なぜ今「コンテキストエンジニアリング」なのか

AIエージェントを運用していると、誰もが同じ壁にぶつかります。「安いモデルに変えると回答品質が落ちる。プロンプトを短くすると回答が薄くなる」。このジレンマから抜け出すには、コスト構造そのものを分解する必要があります。

エージェントのコストは大きく2つに分かれます。

  • モデル自体のコスト: 選択したモデルの単価。変えない限り固定です。
  • コンテキストのコスト: 毎ターン再送される入力トークン。ここが運用コストの大半を占めます。

モデルは学習が終わった時点で能力が固定されます。指示文(instruction)も誰かが書き直すまでそのままです。しかしエージェントが知り、アクセスし、記憶するものは実行するほど増えていきます。これを適切に設計するのがコンテキストエンジニアリングであり、結果として品質を維持しながらコストを下げる唯一のレバーになります。

根拠資料: The Economics of Agent Optimization: Context engineering for enterprise AI agents

モデルには記憶がありません

モデルは自分では何も記憶しません。毎ターン、コンテキストウィンドウが以下を運んできます。

  1. システム指示文
  2. 利用可能なツールの説明
  3. 検索されたドキュメント
  4. 会話履歴

ターンが終わればこのコンテキストは消え、次のターンでまた全部送り直されます。チャットボットの単発回答では目立ちませんが、複数ターンを回して1つの成果物を作るエージェントでは、これが最大の支出項目になります。コンテキストは毎ターン課金されるため、不要な内容は繰り返し請求されます。

さらに見えにくいのが品質コストです。コンテキストが多いからといって回答が良くなるわけではありません。40ページに埋もれた正解はむしろ見つけにくく、ツール一覧が長いと誤選択が増えます。誤ると復旧にターンが増え、ターンが増えればコストも増えます。

AI agent context window diagram showing instructions, tools and memory tokens flowing per turn System Abstract Visual

実践4ステップ: 何をコンテキストに入れるか

コンテキストエンジニアリングは結局のところ、**「今回のリクエストに必要なものだけを入れる」**という意思決定です。一度決めて終わりではなく、各ターンで露呈する利用パターンを見ながら継続的に磨き続ける作業です。実務では以下の4つの問いをこの順番で扱います。

1) エージェントが「知るべき」こと — 知識検索

多くのチームは最初、ドキュメント全体をプロンプトに流し込む方式で始めます。作りは簡単ですが、運用すると高コストで、モデルはその中から一行の正解を探さなければなりません。

Microsoft FoundryのFoundry IQは、この部分をマネージドな知識レイヤーで置き換えます。エージェントがクエリを投げると:

[Agent Query]
   ↓
[Foundry IQ]
   ├─ サブクエリに分解
   ├─ 接続ソースを並列検索 (Work IQ, Fabric IQ, Web IQ,
   │   Azure Blob, SharePoint, OneLake, Azure SQL)
   ├─ セマンティック再ランク
   └─ 引用付きグラウンディングパッセージを返却
   ↓
[Model Context] ← 最も関連性の高い根拠のみ注入

重要なのは再利用性とガバナンスです。1つの知識ベースを複数エージェントで共有でき、インデクサースケジュールで増分更新され、クエリ時に呼び出し元のEntra ID・ACL・Purview機密度ラベルをそのまま尊重します。つまり、呼び出し元がアクセス権を持つコンテンツのみが検索されます。

社内評価では、Foundry IQの知識ベースはBrowseComp-Plus基準で根拠再現率を最大54%向上させ、検索トークンコストを34%削減しました。

2) エージェントが「到達できるべき」こと — ツールボックス

ツールのオーバーヘッドは見落としがちです。ツール追加はコード1行ですが、そのツールの完全な説明は毎ターンプロンプトに送られます。使わないターンでもです。エンタープライズエージェントは接続システムが増えるほどツールが増えていきます。

FoundryのToolboxesは、Web検索・コードインタプリタ・ファイル検索などの組み込みツールと、カスタムMCPサーバー、OpenAPI 3.0/3.1、A2Aエージェントを1つのMCPエンドポイントにまとめます。認証・アクセスポリシー・バージョン管理を一元化するため、新バージョンを昇格しても接続済みエージェントはコード変更なしで利用できます。

本当の節約はtool searchから生まれます。モデルはツール全一覧の代わりに2つだけ受け取ります。

  • 自然言語で「必要なものを説明する方法」
  • 「返ってきたものを呼び出す方法」

これにより、ツールボックスがどれだけ大きくなってもツール一覧のコストは一定に保たれます。公開オープンソースのツール検索データセットに対する社内ベンチマークでは、大規模ツールライブラリ基準で平均入力トークン消費が約97%削減されました。推論コストがそのまま下がるということです。

3) エージェントが「働き方」 — スキル

知識とツールは「見つけられるもの」と「できること」をカバーします。しかし**「自社はこの業務をこう進める」**という部分はカバーしません。例えば:

  • CSエージェントのエスカレーションパス
  • コードレビューのチェックリスト

こうした手順は通常、指示文に入りますが、複数のエージェントにコピーされ、毎リクエストに送られます。無関係なときでもです。

