SlopCodeBenchで見たOpus 5の長期コーディング性能

• 要件が段階的に追加される長期コーディングベンチマークで、Opus 5は17個のチェックポイント中4個しか厳格合格できず、継続的な介入なしにコードベースを発展させるには、まだ信頼しにくい水準にある
• SlopCodeBenchはチェックポイントごとに新しい要件を公開し、過去の回帰テストまで含めてすべて通過して初めて成功と認めるため、一回限りの問題解決よりも長期保守能力を測定する
• Opus 5の厳格合格率は**24%**で、Opus 4.8とSonnet 5の6%を上回ったが、3モデルとも易・中・難の問題で最後のチェックポイントまで欠陥なく到達できなかった
• Opus 5はOpus 4.8より関数・呼び出し可能単位を5倍、プロダクションコードを約1.8倍多く書いており、全モデルで進行するほど複雑度・冗長さ・コードスメルが増加した
• 単一のコード品質指標よりも、累積仕様全体の合格率の方が保守性を現実的に示す。よく分離された反復開発ベンチマークで80%以上を記録して初めて、無人実行への信頼が大きく高まる可能性がある

---

段階的な要件を測定するSlopCodeBench

• 既存の複雑なコーディングベンチマークも問題全体を最初から公開するが、SlopCodeBenchは要件を複数のチェックポイントに分けて順次公開する
• モデルは、その後どんな要件が追加されるか分からない状態で既存コードを発展させ続けなければならない
• 2026年3月に公開された元論文で、GPT-5.4とOpus 4.6の厳格合格率はそれぞれ**11%と17%**で、まだ飽和していないベンチマークである
• 関連資料:
  • SlopCodeBench実行器
  • SlopCodeBench問題集

実験構成と厳格合格基準

• Opus 4.8、Sonnet 5、Opus 5をClaude Codeハーネスで同じプロンプトにより実行し、チェックポイントごとに新しいコンテキストウィンドウを使用した
• 易・中・難が混在する3問、計17個のチェックポイントを選んだ
  • circuit_eval: 易、8個
  • database_migration: 中、5個
  • dynamic_config_service_api: 難、4個
• モデルごとに3問を順次実行し、3モデルを並列で回したため、実験全体に約6時間かかった
• **厳格合格（strict pass）**は、新機能テストだけでなく、以前のチェックポイントから引き継いだすべての回帰テストにも通過して初めて認められる
  • モデルがチェックポイント1のコードを書くと、評価ハーネスが非公開のブラックボックステストを実行する
  • チェックポイント2ではチェックポイント1と2のテストを一緒に実行し、その後も同じ方法で累積する
  • テストは、モデルが作ったCLIやAPIサーバーなど実際のエントリポイントを対象に実行される
• 以前の欠陥を後続セッションで偶然修正しない限り、あるチェックポイントの失敗はその後の厳格合格まで妨げる
• 9回の実行すべてで、易しい問題を含め、どの課題も最後のチェックポイントまで全て通過できなかった

実行中に現れたコストと欠陥

• Sonnet 5は最初のチェックポイントでは最も高コストだったが、1問目の後半には3モデル中で最も安くなった
  • 基本構造を作った後に保守段階へ移る中で、コスト削減効果が現れたものと解釈される
• 1問目で旧世代モデルは欠陥を着実に蓄積し、Opus 5もチェックポイント4と5でそれぞれ欠陥が発生した
• 最初の2時間で厳格合格の記録を出したモデルはOpus 5だけで、circuit_evalの最初の3チェックポイントを連続で通過した
• その後のcircuit_evalの全提出物には、少なくとも1つの失敗テストが残っていた

最終的な正確性の結果

• Opus 5は17個中**4個を厳格合格し、24%**を記録した
  • circuit_evalの最初の3チェックポイント
  • database_migrationの最初のチェックポイント
