SWE-bench Verifiedは終わった — OpenAIが自社ベンチマークを葬った本当の理由

80.9%と45.9%。同じモデル、同じ週に測定された二つのスコアの差は何を意味するのか。そしてOpenAIが自社の評価指標を自ら降ろした出来事は、単なるベンチマーク交換なのか、それともAIコーディング能力測定のパラダイムが崩れる兆候なのか。

OpenAIが自分のベンチマークを切った

2026年2月23日、OpenAIは公式ブログに「Why we no longer evaluate SWE-bench Verified」という短い記事を公開した。一行で要約するとこうだ。「フロンティアコーディング評価の基準は、モデルの成熟度とともに変化している（The standard for frontier coding evals is changing with model maturity）」。同日、OpenAI DevsのXアカウントも同じメッセージを発信している。

この発表はHacker Newsで281点を獲得し、158件のコメントが付いた。興味深いのは、発表から2か月が経過した4月時点でもXのタイムラインやエンジニアコミュニティで再び話題になっている点だ。理由は単純である。2024年以降ほぼすべてのLLM発表資料の冒頭スライドを飾ってきた指標が、その指標を最も積極的に使ってきた当の会社の手によって事実上の死亡宣告を受けたからだ。

SWE-bench Verifiedは、2024年にOpenAI自身が検証・整備した派生ベンチマークである。本家SWE-benchのノイズの多さが指摘される中、OpenAIは人間アノテーターを動員して500件のPython issueを精選した。「Verified」の名はそこから来ている。その後の約1年半、GPT-5シリーズ、Claude Opusシリーズ、Geminiシリーズなど、すべてのフロンティアモデルがこの指標の上で点数競争を繰り広げた。「80%突破」のヘッドラインが連発され、外注RFPでも「SWE-bench Verified X%以上」という条項が散見されるようになった。

そのベンチマークを作った側が「もう我々はこれでモデルを評価しない」と宣言したのである。本稿ではこの判断の根拠データを整理し、発注側および意思決定者がAIコーディングツールを評価する際に何を見るべきかを考える。

何が起きたのか — 二つの欠陥

OpenAIが提示した廃止理由は大きく二つある。テストケース自体の欠陥、そしてデータコンタミネーション（学習データ汚染）だ。

欠陥1. テストケースの59.4%が壊れていた

OpenAIによると、自社で監査したSWE-bench Verifiedの問題のうち、59.4%が欠陥を含むテストケース（flawed test cases） だった。何が欠陥なのか。最も頻出するパターンは「機能的に正しい解答を自動採点機が拒否（reject）する」ケース、つまりfalse negativeである。

具体的にはこうだ。あるGitHub issueを修正するパッチが実際にバグを解決していても、採点スクリプトは「元のPRとトークン単位で一致するコード」しか正解と認めない。変数名を変えたり、同じ機能を別のシグネチャで実装すれば0点になる。コードに単一の正解はないという当然の前提が、採点機の中では通用しないのである。

ここに逆説が生まれる。賢いモデルほど多様な表現で解を出す。一方、学習データに同じPRを暗記したモデルはトークン単位で正解を再現する。結果として 「本当に上手く解いているモデルほどスコアが下がる」 という矛盾が構造化される。評価指標としては致命的な欠陥だ。

欠陥2. すべてのフロンティアモデルが正解を暗記していた

二つ目はコンタミネーションである。OpenAIは「すべての主要なフロンティアモデルがverbatim gold patchesを再現可能だ」と明言した。GPT-5.2、Claude Opus 4.5、Gemini 3 Flash。名の知れたモデルはどれも、SWE-bench Verifiedの「正解パッチ」をそのまま出力できる、という意味である。

理由は考えれば自明だ。SWE-benchはGitHubの公開PRをベースに作られている。公開PRはすべてのLLMの学習データに含まれる。したがってSWE-bench Verifiedの「問題と正解」は、事実上モデルの事前学習コーパスの中に丸ごと入っている。試験直前に学生に解答を見せたようなものだ。

OpenAI自身が用いた比喩を日本語に置き換えるなら、「期末試験の問題と模範解答が学生の教科書に印刷された状態で試験を受ける」状況に近い。この状態で80%を突破したという数字は、能力の証拠というより露出の証拠に近い。

スコア差が示す一場面

この二つの欠陥が重なるとどんな矛盾が見えるか。最も端的な例がClaude Opus 4.5である。

  • SWE-bench Verified: 80.9%
  • SWE-bench Pro: 45.9%

