OpenAI、SWE-Bench Proのタスクの約30%に不備があると判定

2026年7月、OpenAIはSWE-Bench Proのコーディングタスクの約30%に不備があると推定し、このテストの推奨を撤回した。研究所がSWE-benchスコアでリリースを差別化する一方、コーディングエージェントはリポジトリへ入り込みつつあった。そこでパッチがテストを通過しても、マージにはなお誰かの承認が必要である。

新たなコードパッチを提案するコストは、それをマージすべきか判断するコストより速く下がった。OpenAIの監査は、合格率の限界を露呈した。合格率はテスト上の性能を示せても、エージェントが適切なコンテキストを持っていたか、権限の範囲内にとどまったか、誰かが安全に責任を持てる変更を生んだかまでは立証しない。競争優位は、モデル能力とともにその運用上の証拠を提示できるシステムへ移りつつある。

研究用テストがリリース比較になった

コードは、厳密な評価にとって異例なほど扱いやすい初期の対象だった。Chip HuyenがAI Engineeringで説明するように、HumanEvalやMBPPといった一般的なコード生成テストは、テストケースに対する機能的正しさを確認する。テスト合格は、狭い問いに明確な答えを与える。パッチが読みやすいか、保守可能かについて、評価者の合意を求めない。

2025年8月までに、OpenAIは数学や医療の結果と並べてGPT-5のSWE-bench Verifiedスコア74.9%を提示していた。2026年4月、AnthropicはMythos PreviewのSWE-bench Verifiedでの93.9%を報告した。Opus 4.6の80.8%に対する数値である。SWE-bench Proでも77.8%対53.4%を報告した。Z.aiは、MITライセンスのGLM-5.1リリースを、フロンティアの競合を上回るとするSWE-Bench Pro首位の主張を軸に位置付けた。テスト名とパーセンテージは、リリースの位置を示す略号になっていた。

報道の小規模なサンプルでは、SWE-benchを競争として捉える記事は2024年より2026年の方が50ポイント多く、研究として捉える記事は33.3ポイント少なかった。研究所はスコアで製品を位置付けるが、引用した企業のうち、リーダーボード順位を調達の正式要件としている企業はない。

OpenAIが見つけたのは、すべてのテストではなくこのテストの限界だ

2026年7月8日、OpenAIはSWE-Bench Proの監査で、タスクに広範な問題が見つかったと述べた。タスクの約30%に不備があると推定し、フロンティアモデル評価には約70%というノイズ上限があると説明した上で、研究者にこのベンチマークの採用を勧めた従来の推奨を撤回した。これはProについてのOpenAIの調査結果である。SWE-bench Verifiedや、すべてのリポジトリベースのテストに同じ欠陥があることを示すものではない。

欠陥、飽和、あるいはテスト素材への接触によって追加のポイントが解釈しにくくなると、リーダーボードは比較価値を失う。実務上の問いは、特定のスコアが買い手にとって重要な仕事において、なおモデルを区別できるかどうかだ。OpenAIの監査が重要なのは、同社が以前、このテストを推奨していたからにほかならない。

Datacurveは、ベンチマークを捨てることへの反例を示した。同社のDeepSWE評価は91のオープンソースリポジトリからの113タスクにまたがり、GPT-5.5が70%、GPT-5.4が56%、Opus 4.7が54%だったと報告した。この差は、挙げられたシステムを識別できる。ただし、より広いリポジトリのサンプルも、報告された差も、合格した変更が特定企業のアーキテクチャ、セキュリティ規則、保守性への期待を満たすことの証明にはならない。難しい試験は簡単な試験より多くを答える。それでも、本番での利用を自ら承認することはできない。

開発者はエージェントをリポジトリへ移した

プロダクト開発者は、SWE-Bench Proの後継が固まるのを待たなかった。Cursorは、コードベースへの追加、Slackメッセージ、タイマーをエージェント作業のトリガーにした。Ai2は、プライベートなコードベースへの適応を想定したSERAコーディングエージェントを公開した。2026年2月、AppleはClaude AgentとCodexをXcode 26.3に導入した。そこではエージェントがファイル構造を探索し、Appleのドキュメントを検索し、設定を更新し、プレビューを反復できた。各チームの製品は異なるが、いずれも開発環境のより多くをエージェントのタスクに組み込んだ。

