SWE-bench Verifiedはもはや最前線のコーディング能力を測定しない

2026年4月26日原文(openai.com)

概要

SWE-bench Verified は2024年8月以降、業界標準の自律ソフトウェアエンジニアリング評価指標として広く利用
モデルの進歩が鈍化し、評価指標としての限界が明らかに
テストケースの欠陥 や トレーニングデータ汚染 が評価の信頼性を損なう主因
OpenAIはSWE-bench Verifiedの報告を停止し、新たな評価指標の開発を推奨
今後は SWE-bench Pro や GDPVal のような私的に作成されたベンチマークが重要

SWE-bench Verifiedの役割と進展

SWE-bench Verified は、2024年8月の公開以降、最先端モデルの自律ソフトウェアエンジニアリング能力を測定する業界標準
OpenAIの Preparedness Framework でも進捗追跡の主要指標として採用
公開後、モデル精度は 74.9%から80.9% へと向上したが、最近は進歩が停滞
残された失敗例がモデルの限界かデータセットの問題かが課題

SWE-bench Verifiedの問題点

テストケースの欠陥 ・監査対象の27.6%の問題のうち、少なくとも59.4%で正しい解答がテストで不正に却下・タスク実装の細部に依存する「狭すぎるテスト」や、記述外の機能まで要求する「広すぎるテスト」が多数
トレーニングデータ汚染 ・モデルがテスト対象の問題や解答を事前学習している事例を多数確認・「gold patch」や問題文の詳細をそのまま再現するケースも発生・これにより、モデルの本来の能力ではなく、事前露出度がスコアに影響

SWE-bench Verifiedの評価停止と今後の指針

SWE-bench Verified のスコアはもはや実世界の能力向上を反映しないと判断
OpenAIは SWE-bench Verifiedのスコア報告を停止、他社にも同様の対応を推奨
新たな「汚染されていない」評価指標の開発が急務
当面は SWE-bench Pro での評価報告を推奨

SWE-bench/SWE-bench Verifiedの詳細と監査結果

SWE-bench （2023年公開）は、12のOSS PythonリポジトリからGitHub issueとPRを抽出し、バグ修正能力を評価・修正前後で失敗/成功するテストで正当性判定・モデルはテストを参照せず、issue文と修正前コードのみで解答
SWE-benchの問題点・テストが過度に具体的・ミスマッチな場合が多い・タスク記述が曖昧で複数解釈可能、テストカバレッジが限定的・環境依存でテストが不安定
SWE-bench Verified は専門家3名による1,699問題の審査で500問題に厳選
しかし再監査で138問題中59.4%に重大なテスト設計・記述問題を発見・「狭すぎるテスト」35.5%、記述外機能要求の「広すぎるテスト」18.8%、その他5.1%

具体的な失敗例

pylint-dev__pylint-4551 ・テストが特定関数名get_annotationの実装を要求するが、問題文に明記なし・正しい修正でも関数名が違うと失敗扱い
sympy__sympy-18199 ・PRは3つのissue解決、問題文は1つのみ記載・テストは全3つをカバーし、記述外の修正まで要求

汚染リスクと自動評価の課題

SWE-bench Verifiedやリポジトリが公開・広範利用されており、モデルの事前学習時に情報流入が不可避
GPT-5.2などがrelease note情報やgold patchをそのまま出力する事例を確認
自動red-teaming による汚染検出で、GPT-5.2, Opus, Gemini 3 Flash Previewなど主要モデルが多数のタスクでgold patchや詳細情報を再現
汚染リスクを避けるためには、・ベンチマークや解答の公開方法（パスワード保護等）の工夫・トレーニングデータフィルタリング（canary stringの厳密運用等）が不可欠
自動スコアリングは「正しい機能実装を、実装詳細に依存せず検証」できるテスト設計が難題

今後の評価指標と業界への提言

OpenAIは最近 SWE-bench Pro のpublic splitで結果を報告・SWE-bench Verifiedより汚染が少なく、gold patchの完全再現も未確認
将来的には GDPVal のような「非公開・専門家作成タスク」「訓練済みレビュワーによる全体評価」が重要
こうしたリソース集約型の評価が、真の能力向上測定には不可欠
業界・学術界全体で、 オリジナル・非公開ベンチマーク の開発と運用の協力が必要

Hackerたちの意見

これって、ずっと前から質問と回答の4分の1が間違ってたってことなの？！いや、27.6%のサブセットの59.4%が欠陥のあるテストケースを持ってるって言ってるんだと思う。 > もしそうなら、どうしてこれが有効な測定だったの？ベンチマークは実際のところ、あまり意味がないんだよね。自分のユースケースを表してないし、すべてのユースケースを代表してるわけでもない。ベンチマークに含まれてるものを測るのには有効だけど、それ以上でもそれ以下でもない。公共のベンチマークを使うことに執着するエコシステムが理解できない。価値のあることを教えてくれることなんてほとんどない。例えば、Qwen 3.5がQwen 2.5よりベンチマークXで50%良くなったとして、それが自分が使う目的に対しても50%良くなるってことにはならないよね？まずありえない。自分は特定の問題に対してLLMを使うために、どこにも共有しないテストケースでプライベートなベンチマークを運営してる。中には、LLMが間違った実際のケースに基づいて、プロンプトを調整しなきゃいけなかったものもあって、時間をかけてスイートを構築してきた。新しいモデルのアップデートが出るたびに、自分のベンチマークでは2-3%しか動かないのに、公共のベンチマークでは30-40%の増加とか言われて、モデルのトレーニングデータが汚染されてないって信じろって言われるのは無理があるよね。

