2026年7月8日

コーディング評価における信号とノイズの切り分け

詳細な監査を通じて、SWE-Bench Pro に広範なタスク上の問題があることを確認し、タスクの約 30% が破綻していると推定しています。

読み込んでいます...

OpenAI の Preparedness Framework⁠（新しいウィンドウで開く）に基づく判断を含め、健全なデプロイと安全性に関する意思決定には、モデルの能力を正確に測定することが重要です。私たちはモデルをリリースするたびに、モデルの進歩を追跡するため、さまざまな外部および内部ベンチマークの結果を報告しています。評価に結果へ影響する欠陥があると、能力について誤った理解を与え、安全性に関する根拠を歪め、研究の優先順位にも影響を及ぼす可能性があります。

私たちは最近、調査を行い、最も広く使われているコーディングベンチマークの 1 つである SWE-bench Verified に根本的な設計上の問題とコンタミネーションの問題があることを明らかにし、この評価がソフトウェア開発能力について意味のあるシグナルをもはや提供していないことを確認しました。その時点で、私たちはより広いコミュニティに SWE-Bench Pro への移行を推奨しました。

SWE-Bench Pro⁠（新しいウィンドウで開く）は、より長い時間軸とより現実的なコーディングタスクでモデルをテストし、エージェント型コーディング能力をより適切に追跡することで、SWE-bench Verified を改善するために設計されました。SWE-bench Verified と同様に、タスクは公開および非公開リポジトリ群の機能変更履歴からプログラム的に取得されます。モデルには、既存機能を壊さずに、機能に対する新しいテストに合格する解決策を実装することが求められます。731 タスクからなる公開分割では、フロンティアモデルの合格率が 8 か月で 23.3% から 80.3% に向上しました。

その後、私たちは SWE-Bench Pro についても同様の監査を行い、データポイント分析パイプラインを使ってデータセットをレビューしました。このパイプラインは、タスクに対するモデルの試行、タスクのメタデータ、失敗トレースをレビューし、評価上の欠陥が疑われるものを検出しました。検出された各タスクは、複数回の調査エージェントによる確認を経たうえで、経験豊富な 5 人のソフトウェアエンジニアが独立にレビューし、意見が分かれた場合は追加調査にエスカレーションしました。

データセットのかなりの部分に、破綻した問題がある証拠が見つかりました。データポイント分析パイプラインでは破綻したタスクが 200 件（27.4%）検出され、人手によるアノテーションキャンペーンでは 249 件（34.1%）が特定されました。

問題は主に 4 つのカテゴリに分類されました。

過度に厳格なテスト¹ は、プロンプトで指定されていない特定の実装詳細を強制し、機能的には正しい多くの提出物を無効にします。
仕様が不十分なプロンプト² は、非公開テストが要求し、かつ合理的には推測できない要件を省いています。
カバレッジの低いテスト は、求められた機能を十分にチェックしないため、不完全な修正でも合格できてしまいます。
誤解を招くプロンプト は、モデルを誤った挙動へ誘導するか、テストが要求する内容と矛盾します。

今回の知見は、難しくても公平なベンチマークを整備することの難しさと、スケーラブルなデータ品質チェックにおけるエージェントの有用性の高まりを示しています。これらの結果を踏まえ、私たちは SWE-bench Pro のタスクの約 30% が破綻していると推定し、モデル開発者には結果を慎重に検証することを勧めます。

方法論

私たちの目的は、タスクの失敗が真のモデルの限界を反映し、タスクの成功がプロンプト要件に対する完全で妥当な解決策を反映するようにすることです。評価に使われるデータの品質を確認するため、各データポイントがモデルの能力を正確に反映しているかを評価する品質保証パイプラインを作成しました。

タスク品質を評価するために、自動スクリーニングと人手レビューを組み合わせた品質保証ワークフロー。 — 初期のデータ品質パイプラインが、レビュー対象となる問題を検出します。検出されたタスクについて、より詳細なエージェント支援の監査と、経験豊富なエンジニアによる人手アノテーションキャンペーンで検証します。

最初の自動フィルターでは、モデルに与えられた指示、タスク解決に向けたモデルの試行、そしてそれらの試行を採点するためのテストをレビューし、破綻または問題がある可能性の高い例を検出します。このフィルターは、破綻している可能性のある 286 件のタスクを検出しました。次に、そのサブセットを 2 つの方法でより詳しくレビューしました。調査エージェントによる広範なチェックと最終的な人間の判断を組み合わせた、人間が監督するエージェントレビュー、および経験豊富なソフトウェア開発者による人手アノテーションキャンペーンです。

人間が監督するエージェントレビュー

検出された各問題は、タスクのリポジトリと環境へのアクセスを与えられた Codex ベースの調査エージェントによって監査されます。これにより、近くのコードやリポジトリの慣例を調べれば解消できることが多い妥当なタスクの曖昧さと、真の仕様不足とを区別しやすくなります。エージェントはテストを実行し、リポジトリ内のファイルを調べ、モデルの試行やそのタスクでよく見られる失敗モードを調査できます。こうした詳細な監査を独立に数回繰り返した後、研究者が要約を確認し、最終判断を下して、可能性の高い問題にラベルを付けました。

