この記事は コンテキストエンジニアリング を、定量的に捉えた問題への対応として提示する。チャットアプリケーションからエージェントへ移行すると、コンテキストに保持すべきものの内容だけでなく規模が変わる、というのがその問題である。記事の例では、エージェントがタスクを 10 のサブタスクに分解し、各サブタスクで 2 回のツール呼び出しが必要になる。記事はこれを、最初の分解 1 件とサブタスクごとの 4 件を合わせて 41 件の新たなコンテキストレコードと数える。マルチエージェントシステムでは各エージェントがその負荷全体を抱えるため、総量はさらに何倍にもなる。
そこから記事はコンテキストエンジニアリングをプロンプトエンジニアリングとの対比で定義しており、この対比こそ記事が最も明確に述べている部分である。従来のプロンプトエンジニアリングは静的な文字列を扱い、ライブデータ、過去の状態、ツールインターフェースといった動的で複数ソースにまたがる情報を扱えないため、単一の出力に向けてコンテキストの言い回しを最適化する。これに対してコンテキストエンジニアリングは、コンテキストを動的で構造化された構成要素の集合として扱い、明示的なメモリとモジュール的な組み合わせによって、取得、フィルタリング、保存、検索、最終的な組み立てという情報のライフサイクル全体を通じて管理する。
後半は一般論ではなくベンダーとしての説明である。記事は AWS のスタックを 3 層で示し、各サービスがコンテキストエンジニアリングの中核要素に対応すると主張する。基盤モデル層（Amazon Bedrock。Converse API の標準化されたコンテキスト構造、Prompt Cache、ネイティブなツール呼び出しのため）、エージェントフレームワーク層（Strands Agents。会話管理、メモリ、ツール統合のため）、そしてエージェントランタイム層（Amazon Bedrock AgentCore。デプロイ、Memory、Gateway、Identity、Observability のため）である。各層は Python の実例とともに示される。
要点
- 記事が出発点とする定義は、著者ら自身のものとしてではなく、近年業界が収束してきた理解として紹介されている。それによれば、コンテキストエンジニアリングとは、コンテキストウィンドウに入るものを動的に管理することでモデルの推論と意思決定を最適化する技術的枠組みであり、コストを抑えつつウィンドウを的確に満たすことを目指し、プロンプトエンジニアリングを拡張するのではなくその限界に対処するものである。
- コンテキストエンジニアリングを、動的な反復ループを形成する 3 つの中核的な構成要素、すなわちコンテキストの取得と生成、コンテキストの処理、コンテキストの管理に分解する。このうちコンテキストの管理は、フロー全体を通じて情報を整理、圧縮、スケジューリングするハブとして機能する。
- コンテキストが何から構成されるかについては、入力（システム指示、外部知識の検索、ツール定義、グローバルな状態、ユーザー入力）、メモリ（長期と短期）、出力（ツールの実行結果とモデルが生成した構造化コンテンツ）であると説明する。
- 動機として 4 つの課題を挙げる。コンテキストウィンドウの物理的な上限、トークン数に伴うコストの増加、訪問をまたいでユーザーの好みを永続化する必要性、そして速度と精度の両方における目に見えない劣化である。最後の点については、長すぎるコンテキストが重要な情報を見失う仕組みとして「Lost in the Middle」を引用している。
- この作業を担う構成要素として「コンテキストオプティマイザー」を挙げ、その位置づけについては慎重である。現時点ではこれは主にエンジニアリング上の実装であり、将来ありうる発展形はモデル駆動のオプティマイザーで、現在のユーザー入力、タスクの目標、モデルの状態から、圧縮するかどうか、どの圧縮戦略を使うか、何を破棄するか、何をメモリとして保存するか、いつメモリを補充するかを判断するものになる、と述べる。
- AgentCore Gateway については、注目すべき仕組みはセマンティックなツール検索であると論じる。すべてのツールをコンテキストに読み込むのではなく、最も関連性の高いツール定義を動的に取得するもので、記事によれば、多数のツールが存在する状況でトークン使用量を削減し、選択の精度を向上させる。
- 記事は AWS 層の説明にコストの数値を添えているが、それらは測定されたものではなく主張されたものである。キャッシュされたトークンは標準の入力トークンより 90% 安く課金されること、エージェントのタスクでは入力と出力の比率が 100:1 に達しうること、そして Claude Code のようなコードアシスタントが安定したエージェントワークフローで動作する場合、キャッシュヒット率が 90% を超え、推論コスト全体が 80% 削減されることである。いずれについても方法論やベンチマークの条件は示されていない。
背景
この記事は Agentic AI インフラストラクチャに関する連番のシリーズの 1 回分であり、以前の回へのリンクを含むため、完全に単独で成り立つものではなく、シリーズの前後の文脈を前提としている。一般論の部分は、基本的な RAG からマルチエージェントやツール統合型の推論システムへの発展の道筋について、コンテキストエンジニアリングに関する外部のサーベイを明示的に参照している。また、AWS 自身のサービスに移る前に分野を概観するなかで、Mem0、Letta、MemOS、SCM、FlashRAG、ComposeRAG、Self-RAG、PlanRAG、GraphRAG、HippoRAG、GNN-RAG、SagaLLM といった幅広いサードパーティのフレームワークを挙げている。
著者らが述べる立場は、コンテキストエンジニアリングは単なる技術的最適化ではなく、持続可能でスケーラブルな AI アプリケーションを構築するための基礎的な方法論であり、AWS の貢献はその理論をデプロイ可能なスタックに変えることにある、というものである。この位置づけは記事自身のものであり、ベンダーがベンダーについて書いたものである。