WildToolBench: なぜ現実世界のツール利用においてLLMのセッション精度は15%を超えないのか
私が追跡してきたツール利用のベンチマーク（BFCL、ToolBench、τ-bench）には、共通の設計上の欠陥があります。それは、ベンチマークの作成者が想像したユーザーの行動に基づいてタスクが構築されている点です。ICLR 2026に採択されたWildToolBenchは、実際のユーザーログに立ち返り、ユーザーが実際に何をしているのかを問い直しています。その答えは衝撃的なものでした。評価された57のLLMのうち、セッション精度が15%を超えたモデルは一つもありませんでした。
論文について
AlibabaのPeijie Yu、Wei Liu、Yifan Yang氏らは、WildToolBench (arXiv:2604.06185) を発表しました。これは、本物のユーザー 行動パターンから抽出された1,024のタスクを含む256のマルチターン対話シナリオのベンチマークであり、約1,600のパブリックAPIに基づいています。中心的な主張は、既存のベンチマークが飽和状態にあるのはモデルが優れているからではなく、タスクが人工的だからであるという点です。現実のユーザーはリクエストをひとまとめにし、2ターン前に共有したコンテキストを省略し、ツールの質問、雑談、説明の要求を——時には一つのメッセージ内で——切り替えます。WildToolBenchは、これらの失敗モードを3つの構造化されたチャレンジカテゴリに落とし込み、タスクレベルの精度と、対話内の4つのタスクすべてに成功する必要がある、より厳格なセッションレベルの精度の両方を測定します。
主なアイデア
- ほとんどのモデルでセッション精度が1桁台に崩壊: Gemini-2.0-Flash-Thinkingがセッション精度14.45%で首位、Claude-4-Sonnetが12.50%、GPT-4oが11.72%と続きます。4ターンのセッションで全タスクをクリアするのは非常に難しく、タスク精度が60%あってもセッション精度は15%未満になります。これは、あらゆるやり取りにかかる「複合確率の税金」と言えます。
- 構成的オーケストレーションが最大の難所: 順次実行と並列実行が混在したツールのトポロジーでは、トップモデルでもタスク精度が25%に制限されます。これに対し、純粋な並列または順次チェーンでは54〜62%です。タスクが並 列展開の後に順次マージを必要とする場合、現在のどのモデルも確実に対処できないほど調整問題が深刻化します。
- 隠れた意図は、これまで測定された以上の大きなギャップ: WildToolBenchはタスクの100%に暗示的またはターンを跨ぐ情報が含まれるようにしていますが、BFCL v3ではわずか15.7%です。不足している情報が2ターン以上前にある長期依存タスクは最も困難なサブタイプであり、タスクレベルでさえ50%を超えるモデルはありません。
- 指示の遷移がエラーを線形的に増幅させる: ポリシーの切り替え（ツールタスク → チャット → 明確化の要求 → ツールタスク）が1つ増えるごとに、精度は約5〜15パーセントポイント低下します。3つの遷移が発生すると、最も影響を受けるモデルでは30ポイントも低下します。著者らはこれを「自己条件付け（self-conditioning）」と呼び、過去の回答がその後の指示の解釈に偏りを与え、セッションの途中で修正するのが困難になると指摘しています。
- 最適パス率（Optimal Path Rate）は43%以下: モデルがタスクを正しく完了できたとしても、余計なAPI呼び出しを消費してしまいます。Claude-4-Sonnetが最高の最適パス率42.74%を記録しましたが、これは正しい完了の大部分が必要以上のステップを踏んでいることを意味し、本番システムにおけるレイテンシとトークンコストに直結します。
- ツール利用特化型モデルが汎用フロンティアモデルに劣る: xLAM-2-70BやToolACE2-8Bは、関数名の間違いによるエラー率が30%を超えており、GPT-4oやClaude-4-Sonnetよりも悪い結果となりました。限定的なツール利 用コーパスでのファインチューニングは、野生のユーザー行動への分布シフトに対して、頑健性（ロバストネス）ではなく脆弱性を生んでいるようです。
何が妥当で、何がそうでないか
ベンチマークの設計は、最も重要な部分で強力です。タスク精度とセッション精度の区別は正に適切です。失敗モードの連鎖こそが現実の導入を困難にする要因であり、以前の多くの研究はタスクレベルの数値を報告することでこれを隠蔽していました。3つのチャレンジ分類（構成的オーケストレーション、隠れた意図、指示の遷移）は動機付けが明確で、実証的に裏付けられています。チャレンジタイプごとの性能低下曲線は現実的で顕著です。
弱点はスケールです。256のシナリオから得られた1,024のタスクは、研究成果としては信頼に値しますが、57のモデルを継続的に追跡するリーダーボードとしては薄いと言わざるを得ません。著者らもこれを直接認めており、今後の課題として自動スケーリングパイプラインに言及しています。もう一つの問題は「実際のユーザーログに基づいている」という主張の扱いです。最終的なタスクは一部合成されており、シードパターンからマルチエージェントシステムによって構築され、その後人間のアノテーターによって検証されています。主張は事実に根ざしていますが、データは逐語的な「野生」のものではなく、 「野生にインスパイアされた」ものです。これは15%という天井をどれほど文字通りに解釈すべきかに影響します。生成パイプラインが現実のユーザーが実際には示さないような人為的な困難さを導入している場合、ギャップの一部は縮まる可能性があります。
また、指示遷移の分析をアーキテクチャ上の主張とすることにも懐疑的です。論文はこれを根本的な限界としていますが、RLHFのファインチューニング目標とマルチモーダルなユーザーセッション間のトレーニング分布の不一致の方が、より簡潔な説明（オッカムの剃刀）に思えます。これは構造的な問題ではなく、対処可能な問題です。
なぜこれが金融AIにとって重要なのか
この3つの失敗モードは、実際のユーザーがBeancountの書き込み（ライトバック）エージェントとやり取りする方法とほぼ完璧に一致します。ユーザーが「先月の食費はいくらだった？ついでに今日のホールフーズのレシートを追加しておいて」と言うのは、1つのターンにまとめられた構成的タスクです。続いて「やっぱり42ドルじゃなくて47.23ドルにして、調べ直したから」と言うのは、エージェントがセッション状態を追跡する必要があるパラメータ修正です。さらに「そのカテゴリーは合ってる？」と聞くのは明確化の要求であり、エージェントは今終わったばかりの書き込み操作を再実行 してはいけません。混在型オーケストレーションにおける25%の限界と、指示遷移による30ポイントの低下は、まさに帳簿エージェントが実際のユーザーセッションを処理する際に現れる失敗モードそのものです。
ツール利用特化型モデルが汎用フロンティアモデルに劣るという発見は、特に重要です。Beancount専用のツール呼び出し例を使って、より安価な小型のオープンモデルをファインチューニングすることを検討しているなら、WildToolBenchは「特化が実際のユーザー行動の分布に対する頑健性を犠牲にする可能性がある」という直接的な警告となります。最適パス率の発見も重要です。タスク完了に2倍のAPI呼び出しを行うエージェントは、単に非効率なだけではありません。書き戻し操作において、冗長な中間呼び出しは帳簿を不整合な中間状態にするリスクを孕んでいます。
次に読むべきもの
- ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs (arXiv:2307.16789, ICLR 2024) — WildToolBenchが明示的に対置させている基礎的なトレーニングフレームワーク。その合成評価設計を理解することで、ライブ実行が何を付加するかが明確になります。
- τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains (arXiv:2406.12045) — 現実的なマルチターン・ツール利用に関する最も近い先行研究。τ-benchのリテール/航空ドメインとWildToolBenchのパブリックAPIカバレッジ を比較することで、課題がどれほど一般化されるかがわかります。
- AFlow: Automating Agentic Workflow Generation (arXiv:2410.10762, ICLR 2025 oral) — 指示遷移の問題が、学習データのスケーリングではなく、より優れたエージェントワークフローを自動的に発見することで解決可能であるならば、AFlowはそのための最も信頼できるメカニズムです。
