- Claude Developer Platform に3つの新機能が追加され、モデルが数千もの外部ツールを効率的に探索・呼び出し・学習できる 高度なツール利用アーキテクチャ を提供
- Tool Search Tool は必要なタイミングでのみツール定義を読み込み、トークン使用量を最大85%削減、大規模なMCP環境で 精度を74〜88%水準まで向上
- Programmatic Tool Calling はコード実行環境でツールを並列呼び出しし、トークン削減（37%）、レイテンシ低減、精度向上 を実現
- Tool Use Examples は実際の呼び出し例を通じて、JSON Schemaでは表現できない ツール利用パターンとパラメータ関係 を学習させる
- これら3機能は 大規模AIエージェントの効率的なオーケストレーション基盤 を提供し、複雑なワークフロー自動化の中核コンポーネントとなる
AIエージェントのツール利用拡張
- 将来のAIエージェントは数百〜数千のツールを統合的に活用する必要がある
- 例として、IDE支援ツール、運用コーディネーター、Slack・GitHub・Jira・Google Drive などとの連携を提示
- 従来方式ではすべてのツール定義を事前に読み込む必要があり、コンテキストウィンドウ（context window） を急速に消費する
- 新しいアプローチでは 必要な時点でツールを探索・ロード し、コードベースの呼び出し と サンプル学習 によって効率性を確保する
Tool Search Tool
- 既存のMCP環境では、多数のサーバーを接続するとツール定義が 10万超のトークン を占める
- 例: GitHub（26K）、Slack（21K）、Jira（17K）など、合計で134Kトークンを超えるケース
- Tool Search Tool はツールを on-demand方式で検索・ロード する
- 初期ロード時は約500トークン בלבדを使用し、必要なツールだけを追加ロード
- 総トークン使用量は約8.7Kまで減少し、95%のコンテキスト節約
- 内部テストでは、MCP評価精度が Opus 4: 49%→74%、Opus 4.5: 79.5%→88.1% に向上
defer_loading: true 設定によりツールの遅延ロードが可能
- よく使うツールだけを常時ロードし、それ以外は検索時に読み込む
- 正規表現（regex）・BM25ベースの検索ツールを標準提供し、埋め込みベースのカスタム検索も可能
- 適用推奨条件: ツール数が10以上、定義が10Kトークン以上、選択ミスが頻発する環境
Programmatic Tool Calling
- 従来の自然言語ベース呼び出しは、中間結果の蓄積 と 複数回の推論パス により非効率が生じる
- 例: 10MBのログ分析では、全データがコンテキストに含まれてトークンを浪費する
- Programmatic Tool Calling（PTC）は コード実行環境でツールを並列呼び出し する
- Claude が Python コードでループ・条件分岐・データ変換を実行
- 中間結果はモデルのコンテキストに含まれず、最終結果のみ返される
- 例: 四半期ごとの予算超過者を探す作業では、2,000件の項目の代わりに結果1KBだけをコンテキストに含める
- 効果
- トークン使用量 43,588→27,297（37%減）
- レイテンシ短縮（20回の呼び出しで19回の推論を削減）
- 精度向上: 内部検索 25.6→28.5%、GIAベンチマーク 46.5→51.2%
- 適用推奨条件
- 大規模データ要約、3段階以上の依存呼び出し、並列実行が必要な作業
- 単一呼び出しや小さな応答には非効率
Tool Use Examples
- JSON Schema は構造を定義するだけで、利用パターン・書式ルール・パラメータ関係 を表現できない
- 例: 日付形式、IDルール、ネストされたオブジェクトを使うタイミングなどが不明確
- Tool Use Examples はツール定義に 実際の入力例（input_examples） を追加する
- サンプルを通じて Claude が日付形式（YYYY-MM-DD）、IDルール（USR-XXXXX）、選択パラメータの組み合わせなどを学習
- 内部テストでは 複雑なパラメータ処理精度が72%→90% に向上
- 適用推奨条件
- ネスト構造や選択パラメータが多いツール
- ドメイン固有ルールが Schema で表現されない API
- 類似ツール間の区別が必要な場合
3機能の統合活用とベストプラクティス
- 3機能は 相互補完的 に動作する
- Tool Search Tool → 必要なツールを探索
- Programmatic Tool Calling → 効率的に実行
- Tool Use Examples → 正確に呼び出す
- 適用優先順位
- コンテキスト超過 → Tool Search Tool
- 中間結果が多すぎる → Programmatic Tool Calling
- パラメータエラー → Tool Use Examples
- 設定のヒント
- ツール名・説明を明確に記述して検索精度を向上
- よく使う3〜5個のツールは常時ロードし、それ以外は遅延ロード
- コード実行用ツールは返却形式を明記
- サンプルデータは現実的かつ簡潔に作成（1〜5例）
はじめに
- 3機能は ベータ版 として提供
betas=["advanced-tool-use-2025-11-20"] ヘッダーを追加して利用可能- 含まれるツール:
tool_search_tool_regex_20251119, code_execution_20250825 など
- 公式ドキュメントと GitHub cookbook で API サンプルおよび実装ガイドを提供
- これらの機能は、単純な関数呼び出しを超えて インテリジェントなオーケストレーション へ進化する基盤技術と位置付けられる
- 複雑なワークフローと大規模データ環境において、動的探索・効率的実行・正確な呼び出し を実現する中核コンポーネントとして強調されている
5件のコメント
でも、今のところはまだモデル頼みな気がします。Claudeが提供しているモデルだからこそ、これほどうまく機能しているのであって、他のモデルでも本当にそうなのかは……という感じですね。
Anthropic、Google、OpenAI のような企業の中では、Anthropic が最も Agentic AI に近いという印象を受けます。
Hacker Newsの意見
複数のtool callをストリーミングする際に、context使用量を減らす方法を探している
一部の処理をツール自体にオフロードして、200kトークン級のmarkdownを要約構造として返させることはできるが、この方式でもメインモデルのcontextがすぐ埋まってしまうことがある
Programmatic Tool Callingは自然な次のステップだと思う
LLMはコードを言語のように扱う方向へ進んでいるので、その言語定義が重要になる
ただしtool searchは不要なオーバーヘッドだと思う。必要なツールをあらかじめcontextに入れておく方が効率的だ
結局、関数定義のように簡潔なtool definition languageが必要で、オブジェクトをcontextに入れて型と呼び出し可能なメソッドを認識させたい
.d.tsのような宣言ファイルを渡せばよい保守やテストも容易で、必要なら
export * as Foo from '@foo/foo'のように取り込めばよいLLMはコード生成も得意なので、書き込み権限を与えれば自分でツールを作ったり取り込んだりできる
将来的にはJupyter/Pluto/MathematicaのようなインタラクティブなAI↔人間協業プラットフォームの方が適していそうだ
音声入力を組み合わせ、セッション間の協業も可能にすれば、ほぼSkynet級のシステムになりそうだ
私が作ったエージェントは、Python SDKの一部機能とカスタム関数だけで十分に動いている
こうしたpseudo-RPC構造は不要な儀式のように感じる
Smolagentsはこれを活用してツール出力をオブジェクト（dict）として扱う
このアプローチが私の言う方向に近いのか気になる
詳細はHugging Faceのブログ記事にある
MCPサーバーがツール定義に使用例を含めるのか気になる
もしそうならコード例も入れてコード生成段階を省けるはずだが、おそらくセキュリティ上の問題で避けているのだと思う
第三者が提供したコードを実行するのは危険なので、この設計は理解できる
Pythonをラッパーに使ったのは惜しい
Bashを使っていれば、言語間の互換性がもっと高く、Pythonを使わないワークフローにも合っていただろう
外部ツールを実行する能力もBashに劣らない
「数百〜数千個のツールをモデルがシームレスに扱う未来」という方向性は間違っている気がする
むしろ少ないツール + より高い活用能力こそ正しい方向だと思う
極端に言えば、ShellToolひとつでも十分かもしれない
モデル自身がツールを作ってテストし、信頼できるよう学習する方式が理想的だ
コネクターのエコシステムは理解しやすく、マーケティングもしやすいが、根本的には間違ったパラダイムのように思える
小さなローカルオーケストレーターモデルがあるとよいと思う
ワークフロー全体をプログラム的に調整するには非効率なことが多い
context汚染を減らして速度を上げるには、programmatic > tiny local LLM > frontier LLMという構成が理想的だ
小さなモデルはcontextを頻繁に初期化し、必要な結果だけを大きなモデルに渡せばよい
AIアシスタントを使っていると、繰り返し現れるパターンがある
非効率な方法を自分で改善すると、数か月後には新しいツールが出てきて、自分の作業が無意味になる
最新技術を追いかける代償だと思う
いつかWeb全体が数十億のツールで構成されるようになる気がする
Googleがそれをインデックスし、Geminiが動的に選択して世界で行動を実行するようになるだろう
実際、私はそれをGemini 3に期待していた
ここで言及されている機能#2は、最近話題になった「ツールを直接呼び出さず、コードを書いて呼び出す」という概念の実装だ
Python sandbox上で動作し、APIからもアクセスでき、ツール呼び出しを通常のAPI呼び出しのように公開する
Batch tool callingはすでに私たちの製品のAIアシスタントを大幅に高速化しており、今回の機能はその進化形のように見える
私たちのagentic builderはツールをひとつしか使わない — それがGraphQLだ
エージェントがクエリを書いて実行し、introspectionで必要な情報を得る
最小限のデータだけを受け取ることでトークン節約が可能になる
50個以上のツールをロードする必要もなく、REST APIのN+1問題も解消される
GraphQL typed schemaのおかげで、エージェントはよりよいコードを書ける
以前はGraphQLが好きではなかったが、MCPの現状を見ると、AIエージェントに最も適した技術のひとつだと思う
詳細はこの記事にまとめた
私のエージェントはSPARQLクエリひとつだけを実行し、状態はグラフDBだけだ
ほとんどのオントロジーは公開されているので、schema introspectionはほぼ不要だ
構造化出力のおかげで、有効なRDFだけを生成するよう制約できる
GraphQLでも似たやり方は可能そうだ
私はWeb検索、ローカルAPI呼び出し、Slack統合などさまざまな作業をしなければならないので、GraphQLひとつでは足りない
権限、キャッシュ、mutationの問題はあるが、選択的context読み込みには大きな影響はない
LLMはschemaに合ったGraphQLクエリをかなりうまく書ける
間違えても、よいエラーメッセージを返せばすぐ修正する
関連するreasoningはこのブログ記事にある
Sonnet 4.5 もかなり良いと思っていたんですが、
Opus 4.5 はさらに良い気がします。うわあ。
そうですか？主にどのような点がそうなのでしょうか？