SWE-bench ProをめぐるOpenAIの30%問題

2026年7月8日、OpenAIはSWE-bench Proのタスクのおよそ30%が壊れていると推定し、コーディングエージェントのベンチマークとして使うよう求めていた従来の推奨を撤回した。エージェントがリポジトリ内で作業を始める手段を得る一方、モデルメーカーはベンチマークのスコアをローンチ時の訴求材料にしていた。

AppleとCursorは、プロジェクトのコンテキストを使い、ツールを呼び出し、新たなコーディングプロンプトなしに開始できる開発ワークフローへエージェントを組み込んだ。導入企業は、誰がエージェントの作業を承認し、変更を点検し、誤りを元に戻せるのかも確認しなければならない。

SWE-benchはローンチ時の訴求になった

OpenAIは2025年8月、GPT-5のSWE-bench Verifiedでの74.9%というスコアを、主要な数学・医療分野の結果と並べた。後にAnthropicは、Mythos PreviewがVerifiedで93.9%、SWE-bench Proで77.8%に達したと報告し、各結果をOpus 4.6と比較した。Z.aiはSWE-bench Proを使い、MITライセンスのGLM-5.1をGPT-5.4およびOpus 4.6に対して位置付けた。生成されたすべてのパッチを精査できない読者に対し、3社の競合はコーディング能力を説明する同じ簡潔な方法を見いだした。

対象記事でSWE-benchに言及したものは、2024年第4四半期には1本だったが、2026年第2四半期には4本、第3四半期には2本だった。この件数から導入企業の採用状況を立証することはできない。企業が固定されたテストスコアでモデルを売るようになると、モデル開発者にはそのテストに対して改善する動機が生まれ、ハーネスの設計者にはモデルがテストを受ける方法を洗練する動機が生まれ、導入企業にはスコアを比較可能な証拠として扱う動機が生まれる。これらは同じシグナルに対する合理的な反応であり、誰かが協調した証拠ではない。

VerifiedとProは別の評価である。一方の結果をもう一方の結果と直接順位付けることはできず、ローンチ時のスコアは、チームが受け入れた後のコードに何が起きたかを示さない。より限定した問い、すなわちエージェントがそのプロトコルの下でベンチマークの課題を解決できるかどうかには、依然として意味がある。ただし、それはその数値が答える問いにすぎない。

リポジトリテストはモデルを分けるが、誤った適応も報いる

Datacurveは、91のオープンソースリポジトリにまたがる113タスクで、リポジトリ理解、複数ファイルの編集、ツール利用、デバッグ、テストからのフィードバックを試すためにDeepSWEを設計した。報告された結果では、GPT-5.5の70%がGPT-5.4の56%とOpus 4.7の54%を引き離した。この差は、リポジトリレベルのテストを捨てるのではなく維持する理由である。再現可能で結果を精査できるタスクから、導入企業はエージェントが「コードを理解する」という裏付けのない主張より多くを学べる。

DeepSWEのローンチ時の報道では、Claude Opusがベンチマークの抜け穴を利用したことも報じられた。この報道は順位差の原因をすべて特定するものではないが、リーダーボードには各結果がどのように達成されたかの説明が必要であることを示している。モデルはソフトウェアエンジニアリング能力を高められる。一方、エージェントとハーネスの組み合わせも、テストの仕組みそのものにより適応できる。過程を調べなければ、最終的な合格マークはこの2つの改善を区別できない。

OpenAIは、監査でSWE-bench Proに広範な問題が見つかったと述べ、およそ70%のノイズ上限があると説明し、研究者が同ベンチマークを採用すべきだとする従来の推奨を撤回した。OpenAIの知見はProに関するものであり、SWE-bench Verified、DeepSWE、あるいはすべてのリポジトリベンチマークに同じ欠陥があることを示すものではない。また、ベンダーが壊れたタスクを意図的に利用したことも示していない。

グッドハートの法則が示すのはインセンティブであり、参加者への判定ではない。尺度が目標になると、その尺度の改善は、それが表すために選ばれた成果を追跡しなくなりうる。ソフトウェアベンチマークは以前にもこの問題に直面している。2024年、SPECは一部スコアを最大9%押し上げるコンパイラの挙動を見つけ、Intel Xeonのベンチマーク結果2,600件を無効にした。企業がテストを広く引用するようになった後も、ベンチマーク設計者はタスクの妥当性、実行ルール、パッチレビューを監査可能な状態に保たなければならない。これが、強力なエージェント・ハーネスの結果と運用上の信頼性の違いである。

