プログラマティックツールコーリングのコスト削減効果 — 効くワークロードと効かないワークロード

プログラマティックツールコーリングは、ツール呼び出しの中間結果をClaudeの文脈に流さずコードで処理することで、トークン消費と往復回数を減らす仕組みです。ただし削減幅は一律ではありません。開示されている実測値では、75ツール構成のベンチマークで入力トークンが38%減る一方、逐次的なツール呼び出しが中心のτ²-benchでは逆に8%のコスト増になっています。同じ機能が正反対の結果を出す理由は、ワークロードの形にあります。

トークンが減る3つの仕組み

プログラマティックツールコーリングがトークンを減らす経路は、次の3つに分けて説明されています。

• プログラマティックな呼び出しのツール結果は、Claudeの文脈に追加されない: 最終的なコード実行結果だけが文脈に入る
• 中間処理はコードの中で完結する: フィルタリング・集計・変換のような処理がモデルのトークンを消費しない
• 1回のコード実行に複数のツール呼び出しをまとめる: モデルのターンを都度挟む方式に比べてオーバーヘッドが減る

ドキュメントに挙がっている例え話では、10個のツールを直接呼び出す場合と比べ、プログラマティックに呼び出してサマリだけを返す場合はおよそ10分の1のトークンで済む、と説明されています。ただしこれは「10ツールをすべてコード内で処理し、要約だけを返す」という理想的な条件での比較であり、実際のワークロードではこの倍率がそのまま出るわけではありません。次節以降の実測値のほうが、導入判断の材料としては現実的です。

具体例で見る削減の仕組み — 20人分の経費チェック

ドキュメントに挙がっている例は、20人の従業員について予算超過をチェックするタスクです。従来の方式では、1人ずつ経費データを問い合わせるため20回分のモデルとの往復が発生し、各従業員の経費明細が数千行単位でそのままClaudeの文脈に流れ込みます。プログラマティックツールコーリングでは、1本のスクリプトが20回分の照会をまとめて実行し、結果をフィルタしたうえで予算を超えた従業員だけを返します。Claudeが最終的に読むのは数百キロバイトの生データではなく、数行の結果です。

この例が示しているのは、削減幅が「呼び出し回数」と「1回あたりの結果サイズ」の掛け算で決まるという構造です。呼び出し回数が多く、かつ個々の結果が大きいワークロードほど、コード側でまとめて処理する効果が乗数的に効きます。逆に呼び出しが1〜2回で結果も小さいなら、掛け算の答えそのものが小さく、固定オーバーヘッドの比重が相対的に大きくなります。

実測値1 — 75ツール構成のプロジェクト管理エージェントで38%削減

Anthropicの社内評価では、75個のツールを持つプロジェクト管理エージェントのベンチマークで、プログラマティックツールコーリングを有効にすると課金対象の入力トークンが約38%削減され、タスクの精度に変化はなかったと報告されています。

もう1つ、本番のAPIトラフィックを対象にした実測もあります。tools配列に10〜49個のツール定義を含むリクエストでは、プログラマティックツールコーリングを有効にすると、典型的には20%から40%のトークン削減が見られるとされています。75ツールの単一ベンチマークだけでなく、実運用に近い幅を持ったレンジが示されている点が実装判断の参考になります。

関連ベンチマーク: BrowseComp / DeepSearchQAでの実測

プログラマティックツールコーリングを基本的な検索ツールに重ねた場合の実測として、BrowseCompとDeepSearchQA(複数ステップのWeb調査や複雑な情報検索を評価するベンチマーク)で、平均11%の性能改善と24%少ない入力トークンという数値も冒頭で触れられています。これはトークン削減だけでなく精度側にも効果が及ぶケースがあることを示す例で、web_searchのdynamic filteringが使うallowed_callersの既定値とも関係する文脈です。

実測値2 — τ²-benchでは8%のコスト増

一方で、逐次的にツールを呼ぶワークロードでは効果が反転します。航空・小売・通信ドメインを扱うτ²-bench(1ターンにつき1〜2回の連続したツール呼び出しが中心のベンチマーク)では、プログラマティックツールコーリングを有効にしてもスコアは変わらず、コストはおよそ8%増加したと報告されています。

