プログラマティックツール呼び出しとは、言語モデルのエージェントがツールを使う方式の 1 つで、モデルは関数ごとに構造化された呼び出しを 1 つずつ出力してその結果を順番に受け取るのではなく、ツールを呼び出すコードを書く。これは従来のツール呼び出しとの対比で定義される。ツール拡張されたモデルの標準的な展開パターンであるネイティブの JSON ツール呼び出しでは、モデルはツール呼び出し API を通じて関数呼び出し 1 回につき 1 つの構造化された JSON オブジェクトを出力し、依存関係のある各ステップにはさらに推論ターンが必要になる。呼び出しが通常のコードであるため、スクリプトはそれらを連鎖させる — ある呼び出しの結果から別の呼び出しの引数を計算する — ことも、ループや asyncio.gather ブロックで並列に展開することもでき、何かがモデルに返される前にその結果をフィルタリングしたり集約したりすることもできる。
用法
この用語は、密接に関連する 2 つのものに対して使われる。プラットフォームの機能と、研究で評価されている方式である。
Claude Developer Platform の機能
Anthropic は、Claude Developer Platform における高度なツール利用の紹介 において、Claude Developer Platform のベータ機能として Programmatic Tool Calling を導入した。開発者はコード実行ツールと並べて allowed_callers フィールドを指定することでツールをオプトインし、API はそれらを Python の関数として Claude に公開する。Claude はオーケストレーション用のコードを書き、それはサンドボックス化されたコード実行環境で実行される。コードがツールを呼び出すたびに、開発者は caller フィールドを含むツールリクエストを受け取って結果を返し、その結果はモデルではなくスクリプトによって処理され、スクリプトの最終出力だけが Claude のコンテキストに入る。Anthropic の動機は、従来のツール呼び出しに起因するとする 2 つの問題、すなわち中間結果によるコンテキストの汚染と、呼び出しごとに 1 回のモデルパスを要したうえで自然言語で統合するという推論のオーバーヘッドである。Anthropic は、複雑なリサーチタスクにおける平均トークン使用量が 43,588 から 27,297 へと 37% 減少したこと、多数の呼び出しが 1 つのコードブロックで実行される場合に推論パスが減ること、社内の知識検索（25.6% から 28.5%）と GIA ベンチマーク（46.5% から 51.2%）で精度が向上したことを報告しており、Claude for Excel がこの機能を使って数千行のスプレッドシートを読み取り、変更していると述べている。
研究での用法
この用語は ツール呼び出しの苦い教訓 でも使われており、同論文はこれを、JSON のツール呼び出しを実行可能なコードで置き換えるという主張を拡張するものと説明している。この研究の流れには CodeAct が含まれる。同論文の実装では、ツールは型付きの Python スタブとして公開される。システムプロンプトには、利用可能な関数スキーマと一対一に対応する関数を持つスタブモジュールのソースが埋め込まれ、モデルはそのモジュールをインポートして必要な関数を呼び出すスクリプトを 1 つ書き、エージェントループはそれをシェルのサブプロセスで実行してその出力から結果を読み取る。サブプロセスが戻った後にさらなる推論ターンは発生しない。
適用される場面
どちらの情報源も、これをあらゆる場合に従来のツール呼び出しを置き換えるものではなく、トレードオフとして扱っている。Anthropic は、最も効果が大きいのは、集約値だけが必要な大規模データセットの処理、依存関係のあるツール呼び出しが 3 つ以上あるワークフロー、モデルが見る前に結果をフィルタリングまたは変換する場合、中間データがモデルの推論に影響すべきでないタスク、そして多数の項目にわたる並列操作であり、効果が小さいのは、単一ツールの呼び出し、モデルがすべての中間結果を見てそれについて推論すべきタスク、そして応答が小さい手早い参照だと説明している。モデルが正しいパース用コードを書けるようにツールの戻り値の形式を明確に文書化すること、そして並列に実行できるツールや再試行しても安全なツールをオプトインすることを推奨している。その数値は Anthropic 自身の社内テストによるものである。
論文の主張は、すでに実行可能なコードを書けるモデルにとって、呼び出しごとに JSON オブジェクトを出力することは必然ではなく設計上の選択だ、というものである。これは、モデルのスクリプトを実行できる実行環境と、有効な複数行のコードを生成できるモデルを前提としている。論文の評価では、OpenAI の旧モデル 3 つが改行の代わりにリテラルの \n エスケープシーケンスを書き、それぞれの JSON ベースラインを大きく下回った一方、Anthropic の 5 つのモデルすべてと最新の GPT-5.6 系のバリアントは、それぞれのベースラインと同等かそれを上回った。論文が報告するその他のコストとしては、システムプロンプトに固定のオーバーヘッドがあるため、並列呼び出しがおよそ 26 回未満では JSON ツール呼び出しよりも高くつくこと、そして一部のモデルが実際に呼び出しを実行せずにパラメトリックな知識から集約の質問に答えてしまう傾向があることが挙げられている。
その証拠基盤は、あるベンダーの社内測定と、1 つの統制された比較である。後者は、Berkeley Function Calling Leaderboard（BFCL） v4 のサブセットで 14 のモデルを対象とした単一の研究であり、そのスタブは実際の API を呼び出すのではなく引数をそのまま返すため、エンドツーエンドのツール利用ではなく引数のシリアライズを測定している。この証拠に基づき、論文は、14 モデル中 11 モデルでこれが JSON ツール呼び出しと同等かそれを上回ったこと、Claude Sonnet 5 で JSON ツール呼び出しに見られた呼び出し脱落のしきい値なしに大規模な並列展開を処理できたこと、そしておとりのスキーマがコンテキストにあふれても安定していたことを見出している。