SWE-bench Verified はもはや最先端レベルの実装能力の評価指標として機能しなくなりました。

2024 年 8 月に SWE-bench Verified を初公開以降、業界全体で自律的なソフトウェアエンジニアリングタスクにおけるモデルの進歩を測定するために幅広く採用されています。本 Benchmark のリリース以来、それは能力向上に関する強力なシグナルを示し、最先端モデルの発表に伴う標準指標として位置づけられてきました。また、OpenAI の「備えのための枠組み（Preparedness Framework）」においても、これらの能力の進捗を追跡・予測することは重要な構成要素です。当初、SWE-bench Verified を構築する際には、元々の評価において特定のタスクが不可能になるような問題を解決するために尽力しました。初期段階で大きく向上した後、SWE-bench Verified における最良性能（state-of-the-art）の進捗は鈍化しており、過去 6 ヶ月間でわずか 74.9% から 80.9% への改善にとどまっています。これにより新たな問いが提起されます：残りの失敗事例は、モデル自体の限界によるものなのか、それともデータセットそのものの特性に起因するのか？

新たな分析を通じて、今日のような性能レベルにおいて最先端モデル向けローンチにおける自律的なソフトウェアエンジニアリング能力の進捗を測定するという観点から、SWE-bench Verified はもはや適正でないと判断されるべき二つの重大な問題が存在することが明らかとなりました：

• 正しい解答が却下されるテスト：モデルがよく失敗する 27.6% のサブセットに対して監査を実施したところ、少なくとも 59.4% に達する監査済み問題において、機能上は正しい提出物を却下してしまう破綻したテストケースが存在することが分かりました。SWE-bench Verified の初期構築時に我们がこれらの問題を改善しようとしたにもかかわらずです。
• 解答データを用いた学習：大規模な最先端モデルはトレーニングを通じて情報を学習できるため、評価対象となる問題や解答から決して学習してはならないことが重要です。これは、試験本番前に生徒たちに出題と解答を共有してしまうようなものであり、答えを暗記しない場合でも、解答を見ている生徒は見ていない生徒よりも確実に高い成績を取り得ます。SWE-bench の問題は、多くのモデルプロバイダがトレーニング用に利用するオープンソースリポジトリから抽出されています。われわれの分析では、全てのテストされた最先端モデルが、正解として用いられる元ネタとなる人間によって書かれたバグ修正（ゴールドパッチ）や、特定のタスクにおける問題記述の詳細を完全にそのまま再現できており、つまりすべてのモデルがトレーニング中に少なくともこれらの問題や解答の一部に接していたことを示しました。

さらに、トレーニング中に問題に触れたモデルの方が成功確率が向上する証拠も発見しました。これは、未定義のテストを通過するために必要な追加的情報を有しているためです。つまり、SWE-bench Verified における進歩が、モデルの実世界でのソフトウェア開発能力の有意味な向上を反映し続けているとは言い難く、むしろトレーニング時におけるベンチマークへの露出度合いを象徴するものとなっています。そのため、われわれは SWE-bench Verified のスコア報告を終了し、他のモデル開発者にも同様の対応を推奨いたします。これに代わる新たな汚染されていない評価指標の構築を進めており、これは広範な研究コミュニティにとって重要な焦点となるべき分野であると考えます。本評価が確立されるまで、OpenAI は SWE-bench Pro の結果報告を推奨しています。

元々の SWE-bench 評価は 2023 年にリリースされました。各問題は、12 つのオープンソース Python リポジトリの一つから解決済みの GitHub Issue を源とし、それに対応するプルリクエスト（PR）とペアリングされます。モデルが生成したコード変更の正否を判定するため、各問題には以下の二種類のテストセットが付属しています：

• 未修正のコードベースでは失敗するが、Issue が適切に修正されればパスするテスト
• 修正前後もパスし、関連しない機能的動作が保たれていることを確認するためのリグレッションテスト

