メインコンテンツまでスキップ

コード・エロージョン：エージェントが、すでに作ったものを壊す理由

上級

あなたが読んだことのあるほぼすべてのコーディング・ベンチマークは、同じ問いを立てています。タスクが与えられたとき、エージェントはそれを解けるか？ 1つのプロンプト、1つのパッチ、1つの判定です。この設定は便利ですが、実際にお金を失わせる失敗モードを隠してしまいます。現実のソフトウェアは一度で書き上がることがないからです。仕様は動きます。先週作ったものを拡張します。そして本当に興味深い問いは、エージェントがその機能を書けるかどうかではなく、すでに動いていたコードにエージェントが何をするかです。

SlopCodeBench はまさにそれを測るために存在し、その結果は世間の議論が示唆するよりも悪いものです。論文自身の言葉では、「ソフトウェア開発は反復的だが、エージェント型コーディング・ベンチマークは、単発の設定によって設計上の問題を覆い隠している。」

今週このページを書く価値があった理由は2つあります。第一に、第三者によるキャンペーン報告 "SlopCodeBench 10/2026 – Opus 5.5, Astra wins overall, xhigh considered harmful" が、2026年10月15日に Hacker News で260ポイント・101コメントに達しました。7月の同じベンチマークに関する405ポイントの投稿に続くものです。第二に、その中で最も重要な数字をほとんど誰も引用していません。見出しは広まりましたが、リグレッションの統計、合格1件あたりのコストの計算、そして清潔さと正しさの逆転は広まりませんでした。

What you'll learn
  • SlopCodeBench が測るもの、すなわち SWE-bench 型ベンチマークが構造的に測れないもの — 全チェックポイントにわたってリグレッションテストを引き継ぐ、反復的な仕様の洗練 — を説明する
  • 2つの合格率を正しく読む：strict と core は同じ10のキャンペーンをほぼ逆順に並べ、どちらを引用するかで勝者が決まる
  • 報告が埋もれさせている統計を導く — 最終チェックポイントで失敗するテストの82%〜88%は、新しい要件ではなくリグレッションである
  • 労力（effort）を正直に価格づけする：合格したチェックポイント1件あたりのコストで、すべての medium キャンペーンがすべての xhigh キャンペーンに勝ち、最良と最悪で9.7倍の開きがある
  • 2つの発見をひるまずに同時に受け止める — xhigh の Opus 5.5 は明らかにクリーンなコードを書いたが、同じモデルの medium より通過したチェックポイントは少なかった
  • 論文で最も実行しやすい結果を適用する：クリーンなコードを書けとエージェントに伝えると最初のコミットは最大3分の1改善したが、劣化曲線はまったく変わらなかった

ベンチマークが実際にやっていること​

SlopCodeBench の作業単位はタスクではなく**軌跡（trajectory）**です。エージェントは問題を与えられて解答を書き、次に新しい要件を受け取り、自分自身の既存コードを修正しなければなりません。これを繰り返します。仕様は、実装の詳細は開いたまま、アーキテクチャ上の判断を迫る形で進化します。そして — これがこのベンチマークを効かせる仕組みですが — 以前のチェックポイントのテストは引き継がれます。チェックポイントを通過するには、新しい要件を満たし、かつ以前のすべての要件を動作させ続けなければなりません。

論文によれば規模は次のとおりです。36問題が合計196チェックポイントに分解され、オープンとクローズドのモデルファミリーにわたる15のコーディングエージェントが評価されています。

2つの指標が得られます。

  • Strict pass — すべてのテストが通ること。以前のすべてのチェックポイントのリグレッションテストをすべて含みます。
  • Core pass — より緩い基準で、現在の要件を満たしたことに点を与えます。

そして論文は、追跡する2つの劣化モードに名前を付けています。構造的エロージョンは複雑さが集中すること、つまりコードが少数の過負荷な箇所に固まっていくことです。**冗長性（verbosity）**は重複したコードが増殖することです。これらは雰囲気ではなく、測定されています。

見出しになるべき結果​

論文より：1つの問題でもエンド・ツー・エンドで完全に解いたエージェントはありませんでした。 15のエージェントのどれも、36の問題のどれもです。最良のエージェントでも**チェックポイントの14.8%**に到達しただけでした。

構造的エロージョンは軌跡の77%で、冗長性は75.5%で増加しました。473のオープンソースリポジトリのコーパスと比べると、エージェントが書いたコードは2.3倍の冗長性と2.0倍のエロージョンを示しました。

つまり基本的な主張は「エージェントは人間より少し散らかったコードを書く」ではありません。長期的な軌跡の4分の3で、エージェントが作業するほどコードは構造的に悪化し、最終状態は人間が出荷するものの約2倍エロージョンが進んでいる、ということです。

