τ²-bench：対話型AIエージェントにおけるデュアルコントロールのコストを測定する

ここ数週間、τ-bench シリーズを読み進めてきましたが、τ²-bench (arXiv:2506.07982) はまさに私が待ち望んでいた論文です。これは、ユーザーが単なる受動的な情報提供者ではなく、独自のツールセットを持つ能動的な参加者である場合に何が起こるかを、ついに問いかけています。対話型の会計エージェントを構築している人にとって、そのギャップは常に顕著なものでした。

論文の概要

Victor Barres、Honghua Dong、Soham Ray、Xujie Si、Karthik Narasimhan（Sierra AI およびトロント大学）は、元の τ-bench の直接的な拡張として τ²-bench を導入しました。中心的な考察は、従来の対話型 AI エージェント向けのベンチマークが「シングルコントロール」であるという点です。つまり、エージェントのみがツールを呼び出すことができ、ユーザーは自然言語のメッセージに限定されていました。現実世界のテクニカルサポートはこの前提を覆します。カスタマーサービスのエージェントが「機内モードをオフにしてください」と言ったとき、あなたは単に自分の好みを語っているのではなく、自分のデバイス上でツール呼び出しを実行しているのです。

著者らはこれを「分散部分観測マルコフ決定過程（Dec-POMDP）」としてモデル化しました。ここでは、エージェントとユーザーシミュレーターの両方が、共有された動的な世界の状態に対して異なるアクションスペース（関数呼び出しとメッセージ）を持っています。エージェント側は標準的な CRM のように見えます。顧客記録の検索、ローミングの有効化、SIM の交換などが可能です。ユーザー側は、読み取りツール（get_status_bar、get_sim_status）と書き込みツール（toggle_airplane_mode、toggle_data、reseat_sim_card）を備えた模擬電話です。このベンチマークには、新しいテレコムドメイン（プログラムによって生成された 2,285 のバリアントからサンプリングされた 114 のタスク）に加えて、元の τ-bench からの検証済みリテール（115 タスク）および航空（50 タスク）ドメインが含まれています。

主なアイデア

• デュアルコントロールの定式化: Dec-POMDP による表現は、各プレイヤーが何を観察し、どのツールを呼び出せるかを明確に分離します。これは、既存のシングルエージェントの仕組みに無理やり付け足したようなアドホックな「電話を持つユーザー」よりも厳密です。
• 構成的なタスクジェネレーター: タスクは、3 つのインテントタイプ（service_issue、mobile_data_issue、mms_issue）をカバーする 15 の原子的サブタスクグループから組み立てられ、解決に必要なステップ数によって難易度が明示的にスケーリングされます。
• テレコムドメインでのパフォーマンス (pass¹): GPT-4.1 はわずか 34%、o4-mini は 42%、Claude 3.7 Sonnet は 49%、GPT-4.1-mini は約 50% でした。すべてのモデルにおいて、リテールや航空ドメインよりも大幅に低いスコアとなりました。
• デュアルコントロールのペナルティ: ユーザーがツールを持つ「Default」モードと、エージェントがすべてのツールを自分で制御する「No-User」モードを比較するアブレーション調査が行われました。GPT-4.1 は 18 ポイント、o4-mini は 25 ポイント低下しました。この差は、純粋な推論の難しさとは切り離された、能動的なユーザーとの調整にかかるコストです。
• オラクルプランとのギャップ: エージェントにあらかじめ完全なアクションシーケンスが与えられた場合でも、パフォーマンスは 100% に達しません。これは、プランニング以上に、実行とユーザーとの調整においてエラーが加わることを示しています。
• 構造化されたユーザーツールがシミュレーターのノイズを劇的に削減: テレコムのユーザーシミュレーターにおけるエラーはわずか 16%（致命的なものは 6%）であり、元の τ-bench のリテールにおけるエラー 40%（致命的なものは 12%）と比較して大幅に改善されました。この改善は、自由な自然言語によるユーザープロンプトを、デバイスの状態を追跡する厳密に制限されたツールインターフェースに置き換えたことによるものです。

