Microsoft Foundry、企業向けAIエージェントの最適化戦略を公開

「エージェント最適化の経済学」シリーズは全 4 部構成で、Microsoft Foundry で AI を管理投資システムとして運用し、エージェントのコストを最適化するための戦略、機能、実証事例を紹介します。第 1 回ではシステムの根幹となる 3 つの意思決定について解説しました。第 2 回ではランタイム時のリクエスト処理を取り上げました。今回の第 3 回は、その次のステップとして「学習を通じてエージェントを徐々に低コスト化する方法」に焦点を当てます。

すべてのエージェントには、各ターンでモデルが何を認識するかを決定するメカニズムが存在します。多くの実運用システムでは、この設定はプロトタイプ段階で行われ、その後見直されることはありませんでした。しかし、これが運用コストの大部分を占め、期待通りの回答が得られない原因となっているケースも少なくありません。

実は、ここがエージェント自身が改善できる部分でもあります。モデル自体の能力は選定時と変わらず、指示内容も誰かが書き換えない限り変化しません。ただし、エージェントが「知っていること」「アクセスできる情報」「記憶している内容」は、実行するたびに成長します。これが、コストを下げつつパフォーマンスを向上させる鍵となります。このプロセスを管理することを「コンテキストエンジニアリング」と呼びます。

なぜコンテキストウィンドウがコストを決めるのか

モデル自体には記憶機能がありません。各ターンでは、コンテキストウィンドウを通じて利用可能なすべての情報——指示、使用可能なツール、取得したドキュメント、会話履歴など——を参照します。ターンが終了するとこのコンテキストは消去され、次のターンでは再度送信する必要があります。

1 問に答えるチャットボットであれば、このコストは管理可能な範囲です。しかし、単一の成果物に向けて複数のやり取りを繰り返すエージェントにとっては、これが最大の経費となることが少なくありません。コンテキストウィンドウは各ターンで課金されるため、不要なコンテンツが含まれると、その分だけ重複して請求されてしまいます。

見落としがちなコストとして「品質」があります。コンテキストを増やせば必ずしも回答が良くなるわけではありません。40 ページの文書に埋もれた関連事実を見つけるのは難しく、ツールリストが長すぎると誤った選択を犯す確率が高まります。一度ミスをすると、それを修正するためにさらに多くのターンが必要になり、結果としてコストが増大します。

このため、コンテキストは経営層の注目を集めるべき重要な要素です。コスト削減には往々にしてトレードオフが伴います。安価なモデルを使えば品質が低下する恐れがあり、指示を短くすれば回答の質が弱まる可能性があります。一方、不要なコンテキストを削ぐことは、品質を落とさずにコストを下げられるため、チームが推進しやすい最適化手法と言えます。

実践における「コンテキストエンジニアリング」とは何か

これがコンテキストエンジニアリングの本質です。各ターンで何を入力すべきかを判断し、エージェントに「将来必要になるかもしれないすべて」ではなく、「現在の要求に必要なものだけ」を提供します。一度きりの設計判断として捉えることもできますが、継続的な実践を通じてこそ真価を発揮します。なぜなら、各やり取りの結果から実際に何が使われたかが明らかになり、それに基づいて改善できるからです。

この作業を担うには 4 つの問いがあり、チームは通常以下の順序でこれらに取り組むのが一般的です。

「エージェントは何を知っているべきか？」

多くのチームがまず行うのは、文書全体をプロンプトに挿入する広範な検索アプローチです。これは実装は容易ですが、実行コストが高くつき、モデルがあらゆる情報の中からたった一つの関連詳細を見つけ出すことを強いることになります。

Foundry IQ は、管理された知識レイヤーによってその課題を解決します。この知識ベースは、Work IQ、Fabric IQ、Web IQ、Microsoft Azure Blob Storage、SharePoint、OneLake、Azure SQL といった多様なソースに接続されています。エージェントがクエリを送信すると、Foundry IQ はそれをサブクエリに分解し、接続された各ソースを並列検索します。その後、結果を意味的に再ランク付けして、出典を示す根拠のある文章を返します。これにより、モデルのコンテキストに入る情報は最も関連性の高い証拠に絞り込まれつつ、情報の出所を追跡可能に保たれます。

