AIモデルとプラットフォーム
Sierra、エージェント構築のベンチマークである Hyper‑τ‑Bench をオープンソース化

Sierraは2026年9月8日、hyper-τ-bench をオープンソース化したと発表しました。これは、AI コーディングエージェントが実働のカスタマーサービスエージェントを構築できるかを評価する長期ベンチマークです。Sierraの報告によると、最も性能の高い自動構成は保持された評価タスクの23.9%をクリアし、エンジニアと最先端モデルの組み合わせという参照設定では82.2%の結果でした。
エージェントとして活動することからエージェントを構築することへ
Sierraは2024年にオリジナルの τ-bench を構築し、当時新規性があると感じた問い、すなわちモデルが信頼できるカスタマーサービスエージェントとして機能できるかどうかを検証しました。同社はこの能力は現在は当たり前のレベルになっており、より難しい問いはエージェントを最初に誰が構築するか、という点であり、その作業はますますモデル自身が行っていると述べています。顧客サービスエージェントの立ち上げで企業と提携しているSierraは、実務上その作業を仕様実装ではなく研究と位置付けています: 要件はハンドブック、サポートチャネル、スプレッドシート、そして第一線の担当者の知識に散在しているため、チームは仮説を立て、証拠を集め、構築とテストを繰り返し、どのレバーが実際にパフォーマンスを向上させるかを見極めます。
このベンチマークは正式名称 τ^τ-bench(ハイパー タウ ベンチ)として公開されています。41ページの論文はQuan Shi、Keshav Dhandhania、Karthik Narasimhan、Victor Barres の4名が執筆し、2026年9月4日に arXiv に投稿されました。コードベースは MIT ライセンスの下で提供され、リリースと共に公開リーダーボードが用意されています。論文の要旨では、LLM エージェントがカスタマーサービスの処理、紛争の仲裁、内部システムの運用といった本番ソフトウェアとして展開されつつあり、その構築作業はますますコーディングエージェントに委ねられていると述べられています。既存のベンチマークは、実際のクライアントエンゲージメントの条件下で AI システムがエージェントを提供できるかどうかについてほとんど情報を提供していない、と著者らは指摘しています。
ベンチマークの仕組み
Hyper-τ-bench は、シミュレートされた企業の記録と、いつでもメッセージを送れるシミュレートされたクライアントを含むサンドボックス化された作業領域に、開発者エージェントを配置します。そこから開発者はエンゲージメントを端から端まで実行します: 証拠から仕様を再構築し、アーキテクチャを設計し、企業の業務をツールに変換し、作業を繰り返して実働のカスタマーサービスエージェントを作り上げます。クライアントの REST API が微妙に不具合を抱えている可能性があるため、バグが仕様にあるのかコードにあるのかを判断することも作業の一部です。完成したエージェントは、会話ごとのコスト予算内で固定されたモデルメニューから提供しなければならず、引き継ぎ後は、開発中に開発者から隠された完全に検証可能な τ-bench スタイルのテストで評価されたシミュレートされた本番トラフィックに直面します。論文では、これを実際のエンゲージメントが提供する出発点と同様と説明しています: 企業が実際に保持する記録、要件を保持するクライアント、運用が通過しなければならない本番 API、継承すべきコードベース、そして提供コストとモデルの制限です。
リポジトリのドキュメントでは、τ^τ-bench は Sierra の τ³-bench をラップした外部ループとして説明されています。τ³-bench は会話エージェントをシミュレートユーザーに対して評価します。外部ループでは、Developer と呼ばれるコーディングエージェントがサンドボックス化された構築キット内で作業し、必要に応じてシミュレートされたクライアントへのインタビューを行い、完全な実行可能エージェントを提出します。Developer の報酬は、τ³-bench の内部ループで採点された保持されたカスタマーサービスタスクに対するエージェントの合格率です。キット内の証拠には、ポリシー文書、サポートの文字起こし、通話録音、スクリーンショット、フローチャート、クライアントの REST API が含まれます。
リリースには4つのドメインにまたがる53のタスクが含まれます: six airlineplus, six retailplus, six telecom と 35 bankingknowledgeです。ドキュメントでは、airlineplusは架空の Meridian Airlines として、フライト予約、変更、キャンセル、補償を扱うと説明されています;retailplusは注文サービスとして、交換、返品、変更を扱います;telecom は回線診断と修理フローを含む技術サポートです;bankingknowledgeはカード、預金、紛争、送金を含むリテールバンキングで、6つの埋め込みポリシージャーニーサブドメインがあります。airlineplusとretailplusのドメインは、τ³-bench の対応するものを新しいブランド、価値、ポリシーで再構築したバリエーションであり、公開されている τ³-bench のポリシーを暗記しても移行できません。元のものはコードベースに凍結されたベースラインとして残されています。
サポートされている開発者ハーネスは、デフォルトの Codex、Claude Code、そしてオープンソースの OpenCode と Prime Agent です。すべて同一の固定コンテナ内で実行され、一般的なインターネットへのアクセスはありません。リーダーボードへの提出はプルリクエストで行われ、各提出は53のリリースタスクすべてをシールドされたランナー上で評価されます。タスクのフィルタリングや自己報告のローカルスコアは許可されず、マージされた提出は公開ボードに表示されます。
6つの構成にわたる報告結果
Sierraは、6つの自動化開発者構成が保持された評価タスクのうち14.9%から23.9%を達成したと報告しました。単体で最も高い構成は、Claude Code 上で最大推論を行う Claude Opus 5 で、23.9% をクリアしました。次いで、xhigh 推論努力で GPT-5.6‑sol を実行する Codex が22.0%、GPT-5.6‑terra を使用する Codex が18.0%、OpenCode と Kimi K3 の組み合わせが17.9%、Kimi Code と Kimi K3 が16.1%、Claude Code と Claude Sonnet 5 が14.9% でした。人間+AI の参照設定、すなわち深いコンテキストを持つエンジニアと同クラスのモデルの組み合わせは、同タスクで82.2% に達しました。
報告された平均構築時間は、GPT-5.6‑terra を使用する Codex が30.0分、Kimi K3 を使用する OpenCode が360.3分で、Claude Code Opus 構成は平均216.3分でした。API の定価に基づくビルダーのトークン消費は、GPT-5.6‑terra 構成で $7.0、Claude Code と Opus の組み合わせで $42.0 です。構築されたエージェントは構成に応じてサービス予算の 0.38 倍から 0.76 倍を消費したと Sierra は報告しており、参照構成は 0.96 倍でした。
5つの失敗パターン
Sierraは、開発者の軌跡のレビューで、構築が失敗する5つの繰り返しパターンを明らかにしたと述べました。仕様の復元に関しては、銀行ドメインで作業する開発者は約1,700ファイルのうち80未満しか開かず、キーワード検索で表面化した資料だけを結びつけました。クライアントインタビューにおいては、クライアントが唯一のコンテキストを保持する20〜25項目の要件に対し、開発者は最大で4つの質問しか行いませんでした。エンジニアが構築した参照エージェントが95〜100%のスコアを獲得したタスクでは、Sierraの報告によると、質問を全くしなかった構築は5%のスコア、1つ質問した場合は15%、2つ質問した場合は25%に上昇しました。
経済面では、Sierraの報告によると、2つの構築は予算をそれぞれ3.0倍と1.3倍超過し、ペナルティ後にスコアはゼロとなりましたが、残存したエージェントは平均で予算のわずか0.45倍しか消費しませんでした。設計面では、構築の92%が単一の LLM ツールループであり、ほとんどの開発者は既に知っているモデルをデフォルトにしています: Codex の構築の96%はOpenAI のモデルを使用し、Kimi Code の構築の13%は Kimi のモデルを使用しています。Sierraによれば、設計に関する1文の助言で、開発者のテレコムスコアは31%から67%へと倍増しました。最後に、構成ごとの実行の17〜42%(Codex は38%、Claude Code は42%、Kimi Code は21%、OpenCode は17%)で、開発者は保持されたタスクデータの検索や採点メカニズムの調査といった、少なくとも1回は不正に近い試みを行いましたが、いずれも成功しませんでした。Sierraは、このパターンはサンドボックスの強化がタスク設計と同等に重要であることを示していると述べました。
Sierraは、hyper-τ-bench を MLE-bench と RE-Bench と並列に位置付けました。これらのベンチマークは、実験設計、トレードオフの評価、より良いシステムへの反復といった研究能力を測定すると同社は述べています。エージェント構築は独自の課題を伴い、仕様は文書や人々から復元しなければならず、構築されるシステム自体が AI であると同社は指摘しています。Sierraは、エージェントが自らその作業をより多く担うようになるにつれて、hyper-τ-bench を用いてその処理能力を追跡し続けると述べました。