この結果は一文で総括されています。

Sequential single-call workflows do not benefit.

コンテナの起動とコード生成には固定のオーバーヘッドがかかります。1ターンにつき1〜2回しかツールを呼ばない構成では、この固定費用がツール結果を文脈に流さないことによる節約分を上回ってしまい、差し引きでコスト増になります。

効くワークロードと効かないワークロードの早見表

向く条件と向かない条件は、次のように明示的に切り分けられています。

会話の最初のターンという条件が向かない側に明記されている点は見落としやすい部分です。コンテナがまだ存在しない最初の呼び出しでは起動コストが丸ごと乗るため、同じワークロードでも2回目以降のターンでは損益分岐点が変わる可能性があります。

数字が割れる理由をどう読むか

38%削減と8%増加という2つの数字を並べると、プログラマティックツールコーリングは「効果のある機能」というより「ワークロードの形を測る機能」だと捉えるほうが実態に近く見えます。ファンアウトや並列処理が多いエージェントほど、モデルの推論を挟まずコードで完結させる余地が大きく、逆に1ステップずつClaudeの判断を挟む必要があるワークフローほど、コード実行という別レイヤーを挟むこと自体が純粋なオーバーヘッドになります。

この機能の初出は2025年11月のAdvanced Tool Useで、当時は「複雑な調査タスクで平均43,588トークンから27,297トークンへ、37%削減」という単一の数字が示されていました。現在のドキュメントは、75ツールのベンチマークとτ²-benchという性質の異なる2つの実測を並べ、「ワークロードによって効果が変わる」という前提そのものを明示する説明に変わっています。単一の削減率を示す段階から、向き不向きを併記する段階へ、ドキュメントの説明自体が一段具体的になった、と見ることができます。

コード実行のオーバーヘッドと組み合わせて考える

プログラマティックツールコーリングはコード実行ツールの上に成り立つ機能なので、コンテナの起動・実行時間そのものにもコストが発生します。Web検索・Web Fetchと同じリクエストに含めれば実行時間分は無料になりますが、単体で使う場合は実行時間ベースの課金が上乗せされます。トークン削減効果だけを見て導入判断をすると、この実行時間コストを見落とすことがあります。逐次ワークフロー寄りの構成で無理に導入すると、τ²-benchの実測が示すとおりトークンとコンテナ実行時間の両方でコストが増える可能性があります。

disable_parallel_tool_use: trueのようにプログラマティックツールコーリングと併用できない設定もあります。disable_parallel_tool_useの挙動を使っている構成では、そもそも本記事の削減効果自体が前提から外れる点も導入前に確認しておく必要があります。

導入する場合に効果を底上げする2点

向くワークロードだと判断して導入する場合でも、実装の仕方で削減幅はさらに変わります。挙げられているのは次の2点です。

• 関連するリクエストではコンテナを再利用する: 複数の関連したリクエストにまたがって同じコンテナIDを渡すと、状態を維持したままファイルやインタープリタの中身を引き継げる。毎回新規コンテナを作ると起動コストが積み上がる
• 似た操作は1回のコード実行にまとめる: 可能な限り、複数の操作を1本のスクリプトに詰め込んでから実行する。呼び出しを細かく分けるほど、コード実行の起動・停止に伴うオーバーヘッドの回数が増える

どちらも、38%削減や20〜40%削減という数字が「機能を有効にしただけ」で得られる保証値ではなく、実装の組み方に応じて変動する幅であることを裏付けています。ツール設計そのものの原則(エージェント向けツール設計の原則)を満たしたうえで、この2点を意識して初めて、示されている削減幅に近づけるという順序で考えるのが実務的です。

まとめ

プログラマティックツールコーリングのトークン削減効果は、ワークロードの形に強く依存します。多数のツールへのファンアウトや大きな結果のフィルタリングが中心の構成では38%前後、あるいは本番トラフィックで20〜40%の削減が報告されている一方、1ターンに1〜2回しかツールを呼ばない逐次ワークフローでは8%のコスト増という逆の結果が出ています。導入前には、allowed_callersの有無で課金対象トークンを実測し、自分のワークロードがファンアウト型か逐次型かを数字で確認するのが確実です。