この知識レイヤーが複数のエージェント間で再利用可能で、かつ大規模な運用でも管理しやすいのは、2 つの特徴によるものです。まず、単一の知識ベースを複数のエージェントが共有できます。インデックス化されたソースは設定されたスケジュールに従って増分更新され、リモートソースは必要に応じてクエリされます。クエリ実行時には、Foundry IQ は呼び出し元の Microsoft Entra 身份（ID）の下で動作し、対応するソースのアクセス制御リストを同期します。さらに、Microsoft Purview の機密ラベルも尊重するため、エージェントが取得できるのは呼び出し元が権限を持つコンテンツのみとなります。

内部評価では、Foundry IQ の知識ベースを使用することで、BrowseComp-Plus ベンチマークにおける証拠の想起率が最大 54% 向上し、検索にかかるトークンコストは 34% 削減されました。これらの成果は、エージェントによる検索、意味的な再ランク付け、回答合成の改善、そしてより効率的なトークンの利用によって実現されたものです。

では、エージェントがアクセスできる範囲をどう定めるべきでしょうか？

ツールオーバーヘッドは見過ごされがちです。追加にはコードが一行増えるだけですが、そのツールの完全な説明はプロンプト全体を占領します。エージェントに接続されたすべてのツールは、必要かどうかに関わらず、各ターンでモデルに送信されます。エンタープライズ向けエージェントでは、より多くのシステムと連携するにつれて、すぐに多数のツールを追加してしまいます。

Foundry のツールボックスは、Web 検索やコードインタプリタ、ファイル検索といった組み込みツール用の管理された Model Context Protocol (MCP) エンドポイントを一つ提供します。これにはカスタム MCP サーバーや OpenAPI 3.0/3.1 API、A2A エージェントも含まれます。Foundry では認証、アクセスポリシー、ツールのバージョンを一元管理するため、各エージェントごとに個別の統合設定を行う必要がありません。新しいツールボックスのバージョンがテストされ、本番環境に公開されると、接続されているエージェントはコード変更や再デプロイなしでその機能を利用できます。

ツールボックスはツールを整理します。ツール検索機能が、すべてのツールの利用料を支払う必要を防ぐ鍵です。モデルには一覧全体ではなく、必要なものを自然言語で記述する方法と、結果として返ってきたツールを呼び出す方法の二つが提供されます。これにより、ツールリストのコストは、ツールボックスがどれだけ大きくなっても一定に保たれます。公開されたオープンソースのツール検索データセットとの内部ベンチマークでは、Foundry のツールボックスは大規模なツールライブラリにおいて平均的な入力トークン消費量を約 97% 削減し、エージェントを構築する顧客の推論コストを直接的に下げる結果となりました。1

Foundry は、各ツールボックスでどのツールが最も頻繁に使用されているかを把握し、それらをすぐにアクセスできる場所に配置します。これにより、エージェントの稼働時間が長くなるほど、一般的な処理パスはより高速かつ低コストになります。精度も同時に向上します。短く適切なリストは、誤った呼び出しを減らし、回復に要するターン数を削減するためです。

では、エージェントはどのように作業を行うべきでしょうか？

知識とツールは、エージェントが「何を見つけ、何を実行できるか」を定義します。しかし、これらは「自社の業務をどのように遂行すべきか」という指針まではカバーしていません。例えば、サポート担当者がたどるエスカレーションパスや、コードレビューで適用されるチェックリストなどが該当します。こうした指針は通常、エージェントの指示（instructions）に記述されます。その結果、関連性のない場合でも、同じ手順が複数のエージェント間でコピーされ、すべてのリクエストに含まれてしまうことがあります。

スキル（Skill）とは、そうした指針を名前付きで再利用可能な手順に変換するものです。スキルは Foundry 内で中央集約的に管理され、ツールボックスを通じてエージェントに提供されます。各エージェントに手順のコピーを埋め込むのではなく、ツールボックスが中央管理されたスキルを参照します。組織が手順を更新した場合、新しいバージョンを公開してデフォルトとして設定できます。そのスキルを利用するすべてのエージェントは、コードの変更や再デプロイなしで更新された手順に従うことができます。

コンテキストの使用量を最小限に抑えるため、エージェントは最初に見るのは各スキルの名前と短い説明だけです。実際の詳細な指示は、そのスキルが関連する場合のみロードされます。これにより、膨大な数の詳細な手順ライブラリを提供しつつ、すべての対話に不要なコンテンツを追加することなく運用することが可能になります。

エージェントは何を記憶すべきか

エージェントには継続性が必要ですが、すべての対話の詳細を保持する必要はありません。会話全体を毎回モデルに送ると、コストが増大し、コンテキストリソースを浪費することになります。実際には、必要な情報がごく一部だけであるケースも多々あります。