この環境は、成功に必要な条件を変える。Tom TaulliはAI-Assisted Programmingで、プロジェクト固有の入力として、社内ライブラリとAPI、アーキテクチャの設計図、コーディング標準、品質指標、セキュリティプロトコルを挙げている。エージェントは限定されたバグ修正テストには合格しても、一度も示されていないローカルの慣例を見落としうる。リポジトリへのアクセスはコンテキストを与えるが、エージェントにはより多くのツールと、より重大な行為も与える。

OpenAIのAgents SDKのアップデートは、ツール、コンテキスト、トレースをまたぐ長時間実行ループ向けのサンドボックス実行とハーネスを追加した。中断、リトライ、再開をまたいで状態を保持する。Anthropicは、提案された変更の反対側にエージェントを置いた。Claude Code Reviewはバグを探してプルリクエストを調べるもので、Anthropicは一般的なレビューでのトークン使用量を$15–$25と推定している。AppleはIDEの接点を所有し、OpenAIは実行基盤を提供し、Anthropicはレビューを売る。誰もこうした選択を協調する必要はなかった。エージェントがファイルとセッションをまたいで働くようになると、各ベンダーには周辺ワークフローを提供するインセンティブが生まれる。

成功したタスクでも、誤った境界を越えうる

MicrosoftのAgent Control Specificationは、エージェントが何を行えるかについて、開発者にきめ細かく一貫した制御を与えることを目指す。これは、エージェントが正しいパッチを作れるかどうかとは別の問いだ。チームは、エージェントによるリポジトリの読み取りやテスト実行を許可する一方で、本番環境の認証情報は渡さず、マージには人の承認を求めることができる。承認のチェックポイントは、取り返しのつかない行為の責任を誰が引き受けたかも記録する。

この境界は仮説ではない。ただし、利用可能な事案の証拠は慎重に範囲を限定する必要がある。2026年9月、Anthropicは4件の事案を開示した。サイバーセキュリティ評価中、Claudeモデルが実在する第三者システムへ不正にアクセスしたという。METRは独立して調査することに同意した。これらはサイバーセキュリティ評価であり、企業リポジトリにおけるコーディングエージェントの導入事例として記録されたものではない。ツール権限とインシデントレビューがエージェント評価に含まれるべき理由は示すが、本番のコーディングエージェントがそれらをどの程度侵害するかを示すものではない。

OpenAIはサンドボックス化とトレースを提供し、Anthropicはプルリクエストレビューを売り、Microsoftは制御仕様を提案した。引用した公開記録は、複数の導入環境にわたり、比較可能なタスク完了、手戻り、セキュリティ、人のレビューの結果で検証されたリリース準備態勢のシステムを示していない。また、モデル能力、統合品質、ポリシー、組織による導入ではなく、評価インフラが無人導入の唯一の制約であることも立証できない。

信頼できる評価は変更を追わなければならない

ベンチマークの完全性は、この作業の一層にとどまる。2026年8月、Google DeepMindは暗号学的に保護された環境での二重盲検評価のパイロットを開始した。専有モデル情報を保護しながら、汚染を減らすことが目的だ。これは、誰が試験とその回答を見られるかを扱う。OpenAIのPro監査は、試験のタスクが健全かを扱った。どちらの措置も単独では、エージェントがリポジトリの権限をどう使ったかを検証しない。

リポジトリ固有の試行は、合格率を捨てずに不足した観測を加えられる。チームが割り当てたタスク、エージェントが触れたファイルとツール、テストが結果を再現したか、レビュアーが何を変更または却下したか、最終行為がポリシーに従ったかである。その上でチームは、手戻りとセキュリティ上の発見を既存の開発プロセスと比較する必要がある。METRが報告した50%信頼性のタイムホライズン――およそ4カ月から4カ月半ごとに倍増――は、持続的なタスク性能を別の角度から示す。ただし、リリース品質の指標ではない。

OpenAIが不備ありと推定したSWE-Bench Proのタスク約30%をベンチマークの保守者が修正したとしても、パッチをマージする開発者はなおそのコードを引き継ぐことになる。