あなたの AI エージェントは何も覚えていない：コンテキスト肥大化を直す MCP の工夫

誰も宣伝しない問題

AI コーディングエージェントのデモはいつも同じだ。きれいなターミナル、明確な指示、整った結果。だが 3 時間目の様子を見せる人はいない。その時点でエージェントは 40 個のファイルを読み、十数のテストスイートを走らせ、これまで実行したすべてのコマンドの雑音まじりの出力でコンテキストウィンドウを埋め尽くしている。その状態のエージェントは賢くなるどころか、鈍くなり、忘れっぽくなり、すでに終えた作業を自信満々に繰り返す。

これはエージェント型コーディングで最も地味で、最も普遍的な問題だ。コンテキストはエージェントの作業記憶であり、有限である。エージェントが読むものはすべて同じ空間を奪い合い、その大半はゴミだ。ビルドログ、スタックトレース、ディレクトリ一覧、1 行だけ必要だったのに全文を読み込んだファイル。ウィンドウは堆積物で埋まり、そもそもエージェントを役立たせていた推論が押し出されていく。

これを解決するツールは、ベンチマーク比較で勝つ類のツールではない。配管だ。そしてこの 10 月、GitHub のトレンドに登ったのは、その配管だった。

ツール出力 sandboxing の背後にある考え方

浮上した中でも特に興味深いプロジェクトの一つは、コーディングエージェント向けのコンテキスト最適化レイヤーで、問題の根本に切り込む。その看板となる数字は、モデルに届くツール出力の量が約 98% 減るというものだ。

仕組みは概念としては単純だ。コマンドの生の出力をそのまま会話に流し込む代わりに、sandbox の中で実行し、結果からモデルが必要とするものだけを渡す。要約、終了ステータス、クエリに一致した特定の行。完全な記録はモデルが意図的に取得できる状態のまま保たれるが、役に立つかもしれないという理由だけでウィンドウの場所を占め続けることはない。

それは有能なエンジニアが習慣として実践しているのと同じ規律だ。エラーの 1 行が要点なら、ログ全体をチャットに貼り付けたりしない。放っておかれたエージェントは、まったく逆のことをする。

これには請求書がついてくる。だからこの道具立ては単なるエンジニアリング上の気遣いではない。コンテキストウィンドウは無料ではない。モデルが処理しなければならないトークンはすべて、金と時間を食う。記憶しなければならないトークンはすべて、注意力を食う。ビルド出力を 10 万トークン分セッションに流し込むツールは、二重に請求している。トークン代として一度、信号が埋もれることでモデルの判断力が落ちる分としてもう一度。この 98% の削減は、実のところコスト削減の衣をまとった品質の修正だ。

セッションより長く生きる記憶

問題の残り半分は、エージェントがセッション内だけでなく、セッションをまたいで忘れることだ。ターミナルを閉じればコンテキストは消える。翌日開き直しても、エージェントはあなたが何を決め、どの方針を却下し、なぜコードが今の形になっているのか、何もわからない。あなたはもう一度説明し、エージェントはもう一度導き出し、どこかで同じ決定が二度下される。

この領域の永続メモリのツールは、それぞれ違うアプローチを取る。最も目立つものの一つは、エージェントがセッション中に行ったことを取り込み、モデルで圧縮し、関連する部分を今後のセッションに注入する。売り文句は地味だが正しい。プロジェクトの輪郭を覚えているエージェントは、単一のタスクでわずかに賢いエージェントよりも価値がある。主要なモデルベンダーも同じ方向に動いており、subagent が親の会話より早く自分の context を圧縮できるつまみを加えている。まさに、まったく必要としないタスクにセッション全体の履歴を持ち込まないためだ。

ここで興味深い設計上の問いは、何を覚えるかだ。すべてを覚えれば、元の問題をより遅い形で作り直したことになる。覚えなさすぎれば、記憶は役に立たない。勢いを得ているプロジェクトは、選んで覚えるタイプだ。過去 1 か月の良い要約は、過去 1 時間の完璧な記録に勝る、という理屈である。

コンテキスト戦略としての routing

パズルの三つ目のピースは routing だ。タスクが走る前に、どのモデルとどのツールが必要かを決めておく。そうすれば、決して使わない能力を積み込まれずに済む。17 種類の異なる統合について知らされたモデルは、タスクがそのうち一つしか必要としなくても、17 種類すべてにコンテキストを使う。プラットフォームをまたいで routing を強制するのは、インフラの細部のように聞こえる。だが実際は、変装したコンテキスト予算の決定だ。

ここで問題はキャッシュの問題に見えなくなり、システム設計に見え始める。エージェントのコンテキストウィンドウは資源であり、メモリやディスクが資源であるのと同じだ。そしてそれを資源として扱うツールが、長い仕事を通じてエージェントを一貫した状態に保つ。sandboxing、記憶、routing のプロジェクトが収束しているのは偶然ではない。同じ希少性の三つの見方なのだ。

subagent パターンが最も明確な例だ。エージェントが狭い仕事をする助っ人を生み出すとき、その助っ人は会話全体を引き継ぐ必要がない。目の前のタスクだけを含むきれいなコンテキストを渡すほうが、安くて正確だ。だから新しい harness は、subagent が親より早く自分の context を圧縮できるようになっている。親は長い履歴を保ち、子はまっさらな机を与えられる。1 週間に及ぶリファクタリングでエージェントを走らせてきたチームは、たいていこの規則に自力でたどり着く。多くの場合、ある subagent が不要な会話を読み直すだけでウィンドウを使い切るのを見た後で。

なぜ今なのか

これらの問題に新しいものは一つもない。最初のエージェントが走ったときから、エージェントはコンテキストを失い続けてきた。変わったのは、エージェントが何時間も、多くのセッションをまたいで、本当に重要な仕事を走り続けることを期待されるようになった点だ。おもちゃは忘れても何も失わない。チームが 1 週間のリファクタリングで頼りにするツールは、忘れると大きなものを失う。

市場は気づいている。2 年前、「うちのエージェントは 200k のコンテキストウィンドウがある」は売り文句だった。今、役に立つ問いは、そのウィンドウのどれだけの割合が信号に使われているかだ。これを理解したベンダーは圧縮の制御と subagent の context 分離を出荷している。コミュニティは残りを耐えられるものにする配管を出荷している。

地味な結論

10 月のエージェントのニュースを、より賢いモデルとより巧妙なプラグインの話として読む誘惑がある。だがより静かで、より持続する話は衛生（hygiene）についてだ。エージェントは長時間走らせられるほど役立つようになり、長時間走らせると、自分自身の記憶をどう管理しているかの弱点がすべて露呈する。

トレンドチャートを登っているプロジェクトは、ありふれた真実を受け入れたものだ。自律的な仕事のボトルネックが、素の知能であることはまれだ。自分のメモに溺れずにタスクに留まり続ける能力こそがボトルネックだ。記憶を直し、雑音を sandbox に収め、能力を routing すれば、そこそこのモデルが突然、優秀に見える。これらを誤れば、最先端のモデルですら午後を、すでに 5 回読んだログファイルの読み直しに費やす。