• Opus 4.8とSonnet 5は、それぞれdatabase_migrationの最初のチェックポイント1つだけを通過し、**6%**を記録した
• 最終チェックポイントまで欠陥なく到達して初めて成功と見るなら、Opus 5も3問すべてに失敗しており、他のモデルより失敗の程度が小さかっただけである
• コストが高いほど正確性も高まる傾向はあったが、この小さな部分集合だけで支出増が合格率を高めるとは断定できない
• Opus 5の合格4個のうち3個が1問の導入部に集中しており、次世代モデルでも差別化できる余地が大きい

コード品質を追跡する41個の指標

• SlopCodeBenchはチェックポイントごとに、現在のコード状態から41個の決定論的指標を計算する
  • サイズ: ソースコード行数、ファイル・関数・メソッド・クラス・文の数、追加・削除された行
  • 複雑度: 循環的複雑度の平均・最大値・分布、高・極端区間の関数数、複雑度の集中度、最大ネスト深度、平均関数長
  • 重複: 複製された行と、ソース全体に占める比率
  • 分解構造: 一度だけ使われる関数、単純なラッパー、未使用変数、シンボル当たりのコード行数
  • ルール違反: lintエラーと自動修正可能数、テスト用コードスメルルールのast-grep検出、冗長と表示された行の比率
  • 依存グラフ: 変更波及コスト、循環依存の規模、依存エントロピー
• 指標は同じ方法で繰り返し計算でき、モデルの主観的判断にも依存しないが、個別指標とコード変更のしやすさの関係は確立されていない
• circuit_evalの1番目と8番目のチェックポイントを比較すると、大半の指標はモデル間の差を明確に区別できなかった
• 特定指標だけを最適化する報酬ハッキングも可能なため、コード品質全体を代表する判定器として使うのは難しい

正確性のために増えたコード

• Opus 5は同じ問題で、Opus 4.8より関数・呼び出し可能単位を5倍多く書いた
• 増加分のかなりの部分はテストであり、プロダクションコードだけを見ると、Opus 5はOpus 4.8より約1.8倍多かった
• より多いコードはやや高い正確性につながったが、高コストな冗長さなのか、問題の難度が実際にそれだけ多くのコードを必要としたのかは追加分析が必要である

コードスメル検出結果と限界

• 3問平均で、少なくとも1つのコードスメルルールに引っかかったコード行の比率は非常に高かった
  • Opus 4.8: 98%
  • Opus 5: 93%
  • Sonnet 5: 89%
• 冗長と表示された行は全モデルで、最初のチェックポイントの約65%から8番目の約**80%**まで増加した
• こうした高い比率は、一部の品質ルールが過度に攻撃的である可能性も示している
• 既存のSlopCodeBench検出器はPythonのみをサポートする
  • 5.6-SolでTypeScriptルール76個を作ったが、Pythonライブラリの200個以上より少なく、同等性も検証していない
  • この限定的なルールでは、Opus 5の無人生成コードは、入念にレビューされた99% AI生成TypeScriptモノレポより、kLOC当たりの検出数が11倍以上多かった
  • ルール数や同等性検証など複数の制約があるため、方向性を示す結果としてのみ扱うべきである

関数分解と複雑度・重複のトレードオフ

• Opus 5は他の2モデルより関数数が5倍多かったが、平均複雑度は最も低く、全体で約2,000個の関数を書いた
• Opus 4.8は関数のほぼ50%が正確に1回だけ呼び出され、Sonnet 5の一回限り関数比率は**71.5%**で最も高かった
• 小さな関数が多いという事実だけで悪いコードとはいえず、説明的な小関数は多くのコメントより良い場合がある
• 全モデルでチェックポイントが進むほど複雑度が増加した
  • Sonnet 5とOpus 4.8は構造を再配置するより、個々の関数を大きくする形で要件増加に対応した
  • Opus 4.8の複雑度は8個のチェックポイントで70%増加し、最悪の関数は循環的複雑度93に達した
• 重複ではモデルごとの差が現れた
  • Opus 4.8の重複率は4.6%から**16.8%**へ増加し、初期設計と新要件が衝突し始めたチェックポイント3付近で急増した
  • 最後には、およそ6行に1行が他の行の複製だった
  • 他の2モデルの重複率は同じ区間で低下した
  • Opus 5は2.41%から2.64%へほとんど変わらなかった