Skillはこのガイダンスを、名前付きの再利用可能な手順に変えます。Foundryに中央保存され、ツールボックス経由でエージェントに公開されます。手順が改善されたら新バージョンをデフォルトに昇格するだけ。すべてのエージェントがコード変更なしに更新された手順に従います。

コンテキスト節約の鍵は遅延ロードです。エージェントは最初、各スキルの名前と短い説明のみを見ます。関連があるときだけ完全な指示をロードします。おかげで詳細な手順ライブラリを大きくしても、毎回のやり取りに不要な内容が混ざりません。

4) エージェントが「記憶すべき」こと — メモリ

エージェントには継続性が必要ですが、すべての会話のすべての詳細を持ち歩く必要はありません。会話全体を毎回送り直すのはコストもコンテキストも無駄です。

Foundry Agent ServiceのMemoryは3種類をサポートします。

  • Session memory: 現在の会話
  • User memory: セッションを跨いで保持される好み・事実
  • Procedural memory: 学習されたワークフロー・タスク実行パターン

戻ってきた顧客が前回の続きから再開でき、エージェントは毎回再指示なしに検証済みプロセスを踏襲できます。Microsoftの評価では、procedural memoryを有効にするとSTATE-BenchとTau-Benchで約5%向上しました。ユーザー単位の分離、保持設定、TTLポリシーで保存・失効も制御できます。

Enterprise AI agent architecture with knowledge base, toolboxes and memory layers on Microsoft Foundry Coding Session Visual

注意点: コンテキストエンジニアリングは万能ではありません

ここまで読んで「とりあえず導入すればいい」と思ったなら、少し立ち止まるべきです。実務でよく踏む地雷を整理します。

1) マネージドレイヤーへのロックインリスク

Foundry IQ、Toolboxes、Memoryは強力ですが、Microsoftエコシステムに深く結合します。Entra ID、Purview、Fabric IQなど社内インフラが既にAzure中心なら相乗効果は大きいですが、マルチクラウドやオンプレミス比率が高い場合は、統合コストがむしろ増える可能性があります。LangGraph、GitHub Copilot SDK、Claude Agent SDKと互換とされていますが、「互換」と「同一水準のガバナンス」は別の話です。

2) 再現率54%はワークロード依存

54%向上、34%削減、97%トークン削減といった数値は、特定ベンチマーク(BrowseComp-Plus、公開ツール検索データセット)での結果です。社内ドキュメントが短く定型化されている、あるいはツールが5個未満のチームでは削減幅ははるかに小さくなる可能性があります。導入前に自社ワークロードでパイロットを回して実測してください。

3) Procedural memoryの5%は「平均」です

STATE-Bench/Tau-Benchでの5%は特定タスクファミリでの数値です。反復性が低い創造的タスクでは、誤った手順を学習して性能がむしろ落ちるリスクがあります。TTLとユーザー分離を積極的に設定してください。

4) 「遅延ロード」は遅延を生む

Skillとtool searchはコンテキストを減らす代わりにターンを1つ余分に使います。短い相互作用が多く遅延に敏感なUX(例: リアルタイムチャット)では、体感品質がむしろ落ちることがあります。逆にバッチ的・非同期エージェントではほぼタダの利益です。

次の学習ステップ

この記事を読み終えたら、以下の順で試すことをお勧めします。

  1. Foundry IQの知識ベースを1つ接続 — 既存RAGパイプラインとトークン消費をA/B比較
  2. Tool searchを有効化してツール一覧トークンを測定 — ツール10個以上のエージェントで効果大
  3. Skillを1つ作成して中央配布 — コードレビューチェックリストのような反復指示から
  4. Memory TTLポリシーを設計 — 個人情報・規制の観点から、何をどれだけ保持するか先に決定

エージェントオプティマイザ(Agent optimizer)まで繋げると、指示文・スキル・ツール説明を自動改善するループが完成します。ただしその前に、上記4ステップを手動で一度回してみるのが勘所を掴む近道です。

Cloud cost dashboard comparing context engineering token savings for enterprise AI agents Technical Structure Concept

まとめ: モデルを変える前にコンテキストを見直す

要点はシンプルです。

  • エージェント運用コストの大半は毎ターン再送されるコンテキストから発生します。
  • コンテキストを削るのは、品質を落とさずにコストを下げられる稀な最適化です。
  • 4つの軸 — 知識(Foundry IQ) / ツール(Toolboxes) / 手順(Skills) / 記憶(Memory) — を順に磨けば、エージェントは使うほど良くなります。

最も早い出発点はこれです。**「今、毎ターンのコンテキストに何が入っているか」**を一度列挙してみてください。検索されるドキュメント、露出するツール、繰り返される指示文、引き継がれる会話履歴。多くのチームで、モデルを変えるよりもこのリストを整える方がコストと品質に大きなインパクトを与えます。

あわせて読みたい

本コンテンツは、信頼性の高い情報源をもとにAIツールを活用して作成され、編集者によるレビューを経て公開されています。専門家によるアドバイスの代替となるものではありません。