Advanced Tool Use — Claudeが大量ツールを「探して・書いて・呼ぶ」3つの新ベータ機能を読み解く

背景 — エージェントが扱うツール数が「コンテキストを食い潰す」段階に入った

2025年11月24日、AnthropicはClaude Developer Platform向けにAdvanced Tool Useと総称される3つのベータ機能を公開しました。Tool Search Tool、Programmatic Tool Calling、Tool Use Examplesの3つで、いずれも「Claudeが大量のツールを扱うときに発生するコンテキスト圧迫と精度低下」を別々の角度から解消する設計です。

背景には、エージェント運用が一段スケールしたことで顕在化した数値があります。Anthropic社内では、ツール定義だけで会話開始前に134Kトークンを消費しているケースがあり、5つのMCPサーバ・58ツールを束ねた構成では約55Kトークンが定義の段階で埋まる、と本記事内で言及されています。200Kトークンの文脈窓のうち、何もしていない時点で4分の1から3分の2がツール記述で埋まる、というのが偽らざる現状です。

この記事では、3つの機能それぞれが何を解こうとしているのか / どんな実装で / どこまで効くのかを、Anthropic公式の開示数値と、実装上の落とし穴になりそうな点を含めて順に見ていきます。MCP(モデルコンテキストプロトコル、外部サービスをClaudeに繋ぐ標準仕様)やAgent SDK経由でエージェントを組んでいる読者を主な対象にします。

3機能の役割を1枚で

3つはそれぞれ独立したbeta headerで有効化されますが、目的は明確に分かれています。先に対応関係だけ押さえておきます。

ベータヘッダは共通で advanced-tool-use-2025-11-20。3つを同時に有効化することも、必要なものだけ拾うこともできます。

Tool Search Tool — 「全ツール定義を最初に渡す」をやめる

何を変えるか

これまでのツール呼び出しは、利用可能なすべてのツール定義を最初のpromptに詰め込む方式でした。100個ツールがあれば100個分の名前・説明・JSON Schemaが会話前から消費されます。Tool Search Toolは、ツール定義をオンデマンドで取りに行けるようにする仕組みです。

実装側は各ツールに defer_loading: true を付けることで「初期ロードしない」と宣言できます。Claudeは会話の中で必要になったタイミングでTool Search Tool自体を呼び、関連するツールを動的に発見してから実際の呼び出しに移ります。常に使う3〜5個だけを defer_loading: false で残し、残りをdeferredに倒すのが基本パターンです。

数値の読み方

公式が示している数値を整理すると、コンテキスト保全と精度の両面で効いていることが読み取れます。

• トークン: ツール定義のロード分が~77K → ~8.7K(85% 削減)
• 作業に使える文脈: 122,800 → 191,300トークン(約1.56倍)
• 精度: Opus 4で49% → 74%、Opus 4.5で79.5% → 88.1%

精度が下がるのではなく上がる点が重要です。Anthropicは「ツール選択ミスとパラメータ誤りが最頻のエラー」だと述べており、必要なツールだけをdeliberateに発見する経路に切り替えることで、無関係なツールに気を取られる頻度が減る、という理屈で説明されています。

プロンプトキャッシュとの相性

公式は「Tool Search Toolはプロンプトキャッシュを壊さない。なぜならdeferredなツールは初期promptから完全に除外されるから」と明言しています。キャッシュヒット率を死守しながらツール群を増やせるため、長期セッション運用と相性が良い設計と言えます。

向く / 向かないケース

MCP実用ガイドで扱ったGoogle Drive / Slack / GitHubのような複数サーバ構成を1つのClaudeに繋いでいる場合、まず最初に効くのがこの機能、という位置付けです。

Programmatic Tool Calling — 「中間結果を文脈に流さない」コード経由の実行

何を変えるか

従来、Claudeが20個のツールを呼ぶと、20回分の中間結果がすべて文脈窓に蓄積されました。経費明細2,000行を引いてくるAPIを呼べば、その全行がClaudeのコンテキストに入り、50KB以上を占有することもあります。さらに、各ツール呼び出しごとにフルの推論パスが走るため、20ステップのワークフローでは20回分のinferenceオーバーヘッドが発生していました。