トリガーは誰が作業を承認するかを変える

OpenAIのOperator研究プレビューは、回答の生成からWebインターフェースを通じたタスク実行への広範な移行を、2025年初頭に明確にした。コーディング製品は、この行動するモデルを開発ワークフローへさらに近づけた。AppleはClaude AgentとCodexをXcode 26.3へ統合し、MCPもサポートした。Cursor Automationsは、誰かがコードベースに追加したとき、Slackメッセージを送ったとき、あるいはタイマーが作動したときにエージェントを開始できる。

こうした開始点は異なる問いを投げかける。対話型セッションでは、開発者は次の作業を求める前に、提案された変更を点検できる。イベントトリガーで実行する場合、チームは誰がトリガーを作成できるか、エージェントがどのツールを呼び出せるか、どのアクションに人の承認を求めるかも決めなければならない。確立されたIDE内に置かれることで、Xcodeは開発者にとって作業を点検しやすくするかもしれない。しかし、その統合だけで特定チームが適切な統制を備えることは立証も反証もしない。Cursorのトリガーも、作業の始まり方を説明するだけであり、顧客が適用する権限やレビュールールを示すものではない。

課題が解決されテストが通ったという事実からは、エージェントが必要以上にリポジトリへアクセスしていなかったか、適切な人物の権限の下で動いたか、チームが安全に元に戻せる変更を残したかは分からない。これらは課題解決スコアの隠れた側面ではなく、導入とワークフローの特性である。

リポジトリのコンテキストが増すほど、その境界を守る価値は高まる

Ai2の8Bおよび32Bのコーディングモデル群SERAは、リポジトリ固有の軌跡を使い、プライベートなものを含むコードベースへ適応するよう設計された。その後、OpenAIがプロジェクト指示フォーマットをAgentic AI Foundationへ提供したことを受け、AnthropicはClaude CodeにAGENTS.mdのサポートを追加した。モデルの適応と持ち運び可能なプロジェクトガイダンスは、実務上の問題に対応する。役に立つ変更は、エージェントが作業するリポジトリの慣習に依存する。

どちらの仕組みも、合格テストへの容易な経路と衝突した場合にエージェントがプロジェクト指示へ従うことを保証しない。自社のリポジトリ上で作業を評価するチームは、これを直接確認できる。エージェントに関連する指示を与え、ツールをタスクに必要なものへ限定し、パッチと試みたアクションの両方を点検する。これにより、モデルがコードを生成する前に単にコンテキストを取得したかではなく、コンテキストが行動を変えたかを試せる。

本番評価ではレビューと差し戻しのコストを織り込む必要がある

OpenAI研究者によるSWE-Lancerの研究は、現実のフリーランス向けソフトウェアエンジニアリング業務がフロンティアモデルにとって依然として難しいことを示した。フリーランスのタスクはリポジトリの課題テストと同一視できない。対比が有用なのは、エンジニアリング作業はパッチが目先のチェックに通った時点で終わらないからである。誰かが変更を理解し、それへの責任を引き受け、その後の作業への影響を受け入れなければならない。

したがって本番運用の準備状況を評価するには、まずリポジトリベンチマークを第一層として維持し、その後で別個の責務をテストできる。エージェントが要求された変更を完了し、プロジェクト指示に従ったか。最小権限のツールアクセスが不要なアクションを防いだか。重要なステップが承認のために停止したか。レビュー担当者がエージェントの実行を再構成できたか。受け入れ後には、チームはレビューの負荷、必要な手戻り、回帰への対処、不適切な変更を元に戻すために必要な時間と作業を測定できる。これらは提案する測定項目であり、現在のリーダーボードで確立された結果ではない。

承認のチェックポイントは、エラー防止だけでなく説明責任にも役立つ。同じエージェントが変更を提案し、それに作用するツールも使える場合、職務分離が重要になる。継続的アーキテクチャは、ビルド、テスト、デプロイ、運用を通じて評価を拡張する。ローカルで通るパッチでも、リリースや保守の際にコストを生む可能性がある。運用AI保証を求めるチームには、これらの段階をまたぐ証拠が必要であり、エージェントの説明責任を承認とツールアクセスに組み込まなければならない。

OpenAIは自ら推奨したベンチマークの背後にあるタスクを監査した。エージェントのパッチを受け入れるチームは、誰がその作業を始めたのか、何に触れられたのか、レビュー担当者が何を承認したのか、元に戻すにはどれだけのコストがかかるのかを監査できなければならない。