AIコーディングツールの進化により、開発者はかつてないスピードでプロダクトを構築できるようになった。しかしその一方で、AIが推奨するサービスやデフォルト設定を深く検証せずに採用した結果、予期せぬ高額請求や依存リスクに直面するケースも増えている。本動画では、Vercelから800ドルの請求を受けた実体験を通じて、AIコーディング時代における新たな課題――コードやサービス設定の理解不足、プラットフォーム依存、そしてAIが書くコードを人間が完全にレビューできない物理的限界――について考察する。開発速度と理解のバランスをどう取るべきか、そしてAI最適化された未来のコード言語が人間に理解不能になる可能性についても問いかける。
AIコーディングがもたらした予期せぬ高額請求
私は失敗しました。バイブコーディングで最高の1ヶ月を過ごし、複数のプロダクトをリリースしました。しかしその後、Vercelからわずか2週間で800ドルという驚きの請求が届いたんです。本当に驚きました。全く予想していなかったんです。そしてこの出来事をきっかけに、AIコーディングの現状について深く考えるようになりました。それが今日お話ししたいテーマです。
さて、Journey Kitsを構築する過程で、当然デプロイが必要でした。そしてVercelは、私のAIコーディングアシスタントが使うように勧めてきた選択肢だったんです。でもここで重要なポイントがあります。コードをほとんど読まないのと同じように、使っているサービスについても深く考えていませんでした。設定方法も、構成も、何も気にせずただ「デプロイ」と言っただけでした。
するとデフォルトで、Vercelはビルドに最も高コストなマシンを選択したんです。しかもビルド設定も最も高コストなものの一部を選んでいました。お見せしましょう。
デフォルト設定の落とし穴
最初の間違いはこれです。デフォルトでVercelはターボビルドマシンを選択します。これはビルド用の非常に強力なマシンで、非常に高コストでもあります。さらにElastic Standard Enhancedも有効になっていて、私の小さなプロジェクトには最上位のビルドマシンは全く必要ありませんでした。
つまりすでに、私はビルドに対して可能な限り最大の料金を請求されていたんです。見てください。ビルド1分あたり12セントも請求されていました。比較のために言うと、今はElasticプランを使っていて、1分あたり0.003セントから始まります。つまりビルド1分あたりの価格が劇的に安くなったんです。
2つ目の問題は、同時ビルドでした。そして聞いてください、AIを使ってコーディングしていたので、1日に何十回もデプロイしていて、しょっちゅう重複したビルドが発生していました。何かをデプロイして、ちょっとした変更を加えたいと気づき、それを修正してデプロイする。でも前のビルドがまだ実行中なんです。
その結果、同時に複数のビルドが走っていて、基本的に全て同じものをデプロイしているのに、全てに対して課金されていました。そこでもう1つオフにした設定がこれです。「全てのビルドを即座に実行」というVercelのデフォルト設定の代わりに、「オンデマンドの同時ビルドを無効化」に切り替えました。これにより全てが順次ビルドされるようになります。
そして最初のビルドが進行中に2つ目のビルドを出した場合は、待つか最初のビルドをキャンセルするかを選べるんです。これでもかなりのコストを節約できました。
実はこの件についてX(旧Twitter)に投稿したんです。というのも、問題はこれだけではなかったからです。これらはVercelのデフォルト設定でした。確認すべきだったんですが、もちろん私は非常に速く動いていて、AIコーダーが全てを推奨してくれていたので、確認しませんでした。ええ、それは私の落ち度です。
コミュニティからのフィードバック
私は失敗しました。そして他にも問題がありました。なぜビルドに数分もかかっているのか、考える時間を取らなかったんです。それでこのツイートを投稿しました。「まあ、このVercelの請求は完全に予想外だった」と。するとTheoが飛び込んできて「一体ビルドプロセスに何が起きてるんだ」と言いました。
私たちは何度かやり取りして、彼は実際に本当に良い提案をいくつかしてくれました。何かがビルドを超遅くしていて、それが請求額が高い理由だったんです。なぜならビルド1分ごとに課金されるからです。ビルドに数分かかれば、数秒で済む場合よりも多く請求されます。そして数分かかる理由なんてないはずなんです。でも繰り返しますが、私はこれについて考えていませんでした。
とにかく早くリリースしたかっただけです。そして請求書を受け取って初めて、「よし、ちょっと立ち止まってこれらの設定を最適化してみるべきかもしれない」と思ったんです。
実際、このスレッドには他にも素晴らしい人々がたくさん飛び込んできて、ビルドを最適化する方法について提案をくれました。今ではビルドは数秒で完了します。しかも最も低いティアを使っています。その結果、週に数百ドル請求されるのではなく、今は数ドルしかかかっていません。
ビルド時間の大幅短縮
ビルド時間をかなり削減した方法をお見せしましょう。まだ改善の余地もあります。元々はこんな感じでした。デプロイするたびに複数回デプロイされ、それぞれが3分以上かかっていました。時には4分かかることもありました。
修正後は、各ビルドが約1分で完了するようになりました。でもここからがポイントです。誰かが「ねえ、GitHubフックを使ってビルドして、Vercelはデプロイだけに使うべきだよ」と言ってくれたんです。それで私もそうしました。
これらの提案は全て、私が考えていなかったことばかりでした。理解できなかったわけではありません。ただあまりに速く動いていたので、そういったことについて立ち止まって考えたくなかっただけなんです。そして800ドルの請求書を受け取って初めて、立ち止まってこれらの小さな最適化について考えるようになるんです。
ちなみに、私はVercelの大ファンです。Vercelのカスタマーサポートチームの誰かがTwitterでDMをくれて、「この件についてカスタマーサポートチケットを作成すべきですよ」と言ってくれました。まだやっていませんが、やるつもりです。もしかしたら返金してくれるかもしれません。ただ、最初は自分が返金に値するとも思っていませんでした。これは私の落ち度です。
これらはVercelのデフォルト設定です。確認する時間を取るべきでした。そしてそれがこの動画全体のポイントなんです。
AIに好みがあるように、私にも好みがあります。今日の動画のスポンサーのように、コンテキストエンジニアリングはAIスタックの非常に重要な部分です。AIが最高の結果を出すために必要な全てのデータを確実に持たせることは、実はかなり難しい問題なんです。
1つのドキュメントで作業しているなら、そのドキュメントを渡せばいいので簡単です。でも何千ものドキュメントがあって、それに動画や記事、他のタイプのメディアを混ぜ始めたら想像してみてください。GbrainやKarpathyのLLM wikiから分かるように、人々は全てを自分で構築しています。でもそれは簡単ではありません。
そこでRecall 2.0の出番です。Recall 2.0を使えば、全てをこのデータの海のようなものに投げ込むことができ、適切なタイミングで適切なコンテキストをAIに提供できます。Recall 2.0では、知識ベースとのチャットとウェブ上でのリサーチを切り替えることができます。
私は全てのOpenCloudの動画をRecallの知識ベースに追加して、最良のセキュリティプラクティスは何かを尋ねることができます。するとRecallはアプリ内で視聴できるタイムスタンプまで提供してくれます。APIとMCPを使えば、すでに使用・構築している任意のシステムにこれを接続できます。
そして最良の点は、1つのモデルに縛られないことです。ぜひRecallをチェックしてみてください。素晴らしいプロダクトです。MB25というコードを使えば25%オフになります。リンクは下の説明欄に貼っておきます。Recallに改めて感謝します。では動画に戻りましょう。
AIコーディング時代の到来
さて、話を広げていきましょう。どうやって私はここに辿り着いたのか。約4、5ヶ月前、AIコーディングの世界で何かが変わりました。Opus 4.5がリリースされ、コーディングエージェントが非常に優秀になったんです。多くの人々が、コードを手動で一切レビューせずに驚異的な速度でコードをリリースし始めました。
実際、AnthropicのClaude Codeチームのリーダーであるボリス・チャーニーは「もう手でコードを書くことは一切ない」と言いました。そして突然、書かれるコードが指数関数的に増加しているんです。これは素晴らしいことです。私のような人間が、数ヶ月かかっていたようなものをわずか数日で構築できるようになりました。
PSPDFKitの創設者であるピーター・スタインバーガーも同じことを言っていました。約5ヶ月前に何かが起こり、彼はコードを読まずにリリースしているんです。そしてそれがトレンドのようです。実際、AIのコードをレビューすることは物理的に不可能です。
その考えを保留しておいてください。この動画の後半で戻ってきます。
サービス選択の自動化とその影響
今、私はこれまで以上に多くのコードを書けるようになりました。これまで以上に速くプロダクトを構築できるようになりました。でも同時に、AIが使うサービスの多くを選択していて、私はそれらについてあまり考えなくなっています。
Vercelは良い例です。Resendというメール送信プラットフォームは、私が構築する全てのプロジェクトで推奨されます。Fly.io、Railwayなども同様です。これらのプロジェクトは全て、私のコーディングエージェントによって推奨され続けています。だから私は「いいね、それを使おう」と言うだけで、それ以上あまり考えないんです。
設定を調整しに行くこともありません。自分のユースケースがこれらのサービスの特定のプランにどう合うかも考えません。これらのサービスの依存リスクについても考えていません。そしてこれは非常に重要です。
私は人生で複数のソフトウェア会社を立ち上げてきましたが、プラットフォームリスクや依存リスクは非常に頻繁に考えていたことです。とても重要でした。会社はどのくらい存続しているのか。稼働時間は。彼らのプロダクトやサービスは私のニーズに正確に合っているのか。サポートはどのくらい良いのか。
もうこういったことは何も考えていません。公平に言えば、今私が構築しているプロジェクトは非常にローステークスです。楽しいと思ったものをバイブコーディングして、世界にリリースするだけです。
でももしあなたが企業で、Anthropicがどれだけ速くリリースしているかを見て、そのスピードを再現しようとしているなら、おそらくAIにこれらの決定の多くを任せているでしょうし、プラットフォーム依存リスクについても考えていないでしょう。
GEOの重要性と急成長するサービス
実際、ここには解きほぐすべきことがたくさんあります。1つは、GEOが非常に重要だということです。GEOはSEOのようなものですが、自社のウェブサイトやサービスが生成AI結果に表示されるようにすることです。
Fly.io、Vercel、Resendのようなサービスが、コーディングエージェントが最初に推奨するものであり続けているという事実は、彼らが急成長しているということを意味します。そして実際そうなんです。
Resendの創設者兼CEOを見てください。彼はつい数日前にこう投稿しました。「Resendでユーザー数200万人を突破しました。わずか4ヶ月前は100万人を祝っていたところです」と。開発者の定義は変わりつつあり、それも急速にです。
つまり、複数のことが起こっていて、それらが互いに複合しているんです。これまで以上に多くの人々が開発していて、これは素晴らしいことです。そしてまた、AIがどのサービスを推奨するかを選択しています。そして何だと思いますか。彼らはResendを選んでいます。
これらのサービスの多くは、このAIコーディングブームから複数の方法で本当に恩恵を受けています。でも繰り返しになりますが、私に起こったことに話を戻すと、私はどのサービスを選ぶかについてますます考えなくなっていて、その選択をAIに任せるようになっています。
実際、私はResendを使っています。
コード生成量の増加と理解度の低下
さて、範囲をさらに広げましょう。私たちはこれまで以上に多くのコードを書いています。コーディングプロセス、構築プロセスの間に、決定をAIにますます委ねるようになっています。そしてこれは良い面も悪い面もあります。それが私が話したいことの核心なんです。
一方では、これまで以上に多くの人々が何かを構築しています。ソフトウェアはより安く、よりアクセスしやすくなっていて、これまで以上に多くのコードを書いています。しかし同時に、実際にはコードをこれまで以上に理解していないんです。そしてそれは大丈夫かもしれませんが、そうでないかもしれません。
Anthropicのように、絶対的に驚異的なスピードでリリースする方法を見つけ出した企業があります。彼らは1日に複数回、新機能や新プロダクトをローンチしています。実際、Twitterユーザーのchad GBT21が、リリーススピードについて素晴らしいチャートをまとめました。
Anthropicは明らかに何かを掴んでいて、それを理解しています。彼らは4月の最初の2週間で13の機能またはプロダクトをリリースしました。これはほぼ1日1つで、とんでもないことです。そしてこれはOpenAI、Google、さらにはxAIよりもはるかに多いんです。
彼らは非常に速く動いています。でもここからが本題です。AIのコードをレビューすることは物理的に不可能です。あちこちの行はレビューできますが、人工知能によって書かれるコードの量が増えるにつれて、コードをレビューする能力は大幅に低下します。実際に全ての行をレビューする物理的な方法がないんです。
レビュー不可能性という新しい現実
何人かの人々は「ああ、でもマット、それは大丈夫だよ。全ての行をレビューする必要はないんだ」と言います。私は「ああ、それは素晴らしいね」と言います。でも、全ての機能さえどうやってレビューするんですか。自然言語であっても、仕様を書いているとき、AIは推奨事項を返してきます。
その推奨事項は、物事がどのように機能するかについての巨大なエッセイです。そしてその時でさえ、全ての自然言語の仕様を読むのに多くの時間を費やしたとしても、実際にデプロイされるものは、私が理解していたものと常に同じではありません。
これは本当に重要なポイントです。私のプロジェクトに、こんなことを頼んだ覚えがないというものが現れたことがあります。
コードをレビューしないことは、バグではありません。機能なんです。意図的なんです。業界が向かっている方向なんです。主要なAIコーディングプロダクト、Cursor、Codex、Claude Codeを見れば、全て実際にコードを見ることから離れていく方向に進んでいます。
デザインパターンは非常に明確で、実際にコードを見ることから離れているんです。IDE、つまりコーディングエディターを覚えていますか。コードを書くためのインターフェースです。以前はコードに主に焦点を当てていました。そして変わり始めました。
Tabキーを押してオートコンプリートしていて、それは素晴らしかったです。でもこれらのモデルがコーディングに優れてくるにつれて、変化し始めました。デザインパターンが変わり始めたんです。突然、Tab補完ではなく、チャットインターフェースができました。「これを作って」とタイプするだけで、素晴らしかったです。
UIデザインの変化が示すもの
でも構築されているコードを見るための大きなウィンドウがありました。そしてCodexとClaude Codeが少し変えたんです。実際のコード閲覧体験を強調しなくなり始めました。そしてCursorでも同じことが見られるようになりました。そして突然、コードベース内のファイルを実際にレビューするためのウィンドウがなくなり始め、CodexやClaude Code Desktopに似た新しいバージョンのCursorができました。
それはチャットインターフェースで、コードの閲覧は二次的なものです。そして突然、こちら側にチャットがあり、こちら側でコードを読めるという状態から変わりました。ディレクトリリストがここにありました。それが新しいバージョンのCursorになり、こんな感じです。
まだコードはレビューできますが、完全に強調されなくなっています。チャットウィンドウです。左側に全ての異なるチャットがあります。中央のメインセクションは実際にはチャット会話です。そして必要であれば右側で開けますが、様々なものが混在していますが、そこでコードをレビューできます。
新しいバージョンのCursorでは、本質的にコードがほとんど全く表示されていません。実際、これは本当に好きな機能なんですが、コードではなく、ブラウザで実際のプロダクトがどのように見えるかを表示しています。「コードのことは心配しないで。最終的なプロダクトをチェックして」と言っているんです。
そしてそれが私たちが見ているものです。スクロールしていくと、たくさんの作業が行われていますが、実際に表示されているコードはほとんどありません。Codexでも同じです。たくさんのコードが書かれていますが、表示されていません。変更されたファイルはこれです、追加したコード行数はこれだけ、削除したコード行数はこれだけ、具体的なファイルはこれです、と言っているだけです。
クリックすれば実際にコードを見ることができますが、クリックした場合だけです。それがこの時点で二次的な閲覧オプションになっているんです。
抽象化レイヤーの最終段階なのか
それがトレンドです。実際のコードを読むことから離れているんです。そして私がこのことについて話す多くの人々は「でもマット、それは抽象化と同じだよね」と言います。ある時点で、私たちはバイナリでコードを書いていました。そしてバイナリから、機械語へと抽象化しました。
機械語から、より読みやすい言語になりました。そしてどんどん抽象化して、最終的な抽象化レイヤーである自然言語に到達しました。それが今私たちがいる場所です。だからマット、これはまた別のレベルの抽象化に過ぎない。なぜこれが違うんだ、と。
私の主張は、私たちは完全に理解していないコードをリリースしているということです。そして理解していないのはコードだけではありません。構築している機能も完全には理解していません。物事が説明される方法は、実際にコード化される方法と正確に同じではないかもしれません。
そして自然言語、これは不完全で曖昧なものと、伝統的なコード、これは完璧で曖昧ではないものとの間には断絶があります。1プラス1は2と言いますが、自然言語はそういう働き方をしません。
低品質コードの量産か、新しいパラダイムか
では、私たちは粗悪品をリリースしているのでしょうか。たぶんそうかもしれませんが、そうでないかもしれません。私が思うより大きな問題は、私たちがリリースしているものを完全に理解していないということです。
モデルは良くなっています。より良いコードを書いています。より少ない説明で私たちの意図を理解することに長けてきています。大規模なコードベースを理解することにも長けてきています。
ですから、私たちは確実に、これらのモデルが膨大な量のコードを書く世界に向かっていて、そのコードを一行一行レビューする必要はないんです。そして実際、もうそこにいます。最前線でリリースしている企業は、コードを読んでいません。
AIがコードを書き、AIがコードを読み、そしてその人はボンネットの下で何が起こっているか理解していません。間違いなくです。
AIに最適化された新しいコード言語の可能性
では、それは私たちをどこに導くのでしょうか。伝統的なコードがなぜあのように見えるのか話させてください。伝統的なコード、特にRubyやPythonのような現代的な言語を見ると、自然言語のように見えます。それでもシンタックス言語です。本質的に決定論的です。でも人間の目には読みやすいんです。
そしてそのように書かれた理由、そのように設計された理由があります。なぜなら人間は実際コードを書いたり読んだりするのが本当に下手だからです。簡単である必要があるんです。バイナリや機械語を見て、何が起こっているか簡単に理解することはできません。
だからますます多くの言語が自然言語のように見えるように移行し、そしてもちろん最終的な飛躍として実際の自然言語をコードとして使うようになりました。
でもここからが本題です。AIはコードを読み書きするのが本当に得意です。そしてAIがコードの大部分を書くというこの道を進むにつれて、これまで以上に多くのコードを書くようになっても、AIは依然として人間の可読性のために最適化された言語でコードを書いています。
でもそれはAIの可読性にとって最適ではないかもしれません。実際、最適ではありません。AIが独自の言語を書き、AIがそのコードを読み書きするために最適化されるという潜在的な未来があります。
でももしAIに最適化されているなら、私たちがそれを理解できない可能性もあります。もしかしたら、私たちが理解できないようなクレイジーなコード設計があるかもしれません。私たちの脳がそれを理解することができないんです。そしてAIがそれを書いている。私たちが理解できる自然言語で説明してくれていますが、正確に説明していないかもしれません。
その結果が私を心配させるんです。
基礎を理解することの重要性
そしてVercelの請求に全てを結びつけると、覚えていますか。それが始まりでしたね。コードの基礎を知ることは依然として非常に重要です。サービスを決定するとき、なぜそのサービスを選ぶべきかを知ること。異なる設定可能性オプションは何か。コードの特定の設計パターンのトレードオフを知ること、これらのことは依然として非常に重要です。
そしてもしプロダクショングレードのシステムを構築しているなら、それらを理解することに投資する必要があります。もしバイブコーダーで、コードを書いた経験がないなら、基礎を学び始めてください。それはあなたを非常に助けることになります。
私たちはこの奇妙な世界にいて、私はこれまで以上にリリースしています。そうすることをこれまで以上に楽しんでいます。でも同時に、書いているコードについて不安も持っています。ほとんど機能することは分かっています。そしてどのように機能するかもほとんど理解しています。でも完全ではありません。
この動画を楽しんでいただけたなら、いいねとチャンネル登録をご検討ください。
コメント