モデルはテスト内容を見ることはできず、元の Issue テキストのみと、修正前のリポジトリの状態を参照してコード変更を生成しなければなりません。提出したコード変更を適用した後で全てのテストがパスした場合にのみ、その問題は「クリア」とみなされます。われわれはその評価において、モデルの能力を見下げる原因となり得る多くの問題を発見しました：

• 一部のユニットテストが特定の実装詳細に過剰に焦点を当てすぎたり、タスクと整合していないために、正しい修正案さえも却下されてしまうケースがありました。
• 多くの問題記述は不十分であり、複数の正当な解釈が可能ですが、テストは特定の一つの解釈しかカバーしていませんでした。
• 環境のセットアップ（例：Linux か Windows か、Python のバージョンなど）によって、一部のテストが偶然に失敗することがありました。

SWE-bench Verified は 2024 年にこれらの課題を解決するために作成されました。専門ソフトウェアエンジニアとの協力の下、1,699 件の SWE-bench 問題をレビューし、上記の問題を抱えたものをフィルタリングしました。各問題については三人の専門家により independently に審査が行われ、その結果、500 件の厳選された問題からなる「SWE-bench Verified」が誕生しました。

SWE-bench Verified は初期バージョンに対して大きな改善をもたらしましたが、依然として残存する課題もあります。OpenAI の o3 モデルが 64 回の独立した実行で一貫して解決できなかった 138 件の SWE-bench Verified 問題について監査を実施し、各ケースについて少なくとも六名の経験豊富なソフトウェアエンジニアによって independently にレビューされました。専門家が問題を指摘した場合、追加のチームで再検証が行われました。

その結果、監査された 138 件の問題のうち 59.4% でテスト設計および／または問題記述に重大な不備が発見され、最も有能なモデルでも人間であっても極めて困難あるいは不可能に近い状態となっていました：

• 監査タスクの 35.5% は、特定の実装詳細を強制する厳格なテストケースを持ち、機能上は正しい提出物を却下します。これを「狭いテストケース」と呼びます。
• 18.8% の監査タスクでは、問題記述に明記されていない追加機能的動作を検証するテストが存在します。これを「広いテストケース」と呼びます。
• 残りの 5.1% はこの分類体系とよくまとまらない雑多な問題を有していました。

第一の失敗モードの具体例として

pylint-dev__pylint-4551

を挙げることができます。この PR では、全体的な解決策の一部として新しい関数

get_annotation

が導入されていますが、問題記述にはこの関数名は言及されていません。テストでは直接インポートされます。いくつかのモデルはこの関数の作成を直感的に行うかもしれませんが、この特定の名前の関数を実装することは、問題の適正な解決には必ずしも必要ではありません。多数の有効な解答がインポートエラーによりテストで失敗しました。

「広すぎるテストケース」の例としては

sympy__sympy-18199

が挙げられます。このタスクは、

nthroot_mod

関数に関する三つの異なる問題（#17373, #17377, #18212）を解決した PR から抽出されています。SWE-bench Verified のタスク記述では、その最後の問題 #18212 のみカバーされています。これにより不整合が生じます：PR テストは三つの問題をすべてカバーする一方、記述はの一つの問題の詳細のみを含んでいます。われわれの実行結果において、モデルは説明された修正を正しく実装することも多いのですが、他の二つ問題の实装をカバーするテストで失敗することがありました。

SWE-bench Verified とそのリポジトリ（コードベースおよびリリースノート）はどちらもオープンソースであり、広く利用・議論されているため、モデル開発者にとっては汚染回避が困難です。われわれ自身のモデルでも最初の汚染の兆候を確認しました。例えば、GPT-5.2 は 31 タスクを解決しましたが、われわれがほぼ不可能と判断したタスクの一つです。

django__django-14725

の場合、テストは明示的に問題記述に要求されていない特定の新しいパラメータ

edit_only

を必要とします。GPT-5.2 がこの問題を解決する際、その思考過程（chain of thought）において、コードベースの変更点を詳述したリリースノートに関する情報を有していること、そして

edit_only

パラメータが Django 4.1 で導入されたことを正しく特定しました。

