AWSがAIエージェントのコンテキスト管理を4層に整理、Deep Insightで実装例

何が示されたのか

AWSの機械学習ブログ「Four layers of context engineering for production AI agents」は、本番環境で動くAIエージェントのコンテキスト管理手法を4つの層に整理し、動作するコードで各層の実装を示した。参照実装として使われたのは、Strands Agents SDKとAmazon Bedrock AgentCore上に構築されたオープンソースのマルチエージェント型データ分析ソリューション「Deep Insight」である。

記事は連載の第2回にあたる。第1回では本番マルチエージェントが解くべき5つの課題を定義し、Strands Agents SDK、Amazon BedrockとBedrock AgentCore、AWS Fargateがそれぞれどの層を担うかをコード例付きで紹介した。今回はその上に載る実践的な設計論が主題となる。第3回はAmazon VPC内の閉域網へのデプロイと運用を扱う予定とされている。

記事は、AnthropicのエンジニアリングブログとStrands Agents SDKの機能が同じ4層構造に収束していると説明する。4層とは、アーキテクチャでコンテキストを分離する、プロンプトで流入を制御する、ファイルシステムへ外部化する、独立したエージェントとセーフガードで検証する、というものである。

200Kトークンの壁

Amazon Bedrockで利用できるClaude Sonnet 4.5は200Kのコンテキストウィンドウを持つが、複雑な本番タスクはすぐにこれを超えると記事は指摘する。「売上データを分析してDOCXレポートを作成する」という一見単純な依頼でも、データの読み込みと探索(5分)、カテゴリ別の売上分析(3分)、時系列分析用の5つのグラフ生成(10分)、統計的検証(3分)、最終レポート生成(5分)という段階を踏み、15分間で150Kトークン以上を消費するという。

単一のコンテキストで処理すると、途中でウィンドウがあふれる、古い文脈が残って精度が落ちる、エラー時にパイプライン全体をやり直す必要がある、といった問題が起きる。コンテキストが長くなるほど重要な情報への注意が薄れ、トークン単位の課金のもとではコストも膨らむ。

記事はAnthropicの「Effective Context Engineering for AI Agents」(2025.09)から、トークン数が増えるほどコンテキストから情報を正確に想起する能力が下がるという「Context rot」の指摘を引用している。コンテキストエンジニアリングは、この問題に対する設計・プロンプト・ツール実装・検証にまたがる層的な取り組みだと位置づけられている。

第1層と第2層の実装

第1層は、専門エージェントごとに独立したコンテキストウィンドウを持たせ、オーケストレーターには圧縮した結果だけを渡す設計である。Deep InsightはCoordinator、Planner、Plan Reviewer、Supervisor、そしてCoder・Validator・Reporter・Tracker・Auditorというツールエージェントの階層でこれを実現している。共有するのはshared_stateというPython辞書に入れたmessages、clues、full_plan、historyの4つだけに絞っている。

この結果、最も多くトークンを使うCoderでも合計25Kトークン未満に収まるという。エージェント間の受け渡しはCLUES_FORMATという固定書式で圧縮された要約のみを渡す。記事はAnthropicのオーケストレーター・ワーカーパターンと同じ発想であり、Strands Agents SDKのagents-as-toolsパターンを使えばフレームワーク側で分離できると説明する。

第2層はプロンプトで各エージェントの出力量を制限する。エージェントごとに応答トークンの上限を指定し、Status・Completed Tasks・Key Insights・Generated Filesという共通フォーマットで返させる。加えてCoderのプロンプトには「変数はスクリプト間で保持されない」と明記し、すべてのスクリプトを自己完結させることで、過去のコードをコンテキストから安全に外せるようにしている。

第3層の外部化と削減効果

第3層は、コードやデータといった重い内容をコンテキストの外、つまりファイルシステムに追い出す。Coderが100行のPythonコードを書くとそのコード自体がコンテキストに入ってしまい、スクリプトが増えるほど蓄積する。記事では、ファイル書き込みツールと実行ツールを分ける従来構成では1,000行を超えるとしている。

Deep Insightはこれをwrite_and_execute_toolという1つのツールに統合した。ファイルを書き込んですぐ実行し、コンテキストには「105行を書き込み、実行成功、5カテゴリの分析が完了」といった数行の要約だけを返す。記事の試算では、これによりスクリプト1本あたりのコンテキスト消費を約95%削減できるという。

記事はさらに、Anthropicの「Code Execution with MCP」(2025.11)にあるサーバーサイドフィルタリングの事例として、実行層でデータを絞り込むことで150Kから2Kへ98.7%のトークン削減になったという数字も引いている。これはDeep Insightの計測値ではなく、Anthropicの記事からの引用である。

現時点での留意点

記事の抜粋では、4層のうち第4層「独立したエージェントとセーフガードによる検証」の具体的な実装は示されていない。第1層から第3層についてはコード断片付きで説明されているが、第4層の内容は元記事の本文で確認する必要がある。

また、示されている削減率(約95%、約97%)はDeep Insightという特定の参照実装での試算であり、他のワークロードにそのまま当てはまるかは明らかでない。トークン数の削減がそのままコスト削減になるかは、モデルの単価やリクエストの構成にも左右される。

Deep Insightのリポジトリ構成やライセンス、対応リージョン、性能ベンチマークについては、この抜粋からは分からない。第3回で扱われるVPC構成や運用面の詳細も、公開後に確認する必要がある。