ツール呼び出しを「JSONではなくコードとして」渡すと何が変わるか

---

TL;DR

• 本命:ツールをコードとして呼ばせるProgrammatic Tool Calling(PTC)が、14モデル中11モデルでJSON tool callingと同等以上、並列ファンアウトでは14モデル中13モデルで同等以上、コンテキスト劣化下では安定という実証研究が出た
• その他:誤情報への「選択的信頼」を測るベンチマーク、ポーカー型エージェント評価を74倍効率化する統計手法、動画LMのイベントカウント失敗、エージェント失敗トラジェクトリの原因特定手法の4本
• 共通するのは「エージェントの信頼性・評価コスト・デバッグ可能性」を測る動きの同時多発。プロダクト化を急ぐより、公式SDKに吸収されるかどうかを見極める週

本命:ツールをコードとして呼ばせる方式が、14モデルの大半でJSON方式と同等以上になった

The Bitter Lesson of Tool Calling は、ツールをコードとして呼び出させるProgrammatic Tool Calling(PTC)と、従来のネイティブJSON tool callingを、14個の言語モデルで確立ベンチマークBFCL v4上で比較した。PTCでは、ツールは型付きPythonスタブとしてモデルに公開され、モデルはコードを書いてそれを呼び出す。実行と結果の受け取りは1回のエージェントターン内で完結する。

結果は、14モデル中11モデルでPTCがJSON tool calling以上の性能。GPT-5.6ファミリーではJSON方式に対し10.6%の改善。並列ファンアウト(複数ツールの同時呼び出し)条件では14モデル中13モデルで同等以上。さらに長いコンテキストによる劣化(context rot)条件下では、JSON tool callingが平均2.3%劣化するのに対し、PTCは安定を保った。

技術的読み

この研究の新規性は、「コードとしてツールを呼ばせる方が柔軟」という実務者の経験則を、確立ベンチマーク・複数モデル世代で体系的に検証した点にある(論文も、これまで体系的な評価は行われていなかったと述べている)。特にcontext rot条件下での安定性は、長時間稼働するエージェントほど効いてくる可能性を示唆する。

ビジネス的読み

ユニットエコノミクス(1回の処理あたりの収益・費用構造)やトークン単価の直接測定は論文にないが、並列ファンアウトとcontext rotでの安定性は、失敗による再試行や人手修正のコストを減らす方向に働きうると読める。一方、この技術選択自体は独自資産になりにくい。コード実行ベースのツール呼び出しをベンダーの公式SDKが標準装備すれば、自前で作り込んだPTC実行基盤はすぐにコモディティ化する。運用負荷の面では、ツールを型付きPythonスタブとして公開する変更は定型化できる可能性があり、対応済みのコード実行基盤があれば横展開しやすいと考えられる。

逆張り・見落とし

「コードとして呼び出す方が柔軟」という見方自体は実務者の経験則に近く、驚きは小さい。この論文の価値は定量的な裏付けにある。見落とされがちなのは、14モデル中3モデルで非改善という点と、BFCL v4以外での検証が論文の範囲外という点で、過度な一般化は禁物。

含意とポジション

新規にエージェント基盤を組む、または作り直すタイミングであれば、PTC方式を既定選択にする価値がある。ただし独自の堀にはなりにくいため、自前でPTC実行系を作り込みすぎず、対応済みのフレームワークがあれば利用するのが妥当。「JSON tool callingが業界標準だから」という理由だけでJSON方式に固執する必要はない。

その他の重要トピック

選択的信頼を測るベンチマークMISTと訓練手法SCOPE

Learning When to Trust via Selective Context Preference Optimization は、言語モデルが外部コンテキストに条件づけて回答する際、誤解を招く1つの信号が正しい答えを誤りに反転させる問題を扱う。素朴な対策(コンテキストへの抵抗を訓練)には隠れた失敗モードがあり、コンテキストを完全無視するモデルは頑健に見えても、コンテキストが信頼できる場面で役に立たない。著者らはこれを「選択的信頼」の問題として再定義し、各項目をclean・misleading・correct-context・irrelevant-contextの4条件で作成する人手注釈ベンチマークMISTと、誤解を招く信号がclean-correctな答えをwrongに反転させる頻度を測るペア指標SC2Wを導入。提案手法SCOPEは、誤解を招く項目だけでなく4条件全てでバランスよくDPOを最適化することで、SC2Wを削減しつつ他条件での精度を維持したと報告している。

技術的には、「疑わせる」訓練が別の失敗(過剰な無視)を生むことを定量化した点が新しい。ビジネス的には、検索拡張やツール結果注入型のエージェントを運用している場合、ノイズの多い外部コンテキストへの耐性は信頼性に直結する領域であり、SC2Wのような指標は自社パイプラインの脆弱性を測る枠組みとして参照できると読める。含意として、自社のRAG・ツール注入型パイプラインで「怪しい入力を疑え」という指示プロンプトだけを対策にしているなら、それ自体が正答を捨てる別のリスクを生みうる。疑わせすぎ・信じすぎ両方向を測る評価軸を持つ価値がある。

