Claude開発者プラットフォームの高度なツール利用機能

公開日: 2025年11月24日

著者: Bin Wu（Adam Jones、Artur Renault、Henry Tay、Jake Noble、Nathan McCandlish、Noah Picard、Sam Jiang、およびClaude Developer Platformチームの貢献による）

原文: Advanced Tool Use on the Claude Developer Platform

概要

Anthropicは、Claudeが大規模なツールライブラリをより効率的に扱えるようにする3つのベータ機能をリリースしました：

1. Tool Search Tool - ツールの動的発見
2. Programmatic Tool Calling - コードによるツールオーケストレーション
3. Tool Use Examples - 具体的な使用パターンの提示

Tool Search Tool

課題

MCPツールの定義は、会話が始まる前に大量のトークンを消費します。5つのサーバーを使用した例を見てみましょう：

合計58ツールで約55Kトークンが初期費用として消費されます。Jira（約17Kトークン）を追加すると、100K以上のオーバーヘッドに達します。Anthropicでは、最適化前にツール定義だけで134Kトークンを消費しているケースを観察しました。

トークンコストに加えて、notification-send-user と notification-send-channel のような似た名前のツールでは、誤ったツール選択や不正確なパラメータという失敗パターンが特に発生しやすくなります。

解決策

すべてのツール定義を事前に読み込む代わりに、Tool Search Toolはツールをオンデマンドで発見します。Claudeは現在のタスクに必要なツールにのみアクセスします。

従来のアプローチ:

• すべてのツール定義を事前に読み込み（50以上のMCPツールで約72Kトークン）
• 会話履歴とシステムプロンプトが残りの領域を奪い合う
• 作業開始前の総コンテキスト消費量：約77Kトークン

Tool Search Toolを使用した場合:

• 事前に読み込むのはTool Search Toolのみ（約500トークン）
• 必要に応じてオンデマンドでツールを発見（3〜5個の関連ツール、約3Kトークン）
• 総コンテキスト消費量：約8.7Kトークン、コンテキストウィンドウの95%を保持

これはトークン使用量の85%削減を意味します。内部テストでは精度の大幅な向上が確認されました：Opus 4は49%から74%に、Opus 4.5は79.5%から88.1%に改善しました。

実装方法

オンデマンド発見のために、ツールに defer_loading: true を設定します。Claudeは最初にTool Search Toolと defer_loading: false のツールのみを認識します。

{
  "tools": [
    {"type": "tool_search_tool_regex_20251119", "name": "tool_search_tool_regex"},
    {
      "name": "github.createPullRequest",
      "description": "Create a pull request",
      "input_schema": {...},
      "defer_loading": true
    }
  ]
}

MCPサーバーの場合、特定のツールを読み込んだまま、サーバー全体を遅延させることができます：

{
  "type": "mcp_toolset",
  "mcp_server_name": "google-drive",
  "default_config": {"defer_loading": true},
  "configs": {
    "search_files": {"defer_loading": false}
  }
}

使用すべき場面

効果的な場面:

• ツール定義が10Kトークン以上を消費している
• ツール選択の精度に問題がある
• 複数のサーバーを持つMCPベースのシステムを構築している
• 10以上のツールが利用可能

効果が薄い場面:

• ツールライブラリが小さい（10未満のツール）
• すべてのツールが毎セッションで頻繁に使用される
• ツール定義がコンパクト

注意: Tool Search Toolは、遅延ツールが初期プロンプトから除外されるため、プロンプトキャッシュを破壊しません。

Programmatic Tool Calling

課題

従来のツール呼び出しは、複雑なワークフローで2つの問題を引き起こします：

中間結果によるコンテキスト汚染: 10MBのログファイルをエラーパターンで分析する場合、必要なのはエラー頻度の要約だけなのに、ファイル全体がコンテキストに読み込まれます。複数のテーブルから顧客データを取得する場合、関連性に関係なくすべてのレコードがコンテキストに蓄積され、大量のトークン予算を消費します。

推論オーバーヘッドと手動合成: 各ツール呼び出しには完全なモデル推論が必要です。Claudeはデータを「目視」して関連情報を抽出し、ピースがどのように組み合わさるかを推論し、次のステップを決定する必要があります。これらすべてが自然言語で行われます。5ツールのワークフローは、5回の推論パスに加えて、Claudeが結論を解析・合成する必要があります。

解決策

Programmatic Tool Callingにより、Claudeは個別のAPIラウンドトリップではなく、コードを通じてツールをオーケストレーションできます。Claudeは複数のツールを呼び出し、出力を処理し、どの情報がコンテキストウィンドウに入るかを制御するコードを書きます。

コードはオーケストレーションロジック（ループ、条件分岐、データ変換）に適しています。自然言語でのツール呼び出しではなくPythonでオーケストレーションを表現することで、明示的なエラー処理を持つ、より信頼性の高い正確な制御フローが得られます。