Programmatic Tool Callingは、ClaudeにPythonコードを書かせて、サンドボックス内で複数ツールを一括オーケストレーションさせる方式です。ツールに allowed_callers: ["code_execution_20250825"] を付けると、そのツールはコード実行環境からも関数として呼び出せるようになります。

動き方

公式が挙げている例は「予算遵守チェック」です。チームメンバー一覧、メンバー別の予算、メンバー別の経費を取って横断集計する、という用途です。

1. Claudeはツール定義をPythonの関数シグネチャに変換した状態で見える
2. その関数群を組み合わせるPythonコードを生成する(並列フェッチ・フィルタ・集計)
3. コードはサンドボックスで実行され、個別ツール呼び出しの戻り値はClaudeの文脈に入らない
4. 最終的な集計結果だけがClaudeに返り、自然言語での回答に使われる

20ステップのうち19回分の推論パスが消えるため、レイテンシとコストの両方に効きます。ツール戻り値をClaudeが「自然言語で要約して次の呼び出しに繋ぐ」必要がなくなるのも大きな違いです。

数値の読み方

• トークン: 複雑な調査タスクで平均43,588 → 27,297(-37%)
• 精度: 内部KB検索25.6% → 28.5%、GIAベンチマーク46.5% → 51.2%
• 適用例: Claude for Excelが本機能を使い、「数千行のスプレッドシートをモデルの文脈窓を圧迫せずに読み書きする」と明記

スプレッドシートのような構造化大量データの取り扱いで、コンテキスト窓を消費せず処理できる点が実務的な勘所です。

向く / 向かないケース

逆に、中間結果をClaudeに「考えさせる」設計を意図的に取っているエージェント(チェーンオブソート系)では、コード実行で結果を覆い隠してしまうと、本来期待する推論経路が消えます。用途が情報抽出型か意思決定型かで切り分けるのが基本になります。

安全にopt-inするための条件

公式は実装ガイドラインで以下を挙げています。

• 戻り値の形式(型・フィールド名・取りうる値)をドキュメントに明示する
• 並列実行可能 / 冪等(idempotent)なツールからopt-inする
• 副作用のある書き込み系は慎重に

外部副作用が冪等でないツール(同じ呼び出しを2回投げると2回課金される系)は、コード生成時に重複呼び出しが起きうる前提で考える必要がある、と読めます。

Tool Use Examples — JSON Schemaが表現できない「使い方」を渡す

何を変えるか

JSON Schemaは型と必須フィールドは表現できますが、慣習的な使い方は表現できません。代表的な例として公式が挙げているのは、サポートチケット作成APIの due_date フィールドです。型は string でも、"2024-11-06" なのか "Nov 6, 2024" なのかISO 8601なのかはSchemaからは読めません。

Tool Use Examplesは、ツール定義に input_examples として具体的な呼び出しサンプルを1〜5個添える機能です。Claudeはこれを参照して、Schemaが表現しきれない以下のパターンを学習します。

• 任意フィールドをいつ含めるかの判断
• API固有の慣習(例: 日付フォーマット)
• パラメータ間の相関(あるフィールドが入るならこのフィールドも必須、等)
• 似た名前のツールの使い分け(create_ticket と create_incident 等)

数値の読み方

• 精度: 複雑なパラメータ処理で72% → 90%

この18ポイント差は、特に「optionalパラメータの取り扱い」「ネストされた構造」で効いてくる、と公式は説明しています。

例の作り方

Anthropicは「最小限・部分的・完全な」3パターンの例を見せると効果的だと述べています。サポートチケットの例では:

1. 完全版: 緊急バグ報告(連絡先・エスカレーション先・厳しいSLAすべて指定)
2. 部分版: 機能要望(報告者のみ、連絡先・エスカレーション先なし)
3. 最小版: 内部タスク(タイトルのみ)

