エージェント構築ベンチマークでClaudeが首位、合格率は25%未満

現在、AI モデルはあらゆる種類のエージェントを動かす原動力となっています。コードの作成やデバッグを行うコーディングアシスタントから、問い合わせへの回答、返金処理、予約変更、社内システムとの連携などを行うカスタマーサポートシステムまでです。

しかし、これらのシステム構築において AI の役割がますます重要になる一方で、人間による重要な舵取りも依然として不可欠です。目標の設定、文脈の提供、アーキテクチャの選定、意思決定のレビュー、そして結果のテストなど、人間の関与は欠かせません。

そこで興味深い疑問が生じます。エージェントに「自分自身で別のエージェントを構築せよ」と命じた場合、どのようなことが起こるのでしょうか？

この問いこそが、「Hyper-휏-bench」が探求しようとしている核心です。

Hyper-휏-bench は、AI エージェントが他のエージェントをどの程度構築できるかを問うベンチマークです。

技術ベテランであり、現在の OpenAI 取締役会会長でもある Bret Taylor が共同設立したエンタープライズ AI エージェント企業「Sierra」によって 9 月初旬に作成され、オープンソース化されました。この Hyper-휏-bench は、同社が 2024 年に導入した元の 휏-bench ベンチマークを発展させたものです。

従来の 휏-bench が、完成したエージェントがいかにユーザーと対話し、ツールを活用し、企業のポリシーに従えるかを測定するものだったのに対し、Hyper-휏-bench はその一歩先へ踏み出します。それは、AI 開発者エージェントが、いかにしてそのエージェントをゼロから構築できるかを評価するものです。

現在、シエラの「Ghostwriter」のような他のエージェントの支援を受けて構築されるケースがほとんどです。昨日、シエラは「hyper-휏-bench」（発表時は 휏^휏-bench と表記）をオープンソース化しました。これは、モデルが単にエージェントとして動作するだけでなく、自らエージェントを構築できる能力を測る新しい長期ホライズンの評価基準です。

— Bret Taylor (@btaylor) 2026年9月9日

9月4日に発表された研究論文では、シエラの研究者らが AI モデルとコーディング・ハッチの組み合わせ計 6 パターンをテストしました。その中には、Claude Code で動作する Anthropic のモデルや、Codex で動作する OpenAI のモデル、さらに Kimi Code とオープンソースの「OpenCode」の両方で動作する Moonshot AI の「Kimi K3」が含まれています。

Hyper-휏-bench は、開発者向けエージェントに対して、ドキュメント、議事録、API、コードベースといった模擬的なビジネス環境から重要な資料を提供し、モデルとコストの制約下でカスタマーサポート用エージェントを構築するよう求めます。その後、完成したエージェントは航空会社、小売、通信、銀行などの分野における未見の顧客会話に対してテストされます。具体的なタスクとしては、フライトのキャンセルや手数料への異議申し立てなどがあります。エージェントが正しい情報を提供し、ビジネスの基盤システムで適切な変更を加えられれば合格となります。例えばスコアが 50% の場合、そのシミュレーションの半分においてエージェントが成功したことを意味します。

リーダーボードによると、最も高いパフォーマンスを示したのは、Claude Code で動作する Claude Opus 5 で、23.9% を記録しました。これは Codex で動作する GPT-5.6 Sol の 22% をわずかに上回る結果です。6 つの自律型構成のうち、いずれも 25% を突破することはできませんでした。

imageHyper-τ-bench のパス率、ビルド時間、トークン使用量、サービングコスト（出典：Sierra）

ベンチマークでスコアが低いこと自体は必ずしも問題ではありません。最先端 AI システムを対象としたテストには、改善の余地を残し、システム間の意味のある差異を浮き彫りにできる十分な難易度が求められます。もし最良のモデルがベンチマークを routinely 突破するようになれば、それは進捗を測る指標としての有用性は大きく低下します。

Hyper-τ-bench の初期結果で際立っているのは、右側に示された 82.2% の「Human + AI リファレンス」のバーです。これはすべての自律型開発エージェントよりもはるかに高い数値ですが、この比較には重要な注意点が伴います。