例：予算コンプライアンスチェック

シナリオ: 「Q3の出張予算を超過したチームメンバーは誰ですか？」

利用可能なツール:

• get_team_members(department) - IDとレベルを含むチームメンバーリストを返す
• get_expenses(user_id, quarter) - ユーザーの経費明細を返す
• get_budget_by_level(level) - 従業員レベルの予算上限を返す

従来のアプローチ:

• チームメンバーを取得 → 20人
• 各人についてQ3の経費を取得 → 20回のツール呼び出し、それぞれ50〜100の明細
• 従業員レベルごとの予算上限を取得
• すべてがClaudeのコンテキストに入る：2,000以上の経費明細（50KB以上）
• Claudeが手動で各人の経費を合計し、予算を調べ、比較

Programmatic Tool Callingを使用した場合:

Claudeは、サンドボックス化されたCode Execution環境でワークフロー全体をオーケストレーションするコードを書きます。スクリプトはツール結果が必要なときに一時停止し、返された結果はClaudeのコンテキストではなくスクリプトで処理されます。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〜3人。2,000以上の明細、中間合計、予算参照はコンテキストに影響を与えず、消費量は200KBの生の経費データから1KBの結果に削減されます。

効率性の向上

トークン削減: 複雑な調査タスクで平均使用量が43,588から27,297トークンに減少、37%の削減。

レイテンシ削減: Claudeが単一のコードブロックで20以上のツール呼び出しをオーケストレーションする場合、19回以上の推論パスを排除。

精度向上: 内部の知識検索が25.6%から28.5%に改善、GIAベンチマークが46.5%から51.2%に改善。

実装方法

1. ツールをコードから呼び出し可能にマーク

code_execution を追加し、allowed_callers でツールをオプトインします：

{
  "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"]
    }
  ]
}

2. Claudeがオーケストレーションコードを書く

ツールを1つずつ要求する代わりに、ClaudeはPythonコードを生成します：

{
  "type": "server_tool_use",
  "id": "srvtoolu_abc",
  "name": "code_execution",
  "input": {
    "code": "team = get_team_members('engineering')\n..."
  }
}

3. ツールがClaudeのコンテキストを経由せずに実行

コードが get_expenses() を呼び出すと、callerフィールドを持つツールリクエストを受け取ります：

{
  "type": "tool_use",
  "id": "toolu_xyz",
  "name": "get_expenses",
  "input": {"user_id": "emp_123", "quarter": "Q3"},
  "caller": {
    "type": "code_execution_20250825",
    "tool_id": "srvtoolu_abc"
  }
}

結果はClaudeのコンテキストではなく、Code Execution環境で処理されます。

4. 最終出力のみがコンテキストに入る

コードが完了すると、結果のみがClaudeに返されます：

{
  "type": "code_execution_tool_result",
  "tool_use_id": "srvtoolu_abc",
  "content": {
    "stdout": "[{\"name\": \"Alice\", \"spent\": 12500, \"limit\": 10000}...]"
  }
}

使用すべき場面

最も効果的な場面:

• 集計や要約のみが必要な大規模データセットの処理
• 3つ以上の依存するツール呼び出しを持つマルチステップワークフロー
• Claudeが見る前にツール結果をフィルタリング、ソート、変換
• 中間データが推論に影響を与えるべきでないタスク
• 多数のアイテムに対する並列操作

効果が薄い場面:

• 単純な単一ツールの呼び出し
• Claudeがすべての中間結果を見て推論すべきタスク
• 小さなレスポンスを持つクイックルックアップ

Tool Use Examples

課題

JSON Schemaは構造の定義（型、必須フィールド、許可されるenum）に優れていますが、使用パターンを表現できません：オプションパラメータをいつ含めるか、どの組み合わせが意味を持つか、APIがどのような規約を期待しているか。

サポートチケットAPIの曖昧さの例：

• フォーマットの曖昧さ: due_date は "2024-11-06"、"Nov 6, 2024"、またはISO 8601を使用すべきか？
• ID規約: reporter.id はUUID、"USR-12345"、または単なる "12345" か？
• ネストされた構造の使用法: Claudeはいつ reporter.contact を設定すべきか？
• パラメータの相関: escalation.level と escalation.sla_hours は優先度とどう関連するか？

これらの曖昧さは、不正なツール呼び出しや一貫性のないパラメータ使用につながります。

解決策

Tool Use Examplesは、具体的な使用パターンを示すサンプルツール呼び出しをツール定義に直接提供します：

