ReactBench v1 ベンチマーク発表

ReactBench は、現実的な React 開発におけるコーディングエージェントの評価指標です。現在のモデルはベンチマークのテストを通過できますが、本番環境では動作しない React コードを書いてしまうことがあります。従来のテストは振る舞いのみを検証しますが、React のパフォーマンス、アクセシビリティ、コード品質に関する課題を見逃しがちです。

ReactBench が従来と異なる点は以下の通りです。

• 単なるテスト通過以上のハードル

すべての解決策は、行動テストの合格に加え、React Doctor の通過も必須となります。これは React コード向けのオープンソースかつ決定論的な検証ツールで、400 以上のルールが適用されます。これにより、不具合のあるエフェクト、不要な再レンダリング、アクセシビリティの問題、保守性の欠如などが検出されます。

• React の専門家によって構築

当チームは、GitHub や PayPal、Rippling、Airbnb のエンジニアにも利用されている React Doctor（★ 13.8k）、React Scan（★ 21.6k）、Million.js（★ 17.7k）を開発しました。モデルの能力における実際のギャップを測定するため、数百時間をかけてタスクを選定・構成しています。

• 既存コードベースでの現実的な作業

ReactBench はオープンソースのリポジトリや、既存プロジェクトに基づいた現実的な変更に対応します。これは合成されたパズルとは異なります。エージェントは機能の実装と振る舞いの維持に加え、React に特化した品質チェックの達成が求められます。

結果

私たちは、2 つの補完的な能力を評価しています。1 つ目は新機能の実装、2 つ目は既存コードの改善です。

React の機能を実装するか、既存のバグを修正します。その際、事前に用意された動作テストに合格し、新たに React Doctor による問題が発生しないことを検証してください。

例

既存コードの React 関連の失敗箇所をリファクタリングします。元の挙動は維持しつつ、新たな React Doctor の問題は発生させないようにしてください。

例

5 回の試行における pass@1 の平均値を報告します。

スコア順にランキングされています。コストは、各ロールアウトあたりの平均値です。

図 2. 平均ロールアウトコストまたは出力トークン数に対する ReactBench スコア (%)

ReactBench は、主要なモデルにおいてもまだ飽和状態には達していません。XHigh の GPT-5.6 Sol が観測された中で最も高い集計スコア 43.1% を記録しましたが、Claude Fable 5 (XHigh) も 41.2% に達しています。評価された設定全体を通じて、Fable は試行あたりの平均コストが 7.97 ドルであるのに対し、Sol は 1.37 ドルで、約 5.8 倍のコスト差があります。特に XHigh では、Fable のコストは Sol の 6.3 倍に達します。最良の設定であっても、ベンチマークタスクの試行を半分も解決できていないのが現状です。

また、モデル設定間でのタスク識別能力についても評価を行いました。51 タスクからなるパネルにおいて、36 タスク (70.6%) で設定間の標準偏差が 0.10 を上回りました。

品質とコストのバランスを考慮すると、GPT-5.6 Terra (Medium) は 38.0% のスコアを達成しています。これは XHigh の GPT-5.6 Sol よりも 5.1 ポイント低く、出力トークン数を 10.8% 削減し、タスクあたりのコストを 63.2% 抑えています。主要な設定の性能のほとんどを維持しながら、コストは約 3 分の 1 で済むため、高ボリュームのワークロードにおいて最も実用的なトレードオフと言えます。

GPT-5.6 Sol (XHigh) が全体の合格率で最高値を記録しましたが、上位の設定間の差が小さすぎるため、明確な勝者を自信を持って断定することは困難です。

GPT-5.6 Sol: 18.2

Fable 5: 18.7

Opus 4.8: 23.6

GPT-5.6 Terra: 26.7

Sonnet 5: 27.0

GPT-5.6 Luna: 31.6

GLM 5.2: 35.8

Kimi K2.7 Code: 67.4

図 3. 4,455 件の「Write React」トライアル全体で、100 回あたりに導入された新規の graded React Doctor の問題数（モデルファミリー 4 つ分）。

4,455 件の Write React トライアルにおいて、評価対象のモデルが導入した graded React Doctor の問題は合計 1,194 件でした。そのうちバグ（セキュリティ上の発見を含む）は 925 件で全体の 77.5% を占めています。最も頻出する問題としては、リストのレンダリングと Hook の正しさが挙げられます。

検証器による結果分類を見ると、「Write」と「Fix」のタスクでは失敗のパターンが異なります。2,486 件の失敗した Write トライアルのうち、1,623 件（65.3%）は動作テストで失敗しましたが React Doctor では合格していました。一方、3,219 件の失敗した Fix トライアルのうち、1,956 件（60.8%）は動作には問題なかったものの、React Doctor で不合格となりました。

Write タスクの失敗は主に要求された動作に起因し、Fix タスクの失敗は主に未解決の React の問題に起因します。

結果を探索する

なぜ ReactBench を構築したのか

