SWE-bench Verifiedと元のSWE-benchはどう違うのですか？なぜ「改良版」まで失効してしまったのですか？
2023年に公開された元のSWE-benchには、テスト環境が不安定、一部の問題がそもそも解けないといった問題があった。OpenAIは2024年、専門家を招いて1,699件の問題を人手でレビューし、品質の高い500件のサブセットSWE-bench Verifiedに絞り込んだ。これは明確な評価上の欠陥を修正するためだった。
しかし、今回の失効の根本原因は元のバージョンとは異なる——問題自体の設計が悪いのではなく（今回の監査でも残存するテスト設計の問題が全体の6割近くを占めることが判明したが）、「データ汚染」が原因だ。この500件の問題はすべて公開のオープンソースプロジェクトに由来しており、時間が経つにつれて、これらのコードベースの内容が各社モデルの訓練に使われるWebクロールコーパスに取り込まれる可能性が高まっていく。つまり、改良版は「問題設計」レベルの課題を解決したが、「問題はいずれモデルに見られてしまう」という構造的な問題は解決できなかった。これこそが、丁寧にレビューされたバージョンでも同じ失効の運命を免れられなかった理由だ。
単に「一部の問題をモデルが見たことがある」だけなのに、なぜOpenAIがベンチマーク全体を放棄するほど深刻な問題になったのですか？
重要なのは「見たかどうか」自体ではなく、OpenAIの分析が特に強調している点だ。答えを見たことのあるモデルは明らかに成功率が高くなる。なぜなら、問題の説明では十分に語られていない追加情報を得ているからで、いわば「不完全な問題の完全な答え」を手にしているようなものだ。例えば、django__django-14725という問題のテストではedit_onlyという新しいパラメータが求められるが、このパラメータ名は問題の説明にはまったく登場しない。しかしGPT-5.2は推論過程で「このパラメータはおそらくDjango 4.1あたりで追加されたものだろう」と明言している。つまり、実際にはDjangoのバージョン履歴に関する記憶に基づいて答えていたのであり、問題の説明から本当に推論して解法を導き出したわけではない。
これは、スコアの向上の一部が実は「記憶力」の向上であって、「未見の問題を解決する能力」の向上ではないことを意味する。しかし業界が本当に測定したいのは後者であり、《防範フレームワーク》が本当に追跡しようとしているのも後者だ。この二つが一つのスコアに混ざり合い、切り分けられない状態になると、そのスコアは本来の役割を失ってしまう。
SWE-bench Proは本当に問題を根本的に解決するのですか、それとも同じ苦境を先延ばしにしているだけですか？
短期的には、SWE-bench Proは確かに汚染度を大きく低減している——OpenAIが同じ「聞き出し」手法でテストしたところ、汚染の兆候が見つかった事例はSWE-bench Verifiedよりはるかに少なく、ゴールドパッチを完全に再現できたモデルは一つもなかった。これは現時点での防御力が明らかに強いことを示している。
しかし構造的に見れば、SWE-bench Proが直面しているのは、実は同じ長期的な苦境の別の段階にすぎない。非公開の問題セットであることは、公開データが訓練コーパスに取り込まれやすいという問題を解決するが、その代償として構築・更新のコストがはるかに高くなり、問題のソースもより限定される。時間が経つにつれ、この問題セットの内容も何らかの形で（引用される、議論される、あるいは一部が流出するなど）公開ネットに流れ込めば、同様の汚染リスクに直面する可能性がある。だからこそOpenAIは同時に、公開日に基づいて動的にフィルタリングするLiveCodeBenchのような評価方式や、完全に非公開で作題し人手で採点するGDPValのような評価方式への投資も強調している。単一のベンチマークだけに希望を託すのではなく、複数の防御メカニズムを組み合わせているのだ。
一般の読者は研究者ではなく、自分で汚染問題を検証することはできません。では、あるコーディングエージェント製品が宣伝するスコアが信頼できるかどうか、どう判断すればよいですか？
比較的検証しやすいいくつかの手がかりに注目するとよい。第一に、その企業が引用しているスコアがSWE-bench Verifiedかどうかを確認する——もしそうで、汚染リスクや代替指標についての説明が一切添えられていなければ、それ自体が警戒すべきシグナルだ。なぜなら業界標準は2026年2月以降すでに転換しているからだ。第二に、その企業がSWE-bench Proや他の耐汚染性のあるベンチマークのスコアも同時に公表しているかを確認し、両者の差を比較する——差が大きいほど、Verifiedスコアの参考価値は限られる。第三に、製品の宣伝が単一のランキングの単一の数字だけを示し、方法論の説明や一次資料へのリンクが一切なければ、その提示方法自体が「一つのスコアは相互チェックが必要」という基本原則に反しており、判断を下す前にもう少し疑問を持つ価値がある。
2026年2月23日、OpenAIは異例の自己修正声明を発表した。同社はSWE-bench Verifiedのスコア報告を停止し、業界全体にも同様の対応を推奨するというものだ。これが注目に値するのは、単に別のベンチマークが陳腐化したからではない——AI業界はこの2年間、あるランキングが「攻略された」ことにすでに慣れつつある。注目すべきは、SWE-bench Verifiedが、OpenAI自身が2024年に元のSWE-benchの欠陥を修正するために構築した「改良版」であり、今やその改良版すら、作った本人によって測定不能と宣言されたという点だ。
SWE-benchが2023年に初めて登場したとき、それはAIコーディング評価における本物の前進だった。おもちゃレベルの単一関数補完をテストするのではなく、モデルを実際のオープンソースプロジェクトの本物のGitHub Issueに直接投げ込み、問題の説明を読み、対応するコードを修正し、元のプルリクエストに付属するテストに合格することを求めた。初期の最高スコアは20〜30%程度で、このベンチマークは一時、難しく、誠実で、本当に役立つものとみなされていた。しかし元のバージョンには明確な評価上の欠陥があった——過度に硬直的なテストケース、曖昧な問題記述、不安定なクロスプラットフォーム実行環境。そこでOpenAIは2024年、専門家を招いて1,699件の元の問題を人手でレビューし、品質の高い500件のサブセットに絞り込み、SWE-bench Verifiedとして公開した。
その後の1年半で、SWE-bench Verifiedは急速に業界標準の指標となり、ほぼすべての最先端モデルのリリースにこのスコアが添えられ、OpenAI自身の《防範フレームワーク》（Preparedness Framework）でも能力の進展を追跡するために使われてきた。しかしOpenAIが今回公表した分析によれば、過去半年間でトップモデルのこのベンチマークにおける進歩幅は74.9%から80.9%へと鈍化しており、これが同社により根本的な問いを突きつけた。残された解けない問題は、本当にモデルの能力が天井にぶつかっているのか、それともデータセット自体に問題があるのか。
OpenAIの今回の監査は、モデルがしばしば解けない138件の問題に焦点を当て、各問題を少なくとも6名の経験豊富なエンジニアが独立してレビューした。結果、そのうち59.4%の問題に明確な欠陥があることが判明した。35.5%は「テストが狭すぎる」問題——テストケースが特定の実装の詳細（例えば特定の関数名を厳格に要求するなど）を求めており、機能的に正しい別解であっても命名が一致しないという理由だけで失敗と判定されてしまう。残る18.8%は「テストが広すぎる」問題——テストケースが問題の説明が要求する範囲を超えてカバーしている。例えば、あるケースでは元のプルリクエストが実際には三つの異なる問題を一度に修正していたが、問題の説明は一つだけを抜き出していた。モデルは説明が求める問題を正しく解決しても、テストに含まれる他の「要求されていない」二つの問題を修正していないという理由で失敗と判定される。
より根本的な第二の問題は汚染だ。SWE-benchの問題はすべて公開されたオープンソースプロジェクトから取られており、そのコードベース、リリースノート、さらには議論スレッドまでもが、すでに各社モデルの訓練コーパスに取り込まれている可能性が高い。OpenAIは、GPT-5がGPT-5.2-Chat、Claude Opus 4.5、Gemini 3 Flash Previewといった非推論モデルから「答えを引き出そう」とする自動化されたレッドチーム体制を構築した。手法は、問題の部分的なヒントだけをモデルに与え、完全な正解の修正内容（いわゆるゴールドパッチ）を「思い出せる」かどうかを試すというものだ。結果は驚くべきものだった。GPT-5.2は問題説明の短い断片だけを与えられただけで、正確なコード変更を、関数名や変数名まで含めて完全に再現した。Claude Opus 4.5に至っては、元のプルリクエストのインラインコードコメントを一字一句違わず引用できた。Gemini 3 Flashは問題説明の文言そのものを一言一句そらんじることができた。三つの異なる企業の、三つの異なるモデルすべてが、同じ問題群の正解をすでに見ていたことが発覚したのである。
OpenAIは今回、業界に対して代替指標としてSWE-bench Proへの移行を公に推奨した。これは汚染への耐性を特に考慮して設計された、非公開の問題セットである。OpenAI自身の汚染テストでは、同じ抽出手法を用いても、SWE-bench Proで見つかった汚染事例はSWE-bench Verifiedよりはるかに少なく、ゴールドパッチを一字一句完全に再現できたモデルは一つもなかった。しかし、新しいベンチマークへの移行には、スコアが崖から落ちるように見えるという代償が伴う。SWE-bench Verifiedで80%以上、93%近くに達していたトップモデルは、SWE-bench Proでは概ね46%から58%の範囲に落ち着く。このギャップこそが、最も直接的な証拠である——モデルが突然弱くなったのではなく、旧ベンチマークが長い間、進歩の幅を体系的に過大評価し続けていたということだ。
SWE-benchシリーズが陥っている苦境は、公開データから構築されるあらゆるベンチマークが最終的に直面するジレンマの本質を表している。問題のソースが実世界に近ければ近いほど、訓練データに取り込まれる可能性が高くなる。問題のソースが閉鎖的でプライベートであればあるほど、構築と維持のコストが高くなる。OpenAIの分析も、これこそが同社が最近GDPValのような評価手法——タスクをドメイン専門家が非公開で作成し、訓練された人間の評価者が総合的に採点する——にシフトしている理由だと認めている。コストははるかに高くつくが、汚染リスクを効果的に抑えられる。これは最近の複数の独立分析が指摘する業界のコンセンサスとも重なる。あるベンチマークのスコアを読む前に、まずそのスコアがどのような「防御メカニズム」を持っているのかを把握しなければならない——問題セットは時間の経過とともに更新されているか、特定の分野向けに再作成されているか、採点は自動化されているか人手によるものか。防御メカニズムを持たないスコアは、本質的には、いつでも攻略されうる一組の数字にすぎないからだ。
もしあなたがベンチマークスコアに基づいてAIコーディングツールを評価している、あるいはAI関連の投資判断を下そうとしているなら、今回の一件から得られる最も直接的な教訓は、単一のランキングのスコアを安定した信頼できる「温度計」の読み取り値として扱ってはならないということだ。それは相互チェックが必要な意見調査に近い。具体的には——ある企業が現在も何の但し書きもなくSWE-bench Verifiedのスコアを報告し続けているかを確認する（それは情報開示の透明性が十分でないことを示している可能性がある）。同じモデルのSWE-bench VerifiedとSWE-bench Proのスコア差を比較する——差が大きいほど、旧スコアの参考価値は低い。そして長期的には、LiveCodeBenchのように公開日に基づいて問題セットを動的に更新し、訓練データの汚染を明確に防ぐ評価方式に注目すること。これらも完璧ではないが、少なくとも「防御メカニズムが何か」を検証可能な問いにしてくれる——ベンダーの言葉をただ鵜呑みにするのではなく。