3つを並べることで、「この場面ではこれを入れる / 入れない」の判断軸が伝わります。プレースホルダ値ではなくリアルなデータを使うこと、曖昧なケースに絞って書くことが推奨されています。

向く / 向かないケース

3つを「重ねて」使うときの順序 — どのbottleneckが先か

3機能を一気に入れる必要はありません。Anthropicはbottleneck優先で段階導入する考え方を示しています。実装上の判断軸は次の通りです。

3つを併用するときの相性も悪くありません。Tool Search Toolで「使うべきツールを発見」させ、見つかったツールが allowed_callers を持っていればコード経由で呼び、その定義に input_examples が添えてあれば慣習的な使い方も伝わる、という重ね方が自然な構造です。

エージェント設計の重心がどこに移るか — 編集視点

3機能を並べて見たときに浮かび上がるのは、「Claudeにツールを直接呼ばせる時代」から「Claudeにツールを管理させる時代」への移行です。

Tool Search Toolは「どのツールを使うか」をClaude自身に判断させる構造で、Programmatic Tool Callingは「どう繋ぐか」をClaudeのコード生成に委ねる構造です。Tool Use Examplesは人間が書いた使用例をClaudeが参照する構造で、3つに共通するのはツール群の一覧をClaudeが「動的に」扱える前提に立っていることです。

これはClaude CodeやCoworkのような完成品エージェントと、SDK上で自作するエージェントの双方に効きます。前者では内部実装が改善され、後者ではアプリケーション側の設計指針が変わります。とくに自作エージェント側では、これまで「最初に渡すツールセットの設計」に時間を使っていたところを、「ツール群が動的に増減する前提でのドキュメント整備(命名・説明・例示)」へと、コストの掛けどころが移っていく可能性が高そうです。

逆方向の懸念も書いておきます。コード経由で大量のツールを呼ばせるProgrammatic Tool Callingは、副作用のある書き込みツールを混ぜたときの監査トレースが取りにくくなる面があります。サンドボックス内で何が呼ばれたかをClaudeの発話履歴で追えなくなるので、運用側でログ取りの責務を引き受ける構成になります。Anthropicが「冪等な並列処理向きのツールからopt-inせよ」と書いているのは、この監査・冪等性の観点からも自然な助言と読めます。

既存のMCP / Agent SDK実装との接続

MCPサーバ側にも本機能は届きます。サーバ単位で default_config: {"defer_loading": true} を指定して全ツールをdeferredに倒し、特に頻出のものだけ個別にloadedのままにする、という構成が公式に示されています。MCP実装をそのまま使い回しつつ、上位のClaude側でdiscoveryを効かせられるため、サーバ作者と利用者の責務が分離されたまま導入できます。

Agent SDKで自作エージェントを組んでいる場合、ツール定義に defer_loading / allowed_callers / input_examples を足すだけで段階的に取り込める設計です。betas=["advanced-tool-use-2025-11-20"] をリクエストヘッダに足し、必要に応じて tool_search_tool_regex_20251119 と code_execution_20250825 をtools配列に加える形で有効化されます。

まとめ

• Tool Search Tool: 大量ツール構成のトークン圧迫を85% 削減し、ツール選択精度も上げる。MCP複数サーバ構成や10ツール以上の自作エージェントで、最初に検討する候補
• Programmatic Tool Calling: 中間結果をClaudeの文脈に流さずPythonコードで一括処理。大量データ集計や多段ワークフローで -37% トークン、推論パス削減によるレイテンシ改善
• Tool Use Examples: JSON Schemaが表現できない「使用慣習」を1〜5個の例で伝える。複雑なパラメータ処理で精度 +18ポイント

3つは独立に有効化でき、bottleneckから順に重ねるのが現実的です。エージェントが扱うツール数の伸びに、Claude側の設計が追いついてきた、という位置付けの更新と言えそうです。ベータ期間中の挙動と本番採用判断は、自分のワークロードでの実測と、Anthropic側の今後のアップデートを並行して見ていく流れになります。