SlopCodeBenchにおけるOpus 5のベンチマーク

長期的なコーディングベンチマークがモデルの劣化を露呈

Opus 5を含む現在の最先端LLMは、要件が進化するにつれてコードベースの品質を維持することに苦戦するため、まだ「lights-off」（完全自動化）のソフトウェアエンジニアリングにおいて信頼できるものではありません。 Opus 5は従来モデルと比較してわずかな改善が見られるものの、欠陥を導入したり技術的負債を増大させたりすることなく、複雑で多段階のコーディング課題を完了させることには依然として失敗しています。

従来のコーディングベンチマークの多くは、問題文全体を事前に提示するため、特定の時点での問題を解決できるモデルに有利に働きます。対照的に、SlopCodeBench（2026年3月にUW Madisonの研究者によって導入）は、複数の「チェックポイント」を通じてコードベースを進化させるモデルの能力をテストします。モデルは要件を段階的に受け取り、新しい仕様に合わせて既存のコードを調整することを強制されます。これは、現実世界のソフトウェアエンジニアリングのプロセスを反映しています。

SlopCodeBenchにおけるOpus 5のパフォーマンス

Opus 5はSlopCodeBenchのサブセットにおいて24%の厳格な合格率（strict pass rate）を達成し、元の論文で報告されたOpus 4.6の17%という数値をわずかに上回りました。 しかし、「厳格な合格」指標（すべての新しいテストに合格し、すべての継承された回帰テストがグリーンであることを要求する）は、重大な限界を明らかにしています。

17のチェックポイント（簡単、中級、上級の問題にわたる）にわたるテスト実行では、結果は以下の通りでした：

• Opus 5: 17件中4件が厳格合格 (24%)
• Opus 4.8: 17件中1件が厳格合格 (6%)
• Sonnet 5: 17件中1件が厳格合格 (6%)

合格率は向上しているものの、Opus 5は「高コストな冗長性（expensive verbosity）」を示す傾向がありました。Opus 5はOpus 4.8の5倍の関数を記述し、大幅に多い総行数（他のモデルの約9,000行に対し、約29,000行）を生成しました。このボリュームの多くはテストに費やされていましたが、生成コードの増加が比例した正確性の向上にはつながりませんでした。

「Slop（無駄なコード）」の測定：コードの品質と複雑性

SlopCodeBenchは41の決定論的な指標を使用してコードベースの劣化を追跡しており、テストされたすべてのモデルにおいて時間の経過とともに複雑さが増大することを示しています。 これらの指標は、サイズ、複雑性（例：循環的複雑度）、重複、分解、およびルール違反に分類されます。

コード品質に関する主な知見：

• 複雑性の増大: チェックポイントをまたいで複雑さを増大させることなく課題を完了したモデルはありませんでした。Opus 4.8は最も極端な劣化を示し、最悪の関数の循環的複雑度は93に達しました。
• コードの重複: Opus 4.8では、新しい要件が初期設計と衝突したため、重複が4.6%から16.8%に上昇しました。Opus 5は比較的横ばい（2.41%から2.64%）であり、構造的な変更の処理においてわずかな改善が示唆されました。
• Slop密度: 膨大な数のコード行が「slop rules」（冗長性や不良パターンに関する指標）に抵触しました。3つの問題全体を通じて、Opus 5の行の93%がフラグを立てられました。人間がレビューしたAI生成のTypeScriptモノレポと比較すると、Opus 5の「lights-off」生成コードは、kLOCあたりのslopトリガーが11倍以上多い結果となりました。

メンテナンス可能なAIコードへの道

SlopCodeBenchにおける高い失敗率は、コードベースを維持する能力が、単一のコーディングタスクを解決する能力とは異なるスキルであることを示唆しています。 ソフトウェア品質のシグナルを向上させるために、著者は「ハンドオフ（引き継ぎ）」評価を提案しています。これは、最先端モデル（Opus 5やFableなど）に最初のN個のチェックポイントを書かせ、その後、より小さく「単純な」モデル（Sonnet 5など）がチェックポイントN+1を正常に実装できるかどうかをテストする手法です。

もし小さなモデルが大きなモデルの成果の上に構築できないのであれば、それは大きなモデルがクリーンでメンテナンス可能なアーキテクチャを維持できていないことの強力な指標となります。

コミュニティの視点と反論

実務家の間での議論では、結果はモデルの生の能力だけでなく、エージェントの実行環境（harness）やシステムプロンプトの影響を受けている可能性があることが示唆されています。

「エージェントが何にでも触れることができる場合、Slop（無駄）は蓄積する。そのため、エージェントを一つの継ぎ目に限定し、その場で編集するのではなく、その横に追加させるように制約をかけることは、モデルの選択以上に大きな影響を与える。」

他のユーザーは、Opus 5は速度とトークン効率の面で4.8よりも改善されているものの、以前のバージョンやFableのような他の特化型モデルで見られたような「革命的な」飛躍ではないかもしれないと指摘しています。

ベンチマーク課題の概要

課題	難易度	フォーカス
circuit_eval	Easy	CLI, boolean logic, vector signals, 3-valued logic, optimization
database_migration	Medium	SQLite migrations, data transformations, foreign keys, rollbacks
dynamic_config_service_api	Hard	REST API, versioning, schema registry, change-management workflows