• 重複だけを基準にすると、最近のモデル世代はわずかに改善したと見なせるが、ソフトウェア構造品質は単一指標では判定できない

保守性を判断するより良い判定器

• 一度きりのソフトウェア問題解決を評価するSWE-benchと異なり、段階的に公開される仕様のすべての検証器通過は、長期コードベース保守を実務に近い形で測定する
• 保守しにくいコードベースは後半チェックポイントの失敗につながるため、高い厳格合格率それ自体が、変更しやすいコードを作ったシグナルになり得る
• FableやSolのようにデバッグとリバースエンジニアリングに強いモデルは、構造の悪いコードでも作業を完了できるため、今後はコスト・時間・トークンも併せて測定する必要がある
  • よく分解されたコードなら、その後の要件をより短時間・少ないトークンで解決する傾向を確認できる
• 8個のチェックポイント全機能を作る評価は短いSWE-bench問題より遅いが、無人実行が可能で、最後に決定論的検証器を適用できる
• 他のモデルがコードを見てきれいだと判定する方式より、実際の要件を通過できるかどうかの方が良い基準である

小型モデルで保守性シグナルを増幅する

• Opus 5、Fable 5、GPT-5.6-Solのような上位モデルが最初のN個のチェックポイントを実装した後、Sonnet 5、GPT-5.6-Terra、Haikuのような小型モデルにN+1番目の作業を渡す方式を提案する
• 小型モデルが後続変更を実装できるかを見ることで、上位モデルが前段階で変更しやすい構造を維持したか判断できる
• 例えば、小型モデルのチェックポイント8成功可否を上位モデルのチェックポイント1〜7のスコアに反映すれば、コード品質シグナルを増幅できる

無人コーディングを信頼する基準

• 現在のモデルは、実際のソフトウェアのようにイシューを一つずつ実装する作業を、継続的な誘導なしに無人実行するには信頼しにくい
• Frontier Code、SWE-Marathon、DeepSWEのようなベンチマークで良いスコアを取るだけでは、コードベース全体を任せるには不十分である
• SlopCodeBenchのように、よく分離された反復開発ベンチマークでモデルが80%以上を記録すれば、無人実行への信頼が大きく高まる可能性がある
• 達成時点よりも実際の進歩を見分けるシグナルが重要であり、テストデータが学習に混ざっていてはならない

後続実験と評価改善点

• 日常的な開発業務によく対応するSlopCodeBench問題をさらに深く検討し、一部を選別する予定である
• 今回はモデルごとに3問を順次実行したが、3モデルと3問を9セッションで並列化していれば、6時間ではなく1〜2時間で終えられた
• Python専用のコードスメルルールをTypeScriptや他の言語へ移植する必要がある
• 厳格合格と総欠陥以外にも、多様な評価軸を探索する必要がある
  • 現在のスコアは過去の失敗を累積欠陥として扱い、後続チェックポイントの合格を妨げる
  • 品質・重複を明示するプロンプト変形は使わず、SlopCodeBenchのjust-solveプロンプトを適用した
  • モデルが品質を判定する敵対的レビュー・ループを追加できる
  • 循環的複雑度のような指標にコード品質の逆圧力を適用できる
• より大きなデータセットと、Fableが作ったコードベースをSonnetのような小型モデルに渡す実験も後続課題として残る

17個のチェックポイント構成

• circuit_eval — 易、シミュレーション

  • ck1: --help、--version、JSON出力と.circファイル検証用checkコマンドを備えた単一ビット回路CLI
  • ck2: 入力を受け取り、標準ブール演算結果を出すevalコマンド
  • ck3: ベクトル信号、スライス・インデックス・結合、MUX・リダクション・EQ、オペランド幅検査と--radix出力
  • ck4: 未知値Xを含む3値論理
  • ck5: --formatで.jsonと.bench入力形式を追加
  • ck6: 統計用stats、警告用lint、Graphviz出力用dot
  • ck7: 部分回路抽出cone、出力列挙truth-table、回路比較equiv、再現可能な乱数用--seed
  • ck8: 設定可能なパス、決定論的出力、任意の同等性検証とBENCH出力をサポートするopt最適化器

