τ-bench: 実世界のツール使用ドメインにおけるAIエージェントの信頼性の測定

数週間にわたりテーブル推論やtext-to-SQLの系譜を追ってきた後、少し視点を変えて、実際のユーザーとの運用ループに投入された際、現在のエージェントが実際にどの程度のパフォーマンスを発揮するのかという疑問を抱きました。τ-benchは私がこれまで見てきた中で最も正直な回答を提示しており、その数値は身が引き締まるものです。

論文の概要

プリンストン大学とSierra ResearchのYao、Shinn、Razavi、Narasimhanらは、後から考えれば明白な欠落を埋めるためにτ-bench（arXiv:2406.12045、2024年6月）をリリースしました。従来の多くのエージェントベンチマークは、モデルにタスクを渡し、その最終回答を単独で評価するものでした。しかし、実際のデプロイメントはそうではありません。カスタマーサービスエージェントは、中断されたり、追加の質問をされたり、矛盾する情報を渡されたりします。そして、データベースを変更する前に、自由形式の会話を通じてビジネスプロセスやポリシーを遵守することが求められます。

τ-benchは、小売と航空という2つの実世界のカスタマーサービスドメインをシミュレーション環境に統合し、言語モデルがユーザー役、別のモデルがエージェント役を務めます。エージェントは、ドメイン固有のAPI（注文のキャンセル、座席の変更、クーポンの適用）と、どのような条件下でどのアクションが許可されるかを規定したポリシー文書にアクセスできます。評価では中間ステップのスコアリングは行わず、最終的なデータベースの状態をアノテーションされたゴール状態と比較します。また、著者らは、同じタスクに対してk回の独立した試行を行い、エージェントがどれだけ「一貫して」成功したかの割合を示す信頼性指標「pass^k」を導入しました。

主要なアイデア

• 誠実な指標としてのpass^k: 1回の成功率（pass@1）だけではノイズが多すぎます。pass^kは、同じタスクをk回再実行した際に「すべて」で成功する確率を明らかにします。これは、プロダクション環境でそのエージェントを信頼できるかどうかの代用指標となります。
• 一貫性の急落（Consistency Cliff）: 小売ドメインにおけるGPT-4oのスコアは、pass@1では0.604ですが、pass@4では0.383まで低下します。これは、タスクの約60%において、4回の試行のうち少なくとも1回は失敗することを意味し、プロダクション環境で安全に運用できるエージェントとは言い難い結果です。
• 航空ドメインは小売よりも困難: GPT-4oのpass@1は、小売の0.604から航空の0.420に低下します。Claude 3.5 Sonnet（2024年10月版）はより優れており、pass@1では小売0.692 / 航空0.460を記録していますが、pass@4ではそれぞれ0.462と0.225にまで低下します。
• 関数呼び出しはReActに勝る: GPT-4oの関数呼び出しバリアント（航空ドメインでpass@1 = 0.420）は、同じバックボーンを使用したAct（0.365）やReAct（0.325）を上回りました。これは、構造化されたツールAPIがフォーマットに起因する失敗を減少させることを示唆しています。
• ユーザーシミュレーションという変数: 著者らは言語モデルを使用してユーザーをシミュレートしていますが、これ自体が分散の原因となります。弱いユーザーシミュレーターは、敵対的なユーザー行動をどれだけ忠実に再現するかに応じて、エージェントのスコアを不当に下げたり上げたりする可能性があります。
• データベース状態による評価が部分点稼ぎを回避する: 対話ステップではなく最終状態を比較するということは、正しいアクションを実行した後に誤ってそれを取り消したエージェントには点数が与えられないことを意味します。これは書き戻しシステム（Write-back system）にとって正しい判断です。

評価できる点とそうでない点

pass^kという枠組みは極めて有用であり、この特定のベンチマークを超えて活用されると期待しています。トークンレベルの類似性ではなくデータベースの状態で評価するという決定は正解です。これはエージェントが適切な発言をしたかではなく、タスクを完遂したかを直接測定します。

しかし、ドメインは意図的に限定されています。小売と航空は手続き的に整理されており、ポリシー文書はベンチマーク用に作成された有限のもので、APIは小規模で明確に定義されています。実世界のポリシー文書は曖昧であり、実際のユーザーは嘘をつき、記憶を誤り、拒否に対して反論します。ベンチマークの著者もこれを認めています。続編であるτ²-bench（arXiv:2506.07982）の存在自体が、ユーザーも環境状態を操作する二重制御のDec-POMDPモデルへと拡張されており、単一制御の評価では難易度を過小評価していることを認めています。

また、pass^kが実際に何を測定しているのかという疑問もあります。ユーザーシミュレーション自体が確率的である場合、k回の試行における分散は、エージェントの不整合とシミュレーターの不整合を混同させてしまいます。論文はこの点に言及していますが、2つの分散源を完全には分離できていません。安全性が重要なアプリケーションでは、失敗の原因を特定したいはずです。エージェントがポリシーを無視しているのか、ユーザーの意図を読み違えているのか、あるいは単にツール呼び出しのフォーマットを間違えているだけなのか。

llm-stats.comのリーダーボードでは、Step-3.5-Flashのようなモデルが0.882を記録していますが、評価設定が変化している可能性に注意が必要です。新しいエントリーは異なるユーザーシミュレーターのバージョンや、おそらく異なるタスク分割の下でスコアリングされているようです。進化し続けるベンチマーク上でのエントリー間の比較には常に慎重であるべきです。

なぜこれが金融AIにとって重要なのか

私が構想しているBeancount書き戻しエージェントは、τ-benchが評価しているエージェントと構造的に同一です。ドメイン固有のツール（トランザクションの追加、残高の修正、項目の再分類）、ポリシー制約（クローズされた期間を変更しない、負の残高を作成しない、勘定科目表に従う）、そして数ターンにわたる会話を通じて自然言語で指示を出すユーザーが存在します。

pass^kに関する発見は、我々にとって最も実行可能な知見です。比較的寛容なドメインである小売において、Claude 3.5 Sonnetのような最先端モデルのpass@4がわずか0.462であるならば、台帳の書き戻しにおいても同様かそれ以下の整合性しか期待できません。台帳ではミスが複数のトランザクションにわたって連鎖し、ポリシー違反がすぐには見えない場合もあります。

最初からk回の試行における一貫性を考慮して設計することは、アーキテクチャを変えることになります。これは、保守的なツール使用（書き込む前に確認する）、API呼び出し前の明示的なポリシーチェック、そしてコミット前に提案されたデータベースの差分（diff）を監査する独立した検証エージェントの必要性を裏付けています。

また、データベース状態による評価手法も直接応用可能です。Beancountの構造化されたファイルフォーマットにより、書き戻しセッション後の期待される元帳の状態と実際の状態の差分を簡単に取得でき、τ-benchが使用しているような客観的な評価シグナルを得ることができます。

次に読むべきもの

• τ²-bench (arXiv:2506.07982): ユーザーもツールを呼び出す二重制御環境へと拡張した続編。ユーザーを単なる受動的な要求者ではなく、台帳修正の能動的な参加者としてモデル化する場合に直接関連します。
• AgentEval / GAIA (arXiv:2311.12983): GAIAベンチマークは、Webブラウジングやツール使用を必要とする実世界のタスクで汎用AIアシスタントを評価します。τ-benchのドメイン特化型の焦点に対する有用な補完となります。
• WorkArena (arXiv:2403.07718): ServiceNowにおける実際のエンタープライズソフトウェアタスクでエージェントを評価します。ドメインは小売や航空よりも会計ワークフローに近く、タスク設計の教訓として読む価値があります。