ai-docs

Manage tool context

Properties1
tagstools, context, mcp, prompt-caching, agents

5 min read

一行要約

ツール由来の context 圧迫は発生源が4つあり、それぞれに別の対処法が対応する。まず「自分のトークンがどこへ消えているか」を特定してから手段を選ぶ。

要点

ツール定義と蓄積した tool_result ブロックが context window を食う。多数のツールや多数のターンを持つ長時間エージェントは、タスクが終わる前に context を使い果たしうる。パイプラインの異なる地点に効く4つのアプローチがある。

4つのアプローチの対応表

アプローチ何を減らすかいつ合うか
Tool search事前ロードされるツール定義20個以上の大きなツール群で、毎ターン全部は必要ないとき
Programmatic tool callingtool_result の往復一連のツール呼び出しが1つのスクリプトとして実行できるとき
Prompt caching繰り返されるツール定義のトークン単価多数のリクエストにまたがってツール群が安定しているとき
Context editing履歴に残る古い tool_result ブロック長い会話で、初期の結果がもう関係ないとき

それぞれの仕組み

Tool search — Claude が要求するまでツール定義を context の外に置く。50個のスキーマを先に送る代わりに、tool_search ツール1つを送って残りは必要時に発見させる。わずかなレイテンシ（ツールを引くための1ターン追加）と引き換えに、ベースラインの context 消費を大きく減らす。

Programmatic tool calling — 一連のツール呼び出しを、Claude が書き Anthropic のコード実行サンドボックスが走らせる1つのコードブロックに畳む。tool_use / tool_result の5往復ではなく、5関数を呼ぶスクリプトを1つ出す。中間結果が会話履歴に一切入らない。

Prompt caching — context 内のトークン数は減らないが、2回目以降の支払いを減らす。ツール定義が安定しているなら一度キャッシュして数千リクエストで使い回す。ツール群が大きいが固定のときの正解。

Context editing — 役目を終えた古い tool_result ブロックを履歴から取り除く。会話を再開せずに刈り込める。

組み合わせと導入順

These approaches compose. Each solves a different part of the problem, so there’s no conflict in using them together. これらの手法は組み合わせられる。それぞれが問題の異なる部分を解くので、併用しても衝突しない。

高トラフィックのエージェントでの妥当な出発点（この順番が推奨）:

  1. 初日から prompt caching をツール定義に有効化する。 cache write は base input 価格に対して 25% の割増だが、キャッシュにヒットする2回目のリクエストで元が取れる
  2. ツール群がおよそ 20個を超えたら、あるいはベースラインの context 消費が目立ってきたら tool search を足す
  3. 個々の会話が「初期の結果が無関係になる」ほど長くなってきたら context editing を足す
  4. 小さなツール呼び出しの反復的な連鎖に気づいたら programmatic tool calling を検討する

そのまま使える具体例

導入判断のしきい値（この文書の実務的な要点はここに尽きる）:

prompt caching          → 初日から。ツール定義が安定しているなら常に
tool search             → ツールが 20個を超えたら
context editing         → 会話が長引き、初期の tool_result が無関係になったら
programmatic tool calling → 小さなツール呼び出しの連鎖が繰り返し現れたら

原典で言及されている関連文書

未取得の派生リンク

グラフビュー

バックリンク