Sierra の研究者である Ben Shi と Keshav Dhandhania が火曜日に発表したブログ記事では、この結果を「深い文脈を持つエンジニアとペアになったモデル」として説明しています。研究論文ではさらに詳しく解説されており、リファレンスエージェントはベンチマークの作成者が最先端モデルと共に手作業で構築したものであり、何より重要なのは、自律型開発エージェントが自ら発見しなければならない真の要件（ground-truth requirements）にアクセスできていた点です。

そのため、「人間によるサポートがあればパフォーマンスが 3 倍以上になった」と読みたくなるかもしれませんが、Sierra はその解釈を警戒しています。82.2% という数値は平均的な人間の性能を測るものではなく、単なる「オラクル・リファレンス（正解を知っている参照）」に過ぎないと注意を促しています。

これらの全体数値は、タスクごとの劇的な差を隠しています。例えば Claude Opus 5 は、小売で 72.8%、航空会社で 55.9%、通信で 48.2% を達成しましたが、銀行業務ではわずか 5.9% に急落しました。GPT-5.6 Sol は銀行業務においてやや好結果を示し、9% を記録しています。このベンチマークの 53 の構築タスクのうち、銀行関連が 35 を占めています。これは圧倒的に情報量の多いドメインであり、そのコーパスには 2,969 の個別のポリシー事実が含まれており、単一のタスクで最大 580 の事実に依存することもあります。

エージェントが劣勢に立たされる領域

全体スコアは完成したエージェントが機能したかどうかを示すだけですが、Sierra は開発者エージェントが構築中に実際に行った行動も調査し、いくつかの recurring な問題を見つけました。具体的には、ビジネス調査を早々に中断したり、情報が不足している際に質問数が少なかったり、完成するエージェントに必要な計算リソースの配分について判断を誤ったり、異なる技術的アプローチを試そうとする意欲が低かったりすることです。

「失敗は人間のエージェント開発者が直面するものと似ています」

重要なのは、研究者らがこれらのミステイクが機械特有のものではないと主張している点です。「失敗は人間のエージェント開発者が直面するものと同じだ」と論文には記されています。この点は結果をより興味深くします。エージェントはコードを書き動作するシステムを組み立てることはできましたが、構築前に十分な情報を集めること、いつ質問すべきかを知ること、そしてすぐに答えに固執せず代替案を探求することといった、馴染み深いエンジニアリングの問題において劣勢に立たされていたのです。

情報収集の難しさは、特に銀行業界で顕著でした。開発用エージェントは利用可能な約1,700件のファイルのうち80件未満しか開かず、関連しそうな文書を探すために検索に過度に依存していました。その結果、完成したエージェントが遵守すべきすべての業務ルールを把握しないまま構築を開始してしまいました。

また、それらのファイルに含まれていない情報をビジネス側から直接問い合わせる機会も十分に活用されていませんでした。記録された実行例全体を通じて、こうした対話によるツール呼び出しは開発用エージェントの全処理のうちわずか0.3%に過ぎませんでした。あるタスクでは、質問をすることで20〜25件の要件を発見できる可能性があったにもかかわらず、エージェントが尋ねたのは4回以下にとどまっていました。Sierraの研究によると、実際に質問することが重要であることが明らかになりました。専門家が手作業で作成した基準モデルのスコアが95%から100%だったタスクにおいて、一切質問しなかった構築物の成功率はわずか5%でした。しかし、1回の質問で15%に、2回の質問では25%まで上昇しています。

コストもまた大きな問題でした。Hyper-τ-benchでは、会話処理中に顧客サービス用エージェントがAIモデルの呼び出しに費やせる金額に上限を設けています。2つの構築案がこの許容範囲を超え（それぞれ3倍と1.3倍）、ペナルティ適用後にスコアは0点となりました。一方で、多くのケースでは逆に予算を使い果たすほど過剰でした。許容範囲内に収まったエージェントの中でさえ、平均的な支出額は利用可能な予算の45%に過ぎませんでした。

開発エージェントが下した技術的な選択にも、他の弱点が浮かび上がりました。どのようなタイプのエージェントを構築するか、それを動かすモデルをどう選ぶか、そして場合によってはベンチマークの隠された部分を解き明かそうとしたかどうかといった点です。

image構築されたエージェントのアーキテクチャ、モデル選択、そして「不正に近い」試行（提供：Sierra）

