コーディング評価の signal と noise を運用者目線で切り分ける

ベンチマークのスコアは signal と noise が混ざっている

AI コーディングツールのベンチマーク（性能を測る共通問題集）のスコアは、モデルの実力（signal）と、問題や採点側の欠陥・ばらつき（noise）が混ざった数字です。2026 年 2 月、OpenAI がその noise の中身を実名で開示しました。運用者の仕事は、リーダーボードの数字を鵜呑みにせず、この 2 つを自分で切り分けることだと私は考えています。

私は普段 Rails の API と Next.js のフロントを回していて、コーディングエージェントをどこまで本番作業に入れるかを毎月のように見直しています。判断材料はベンダーの発表スコアですが、あの数字がどこまで信じられるのかは、正直ずっと曖昧なままでした。今回の OpenAI の記事は、その曖昧さの正体を「壊れたタスク」「データ汚染」「統計のばらつき」の 3 つに分解してくれます。

数字を先に置きます。OpenAI は 2026-02-23 の分析で、広く使われてきた SWE-bench Verified というベンチマークについて「もう最前線の実力を測れていない」と結論づけ、スコアの報告をやめました。理由がなかなか重い。以下、運用に効く順で読んでいきます。

SWE-bench Verified で起きたこと — 壊れたテストと汚染

一番効いたのは「採点が壊れていた」ことです。OpenAI が難問 138 問を精査したところ、そのうち 59.4% で、機能的には正しい解を弾いてしまう欠陥テストが見つかりました。モデルが正しく直しても不正解にカウントされていた、という問題が半数以上に混ざっていたわけです。

もう一つが汚染（contamination、テストの答えが学習データに紛れ込んでいる状態）です。OpenAI は GPT-5.2・Claude Opus 4.5・Gemini 3 Flash という各社の最前線モデルに、ベンチマークの模範解答を学習した痕跡があると報告しました。GPT-5.2 は最小限のヒントだけで Django の認証修正パッチをそっくり再現し、別のモデルは見たことがないはずの模範解答のコメントを一語一句そのまま引用したそうです。

ここで大事なのは、OpenAI が自社の GPT-5.2 も汚染側に挙げている点です。特定の他社を叩く話ではなく、「公開データから作ったベンチマークは、そのうち全モデルの学習データに溶けていく」という構造の話として読むのが正確だと思います。公開クロールで作った問題は、時間が経つほど signal が薄れていく宿命がある。

SWE-bench Pro に移してもゼロにはならない

OpenAI は主軸を SWE-bench Pro に移しましたが、これで問題が消えるわけではありません。Pro でも壊れたタスクは推定でおよそ 3 割あるとされ、汚染も「Verified より稀で軽い」という相対評価にとどまります。ベンチマークの乗り換えは noise を減らす作業であって、ゼロにする作業ではない。

欠陥タスクには型があります。指示が曖昧なのに採点は厳格、というミスマッチです。タスク文が「バグを直せ」程度にしか書かれていないのに、採点コード（verifier、正解かどうかを機械的に判定する仕組み）が特定の実装を前提にしていると、別解として正しいコードが機械的に落とされます。人間のレビュアーなら通す解を、狭い verifier が拒否する構図です。

OpenAI の処方箋は「自動抽出より、少し手をかけた問題づくりへ」というものでした。リポジトリから機械的に issue を引っこ抜くのではなく、人が verifier の妥当性まで見て作る。手間は増えますが、その手間こそが noise を削る唯一の場所だ、という主張です。私はこの結論に賛成で、評価は結局のところ、作る側の丁寧さがそのまま質になると感じています。

noise を測る — 信頼区間と bootstrap

スコアを一つの数字で出すのはやめたほうがいい、というのが統計側の教訓です。OpenAI は pass@1（1 回の試行で正解する割合）に 95% 信頼区間（真の値がこの幅に入るという確からしさの範囲）を付け、bootstrap（試行データを再抽出して分布を近似する手法）で算出しています。数字は点ではなく幅で見る、という当たり前を徹底しているわけです。

ただし OpenAI 自身が注意書きも添えています。この bootstrap は問題ごとの試行を再サンプルするので、データが極端に小さいと不確実性を過小評価する。捉えているのは試行のばらつきだけで、問題そのもののばらつきまでは織り込めていないからです。「信頼区間が狭い＝安定」ではなく、「問題数が少なすぎて狭く見えているだけ」の可能性が残る。

運用側の実感としても、これは効きます。私の観測でも、同じエージェントを同じ 30 問に当てても、走らせる日によって数問は結果が入れ替わる。1 回のスコアで「A は B に 3 ポイント勝った」と言い切るのは危うい。その 3 ポイントが信頼区間の幅の中に収まるなら、それは勝敗ではなく誤差です。

自組織で AI コーディングツールを評価するときの実務

自分の組織でツールを選ぶなら、公開ベンチマークは参考程度にして、自前の小さな eval を持つのが一番堅いです。理由は汚染を避けられるからで、公開されていない自社リポジトリのタスクなら、モデルがあらかじめ答えを見ている可能性がほぼありません。signal が濁っていない土俵を自分で用意できます。

手順はそれほど大げさではありません。まず自社の閉じたコードベースから、実際に起きた修正タスクを 20〜30 件選びます。次に各タスクをモデルに複数回（私は 5 回）走らせ、pass 率とそのばらつきを一緒に記録する。最後に失敗ケースを人の目で開き、「モデルが本当に間違えた」のか「採点や指示が壊れていた」のかを仕分けます。この仕分けこそが signal と noise の切り分けそのものです。

一つ釘を刺しておくと、ベンチマークは Goodhart の法則（指標が目標になると指標として壊れる現象）に弱い。タイムアウトやハードウェア構成を調整してスコアを盛る、いわゆる benchmaxx は現に起きています。だから社内 eval も「点を上げる」ためではなく「実作業で使えるか」を測るために回す、という姿勢を崩さないほうがいい。単発の合否より、繰り返し使ったときの安定性のほうが現場では効きます。関連する考え方は評価をテストとして扱う話でも触れました。

私ならこう組む — 小さく始める内製 eval

私のやり方はごく単純です。「20〜30 問 × 5 試行 × 人手での失敗仕分け」から始めます。大がかりな評価基盤は要りません。壊れたタスクを人が弾き、残った signal だけで比較すれば、リーダーボードより自組織に効く数字が出ます。

正直に言うと、この仕分けは地味で面倒です。私のエージェントは賢いのに、私の書いたテストは相変わらずたまに嘘をつくので、失敗ログを一件ずつ開く時間は毎回それなりに削られます。それでも、ベンダーの発表スコアを眺めて「たぶん速くなった」と唱えるより、自分の 30 問で幅つきの数字を見るほうが、翌月の判断はずっと軽くなりました。

noise はゼロにできません。できるのは、noise の大きさを測って、signal がその幅を超えているときだけ動く、という運用です。OpenAI が公開ベンチマークでやって見せたことを、規模を落として自分の現場で回す。それが、コーディングツールの評価で私がいま一番信じている方法です。