はじめに
OpenAIが2026年2月23日、AIの自律的なソフトウェア開発能力を測る標準指標として広く使われてきた「SWE-bench Verified」が、もはやフロンティアモデルの能力を正確に測定できないと発表しました。本稿では、その分析内容と、OpenAIが推奨する代替ベンチマークについて解説します。
参考記事
- タイトル: Why SWE-bench Verified no longer measures frontier coding capabilities
- 著者: OpenAI
- 発行元: OpenAI
- 発行日: 2026年2月23日
- URL: https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/
要点
- SWE-bench Verifiedは2024年8月の公開以来、自律ソフトウェアエンジニアリング能力の標準指標として業界に広く用いられてきたが、OpenAIはその信頼性に重大な問題があると結論づけた
- 監査対象の138問題のうち59.4%に、正しい解答を不合格とするテスト設計の欠陥が確認された
- GPT-5.2、Claude Opus 4.5、Gemini 3 Flashのすべてで、訓練データへの混入（コンタミネーション）が確認された
- OpenAIはSWE-bench Verifiedのスコア報告を停止し、他のモデル開発者にも「SWE-bench Pro」の利用を推奨している
詳細解説
SWE-bench Verifiedとは何か
SWE-bench Verifiedは、AIモデルが実際のソフトウェアバグ修正タスクをどれだけ自律的にこなせるかを評価するベンチマークです。元となるSWE-benchは2023年に公開され、GitHubのオープンソースPythonリポジトリから収集した実際のissueとプルリクエストのペアで構成されています。モデルはissueの内容だけを与えられ、テストコードを見ずにコード変更を行う必要があります。
初版には「テストが特定の実装を前提としすぎている」「タスクの記述が曖昧で複数の解釈が可能」「実行環境によってテストが失敗する」などの問題があり、モデルの能力を過小評価する懸念がありました。そこでOpenAIは2024年に、専門的なソフトウェアエンジニア3名が独立してレビューした500問の厳選セットをSWE-bench Verifiedとして公開しました。
OpenAIによれば、公開後の6か月でスコアは74.9%から80.9%へ改善しましたが、その進歩は鈍化していました。残る失敗が「モデルの限界」なのか「データセット自体の問題」なのかを確かめるため、詳細な監査が実施されました。
テスト設計の欠陥：狭すぎるテストと広すぎるテスト
OpenAIは、o3が64回の独立した試行で安定して解けなかった138問を対象に、6名以上の経験豊富なソフトウェアエンジニアが独立してレビューする監査を実施しました。その結果、138問中59.4%に「テスト設計または問題記述の重大な欠陥」があることが判明しました。
問題は2種類に大別されます。
1つ目は「狭すぎるテスト（narrow test cases）」で、監査対象の35.5%を占めます。これは問題文に記載されていない特定の実装詳細（関数名など）をテストが要求するケースです。例えば、あるタスクでは問題文に言及のないget_annotationという関数名をテストが直接インポートしようとするため、別の正しい実装方法を選んだモデルはインポートエラーで不合格になります。
2つ目は「広すぎるテスト（wide test cases）」で18.8%を占め、問題文が1つの不具合しか説明していないにもかかわらず、テストが複数の不具合修正を要求するケースです。残る5.1%はこれらに分類されない雑多な問題でした。
ベンチマーク設計において「テストは実装の詳細に依存しすぎず、かつ抜け道を許さない」というバランスを保つことが難しいことが、この数字からも読み取れます。
訓練データへの混入（コンタミネーション）
もう1つの深刻な問題は、コンタミネーション（contamination）です。SWE-benchのタスクはオープンソースリポジトリから取得されており、多くのモデル開発者が訓練データとして利用する公開情報に含まれています。これは試験前に問題と解答を見た状態で試験を受けるようなものであり、スコアが本来の能力を超えて高くなる可能性があります。
OpenAIは自動化された検証手法を構築し、GPT-5がGPT-5.2-Chat、Claude Opus 4.5、Gemini 3 Flash Previewに対して各タスクの情報をどれだけ引き出せるか試みました。その結果は明確で、3つのモデルすべてで強い混入の証拠が確認されました。GPT-5.2はタスクIDと問題文の断片を与えられただけで、正解のコード差分をほぼ正確に再現しました。Claude Opus 4.5はファイルパスと関数名、さらにコード内のコメントを一字一句正確に再現しました。Gemini 3 Flash Previewはタスクの詳細な記述と正解パッチのコード行番号まで含め、逐語的に出力しました。
さらに、OpenAIは「訓練時に問題を目にしたモデルほど正解しやすい」という傾向も確認しています。テストが不完全で特定の実装情報がないと合格できない問題では、訓練データで答えを見たことがある場合に有利になるためです。これは、スコアの改善が「本当の能力向上」ではなく「ベンチマークへの露出量」を反映していた可能性を示します。
OpenAIの対応と今後の方針
この分析を受け、OpenAIはSWE-bench Verifiedのスコア報告を停止し、他のモデル開発者にも同様の対応を呼びかけています。現時点での代替として推奨されているのがSWE-bench Proです。OpenAIの検証パイプラインでは混入ケースが存在したものの、SWE-bench Verifiedと比べて件数は大幅に少なく、完全な正解パッチを逐語再現できたモデルはなかったとされています。
より長期的な取り組みとして、OpenAIはドメイン専門家が非公開で独自に作成したタスクを、訓練されたレビュアーが包括的に採点する「GDPVal」のようなアプローチを推進しています。ベンチマークの問題や解答を公開することでそれ自体が訓練データに混入するリスクを避けるためです。パスワード保護などでのデータセット公開方法の工夫や、訓練データのフィルタリング時のカナリー文字列の活用なども、今後の評価設計における重要な視点になると考えられます。
まとめ
OpenAIは、SWE-bench Verifiedの監査で「テスト設計の欠陥」と「訓練データへの混入」という2つの構造的問題を明らかにし、スコア報告の停止を決定しました。モデルのベンチマーク性能と実際の能力の乖離という課題は、AI評価全体に関わる問いと言えます。今後の評価手法の進化が注目されます。