2026年10月のキャンペーン​

HumanLayer は、固定された v1.0 カタログに対し、標準の just-solve プロンプト、シード42、any-case ランナーの合格ポリシー、Python 3.12 と uv を使った Docker 上で、10の完全なキャンペーンを実行しました。モデルと労力の組み合わせごとに1回の実行です。

キャンペーンStrictStrict 率Core 率推定コスト
GPT-6 Astra XHigh32/19616.33%69.39%$758.62
GPT-6 SOL Medium30/19615.31%67.86%$245.69
GPT-6 Astra Medium29/19614.80%66.33%$261.05
GPT-6.1 SOL Medium29/19614.80%65.82%$178.51
Opus 5.5 Medium28/19614.29%73.98%$193.47
GPT-5.6 SOL XHigh28/19614.29%70.92%$753.30
Fable 5.1 XHigh26/19613.27%72.45%$1,550.07
GPT-6 SOL XHigh26/19613.27%68.37%$517.32
Opus 5.5 XHigh25/19612.76%71.94%$817.04
GLM 5.3 XHigh24/19612.24%66.33%$365.13

まず strict の列を見てください。フロンティア全体が**12.24%〜16.33%**の間に収まっています。最良と最悪の差は196件中8チェックポイントです。これらのモデルの1つが長期的な保守で決定的に優れていると言う人がいれば、それはノイズを読んでいるのです — とりわけ、各セルが1回の実行であることを踏まえれば。

引用する指標によって順位が入れ替わる​

これは、どれかを引用する前に身につけておくべき部分です。

  • GPT-6 Astra XHigh は strict で1位（16.33%）、core で5位（69.39%）。
  • Opus 5.5 Medium は strict で5位（14.29%）、core で1位（73.98%）— 表の中で最良の core 率です。
  • GPT-6.1 SOL Medium は strict で4位タイ（14.80%）、core では最下位（65.82%）。

同じ10回の実行、同じデータで、表彰台が入れ替わります。2つの指標は本当に異なるものを測っています。core 率は「新しいことをどれだけ達成したか」、strict 率は「古いものを壊さずに新しいことをどれだけ達成したか」です。一方が得意で他方が平凡なモデルもあり、これらの大半がそうです。

このページから1つだけ覚えるなら：コーディングエージェントの数字が、どちらの合格率を指しているのかを尋ねてください。 同じデータセット上の1つのモデルで14.29%と73.98%という差があること、それが議論のすべてです。

誰も引用しない統計：新機能ではなくリグレッションだ​

報告は、最終チェックポイントでの失敗したテストケースの表と、そのうちリグレッションによる失敗が何件だったかを別に公開しています。一方の列をもう一方で割ると、このベンチマークの主張は主張ではなくなります。

キャンペーン最終的な失敗テストリグレッションリグレッションの割合
Opus 5.5 Medium2,5082,20688.0%
GPT-6 SOL Medium2,8312,47987.6%
GPT-6.1 SOL Medium2,7572,40487.2%
GPT-5.6 SOL XHigh2,7272,37687.1%
GPT-6 Astra Medium1,7471,51686.8%
Opus 5.5 XHigh2,4462,12386.8%
Fable 5.1 XHigh2,4632,12686.3%
GLM 5.3 XHigh2,7482,31184.1%
GPT-6 SOL XHigh1,6511,36682.7%
GPT-6 Astra XHigh1,4351,17882.1%

リグレッションの割合の列は、報告が公開している件数に対する算術であり、報告自身が述べている数値ではありません。10のキャンペーンすべてで**82.1%〜88.0%**の間に収まっており、4つのモデルファミリーにわたる10の異なる構成としては驚くほど狭い範囲です。

もう一度読んでください。フロンティアのコーディングエージェントが長い反復タスクの終わりで失敗するとき、おおよそ7件の失敗のうち6件は、以前は動いていたものです。実際に頼まれた機能に関するものは、およそ7件に1件にすぎません。

Watch out
  • これは、モデルの選択ではなく、あなたのハーネスを変えるべき数字です。フロンティアモデル間の strict 率の4〜6ポイントの差は、1回の実行のノイズの範囲内です。85%前後というリグレッションの割合は、エージェントがコードを編集する仕組みの構造的な性質であり、CI、テスト保持の方針、レビュープロセスが実際に手を打てる対象です。
  • また、エージェントが測定値よりも良く感じられる理由も説明します。機能を頼み、それが入るのを見て、出荷する。リグレッションは3チェックポイント先にあり、誰も古いテストを再実行していません。

「xhigh は有害とみなされる」​

さて、この投稿をトップページに押し上げた発見です。3つのモデルが medium と xhigh の両方の労力で実行されました。