異なる設計への実験も驚くほど少なかったのです。作成物の 92% が「単一 LLM ツールループ」という構成を採用していました。これは本質的に、1 つの AI モデルが応答するかツールを呼び出すかを繰り返し判断する仕組みです。この選択も重要でした。ある通信事業者の実験では、開発エージェントに対して異なるアーキテクチャを示唆する一文を与えただけで、スコアは 31% から 67% に跳ね上がりました。

「構築されるシステム自体が AI であるため、設計が機能しているかどうかを知る唯一の方法は、実際に実行して、開発者が構築中に決して見ることのないリアルユーザーへの応答を確認することです。」

これは開発エージェントにとって盲点となります。顧客体験を本当に向上させる有力な証拠の一部を見ずに、設計上の判断を下さなければならないからです。

「構築されるシステム自体が AI であるため、設計が機能しているかどうかを知る唯一の方法は、実際に実行して、開発者が構築中に決して見ることのないリアルユーザーへの応答を確認することです」と、Shi と Dhandhania は記しています。

Sierra の結果によると、開発者向けエージェントは、その盲点を十分なテストと反復によって補うことが失敗することが多く、「動く最初の設計」をそのままリリースしてしまう傾向があるようです。

さらに、これらのエージェントは慣れ親しんだモデルを好む傾向も見られました。Codex が構築したエージェントの 96% は OpenAI のモデルを採用している一方、Kimi が生成したビルドではその割合が 13% に過ぎません。Sierra はこのパターンから、開発者向けエージェントは最適な選択肢を検証するのではなく、慣れ親しんだモデルファミリーに安易に依存しがちだと指摘しています。

最後に、研究者たちは開発環境の設定によって 17% から 42% のケースで、「不正に近い」行動が観察されたと記録しました。これは期待されるビジネス要件の発見を試みるという意味ではなく、エージェントがベンチマークの隠されたテストデータを検索したり、採点システムを調べたりする試みを含みます。これらの情報は、システムが単に答えに合わせて構築できないように秘匿されています。Sierra によると、こうした試みのいずれも成功しませんでした。

エージェントがエージェントを作る

AI はエージェント構築において、その役割をますます拡大しています。Microsoft の Copilot Studio や Salesforce の Agentforce Builder といったツールを使えば、人間は自然言語でエージェントの概要を記述するだけで、AI がその背後にあるロジックの多くを自動生成してくれます。

「Ghostwriter」と呼ばれる Sierra の新機能は、さらに一歩進んだ「エージェント構築用エージェント」です。ユーザーは指示書や標準手順書、会話記録、音声録音などを提供することで、Sierra にエージェントの作成や修正、テスト生成、シミュレーション実行、そして発見された問題の解決を任せることができます。ただし最終的な判断権は人間が握っており、Ghostwriter が構築した内容は公開前に必ず表示され、レビューと承認を経てから本番環境へ反映されます。

開発者は、Claude Code や Codex といったコード生成エージェントに対して、「エージェントを作ってください」というより広範なタスクを直接指示することも可能です。しかしこれらのケースでも、依然として人間がビジネスコンテキストの多くを提供し、成功の基準を定義し、最終結果を検証する役割を担っています。

Sierra が示すエージェント開発のプロセスは、その理由を如実に物語っています。Shi と Dhandhania は、企業向けエージェント（人間を対象としたものでも）の開発は、「仕様書を実装する作業」というよりは「研究活動」に近いと指摘しています。

彼らはこう述べています。「要件はマニュアルやサポート資料、スプレッドシート、そして最前線の優秀な担当者の頭の中に散在しているため、仮説を立てて証拠を集め、構築とテストを繰り返すことで、実際にパフォーマンスに効果をもたらす要因（レバー）を特定する必要があります」

この背景こそが、Hyper-휏-bench の結果が興味深い理由です。自律型開発エージェントはコードの記述や動作するシステムの生成には成功しましたが、必要な情報を十分に収集できず、要件が不明確な場合でも質問をほとんど行わず、設計に落ち着く前に試行錯誤を行うことが少なかったのです。

おそらくこれが、Hyper-휏-bench が急成長中のベンチマーク群の中で特筆すべき存在となる理由でしょう。すでに AI はエージェント構築に関わる業務の多くを担い始めています。このベンチマークは、現在なおプロセスを取り巻く人間の指導を大幅に排除した場合に何が起こるかを問うものです。少なくとも現時点での結果は、自律型開発者エージェントが、判断力を要する仕事の難所において依然として苦戦していることを示唆しています。