「The Bitter Lesson of Tool Calling」論文レビュー｜JSON関数呼び出しからProgrammatic Tool Callingへ

この記事でわかること

• 論文「The Bitter Lesson of Tool Calling」の主張と実験条件
• Programmatic Tool Calling(PTC)とJSON方式の技術的な違い
• BFCL v4での主要な数値結果と読み方
• 企業がPTC導入を判断する際のチェックリスト
• 論文が示していない実務リスクと運用上の注意点

3つの要点

• 提案: JSONで関数を列挙する代わりに、型付きPythonスタブを渡し、LLMがコードでツールを呼ぶ。実行結果は単一ターンで返す。
• 改善: BFCL v4で14モデル中11がJSON以上、GPT-5.6系列で+10.6%、並列fan-outで13/14が安定、長文コンテキスト条件でも劣化しない。
• 実務: ツール数が多い、並列呼び出しを多用する、会話履歴が長い業務ほど恩恵が大きい。

従来手法の課題：JSON tool callingで詰まる本番運用

JSONで関数を定義するツール呼び出しは、少数ツール・単発呼び出しでは十分に機能します。しかしツール数が増えるとschemaがコンテキストを圧迫し、精度と応答時間が同時に悪化します。

本番運用でJSON方式が特に苦しくなるのは、次の3つの場面です。

• 数十個のツールを扱うため、schema定義だけで数千トークンを占める
• 並列呼び出しを行いたいが、モデルやAPIバージョンで挙動が変わる
• 会話履歴が長くなるにつれ、schemaの効きが劣化する

これらの弱点は、AIエージェントを企業システムに接続する際に頻繁に現れます。

fan-outは1リクエストで複数ツールを並列呼び出しする形です。JSON方式では、プロトコル依存で再現性が低いと以前から指摘されてきました。

提案手法：ツールをコードとして書く

Programmatic Tool Calling(PTC)は、ツールを関数定義として渡すのではなく、LLMに型付きPython関数の情報を渡し、実行をコード生成でまかなう方式です。

論文が定義するPTCの特徴は次のとおりです。

• ツールは型付きPythonスタブ(引数と戻り値の型のみを持つ関数シグネチャ)として提示される
• LLMは通常のPythonコードとしてツール呼び出しを記述する
• 生成されたコードはサンドボックスで実行され、結果を単一ターンで返す
• チェーン(A→B→Cと順に呼ぶ)、並列fan-out、条件分岐などをコード構文で自然に表現できる

技術的な差分の中心は、ツール呼び出しをプロトコルからプログラムへ移すことです。多ターンのやり取りが不要になり、fan-outの制御はPython側の並列構文に委ねられます。

実験結果：BFCL v4での主要スコア

論文は関数呼び出し能力を測る**BFCL v4(Berkeley Function Calling Leaderboard v4)**を評価軸として用いました。対象は14種類のLLMで、PTCとJSON native tool callingを比較しています。

主要な結果は下表のとおりです。

数値はarXiv版abstractで確認できる範囲に限定しています。個別モデルの詳細スコアは論文本文（arxiv.org/abs/2608.06370）を参照してください。

数値の読み方で重要なのは、PTCが上位モデルかつ長文または並列条件で最も差を広げている点です。ツール数が少なく単発呼び出しが中心の条件では、JSONとの差は小さくなります。

限界と注意点：論文が示していないこと

論文の主張は強力ですが、実務適用にはいくつかの前提条件があります。

論文自体の限界として、次があります。

• BFCL v4という関数呼び出し特化ベンチマーク上の評価であり、業務精度そのものではない
• 14モデル中3モデルではPTCがJSONを下回った(全モデル一律ではない)
• 公開情報からはコードやモデル一覧の公開状況を断定できない
• 日本語プロンプトや国内モデルでの検証は範囲外

実務適用時の注意として、次があります。

