ツールコンテキストの管理

ツール定義と蓄積された tool_result ブロックは、コンテキストウィンドウを消費します。多数のツールや多数のターンを伴う長時間実行のエージェントは、タスクが完了する前に利用可能なコンテキストを使い果たす可能性があります。4つのアプローチが、パイプラインの異なる段階でこの問題に対処します。



4つのアプローチ

各アプローチは、コンテキスト圧迫の異なる原因を対象としています。トークンがどこで消費されているかに応じて、適切なものを選択してください。



ツール検索

「tool search」（ツール検索）は、Claudeが要求するまでツール定義をコンテキストウィンドウの外に保持します。50個のツールスキーマを事前に送信する代わりに、単一の tool_search ツールを送信し、残りはClaudeがオンデマンドで発見できるようにします。これにより、わずかなレイテンシ（ツールを検索するための追加の1ターン）と引き換えに、ベースラインのコンテキスト使用量を大幅に削減できます。



プログラマティックツール呼び出し

「programmatic tool calling」（プログラマティックツール呼び出し）は、一連のツール呼び出しを、Claudeが記述しAnthropicのコード実行サンドボックスが実行する単一のコードブロックにまとめます。tool_use と tool_result の5回の往復の代わりに、Claudeはサンドボックス内から5つの関数すべてを呼び出す1つのスクリプトを出力します。中間結果は会話履歴に入ることはありません。



プロンプトキャッシング

「prompt caching」（プロンプトキャッシング）は、コンテキスト内のトークン数を削減するわけではありませんが、後続のリクエストでそれらに支払うコストを削減します。ツール定義が安定している場合は、一度キャッシュして、キャッシュされたプレフィックスを数千のリクエストにわたって再利用します。ツールセットが大規模だが固定されている場合、これが適切な選択です。



コンテキスト編集

「context editing」（コンテキスト編集）は、役目を終えた古い tool_result ブロックを会話履歴から削除します。長いエージェントループでは、その時点では有用だったが今では無駄な重荷となっている数百の中間結果が生成される可能性があります。コンテキスト編集により、会話を再開することなくそれらを削除できます。



アプローチの組み合わせ

これらのアプローチは組み合わせて使用できます。長時間実行のエージェントは、ツール検索を使用してツールセットをスリムに保ち、プロンプトキャッシングを使用して残りの定義のコストを分散し、会話が長くなるにつれてコンテキスト編集を使用して古い結果を削除することができます。それぞれが問題の異なる部分を解決するため、併用しても競合はありません。

大量処理を行うエージェントの合理的な出発点は次のとおりです。

1. 初日からツール定義でプロンプトキャッシングを有効にします。キャッシュ書き込みには基本入力価格に対して25%の上乗せがかかりますが、キャッシュにヒットする2回目のリクエストで元が取れます。
2. ツールセットが約20ツールを超えるか、ベースラインのコンテキスト使用量が目立つようになったら、ツール検索を追加します。
3. 個々の会話が十分に長くなり、初期の結果が無関係になり始めたら、コンテキスト編集を追加します。
4. 単一のバッチとして実行できる小さなツール呼び出しの反復的なチェーンに気づいた場合は、プログラマティックツール呼び出しを検討します。



次のステップ