AIが「SWE-benchで80%超え」と報じられた。そのベンチマーク自体をOpenAIが捨てた話をする。
SWE-benchとは何か
AIコーディングツールを選ぼうとして、「SWE-bench Verifiedで80.9%を達成」という数字を見たことがあるかもしれない。この数字が何を意味するのかを理解するには、まずSWE-benchが何かを知る必要がある。
SWE-benchは、AIが実際のソフトウェアエンジニアリングタスクをどれだけこなせるかを測る評価指標だ。GitHubに公開されている実際のバグ修正タスクを使い、AIがそのバグを修正できるかどうかを採点する。「SWE-bench Verified」はその信頼性向上版で、人間のエンジニアが問題を検証したセットだ。
2024年頃から業界標準の指標として定着し、Anthropic、OpenAI、Googleの各社がスコアを競うようになった。メディアもそれを報じた。「このモデルが何%達成した」というニュースが繰り返し流れ、ツール選びの判断材料として使われるようになった。
問題は、この評価自体が根本的に信頼できなくなったことだ。
汚染の現場
OpenAIの調査で、あることが発覚した。特定のタスク問題（タスクIDだけ）をモデルに与えると、本来解けないはずなのに正確な正解を再現できてしまう。
「汚染（contamination）」と呼ばれる問題だ。AIが問題を「解いた」のではなく、「訓練データで見た答えを思い出した」可能性が高い。
OpenAIの公式ブログが挙げた具体例が django__django-14725 という問題だ。Djangoフレームワークの edit_only パラメータに関するバグ修正で、Django 4.1のリリースノートを知らなければ解けない設問だった。ところがGPT-5.2のChain of Thought（AIの思考過程）を確認すると、そのリリースノートの知識が含まれていた。問題を「解いた」のではなく「覚えていた」と疑わざるを得ない証拠だ。
汚染はGPT-5.2だけの問題ではなかった。arxivの研究によれば、Claude Opus 4.5、Gemini 3 Flash Preview全てで同様の汚染が確認された。タスクIDだけを与えると、正解パッチや問題文を逐語的に再現できてしまった。
この汚染の程度は研究でも量的に示されている。arxivの論文によると、SWE-bench Verifiedでの5-gram（5単語の文字列）の逐語一致率は約35%に達した。他のベンチマークでは18%程度だ。Claude Opus 4.5はプレフィックス補完タスクで31.6%の逐語一致を記録した。「解いている」のか「思い出している」のかの境界が曖昧になっている。
汚染の発見プロセスを単純化するとこうなる。
なぜ汚染は避けられないのか
SWE-benchの問題はGitHubの公開リポジトリから収集されている。つまり、AIモデルの訓練データとほぼ確実に重複している。
受験生が過去問を全科目何年分も暗記して試験に臨んだようなものだ。試験では高得点が出る。でもそれは問題を解く能力の証明ではなく、記憶の証明だ。同じ試験を見たことのない初見問題でやり直したら、まったく違う結果が出る。
「モデルが問題を記憶しているのでは」という疑惑は以前からあった。ただ「疑惑」の段階にとどまっていた。OpenAIの調査によってそれが証拠として示された。
もう一つの問題は設問の質だ。OpenAIが138の未解決問題を詳細分析した結果、残る問題の多くが欠陥を抱えていることがわかった。テストが狭すぎて正解を不正解と判定するケースや、問題文に書かれていない前提知識を暗黙的に要求するケースが相当数含まれていた。
これらを踏まえて、OpenAIはSWE-bench Verifiedを「フロンティアモデルのコーディング能力をもはや正しく測れない」と結論づけた。
SWE-bench Proとは
OpenAIがSWE-bench Verifiedを捨てると宣言した同じ時期、Scale AIが「SWE-bench Pro」を設計した。汚染対策を構造に組み込んだ次世代の評価基準だ。
SWE-bench Verifiedとの設計思想の違いはこうだ。
1,865タスク、41リポジトリ（Python/Go/TypeScript/JavaScript）で構成される。変更量の中央値がVerifiedの4行に対して、Proは平均107行・4.1ファイルだ。現実のバグ修正がいかに複雑かを反映している。
特筆すべきはプライベートセット（276タスク）の存在だ。18社のスタートアップから提供された非公開コードベースで構成されており、モデルが訓練データで見ていた可能性がゼロのタスク群だ。汚染の影響を排除した「素の実力」に最も近い指標になる。
「80%」が「23%」になった日
SWE-bench Proリリース時に、Scale AIの公式ブログが当時のトップモデルのスコアを公表した。SWE-bench Verifiedで80%超えを記録していたモデルが、Proの標準評価では23%前後にとどまった。
「偏差値70を取っていた受験生が、初見問題の試験を受けたら偏差値50になった」ような結果だ。80%と23%の差が、「記憶の効果」と「実際の問題解決能力」の差を示唆している。
その後、各社がエージェント（タスク自動実行プログラム）の最適化を進め、SWE-bench Proの現在のトップスコアは46%前後まで上昇した（Scale AIリーダーボード、2026年2月時点）。それでもVerifiedの80%+には大幅に及ばない。非公開コードベースを使ったプライベートセットに至っては、スコアがさらに落ちる傾向がある。
この問題はOpenAIだけが感じていたわけではない。IBM Research のMartin Hirzelは、Pythonのリーダーボードが飽和しており、最新のフロンティアモデルがベンチマークデータを訓練データで見ているという証拠が積み重なっていると述べている。
「Pythonのベンチマークはもう信用できない。Javaで評価し直す」というのが彼らの結論だ。非公開データ・マルチ言語・実際の業務複雑さへの移行が、評価の信頼性を担保する方向性として業界に広まりつつある。
ベンチマーク数字の正しい読み方
「80%」という数字を見たとき、何を確認すべきかをまとめる。
❌ 鵜呑みにした場合:
「Claude Opus 4.5はSWE-bench 80.9%！最強のAIコーディングアシスタントだ」
→ どのベンチマークか確認していない
→ スコアの測定条件（エージェント構成）を確認していない
→ 汚染の問題を考慮していない
→ 自分のコードベースとの関連性を考えていない
✅ 正しく読んだ場合:
「Claude Opus 4.5はSWE-bench Verified 80.9%（OpenAI廃止宣言済み）」
→ 汚染と設問欠陥が確認されており、信頼性が低い
→ 汚染対策済みのSWE-bench Proでは標準評価で23%、最適化後でも46%前後
→ 非公開コードベースのプライベートセットではさらに低下
→ 自社のコードで実際に試すのが唯一信頼できる指標
信じられる指標とは何か
「AIツールを選ぶとき、どのベンチマークを見ればいいか」という問いに対する正直な答えはひとつしかない。「自分のコードで試す」だ。
ベンチマークは条件を揃えた環境での評価だ。あなたのプロダクトは、そのベンチマークの問題セットとは違うコードベースを持ち、違う言語で書かれ、違う複雑さを持っている。モデルが問題を記憶しているかどうかも、あなたのコードには関係がない。「80%」も「46%」も、あなたの仕事への適合性を保証しない。
ただ、参照すべき方向性はある。汚染対策を構造的に持つSWE-bench Proのようなベンチマークの方が、Verifiedよりは実力に近いものを測っている。特にプライベートセット（非公開コードベース）のスコアは、「記憶の効果を除いた実力」に最も近い指標だ。
スコアの数字そのものよりも、「どういう条件で測られたか」の方が重要だ。公開データで測ったか非公開データで測ったか、標準エージェントで測ったか独自最適化で測ったか、その違いを把握した上で数字を読む。
「業界標準のベンチマークで80%を記録したAIが、汚染のない評価では半分以下のスコアになった」という事実は、AIの能力そのものへの否定ではない。測定器に問題があったというだけの話だ。ただ、その測定器で競い合っていた業界全体と、その数字を使って判断していた私たちには、「測り直す」という作業が必要になった。
どのツールを使うかは、スコアではなく自分のユースケースで決める。80%という数字に惑わされなければ、それでいい。