React は現在、フロントエンドフレームワークとして圧倒的なシェアを持ち、コーディングエージェントにとって最も人気のあるターゲットです。JavaScript フレームワークを採用して構築されたウェブサイトの約 70% が React を選択しています。

私たちはそのリスクを肌で感じてきました。React Doctor は PayPal、Rippling、Polymarket、米国疾病予防管理センター（CDC）のエンジニアが活用しているオープンソースツールで、React の問題をスキャンするために使用されています。このツールの採用が進んだ背景には、モデル生成コードの増加により、微妙な欠陥が生産環境に到達しやすくなったという事情があります。モデルがより多くの React コードを生成するようになると、些細なミスも巨大な規模で増幅・伝播してしまいます。最悪の場合、これらの欠陥は生産環境での障害を引き起こします：

「useEffect」の誤用が本番環境をダウンさせる事例があります。Cloudflare は 2025 年 9 月のダッシュボードおよび API の障害について、不良な依存関係を持つ 1 つの effect が原因であると特定しました。人的レビューとテストを経ても、このバグは本番環境にデプロイされてしまいました。

ReactBench の構築

各タスクタイプには、異なる構成と評価プロセスが用いられています。

Write React

「Write React」は、エージェントが React 回帰を引き起こすことなく実際の業務を実装できるかを測定します。各タスクは、オープンソースリポジトリのマージされたプルリクエストから始まります。エージェントにはベースとなるリポジトリと、課題形式の指示が与えられます。ただし、参照用パッチや検証ツールは提供されません。

• 振る舞い: 検証者は隠された動作テストを注入し、エージェントの実装完了後に別コンテナ内で結果を検証します。
• React の健全性: ピン留めした React Doctor スキャンで提出物をベースコミットと比較します。新しい問題が検出されると不合格となります。

Fix React

「Fix React」は、ソースコードのみから React 上の問題を認識し、リファクタリングできるかを測定します。既知の React 課題を持つコンポーネントを選択し、その指摘内容を明示せずに改善を求めます。

• React の健全性: エージェントは、新たな評価対象となる React 問題を引き起こさずに、すべてのターゲットを除去しなければなりません。採点者は行番号の変更は無視します。
• 振る舞い: コンポーネントのリファクタリングが機能面で後退していないことを確認するため、タスクのテストスイートは引き続き通過する必要があります。

エージェントの画像からは React Doctor やその他の React 対応リンターを削除しました。スキャナーとクリーンなベースラインが固定されているのは、検証者（verifier）のみです。

検証者としての React Doctor