汚染の規模をより広く評価するため、自動化されたレッドチーム化体制を設定しました。SWE-bench Verified の各問題に対して、GPT-5 を用いて GPT-5.2-Chat, Claude Opus 4.5, Gemini 3 Flash Preview の三つのモデルに汚染の有無を探らせるというタスクを行いました。これらには推論専用モデルは含まれていませんが、それらの間にも非自明な能力の差が存在する可能性を認めざるを得ません。汚染を検出するため、GPT-5 は SWE-bench Verified タスクの ID、記述、ゴールドパッチ、および PR テストを受け取りました。最大 15 回のターンにわたり、システム/開発者プロンプト、ユーザープロンプト、アシスタントプリフィル、そしてさまざまな誘発戦略を GPT-5 に変化させました。各ターンの後、判定モデルが新規タスク固有情報がどの程度出現したかをラベル付けし、各応答は「なし」から「強い」までの汚染の重症度でラベル付けされました。GPT-5 は前回のターンに基づいて戦略を適応させて、逐次的にタスク固有の詳細を取り戻すことができました。強く汚染された各事例について、別の判定モデルを用いて GPT-5 がターゲットモデルへ情報を過度に漏洩していないことを検証しました。最後に、本ブログ投稿に含まれるスクリプトによって構成される「強い」汚染事例を手動でレビューしました。

異なるモデルプロバイダにおける強力な汚染の具体例は以下の通りです：

• GPT-5.2：タスク記述からの短い断片が与えられた際、GPT-5.2 は正確なゴールドパッチを出力します。特に、クラス名とメソッド名、そして新たに導入された早期リターン条件

  if username is None or password is None

  を正確に把握しています。
• Claude Opus：Opus は、PR が導入した正確な 4 ラインの機能的変化だけでなく、関連する特定のファイル名とメソッドも想起し、さらに差分の一部であったインラインコメントをそのまま引用します。
• Gemini 3 Flash：タスクに関する追加情報なしで ID だけが与えられた場合でも、Gemini 3 Flash はタスク記述とゴールドパッチからの正確な詳細を出力できます。これにはユーザー名検証用の新しい正規表現式や、変更の正確な行番号が含まれます。

SWE-bench Verified におけるこの監査を通じて、評価設計に関する二つのより広範な教訓を得ました：

• 汚染リスク：公開情報から源となる Benchmark は、トレーニングデータへの露出によりスコアが静かに過大評価される汚染リスクを伴います。もしBenchmark の構築にパブリックにクロールされたデータが使用される場合、モデル開発者は追加の汚染テストを行う必要があります。公開される Benchmark そのものやその解答さえもトレーニングデータに含まれてしまう可能性があります。 datasets の公開方法（例：パスワード保護）とトレーニングデータのフィルタリング（例：カナリーストリングへの厳密な準拠）において十分な注意を払う必要があります。
• 自動採点の課題：自動採点は正しく実装するのが困難です。完璧なテストケースは特定の非重要な実装詳細に対して不感応であり、かつショートカット解答に対しても頑健であるべきです。これら問題は本質的に複雑で解決が難しく、これらの問題を検出するには複数の大規模な人間ラベルリングキャンペーンが必要でした。

われわれはこの発見を最近の評価活動に統合しました。過去数ヶ月間は、SWE-bench Pro の公開分割の結果報告を選択しています。他のモデル開発者にも同様にとめることを推奨します。SWE-bench Pro は完璧ではありませんが、経験的に汚染問題による影響は SWE-bench Verified よりも少なく観察されます。われわれの汚染パイプラインではいくつかの汚染事例を発見しましたが、それらは SWE-bench Verified に比べて顕著に稀で軽微であり、どのモデルも完全なゴールドパッチを出力するに至りませんでした。

われわれは引き続き、オリジナルのプライベート作成ベンチマークへの投資を行い、業界および学界にも同様の取り組みを支援するよう求めてまいります。GDPVal ではドメイン専門家によってタスクが私有で作成されることで露出リスクが軽減され、解答は訓練されたレビュアーによって包括的に評価されます。このアプローチはリソース集約的ですが、真の能力向上を測定するためにはますます不可欠です。