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

10時間前原文(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%の問題には問題があるってことだね。

└

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

└

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

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

└

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

└

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

└

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

└

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

└

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

└

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

└

「コミュニティ」はめっちゃアストロターフされてるよね。AnthropicはインフルエンサーにClaude Codeを宣伝させてるし、多分ボットもたくさん使ってるから、オンラインで合意を得るのは難しい。みんなが善意で行動していても、働いている分野によって、体験が全然違うからね（例えば、AIがフロントエンドや一般的なライブラリでめっちゃ得意だったりする）。モデルを評価する唯一の本当の方法は、自分でテストすることだけど、それは新しいモデルごとに疲れるし、包括的でもない。

└

> コミュニティに決めさせようどのコミュニティのことを言ってるの？LLMを10年以上使ってるプロたち、コードを書く経験が全くないバイブコーダー、そしてその間にいるみんな？オンラインコミュニティを読むと、モデルに関する体験がバラバラで、ある人はGPT 5.5をJCの再来だと比較し、他の人は5.4よりもバカだと思ってる。個人的には、出てくるモデルを比較するためのプライベートなベンチマークを作る時間がないから、主にプライベートやセミプライベートなベンチマークに頼って、サービスに登録して自分で使い始める前にモデルの改善具合を感じ取ってる。少なくとも、redditのランダムな人やボットのバイブよりは、ちょっと信頼できる情報だと思う。

└

逆に、インタビューでOpenAIの誰かが言ってたけど、モデルが良くなってるかどうか判断するのが難しくなるから、それを避けようとしてるんだって。

>>私たちの分析では、テストしたすべてのフロンティアモデルが、基準となる人間が書いたバグ修正を再現できることがわかった。これをゴールドパッチと呼ぶんだけど、特定のタスクの文言の詳細も含まれていて、すべてのモデルがトレーニング中に少なくともいくつかの問題と解決策を見たことを示している。この文だけでSWE-benchのテストが無効になるように思える。

なんで彼らのプレミアモデルにベンチを生成させないの？冗談はさておき、楽しみにしてるベンチマークはARC-AGI-3だよ。彼らの人間シミュレーションを試してみたけど、すごく推論が重い感じがした。リーダーボード: https://arcprize.org/leaderboard（ほとんどのプレミアモデルは5%も通過しないけどね。）

└

理論的に重いベンチマークが一番いい感じだね。ゲームしにくいから。

└

動きの回数を最小限に抑えることに重点を置いていて、全くハーネスを許さないから、ハードルがめっちゃ高い。現在のトップの検証済みコンペティター（Claude Opus 4.6）は、たったの0.45%だよ。でも、まだ新しいから、次の世代のモデルではかなりの改善が期待できると思う。

└

なんで彼らはプレミアモデルにベンチを生成させないんだろう？変なアイデアじゃないと思うけど。古いモデルに新しいモデルをインタビューさせて、両方（もしくは第三の審判モデル）にどっちが賢いと思うか聞いてみればいいんじゃない？それを100回、異なるシードで繰り返してみて、両方が新しいモデルの勝ちに同意した回数の割合がスコアになる。

└

AIは、自分でも解けないくらい難しい問題を作れるのかな？へへ。

実際、あんまり良くなかったみたい。2025年の間、モデルが質の高いコードを生成する速度にはほとんど改善がなかったんだ。自動テストを通過するのは上手くなったけどね。 https://entropicthoughts.com/no-swe-bench-improvement

└

たぶん、これは本当だと思う。モデルの質が停滞してるし、新しい改善のベクトルを見つけるのは簡単じゃない気がする。モデルの幅を広げること（これまでの改善のスピードを支えてきた要因）が限界に達してるみたいだね。これがどうなるか、ちょっと興味深いね。ツールだけでは長期的には限界があるから。

└

でも、それはコーディングの生産性にとってものすごい源なんだよね。だからAnthropicは数十億の価値があるんだ。SWE-benchがコーディングにとってこんなに成功して有用なのは、ソフトウェアエンジニアリングが自動テストを作って使うための伝統とインフラがたくさんあるからだよ。

オリンピック形式の方がいいと思う。でも、金銭的なインセンティブがあるから、漏洩を止めるのはほぼ不可能かも。つまり、パネルが一連の問題を考え出すんだ。 Advent of CodeやProject Eulerみたいだけど、もっと複雑で制約がある感じ。ベンチマークの結果はパフォーマンスポイントやコスト、解決までの時間（実際にはトークン数）を測ることができる。年に数回実施されて、オーバーフィッティングを避けることができる。時間が経つにつれて、必要ならタスクはもっと複雑になっていく。もしそれをベンチマックスして、仕様から完全な製品を完成させるような堅牢な実装ができたら、すごいことになるね。

└

SWE-benchはオリンピアードのコーディングベンチマークを置き換えるために作られたんだ。過去のオリンピアードのコーディングベンチマークは、SWE-benchみたいに実際の労働から派生したものより、現実のコーディングをあまり反映してなかったと思う。それに、オリンピアードスタイルのベンチマークは、定期的にリフレッシュしないと汚染されたり、暗記しやすくなっちゃうけど、SWE-benchも同じことが言えるね。

ベンチマークや評価は本当に難しいし、業界規模でそれをゲームするインセンティブが大きいと、さらに難しくなる。ELT-Benchは最近の別の例だ。データエンジニアリングのワークロードに対するベンチマークの初めての真剣な試みで、約1年前に発表された。数日前、元の著者の一人を含むグループがそのベンチマークを監査したフォローアップ論文が出たんだけど、チームはそのベンチマークに構造的な問題があって、結果が偏っていることを発見した。論文はこちら: https://arxiv.org/abs/2603.29399 でも、これらは新しいことじゃない。業界は以前に小規模で同じことを経験していて、そこから学ぶことがたくさんある。データベースシステムのベンチマーケティング戦争と今日のパラレルについて書いた投稿もあるよ。https://www.typedef.ai/blog/from-benchmarketing-to-benchmaxx...

└

データベースのベンチマークもそうだね。私は、精度の測定ができない分類器を作った経験があるけど、その分類器は人間よりも常に良いパフォーマンスを発揮するんだ。だから、それ自体が最先端のベンチマークになってしまって、自分自身以外のものと比較できない。これは、非自明で複雑なタスクに関するもので、コーディングよりも論理的ではなく、持続的な推論も少ない。でも、いつかモデルとは独立したキャリブレーションされたベンチマークが存在しない日が来るかもしれないね。

└

トレーニングデータに含めないのが難しいんだよね。BrowseComp plusや他の深い研究データセットでちょっと見られる現象だよ。フロンティアラボが不正をしようとしてるわけじゃなくて、ただ全ウェブでトレーニングしてるから。新しいデータセットが常に必要だね。

└

毎月新しいベンチマークを作ることでこの問題は解決できるのかな？

SWE-benchの共同制作者なんだけど、1. SWE-bench Verifiedは今93.9%で飽和状態（おめでとう、Anthropic）。でも、まだその数字に達してない人は成長の余地があるよ。2. SWE-bench MultilingualとSWE-bench Multimodal（来月オープンソースにする予定）はまだ飽和してない。3. すべてのベンチマークとベンチマークの枠組みは最終的に飽和するんだ。だからSWE-benchチームは次のステージのベンチマークを作るために頑張ってきたし、すでにいくつか出てるよ。例えば、https://codeclash.ai/ や https://algotune.io/ みたいな。もっとお知らせすることもあるから、楽しみにしててね :)

└

> 93.6%（おめでとう、Anthropic）でも、記事には「モデルがしばしば解決できなかったデータセットの27.6%のサブセットを監査したところ、少なくとも59.4%の監査された問題には機能的に正しい提出を拒否する欠陥のあるテストケースがあることがわかった」と書いてある。0.191 * 0.594 > 1 - 0.936 これは、監査されたサブセットが代表的ではなかったってこと？それとも、Anthropicが何か怪しい手段で高いスコアを得てるってこと？

└

どっちもかなり古く見えるね？

└

> 1. SWE-bench Verifiedは今93.9%で飽和状態だね（おめでとうAnthropic）。でも、まだその数字に達してない人は成長の余地があるよ。ただ、もし一部または全てのプレイヤーがベンチマックスしてるなら、比較のためにはあまり役に立たない指標になっちゃうね。それに、OpenAIが言ってるテストスイートが有効な解法を許可しないっていう問題にも触れてないし。

└

歴史を学ばない（またはそれを生き抜かない）人は、同じ過ちを繰り返す運命にある。SPECintとSPECfpはまさにこの映画を経験したんだ：ベンチマーク、飽和、引退、置き換え、繰り返し。トレッドミルが製品なんだよ。解決策は持ってないけど、このパターンに気づいてるだけさ。

└

うちの会社の仕事をモデルにしたのを作るのって、どれくらい難しいんだろう？

「プライベートベンチマーク」の提案は毎回出てくるけど、もっと面白い視点があると思うんだ。それは、すでに公開されていて安定したテストツールの上に構築されたベンチマークだよ。SWE-benchは基本的にGitHubに存在するコーパスで、一度リリースされると、自動的にトレーニングデータに漏れ出すんだ。論争のある定性的なツール（心理テストや意見調査）に基づいたベンチマークは、正しい答えがトレーニングコーパスに存在しないから、汚染のプロファイルが違うんだ。具体的なコーディング能力を測るのには役立たないけど（正確なコードのオラクルが必要だからね）、能力の軸で「答え」が検証可能な事実ではなく、主張された立場である場合には、公開かつ安定していることがまだ有用だよ。SWE-benchの問題は「公開」じゃなくて、「公開かつ固定された正しい答えがある」ってことなんだ。

基本的に、我々は自分たちがふさわしいベンチマークを得ていると思う。多くのSWE-benchを通過したPRはマージされないだろうね： https://news.ycombinator.com/item?id=47341645 トップモデルのSWEベンチスコアは、gitの履歴漏れによって歪められてるかもしれない： https://news.ycombinator.com/item?id=45214670

ハクソク