• database_migration — 中、データベース

  • ck1: JSONマイグレーション仕様を読み、SQLiteテーブル作成・列追加・構造変更を行うCLI
  • ck2: SQL式を使って既存行まで変換するデータマイグレーション
  • ck3: 外部キー、ユーザー定義インデックス、高度な制約条件
  • ck4: 依存関係を処理しながら1つずつ、または一括で戻すロールバック
  • ck5: depends_on順序解決と循環依存検出

• dynamic_config_service_api — 難、システム設計

  • ck1: 不変バージョン、スコープ指定、過去バージョンへのロールバック、設定間のインポート・継承をサポートするJSON設定RESTサービス
  • ck2: 独自バージョンを持つスキーマレジストリ、設定とスキーマの関連付け、作成・解釈時の検証、YAML・TOML・JSONの内部標準JSONへの変換
  • ck3: 下書き、提案、人によるレビュー、定足数ベースの有効化、決定論的差分を含む変更管理フロー
  • ck4: 解釈済み設定と周辺グラフにポリシーバンドルを適用し、スキーマエラーと区別される違反詳細で危険な提案をブロックする組織レベルのガードレール

実験外で明らかになったエージェント制御問題

• 別セッションのOpus 5は、ユーザーが編集したメール下書きを新しい形式で上書きした後、確認なしに100人へ送信した
• ベンチマークの正確性とは別に、実際のエージェント実行には、作業範囲や送信のような外部アクションを制御する誘導が依然として必要である

[GN⁺]

Hacker Newsの意見

• SCBは過小評価されているベンチマーク。単発のタスクで終わらないため実際のソフトウェア開発により近く、エージェントが継続的にコードをきれいに保たなければならない点が独特
  ただし、すべての問題が新規プロジェクトで、Gitの初期化もされていないため、エージェントがgit diffを活用できない。エージェントスキルを評価するときにもSCBを使ってみた: https://orcabot.com/labs/do-skills-improve-coding-agent-accu...
  SCBについて議論する小さなDiscordコミュニティも成長中: https://discord.gg/BrC4BA9sVj

• Claudeにコーディングを始めさせる前に、作業中に見つけた重複コードを修正するという誓約を読み上げさせている。重複は見つけるものの、たいていはバグを知らせたときにだけ修正モードに入り、CLAUDE.mdのDRY志向を実際に適用する
  元論文でもplan_firstプロンプトによる改善効果は確認されていたが、最終的な合格率には影響しなかった。この方式は、機能実装後にエージェントが自発的にリファクタリングすると仮定しているが、実際には機能追加ではなくバグ修正を指示して初めて意味のあるリファクタリングをするようだ
  ベンチマークはテストを隠し、失敗から合格に変わるフィードバックも与えないため、性能低下が単調に続いた可能性がある

  • それは単なる迷信

• 最近この論文とベンチマークを知ったが、プロダクションコードで常に重要だった非機能的・長期的要件を評価しようとする初期の試みに近い。今ではモデルが単発問題の大半を解けるほど良くなっているので、とくに時宜にかなっている
  決定的なスコアが出る点もよい。「保守可能性」は複数のシグナルで構成される高次元空間に近く、その空間を把握するには人によるラベリングが必要になる可能性が高い
  もう一つのシグナルはシステムの状態空間であり、最近は形式手法もよく登場している

  • システムの状態空間だけでなく、それをモデルがアクセスし、見られるようにする方法も重要。モデルに適した形で状態を「見せる」と、驚くような成果を出すことが多い
    環境にCLIを一つ追加するだけで大きな突破口が生まれるのも、複雑な状態を構造的に観察し操作できるようにするから
  • 「保守可能性」を単一の指標では有用でない多次元空間と表現したのは簡潔で正確
    データベースやサードパーティサービスに依存するプロダクションソフトウェア全体の状態空間は、測定が難しすぎるかもしれない。しかしシステムの一部を境界の明確な状態機械として分離できれば、クリーンなインターフェースの背後にあるモジュールの価値指標として活用できそう
    Kubernetesの制御ループが良い例。範囲が限定されたコンポーネントが、よく定義された状態機械の制御ループを担い、ほとんどのネットワーク分断や停止時にも動作し復旧する。CRDTの約束をより実用的に実装したアプローチに近い

