Opus 5は長期保守で使えるか SlopCodeBench検証

「ベンチマークのスコアは上がったのに、長く運用するとコードが読めなくなる」。

AIコーディングを実務で回していると、この落差にぶつかりますよね。

SlopCodeBenchでClaude Opus 5を検証したデータは、その落差を「Opus 5すごい」だけでは終わらない捻れた形で見せてくれました。

SlopCodeBenchはコードが育つ過程を丸ごと採点する

SlopCodeBenchは、2026年に公開された長期保守向けのベンチマークです。

普通のコーディングベンチと違うのは、問題の全体像を最初に見せない点なんですよ。

チェックポイントごとに新しい要件が小出しにされて、モデルはその都度コードベースを継ぎ足しながら育てていきます。

合格（strict pass）の条件も厳しくて、新しく追加されたテストだけでなく、それまで通っていた回帰テストを全部維持できて初めて1点です。

検証に使われたのは3問題で、合計17チェックポイント。

circuit_evalが易しめで8、database_migrationが中くらいで5、dynamic_config_service_apiが難しめで4という構成でした。

SWE-benchのような一発勝負のissue解決と何が違うかというと、「機能を足すたびにコードベースが壊れていかないか」を累積で見るところです。

これ、実務の長期保守そのものなんですよね。

1個の機能を綺麗に書けるかより、10個目の機能を足したときに最初の機能がまだ生きているか。

そこを測るベンチだと思ってください。

GitHub - SprocketLab/slop-code-bench: SlopCodeBench: Measuring Code Erosion Under Iterative Specification Refinement

SlopCodeBench: Measuring Code Erosion Under Iterative Specification Refinement - SprocketLab/slop-code-bench

github.com

Opus 5のpass率は24% 最終地点には一度も届かない

数字だけ見ると、Opus 5は大きく伸びています。

17チェックポイント中4つをstrict passで、pass率24%。

同じ条件で回すとOpus 4.8とSonnet 5は6%どまりなので、4倍のスコアです。

Opus 4.6とGPT-5.4は原論文の値、Opus 4.8とSonnet 5は同じ条件での再検証値です。

ただ、ここで満足すると読み違えます。

通った4つのうち3つは、易しいcircuit_evalの最初の3連続チェックポイント。

残る1つもdatabase_migrationの1個目でした。

裏を返すと、3問題のどれも最終チェックポイントには一度も到達できていない。

要件が積み上がった後半で、必ず力尽きているんです。

「6%が24%」はたしかに前進です。

でもそれは序盤の簡単な区間を拾えるようになっただけで、長く育て続ける区間はまだ越えられていない。

ここが今回のいちばん大事な前提になります。

関数はOpus 4.8の5倍 でも複雑度はむしろ下がる捻れ

一番おもしろい（そして少し怖い）のは、生成されるコードの量です。

同じ問題セットを解く過程で、Opus 5はOpus 4.8の約5倍の関数を書きました。

総ソース行数は29,065行、そのうち51%がテストコード。

Opus 4.8は約9,000行（テスト比率11%）なので、単純な量で3倍以上に膨らんでいます。

ここで「関数が5倍なら、さぞ複雑で汚いコードだろう」と思いますよね。

ところが逆でした。

Opus 5は関数を大量に書くのに、1関数あたりの循環的複雑度はモデル中で最も低い水準を保っています。

コード重複率も2.41%から2.64%とほぼ横ばい。

対するOpus 4.8は重複が4.6%から16.8%へ跳ね上がり、複雑度も70%増、単一の関数で93に達した箇所までありました。

使い回しの効かない単発関数の割合も、Opus 5は14.9%と一番低い（Sonnet 5は71.5%）。

同じ関数を複数箇所で再利用できているということです。

つまりOpus 5は、4.8で問題だった「1つの関数がどんどん太って汚れる」現象を、「小さくて綺麗な関数を大量に生やす」方向で回避している。

個々の部品はむしろ改善しているんですよ。

捻れているでしょう。

Claude Opus 4.8 — Claude Codeで使い倒した5つのリアル

