7月18日、Saqib Janが「AI-Generated Code Is Cheap But the Context Infrastructure Behind It Is Not」と題した記事を公開した。AIによるコード生成のトークンコストは下がり続けているが、モデルに正しいコンテキストを与えるためのインフラコストは逆に上昇しており、それが本番運用の真のボトルネックになっているという実態を、複数の実務家の証言をもとに詳しく掘り下げている。

「コード生成は安い」の裏側で何が起きているか

AIでコードを生成するコストは急速に下がった。かつてシニアエンジニアが午後を丸ごと使っていた作業が、今では数分でスキャフォールドできる。トークン単価は下がり続け、生産性議論の表面上の指標では「経済的に有利」という結論しか出ない。

しかし本番運用に踏み込んだチームは、別のコストに直面している。モデルが「実際に正しく、保守可能で、安全にシップできるコード」を生成するために必要なコンテキストを与えるインフラのコストは、下がっていない。むしろ上がっているケースが多い。

そしてそのインフラは、多くのチームにまだ存在しない。

ボトルネックはモデルではなく「検索層」だ

近年「コンテキストエンジニアリング」という言葉がAIインフラの文脈で頻繁に語られるようになった。ただしこの言葉にはすでにハイプが蓄積されており、問題の本質を正確に押さえる必要がある。

コードレビュー支援ツールQodoのCEO兼共同創業者であるItamar Friedmanは、「メモリシステム」と「ブレイン」の違いを軸に問題を整理する。

単に情報を格納して取得するだけのシステムはメモリだ。本番AIアプリケーションが必要とするのはそれではなく、情報間の関係を理解し、取得した情報が陳腐化しようとしていることを認識し、明示的に問われなくても関連情報を浮上させられるシステムだ、とFriedmanは言う。

「メモリは過去10年間に使われたAPIをすべて記憶しているかもしれない。でも同時に、あるAPIが間もなく非推奨になって別のAPIに移行すべきだ、ということも記憶しているべきだ。あるAPIについて質問されたとき、それが非推奨予定であることを推論して、別のAPIについて聞くべきだと判断できる——それがメモリとブレインの違いだ。」

この議論から導かれる重要な結論がある。「あらゆるドメインの質問に答えられる汎用コンテキストエンジン」を構築したと主張する製品は、それが本当なら事実上AGI（汎用人工知能）に近いものを作ったことになる、というものだ。現実に価値を生んでいるコンテキストエンジンは、単一のユースケースに深く特化したものだ。

Friedmanは自社についても率直に認める。「Qodoのコンテキストエンジンをヘルスケアやカスタマーサポートに使おうとすると、それは問題だ。」特化性はよく設計されたコンテキストエンジンの「制限」ではなく、機能させるための工学的選択だ。

RAGは「2段階の問題」であり、チームは混同している

NetAppのオープンソースコントリビューションマネージャーであるCarlos Juzarte Roloは、データインフラ側からこの問題を診断する。

本番でコンテキスト品質が劣化する原因は、ほぼ例外なく生成モデルの問題ではない。モデルへ情報を渡す検索ステップ（retrieval）が適切なコンテンツを引き出せていないことが原因だ。しかしチームはモデルの出力が見えているため、モデルをデバッグしてしまう。

「RAGは2段階の問題だ。まず検索を直す、そして正しい順序でLLMにコンテキストを渡す。この2つは異なる失敗モードを持ち、異なる解決策が必要だ。」

なおRAG（Retrieval-Augmented Generation）とは、LLMの推論時に外部知識ベースから関連情報を動的に検索して入力に付加する手法で、モデルのパラメータ自体を更新せずにドメイン知識を与えられる点が特徴だ。

Roloが実際に経験したのは、ベクトル検索に加えてキーワード検索を組み合わせることで検索品質が大幅に改善したケースだ。ベクトル検索が優れているのではなく、両者は異なる問題を解くため、どちらか一方を万能解として選ぶべきではない、という結論だ。

