AI コーディングモデルの評価で信号とノイズを見分ける — SWE-bench が揺らいだ理由

はじめに — リーダーボードはなぜ信じにくくなったのか
信号とノイズという二つの軸
コーディングベンチマークのノイズはどこから来るのか
チームが実際にやるべきこと
おわりに
参考資料

はじめに — リーダーボードはなぜ信じにくくなったのか

コーディングモデルの SWE-bench スコアは毎週更新されますが、いざ自分のコードベースに組み込むと順位と体感がずれる、という経験はよくあります。いま GeekNews で話題の OpenAI 評価チーム（Frontier Evals）による記事 "Separating signal from noise in coding evaluations" は、このズレを正面から扱います。結論はかなり強めです — 最も広く使われるコーディングベンチマークである SWE-bench Verified が、汚染と設計上の欠陥のためにもはや意味のある信号を与えない というものです。

これは「ベンチマークはもともと完璧ではない」という定番の言い訳ではありません。要点は 信号（signal）とノイズ（noise）を分けて見る という方法論です。本稿はそのレンズでコーディング評価を整理し、チームが実際に何をすべきかまで踏み込みます。

タイミングも効いています。コーディングモデルはほぼ毎週登場し、チームはリーダーボードの小数点の差一つで実際の導入判断を下すことが増えました。その差がノイズなら、その判断は実験着を着たコイン投げにすぎません。

信号とノイズという二つの軸

Allen Institute for AI（Ai2）のフレームが、定義を最も明快に与えてくれます。

信号はベンチマークの 識別力 です — より良いモデルとより劣るモデルのスコアをどれだけ引き離すか。Ai2 はこれを「特定の規模におけるモデルの散らばり」として測ります。
ノイズ は同じモデルを再実行したとき（あるいは学習チェックポイントごと）にスコアが揺れる 変動性 です。

良いベンチマークは両者の比、すなわち 信号対ノイズ比（SNR） が高いものです。面白いのは、大きさが答えではないという点です。Ai2 の実験では、SNR の高い 16 個の MMLU サブタスクだけを使ったほうが全 57 個より優れており、誤差が 32% 減りました。 採点指標を正解/不正解から bits-per-byte に替えると、MBPP の SNR は 2.0 から 41.8 へ跳ね上がりました。

Ai2 は、この比がベンチマークの大きさよりも有用性をよく予測すると報告します — SNR の高い指標に替えると、二つのモデルのうち良いほうを正しく選ぶ「決定精度」が 68% から 93% へ上がりました。小さく綺麗な評価が、大きく騒がしい評価より信頼できることがある — 多くのリーダーボードが前提としていない直感です。

実務に落とすと規則は一つです — 二つのスコアを比べるとき、まずその差がノイズより大きいかを問え。 順位表の 1 位と 3 位がノイズの帯の中にあるなら、その順位は情報ではなく錯覚です。

コーディングベンチマークのノイズはどこから来るのか

コーディング評価のノイズは、大きく四つの方向からやってきます。

1）汚染（contamination）。 OpenAI の評価チームは、モデルが task_id だけから元の gold patch や問題文をほぼそのまま再生産できることを示しました。これはソフトウェアを書く能力ではなく、学習データを暗記した結果です。スコアは上がりますが、信号は上がりません。

2）採点の欠陥（design flaws）。 同じ記事は、SWE-bench Verified の残る未解決問題のうち 60% 以上が採点基準上そもそも解けない ものだと指摘します。機能的に正しい提出を 49 個のテストが誤りと判定し、26 個のテストは仕様書にない挙動を要求します。モデルが正解しても 0 点になる構造です。

3）ハーネス・インフラの差。 Anthropic は、モデルの重みを一切変えずに 実行環境を調整するだけで スコアが動くことを測定しました。Terminal-Bench 2.0 では、資源を最も潤沢に与えた設定と最も切り詰めた設定の差が 6 ポイント（p < 0.01） で、インフラのエラー率は 5.8% から 0.5% へ下がりました。順位を分けているのがモデルではなくコンテナ設定かもしれない、ということです。