モデルStrict：Medium → XHighCore：Medium → XHighコスト倍率
Opus 5.528 → 25145 → 1414.22×
GPT-6 SOL30 → 26133 → 1342.11×
GPT-6 Astra29 → 32130 → 1362.91×

3モデル中2つは、労力を上げると strict の合格数が悪化し、しかもコストは2.11倍〜4.22倍かかりました。著者の言葉では、「opus 5.5 は xhigh よりも medium の労力のほうが良かった。」

大いに評価すべきことに、著者は過大に主張しません。報告は、この発見が*「推論を増やすとコーディングが悪化することを証明するものではない」とし、示すのは「高い労力は、より多くの strict 合格を買う確実な方法ではなかった」ことだけだと述べています。そして方法論上の注意点もはっきり述べられています：「各モデルと労力の設定を1回ずつ実行した…… これらの単発の実行では、労力を原因として切り分けられない。」*

その注意点は本物であり、手放さないでください。196件中3チェックポイントの揺れは、同じ構成を2回実行した間に予想される分散の範囲内に十分収まります。生き残るのは弱い主張です：長期的な作業において、労力は正しさを確実に買えるダイヤルではない。 強い主張 — xhigh が積極的にコーディングを損なう — は、このデータでは確立されておらず、著者もそう主張していません。

証拠がはるかに強くなるところ：合格1件あたりのコスト​

労力の表はノイズが多いです。しかし経済性はそうではありません。ここではコストの差がノイズを圧倒するほど大きいからです。推定コストを strict の合格数で割ると：

キャンペーン労力strict 合格1件あたりの $
GPT-6.1 SOL MediumMedium$6.16
Opus 5.5 MediumMedium$6.91
GPT-6 SOL MediumMedium$8.19
GPT-6 Astra MediumMedium$9.00
GLM 5.3 XHighXHigh$15.21
GPT-6 SOL XHighXHigh$19.90
GPT-6 Astra XHighXHigh$23.71
GPT-5.6 SOL XHighXHigh$26.90
Opus 5.5 XHighXHigh$32.68
Fable 5.1 XHighXHigh$59.62

これは報告の公開数値に対する私の算術であり、パターンは例外がありません：すべての medium キャンペーンは、すべての xhigh キャンペーンよりも、合格したチェックポイント1件あたりで安い。 重なりはありません。最良から最悪までの開きは9.7倍です。

データセット全体で最も際立った比較：xhigh の Fable 5.1 は、26チェックポイントを通すのに $1,550.07 を使いました。medium の Opus 5.5 は、28を通すのに $193.47 でした。 8倍のお金で、合格は2件少ない。

Pro tip
  • 実行可能な形にすると：長期の反復コーディングでは medium から始め、xhigh にお金を払う前に、あなた自身のワークロードで価値を証明させてください。デフォルトはすでにその方向に傾いています — Opus 5.5 と Haiku 5.5 は medium がデフォルトで、Sonnet 5.5 でのエージェント型コーディングの推奨開始労力も medium です。
  • 比較を行うなら、各構成を複数回実行してください。このベンチマークの解像度での単一キャンペーンでは、3チェックポイントの労力効果と3チェックポイントのコイン投げを区別できません。

クリーンになったのに、動く頻度は下がるコード​

これは本当に言い逃れしにくい結果であり、報告の中で最も興味深いものです。

xhigh の Opus 5.5 は、medium の Opus 5.5 より strict で通過したチェックポイントが少なく、それでいてスロップ指標では明らかに優れたコードを書きました。一致する28問題で、スロップのカバレッジは xhigh が 77.75%、medium が 94.25%（フィルタ後 92.90%）でした。著者は xhigh の出力を*「約5倍クリーン」*と特徴づけています。

その数字については、引用の仕方に関わるので注記します。約5倍というのは、著者による複合スロップ指標の特徴づけです。上の2つのカバレッジ率からは導出できません。それらの差は約16ポイントであって、5倍ではないからです。検証可能なものが必要なら、カバレッジの数値を引用してください。「約5倍クリーン」は、内部を見ていない指標についての方向性の主張として扱ってください。

いずれにせよ方向は一貫しており、含意は不都合です：推論の労力を増やすと、見た目は良くなり、機能は悪くなるコードが買えた。 労力は部分的にアーキテクチャ上の趣味 — リファクタリング、抽象化、整頓 — を買っているようで、それらの編集こそが、すでに動いていたコードを壊すものです。整頓はリグレッションのリスクです。醜くても動いているものをそのままにするモデルは、以前に何が通っていたかを覚えているベンチマークでは、より良いスコアを取ります。

合格率とコード指標のあいだの乖離についての報告の推測は、繰り返す価値があります。新しいモデルは、既存のリンターがまだ検出できない新しい種類のスロップのパターンを生成している可能性があります。これは、エージェントの出力に対するクリーンなリント報告は、あなたのコードについてと同じくらい、あなたのリンターについての証拠でもある、という良い注意喚起です。