もう一つ、見落とされがちな問題が「コンテキストロット（Context Rot）」だ。これは元記事で使われている造語で、コンテキストウィンドウ内に無関係・低品質な情報が蓄積することで、必要な情報が含まれていてもモデルの推論品質が劣化していく現象を指す。

「低品質なコンテキストが大量にあると、その中に必要な情報が含まれていても良い手法とは言えない。必要なコンテンツと大量の無関係な内容が混在した状態は、コンテンツが少なすぎる状態と同程度に悪い可能性がある。」

コンテキストは大きければ良いのではなく、精度の高いものが少量の方が、モデル出力が改善する。検索アーキテクチャはリコールではなく精度を最適化すべきだ、というのがRoloの主張だ。

エンタープライズ導入が止まる場所

TestMu AIの共同創業者Mudit Singhは、エンタープライズ導入の現場で一貫したパターンを観察している。チームはモデル選定に多大な投資をし、検索品質にはほぼ何も投資しない。そして最終的に、初速で節約した時間より多くの時間をデバッグに費やす。

モデルは可視で、比較可能で、マーケティングできるコンポーネントだ。検索インフラは不可視のコンポーネントだが、それがモデルの約束を実現できるかどうかを決定する。

本番運用のリトリーバルシステムが抱えるもう一つの構造的問題がある。メンテナンスコストだ。基盤データは変化し続ける。ユーザーが何を聞くかの分布も変わる。モデル自体もアップデートされる。これらの変化は、アラートを一切発火させることなく、静かに検索品質を劣化させる。

「AIパイプラインから持続的な価値を得ているチームは、コンテキストエンジニアリングを専任オーナーを持つ継続的な規律として扱い、定期的な検索品質ベンチマークと、データ分布が変化したときにパイプラインを更新する明確なプロセスを持っている。」

これはスプリントやローンチマイルストーンに収まるものではなく、システムのライフタイム全体にわたって維持すべき運用姿勢だ。

グラフDBとエージェントルーティング：Qodoのアーキテクチャ

データベース選定については、Roloが実用的な助言を示している。「データベースの世界で最良のアドバイスは、すでに持っているデータベースだ。ベクトルをサポートしているなら、そこから始めよ。」本番AIシステムの構築と並行して新しいインフラを導入する組織的コストは、ベンチマーク上の性能差より往々にして大きい。

一方でFriedmanのQodoは、コードアーティファクト・PRレビュー決定・開発履歴の関係性が本質的にリレーショナルであることから、**グラフデータベースを主基盤**として採用している。グラフDBはノードとエッジで構成されるデータ構造を持ち、エンティティ間の関係そのものをファーストクラスで表現できる点が特徴だ。ベクトルストアだけでは表現できない、APIとそれを導入したPRの依存関係、レビューコメントとコード変更の接続、特定バージョンにおける関数の非推奨状態——こうした構造をグラフとして保持する。

「メタデータを取り込んでグラフとベクトルDBを組み合わせた複数のデータベースに変換するインジェスション機構があり、クエリ層ではルーティングエージェントが複数のツールに問い合わせを振り分ける。各ツールはそれ自体がエージェント的に動作する場合もある。」

これは標準的なRAG実装よりはるかに複雑なアーキテクチャだ。しかしコード品質・レビューというドメインでは、アーティファクト間の関係がコンテンツそのものと同程度に重要であり、その複雑さは正当化される。

本番とデモを分けるもの

本番環境でコンテキストエンジニアリングを一度きりの設定ステップとして扱うか、継続的な工学的規律として扱うか——その差がデモと本番の間のギャップを生み続ける、というのがこの記事の核心だ。モデルの性能比較に目が向きがちな現状において、検索インフラへの投資と運用設計こそが、AIシステムの長期的な価値を左右する、というメッセージは実務的な重みを持つ。

詳細はAI-Generated Code Is Cheap But the Context Infrastructure Behind It Is Notを参照していただきたい。