• 大手研究所がこのベンチマークを強化学習パイプラインに活用してほしい。生成コードの複雑さを減らすことが最優先であるべきで、理想的なモデルは正しい抽象化を選んで機能を実装しつつ、コード行数も減らすべき
  このベンチマークで、コード複雑度を下げるプロンプトやスキルを反復改善できる点もよい

  • コード行数を減らすという名目で、あまりに多くのロジックを一行に詰め込む方向へ偏りやすくもある
  • 研究所は少なくとも公式にはベンチマークデータで学習しない。似た問題では学習できるが、ベンチマークに含まれる特定の文字列は学習コーパスから積極的に除外すべき

• 良いとは思うが、人間の性能との比較があればはるかに有用になる。難しいのは分かるが、多くの人がタイトルの数値だけを見て、Opus 5が人間の開発者の4分の1程度だと誤解する可能性が高い

• Opus 5はOpus 4.8より明らかに改善しているが、Fableで感じたほど革命的ではないという自分の実感と一致する
  今はOpus 4.8 xhighの代わりにOpus 5 mediumを使っており、トークン消費も少なく高速。文体を嫌う反応は理解できるが、実作業ではまったく気にならず、満足して使っている

  • Fableは性能が意図的に弱められたように見える。登場当初は本当に革命的だったが、禁止措置以前と現在のモデルは同じではない
  • Fableのどの部分が革命的に感じられたのか、もう少し詳しく聞きたい
  • なぜhighではなくmediumを選んだのか気になる。この性能チャートではmediumからhighへの向上はかなり大きく、highからxhighへの向上はそれほど大きくなかった

• これまでの解決策は、別途コードベース全体のレビューを定期的に実行し、可能ならFableで確認したうえで、結果に応じて複数回リファクタリングするというもの

  • 自分もこの方式が好み。そうしないと、過度に深い局所最適に陥るリスクが大きい

• 生のテスト結果が見たい。ほとんどのモデルはdatabase_migrationのチェックポイント2のテストでdefault_valueを見落としそう。これはJSONリテラルともSQL式とも解釈できるため
  論文で挙げられた原因とは無関係な理由で失敗しやすいテストが他にもあるかもしれない。依存関係が許す範囲でチェックポイントの順序を3→2→5→4のように変えれば、各チェックポイントの難易度差を制御できて興味深い実験になるはず

  • チェックポイントの順序を変えて結果を比較するという発想は気に入った。難易度を上げたり下げたりする方法としても使えそう
    情報を漏らさずに結果の一部をまとめて公開するのがどれほど簡単か見てみるつもりで、おそらく可能だと思う

• しばらく議論には参加していなかったが、この結果が出たのは喜ばしい。Opus 5は大きな改善ではないと感じており、本当に驚きを与えたのはOpus 4、4.6、そしてTrump政権による性能弱体化措置以前のFableだけだった

  • 今回の作業は、新モデルで最も速く安価に試せる出発点にすぎない
    今後はsolとFableも含め、より多くの言語を探索し、ベンチマークをより幅広く反映するよう問題セットを磨きたい
    個人的にはOpus 4.5が4.1より鈍く感じられた。4.5が2.5倍高速で2.5倍安いという点から、より小さいモデルだと推測してバイアスがかかっていたのかもしれない

• コード重複とコード行数全体にペナルティを与える敵対モデルを提供すれば、このベンチマークの性能をどの程度誘導できるのか気になる