Claude Opus 4.7のReact習熟度をeffort=maxで測る、ついでにOpus 4.6の劣化説も検証
React習熟度シリーズ5回目です。前回の記事ではClaude Opus 4.7のReact習熟度を測り、これまでの首位だったGPT-5.4を抜いてベンチマーク首位に立ったことを示しました。
これまでの記事はこちらです。
今回は新たに以下の2点を検証しました。
-
Opus 4.7をeffort=maxで実行する: Opusにはeffortを指定できる機能があり、これまでは
highで検証していました。最上位のmaxにすることでReact習熟度が向上するのか検証しました。 - Opus 4.6の劣化説を検証する: 前回の記事でも触れた「Opus 4.6はリリース当初より劣化しているのでは？」という噂を、同一スペック・同一評価者で再走させて検証します。
ベンチマークの設定はこれまでと同じ、13スペック・評価者はClaude Sonnet 4.6です。
なお、末尾の生レポートにあるように、この記事は実施日（Opus 4.7リリース直後の4月18日）から若干間をあけて投稿されています。直近ではOpus 4.7の劣化説が出てきているので、時期にご注意ください。
結果
| スペック | Sonnet 4.6 | Opus 4.6 (3月) | Opus 4.6 (4月) | Opus 4.7 default | Opus 4.7 max | Haiku 4.5 | GPT-5.4 |
|---|---|---|---|---|---|---|---|
| 001 イベント登録フォーム | 86 | 85 | 83 | 90 | 90 | 65 | 88 |
| 002 データダッシュボード | 78 | 79 | 83 | 69 | 76 | 53 | 74 |
| 003 クイズビルダー | 69 | 69 | 69 | 78 | 83 | 64 | 70 |
| 004 ユーザープロフィール閲覧 | 66 | 56 | 66 | 65 | 65 | 58 | 74 |
| 005 システムステータス監視 | 50 | 62 | 66 | 72 | 83 | 58 | 59 |
| 006 通知アクティビティフィード | 58 | 61 | 54 | 59 | 69 | 51 | 48 |
| 007 SNSフィード | 61 | 65 | 69 | 81 | 81 | 62 | 66 |
| 008 フォームアクション | 61 | 58 | 69 | 76 | 77 | 63 | 64 |
| 009 再利用コンポーネント | 63 | 69 | 69 | 79 | 72 | 65 | 73 |
| 010 ツリーファイルエクスプローラ | 55 | 80 | 74 | 63 | 68 | 59 | 82 |
| 011 ツールチップ/ポップオーバー | 61 | 65 | 64 | 76 | 78 | 66 | 77 |
| 012 マルチタブエディタ | 78 | 78 | 86 | 92 | 88 | 74 | 72 |
| 013 設定画面Undo/Redo | 78 | 86 | 76 | 80 | 86 | 64 | 82 |
| 平均 | 66.5 | 70.2 | 71.4 | 75.4 | 78.2 | 61.4 | 71.5 |
Opus 4.7をeffort=maxで実行することで、平均78.2を記録しました。Opus 4.7 high（75.4）から+2.8、ベンチマークの新記録となっています。
そして、Opus 4.6の再走（4月）の平均は71.4で、3月の70.2とほぼ同水準でした。Reactの習熟度という観点では、劣化説を支持する結果は得られませんでした。
考察
effort=maxの効果
Opus 4.7 maxは、highと比較してカテゴリ別の全項目で改善または横ばいとなりました。特にコンポーネント設計が+0.24と最も伸びており、設計品質の底上げという形で効果が現れています。
個別のスペックでは、スペック002（データダッシュボード）で前回のOpus 4.7が派生値を個別state化するアンチパターンに陥っていたのが、maxではこれが解消されて状態設計が3→5と回復しました。前回の記事で「最大の退行ポイント」とされていた部分がmaxでは見られなくなっています。ただ、これはOpus 4.7の問題というより、前回の試行で単に運が悪かったことも十分に考えられます。
一方、Reactの新しめのAPIの採用状況についてはhighとmaxで差がなく、effortによって改善できる部分ではないようです。これはさらに新しい情報や質の高い情報を学習したモデルを待つ必要があるのでしょう。
Opus 4.6の劣化説検証
結論としては、本ベンチマーク上では劣化の証拠は得られませんでした。3月の70.2 → 4月の71.4と、平均はむしろわずかに上昇しています。
ただ、スペック単位では±10程度のばらつきが普通に発生しており、たとえばスペック013（設定画面Undo/Redo）は86→76と10点低下しています。13スペックあるので平均を取ることで最低限ばらつきを吸収できているはずですが、誤差の範囲内という間隔です。
筆者としてもOpus 4.6の劣化は実際に感じていましたが、少なくともReactを使いこなす技術力という点での劣化は無かったようです。どちらかというと、指示追随能力とか、そちらの方面での劣化が著しかったように思います。
ちなみに、4.6固有の弱点であるアクセシビリティの低さ（2.46→2.54）はそのまま残っています。Opus 4.7（3.38）との差を改めて明確にする結果となりました。Claudeに見られる劣化も、モデル本体というよりは周辺のハーネスとかパラメータの調整によるものであろうとは想像が付くので、そうではないモデル本体の技術力の差がこうしてベンチマークで見られるのは面白いですね。
最近はOpus 4.7の劣化に伴って逆に4.6のほうが好きという人も出てきていますが、4.6と4.7の技術力の確かな差については認識しておいたほうが良さそうです。
React Profession Bench 第5回レポート: effort=max と Opus 4.6 劣化検証
実施日: 2026年4月18日
評価者モデル: Claude Sonnet 4.6（過去全レポートと同一）
スペック数: 13
目的
本レポートでは以下の2つの検証を行う。
-
Opus 4.7 × effort=max: Claude CLI の
--effortフラグに対応（コミット 7bc2643）、Opus 4.7 をeffort=maxで走らせ、既定値（high）との差分を測る。 - Opus 4.6 再評価: 「Opus 4.6 はリリース当初より劣化しているのではないか」という噂を検証するため、同モデルで13スペック全体を再走させ、2026年3月19日実施スコアと直接比較する。
評価者は全試行で Sonnet 4.6 のまま固定している。
実施上の注意
- 本実験は複数回のレート上限到達を受けて分割再実行を繰り返した。スコアファイル
scores/multi_opus-4.7-max_2026-04-18.jsonおよびscores/multi_opus-4.6-rerun_2026-04-18.jsonはそれぞれ最終的な13スペック分のスコアを集約した正規ファイルである。 - スペック010（ツリーファイルエクスプローラ）は両モデルとも evaluator 出力の JSON エスケープ不備で複数回失敗した。4.6 側は合計3回の試行で成功、4.7-max 側は evaluator のタイムアウト後1度の再実行で成功。採点対象コードはその成功時のものである。
検証1: Opus 4.7 default vs Opus 4.7 max
総合スコア比較
| スペック | 4.7 default | 4.7 max | Δ |
|---|---|---|---|
| 001 イベント登録フォーム | 90 | 90 | 0 |
| 002 データダッシュボード | 69 | 76 | +7 |
| 003 クイズビルダー | 78 | 83 | +5 |
| 004 ユーザープロフィール閲覧 | 65 | 65 | 0 |
| 005 システムステータス監視 | 72 | 83 | +11 |
| 006 通知アクティビティフィード | 59 | 69 | +10 |
| 007 SNSフィード | 81 | 81 | 0 |
| 008 フォームアクション | 76 | 77 | +1 |
| 009 再利用コンポーネント | 79 | 72 | −7 |
| 010 ツリーファイルエクスプローラ | 63 | 68 | +5 |
| 011 ツールチップ/ポップオーバー | 76 | 78 | +2 |
| 012 マルチタブエディタ | 92 | 88 | −4 |
| 013 設定画面Undo/Redo | 80 | 86 | +6 |
| 13スペック平均 | 75.38 | 78.15 | +2.77 |
max 側は 13 スペック中 9 スペックで改善、2 スペックで横ばい、2 スペックで回帰となった。平均 +2.8 の底上げで、ベンチマーク全モデル中の最高スコアを Opus 4.7 max が更新した。
カテゴリ別平均の変化（4.7 default → max）
| カテゴリ | default | max | Δ |
|---|---|---|---|
| 状態設計 | 4.38 | 4.46 | +0.08 |
| Effect衛生 | 4.08 | 4.08 | 0.00 |
| コンポーネント設計 | 3.38 | 3.62 | +0.24 |
| TypeScript品質 | 4.54 | 4.69 | +0.15 |
| パフォーマンス意識 | 3.54 | 3.69 | +0.15 |
| アクセシビリティ | 3.38 | 3.54 | +0.16 |
全カテゴリで改善または横ばい。特にコンポーネント設計が +0.24 と最大の伸びを見せた。Effect衛生は完全に横ばいで、useSyncExternalStore / useActionState 等のモダンAPI採用は既に default でも取れており、effort を上げても新規導入は進まなかった。
注目すべき個別スペックの変化
スペック005 システムステータス監視（+11、72→83）
max ではアクセシビリティが 3→4 に上昇し、Effect衛生も 4→5 と満点化した。default 時点で useSyncExternalStore を5箇所使用する実装は既に取れていたが、max ではさらに live region による動的イベント通知、フィルタボタンの aria-pressed 等、セマンティクス面が一段厚くなった。
スペック006 通知アクティビティフィード（+10、59→69）
default の弱点はコンポーネント設計（3/5）と Effect衛生（2/5）だったが、max では設計4/5、Effect衛生3/5 と両方改善。panel 単位の分解が取れ、バッファ中の通知の扱いも effect を介さず reducer で表現する設計に近づいた。
スペック002 データダッシュボード（+7、69→76）
default で評価者が指摘した「派生値を個別state化する」トラップが max では解消され、状態設計は 3→5 に復活。これは 4.7 default で強く見えた最大の退行ポイントが、effort を上げることで取り戻されたことを意味する。
スペック009 再利用コンポーネント（−7、79→72）
max 側で唯一目立った回帰。アクセシビリティは4→3、Effect衛生は5→4に低下した。ToggleButtonGroup を汎用化する過程で ARIA 関連の記述が薄くなり、また fetchTasks の初期化 effect が依存配列的に乱雑になったと評価者は指摘している。
スペック012 マルチタブエディタ（−4、92→88）
本ベンチマーク全モデル最高スコアを保持していたが、default 時点から −4。コンポーネント設計は 5→4、state 設計は 5 のまま維持されたが、default で見られた明確な 4 層階層（App → TabBar → {PlainText, Markdown, JSON}）の明示性がやや薄まった。
検証1 小括
effort=max への切り替えは、期待通り「設計品質の底上げ」として現れた。個別スペック単位では ±10 規模の揺れが残るが、total で +2.8、カテゴリ全項目で改善/横ばいは意味のある差である。
ただし コスト と 所要時間 は default 比で2〜3倍（一部スペックで5〜8分 → 10〜20分）に伸びており、常用するかはタスクの重要度に応じた判断が必要となる。
検証2: Opus 4.6 の劣化検証
「Opus 4.6 はリリース当初（3月）より劣化している」という噂を、同モデル・同スペック・同評価者での再走により検証する。
総合スコア比較
| スペック | 4.6 (03-19) | 4.6 (04-18) | Δ |
|---|---|---|---|
| 001 イベント登録フォーム | 85 | 83 | −2 |
| 002 データダッシュボード | 79 | 83 | +4 |
| 003 クイズビルダー | 69 | 69 | 0 |
| 004 ユーザープロフィール閲覧 | 56 | 66 | +10 |
| 005 システムステータス監視 | 62 | 66 | +4 |
| 006 通知アクティビティフィード | 61 | 54 | −7 |
| 007 SNSフィード | 65 | 69 | +4 |
| 008 フォームアクション | 58 | 69 | +11 |
| 009 再利用コンポーネント | 69 | 69 | 0 |
| 010 ツリーファイルエクスプローラ | 80 | 74 | −6 |
| 011 ツールチップ/ポップオーバー | 65 | 64 | −1 |
| 012 マルチタブエディタ | 78 | 86 | +8 |
| 013 設定画面Undo/Redo | 86 | 76 | −10 |
| 13スペック平均 | 70.23 | 71.38 | +1.15 |
13スペック中、改善6・横ばい2・回帰5。平均スコアはわずかに上昇（+1.2）しており、劣化の証拠は得られなかった。
カテゴリ別平均の変化（4.6 original → rerun）
| カテゴリ | original | rerun | Δ |
|---|---|---|---|
| 状態設計 | 4.62 | 4.31 | −0.31 |
| Effect衛生 | 3.92 | 4.08 | +0.16 |
| コンポーネント設計 | 3.31 | 3.08 | −0.23 |
| TypeScript品質 | 4.23 | 4.62 | +0.39 |
| パフォーマンス意識 | 3.23 | 3.31 | +0.08 |
| アクセシビリティ | 2.46 | 2.54 | +0.08 |
TypeScript 品質が +0.39 と最大の改善を見せた一方、状態設計が −0.31、コンポーネント設計が −0.23 と回帰している。
劣化仮説の検証
平均 +1.2 という結果は評価の標準的なばらつきの範囲内である。本ベンチマークは LLM の確率的出力に依存するため、同一モデル・同一 prompt であっても再走ごとに ±5 〜 ±10 程度のスペック別ばらつきが観測される。今回の個別スペック差（最大 +11 / −10）はこの範囲内に収まっている。
従って、「Opus 4.6 が劣化している」という主張は、本ベンチマーク上は支持されない。むしろ以下の定性的観察から、「別の方向に振れた」と表現する方が適切である。
-
TypeScript 品質が明確に向上: ジェネリクスと判別共用体の使いこなし、
anyの忌避が前回より徹底されている。 -
状態設計では派生値トラップに再度はまった: スペック006 で
bufferCountの state 化、スペック013 で settings 側のコンポーネント肥大化など、3月時点では避けられていた局所的なミスが発生している。 - アクセシビリティは依然低い（2.54）: 4.6 の固有の弱点は改善されないままで、これは Opus 4.7（3.38 / 3.54）との一貫した差として残っている。
要するに、同じ 4.6 を2度走らせれば、スペック単位ではスコアが ±10 程度揺れるが、平均は安定し、カテゴリごとの強み/弱みのプロファイルもほぼ保たれている。「劣化している」という主観的印象は、おそらくユーザーが出会ったサンプルのばらつきに起因する可能性が高い。
注目すべき個別スペックの変化（4.6）
スペック008 フォームアクション（+11、58→69）
03-19 ラウンドではコンポーネント設計 2/5・Effect衛生 3/5 と低迷していたが、04-18 では設計 2/5・Effect衛生 4/5 に改善。useActionState は依然未採用だが、useEffect を使わない純粋なフォーム処理に近づいた。
スペック004 ユーザープロフィール閲覧（+10、56→66）
コンポーネント設計が 2→4、状態設計が 3→4 と伸びた。ただし Suspense for data fetching は依然未採用（2/5）で、useEffect + isLoading のクラシックパターンのまま。
スペック013 設定画面Undo/Redo（−10、86→76）
最大の回帰。コンポーネント設計が 5→3 に大きく低下した。評価者は「preview 側の分解は良好だが settings 側が1つのコンポーネントに寄っている」と指摘しており、これは 4.7 default でも発生していた同一の症状である。
スペック006 通知アクティビティフィード（−7、61→54）
bufferCount の個別 state 化と、App が単一モノリスになった設計が主因。3月ラウンドで正しく取れていた reducer ベースの整理が再現されなかった。
検証2 小括
- Opus 4.6 劣化仮説は 否定。平均スコア差は +1.2 で、劣化の兆候は観測されない。
- ただしモデルの振る舞いには 確率的揺れ があり、スペック単位では ±10 の差が自然に発生する。ユーザーが「劣化した」と感じる場合、それは特定のタスクでの悪いサンプルに引いてしまった可能性が高い。
- 一方で 4.6 固有の弱点（アクセシビリティ低位）は不変 であり、「噂の劣化」とは独立に、4.6 世代の本質的な限界は存在する。
全モデル最新ランキング
Haiku 4.5 (61.4) < Sonnet 4.6 (66.5) < Opus 4.6 [orig] (70.2) ≈ Opus 4.6 [rerun] (71.4) < GPT-5.4 (71.5) < Opus 4.7 [default] (75.4) < Opus 4.7 [max] (78.2)
Opus 4.7 max が本ベンチマークにおける現時点最高性能。GPT-5.4 との差は +6.7 に広がり、Claude 勢が Opus 4.7 のリリースによって明確にトップグループを形成している。
今後の課題
- 評価者 JSON パース失敗への対策: 今回も evaluator の justification 文字列内バッククォート/バックスラッシュが原因で複数回パースに失敗した。直近の3ラウンドで累積5回以上発生しており、対策の実装（失敗時に JSON-only 再プロンプト、または evaluator 側で justification を base64 化する等）が必要な段階に達している。
- 同一モデル再現性の定量化: 「劣化」の議論を今後もサポートするには、同モデル × 同スペックでの複数回再走の標準偏差を取り、「差がノイズか否か」を客観的に判定する枠組みが要る。
- コスト・時間の報告: effort=max は品質向上を伴う一方でコスト数倍になる。今後は各ラウンドで所要時間とトークン使用量も記録し、品質/コスト曲線を描けるようにしたい。
Discussion