2026-09-12 発行（読了 6 分）
実プロダクトのアーキテクチャ・使用例から AI 開発の現在地を週 3 回・1 号 1 テーマで深掘り
コンテキストウィンドウを増やせば性能も上がる、という前提はすでに崩れている。Chromaの調査は18モデル全てで入力トークンが増えるほど性能が非線形に劣化することを示した。2026年9月、GoogleはエージェントフレームワークADKで、コンテキストを「いま提示すべきもの」と「どこかに保存すべきデータ」に分離するアーキテクチャを公式に説明した。AnthropicやManusの実装にも同じ設計原則がすでに埋め込まれている。今号はこの「コンテキストを保存問題として設計する」という転換を、具体的な実装から追う。
Google ADK（Agent Development Kit）が2026年9月に公開した設計解説では、コンテキストを単一の会話ログではなく、直近のプロンプトを保持する Working Context、構造化イベントとして記録される Session、検索可能な長期知識である Memory、大きな外部データを保持する Artifacts という4層に分けている。invocations数などのしきい値に達すると非同期の compaction プロセスが古い Session イベントを要約し、生データを刈り込みながら Session 自体の整合性は保つ。
この分離が広がっている理由は単純だ。会話を素朴に積み上げる設計では、エージェントが長時間・多ターンで動くほどトークン予算を消費し尽くすうえ、単に容量を増やしても性能は比例して上がらない。Claude Code も、コンテキスト容量の95%に達した時点で auto-compact を発火させ、アーキテクチャ上の決定や未解決のバグは残しつつツール呼び出しの生の結果を優先的に捨てる、という同じ発想の実装を公式に明文化している。
サブエージェントを使う設計でも、境界を越えて子に渡してよい情報は選別されている。Google ADK は include_contents というパラメータで、祖先エージェントの会話やツール結果をどこまで子エージェントに伝播させるかを明示的にスコープし、階層が深くなっても不要な文脈が下流まで流れ込む「コンテキスト爆発」を防ぐ。
Anthropicが自社のマルチエージェント・リサーチシステムで採用したのは、その手前の設計だ。LeadResearcher はサブエージェントを立てる前に、まず自分の調査計画をMemoryに保存する。Claudeのコンテキストウィンドウが200,000トークンを超えると古い内容が切り詰められるため、計画自体を失っても困らない形で先に永続化しておく、という手当てにあたる。
コンテキスト管理はトークン数だけでなく推論コストにも直結する。AIエージェント「Manus」を開発するチームは、KV-cacheのヒット率を本番エージェントにとって最重要の指標だと位置付けている。入力対出力のトークン比が平均100:1に達する同社の環境では、プレフィックスが一致する限り再利用できるKV-cacheが、レイテンシとコストの大部分を決めるためだ。
だからこそ両者は同じ設計判断に行き着く。Google ADK は、安定したシステム指示をコンテキストの先頭に固定し、変化する内容を末尾に寄せることでプレフィックスキャッシュを温存するprocessor順序を採用している。Manus側も、ツール定義を実行途中で動的に追加・削除しないことを明確な指針として挙げている。ツール定義は通常コンテキストの先頭付近にあるため、そこを変更するとそれ以降の全てのKV-cacheが無効化されてしまうからだ。