本番環境向けAIエージェントのためのコンテキストエンジニアリング4層戦略

本番環境のAIエージェントは、データ分析などの複雑なタスクにおいて、コンテキストウィンドウを使い果たすために失敗することがよくあります。Amazon Web Servicesが公開した新しい参照実装「Deep Insight」は、このボトルネックを解決するための4層戦略を概説しています。2026年11月4日に公開されたこのガイドでは、精度を維持しコストを削減するために、コンテキストを分離、制御、外部化、および検証する方法の詳細が説明されています。

何が起きたか

大規模言語モデル（LLM）は、Amazon Bedrock上のAnthropic Claude Sonnet 4.5で利用可能な20万トークンなど、十分な容量のコンテキストウィンドウを提供します。しかし、実際のワークフローではこの容量がすぐに消費されてしまいます。売上データの分析とレポート生成といった典型的なリクエストには、データ読み込み、統計的検証、グラフ生成など複数の段階が含まれます。これらのステップはわずか15分で15万トークン以上を消費する可能性があり、実行中の失敗、古い情報による精度の低下、そしてコストの増加につながります。

これに対応するため、AWSのエンジニアはStrands Agents SDKとAmazon Bedrock AgentCore上に構築されたオープンソースのマルチエージェントソリューション「Deep Insight」を開発しました。このシステムは、単純なプロンプト調整を超えた包括的なアーキテクチャ規律として、構造化されたアプローチでコンテキストエンジニアリングを適用します。実装により、これらの技術を組み合わせることで、各スクリプトによって追加されるトークンを約95%削減し、システムプロンプトを約97%縮小できることが示されています。

このガイダンスは、4つの明確なレイヤーに整理されています。アーキテクチャレベルでのコンテキストの分離、プロンプトを通じた制御、ファイルシステムへの外部化、そして独立したセーフガードによる検証です。この階層化された手法により、ある技術が限界に達したときでも次のレイヤーが補完し、単一エージェントシステムを悩ませる「コンテキスト腐敗（context rot）」を防ぎます。

仕組み

第1のレイヤーは、アーキテクチャレベルでの分離に焦点を当てています。すべてのタスクを単一のエージェントで実行する代わりに、Deep InsightはCoordinator、Planner、Supervisor、および various Tool Agentsを含む専門化されたエージェントの階層構造を使用します。各エージェントは独自の独立したコンテキストウィンドウ内で動作します。それらは完全な会話履歴ではなく、圧縮された要約や「手がかり（clues）」のみを含む共有状態辞書を通じて通信します。これにより、Coderなどの最もアクティブなエージェントであっても、2万5千トークン未満に抑えられます。

第2のレイヤーは、厳格なプロンプトエンジニアリングを通じてコンテキスト流入を制御します。各エージェントには明示的な出力トークン予算があります。例えば、Coderエージェントは実際のコードがチャットで返されるのではなくファイルに保存されるため、1,500トークンに制限されています。プロンプトはまた、自己完結型コードの哲学を強制し、すべてのスクリプトに独自のインポートとデータ読み込みロジックを含めることを要求します。これにより、以前のスニペットをメモリに保持する必要がなくなり、古いコンテキストを安全に破棄できます。

第3の、そして最も影響の大きいレイヤーは、重いコンテンツをファイルシステムに外部化します。Deep Insightは、個別の書き込みツールと実行ツールを単一の write_and_execute_tool に置き換えます。このツールはPythonコードをファイルに書き込み、即座に実行して、簡潔な成功サマリーのみをエージェントに返します。コード自体はコンテキストウィンドウに入りません。さらに、共通ロジックは再利用可能なモジュールに保存され、詳細な分析結果は all_results.txt のような構造化テキストファイルに保存されます。エージェントは必要に応じてのみこれらのファイルを読み取り、アクティブなコンテキストを軽量に保ちます。

主要な詳細

• Deep Insightは、書き込みと実行を組み合わせたツールを使用することで、スクリプトのコンテキスト使用量を約95%削減します。
• スキルのオンデマンド読み込みにより、システムプロンプトのサイズが約97%縮小します。
• システムは shared_state 辞書を使用して、圧縮された手がかりと完了通知のみをエージェント間で受け渡します。
• Coderエージェントは1,000〜1,500の出力トークンに制限されており、コードをダンプするのではなく要約することを強います。
• 共通ユーティリティ関数は、複数エージェントターンにわたる重複コードの再生成を避けるため、事前に coder_analysis_utils.py モジュールとして生成されます。
• all_results.txt のような構造化ノートテイクファイルは、冗長なメッセージパッシングを置き換える、エージェント間通信バスとして機能します。

なぜ重要なのか

本番AIシステムを構築するエンジニアにとって、コンテキスト管理はもはや単なるパフォーマンス最適化ではなく、信頼性の要件です。これらのレイヤーがない場合、コンテキストウィンドウが埋まるにつれてエージェントは注意散漫になり、重要な指示が失われ、モデルは幻覚を起こしたり最近の制約を無視したりし始めます。コンテキストを分離することで、チームは各サブタスクが関連しない履歴からの干渉を受けずに、モデルの全注意力を受け取れることを保証できます。

コスト効率もまた重要なドライバーです。トークン課金モデルでは、ルーチンタスクのために数十万トークンを送信することは持続不可能です。Deep Insightで実証されたファイルベースの外部化戦略は、負担を高価なAPI呼び出しから安価なストレージ操作へシフトさせます。これにより、開発者は過度なコスト増なしに、より複雑で長期ホライズンのエージェントを構築できます。

最後に、このアプローチはデバッグ性とメンテナンス性を向上させます。コードと結果が一時的なチャット履歴に隠されるのではなくファイルに保存されると、開発者は成果物を直接検査できます。懸念事項の分離により、あるエージェントのエラーが別のエージェントの状態を必ずしも損なうわけではなく、部分的な障害に対してシステムがより回復力を持つようになります。

実践できること

• 専門化されたワーカーが独立したコンテキストウィンドウで異なるタスクを処理する、マルチエージェントアーキテクチャを採用してください。
• エージェントが冗長で不要なテキストを生成しないよう、システムプロンプトで厳格な出力トークン予算を実装してください。
• 個別のコード作成ツールと実行ツールを、ディスクに書き込み実行サマリーのみを返す単一のツールに置き換えてください。
• すべてのスクリプトにインポートとデータ読み込みを含めることを要求することで、自己完結型コード生成を徹底してください。
• 中間結果を下流エージェントが読める構造化ファイルに保存することで、ファイルシステムを通信バスとして活用してください。
• 複数エージェントターンにわたる定型コードの繰り返しを避けるため、共通ユーティリティモジュールを事前生成してください。