本記事について
執筆日：2025/11/26
引用元：
本記事では、Anthropicが新たにリリースした以下のツールについて解説します。
-
Tool Serarch Tool (ツール検索ツール)：
すべてのツール定義を前もってロードするのではなく、必要時に検索して定義を展開する仕組みで、コンテキストウィンドウを消費することなく大量のツールが利用可能になる -
Programmatic Tool Calling (プログラマティックツール呼び出し) ：
ツール呼び出しを自然言語の逐次推論ではなく、コード実行コンテナの中でプログラム的に行い、中間結果や推論往復によるトークン消費を削減する
対応モデル：
- Claude Opus 4.5
- Claude Sonnet 4.5
Tool Serarch Tool
概要
従来では、すべてのツール定義をあらかじめコンテキストウィンドウに読み込んでいたことによって、ツールライブラリの拡大に伴い、以下のような問題が発生していました。
- 会話を始める前にすでに、ツール定義がコンテキストウィンドウの大部分を消費する
- ツール選択の精度が低下する（30~50を超える場合に顕著）
これらを解決するために、Tool Serarch Toolは以下のようなアプローチをとります。
- 会話の開始前のツール定義の読み込みを遅延する。(設定方法は後述)
- Tool Serarch Toolを使用して現在のタスクに必要なツールを検索する
- 検索にヒットしたツールだけをコンテキストに読み込む
使い方
サンプルコード全文
import anthropic
client = anthropic.Anthropic()
response = client.beta.messages.create(
model="claude-sonnet-4-5-20250929",
betas=["advanced-tool-use-2025-11-20"],
max_tokens=2048,
messages=[
{
"role": "user",
"content": "What is the weather in San Francisco?"
}
],
tools=[
{
"type": "tool_search_tool_regex_20251119",
"name": "tool_search_tool_regex"
},
{
"name": "get_weather",
"description": "Get the weather at a specific location",
"input_schema": {
"type": "object",
"properties": {
"location": {"type": "string"},
"unit": {
"type": "string",
"enum": ["celsius", "fahrenheit"]
}
},
"required": ["location"]
},
"defer_loading": True
},
{
"name": "search_files",
"description": "Search through files in the workspace",
"input_schema": {
"type": "object",
"properties": {
"query": {"type": "string"},
"file_types": {
"type": "array",
"items": {"type": "string"}
}
},
"required": ["query"]
},
"defer_loading": True
}
]
)
print(response)
ツール定義
検索方法にはRegex(Python正規表現)、BM25(自然言語クエリ)の2パターンのバリアントが存在します。
{
"type": "tool_search_tool_regex_20251119",
"name": "tool_search_tool_regex"
}
{
"type": "tool_search_tool_bm25_20251119",
"name": "tool_search_tool_bm25"
}
遅延ツール読み込み
ツール定義に"defer_loading": trueを追加することで、指定したツールの読み込みを遅延し、ClaudeがTool Serarch Toolの検索で検出した場合にのみ読み込まれます。
※最適なパフォーマンスのため、最も頻繁に使用される3～5個のツールを遅延されていないものとして保つことが推奨されています。
{
"name": "get_weather",
"description": "Get current weather for a location",
"input_schema": {
"type": "object",
"properties": {
"location": { "type": "string" },
"unit": { "type": "string", "enum": ["celsius", "fahrenheit"] }
},
"required": ["location"]
},
"defer_loading": true
}
レスポンス形式
-
server_tool_use: Claudeがツール検索ツールを呼び出していることを示します -
tool_resultwithtool_reference: 検出されたツールへの参照を含む検索結果 -
tool_use: Claudeが検出されたツールを呼び出しています -
tool_referenceで検出されたツールは自動的にコンテキストに展開されます。
{
"role": "assistant",
"content": [
{
"type": "text",
"text": "I'll search for tools to help with the weather information."
},
{
"type": "server_tool_use",
"id": "srvtoolu_01ABC123",
"name": "tool_search_tool_regex",
"input": {
"query": "weather"
}
},
{
"type": "tool_result",
"tool_use_id": "srvtoolu_01ABC123",
"content": [{ "type": "tool_reference", "tool_name": "get_weather" }]
},
{
"type": "text",
"text": "I found a weather tool. Let me get the weather for San Francisco."
},
{
"type": "tool_use",
"id": "toolu_01XYZ789",
"name": "get_weather",
"input": { "location": "San Francisco", "unit": "fahrenheit" }
}
],
"stop_reason": "tool_use"
}
注意点
ツール検索を行うステップを追加するため、遅延が増加します。コンテキスト削減やツール選択精度とのトレードオフを考慮しましょう。
適切なユースケース：
- システムで10個以上のツールが利用可能
- ツール定義が10Kトークン以上を消費している
- 大規模なツールセットでツール選択精度の問題が発生している
- MCPで駆動されるシステムを構築している（複数のサーバー、200個以上のツール）
使用するべきでないケース：
- 合計10個未満のツール
- すべてのツールがすべてのリクエストで頻繁に使用される
- ツール定義が小さい（合計<100トークン）
Programmatic Tool Calling
概要
従来のツール呼び出しでは、ワークフローが複雑になるにつれ以下のような問題が発生します。：
-
中間結果によるコンテキストの汚染
例えば複数のテーブルから顧客データを取得する場合、テーブル同士やタスク内容との関係性に関わらずすべてのレコードをコンテキストに追加してしまいます。これらの中間結果は膨大なトークンを消費し、重要な情報をコンテキストの外へ追いやってしまいます。 -
推論オーバーヘッドと手動合成
ツールの呼び出しごとに、モデルはその結果からタスクに関連する情報を抽出し、次のアクションを決定するなどの推論を行う必要があります。例えば、5つのツールを使用する場合、各ツール呼び出しごとにこのステップを5回繰り返し、それらの結果を統合する必要があり、遅延やエラーの増加につながります。
Programmatic Tool Callingでは、個別のツール呼び出しを繰り返すのではなく、ワークフロー全体をオーケストレーションするPythonスクリプトを作成し、実行します。（コード実行ツールのサンドボックス環境=コンテキスト外で行われます。）
複数のツール呼び出し、それらの出力の処理をPythonコードでプログラム的に実行し、タスクの完了に必要となる最終的な情報だけがコンテキストウィンドウに追加されます。
繰り返し、条件分岐、データ変換処理、エラーハンドリングといったコードを利用した明示的な制御によって、より信頼性の高い、精密なフローコントロールを実現できます。
これにより、以下のような恩恵を得ることができます。
- トークン節約: 中間結果を読み込まない
- 遅延削減: ツール呼び出しごとの推論往復を削減
-
精度向上: 不要な情報をコンテキストに読み込まない
使い方
コード実行可能なツールとしてマークする
["code_execution_20250825"]: コード実行ツール本体
ツール定義に"allowed_callers": ["code_execution_20250825"] を指定します
{
"tools": [
{
"type": "code_execution_20250825",
"name": "code_execution"
},
{
"name": "get_team_members",
"description": "Get all members of a department...",
"input_schema": {...},
"allowed_callers": ["code_execution_20250825"] # opt-in to programmatic tool calling
},
{
"name": "get_expenses",
...
},
{
"name": "get_budget_by_level",
...
}
]
}
モデルがオーケストレーションコードを作成
{
"type": "server_tool_use",
"id": "srvtoolu_abc",
"name": "code_execution",
"input": {
"code": "team = get_team_members('engineering')\n..." # 実行するコード本文
}
}
スクリプトの出力がコンテキストに追加される
コード実行ツールのレスポンス
{
"type": "code_execution_tool_result",
"tool_use_id": "srvtoolu_abc",
"content": {
"stdout": "[{\"name\": \"Alice\", \"spent\": 12500, \"limit\": 10000}...]"
}
}
注意点
コード実行ステップの追加による遅延の増加とコンテキスト削減がトレードオフになります。
適切なユースケース
- 集計や要約が必要な大規模データセットの処理
- 3つ以上の独立したツール使用を含むマルチステップワークフロー
- ツール結果のフィルタリング、ソート、または変換が必要な操作
- 中間データが Claude の推論に影響を与えるべきではないタスク
- 多くのアイテム（例：50 個のエンドポイントをチェック）にわたる並列操作
理想的ではないユースケース
- シンプルなレスポンスを含む単一のツール呼び出し
- タスクの実行において、モデルが全ての中間結果を必要とする場合
- コード実行オーバーヘッドが利益を上回る非常に高速な操作
まとめ
今回紹介した機能はいずれも、ツール実行におけるトークンの消費を削減し、コンテキストウィンドウを最適化するためのアプローチでした。
マルチエージェント構成をとらずとも、単一のモデル内でコンテキストウィンドウに何を載せるかを動的に制御できるというのも面白いポイントだと思いました。
今後はドメイン横断や複雑なデータ処理を伴うようなタスクもより効率的に実行できるようになるかもしれませんね。
先日Microsoft FoundryからもClaudeのモデルが利用できるようになったので、ぜひ試してみてください。
Discussion