この記事を初学者向けにわかりやすく解説します。
この記事は、Anthropic が Claude 開発者プラットフォームに追加した3つの新しいベータ機能を紹介しています。これらの機能は、AI エージェントが大量のツール（外部サービスや API）を効率的に使えるようにするためのものです。
従来のアプローチでは、すべてのツール定義を最初から Claude に読み込ませる必要がありました。これには3つの大きな問題があります。
問題1：コンテキストウィンドウの圧迫
「コンテキストウィンドウ」とは、Claudeが一度に処理できるテキストの量の上限です。本の長さに例えると、一度に読める本のページ数のようなものです。
記事の例では、5つのMCPサーバーを接続した場合：
合計で約55,000トークンが、会話が始まる前から消費されてしまいます。これは、実際のやり取りに使える「余白」が大幅に減ることを意味します。
問題2：中間結果によるコンテキスト汚染
例えば、10MBのログファイルを分析する場合、従来の方法ではファイル全体がClaudeのコンテキストに入ってしまいます。実際に必要なのは「エラーの頻度の要約」だけなのに、全データを保持する必要がありました。
問題3：パラメータの間違い
JSONスキーマ（ツールの入力形式の定義）は「何が有効か」を示しますが、「どう使うべきか」は示しません。例えば：
すべてのツール定義を最初から読み込むのではなく、必要なときに必要なツールだけを検索して読み込む機能です。
従来の方法は「図書館のすべての本を自分の机に積み上げてから作業を始める」ようなものでした。Tool Search Toolは「必要な本だけを図書館の検索システムで探して持ってくる」方式です。
{
"tools": [
// 検索ツール自体を定義（約500トークン）
{"type": "tool_search_tool_regex_20251119", "name": "tool_search_tool_regex"},
// 各ツールを「遅延読み込み」としてマーク
{
"name": "github.createPullRequest",
"description": "Create a pull request",
"input_schema": {...},
"defer_loading": true // ← これがポイント
}
]
}
defer_loading: trueを設定したツールは最初は読み込まれず、Claudeが検索したときだけ読み込まれます。
従来、Claude はツールを1つずつ呼び出し、その都度結果を受け取っていました。Programmatic Tool Calling では、Claude がコード（Python）を書いて、複数のツールをまとめて実行できます。
「Q3で出張予算を超えた社員は誰？」というタスクを考えます。
従来の方法:
Programmatic Tool Callingを使う場合:
Claudeが以下のようなコードを書きます：
team = await get_team_members("engineering")
# 各レベルの予算を並列で取得
levels = list(set(m["level"] for m in team))
budget_results = await asyncio.gather(*[
get_budget_by_level(level) for level in levels
])
budgets = {level: budget for level, budget in zip(levels, budget_results)}
# 全員の経費を並列で取得
expenses = await asyncio.gather(*[
get_expenses(m["id"], "Q3") for m in team
])
# 予算超過者を特定
exceeded = []
for member, exp in zip(team, expenses):
budget = budgets[member["level"]]
total = sum(e["amount"] for e in exp)
if total > budget["travel_limit"]:
exceeded.append({
"name": member["name"],
"spent": total,
"limit": budget["travel_limit"]
})
print(json.dumps(exceeded))
このコードがサンドボックス環境で実行され、Claudeには最終結果だけが返されます。2,000件以上の経費明細はClaudeのコンテキストには入りません。
JSONスキーマだけでは「どう使うべきか」がわかりにくいツールに対して、具体的な使用例を提供できる機能です。
JSONスキーマは「材料リスト」のようなもので、どんな材料が使えるかは分かりますが、どう組み合わせるべきかは分かりません。Tool Use Examplesは「完成した料理の写真とレシピ」を見せることで、正しい使い方を示します。
サポートチケット作成APIを例にします：
{
"name": "create_ticket",
"input_schema": {...},
"input_examples": [
// 例1: 緊急バグ報告（フル指定）
{
"title": "Login page returns 500 error",
"priority": "critical",
"labels": ["bug", "authentication", "production"],
"reporter": {
"id": "USR-12345",
"name": "Jane Smith",
"contact": {
"email": "jane@acme.com",
"phone": "+1-555-0123"
}
},
"due_date": "2024-11-06",
"escalation": {
"level": 2,
"notify_manager": true,
"sla_hours": 4
}
},
// 例2: 機能リクエスト（部分指定）
{
"title": "Add dark mode support",
"labels": ["feature-request", "ui"],
"reporter": {
"id": "USR-67890",
"name": "Alex Chen"
}
},
// 例3: 内部タスク（最小指定）
{
"title": "Update API documentation"
}
]
}
これらの例から、Claudeは次のことを学びます：
feature-request）内部テストでは、複雑なパラメータ処理の精度が**72% → 90%**に向上しました。
create_ticket vs create_incidentなど）| 機能 | 解決する問題 | 主な効果 | ドキュメント |
|---|---|---|---|
| Tool Search Tool | ツール定義によるコンテキスト圧迫 | トークン85%削減、精度25ポイント向上 | リンク |
| Programmatic Tool Calling | 中間結果によるコンテキスト汚染 | トークン37%削減、レイテンシ大幅削減 | リンク |
| Tool Use Examples | パラメータの誤使用 | 精度72%→90%に向上 | リンク |