はじめに：モデルを変える前に考えること
AIエージェントを本番運用していると、ある日突然請求書を見て驚くことがあります。「プロトタイプの時はこんな金額じゃなかったのに」と。多くのチームが最初に取る選択は、より安価なモデルへの切り替えです。しかしこれは、品質低下というトレードオフを即座に招きます。
ここで押さえておくべき事実があります。モデル自体はメモリを持ちません。 毎ターン、コンテキストウィンドウが指示文・ツール説明・検索ドキュメント・会話履歴をすべて再供給する必要があります。そしてこのコンテキストは、毎ターン再課金されます。
チャットボットが一度回答して終わる構造なら、このコストは許容範囲です。しかし、単一の成果に向けて何度もターンを回すエージェントの場合、話はまったく変わります。コンテキストウィンドウは、エージェント運用コストの最大項目になることが多いのです。
本記事では、Microsoft Foundryが提唱する**コンテキストエンジニアリング（Context Engineering）**の観点から、エージェントを作り直すことなく、より賢く、より安くする方法を整理します。（根拠資料：The economics of agent optimization）
なぜコンテキストウィンドウがコストを決めるのか
コンテキストが膨らむと、2種類のコストが発生します。
1) 見えるコスト：トークン
毎ターン、同じ指示文・同じツール説明・同じ会話履歴が再送信されます。40ページのドキュメントを毎回プロンプトに含めると想像してください。モデルがそのうち1行しか使わなくても、40ページ分の料金は毎回支払われます。
2) 見えないコスト：品質
コンテキストが多いからといって、回答が良くなるわけではありません。むしろ逆です。
- 40ページの中に埋もれた正解の一行は、見つけにくくなります。
- ツール一覧が長いと、誤ったツールを選ぶ確率が上がります。
- 誤選択はリカバリーのターンを生み、そのターンがまたコストを生みます。
だからこそコンテキストはリーダーの関心事になる
多くのコスト削減はトレードオフを伴います。安いモデルは品質を削り、指示文を短くすれば回答が弱くなります。一方、不要なコンテキストの除去は、品質を落とさずコストだけを下げる、チームが賛同しやすい最適化です。
# 例：コンテキスト最適化の前後比較（擬似コード）
# ❌ Before: 毎ターン、全ドキュメント＋全ツール説明を送信
def build_prompt_naive(user_query, all_docs, all_tools, history):
return {
"documents": all_docs, # 40ページ全体
"tools": [t.description for t in all_tools], # ツール200件の説明
"history": history, # 会話履歴全体
"query": user_query,
}
# ✅ After: 必要なものだけを選別して送信
def build_prompt_engineered(user_query, knowledge_base, toolbox, memory):
# 1) 知識：セマンティック再ランキング後、上位の根拠段落のみ
passages = knowledge_base.search(user_query, top_k=5, rerank=True)
# 2) ツール：検索可能なエンドポイントのみ公開（全リストは渡さない）
tool_search_endpoint = toolbox.search_endpoint
# 3) メモリ：セッション／ユーザー／手続きメモリから必要な分だけ
relevant_memory = memory.recall(user_query, scope=["session", "user", "procedural"])
return {
"grounded_passages": passages, # 引用付きの根拠のみ
"tool_search": tool_search_endpoint,
"memory": relevant_memory,
"query": user_query,
}
ポイントは、「今回のリクエストに必要なもの」だけを入れることです。「いつか必要になるかもしれないもの」を全部詰め込まないでください。
実践4ステップ：何を入れ、何を削るか
コンテキストエンジニアリングは、4つの問いに集約されます。チームは通常この順序で進めます。
ステップ1. エージェントは何を知るべきか？（知識）
多くのチームは、ドキュメント全体をプロンプトに流し込む広い検索から始めます。作りやすい一方、運用は高コストです。
ここで必要になるのがマネージド知識レイヤーです。Foundry IQのようなレイヤーを置くと、クエリをサブクエリに分解し、複数ソースを並列検索し、セマンティック再ランキングを経て、引用付きの根拠段落のみを返します。社内評価では、BrowseComp-Plusベンチマークで根拠再現率が最大54%向上、検索トークンコストが34%削減されたとのことです。
ステップ2. エージェントは何に到達できるべきか？（ツール）
ツールを1つ追加するのはコード1行ですが、そのツールの説明全体は毎ターンのプロンプトに載ります。 エンタープライズエージェントはシステムが増えるほど、ツールが雪だるま式に増えていきます。
解決策はツールボックス＋ツール検索（Tool Search）です。モデルには全リストを渡す代わりに、「必要なものを自然言語で説明する方法」と「返ってきたものを呼び出す方法」だけを渡します。これにより、ツール一覧がどれだけ大きくなってもコストはフラットに保たれます。社内ベンチマークでは、大規模ツールライブラリで平均入力トークン消費が約97%削減されたと報告されています。
ステップ3. エージェントは仕事をどう進めるべきか？（スキル）
知識とツールは「見つけられるもの」と「できること」を扱います。しかし**「我が社はこの仕事をこう進める」**という部分は扱いません。エスカレーション経路やコードレビューのチェックリストがそれに当たります。
これをスキル（Skill）として中央に配置します。エージェントは最初、スキルの名前と短い説明のみを参照します。実際に関連がある場合にのみ、完全な指示をロードします。手順が変わったら新バージョンを公開しデフォルトに設定すれば、すべてのエージェントがコード変更なしに最新手順に従えます。
ステップ4. エージェントは何を覚えるべきか？（メモリ）
会話全体を毎回再送信するのは、コストでありコンテキストの浪費です。メモリは3種類に分けて扱います。
- セッションメモリ： 現在の会話用
- ユーザーメモリ： セッションを跨いで保持される選好・事実
- 手続きメモリ： 学習されたワークフローとタスク実行パターン
手続きメモリを有効化した場合、STATE-BenchおよびTau-Benchで約5%の性能向上が確認されたとのことです。
⚠️ 注意事項：この技術の限界
- 知識レイヤーはソースの鮮度に依存します。 インデクサーのスケジュールが遅れると、エージェントは古い回答を自信を持って返します。
- ツール検索は検索品質に性能が左右されます。 検索が誤ったツールを返せば、誤ったツールを素早く呼び出すだけです。
- メモリはプライバシーリスクを伴います。 ユーザー単位の分離、保持期間、TTLポリシーを設計段階で必ず定めてください。
- スキルの中央集約は、組織プロセスが成熟している前提で意味を持ちます。 手順自体が頻繁に変わる組織では、スキルは新たな管理負債になります。
まとめ：エージェントは「使うほど良くなる」システムであるべき
コンテキストエンジニアリングの目標は、単にプロンプトサイズを削ることではありません。使うほど良くなるエージェントを作ることです。
- 知識ベースはソースシステムが変われば更新されます。
- スキルはポリシーが進化すれば共に進化します。
- メモリはユーザーと成功したワークフローについて重要なものだけを蓄積します。
- ツール検索は人々が実際に使う機能に適応します。
次のステップ学習の方向性
- まず計測してください。 毎ターンのコンテキストに何が入っているかをログに取ります。多くの場合、ここで半分が解決します。
- モデル交換より入力改善を先に試してください。概ね効果が大きく、巻き戻しも容易です。
- 権限境界をデータ検索地点に置いてください。 エージェントがアクセス権限を「継承する」構造が安全です。
あわせて読みたい記事
- NVIDIA NVbandwidth完全ガイド：GPUメモリ帯域幅をこのツールひとつで測定・最適化する — エージェントを動かすインフラレベルの最適化に興味があれば、まずはこちらから。
- AIエンジニア、6ヶ月でなれる？現実的なキャリア転換ロードマップ — コンテキストエンジニアリングを自身のキャリアに取り込みたい方は、現実的な参入経路をまとめた記事です。