評価できる点と課題

Dec-POMDP の枠組みは、エージェントのベンチマーキングにおいて私がこれまで見てきた中で最も入念な問題定式化の一つです。プログラムによるタスクジェネレーターは非常に有用です。多くのベンチマークを悩ませている手作りのタスク集とは異なり、証明可能で正しいタスクと明示的に制御可能な複雑さを提供します。ユーザーシミュレーターの信頼性に関する数値も説得力があります。評価信号を信頼しようとする際、致命的なエラーを 12% から 6% に削減できることは大きな意味を持ちます。

とはいえ、テレコムドメインは範囲が狭いです。4 人の顧客、9 つの回線、5 つのプラン。これは管理された実験室であって、エンタープライズシステムではありません。gpt-4.1-mini や Claude 3.7 Sonnet の pass¹ の数値（約 50%）は、著者らがドメインの難しさを強調している割には驚くほど高く見えます。114 のタスクという数が、運によるスコアの底上げを避けるのに十分かどうか疑問が残ります。著者らもタスクセットがサブサンプルであることを認めています。また、ユーザーペルソナの分析も薄いと感じます。論文では「難しい」ペルソナ（技術的な自信が低い 64 歳の退職者）が「易しい」ペルソナよりも困難であることを示していますが、これは驚くことではありません。私が知りたいのは、調整の失敗の「タイプ」が異なるかどうかです。難しいペルソナは、より多くの推論エラーを引き起こすのか、それともコミュニケーションエラーを引き起こすのでしょうか。

また、本論文では、エージェントのポリシー文書が間違っていたり不完全であったりした場合に何が起こるかについては調査されていません。これは本番環境への導入においては現実的なシナリオです。すべての結果は、エージェントに正確なポリシーが与えられていることを前提としています。

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

τ-bench、WorkArena、およびほとんどのタスク指向型対話ベンチマークに組み込まれているシングルコントロールの前提は、実際の Beancount サポートのシナリオにはうまく適合しません。Beancount エージェントに台帳の修正を依頼するユーザーは、単に問題を説明しているだけではありません。テキストエディタでファイルを同時に編集したり、bean-check を実行したり、銀行から新しい CSV エクスポートをアップロードしたりしている可能性があります。これはまさに τ²-bench が示す意味でのデュアルコントロール環境です。

No-User モードから Default モードに移行した際の 18〜25 ポイントの低下という数値は、今後も念頭に置くべきものです。これは、自律的な台帳操作においてほぼ完璧な Beancount エージェントを構築したとしても、書き込み権限を共有する能動的なユーザーを介在させると、成功率が約 4 分の 1 低下することを示唆しています。私たちが検討してきた安全な書き戻し設計（GuardAgent、ShieldAgent、検証可能な MCP）は、シングルコントロール設定を想定して設計されていました。ユーザーも同じ環境に対してツールを呼び出すエージェントであるならば、これらは再考の必要があります。

ユーザーシミュレーターの信頼性向上も、直接活用できる知見です。人間の会計士を募集することなく Beancount エージェントのオフライン評価を行いたい場合、自由形式の LLM ロールプレイに頼るのではなく、シミュレートされたユーザーを決定論的な台帳環境に密接に結合させることが、エンジニアリングとして正しい選択です。

次に読むべきもの

• τ-bench (Yao et al., arXiv:2406.12045): これが拡張したベースライン。τ²-bench の結果を解釈する前に、元のタスク構築と pass^k メトリクスの設計を読んでおく価値があります。
• ToolSandbox (Lu et al., arXiv:2408.04682): 詳細なエージェント評価のためのステートフル（状態保持型）ツールを導入。デュアルコントロールの Beancount テストハーネスを設計する上で最も関連性の高いアーキテクチャです。
• TheAgentCompany (Xu et al., arXiv:2412.14161): 実際の社内ツールを備えた模擬ソフトウェア企業内での 175 のタスク。現在利用可能な中で最も現実的なエンタープライズ自動化ベンチマークであり、私の読書リストの次の論文です。