τ²-bench / τ³-bench 評: カスタマーサービスエージェントを対話ごと採点するシミュレータ
τ-Bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains
ひと目でわかる
- これは何？
- ポリシー、ツール、ユーザーシミュレータの三点でエージェントを評価する MIT ライセンスのベンチマーク。テキストのターン制に加え、v1.0.0 で音声全二重と知識検索ドメインが入った。評価指標の比較可能性がバージョンに強く依存する点が導入時の最大の論点になる。
- 誰に向いている？
- 向いているのは、自前のエージェントを airline / retail / telecom のいずれかのポリシーに沿って定量評価したいチームと、音声全二重や RAG 構成の比較に関心があるチームである。向かないのは、単一のスコアを長期にわたって追跡したい場合と、評価対象がコーディングや検索のような非対話タスクである場合だ。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 4 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
τ-bench が埋めようとしている穴は「正解率」ではなく手順の採点にある
一般的な LLM ベンチマークは、入力に対して期待する出力が一致するかを見る。カスタマーサービスエージェントの失敗はそこでは捉えられない。利用者の目的を聞き出し、社内ポリシーの範囲でツールを呼び、途中で方針を変えながら解決に持っていく。この一連の流れのどこで違反したかが問題になる。τ-bench はこの点を評価対象に据えたシミュレーションフレームワークである。README は各ドメインが「エージェントが従うべきポリシー」「エージェントが使えるツール」「評価対象のタスク」を定義し、任意でユーザーシミュレータ用のユーザーツールも持つと説明している。読み手として想定されているのは、エージェントをこれから作る開発者と、モデルやプロンプトの変更が対話品質に与える影響を測りたい評価担当者である。
ポリシー、ツール、ユーザーシミュレータの三者が噛み合う評価ループ
構成は素直である。ドメインがポリシーとツール群とタスク群を持ち、エージェント役の LLM とユーザー役の LLM がオーケストレータの下で対話する。ユーザー側にもツールが必要なドメインでは user tools を定義できる。評価は evaluation_criteria.actions を基準に行われ、reward_basis が報酬の入口を制御する。この二つの関係は docs/evaluation.md に切り出されており、何をもって正解とするかがタスク定義側に寄っているのが分かる。テキストモードは half-duplex のターン制で、ツール呼び出しを挟みながら交互に発話する。v1.0.0 で入った音声モードは full-duplex、つまり同時発話で、OpenAI、Gemini、xAI のリアルタイム系プロバイダを通す。同じドメイン定義を別の通信モードで走らせられる構造になっている点が、テキストと音声を別々のベンチマークで測る場合との違いである。
uv sync と extras で機能を段階的に足す
インストールは pip install -e . ではなく uv に移っている。Python は 3.12 以上 3.14 未満が必須で、以前の 3.10 以上から引き上げられた。手順は README にそのまま載っている。git clone の後、uv sync でコアのみ、つまり mock、airline、retail、telecom のテキスト評価が動く状態になる。音声は uv sync --extra voice、banking_knowledge は uv sync --extra knowledge、gymnasium 経由の強化学習インタフェースは uv sync --extra gym、pytest と ruff と pre-commit は uv sync --extra dev、全部入りは uv sync --all-extras である。API キーは .env.example を .env にコピーして書く。LiteLLM 経由なので対応プロバイダなら何でもよいと README は述べている。実行は tau2 run --domain airline --agent-llm gpt-4.1 --user-llm gpt-4.1 --num-trials 1 --num-tasks 5 のような形で、結果は data/simulations/ に保存され、tau2 view で閲覧する。全体像は tau2 intro で確認できる。音声を使う場合は macOS で brew install portaudio ffmpeg といったシステム依存も必要になる。
採点の修正がスコアの互換性を断ち切る
このプロジェクトで最も見落とされやすいのは、モデル側ではなくベンチマーク側の更新がスコアを動かす点だ。v1.0.1 のリリースノートは banking_knowledge のタスク誤りを修正したと述べており、そのドメインのスコアは結果として変わる。README は tau2-bench 1.0.1 未満で出した結果は 1.0.1 以上と比較できないと明記し、影響を受けたリーダーボード提出は再採点されたとしている。過去の結果ファイルは tau2 evaluate-trajs --fresh-tasks で再採点でき、修正前の挙動を再現したい場合は pre-v1.0.1 タグに固定する。他のドメインは影響を受けない。v1.0.0 では 75 件以上のタスク修正が airline、retail、banking に入っており、SABER と呼ぶ分析に基づくと説明されている。つまり、ある時点で取った数値をそのまま社内の基準線として残すと、後から同じ条件で再現できなくなる。評価パイプラインを組むなら、ベンチマークのバージョンを結果と一緒に記録する仕組みを最初から入れておく必要がある。
音声全二重と知識検索は別の前提を要求する
v1.0.0 で追加された二つの機能は、コアのテキスト評価とは前提が異なる。音声の full-duplex は同時発話を扱うため、リアルタイム系 API のレイテンシや割り込みの挙動が評価結果に混ざる。テキストのターン制で測ったエージェント能力とは別のものを測っていると考えたほうがよい。banking_knowledge は検索拡張生成の構成を評価対象に含み、ドキュメント検索、埋め込み、エージェントによるシェルベース検索を設定可能なパイプラインとして扱う。ここでのスコアはエージェントの推論だけでなく検索側の設定にも依存する。どちらも extras を分けてインストールする設計になっており、コアだけを使う分にはこれらの依存を引かない。逆に言えば、音声や知識検索の結果をテキストドメインの結果と並べて単純比較するのは、測定条件が違うものを同じ表に載せる作業になる。
向かない用途と、評価軸を分けた代替の考え方
τ-bench が答えを出すのは、ポリシーに従った対話とツール操作ができるかである。コーディング、検索、長文生成のような非対話タスクの能力を測る道具ではない。また、ユーザーシミュレータも LLM なので、ユーザー役のモデルを変えればタスクの難易度が動く。エージェントだけを差し替えて比較する場合でも、ユーザー側を固定する統制が要る。代替として挙げられるのは SWE-bench のような静的な入出力型のベンチマークである。あちらはリポジトリとテストが与えられ、生成したパッチがテストを通るかで判定する。ユーザーとの多ターン対話もポリシー遵守も評価対象に入らない代わりに、判定が実行結果に閉じており、モデルを変えても採点基準がぶれにくい。τ-bench は逆に、判定基準がタスク定義と採点コードに依存する。どちらが優れているかではなく、対話の手順を測りたいのか、成果物の正しさを測りたいのかで選ぶ。
MIT ライセンスと保守コストの見積もり
ライセンスは MIT で、社内評価への組み込みや改変に大きな制約は置かれていない。ただし MIT が及ぶのはリポジトリ内のコードであって、評価に使うモデルの API 利用条件や、同梱データの扱いまで保証するものではない。この点は法務判断なので、導入前に自組織の基準で確認する必要がある。保守コストとして見ておくべきは、uv と Python のバージョン制約、extras ごとの依存、そしてベンチマーク自体の更新頻度である。v1.0.0 から v1.0.1 までが約 4 か月で、その間に採点の修正が入った。CHANGELOG.md と RELEASE_NOTES.md を追わないままスコアを蓄積すると、比較できない数値が混ざる。逆に、バージョンを固定して運用し、更新時に tau2 evaluate-trajs --fresh-tasks で過去の結果を再採点する手順を決めておけば、この負荷は見積もりやすい。
編集部の結論
向いているのは、自前のエージェントを airline / retail / telecom のいずれかのポリシーに沿って定量評価したいチームと、音声全二重や RAG 構成の比較に関心があるチームである。向かないのは、単一のスコアを長期にわたって追跡したい場合と、評価対象がコーディングや検索のような非対話タスクである場合だ。導入前に確認すべきは、uv と Python 3.12 以上 3.14 未満が用意できるか、そして tau2-bench 1.0.1 未満で出した banking_knowledge のスコアを資産として持っていないかである。後者に該当するなら tau2 evaluate-trajs --fresh-tasks で再採点するか、pre-v1.0.1 タグに固定して過去の数値を再現するかを先に決めておく必要がある。
コミュニティノート