Foundry Agent Service のメモリ機能は、会話全体を再生成することなく、重要な文脈をエージェントが保持できるように支援します。この機能は以下の 3 つのタイプのメモリをサポートしています。

• セッションメモリ：現在の対話に限定された記憶
• ユーザーメモリ：セッションを超えて維持される好みや事実の記憶
• 手続き型メモリ：学習したワークフローやタスク実行パターンの記憶

これにより、顧客が前回のやり取りから続きを再開できるようになる一方、エージェントは毎回指示を受けなくても、確立されたプロセスを一貫して実行できます。

これらの機能を活用することで、エージェントは顧客との対話を継続し、将来の応答をパーソナライズし、反復タスクの完了精度を向上させることが可能になります。手続き型メモリは、組織が管理するスキルと補完関係にあります。スキルは組織が認めた手順を定義するものですが、手続き型メモリはエージェント自身がタスク実行から学習することを可能にします。Microsoft の評価では、手続き型メモリを有効化することで、STATE-Bench と Tau-Bench で約 5% の性能向上が確認されました。また、ユーザーレベルでの隔離、保持期間の設定、有効期限ポリシー（TTL）の適用などを通じて、記憶される情報の範囲と期限を組織が制御することも可能です。

なぜコンテキストエンジニアリングがシステム化されるのか

知識の検索、ツールの連携、手順ガイダンス、そしてメモリ機能。これらを組み込むこと自体はどのチームでも可能です。真の課題は、これらを一貫した権限体系の下で統合し、組織の変化に合わせて常に最新の状態を維持することです。

Foundry はこれらの要素を単一のシステムへと統合します。知識、ツール、スキル、メモリを個別の製品として管理するのではなく、共有インフラ上で一元管理できます。また、データ取得時に権限が適用されるため、エージェントは企業コンテンツに既に設定されているアクセス制御をそのまま継承します。

Foundry IQ はこのモデルを企業の知識、ビジネスデータ、組織コンテキスト全体へと拡張し、Microsoft Agent Framework や LangGraph、GitHub Copilot SDK、Claude Agent SDK といった主要フレームワークとの互換性も維持しています。

その結果、エージェントの再構築なしに文脈（コンテキスト）の質を向上させることが可能になります。ソースシステムが変更されれば知識ベースは自動的に更新され、ポリシーが変わればスキルも進化します。メモリにはユーザーや成功したワークフローに関する重要な情報が蓄積されます。ツール検索機能は、実際に利用されている機能を基に適応して変化します。

Foundry Agent Service のエージェント最適化機能がこのループを完結させます。エージェントの行動を分析し、改善された指示、スキル、ツールの説明、モデル設定を自動生成するのです。

コンテキストエンジニアリングの大きな目標は、単にプロンプトサイズを縮小したり検索コストを下げたりすることだけではありません。むしろ、利用するたびに改善されるエージェントを作ることです。知識源が向上し、発見できるツールが増え、従う手順が洗練され、保持する記憶が蓄積されていけば、ゼロからやり直すことなく、エージェントはより能力が高く、より効率的になります。

まずは今日のエージェント構築において、各ターンでコンテキストウィンドウに何が入っているかを点検することから始めましょう。取得されるドキュメント、公開されるツール、繰り返し指示される内容、そして引き継がれる会話履歴を確認してください。多くの場合、モデルを変更するよりも、これらの入力自体を改善する方が、コストと品質に対してより大きな影響を与えます。

Foundry IQ を用いて、企業データにエージェントを根付かせましょう：Foundry IQ のナレッジベースをエージェントに接続します。

ツールは 1 つのエンドポイントに集約し、ツール検索機能を有効化しましょう：ツールボックスでツール検索をオンにします。

セッション間でもコンテキストを引き継げるようメモリを追加しましょう：Foundry Agent Service でメモリを作成して活用します。

Microsoft Foundry で構築を始めましょう。

Microsoft Foundry

大規模な AI アプリおよびエージェントの構築、根付かせ、ガバナンスを行うためのエンタープライズ AI プラットフォーム

機能を確認する

「エージェント最適化の経済学」シリーズで他の記事をお見逃しではありませんか？

AI コスト管理：AI パイロットから測定可能な ROI へ

AI コスト最適化：AI 支出を削減する方法

1 コマンドライン、ツール検索：適切なタイミングで最適なツールを見つける、2026 年 7 月 29 日。

この記事は、Microsoft Azure ブログに投稿された「エージェント最適化の経済学：エンタープライズ AI エージェントのためのコンテキストエンジニアリング」です。