🎓

Claude Opus 4.7のReact習熟度をさっそく測る

に公開

React習熟度シリーズ4回目です。前回の記事で「自分で妙案が出てくるまでこのシリーズは一区切り」と書いたのですが、Claude Opus 4.7がリリースされたので早速測ってみました。

これまでの記事はこちらです。

https://zenn.dev/uhyo/articles/react-profession-bench-1

https://zenn.dev/uhyo/articles/react-profession-bench-2

https://zenn.dev/uhyo/articles/react-profession-bench-3

ベンチマークの設定は前回までと同じ、13スペック・評価者はClaude Sonnet 4.6です。今回は新登場のOpus 4.7を追加で測定し、既存のOpus 4.6のスコアと比較します。

ちなみに、Opusはeffortを設定できるのですが、Opus 4.6とOpus 4.7のどちらもhighで評価しています。また、Opus 4.6は劣化が著しいと噂されています。Opus 4.6のベンチマークを行ったのが2026年3月19日なので、その時点のOpus 4.6のスコアを今回のOpus 4.7と比較する形になります。

結果

スペック Sonnet 4.6 Opus 4.6 Opus 4.7 Haiku 4.5 GPT-5.4
001 イベント登録フォーム 86 85 90 65 88
002 データダッシュボード 78 79 69 53 74
003 クイズビルダー 69 69 78 64 70
004 ユーザープロフィール閲覧 66 56 65 58 74
005 システムステータス監視 50 62 72 58 59
006 通知アクティビティフィード 58 61 59 51 48
007 SNSフィード 61 65 81 62 66
008 フォームアクション 61 58 76 63 64
009 再利用コンポーネント 63 69 79 65 73
010 ツリーファイルエクスプローラ 55 80 63 59 82
011 ツールチップ/ポップオーバー 61 65 76 66 77
012 マルチタブエディタ 78 78 92 74 72
013 設定画面Undo/Redo 78 86 80 64 82
平均 66.5 70.2 75.4 61.4 71.5

Opus 4.7は平均75.4を記録し、これまで首位だったGPT-5.4(71.5)を抜いてベンチマーク首位に立ちました。

考察

4.6→4.7の変化で特筆すべきは、アクセシビリティのカテゴリ平均が2.46→3.38と大幅に伸びたことです。これまでのベンチマークでClaudeの弱点と目されてきた領域です。まだGPT-5.4(3.8)に追いついてはいませんが、大きく差を縮めました。

また、Reactの新しめのAPIという観点でも、useSyncExternalStoreuseActionStateを自主的に採用したのが目新しい点です。Claudeシリーズとしては初採用で、Opus 4.7はベンチマーク全体を通しても最も多くの新しめのAPIを使いこなしています。データフェッチ用SuspenseやuseEffectEventuseOptimisticは依然として未到達ですが、API習熟という観点で着実に進歩している印象を受けました。

一方で、スペック010(ツリーファイルエクスプローラ)と002(データダッシュボード)では明確なリグレッションが見られました。特に010はOpus 4.6が80点だったのに対して4.7は63点と低下しています。相変わらず一発撮りのテストなので偶然かもしれませんが、コーディングの傾向がもしかしたら変わったのかもしれません。

全体として、Opus 4.6から順当にReact力が向上した印象を受けますね。


React Profession Bench 第4回レポート: Claude Opus 4.7 登場

実施日: 2026年4月17日
評価対象モデル: Claude Opus 4.7(新規)
比較対象: Claude Opus 4.6(2026年3月19日実施の既存スコア)
評価者モデル: Claude Sonnet 4.6(前回と同一)
スペック数: 13

概要

本レポートは、2026年4月にリリースされた Claude Opus 4.7 を既存13スペックで評価し、同一の評価者(Sonnet 4.6)で採点されていた Opus 4.6 のスコア(2026-03-19 レポート)と直接比較したものである。評価者が同一であるため、両バージョンのスコア差はそのまま実装側の変化を表すと見なせる。

総合スコア比較

スペック Opus 4.6 Opus 4.7 Δ
001 イベント登録フォーム 85 90 +5
002 データダッシュボード 79 69 −10
003 クイズビルダー 69 78 +9
004 ユーザープロフィール閲覧 56 65 +9
005 システムステータス監視 62 72 +10
006 通知アクティビティフィード 61 59 −2
007 SNSフィード 65 81 +16
008 フォームアクション 58 76 +18
009 再利用コンポーネント 69 79 +10
010 ツリーファイルエクスプローラ 80 63 −17
011 ツールチップ/ポップオーバー 65 76 +11
012 マルチタブエディタ 78 92 +14
013 設定画面Undo/Redo 86 80 −6
13スペック平均 70.2 75.4 +5.2