└

つまり、16%の問題には問題があるってことだね。

└

これって、ずっと前から質問と回答の4分の1が間違ってたってことなの？！いや、27.6%のサブセットの59.4%が欠陥のあるテストケースを持ってるって言ってるんだと思う。 > もしそうなら、どうしてこれが有効な測定だったの？ベンチマークは実際のところ、あまり意味がないんだよね。自分のユースケースを表してないし、すべてのユースケースを代表してるわけでもない。ベンチマークに含まれてるものを測るのには有効だけど、それ以上でもそれ以下でもない。公共のベンチマークを使うことに執着するエコシステムが理解できない。価値のあることを教えてくれることなんてほとんどない。例えば、Qwen 3.5がQwen 2.5よりベンチマークXで50%良くなったとして、それが自分が使う目的に対しても50%良くなるってことにはならないよね？まずありえない。自分は特定の問題に対してLLMを使うために、どこにも共有しないテストケースでプライベートなベンチマークを運営してる。中には、LLMが間違った実際のケースに基づいて、プロンプトを調整しなきゃいけなかったものもあって、時間をかけてスイートを構築してきた。新しいモデルのアップデートが出るたびに、自分のベンチマークでは2-3%しか動かないのに、公共のベンチマークでは30-40%の増加とか言われて、モデルのトレーニングデータが汚染されてないって信じろって言われるのは無理があるよね。

└

Imagenetは地球上で最も人気のあるデータセットの一つだよね。実は、その画像のかなりの割合が誤ってラベル付けされてるんだ。極端な場合、モデルは一定の割合を超えるために間違った答えにフィットしなきゃいけない。答えは「MLは機能したいから機能する」ってこと。欠陥のあるものでどれだけ進めるかは驚きだよね。だからこそ、他の人が気づいていない欠陥に注目することで大きなブレークスルーが可能になるんだ。

└

どのモデルが優れているかを特定するのに役立つためには、ベンチマークスコアは真のパフォーマンスと相関していればいいんだ。大多数のタスクが正しくスコアされていれば十分。たとえば、ラベルの49%が間違っているひどいベンチマークがあって、常に正しい答えを出すモデルが51%のスコアを取ったとしても、常に間違ってるモデルが49%より高ければ、方向性としては正しいんだ。ほとんどの機械学習ベンチマークにはかなりの割合の間違ったラベルがあるけど、異なるモデルを区別したいだけなら、完璧なスコアを保証するためにかける時間は、むしろより大きなベンチマークデータセットを集めるのに使った方がいいことが多いよ。たとえそれがもっとエラーを含んでいてもね。

どんなベンチマークもすぐに古くなっちゃうし、トレーニングデータの中に存在するのは明らかだよね。マーケティング素材のためだけでも、これらのベンチマークに特化して最適化するインセンティブが常にある。トレーニングのカットオフがあるけど、通常は公開日から3-6ヶ月しか離れてない。だから、コーディングのベンチマークの問題は、トレーニングデータに含まれていない新しいベンチマークを作ることになる。過去のベンチマークから何も借りないことが保証されてるやつね。この点に関しては、特定のモデルがリリースされる前に作られたベンチマークは、モデルのパフォーマンスを示すものとして有効だとは思えない。データを含めることで得られる潜在的な金銭的利益は、ほんとに大きいからね。それを考えると、正直、マーケティング素材にはベンチマークを含めるのをやめるべきだと思う。モデルが自分で語るようにして、コミュニティに判断させればいいのに、もちろんそんなことは企業の人たちには通用しないよね。

└

これがZorkベンチを作った理由だよ。Zork、テキストアドベンチャーゲームは、LLMのトレーニングデータに含まれてる。しかも、決定論的なんだ。だから、LLMがプレイしてクリアするのは簡単なはずなのに、実際にはそうじゃない。なぜそうなるのかを理解するのがZorkベンチの目的だよ。 https://github.com/mnky9800n/zork-bench

└

解決策は、いくつかのプライベートで信頼できるベンチマークを使って、その結果を平均することだと思う。

└

記事でも言及されてるね。だから、ゼロから作られたプライベート（非公開）のベンチマークタスクが必要なんだ。

└

コーディングベンチマークを再び有効にする簡単な方法は、モデルのコンテキストに200kの気を散らすトークンや無関係なトークンを初期化することだね。あるいは、同じコンテキストでテストを順番に実行して、モデルがどこまで進むかを見るのもいいかも。これらのベンチマークはいつも新しいけど、人々は腐ったコンテキストに対処できるモデルを求めてる。

└

良いベンチマークは、選ばれたリポジトリを別の言語に移植することかも。で、コンテキストのメモをクリアして、また元に戻す。テストフレームワークがあれば、成功を決定論的に測れるよ。

└

その意見には賛成だけど、もし十分に大きくて洗練されたベンチマークが存在したら、モデルがそのベンチマークだけを暗記して、実際のパフォーマンスがひどいってことは驚きだな。まだそこには至ってないけど、いつかはそうなるかもね。

Hacker Newsで議論の続きを見る

ハクソク