人手アノテーションキャンペーン

並行して、検出されたサブセットに対して人手アノテーションキャンペーンを実施しました。レビューに先立ち、ベンチマークの目的、問題の分類体系、境界事例についてトレーニングを受けた経験豊富なソフトウェアエンジニアと協力しました。各タスクは 5 人のエンジニアによってレビューされました。

レビュアーは、パイプライン分析やトランスクリプトを補助的な文脈として使う前に、表示されている問題文、テストケース、正解の参照解（ゴールドパッチ）から独立に判断を下しました。その後、レビュアーは具体的な証拠に基づいてラベルと重大度評価を割り当て、意見が分かれたケースや確信度の低いケースを追加レビューにエスカレーションしました。

人間のレビュアーは、調査エージェントよりもタスクを破綻していると判断する傾向が高くなりました。2 つのレビュー経路の間ではカテゴリにも多少の不一致がありましたが、検出されたどのタスクでも、人間によるラベルで「破綻していない」が最多になることはありませんでした。エージェントパイプラインが検出したカテゴリについては、レビュアーの判断と 74% のケースで重なっていました。

また、人間のレビュアーはエージェントパイプラインに比べて、1 つのタスクに複数のラベルを選択する傾向が高く、タスクが複数の形で破綻している、または単一のカテゴリにきれいに収まらないと判断していたことが示されました。これは、エージェントとレビュアーを組み合わせたパイプラインのラベル付けが保守的だったことを示唆しています。人間が特定した大まかな失敗モードは同じように捉えつつ、レビュアーが追加または重複する問題を見出したケースは過少に数えていたためです。最大の差はカバレッジの低いテストにあり、人間はこれをベンチマークの 9.4% で最も一般的な問題として選択したのに対し、エージェントパイプラインでは 4.1% でした。

失敗モード

いくつかのケースでは、タスクのプロンプトが特定の実装を指示していましたが、非公開のテストケースは異なる挙動を想定していました。

This task involves normalizing table-of-contents entries and rendering them back to Markdown via TocEntry.to_markdown(). The task prompt specifies serialization down to character-level spacing, describing how exact spacing and pipes are enforced, and gives examples such as " | Chapter 1 | 1" and "** | Chapter 1 | 1":

なし

1"[space]| Chapter 1 | 1"
2"**[space]| Chapter 1 | 1"
3"[space]| Just title | "

The hidden test_to_markdown assertions instead require " | Chapter 1 | 1" and "** | Chapter 1 | 1":

なし

1"[space][space]| Chapter 1 | 1"
2"**[space][space]| Chapter 1 | 1"
3"[space][space]| Just title | "

There are two leading spaces in the hidden tests, but the example given to the model only contains one leading space. If a model rightly follows the given prompt, that one-character difference would fail the hidden test cases and the task would be marked incorrect.

考察

私たちが特定した問題は、SWE-bench Verified で見られた同様のケースとあわせて、ベンチマークを厳密にチェックすることの重要性を浮き彫りにしています。オープンソースリポジトリの Issue やプルリクエストは、もともと人間同士の協働のために作られたもので、多くの場合、メンテナーとコントリビューターの長いやり取りを通じて進められていました。そのため、問題説明、マージされたコード、ユニットテストが、モデルを信頼性高く評価するための明確で独立したタスクとして常に整合するとは限りません。特に、プルリクエストに含まれるテストは、タスク解決のための実装非依存の基準を定義するためではなく、特定の変更を検証するために書かれているため、過度に厳格になることがあります。

同時に、評価上の欠陥は、ほんの少し前と比べても検出しやすくなっています。モデルの能力が向上するにつれて、私たちはそれらのモデルを使い、プロンプト、テスト、パッチ、トレース、境界事例をはるかに深く一貫して調査できるようになり、以前なら大規模に見つけるにはコストが高すぎる、または現実的でなかったベンチマーク上の問題を明らかにしやすくなります。

私たちは、より広い評価コミュニティが、モデルの能力をテストすることに特化して経験豊富なソフトウェア開発者が構築する新しいベンチマークを開発することを期待しています。そのアプローチにより、モデルの能力を測るうえで求める高い基準と現実性を保ちつつ、プロセス全体を通じてより優れた人間の監督が可能になります。今回の分析で明らかになった問題を踏まえ、私たちは SWE-Bench Pro の採用を勧めた以前の推奨を撤回します。

最終的に、評価は、攻略されにくく、信頼しやすく、モデルの能力やアラインメントを真に反映するベンチマークを通じて、意味のあるシグナルを提供するべきです。これらの結果は OpenAI のデプロイと安全性に関する意思決定に影響するため、私たちが追跡する評価は妥当で有益である必要があります。