11月5日、AWSが「Four layers of context engineering for production AI agents: How Deep Insight applies them in working code」と題した記事を公開した。200Kトークンのコンテキストウィンドウを持つモデルを使っても、本番AIエージェントはすぐにコンテキスト超過・精度低下・コスト増大に直面する。同記事はこの問題をアーキテクチャで根本的に制御する4層フレームワークを、実装コード付きで解説している。
200Kトークンでも足りない現実
Anthropic Claude Sonnet 4.5が提供する200Kトークンのコンテキストウィンドウは、一見十分に思える。しかし「売上データを分析してDOCXレポートを作成する」という一見単純なタスクでさえ、15分間で150K超のトークンを消費する。データ探索（5分）、カテゴリ別分析（3分）、チャート生成（10分）、統計検証（3分）、レポート生成（5分）——これらを単一コンテキストで処理すると、ウィンドウ超過、精度低下、コスト増大が次々と発生する。
Anthropicはこの問題を「Context rot（コンテキスト腐敗）」と呼んでいる。コンテキスト内のトークン数が増えるにつれ、モデルが重要な情報を正確に参照できなくなる現象だ。
AWSの記事では、このContext rotへの実践的な対処として、4層のコンテキストエンジニアリングフレームワークを紹介している。参照実装として使われているのは、Strands Agents SDKとAmazon Bedrock AgentCore上に構築されたオープンソースのマルチエージェント分析ソリューション「Deep Insight」だ。
4層フレームワークの全体像
| Layer | アプローチ | 核心原則 |
|---|---|---|
| Layer 1: アーキテクチャ | マルチエージェントによるコンテキスト分離 | 各エージェントが独立したコンテキストで動作 |
| Layer 2: プロンプト | 出力制御と行動ルール | プロンプトでコンテキスト流入を制限 |
| Layer 3: ツール | ファイルベースの外部化 | 重いコンテンツをファイルに追い出す |
| Layer 4: 検証エージェント | 独立した検証とセーフガード | エラー検出とコンテキスト溢れの防止 |
各層は前の層の限界を補う設計になっている。
最も効果的な施策：Layer 3「ファイルへの外部化」
記事中で最もインパクトの大きい施策がLayer 3のツール設計だ。特に「write_and_execute_tool」の実装は、トークン消費を約95%削減するとして紹介されている。
通常、コードの書き込みと実行を別々のツールで行うと、100行のPythonスクリプトがそのままコンテキストのメッセージとして残り続ける。10回の分析で1,000行以上が蓄積される。
Deep Insightではこの2ステップを1つのツールに統合し、コード自体がコンテキストに入らない設計にしている。
# write_and_execute_tool.py
def _handle_write_and_execute_tool(file_path, content, timeout=300):
"""Write a Python script and immediately execute it."""
# Step 1: Write file
with open(file_path, 'w', encoding='utf-8') as f:
f.write(content)
# Step 2: Execute immediately
result = subprocess.run(
f"python {file_path}",
shell=True,
capture_output=True,
timeout=timeout
)
# Return only summary
return f"Written {len(content.split(chr(10)))} lines to {file_path}\n" \
f"Execution successful\n" \
f"Output: {result.stdout[:500]}" # Only first 500 chars
105行のコードを書いて実行した場合、コンテキストに残るのは「105行を書き込み、実行成功、5カテゴリの分析完了」という3行程度のサマリーだけだ。
Layer 1：マルチエージェントによる分離
Deep Insightは Coordinator、Planner、Plan Reviewer、Supervisor、Tool Agents（Coder、Validator、Reporter、Tracker、Auditor）という階層構造を持つ。各エージェントが独立したコンテキストウィンドウを持ち、最もトークンを使うCoderでさえ合計25K以下に収まる。
エージェント間で共有されるshared_stateは次の4つのみに限定している：
messages: 直前エージェントの最終メッセージ（会話履歴全体ではない）clues: 各エージェントからの圧縮サマリーfull_plan: Plannerが生成し、Trackerが更新するチェックリストhistory: エージェント名とメッセージの簡易ログ
# coder_agent_tool.py -- context passing format
CLUES_FORMAT = "Here is clues from {}:\n\n<clues>\n{}\n</clues>\n\n"
RESPONSE_FORMAT = "Response from {}:\n\n<response>\n{}\n</response>\n\n*Please execute the next step.*"
# After Coder completes: add only compressed result to clues
clues += CLUES_FORMAT.format("coder", response["text"])
このオーケストレーター＋ワーカーパターンは、Strands Agents SDKのagents-as-tools機能として提供されており、自前実装は不要だ。
Layer 2：プロンプトによる出力制御
Layer 1でコンテキストを分離しても、各エージェントが長い応答を返せばSupervisorのコンテキストが膨らむ。Layer 2ではプロンプトで各エージェントの出力量を明示的に制限する。
各エージェントには出力トークン上限が設定されている：
- Coder: 1,000〜1,500トークン（コードはファイル保存、サマリーのみ返す）
- Validator: 800トークン（検証結果はcitations.jsonに保存）
- Reporter: 1,000トークン（DOCXファイルを生成し結果サマリーのみ返す）
また、Coderのプロンプトには「スクリプト間で変数は持続しない」というルールが明記されており、各スクリプトを自己完結型にすることで、過去のコードをコンテキストに残す必要をなくしている。
さらに、共通ロジックをcoder_analysis_utils.pyモジュールとして事前生成し、各分析スクリプトでインポートする設計により、200〜300行の重複コードを2行のimport文に置き換えている。
Layer 4：独立した検証エージェント
Layer 1〜3を適用してもエラーや漏れは残る。Layer 4ではAuditorエージェントをはじめとする独立した検証エージェント群が最終防衛ラインを担う。
Auditorは他のToolエージェントとは独立したコンテキストで動作し、各ステップの完了状態・出力ファイルの存在確認・エラーログの照合を行う。Supervisorのプロンプトには「現在のエージェントのセクションのチェックリスト項目がすべて[x]になるまで次のエージェントに進まない」というルールが明文化されており、コンテキスト溢れの検出やリカバリ判断もAuditorが担う設計だ。
# supervisor_prompt（抜粋・概念コード）
"""
Before moving to the next agent, verify:
- All checklist items for the current section are marked [x]
- Auditor has confirmed output files exist and are valid
- No unresolved errors in the error log
If any condition is unmet, re-invoke the current agent rather than proceeding.
"""
このAuditorによるゲーティングにより、途中ステップの失敗が後続エージェントのコンテキストに流入して汚染されるリスクを防いでいる。エラー情報をコンテキストに蓄積させずにリトライで吸収する点が、Layer 3のファイル外部化と組み合わさって特に有効に機能する。
まとめ
記事が示す核心は、コンテキストエンジニアリングが「プロンプトの書き方」だけで解決できる問題ではないという点だ。アーキテクチャ設計、プロンプト制御、ツール実装、検証の4層を組み合わせることで初めて実用的な効果が得られる。write_and_execute_toolによるトークン消費95%削減という数字は、アーキテクチャレベルの設計変更が如何に大きな効果をもたらすかを示している。
詳細はFour layers of context engineering for production AI agents: How Deep Insight applies them in working codeを参照していただきたい。