4）過学習・摩耗。 新しいベンチマークも長くは持ちません。Verified の改善を狙った SWE-bench Pro でさえ、独立した監査では自動パイプライン基準で 27.4%、人手レビュー基準で 34.1% の課題が壊れていました。しかも同じモデルがベンチマークを替えるだけで大きく揺れます — ある報告では、同一モデルが SWE-bench Verified で約 81%、より難しい SWE-bench Pro で約 46% を記録しました。

厄介なのは、これらの効果が単調でないことです。Anthropic は、資源の余裕を適度に変える程度では差がノイズの中に収まる（統計的に無意味、p = 0.40）一方、両極端では大きく開くことを確認しました — SWE-bench では、一つの課題に RAM を 5 倍与えてもスコアは約 1.54 ポイントしか動きませんでした。同じつまみが、ある範囲では無視でき、別の範囲では決定的になります。ハーネスの差が目の前で隠れる仕組みが、まさにこれです。

チームが実際にやるべきこと

リーダーボードはモデルを訓練する人には信号でも、アシスタントを選ぶチームにとっては多くがノイズです。実務の指針はこうまとめられます。

自分の課題で評価する。 チームの実際の PR・課題を 30〜50 件集めて小さなプライベート評価セットを作りましょう。リーダーボード 1 位より「自分たちのコードベースでの通過率」のほうがずっと強い信号です。
順位ではなく信頼区間を見る。 Anthropic の助言は明快です — 3 ポイント未満のリーダーボード差は、評価設定が文書化され揃えられるまで懐疑的に 扱え。
汚染に強い設計を選ぶ。 時間カットオフを回す方式（LiveCodeBench）や非公開テストセット（GAIA）が、暗記スコアを構造的に防ぎます。
ハーネスを固定し文書化する。 プロンプト・再試行・タイムアウト・資源上限を明示しない比較は、りんごとみかんを比べているのと同じです。
評価を公開するなら較正する。 Anthropic の提案は、課題ごとに資源の下限と上限を併せて指定し、両端のスコアが互いにノイズの範囲に収まるよう調整することです — さもないと設定が密かにスコアの一部になります。
複数の種類で三角測量する。 静的ベンチマーク・人手選好アリーナ・エージェントスイートを併せて見れば、一つの軸のノイズが互いに打ち消し合います。
複数回実行する。 一発の合否実行は変動を隠します。課題ごとに 3〜5 回回せばスコアの幅が見え、その幅こそ見抜くべきノイズです。
飽和に注意する。 上位モデルが数ポイント内に固まっているなら、そのベンチマークはすでに識別をやめています — 信号が低く、その中の順序はほぼランダムです。

具体的にはこうします — スキャフォールドを一つに固定し（同じプロンプト・同じ再試行方針・同じタイムアウト）、各モデルをプライベートな課題セットで複数回回し、平均と幅を併せて報告します。二つのモデルの幅が重なるなら勝者はいません — 引き分けであり、そのときは価格・レイテンシ・ライセンスで決めるほうが良いのです。

これらはすべて eval-first の原則 に収束します。モデル（やアシスタント）より評価セットが先だ、という AI モデル開発ライフサイクルの記事で述べたのと同じ順序です。評価が先にあれば、どのモデルを使うかの判断が好みではなく実験になります。

おわりに

信号とノイズを見分けることは、結局のところ謙虚さの問題です。リーダーボード最上位の小数点以下数桁はおおむねマーケティングであり、本当の信号は 自分の課題で再現される差 です。OpenAI は汚染と採点の欠陥から、Anthropic はインフラの変動から、Ai2 は統計的識別力から出発しましたが、到達点は同じです — 一つの数字を信じず、その数字がノイズより大きいかを問え。コーディングアシスタントを選ぶチームにとって、これほど実用的な助言はそう多くありません。

とはいえ、ベンチマークが無用というわけではありません — モデルを訓練する人にとっては欠かせない道具です。ただリーダーボードは問いの出発点であって、答えではないということです。