13スペック中、9スペックで改善、4スペックで回帰という結果となった。改善幅の大きさ(最大 +18)が回帰幅(最大 −17)とほぼ拮抗しているため、平均スコアの伸び(+5.2)以上に個別スペックの差は大きい。

カテゴリ別平均の変化

カテゴリ Opus 4.6 Opus 4.7 Δ
状態設計 4.62 4.38 −0.24
Effect衛生 3.92 4.08 +0.16
コンポーネント設計 3.31 3.38 +0.08
TypeScript品質 4.23 4.54 +0.31
パフォーマンス意識 3.23 3.54 +0.31
アクセシビリティ 2.46 3.38 +0.92

最大の改善: アクセシビリティ(+0.92)

全カテゴリの中で圧倒的に伸びたのがアクセシビリティである。前回レポートで「全モデル共通の最大の弱点」と結論づけた領域で、Claude Opus 4.7 は一世代で GPT-5.4(平均 3.8)に肉薄する水準まで引き上げた。

具体的には、スペック007(SNSフィード)で<article>+<header>+aria-pressed 付きいいねボタンを実装して5/5を記録し、スペック013(設定画面)でも<fieldset>/<legend> によるグループ化と <details>/<summary> の活用で5/5を獲得した。4.6では5/5を一度も取れていなかった(最高4/5)ことを考えると、これは質的変化である。

小幅な回帰: 状態設計(−0.24)

唯一スコアが下がったカテゴリは状態設計であり、原因はほぼ単一スペック(002データダッシュボード)の5/5→3/5という大きな低下で説明される。評価者の所見によれば、mostRecentByContactvisibleMessages 等を個別state化する構造となり、4.6で見られた派生値ベースのクリーンな設計が失われた。

注目すべき個別スペックの変化

大きな改善

スペック008 フォームアクション(+18、58→76)

4.7 は React 19 の <form action={formAction}> + useActionState パターンを実際に採用した。Effect衛生は3→5と満点となり、useEffectゼロの完全に宣言的なフォームライフサイクル実装を達成した。これは本ベンチマーク上、Claude モデルで初めての useActionState 採用である(前回スコアで唯一採用したのは Claude Sonnet 4.6)。

なお、TypeScript コンパイルは失敗した状態で評価された。評価者は生成されたコードを対象にスコア付けしているため、型エラー自体はスコアに直接反映されない。これは評価方式上の既知のグレーゾーンである。

スペック007 SNSフィード(+16、65→81)

アクセシビリティが2→5と3段階ジャンプ。React.memo の適切な使用、useMemo によるメンション/ハッシュタグ解析の局所化、<article>/<header> のセマンティック実装がすべて揃った。useOptimistic は依然不使用だが、他の全要素が押し上げ要因となった。

スペック012 マルチタブエディタ(+14、78→92)

本ベンチマーク全モデル最高スコア(前回 GPT-5.4 の 88 を更新)。コンポーネント設計でベンチマーク上初の5/5を記録した。AppTabBar{PlainTextEditor, MarkdownEditor, JsonEditor} という明確な役割分離に加え、React.lazyによるコード分割も引き続き採用された。

スペック005 システムステータス監視(+10、62→72)

本バージョンの最大の定性的進歩。src/hooks.ts 内で useSyncExternalStore5箇所使用されており、オンライン状態・ビューポート・メディアクエリ・visibilitychange・イベントバスのうち4種の購読が正しくこのフックで実装された。これは Claude Opus が初めて useSyncExternalStore を正しく採用したケースである。Effect衛生は3→4に改善。

スペック011 ツールチップ/ポップオーバー(+11、65→76)

Tooltip と Popover の両方で useLayoutEffect を適切に使用し、createPortal によるポジショニングを丁寧に実装。TypeScript品質は4→5の満点、Effect衛生は3→4となった。

回帰

スペック010 ツリーファイルエクスプローラ(−17、80→63)

本ベンチマーク中、一つのバージョン間変化としては最大の回帰。実装は 303行の単一App.tsx に全てのツリーレンダリング、キーボードナビゲーション、検索フィルタ、フォーカス管理が集約されたモノリシック構造となった。4.6 では TreeView/TreeItem への適切な分割が行われ、WAI-ARIA tree パターンも完全だったことと対照的である。

カテゴリ別でも、状態設計(5→4)、Effect衛生(5→4)、コンポーネント設計(3→2)、TypeScript品質(5→4)、アクセシビリティ(4→3)と全項目で低下が見られた。

