AIビルダーに、ログインフローを一通り動くように組んでもらう——フォーム、バリデーション、ルーティング、データベースチェックまで——と頼むと、たいてい差分が表示されるまでに35秒から90秒ほど待つことになります。このリクエストをエンドツーエンドで計測すると、モデル自体、つまり実際にトークンを生成している部分は、その約3〜4秒しか占めていません。ネットワークの往復でさらに1〜2秒。残りの30秒以上、つまりあなたが「AIが考えている」と感じている部分は、ほぼ別のもの——エージェントチームがファイルを読み込み、ビルドを実行し、結果を表示する前に自分の作業をチェックしている時間——です。
この比率を初めて計測結果として見たとき、ほとんどの人が驚きます。これを仕事として作っているエンジニアも例外ではありません。「大きくて遅いモデルがボトルネックに違いない、だから遅いビルドを直すには速いモデルを使えばいい」という直感が働きがちです。それが正しいこともありますが、たいていは違います。なぜそうなのかを理解しておくと、プロンプトのサイズやプロジェクトのサイズについての考え方、そしてビルドが「固まっている」ように感じるときに何を期待すべきかが変わってきます。
実際に時間を占めているもの
「機能を追加する」という1つのリクエストをフェーズごとに分解すると、すぐにあるパターンが見えてきます。モデルは短く安価なバースト——次に何をするか決めて、ツール呼び出しを書き、結果を読む——に時間を使う一方で、コストがかかる遅い部分はそのバーストの合間、つまりディスク上やシェル内で起きています。
| フェーズ | 総所要時間に占める典型的な割合 | 実際に起きていること |
|---|---|---|
| モデル推論(生成) | 5–10% | 生成されているトークン——計画、コード、ツール呼び出しの引数 |
| ファイル読み込み / コンテキストの組み立て | 10–15% | 既存ファイル、過去の実行履歴、プロジェクトの規約を取り込む処理 |
| ツール実行(書き込み、シェル、パッケージのインストール) | 35–45% | 実際にファイルを変更し、リンターを実行し、依存関係をインストールする処理 |
| ビルド / コンパイル工程 | 15–25% | フレームワークのビルド、型チェック、バンドリング——これはプロンプトのサイズではなくプロジェクトのサイズに比例してスケールします |
| 検証エージェント | 15–20% | 差分が依頼した通りの内容になっているかを表示前にもう一度チェックする工程 |
| ネットワーク / ストリーミングのオーバーヘッド | 2–5% | モデル、サンドボックス、ブラウザ間の往復通信 |
この表から導かれる2つの事実は、並べて見るまで明らかにはなりません。1つ目は、ビルド工程はプロンプトのサイズではなくプロジェクト全体のサイズに比例してスケールするということです——400ファイルのアプリに対する1行のCSS修正は、まっさらなプロジェクトに追加された5ファイルの機能よりも検証に時間がかかることがあります。どちらの場合でも、コンパイラがチェックしなければならない量はより多いからです。2つ目は、最大の対策はそもそもモデルではないということです。それは、どれだけの範囲が変更に触れるかです。
この錯覚が成立してしまう理由
ストリーミング形式のUIも、良い意味である程度この錯覚に加担しています。最初のトークンは通常1秒以内に表示されるため、計画が組み立てられていく様子や文章が打ち出されていく様子、ツール呼び出しがスクロールしていく様子が見えて、UIはすぐに反応しているように感じられます。この最初のトークンが表示されるまでの遅延こそ、人が「AIの速さ」として脳内で記録するものです。しかし、モデルが何をするか決め終えると、その後は言語モデリングとは全く関係のないビルドパイプラインに処理が引き継がれるということは、あまり意識されません。`docker build`や`npm install`、importグラフをたどる型チェッカーなど——これらはGPT-5がGPT-4に置き換わったからといって、あるいはSonnetが旧バージョンのSonnetに置き換わったからといって速くなるわけではありません。誰かが依存関係のレイヤーをキャッシュしたり、不要なチェックを省いたりすることで速くなるのです。
「ビルドが遅い」のを直そうとして、ビルダーが同じ週に2回もプロジェクト途中でモデルを乗り換えるのを見たことがあります。実際のボトルネックは、保存のたびに増分チェックではなくフルの型チェックを再実行している検証パスだったと後で気づくのですが。モデルの乗り換えは何も変えませんでした。そもそもモデルが遅い部分ではなかったからです。
実際に問題になる場面
実務上の影響は、いくつかの予測可能な場面で現れます。
- 大きく広範なプロンプトは不釣り合いなほど遅く感じられます——モデルがそれを解析するのに苦労しているからではなく、12個のファイルに触れるリクエストが12回のファイル読み込み、12回の書き込み、そしてそれらすべてを整合させる必要のあるビルドを引き起こすからです。
- プロジェクトが大きくなるほど、反復のたびに遅くなっていきます。個々のプロンプト自体はシンプルなままでも、ビルドと検証のフェーズはプロジェクト全体のサイズに比例してスケールするからです。
- 「固まっている」ように見えるのは、めったにモデルが停止しているわけではありません。ほとんどの場合、パッケージレジストリの応答待ちのビルド工程か、再実行する必要のなかったチェックを繰り返している検証エージェントのどちらかです。
- 1つの大きな依頼をいくつかの小さな依頼に分割すると、合計時間が短くなることがよくあります。それぞれの小さなリクエストがより狭い範囲のビルドと軽い検証パスを引き起こすためです。個々のステップを待つ回数自体は増えるのですが。
私たちのDiscordのあるメーカーがうまく言い表していました。「もっと速い頭脳が欲しいと言い続けていたが、本当に必要だったのはもっと小さな差分だった」
実際に待ち時間を短縮するもの
本当に効く対策はどれもモデルを大きくすることとは関係ありません。プロジェクト全体ではなく変更部分だけを再コンパイルする増分ビルドは、ビルドフェーズの割合を劇的に削減します——これは利用可能な単一の対策としては最大のもので、他のあらゆる最適化を合わせたよりも効果があることが多いです。実行のたびに依存関係のインストールをキャッシュすることで、特定のプロンプトとは無関係なツール実行フェーズの負担を取り除けます。コードベース全体を毎回チェックするのではなく、実際の差分に検証の範囲を絞ることで、このフェーズを既存のもの全体ではなく変更内容に比例させられます。そして独立したツール呼び出しを並列で実行すること——無関係な3つのファイルを順番にではなく同時に読み込むこと——は、モデルに一切手を加えることなくファイルI/Oフェーズから実際に数秒を削減します。
どれも地味な対策です。しかし、これこそが同じ日に同じプラットフォームへほぼ同じプロンプトを入力した2人のビルダーが、「賢さ」や「速さ」について全く異なる体験をする理由でもあります。実際の違いはモデルの品質ではなく、プロジェクトの形にあるのです。モデルはあなたが見ていた時計そのものではありませんでした。ただそう見えていただけです。
