9月3日、Microsoftが「AI agent optimization: How context engineering lowers AI costs」と題した記事を公開した。エンタープライズAIエージェントの運用コスト削減において、モデルの変更よりも先に試すべき手法として「コンテキストエンジニアリング」を取り上げており、その効果は社内ベンチマークでツール検索トークン消費量の約97%削減という数字にも表れている。
なぜコンテキストウィンドウがコストを左右するのか
AIエージェントはモデル自体にメモリを持たない。各ターン（やり取り）ごとに、指示・ツール一覧・取得したドキュメント・会話履歴といったすべての情報をコンテキストウィンドウに詰め込んで送信する。チャットボットなら1回で済むが、複数ターンにわたって作業するエージェントでは、この繰り返しコストが最大の出費になる。
しかも「コンテキストを長くすれば品質が上がる」わけではない。40ページの中に埋もれた一文はモデルが活用しにくく、ツール一覧が長ければ間違ったツールを選ぶ確率が上がる。誤った選択はリカバリーのための余分なターンを生み、さらなるコストを生む。
ここで登場する概念がコンテキストエンジニアリングだ。各ターンに「必要なものだけ」を渡す設計・運用のプロセスであり、プロトタイプ時に固定されたまま見直されていないプロダクションシステムにとって、モデル変更よりも大きな改善余地がある。
4つの問いで整理するコンテキストエンジニアリング
1. エージェントは何を「知る」べきか？ — Foundry IQ
多くのチームは検索結果のドキュメント全体をプロンプトに挿入してしまう。構築は簡単だが、モデルが必要な情報を1万字の中から探す羽目になる。
Microsoftが提供するFoundry IQは、クエリをサブクエリに分解して複数のソース（SharePoint、OneLake、Azure SQL、Blob Storageなど）を並列検索し、セマンティックにリランキングして関連性の高い箇所だけをコンテキストに返す仕組みだ。
社内評価によれば、BrowseComp-Plusベンチマーク（Microsoft社内の情報検索品質評価指標）でリコール率が最大54%向上し、取得トークンコストが34%削減された。また、Microsoft Entraの呼び出し元IDで動作し、アクセス制御リストやMicrosoft Purviewの機密ラベルを尊重するため、権限のないコンテンツは取得されない。
2. どのツールを「使える」状態にするべきか？ — Toolboxes
ツールを1つ追加するのはコード1行だが、そのツール説明は毎ターン、必要かどうかにかかわらずプロンプトに含まれる。エンタープライズエージェントが接続するシステムが増えるほど、このオーバーヘッドは静かに膨らんでいく。
Foundry Toolboxesは、Webサーチ・コードインタープリター・カスタムMCPサーバー・OpenAPI 3.0/3.1のAPIなどを1つのMCP（Model Context Protocol：Anthropicが提案したAIとツール間の標準通信仕様）エンドポイントで管理する。
さらに重要なのがツール検索機能だ。モデルに全ツール一覧を渡すのではなく、「何が必要か」を自然言語で説明させ、マッチしたツールだけを渡す。公開オープンソースのツール検索データセットを使った社内ベンチマークでは、大規模ツールライブラリに対して平均入力トークン消費量が約97%削減された。ツールライブラリが大きくなっても、コンテキストサイズは一定に保たれる。
3. どうやって「作業手順」を伝えるか？ — Skills
サポートエージェントのエスカレーション手順、コードレビューのチェックリスト——こうした手順書は通常、エージェントの指示文に直接書き込まれ、複数のエージェントに重複してコピーされがちだ。
Skillsはその手順を名前付きの再利用可能なプロシージャとして中央管理する。エージェントは最初、スキルの名前と短い説明だけを受け取り、関連する場合にのみフルの手順をロードする。手順を更新しても、コード変更や再デプロイ不要で全エージェントに即時反映される。
4. エージェントは何を「覚えて」おくべきか？ — Memory
毎回の会話履歴全体をモデルに送り続けるのは、コストと品質の両面で非効率だ。Foundry Agent ServiceのMemory機能は3種類のメモリを提供する。
- セッションメモリ：現在の会話内の文脈
- ユーザーメモリ：セッションをまたいで保持するユーザーの好みや事実
- プロシージャルメモリ：学習済みのワークフローとタスク実行パターン
特にプロシージャルメモリが興味深い。Microsoftの評価では、プロシージャルメモリを有効化することでSTATE-BenchおよびTau-Benchで約5%の改善が得られた。保持期間はTTL（Time-to-Live）ポリシーで制御できる。
コンテキスト最適化はシステムとして機能する
Foundryはこれらを個別ツールではなく、統合されたシステムとして提供する。ナレッジベースはソースシステムの変更に合わせてリフレッシュされ、スキルはポリシー変更に追従し、メモリは有用な情報を蓄積していく。Agent optimizerがエージェントの動作を分析し、指示文・スキル・ツール説明・モデル設定の改善案を自動生成することで、継続的な最適化ループを形成する。
LangGraph、GitHub Copilot SDK、Claude Agent SDKなど主要なフレームワークとも互換性がある。
まず着手すべきは、現在のエージェントが毎ターン何をコンテキストに渡しているかの確認である。取得しているドキュメント、公開しているツール、繰り返し送っている指示文、引き継いでいる会話履歴——それらの見直しが、モデルを変えるよりも大きなコスト・品質改善につながる場合が多い。
詳細はAI agent optimization: How context engineering lowers AI costsを参照していただきたい。