スペック002 データダッシュボード(−10、79→69)

状態設計5→3、コンポーネント設計4→3が主因。評価者は visibleMessages 等がuseMemoではなく個別stateとして保持されていると指摘しており、これは本ベンチマークで最も頻出する派生値トラップに該当する。

スペック013 設定画面Undo/Redo(−6、86→80)

コンポーネント設計が5→3に低下したのが主因だが、アクセシビリティは4→5に上昇した。評価者は「preview側の分解は優秀だが、settings側が一つのコンポーネントに寄っている」と指摘している。

モダンReact API採用状況: 4.6 → 4.7

API Opus 4.6 Opus 4.7
useDeferredValue (002)
Suspense for data fetching (004)
useSyncExternalStore (005) ✗ (partial) ✓ (5箇所)
useEffectEvent (006)
useOptimistic (007)
useActionState (008)
useFormStatus (008)
React.lazy (012)
useReducer (013)
Popover API (011)

新規採用(Claude Opus としては初):

  • useSyncExternalStore: ブラウザAPIおよび外部イベントバスへの購読パターンを正しく認識した。
  • useActionState: React 19 フォームアクションの宣言的ライフサイクルを採用した。

依然未採用:

  • Suspense for data fetching: データフェッチング用 Suspense + use() は引き続き未到達。
  • useEffectEvent: 変更される設定を効果内で読む用途に対し、相変わらず ref ベースの回避策を使用。
  • useOptimistic: 楽観的更新は手動実装のまま。
  • Popover API: tooltip/popover は引き続き createPortal ベース。

10 API 中 2つの新規採用は、短いバージョン更新期間としては実質的な進歩である。特に useSyncExternalStore は React 18 で導入されたにもかかわらず長らく LLM に浸透していなかった API であり、現実のコードベースへの使用例が訓練データに反映されてきたことを示唆する。

考察

Opus 4.7 の特徴

Opus 4.7 は、以下の3つの方向で Opus 4.6 を上回った:

  1. セマンティックHTML/ARIAの理解度が大幅向上: アクセシビリティの0.92ポイント改善は、個別ケースの偶然ではなく一貫した傾向である。
  2. 最新React APIへの着手: useSyncExternalStoreuseActionState を、明示的な指示なしに適切な文脈で採用した。
  3. TypeScript表現力の向上: 5/5 の記録回数が4回→7回に増加。ジェネリクスと判別共用体の使いこなしが安定した。

Opus 4.7 の弱み

一方、以下の領域で後退または現状維持にとどまった:

  1. 大規模単一コンポーネントへの傾向: スペック010 はその典型例で、4.6より明らかに分解が甘い。モデルが「まず動くものを素早く書く」傾向を強めた可能性がある。
  2. 派生値vs state の判定: スペック002 の5→3は、本来 Claude の最も得意とするはずの領域であり、回帰の原因分析が必要である。
  3. useEffectEvent・Suspense-for-data・useOptimistic は依然不使用: いずれも React 19.x の主要機能であり、次期バージョンでの到達に期待したい。

全モデル順位の更新

Haiku 4.5 (61.4) < Sonnet 4.6 (66.5) < Opus 4.6 (70.2) < GPT-5.4 (71.5) < Opus 4.7 (75.4)

本ベンチマークにおける現時点のトップ性能は Opus 4.7 である。GPT-5.4 との差(+3.9)は小さいものの、両モデルは強みの方向性が異なる:

  • Opus 4.7: React のメンタルモデル理解(状態設計・Effect衛生)+ 改善されたアクセシビリティの両立。
  • GPT-5.4: 完遂率とアクセシビリティ優位、ただし状態設計で Claude に劣る。

今後の課題

  1. 評価の再現性: 今回も JSON パース失敗(スペック008)が一度発生した。本件は evaluator の justification 文字列内のエスケープ起因であり、フォールバック(失敗時に JSON-only 再プロンプト)の実装を検討すべきである。
  2. コンパイル失敗の扱い: 今回スペック008 は TypeScript コンパイル失敗のまま評価された。評価者はコードの設計的品質を採点するが、コンパイルが通らない実装はそもそも利用不可能である。将来は総合スコアへのコンパイル通過率の反映を検討する価値がある。
  3. 回帰の定量追跡: Opus 4.7 のような新バージョン登場時に「どのスペックでどのカテゴリが回帰したか」を自動レポートする仕組みがあると、本レポート作成自体を高速化できる。
GitHubで編集を提案

Discussion