• コード生成能力が低いモデルでは効果が限定的または逆効果になり得る
• サンドボックス実行環境が必須で、任意コード実行やインジェクション対策が要る
• 監査ログや権限分離の設計負荷がJSON方式より重い
• 既存のJSON schema資産からの移行コストが発生する

これらは論文が積極的に扱っていない領域です。導入判断の際は自社データを使ったPoC検証を推奨します。

実務への示唆：PTC導入前チェックリスト

企業がJSON tool callingからPTCへの移行を検討する場合、次の5点を先に確認してください。

• 使うLLMはコード生成に十分強いか(GPT-5.6系、Claude Opus 4系、コード特化モデル等)
• 扱うツール数が10個以上、または並列呼び出しが業務要件か
• 会話履歴やコンテキストが長くなりやすい業務か(長時間セッション、ドキュメント分析等)
• Pythonコードをサンドボックスで安全に実行できる基盤があるか
• コード実行を許容できるセキュリティ・監査体制があるか

いずれか1つでもNoが残る場合、まずは既存のJSON方式を維持しつつ、PoCで小規模検証を先行させる判断が現実的です。

Blackfordの見解：モデル選定と一体で判断する

BlackfordのAIエージェント設計案件では、ツール数が5〜10を超えるとJSON schemaの管理コストが跳ね上がる傾向を実務で確認しています。論文の結果は、この体感と整合します。

一方で、PTCはコード生成能力が高いモデル前提の話です。モデル選定と抱き合わせで検討しないと、コード実行基盤だけ整えて精度が上がらない構成になり得ます。

BFCL v4は狭い評価軸のため、自社業務データで応答精度・レイテンシ・コストをA/B比較する段階を必ず挟むべきです。監査ログ・権限分離・サンドボックス設計は、Blackfordが支援する領域です。

関連する社内ナレッジ検索や業務データ活用の観点では、DataRoidによるデータ基盤整備が、PTCで扱うツール群の設計精度を高めます。

よくある質問

PTCとMCP(Model Context Protocol)は何が違いますか？

目的が異なります。MCPはツール定義や接続の共通プロトコル、PTCはLLMがツールを呼ぶ表現形式(JSONではなくコード)の話です。

MCPで提供されたツール群をPTC形式で呼び出す組合せも可能で、両者は排他ではありません。詳しくはMCPのエンタープライズ運用記事を参照してください。

PTCの導入コストは大きいですか？

既存のJSONツール定義をPythonスタブへ移す作業と、コード実行サンドボックスの整備が必要です。特にセキュリティ設計と権限分離が主な工数になります。

既存ツール数が少ないなら移行負荷は限定的ですが、監査要件が厳しい業種では調整に時間がかかります。

論文の結果はどのLLMでも再現できますか？

いいえ。論文はBFCL v4での14モデル評価で、うち3モデルではPTCがJSONを下回りました。

コード生成能力の低いモデルや小型モデルでは、効果が限定的な可能性が高いです。導入前に自社が使うモデルで単発の比較検証を行ってください。

中小企業がすぐにPTCを採用すべきですか？

まず社内で扱うツール数と並列実行の必要性を評価してください。ツール数が少なく単発呼び出しが中心なら、既存のJSON方式で十分に機能します。

ツール数増加、並列fan-out、長文コンテキスト対応が課題化した段階で検討する順序が現実的です。

まとめ：ツール呼び出しの本命はコードか、それともJSONか

論文「The Bitter Lesson of Tool Calling」は、LLMエージェントのツール呼び出しをJSONからProgrammatic Tool Calling(PTC)に切り替えることで、並列・長文条件下でも精度を保てる可能性を示しました。

ただしBFCL v4という単一ベンチマークでの結果であり、モデルによっては効果が出ないケースもあります。導入判断はモデル選定・サンドボックス設計・監査要件と一体で行う必要があります。

Blackfordでは、既存のJSON tool calling運用の設計、PTCへの移行判断、A/B検証まで一気通貫で支援できます。相談したい場合は、以下からお問い合わせください。

Blackfordに相談する