同じモデル、同じ時期に測定された二つのスコアだ。何が違うのか。Verifiedは500件のPython限定タスクで構成され、上記二つの欠陥を抱えている。一方ProはScale AIが構築した1,865件のmulti-languageタスク群で、コンタミネーション対策として部分的にprivate test set構造を採用している。

同じモデルの能力が半分になるのは、モデル能力が変化したからではない。ものさし が変わったから表示値が変わったのだ。そして二つのものさしのどちらが本当の長さに近いかは、上で見た二つの欠陥が答えてくれる。

なぜ起きたのか — Goodhart’s lawの教科書事例

この出来事を一言で要約するのに最適な学術概念がある。Goodhart’s law（グッドハートの法則）だ。英国の経済学者Charles Goodhartが1975年に定式化した命題で、最もよく引かれる形は次の通りである。

“When a measure becomes a target, it ceases to be a good measure.” （指標が目標になった瞬間、その指標はもはや良い指標ではなくなる。）

SWE-bench Verifiedの興亡は、この法則のほぼ完璧な実例である。最初はモデル能力を測る道具だった。それがLLMマーケティングの主役指標に格上げされた。スコアを上げるための学習データ・評価パイプラインの最適化が進み、結果として「指標は上がるが、実能力との相関が弱まる」段階に入った。OpenAI自身もこのパイプラインの一部だった点が重要だ。

自動採点機の構造的限界

コードは自然言語と異なるが、自然言語よりも難しい評価上の問題を抱えている。自然言語は人が読めば意味が伝わる。コードは一度コンパイルされ、実行されてはじめて評価できる。だから自動採点機に頼らざるを得ない。

自動採点機には大きく二種類ある。

  1. テスト合格判定: PRに含まれる単体テストを、モデルのパッチが通せるか
  2. 参照パッチとの一致度: モデルのパッチが人間の正解パッチとどれだけ似ているか

(1)はfalse positiveに弱い。テストだけ回避するコードを書けば通ってしまう。(2)はfalse negativeに弱い。先に見た通りである。実際のSWE-bench系ベンチマークは(1)を主に使うが、テスト自体が脆弱だったり環境依存が高かったりするため、結局欠陥率が上がる。

根本的に、コード評価には単一の正解が存在しないという事実が採点機設計と衝突する。だからモデルが多様な解を作る能力を獲得するほど、採点機とモデルの間のギャップは広がる。

新しい評価基準のトレードオフ

OpenAIはSWE-bench Proへの移行を推奨した。しかしProも万能ではない。新しいコーディングベンチマークが満たすべき条件を整理するとこうなる。

  • 多言語対応: Java、Go、C++、TypeScriptなど。Python限定の評価では実務分布を反映しきれない。
  • 実PR環境への近接性: 単純な関数シグネチャ照合ではなく、複数ファイル・複数モジュール・既存コードのコンテキストまで扱うタスク。
  • コンタミネーション防止: private test setまたは定期リフレッシュ。公開された瞬間、次の学習サイクルで汚染される。
  • 再現性: 誰でも同じ手順で点数を測れることが、比較に意味を与える。

問題は、これらが相互に衝突することだ。再現性は公開を要求するが、コンタミネーション防止は非公開を要求する。実PR環境への近接性は評価コストを膨らませるが、多言語・複数モジュールのタスクを1,865件毎回回すコストは小さくない。OpenAIが「stronger coding eval standards」が産業全体で進行中だと述べたのは、このトレードオフの上で合意形成が進んでいるという意味である。

ベンチマークインフレの終焉

2024年以降のLLMマーケティングの標準パターンは明確だった。新モデル発表 → SWE-bench Verifiedスコア更新 → 「コーディングSOTA達成」のヘッドライン。このパターンは技術報道だけでなくRFPや契約レベルにも浸透した。「ベンチマークスコアX%以上のツールを使うこと」という条件が明記される事例も少なくない。

しかし上記データが示す結論は明白だ。80%台後半での1〜2点差はモデル能力差ではなく、コンタミネーション濃度差を反映するケースのほうが多い。スコアの「ノイズフロア」がモデル間の真の差を上回ってしまった。この状態でのスコア比較は意思決定の根拠として機能しない。

意思決定者にとっての意味

