OpenAIがコード評価ベンチマークの30%に欠陥を発見、SWE-Bench Pro監査結果
コード生成AIの能力を測るベンチマークは、モデルの安全性と展開判断の重要な根拠となる。そのベンチマーク自体に欠陥があれば、過大評価や過小評価を招き、誤った研究優先順位や安全性の見落としにつながる。
OpenAIが2026年7月、広く使われているコード評価ベンチマーク「SWE-Bench Pro」の大規模な監査結果を公開した。タスク全体の約30%に「破損（broken）」と呼ぶべき根本的な問題があり、評価指標としての信頼性が揺らいでいるという。
SWE-Bench Proとは何か
SWE-Bench Proは、AIモデルのソフトウェア開発能力をより現実的なタスクで測るために作られたベンチマークだ。前身のSWE-bench Verifiedが抱えていた設計上の問題やデータ汚染（contamination）を受け、より長期のタスクと実践的なコーディング能力を評価できるように設計されている。
具体的には、GitHub上の公開・非公開リポジトリから実際の機能変更履歴をもとにタスクを抽出する。モデルは既存の機能を壊さずに新機能を実装し、追加されたテストケースをすべて通過するコードを書く必要がある。公開されている731のタスクに対し、わずか8カ月で最先端モデルの合格率は23.3%から80.3%に急上昇した。
上の図は、SWE-Bench Proで見つかった「過度に厳格なテスト」と呼ばれる破損パターンを簡略化したものだ。プロンプトでは「ログイン機能」とだけ指示されているのに、裏側のテストでは特定のライブラリ使用を強制している。こうしたタスクでは、機能的に正しいコードが機械的に不合格になる。
監査で明らかになった破損タスクの実態
データの3割が信頼できない
OpenAIの監査パイプラインは、731件の公開タスクのうち200件（27.4%）を破損としてフラグした。さらに経験豊富なソフトウェアエンジニア5名による独立した人間レビューでは、249件（34.1%）が破損と判定されている。単純計算で、評価データの約3割がモデルの真の実力を反映していないことになる。
この数字の意味は重い。8カ月で合格率が約3.4倍に向上したという華々しい進歩の裏で、点数を押し上げた要因の一部が「タスク側の欠陥をうまくすり抜ける能力」だった可能性を否定できないからだ。
4つの主要な破損カテゴリ
監査で特定された問題は、大きく4つのタイプに分類される。いずれも「モデルが正しくコーディングできたか」ではなく「テストの書き方やプロンプトの不完全さ」が合否を決めてしまうパターンだ。
- 過度に厳格なテスト（Overly strict tests）: プロンプトには書かれていない特定の実装詳細（使用するライブラリ、関数名、データ構造など）をテストが要求する。機能としては正しいコードが不合格になる。
- 要件不足のプロンプト（Underspecified prompts）: プロンプトに記載されていない要件が隠しテストで課せられている。しかも、周辺コードやリポジトリの慣習からも合理的に推測できない内容だ。
- 低カバレッジのテスト（Low-coverage tests）: テストが機能のごく一部しか検証しておらず、不完全な実装でも合格してしまう。
- ミスリーディングなプロンプト（Misleading prompt）: プロンプトの指示がテストの要件と矛盾している。モデルが指示通りに実装すると不合格になるという、本末転倒な状態。
特に注目すべきは、人間レビューとエージェントによる自動分析で頻度の評価が異なった点だ。最も顕著な差が出たのが「低カバレッジのテスト」で、エージェントが4.1%と評価したのに対し、人間レビューでは9.4%がこれを主な問題として指摘した。人間の方が複数の破損パターンの重なりを認識しやすいことが一因とみられる。
品質監査パイプラインの仕組み
3段階のフィルタリング
OpenAIが構築した監査プロセスは、大きく3つの段階で構成されている。
第1段階は自動フィルタリングだ。プロンプトの指示内容、モデルの解答試行、採点用テストの3つを照合し、矛盾や問題のありそうなタスクを機械的に抽出する。この段階で286件がフラグされた。
第2段階はエージェント支援の詳細監査。Codexベースの調査エージェントがリポジトリ環境にアクセスし、テストの実行、ファイルの精査、モデルの解答パターンと失敗モードの分析を繰り返す。周辺コードやリポジトリの慣習を理解した上で「単なる曖昧さ」と「真の要件不足」を区別する点がポイントだ。
第3段階は経験豊富なソフトウェアエンジニア5名による独立レビュー。各タスクについて、問題文、テストケース、正解パッチを検討した後に、エージェントの分析結果を補足情報として参照する。意見が分かれたり確信度の低いケースは追加レビューに回された。
この3段階構成で特筆すべきは、AIエージェントと人間のダブルチェック体制だ。AIだけでは保守的になりがちな判定を、複数人の専門家が補完する。OpenAI Blogの記事によれば、エージェントが「破損でない」と判断したタスクで、人間レビューで最も多いラベルが「破損」だったケースはゼロだったという。74%のケースで両者の判断は重なっていた。
なぜ破損タスクが生まれるのか
根本的な原因は、SWE-Benchシリーズのタスク抽出方法にある。GitHub上の実際のIssueやプルリクエストは、元々人間同士の協業のために書かれたものだ。メンテナーとコントリビューターの間で長いやり取りを経て仕様が固まり、コードがマージされる。
このプロセスでは、問題文とマージされたコード、添付されたユニットテストがきれいに一対一対応するとは限らない。テストは「その変更が正しいか」を検証するために書かれており、「同じ機能を実現する他の方法」を許容するようには設計されていないケースが多い。つまり、人間用の協業ツールをそのままAI評価用に流用したことに、そもそも無理があったというのが実態だ。
ベンチマーク設計の難しさと今後の展望
「難しくて公平」なベンチマークのジレンマ
評価の難易度と公平性はトレードオフの関係にある。難しくしようとすればタスクは複雑になり、意図せず特定の実装方法に依存したテストが紛れ込む。公平にしようとすればタスクは抽象的になり、現実のソフトウェア開発から乖離する。
SWE-Bench Proのケースは、このジレンマに真っ向から直面した好例だ。最先端モデルの合格率が80%を超えた段階で「さらに難しい評価が必要」という圧力がかかる一方、タスクの質を担保する仕組みが追いついていなかった。
AIエージェントによる品質チェックの可能性
今回の監査自体が、AIエージェントの新しい活用方向を示している。Codexベースの調査エージェントは、大量のタスクに対してテスト実行やリポジトリ精査を高速に繰り返し、人間だけではスケールしない品質チェックを実現した。
従来、ベンチマークの品質管理は人手に頼る部分が大きく、大規模なデータセットでは現実的ではなかった。OpenAIの事例は「AIがAIの評価基準をチェックする」というメタ評価の時代の到来を感じさせる。
これからのベンチマーク開発に求められるもの
OpenAIは今回の監査結果を受け、SWE-Bench Proを推奨するという以前の見解を撤回した。同時に、評価コミュニティ全体に向けて、経験豊富なソフトウェア開発者がAI評価専用にベンチマークを設計するアプローチを提唱している。
重要なのは「ゲーム化されにくく」「信頼でき」「本当のモデル能力を反映する」評価基盤だ。それが安全性判断や展開戦略の土台になるからだ。SWE-Bench Proの教訓は、どんなに広く使われているベンチマークでも、定期的な品質監査が欠かせないというシンプルな事実に尽きる。
この記事のポイント
- SWE-Bench Proの公開タスク731件のうち、約30%が破損していると判明した
- 問題は「過度に厳格なテスト」「要件不足のプロンプト」「低カバレッジテスト」「ミスリーディングなプロンプト」の4カテゴリに分類される
- OpenAIは3段階の品質監査パイプライン（自動抽出 → AIエージェント調査 → 人間レビュー）で問題を特定した
- ベンチマークの定期監査と、AI評価専用に設計されたデータセットの必要性が改めて浮き彫りになった
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験