指標に表れる、正反対の2つのアーキテクチャ・スタイル​

もう1つ、見落としやすく、静かに多くを物語る詳細があります。関数・メソッド全体の平均循環的複雑度：

  • Fable 5.1：8,967 個の callable、平均複雑度 3.57
  • GPT-6 SOL Medium：1,083 個の callable、平均複雑度 11.70

同程度の問題で、書かれた関数の数には8.3倍の差があります。Fable は多数の単純な単位へ積極的に分解し、GPT-6 SOL ははるかに少数で、はるかに密度の高いものを書きます。平均複雑度だけで順位づけすれば Fable が3倍で勝ちます。callable の数で順位づけすれば話は逆転します — それらの小さな関数の山こそ、冗長性が住む場所でもあるからです。

どちらの数字も、単独では何も意味しません。これはエージェントの出力に対するコード品質指標についての一般的な教訓です：どの指標もアーキテクチャ・スタイルによって操作可能なので、ペアで読んでください。

実際に何をすべきか​

論文は明白な介入を試しており、その結果はもっと知られるべきです：品質を明示する指示は、初期の問題を最大3分の1減らしたが、劣化のパターンには影響しなかった。

クリーンなコードを書けとエージェントに伝えるのは、一度は効きます。最初のコミットを改善します。腐敗は止めません。エロージョンはエージェントの最初の意図ではなく反復的な編集プロセスの性質なので、意図に向けた指示はそれに触れないのです。

つまり修正は、プロンプトよりも居心地の悪い場所にあります。

Guided walkthrough1 of 5
  1. 82〜88%というリグレッションの割合は、古いテストがまだ実行される場合にしか見えません。あなたのエージェントのループが現在の要件だけを検証しているなら、core の合格率を測りながら strict の失敗を出荷していることになります。これは利用できる中で最もレバレッジの高い変更です。

自分で確かめよう

0/6
  1. SlopCodeBench は、単発のコーディング・ベンチマークが構造的に測れないどんなことを測りますか？
  2. 2026年10月の10のキャンペーン全体で、最終チェックポイントで失敗したテストのうち、新しい要件ではなくリグレッションだった割合はおよそどれくらいですか？
  3. GPT-6 Astra XHigh は strict 合格率で1位、core で5位です。Opus 5.5 Medium は strict で5位、core で1位です。何を結論すべきですか？
  4. 2026年10月のデータが実際に裏づける労力についての主張はどれですか？
  5. xhigh の Opus 5.5 は medium より測定可能なほどクリーンなコードを書きましたが、通過した strict チェックポイントは少なくなりました。最も妥当な解釈はどれですか？
  6. 論文は、品質を明示する指示が初期の問題を最大3分の1減らしたことを見いだしました。それが「しなかった」ことは何ですか？
Key takeaways
  • SlopCodeBench はタスクではなく軌跡を測る：仕様が進化するなかでエージェントが自分のコードを拡張し、以前のテストはすべて引き継がれる。1つの問題をエンド・ツー・エンドで完全に解いたエージェントはなく、フロンティア全体は strict で12.24%〜16.33%に集まる。
  • strict と core の合格率は、同じ10のキャンペーンをほぼ逆順に並べる。Opus 5.5 Medium は strict 14.29%、core 73.98%。数字がどちらを指すのかを必ず尋ねること。
  • 最終チェックポイントで失敗するテストの82〜88%は、新しい要件ではなくリグレッションである — 7件の失敗のうち6件は以前に動いていたもの。これはモデル選択の問題ではなく、ハーネスの問題だ。
  • strict 合格1件あたりのコストで、すべての medium キャンペーンがすべての xhigh キャンペーンに勝ち、重なりはなく9.7倍の開きがあった。Fable 5.1 XHigh：26合格に $1,550、Opus 5.5 Medium：28合格に $193。
  • 労力は部分的に整頓を買い、動いているコードの整頓はリグレッションを引き起こす。xhigh の Opus 5.5 はクリーンなコードを書いたが通過したチェックポイントは少なかった — だからリファクタリングは追加よりも厳しくレビューすること。
  • クリーンなコードを書けとエージェントに伝えると最初のコミットは最大3分の1改善したが、劣化曲線には何も起きなかった。エロージョンは編集プロセスに宿るので、保持したテストとチェックポイントごとの測定で直すこと。
  • コード品質の指標はペアで読むこと：平均複雑度3.57で8,967個の callable と、11.70で1,083個は、2つのアーキテクチャ・スタイルであり、どちらの指標も単独では順位を逆に並べてしまう。

出典とさらなる読み物​

次へ​