React Doctor はオープンソースで決定論的な React 検証ツールであり、400 以上のルール [https://react.doctor/docs/rules] を備えています。これは振る舞いのテストアサーションではカバーしきれない問題を検出するために設計されています。

• 正しさ（Correctness）: 条件付きフック、不安定なリストキー、 hydration の不一致、非推奨の React API を検出します。
• 状態と副作用（State and effects）: 派生または重複した状態、useEffect の乱用、無限再レンダリングを特定します。
• パフォーマンス（Performance）: 不要なレンダリング、レイアウトのスラッシング、逐次的な非同期処理、バンドルサイズを増やすインポートを検出します。
• アクセシビリティとセキュリティ: ラベルのないコントロール、キーボード操作に対応していないインタラクション、不安全な HTML、クライアントバンドルに漏洩した機密情報を検知します。

例

診断情報は、エージェントによって導入された正確な行に紐付けられます。

*図 4. 行動検証と React Doctor は、同じパッチを独立して評価する。*

ReactBench ではすべてのルールを使用しているわけではなく、LLM をジャッジとして使うこともありません。評価に用いる特定の React Doctor ルールを選定し、スキャナーのバージョンとクリーンなベースラインを固定しています。

実際のプルリクエストから検証済みタスクへ

ReactBench は、公開リポジトリのマージされた変更を取り込み、評価用のタスクに変換します。

ReactBench のタスクマイニングは、23,087 件の候補プルリクエストを 4 つの段階を経て絞り込む漏斗プロセスです。各段階で却下された候補が枝分かれし、最終的に 51 件のタスクが残ります。

• 19.2k 件：React のシグナルなし
• 1,680 件：タスクフィルタリングに失敗
• 2,043 件：レビューで却下
• 78 件：バリデーションに失敗

*図 5. リリース用タスクマイニング漏斗。中間の数はマイニングエクスポートから算出されたもので、最終的に 51 件のタスクが採用されました。帯の太さは可読性を考慮して調整されています。

候補の収集

オープンソースの React プロジェクトからマージされたプルリクエストを収集します。

候補のフィルタリング

製品コードに意味のある変更が含まれているかを確認するための自動化されたフィルタを開発しました。その後、レビュー担当者が例外処理を行い、より広範な機能開発や重要なプロジェクトに関わるもの、そして現実的な動作テストを含むものを評価します。

タスクの作成

各レビュー担当者は、検証済みのプルリクエストを実際の課題形式の指示に変換します。候補のテストが厳しすぎる場合、レビュー担当者がカスタムのテストハネスを再構築して動作を検証します。

動作の検証

テストは、固定されたベースコミットに対して失敗し、参照ソリューションでは成功する必要があります。変更されていないリポジトリはスコア 0 を、参照ソリューションはスコア 1 を取得しなければなりません。

検証者のテスト

敵対的なエージェントが、要求された動作を実装せずに満点を得ようとする試行を行います。

リリースの固定

各タスクについて、ソースコミット、環境、テストスイート、参照ソリューション、および検証者設定を固定します。また、公開された各アーティファクトのハッシュ値を記録したバージョン管理付きのマニフェストも用意しています。

React のタスクの 92% が、直近性とリポジトリサイズの両方の基準を満たしています。これらの閾値は、学習データへの露出を減らすために設定されています。

ビヘイビアカバレッジ

すべてのタスクには、リリース前に決定論的な動作チェックが定義されています。要求された振る舞いが既存のテストで完全に特定されている場合は、リポジトリ内の Vitest、Jest、または Playwright のテストを利用します。

既存のテストに隙間がある場合、観測可能な振る舞いを中心に別の検証ハネスを構築します。レビュアーは、参照実装以外の有効な実装も検証器が受け入れることを確認します。

クリーンルーム評価

エージェントと検証器は別々のコンテナで実行されます。評価前に、検証器は独自の Git メタデータ、依存関係、保護された設定、非公開のテスト、および固定された React Doctor バイナリを復元します。

継続的インテグレーション（CI）により、両方のコンテナが同じソースコミットを使用していることが確認されます。検証器はオフラインで実行され、外部ネットワークへの要求を行いません。エージェントの実行中は、非公開のテストや参照実装にアクセスできません。

モデルの失敗とベンチマークの失敗を区別する

スコアが 0 になるのは、モデルの失敗、指示の不備、脆弱なテスト、検証器のエラー、インフラストラクチャの障害、あるいは無効な実行によるものです。

レビュアーは、モデル性能に関する結論に含める前に、その軌跡と最終パッチを検査します。レビューされたロールアウトは、「正当な解決」「純粋なモデルの失敗」「検証器の偽陽性」「検証器の偽陰性」「無効な実行」のいずれかに分類されます。

ReactBench の報酬ハッキング対策テスト

敵対的エージェントは、テストインフラストラクチャ、報酬ファイル、Git の履歴、React Doctor の入力などをプローブし、要求された機能を実装せずに満点のクレジットを獲得しようとします。

こうした抜け道となるタスクについては修正または削除し、すべてのコントロールケースを再実行します。この最終チェックにより、ReactBench が求められた作業そのものを測定しているのか、それともエージェントが採点システムを悪用する能力を測っているのかを検証します。

限界について

React Bench はモデル単体ではなく、エージェントを評価するものです。Codex CLI、Claude Code、Cursor、Gemini CLI、その他のハーンセス間には差異があり、これが結果に影響を与える可能性があります。

各タスクは行動テストと React Doctor を検証者として組み合わせた構成になっています。これらのチェックは重要な React の問題を捕捉できますが、視覚的な正確性や他の重要な属性を保証するものではありません。

また、本ベンチマークは主にオープンソースの React プロジェクトを対象としています。結果が独自コードベース、異なるアーキテクチャ、あるいはその他のフロントエンドフレームワークやセットアップに一般化できるとは限りません。

React Bench はバージョン管理されたタスク、ソリューション、マニフェスト、リリース記録を公開し、他者が評価対象の各タスクセットを検証・再現できるようにします。

今後の取り組み

より多くのモデルを、さらに幅広い難易度レベルで比較する予定です。また、商用ハーンセスだけでなく mini-swe-agent でも実行し、より確固たるベースラインを取得することを目指しています。

今後は視覚デザインや他のフロントエンドフレームワークへの対応も拡大し、取り扱うリポジトリとタスクの多様化を図ります。

ReactBench は常に改善されています。ベンチマークに関する課題は GitHub で報告 してください。モデルラボやコーディングエージェントチームは、お問い合わせ をいただければ、保留中のタセットでのモデル評価、新ベンチマークへの早期アクセス、あるいは共同研究などをご相談いただけます。

謝辞

ReactBench は、エンジニアやオープンソースのメンテナーが時間と専門知識を提供してくれたおかげで実現しました。タスク、ドラフト、評価インフラストラクチャのレビューにご協力いただいた皆様に感謝いたします。

• リサーチ
• デザイン
• 外部貢献者
• Michał Pierzchała (React Native チーム)
• Jovi De Croock (Preact コアチーム)
• Dev Agrawal (SolidJS コアチーム)
• ryoppippi (ccusage 作成者)
• Rahim Alwer (Vidstack、Video.js v10 チーム作成者)
• Tiger Abrodi (初期 Lovable チーム)
• Isabelle Reksopuro

• データアドバイザリー
• Parth Patel (AfterQuery 創設エンジニア)

ReactBench のタスクと評価インフラストラクチャの構築、検証、レビューに携わったエンジニアの方々、および現在のタセットに含まれるオープンソースリポジトリのメンテナーの皆様に特別なお礼を申し上げます。