OpenAIのSWE-Bench Pro監査、Codexの成績を「壊れた課題」から守る
OpenAIが公開したSWE-Bench Proの監査は、コーディングAIの点数をめぐる細かな研究メモではありません。731件の公開課題のうち、約3割に壊れた評価課題があると推定し、Codexベースの調査エージェントと人間のエンジニアで確認したという話です。つまり、AIエージェントの競争は、モデルの正答率だけでなく、何を正答と呼ぶかを点検する仕事へ進んでいます。
問題はモデルの失敗だけではなく、採点側にもある
OpenAIは、SWE-Bench Proの公開731課題を監査し、データ品質パイプラインでは200件、つまり27.4%を壊れた課題として検出したと説明しています。別の人間アノテーションでは249件、34.1%が壊れていると判断され、OpenAIは全体の約3割に破綻があると見積もりました。
壊れ方はかなり実務的です。テストがプロンプトにない実装方法を強制する。プロンプトが隠しテストの前提を説明していない。テストのカバレッジが低く、未完成の修正でも通る。あるいは、プロンプトがテストと矛盾する方向へモデルを誘導する。これは単なる採点ミスではなく、AIエージェントが何を学び、製品チームがどの数字を信じるかに直結します。
| 分類 | 何が起きるか | コーディングAI評価への影響 |
|---|---|---|
| 厳しすぎるテスト | プロンプトにない実装詳細まで強制する | 機能的に正しい修正が失敗扱いになる |
| 不足したプロンプト | 隠しテストが要求する前提を問題文が説明しない | モデルの限界ではなく、課題の情報不足で落ちる |
| 低カバレッジのテスト | 要求機能を十分に検査しない | 不完全な修正が成功扱いになる |
| 誤誘導するプロンプト | テストが求める挙動と違う方向へ指示する | 失敗原因がモデル能力ではなく問題設計に寄る |
ここで面白いのは、OpenAIが『モデルができない』と『課題が不正確』を分けようとしていることです。コーディングエージェントが複雑な変更を扱えるようになるほど、失敗ログを見ただけでは、モデルの限界なのか、テストの過剰指定なのか、問題文の不足なのかを切り分けにくくなります。
Codexは解答者ではなく、評価課題を調べる側にも回った
今回の監査で重要なのは、Codexがベンチマークを解くモデルとしてだけ登場していない点です。OpenAIは、疑わしい課題について、Codexベースの調査エージェントにリポジトリ、環境、モデルの試行、失敗トレースを調べさせ、人間の研究者が最終判断したと説明しています。
これは、AIエージェントの使い道としてかなり示唆的です。エージェントは、課題を解いてスコアを上げるだけでなく、課題そのものの妥当性を調べる作業にも使われ始めています。近くのコード、既存テスト、失敗パターンを読み、曖昧さが実装で解ける範囲か、それとも課題側が壊れているのかを調べる。これはソフトウェアエンジニアがレビューでやっている判断に近い仕事です。
もちろん、OpenAIはエージェントだけで結論を出していません。経験あるソフトウェアエンジニア5人による人間アノテーションも並行し、判断の重なりや差分を確認しています。ここで見えてくるのは、AIで監査を自動化する話ではなく、AIで候補を絞り、人間が評価の基準を守るハイブリッドな品質管理です。
ベンチマークの点数は、製品判断のUIになってしまう
OpenAIは、評価の欠陥がモデル能力の理解を歪め、安全性判断や研究優先順位にも影響すると書いています。これは研究者だけの問題ではありません。Codexや類似のコーディングエージェントを導入する読者にとっても、ベンチマークの点数は『どこまで任せてよいか』を判断する画面の一部になっています。
たとえば、あるモデルが短期間で23.3%から80.3%へ伸びたように見えると、製品チームは自動修正、長時間タスク、レビュー自動化の範囲を広げたくなります。しかし、課題の一部が壊れているなら、その伸びは実力だけでなく、採点面のノイズを含みます。点数は便利ですが、信頼できない点数はUIとして危険です。
Interface Wire的に見ると、今回の話は『AIがコードを書けるか』より『AIの仕事をどう観測するか』にあります。作業ログ、テスト、リポジトリ状態、人間レビュー、ベンチマークの品質。これらを一緒に見ないと、エージェントの能力は数字だけで過大にも過小にも見えます。
次の評価は、難しさより検証可能性を問われる
OpenAIは今回の結果を受けて、SWE-Bench Proの採用推奨を撤回するとしています。さらに、経験あるソフトウェア開発者が最初から評価目的で作る新しいベンチマークを期待すると書いています。ここで求められているのは、単に難しい課題ではありません。モデルが失敗したときに、なぜ失敗したかを検証できる課題です。
これは、以前のDeployment Simulation記事やAppleのEvaluations framework記事ともつながります。AIの評価は、問題集を作って点数を出すだけでは足りなくなっています。実利用に近い文脈、再現できるテスト、採点基準、失敗の分類、人間の監査。それらを組み合わせて、初めて製品判断に使える信号になります。
コーディングAIの次の競争は、ベンチマークで勝つことだけではなく、ベンチマークを信じられる状態に保つことです。OpenAIの監査は、エージェント時代の評価基盤そのものが、もう一つのプロダクト面になり始めたことを示しています。
SWE-Bench Proの約3割が壊れているというOpenAIの見積もりは、コーディングAIの進歩を否定する話ではありません。むしろ逆です。エージェントが複雑な実務へ近づくほど、評価もまた複雑な実務になります。テストが厳しすぎるのか、問題文が足りないのか、モデルが本当に理解していないのか。その切り分けまで含めて、AIの能力を測るインターフェイスを作り直す必要があります。