こんにちは。もるふぉです。日本時間2026年5月29日（米国西海岸時間では5月28日）、Anthropicがclaude-opus-4-8を正式リリースしました。価格は据え置きでベンチマークは全方位で底上げ、しかも個人的に一番効いたのは「エージェントが嘘をつかなくなった」感触の改善です。公式発表が出てすぐ、Cla...

aimanavo.com

長期保守でOpus 5を無人運用できるか

じゃあ部品が綺麗なら長期保守も安心かというと、そう単純じゃないんですよ。

保守する人間の負荷は「1関数の複雑さ」だけで決まりません。

同じ機能を実装するのに3倍の行数、5倍の関数が並んでいたら、全体像を頭に入れる時点でしんどい。

1つ1つは読めても、5倍の数を追いかけ続けるのは別のコストなんです。

しかもOpus 5は最後まで到達できていない。

pass率24%は、要件が積み上がる後半で崩れた結果でした。

TypeScriptで密度を測るとOpus 5のスロップ指標は企業モノレポの11.6倍という数字も出ています。

量で押し切るスタイルの副作用ですね。

検証の結論も歯切れがよくて、「1つずつissueを積み上げる現実的な開発では、今のモデルはステアリング無しの無人運用には任せられない」と言い切っています。

私の実感とも一致します。

Opus 5は「作る相棒」としては4.8より確実に上。

でも長期保守のコードベースを渡して放置できるかというと、まだ人間が設計の芯を握っていないと危ない。

これはOpus 5を貶める話ではなく、線引きがどこにあるかの話です。

肥大化を抑えるステアリング設計 実務で効く3つ

現状のモデルを長期案件に入れるなら、量が膨らむ前提でステアリング（誘導）を設計するのが現実解です。

私が普段やっているのは次の3つです。

1. スコープを小さく渡す。問題全体を一度に投げず、チェックポイント1つ分くらいに刻んで渡します。CLAUDE.mdに「既存の関数を優先して再利用する」「新規ファイルは必要最小限」と制約を書いておくと、勝手に並行実装を生やすのを抑えられます。

1. 読ませる範囲を絞る。コードベースが育つほど、AIは自分から見えていない既存実装を無視して同じ機能を作り直します。関連する部分だけを渡す仕組みを噛ませると、重複の発生源をかなり潰せます。

code-review-graphとは何か。AIに読ませる範囲を絞るMCP

Claude Code で大規模リポジトリを触ると、無関係なファイルまで読まれてコンテキストが枯渇しがち。code-review-graph は Tree-sitter でコードをグラフ化し、MCP で「変更の影響範囲」だけを AI に渡します。GitHub Trending 週次5位、2万1千スター超。code...

aimanavo.com

1. 芯だけ人間が握る。設計判断とアーキテクチャの境界は人間が決めて、生成量の多いモデルには実装とテストを任せる。レビューか別モデルでのガードを1枚挟むと、量に飲まれずに済みます。この「どこまでAIに読ませ、どこから人間が握るか」という発想は、context engineeringの考え方とそのまま地続きです。

Loop EngineeringはGraph Engineeringの中にある

「まだループの話してるの、それとももうグラフにシフトした？」Graph Engineeringという言葉は、ここ数日でX(旧Twitter)を横断して広がっています。震源はPeter Steinbergerさんが2026年7月18日に投げた、たった12ワードのこの問いでした。「え、ループもう古いの？」と一瞬固まっ...

aimanavo.com

まとめ SlopCodeBenchが映すAIコーディングの次の課題

SlopCodeBenchが突きつけたのは、AIコーディングの課題が「1つの関数を綺麗に書けるか」から次の段階に移ったことです。

そこはOpus 5がかなり解いてしまった。

残った宿題は、量を膨らませずに長い進化を最後まで走り切れるか、そして人間がどう芯を握るか。

コード品質の評価軸が「読みやすさ」から「育て続けられるか」へ移ったと言い換えてもいいです。

実務で長期案件にOpus 5を入れるなら、まず自分の手元で生成量を測ってみてください。

同じ機能で行数が膨らんでいないか、それを見るだけでも保守の未来はだいぶ変わります。

速いモデルほど、手綱の設計がものを言う時代になってきました。