ポーカー型エージェント評価を74倍効率化する統計手法AV-AIVAT

AV-AIVAT は、2つのエージェントの強さを判定する評価コスト(金銭・モデル推論・専門家時間)を、逐次的な統計手法で削減する研究。既存のAIVATは不完全情報ゲームの分散を条件付き補正で削減する(15構成・71,439組のHUNLハンドで中央値54倍)が、いつ評価を止めるべきかは示さない。本研究はAIVATと継続監視型の信頼系列(Confidence Sequences)を組み合わせたAV-AIVATを提案し、名目95%水準・目標精度±1BBで、生の結果のみで停止判定するにはAIVAT補正結果に比べ中央値74倍のハンド数が必要と報告している。

技術的には、統計的に正しい信頼水準を保ちながら「証拠が十分になった時点で止める」逐次検定の設計。ビジネス的には、この実証はポーカー(HUNL/Leduc hold’em)という不完全情報ゲームに限定されており、他の領域への適用可能性は論文の範囲では検証されていない。含意として、自社でエージェントのバージョン比較・A/Bテストを固定回数で決め打ちしているなら、「何回で十分か」を逐次的に判定する考え方自体は参照価値があるが、今回の実証結果を直接流用できるわけではない。

動画LMは高頻度の一過性イベントを数えられない

The Low Frequency Trap は、動画LMのイベントカウント能力を、実行可能な正解トレースと突き合わせて検証した研究。跳ねるボールの壁接触・まばたき・カテゴリ的状態遷移という3タスク、2,190本の動画でイベント数と頻度を制御した結果、80%信頼性閾値でGemini 3.6 Flashは持続的な状態遷移を0.5Hzと1.0Hzで12イベントまでは確実にカウントできる一方、一過性のまばたきでは1件以上のイベントを確実にカウントできる領域が存在しなかった。高カウント・高頻度領域では最終カウントの正解率はわずか0.2%、真のイベントの回収率は18.1%にとどまる。サンプリングレートを上げるとBounce Ball精度は19.6%から29.3%に向上するが、報告されたイベント列全体が正解トレースと一致するのは3.7%のみだった。

技術的には、「最終カウントが合っている」ことと「実際に正しいイベント列を回収できている」ことが別物である点(3.7%)が重要で、最終回答だけを採点する既存ベンチマークが動画理解力を過大評価しているリスクを示す。ビジネス的には、動画解析・行動ログ生成のような製品を動画LM単体に任せる設計は、誤検出や見逃しのリスクが高い。含意として、高頻度・一過性イベントの検出が要件に含まれるなら、動画LM単体ではなく決定的な検出ロジックと組み合わせる設計を検討すべきだ。

エージェントの失敗トラジェクトリから真因を特定するTrajDebug

TRAJDEBUG は、LLMエージェントの失敗トラジェクトリの中から、最終的な失敗の原因となった最も早いエラーステップを特定する手法を提案する。長いトラジェクトリでは判断根拠が離れた指示・観測・過去の文脈に散らばり個々のエラーの特定が難しいこと、失敗したトラジェクトリには複数の局所エラーが含まれその一部だけが最終失敗に責任を持つことという2つの課題に対し、多粒度の履歴圧縮・証拠ベースのエラー識別・各エラーの解決状況と最終的な影響の追跡で対応する。Tau2BenchとSWE-Bench Proから486件の手動注釈済み失敗トラジェクトリからなるベンチマークTrajErrBenchを構築し、既存ベースラインに対して最良の総合性能を報告している。コードとデータは公開予定。

技術的には、エラーの「解決されたか」「最終失敗まで影響したか」という経過を追跡する設計が、単純な最初のエラー検出より一段深い。ビジネス的には、エージェント運用の可観測性領域であり、この種の機能がエージェントフレームワークやデバッグツールに標準搭載されれば、自前のトラジェクトリ解析基盤を作り込む意味は薄れる。含意として、自前のエラートリアージ基盤への大規模投資は不要。可観測性はいずれフレームワーク側に標準搭載される公算が高く、自社で手を動かすなら公開予定のTrajErrBenchでの評価に絞るのが妥当。

今週試すなら / 無視していい誇大な期待

今週試すなら、自社のエージェント基盤がJSON tool callingを使っているなら、コード実行ベースのツール呼び出し(PTC)への切り替えコストと効果を小さく検証してみる価値がある。無視していい誇大な期待は、「PTCが銀の弾丸」「動画LMは近く万能になる」という楽観。今回の実測データは、いずれの見方も裏づけていない。