SWE-bench Verifiedの廃止は学術上の事件ではない。AIコーディングツールを導入し、外注先を評価し、社内開発生産性を測る意思決定者にとって、直接的な示唆を投げかけている。

示唆1. 「ベンチマークスコア」だけでツール選定するのは危険水域

CTOや開発マネージャがコーディングアシスタントやAIコードレビューツールを比較する際、ベンダー資料の表紙には例外なくSWE-bench系のスコアが並ぶ。このスコアの意味が揺らいだ以上、ベンダー資料のスコアだけでツールを選ぶ意思決定プロセスそのものを再検討する価値がある。

代替案は新しくない。自社コードベースでのパイロットテストである。実際の自社リポジトリで一週間ほど実PRを作らせ、シニアエンジニアがマージ率・ロールバック率・レビューコメント数といった実指標を記録する方法だ。コストはかかるが、このコストは「誤ったツールを1年使うコスト」よりもはるかに小さい。

示唆2. 多言語・複数モジュール・レガシーコードは別評価が必要

SWE-bench VerifiedのPython限定構成は評価を簡素化するための判断だが、日本市場の実務分布とは距離がある。発注企業のコードベースはJava・PHP・Ruby・Go・TypeScript・C#、場合によってはCOBOLまで共存しているのが普通だ。そこに社内フレームワーク、10年もののレガシーモジュール、社内ライブラリへの依存が重なる。

この環境では、AIコーディングツールの実性能はPython限定ベンチマーク値と無関係になる可能性が高い。SWE-bench Proが提示する多言語タスクのほうが近い近似ではあるが、それでも自社環境の代替にはならない。「自社環境で実際に動くか」 という問いは、どの外部ベンチマークも自動的には答えてくれない。

示唆3. プライベート評価セットの価値

すでに一部の大企業は、自社コードベースの一部を非公開評価セットとして運用している。外注先やツールベンダーに依頼する際、「この非公開タスク50件に対しX%以上のマージ可能PRを生成すること」という条件を付けることができる。

この方式には二つの利点がある。第一に、コンタミネーションが構造的に遮断される。非公開コードは公開学習データに含まれない。第二に、自社ドメイン・コーディング規約・レガシー依存がすべて評価に反映される。欠点は評価セット構築・維持のコストだが、これはRFP作成業務の自然な延長として吸収できる。

示唆4. 「スコアの時価減価」を前提にした契約

ベンチマークスコアの半減期は短くなっている。今日80%の指標は来年の同じモデルで意味が変わりうる。そのためツール導入契約に 「評価指標が更新された時点で再評価する」 条項を明記する事例が増えている。これはベンダーとの信頼関係を損なう条項ではなく、双方が変化する評価環境に備える合理的設計と捉えられる。

結論 — ものさしが変わる時代の意思決定

冒頭の問いに戻ろう。80.9%と45.9%の差は何を意味するのか。答えは明瞭だ。モデル能力ではなく、評価ツールの信頼度が半分に減ったということである。そしてOpenAIによるSWE-bench Verifiedの廃止は、より信頼できるものさしを産業全体で作り直す作業の開始シグナルだ。

この変化は、AIコーディングツールを導入・評価・発注する意思決定者に二つのことを示唆する。第一に、外部ベンチマークスコアの絶対値を意思決定の単一根拠とする時代は過ぎ去った。第二に、自社コードベースに基づく実測・非公開評価セット・多言語評価を組み合わせた評価体系が、徐々に標準になりつつある。

興味深いのは、この流れが特に悲観的ではないという点だ。むしろ「ベンチマークインフレ」以前、つまり導入企業が自社環境で直接検証していた時代への正常化に近い。ただし今回は対象がLLMであり、評価方法論が以前より精緻化される余地があるだけである。

残された問いもある。SWE-bench Pro自体も公開された以上、時間が経てば同じ運命を辿りうる。さらに根本的には、「良いコード」の定義自体が環境ごとに異なる事実を、自動採点機がどう吸収するのか。この問いに産業がどんな答えを作るのか — それが今後数年のAIコーディングツール評価の風景を決めることになる。

出典

  • OpenAI, “Why we no longer evaluate SWE-bench Verified” (2026-02-23): https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/
  • OpenAI Devs X 投稿 (2026-02-23)
  • SWE-Bench Pro Leaderboard (Scale AI)
  • Hacker News 議論 (2026-02-23, 281点, 158 comments)
  • Goodhart, C. (1975). “Problems of Monetary Management: The U.K. Experience”