
2026/10/16 4:09
スロップコードベンチ 10/2026 – オパス 5.5、アストラが総合優勝、xhigh は有害と評価される
RSS: https://news.ycombinator.com/rss
要約▶
日本語訳:
日付: 2026年10月15日 | 作成者: Dex Horthy
GPT-6 Astra は、直近で記録した最も高い厳格な合格率である 16.3% を達成し、GPT-5.5 の 5 月のベンチマークスコア(14.8%)を上回りました。これは、要件が進化しても既存のコード挙動を維持する能力に顕著な改善がもたらされたことを示しています。しかし、このトップクラスのモデルですら最終チェックポイントにおいて全てのテスト対象機能を維持することに苦しみ、AI エージェントにとってレガシーシステムをクリーンに保つことは依然として大きな課題であることが示されました。今回のベンチマークは、有効な比較を確保するために小さなサンプルではなく 36 の問題に対する全評価を実行するという手法に基づいています。特に、評価労力を増やすことはコストを最大 4 倍に引き上げる一方で、合格率の一貫した向上には至っていません。本レポートでは、2026 年第 4 四半期のこれらの結果を earlier(2026年5月)のベンチマークと比較しています。今後を見据えて、業界は評価用に小さなデータサブセットを使用するアプローチから転換し、Opus や Astra のような先進モデルによって新たに生成されたパターンの処理に対応できるようリンティングツールを更新する必要があります。また、ユーザーは、コストが低い GPT-6.1 Medium モデルが、厳格なコード維持におけるプレミアムリーダーと同等のパフォーマンスを発揮することを認識しておく必要があります。組織は、高コスト・高労力設定によって得られるコード品質への不確かな利益を慎重に検討し、それらのコストとのバランスを取る必要があります。
本文
スロップコードベンチマーク (SlopCodeBench) 更新レポート(2026 年 10 月) - Opus 5.5 と Astra のアップデート
日付: 2026 年 10 月 15 日
著者: Dex Horthy、Gabe Orlanski
注記: 本稿は、スロップ (Slop) の第 4 四半期に関するレポートの第 I 部です。 第 II 部では、Slop パターン分析と定性的な考察が公開されます。
概要
ベンチマーク結果のハイライト
- 過去比較: 5 月時点の
は厳密な通過率(strict pass rate)で**14.8%**を記録。gpt-5.5 - 最新最高成績: 今回のキャンペーンでは
が最高得点を記録し、厳密な通過率は**16.3%**となりました。**gpt-6 Astra** - 測定指標の定義:
- 厳密な通過率 (Strict): 全てのチェックポイントにおいて、すべてのテストケース(回帰テストを含む)をクリアした割合。
- コア通過率 (Core): Core カテゴリ内のすべてのテストがパスした割合(回帰テストは含まない)。
テスト対象モデル一覧
- Opus 5.5
- Fable 5.1
- SOL 6 および 6.1
- Astra
- GLM 5.3
パフォーマンス範囲:
- 厳密な通過率: 12.2% 〜 16.3%
- コア通過率: 65.8% 〜 74.0%
Medium(中規模)vs XHigh(超多資源)の意外な結果
- いくつかの新型モデルにおいて、「Medium」モードが「XHigh」モードよりも優れたパフォーマンスを発揮しました。
- コスト効率:
- Opus 5.5 は、Medium モードでのパフォーマンスが XHigh を上回りました。
- 完全なペアにおいて、XHigh のコストは Medium の2.11 倍〜4.22 倍に及びます。
スロップコードベンチマーク (SCB) の仕組み
ベンチマークの概要
- プロセス: コーディングエージェントに対し、問題を一連の段階で提示し、新たな要件に合わせて既存のコードを変更させます。
- 評価基準: 後期のチェックポイントでは、新しい振る舞いと古い振る舞いの双方がテストされます。
- 哲学: 「要件が曖昧でありかつ進化していく」ソフトウェア開発の実態を忠実に再現します。
再現手順 (Reproducibility)
結果を再現するための環境設定:
- カタログ: ピinned (固定化) された
カタログの使用。v1.0 - プロンプト: 標準の「just-solve」プロンプトの使用。
- ランダムシード:
の設定。42 - ランナー: Any-case ランナーのパスポリシーの利用。
- 環境: Python 3.12 と uv を搭載した Docker 環境。
仕組みの詳細:
- モデルと努力量 (Effort) の各組み合わせについて一度ずつ実行しました。
- チェックポイントは前回の結果を基盤とし、問題数に依存してチェックポイント数は異なります。
- チェックポイント数は異なっても、それぞれの通過率は同程度の重みを有します(チェックポイント数の多い問題はより大きな影響力を持ちます)。
コア通過率 vs. 厳密な通過率
定義の違い
| 指標 | 条件 |
|---|---|
| Strict (厳密) | すべてのテストカテゴリ(回帰テストを含む)がパスすること。 |
| Core (コア) | 空でない Core カテゴリ内の全てのテストがパスすること。 (例: チェックポイント 2 で失敗しても、後のチェックポイントで Core パスを獲得することはできません) |
統計概要 (サマリストティスティクス)
- 厳密な通過: 196 チェックポイント中、24〜32 チェックポイント。
- コアな通過: 196 チェックポイント中、129〜145 チェックポイント。
完全キャンペーンの結果一覧
モデル比較表
| モデル | 厳密な通過数 (32/196) | 厳密な通過率 | コア通過率 | 推定コスト |
|---|---|---|---|---|
| GPT-6 Astra XHigh | 32 | 16.33% | 69.39% | $758.62 |
| GPT-6 SOL Medium | 30 | 15.31% | 67.86% | $245.69 |
| GPT-6 Astra Medium | 29 | 14.80% | 66.33% | $261.05 |
| GPT-6.1 SOL Medium | 29 | 14.80% | 65.82% | $178.51 |
| Opus 5.5 Medium | 28 | 14.29% | 73.98% | $193.47 |
| GPT-5.6 SOL XHigh | 28 | 14.29% | 70.92% | $753.30 |
| Fable 5.1 XHigh | 26 | 13.27% | 72.45% | $1,550.07 |
| GPT-6 SOL XHigh | 26 | 13.27% | 68.37% | $517.32 |
| Opus 5.5 XHigh | 25 | 12.76% | 71.94% | $817.04 |
| GLM 5.3 XHigh | 24 | 12.24% | 66.33% | $365.13 |
重要な知見
- Astra の優勢:
が最も高い厳密な通過数(32)を記録しましたが、GPT-6 Astra XHigh
との差はわずか2 チェックポイントです。SOL 6.1 Medium - Opus の強み:
はコア成功率で首位(145/196)ですが、厳密なパス数は 28 でやや低めです。Opus 5.5
主要な洞察: Astra XHigh が最も高い厳密な通過数 (32) を誇りますが、Opus 5.5 はコア通過率で首位に立っています。
努力量と成果の関係
結論:コストの増大は必ずしも結果向上につながらない
- 傾向: すべてのペアにおいて XHigh(超多資源)はコストがかかりますが、厳密な成功数は Astra を除きほとんど向上していません。
- 限界: これらの単一の実行では、努力量自体が原因であることを完全に証明することは困難です(ランとラン間の変動の影響を特定できないため)。
モデル比較:Medium vs. XHigh (変化)
| モデル | 厳密: Medium → XHigh (変化) | コア: Medium → XHigh (変化) | 推定コスト倍率 |
|---|---|---|---|
| Opus 5.5 | 28 → 25 (-3) | 145 → 141 (-4) | 4.22 倍 |
| GPT-6 SOL | 30 → 26 (-4) | 133 → 134 (+1) | 2.11 倍 |
| GPT-6 Astra | 29 → 32 (+3) | 130 → 136 (+6) | 2.91 倍 |
コストパフォーマンスの分析
- 最も安価で優秀:
は記録されたコストが最低 ($178.51) で、Astra Medium と同数の厳密な通過数 (29) を誇ります。GPT-6.1 Medium - 非効率な例:
の見積もりコストは約8.68 倍に達しましたが、厳密な通過数は 3 つ少なくなっています。Fable 5.1 XHigh - 解釈: 「より多くの思考プロセスがコーディングを損なう」という証明ではなく、「努力量を投入しても厳密なパス数を信頼できる手段として購入できなかった」結果です。
最終コードの品質
最終チェックポイントサマリー
チェックポイントの成功は、動作するプログラムの存在を保証するものではありません。ここでは最後のチェックポイントのみがカウントされ、失敗したテストケースはバグではなく「スキップ」として別扱いになります。
| モデル | 厳密な最終チェックポイント (36 中) | 最終的に失敗したテストケース数 | そのうち回帰に失敗したもの |
|---|---|---|---|
| GPT-6 Astra Medium | 1 | 1,747 | 1,516 |
| GPT-6 SOL XHigh | 1 | 1,651 | 1,366 |
| Opus 5.5 Medium | 0 | 2,508 | 2,206 |
| Fable 5.1 XHigh | 1 | 2,463 | 2,126 |
| GPT-6 SOL Medium | 1 | 2,831 | 2,479 |
| Opus 5.5 XHigh | 1 | 2,446 | 2,123 |
| GLM 5.3 XHigh | 1 | 2,748 | 2,311 |
注記:
は最終チェックポイントにおいて厳密なパスを完璧に達成(失敗 0)しました。GPT-6 Astra Medium は最後のチェックポイントで厳密なパス 0、かつ多くのテストケースで失敗しました。Opus 5.5 Medium
コード品質に関する発見:曖昧さ (Blurry)
スロップコードの定義と測定方針
- 問題点: モデルは作業中に大量のジャンクコードやスクラッチコードを残していました。
- 判断基準: 「テスト、スクラッチコード、生成されたコピー」などはメインプログラムではないため、自動的にパス対象にはしません。
- 除外リスト: インストールパッケージ、仮想環境、キャッシュフォルダ(
,_work
,tmp
,temp
,scratch
,generated
,build
など)およびビルトインファイル(dist
など)を除外します。*_pb2.py
「Slop パーセント」の計算方法
- カバレッジ: スロップパターンと反復コードを検出フラグを立てたソースラインの割合。
- カウント方式: 複数のチェックでフラグが立った場合でも、各行は一度だけカウントされます。
- 重み付け: フラグされたライン数とソースライン数を合計し、より大きなプログラムほど重みを増やしてパーセンテージを求めます。
主要な観察事項
-
Opus のジレンマ (複雑性 vs クリーンさ)
はスロップパーセントが最も低く (77.75%) 、Medium では 94.25% です。Opus XHigh- しかし、Opus Medium がより多くの厳密なパスを達成した一方、Opus XHigh のコードの方が約5 倍ほどクリーンでした(通過数:28 vs 25)。
- 推測: 新しいモデルは新しい/異なるスロップパターンをもたらす可能性があります。
-
Opus Medium の残滓
- フィルタリング後も最も多くのコードを残しています。
ファイルのみを除外した際、41,265 ラインすべてが Opus Medium の最終_work
コードでした。dynamic_buffer- 総ソースライン数は 216,881 から 175,616 に減少し、スロップ存在率は 92.90% に低下しました。
-
複雑性
- 平均複雑性は
(3.57) で最も低く、Fable
(11.70) で最高でした。GPT-6 SOL Medium - ヘルパー関数を増やすと複雑性は下がるものの、それが必ずコードの変更しやすさや品質向上につながらないことを示唆します。
- 平均複雑性は
補足: 出力のより定性的な側面については、第 II 部にて Gabe の詳細な考察が共有されます。
私の結論
現在の状況と課題
- 主要な困難: エージェントはメインの振る舞いを正しく理解することはできても、要件変化に伴うすべてのテストされた振る舞いを維持するのは依然として難しいです。
- 進捗の鈍化: コードベース維持能力は向上していますが(5 月からの**14.8%から 9 月の16.3%**へ)、誰も信じるほど早く進化していません。
結論: 今後しばらくの間、スロップコードへの対策を継続してライトを点灯させる必要があると判断します。