{
  "name": "create_ticket",
  "input_schema": { /* schema */ },
  "input_examples": [
    {
      "title": "Login page returns 500 error",
      "priority": "critical",
      "labels": ["bug", "authentication", "production"],
      "reporter": {
        "id": "USR-12345",
        "name": "Jane Smith",
        "contact": {
          "email": "[email protected]",
          "phone": "+1-555-0123"
        }
      },
      "due_date": "2024-11-06",
      "escalation": {
        "level": 2,
        "notify_manager": true,
        "sla_hours": 4
      }
    },
    {
      "title": "Add dark mode support",
      "labels": ["feature-request", "ui"],
      "reporter": {
        "id": "USR-67890",
        "name": "Alex Chen"
      }
    },
    {
      "title": "Update API documentation"
    }
  ]
}

これらの例から、Claudeは以下を学習します：

• フォーマット規約: 日付はYYYY-MM-DD、ユーザーIDはUSR-XXXXX形式、ラベルはケバブケース
• ネストされた構造パターン: ネストされたcontactオブジェクトを持つreporterオブジェクトの構築方法
• オプションパラメータの相関: 重大なバグは完全な連絡先情報＋厳しいSLAのエスカレーション、機能リクエストはreporterのみでcontact/escalationなし、内部タスクはtitleのみ

内部テストでは、Tool Use Examplesにより複雑なパラメータ処理の精度が72%から90%に向上しました。

使用すべき場面

最も効果的な場面:

• 有効なJSONが正しい使用法を意味しない複雑なネスト構造
• 含める/含めないパターンが重要な多数のオプションパラメータを持つツール
• スキーマでは捕捉できないドメイン固有の規約を持つAPI
• どちらを使うべきか例が明確にする類似ツール（例：create_ticket vs create_incident）

効果が薄い場面:

• 使用法が明らかな単純な単一パラメータツール
• ClaudeがすでにURLやメールを理解している標準フォーマット
• JSON Schema制約で処理すべきバリデーションの懸念

ベストプラクティス

機能を戦略的に組み合わせる

すべてのエージェントがすべてのタスクに3つの機能すべてを必要とするわけではありません。最大のボトルネックから始めてください：

• ツール定義によるコンテキスト膨張 → Tool Search Tool
• 大きな中間結果によるコンテキスト汚染 → Programmatic Tool Calling
• パラメータエラーと不正なコール → Tool Use Examples

必要に応じて追加機能を重ねてください；それらは補完的です。

Tool Search Toolをより良い発見のために設定

ツール検索は名前と説明に対してマッチングするため、明確で説明的な定義が精度を向上させます。

良い例:

{
  "name": "search_customer_orders",
  "description": "Search for customer orders by date range, status, or total amount. Returns order details including items, shipping, and payment info."
}

悪い例:

{
  "name": "query_db_orders",
  "description": "Execute order query"
}

最も使用頻度の高い3〜5個のツールは常に読み込んでおき、残りは遅延させます。システムプロンプトにガイダンスを追加：「Slackメッセージング、Google Driveファイル管理、Jiraチケット追跡、GitHubリポジトリ操作のためのツールにアクセスできます。特定の機能を見つけるにはツール検索を使用してください。」

Programmatic Tool Callingを正しい実行のために設定

Claudeが正しい解析ロジックを書けるように、戻り値のフォーマットを明確に文書化してください：

{
  "name": "get_orders",
  "description": "Retrieve orders for a customer. Returns: List of order objects, each containing: id (str): Order identifier; total (float): Order total in USD; status (str): One of 'pending', 'shipped', 'delivered'; items (list): Array of {sku, quantity, price}; created_at (str): ISO 8601 timestamp"
}

並列実行可能なツール（独立した操作）と再試行しても安全なツール（冪等）をオプトインします。

Tool Use Examplesをパラメータ精度のために設定

動作の明確さのために例を作成：

• 現実的なデータを使用（実際の都市名、妥当な価格、プレースホルダー文字列ではなく）
• 最小限、部分的、完全な仕様パターンで多様性を示す
• 簡潔に：ツールごとに1〜5の例
• 曖昧さに焦点を当てる（スキーマから正しい使用法が明らかでない場合にのみ例を追加）

始め方

これらの機能はベータ版で利用可能です。ベータヘッダーで有効にし、必要なツールを含めます：

client.beta.messages.create(
    betas=["advanced-tool-use-2025-11-20"],
    model="claude-sonnet-4-5-20250929",
    max_tokens=4096,
    tools=[
        {"type": "tool_search_tool_regex_20251119", "name": "tool_search_tool_regex"},
        {"type": "code_execution_20250825", "name": "code_execution"},
        # defer_loading、allowed_callers、input_examplesを持つあなたのツール
    ]
)

結論

これらの機能は、ツール利用を単純な関数呼び出しからインテリジェントなオーケストレーションへと進化させます。エージェントが数十のツールと大規模なデータセットにまたがるますます複雑なワークフローに取り組む中で、動的発見、効率的な実行、信頼性の高い呼び出しは、効果的なAIシステムを構築するための基盤的な機能となります。