AIプログラミング最強ランキング、その数字は信用できるのか?OpenAIが「SWE-Bench Pro」の3割を欠陥と認め推奨を撤回した件【2026年7月】

OpenAIが主要コーディング評価「SWE-Bench Pro」を監査し、公開課題の約30%に不備があると認めて推奨を撤回しました。GPT・Claude・Geminiの点差は本当に実力差なのか、ベンチマークの「受験勉強化」、実務能力の測り方までを一次情報に基づいて整理します。

AIコーディングベンチマークの数字は信用できるのかを問うカバー画像
テクノロジー
公開日: 2026年7月16日
読了時間: 13
著者: ぽちょ研究所
読了時間: 13

1. 「AI最強」ランキングが揺れた日

「GPTとClaude、どっちがコードを書くのが上手いの?」——この問いに、私たちはいつの間にか一つの答え方を覚えてしまった。ベンチマークの点数を並べるという答え方だ。SWE-bench Verifiedで88.7%、SWE-Bench Proで69.2%。小数点以下まで並んだ数字は、いかにも客観的で、疑う余地のない「実力の序列」に見える。

ところが2026年7月、その前提を根底から揺さぶる出来事が起きた。OpenAI自身が、業界が「最も難しく、最も実務的」と評価していたコーディング評価指標「SWE-Bench Pro」を監査し、公開課題の約30%に不備があると結論づけたのだ。そしてOpenAIは、かつて自分たちが出した「これを標準的な評価に使うべき」という推奨を、正式に撤回した[1]

これは単なる一指標の不具合報告ではない。「AIプログラミング最強ランキング」という、いま業界全体が信じている数字そのものの信頼性に関わる話だ。この記事では、(1) 何が壊れていたのか、(2) GPT・Claude・Geminiの点差は本当に実力差なのか、(3) モデルがベンチマークに合わせて作られる「受験勉強化」、(4) では実務能力をどう測ればいいのか——という4点を、公表された一次情報に沿って掘り下げる。

SWE-Bench Pro公開731課題のうち約3割が不備と判定されたことを示す図解

図1: OpenAIの監査結果。公開731課題のうち、自動パイプラインは200件(27.4%)、人手レビューは249件(34.1%)を「壊れた課題」と判定した。

2. 何が起きたのか:OpenAIがSWE-Bench Proを監査した

SWE-Bench Proは、データ企業のScale AIが構築したソフトウェア開発ベンチマークだ。実在するオープンソースリポジトリの課題(Issue)をモデルに与え、「テストが通るコードを書けるか」で採点する。従来のSWE-bench Verifiedが上位モデルの点数で飽和し、さらに学習データへの混入(コンタミネーション)が指摘されたため、その後継として「より難しく、より現実的な評価」を掲げて登場した。

OpenAIが監査したのは、このProの公開分731課題(public split)だ。方法は3段構えだった。まず、モデルの挑戦履歴とテストの採点挙動を機械的に分析する自動データ品質パイプライン。次に、リポジトリにアクセスできるCodexベースの調査エージェントが、疑わしい課題を一件ずつ検証。最後に、5人の経験豊富なソフトウェアエンジニアが独立してレビューした。

結果は厳しいものだった。自動パイプラインは200件(27.4%)を、人手レビューは249件(34.1%)を「壊れている(broken)」と判定した。どちらの見積もりでも、おおむね3課題に1課題が、評価指標として信頼できない状態だったことになる。OpenAIの研究チームは端的にこう述べている——「私たちはSWE-Bench Proを採用するという以前の推奨を撤回する」[1]

重要なのは、これが「モデルが弱い」という話ではなく「ものさしが歪んでいた」という話だという点だ。ものさしが歪んでいれば、そのものさしで測ったすべての順位——GPTが上か、Claudeが上か、Geminiが何位か——の意味が揺らぐ。

3. 「壊れた課題」の中身:4つの欠陥パターン

では「壊れている」とは具体的にどういうことか。OpenAIは欠陥を大きく4類型に整理している。

欠陥の型内容何が起きるか
過度に厳格なテスト問題文に明示されていない実装詳細まで一致を要求する正しく動く解でも「不正解」にされる
過少仕様の問題文必要な要件が問題文から抜けている何を作るべきか読み取れないまま採点される
低カバレッジのテスト要求機能を十分に検証していない不完全な修正でも「正解」で通ってしまう
誤誘導する問題文矛盾した指示や誤った方向づけを含むモデルを間違った実装へ誘導する

この4つは、方向が正反対の2組に分かれる点が示唆的だ。「過度に厳格」と「低カバレッジ」は、テストの厳しすぎ/緩すぎという真逆の失敗。「過少仕様」と「誤誘導」は、問題文が足りない/間違っているという真逆の失敗だ。つまり採点の甘辛が両方向にブレていて、優秀なモデルが減点され、雑な解が満点を取ることが同時に起こりうる。これでは点差を実力差として読むのは難しい。

OpenAIによれば、こうした欠陥は「リポジトリの履歴からプログラム的に自動組成した」ベンチマークにありがちだという。人手のレビューが薄いまま大量生産すると、機械的には成立していても人間の開発者から見れば破綻した課題が紛れ込む。

壊れた課題の4類型を厳しすぎ・緩すぎ・不足・誤りの2軸で整理した図解

図2: 4つの欠陥パターン。テストの「厳しすぎ/緩すぎ」と、問題文の「不足/誤り」という両方向のブレが、点数の意味をぼかしてしまう。

4. なぜProが生まれたのか:ベンチマーク世代交代の歴史

今回の話を理解するには、コーディング評価が短期間で何度も世代交代してきた事実を押さえる必要がある。

もともとSWE-benchは、GitHubの実際のIssueとPull Requestから作られた画期的な評価だった。だがオリジナルには曖昧な課題や解けない課題も混じっていたため、人手で精査した部分集合としてSWE-bench Verifiedが整備された。ところが2026年に入ると、上位モデルがVerifiedで軒並み88%前後に到達し、指標として飽和。加えて、評価課題が学習データに混入している疑い(コンタミネーション)も強まり、OpenAIは2026年2月にVerifiedを実質的に「役目を終えた指標」として扱うようになった。

その空席を埋めるべく登場したのが、Scale AIのSWE-Bench Proだ。より大規模なリポジトリ、より長い修正、より厳しいテストを掲げ、「実務に近い難易度」を売りにした。実際、点数は一気に下がり、トップモデルでも6〜7割前後にとどまる。難しくなったこと自体は、指標として健全な方向だった。

しかし今回の監査で、Proもまた別の形で壊れていたことが分かった。飽和とコンタミネーションを避けようと難度と規模を上げた結果、今度は課題の品質管理が追いつかず、3割が欠陥品になっていた。皮肉なことに、「難しくする」ことと「正しく測る」ことは別問題だったのだ。

SWE-benchからVerified飽和・Pro登場・推奨撤回までの世代交代を示す時系列図

図3: コーディング評価の世代交代。飽和とコンタミネーションを避けて難度を上げたProが、今度は品質管理で躓いた。

5. 点数を並べてみる:VerifiedとProのギャップ

議論を具体的にするため、2026年前半に各所で報じられた代表的なスコアを並べてみる。数値は測定条件や時期で変動するため、あくまで傾向を掴むための目安として見てほしい。

指標GPT系Claude系Gemini系
SWE-bench Verified(飽和)88.7%(GPT-5.5)88.6%(Opus 4.8)80.6%(Gemini 3.1 Pro)
SWE-Bench Pro(高難度)約59%(GPT-5.4)69.2%(Opus 4.8)

まず目を引くのは、VerifiedではGPTとClaudeが誤差の範囲(0.1ポイント差)で並んでいること。88.7%と88.6%を「GPTの勝ち」と読むのは、ほぼ意味がない。Verifiedはすでに天井に張り付いていて、上位陣を区別する解像度を失っている。

一方、より難しいProではスコアが5〜7割まで落ち、モデル間の差も開いて見える。だからこそ業界は「本当の順位はProで決まる」と見なしてきた。ところがそのProの3割が壊れていた。つまり、私たちが「本当の実力差」を読み取っていたつもりの土俵そのものが、3課題に1課題の割合で歪んでいたことになる。

SWE-bench VerifiedとSWE-Bench Proのスコア比較と飽和を示す棒グラフ

図4: Verifiedは上位が88%前後に密集し飽和。Proは点数が下がり差も見えるが、その3割に不備があった。

6. GPT・Claude・Geminiの点差は「実力差」なのか

ここで核心の問いに戻る。ランキングの点差は、本当に実力差なのか。

冷静に考えると、点差を実力差として信じるには、少なくとも3つの前提が要る。第一に、課題そのものが正しいこと(問題文が明確で、テストが妥当)。第二に、採点が公平であること(正しい解を落とさず、雑な解を通さない)。第三に、測定条件がそろっていること(同じ足場・同じ試行回数・同じ制約)。今回の監査は、このうち第一と第二が3割の課題で崩れていたことを示した。

具体的に考えてみよう。もし0.1ポイント差の2モデルがあり、その差が「たまたま壊れた3課題」の当たり外れで生まれているとしたら、その順位は実力ではなくだ。さらに、Verifiedのように飽和した指標では、残っている数ポイントの差は「本当に難しい少数の課題」に集中する。その少数が偏っていたり壊れていたりすれば、順位はいくらでもひっくり返る。

だから正直に言えば——上位モデル間の小さな点差(数ポイント以内)は、実力差の証拠としてはかなり弱い。これは「GPTもClaudeも大差ない」という意味ではなく、「その数字だけでは大差の有無を判定できない」という意味だ。数ポイントではなく二桁の差が、複数の独立した指標で、再現的に出て初めて、実力差として語る資格が出てくる。

7. ベンチマーク受験勉強化:グッドハートの法則

もう一つ、点数を鵜呑みにできない構造的な理由がある。モデルがベンチマークに合わせて作られていくという力学だ。

経済学に「グッドハートの法則」という有名な言葉がある——「ある指標が目標になると、それは良い指標ではなくなる」。ベンチマークの点数が製品価値やニュースの見出しに直結する世界では、開発の焦点が自然と「そのベンチマークで高得点を取ること」に寄っていく。これは不正を意味しない。データ配合の調整、評価に似たタスクでの反復学習、失敗パターンの潰し込み——どれも真っ当な最適化だが、積み重なると指標に過剰適合(オーバーフィット)したモデルが生まれる。いわば「受験勉強化」だ。

さらにやっかいなのがコンタミネーション、つまり評価課題そのものが学習データに紛れ込む現象だ。公開ベンチマークはネット上に存在するため、大規模に学習すれば答えの一部を「見たことがある」状態になりうる。これが起きると、点数は実力ではなく記憶を測っていることになる。VerifiedがProに置き換えられた背景にも、この懸念があった。

だからこそOpenAIの提言は示唆的だ。彼らは、次世代のベンチマークは「経験豊富なソフトウェア開発者が、最初から人間の監督を組み込んで作るべきであって、リポジトリ履歴からプログラム的に組成すべきではない」と述べている[2]。裏を返せば、量産・自動化された指標ほど、受験勉強化とコンタミネーションに弱いということだ。

ベンチマークが目標になると指標として劣化するグッドハートの法則を示す図解

図5: 指標が目標になると、モデルは指標に最適化される。過剰適合とコンタミネーションが、点数と実力の間に隙間を生む。

8. 実務能力をどう測るか

では、ベンチマークが当てにならないなら、AIの「本当に使える力」はどう測ればいいのか。万能の答えはないが、方向性ははっきりしている。単一の点数を、複数の観点の束に分解することだ。

第一に、自分の仕事に近いタスクで測る。汎用ベンチマークより、自社のコードベース・言語・フレームワークで代表的な課題を10〜20件用意し、実際に解かせて人間がレビューする方が、桁違いに情報量が多い。第二に、一発の正解率ではなく、工程で見る。要件の理解、設計の妥当性、テストの追加、失敗時の自己修正、レビュー指摘への反応——完成物だけでなく、そこに至る過程を評価する。第三に、コストと速度を同時に見る。同じ正解率でも、消費トークンや所要時間、再試行回数が違えば実務価値は大きく変わる。

そして第四に、壊れにくさ(信頼性)を見る。同じ課題を何度か解かせて結果がばらつかないか、少し条件を変えると崩れないか。実務では「たまに天才、たまに事故」より「常に80点」の方が使いやすい。ベンチマークの平均点は、この分散(ばらつき)を覆い隠してしまう。

要するに、実務能力とは「難問を一度解けるか」ではなく、「自分の現場の問題を、妥当なコストで、安定して、検証可能な形で解き続けられるか」だ。これは単一のリーダーボードでは決して表現できない。

実務能力を近さ・工程・コスト・信頼性の4観点で測る枠組みの図解

図6: 実務能力を測る4つの観点。単一スコアを「近さ・工程・コスト・信頼性」に分解すると、現場での使い勝手が見えてくる。

9. それでもベンチマークは無価値ではない

ここまで読むと「ベンチマークは全部インチキ」と結論したくなるかもしれないが、それは行き過ぎだ。今回の件でむしろ確認できたのは、評価コミュニティが自己修正できるという健全さでもある。指標を疑い、監査し、欠陥を公表し、推奨を撤回する——この一連の動きこそ、科学に近い態度だ。

ベンチマークには、粗い足切りとしての価値がある。「80%と40%」のような大きな差は、多少ノイズがあっても意味のある信号だ。新モデルが従来比で明確に跳ねたかどうかを、共通の土俵でざっくり比べる用途では、依然として有用だ。問題なのはベンチマークの存在ではなく、小数点以下の差を実力の序列として神格化する読み方の方にある。

OpenAI自身、SWE-Bench Proを「使うな」とは言っていない。彼らの提言は「スコアをコーディング能力のきれいな尺度として扱うのをやめよ。もし使い続けるなら、公表前に結果を注意深く精査せよ」というものだ[3]。これは指標の否定ではなく、指標の使い方の成熟を求める声である。

10. 数字を読むための実践チェックリスト

最後に、AIのランキングやベンチマーク記事を読むときに、私たちが実際に使える判断の物差しを置いておく。

  • 差の大きさを見る。数ポイント以内の差は「ほぼ同等」と読む。二桁の差になって初めて傾向として扱う。
  • 単一指標を信じない。複数の独立したベンチマークで一貫して上位か。一つの指標だけの1位は割り引く。
  • 飽和を疑う。上位が軒並み高得点(例:88%台)に密集していたら、その指標はもう解像度を失っている。
  • 測定条件を確認する。足場(エージェント構成)、試行回数、制約がそろっているか。条件が違えば点数は比較できない。
  • コンタミネーションを疑う。公開ベンチで異様に高い場合、実力か記憶か区別がつかない。
  • 自分で小さく試す。最終的には、自分の仕事に近い課題を数件解かせるのが、どんなランキングより雄弁だ。

11. まとめ:疑うことは、使わないことではない

2026年7月のSWE-Bench Pro監査が突きつけたのは、「AI業界が信じている数字は、私たちが思うほどきれいではない」という不都合な事実だった。最も実務的とされた指標の3割が壊れ、その指標を推した当のOpenAIが推奨を撤回した。GPT・Claude・Geminiの小さな点差を「実力の序列」と読むことの危うさが、はっきりと可視化されたのだ。

だが本質は悲観論ではない。指標を疑い、監査し、公表し、直していく——この健全な自己修正こそ、AI評価が科学に近づいていく過程である。私たちに求められるのは、数字を捨てることではなく、数字を正しく疑い、正しく使うことだ。差の大きさを見る。複数の指標を束ねる。飽和を疑う。そして最後は、自分の現場で小さく試す。

「その数字は信用できるのか?」——この問いを手放さない限り、ランキングは私たちを支配する神託ではなく、判断を助ける一つの道具であり続ける。AIがどれだけ賢くなっても、何をどう測るかを決めるのは、依然として人間の仕事なのだ。


参考文献 / References

  1. OpenAI Retracts SWE-Bench Pro After Finding 30% of Tasks Broken — AlphaSignal
  2. OpenAI Retracts Recommendation To Use SWE Bench Pro As Coding Eval Over 30% Broken Tasks — OfficeChai
  3. OpenAI wants new benchmarks to replace "broken" SWE-Bench Pro — The Stack
  4. OpenAI Flags Major Flaws in SWE-Bench Pro — StartupHub.ai

参考文献・出典

  1. [1]OpenAIの監査は、SWE-Bench Proの公開731課題(public split)を対象に、(1)自動データ品質パイプライン、(2)リポジトリにアクセスできるCodexベースの調査エージェント、(3)5人の経験豊富なソフトウェアエンジニアによる独立レビュー、という3段構えで実施された。自動パイプラインは200件(27.4%)、人手レビューは249件(34.1%)を「壊れた課題」と判定している。
  2. [2]OpenAIは、次世代ベンチマークは「経験豊富なソフトウェア開発者が、人間の監督を最初から組み込んで構築すべきであり、リポジトリ履歴からプログラム的に組成すべきではない」と提言している。量産・自動化された指標は品質管理が追いつかず、欠陥課題が紛れ込みやすい。
  3. [3]本記事のスコアは2026年前半に各所で報じられた代表値であり、測定条件・エージェント構成・時期によって変動する。特定モデルの優劣を確定するものではなく、指標そのものの信頼性を論じるための参照値として扱ってほしい。

関連記事

2026年5月1日

AIエージェントは「グレーなコード」をどこまで拒否するのか

OpenAI・Google・Anthropicのポリシーと実運用の差を踏まえ、SNS自動化のようなグレー領域でAIエージェントがどこで拒否し、どこで補助してしまうのかを整理します。

テクノロジー続きを読む
2026年3月8日

2026年のコーディングAIは、一本化よりも役割分担で理解した方が正確になる

GPT-5.3-Codex、GPT-5.4、Claude Opus 4.6を単純な最強ランキングではなく、実装・統合・長時間自律作業という役割分担で比較し、2026年の実務でどう使い分けるべきかを整理します。

テクノロジー続きを読む
2025年12月11日

OpenAI「コードレッド」の真相──GeminiとClaudeに追い上げられた巨人の次の一手

OpenAIが「コードレッド」を宣言した背景を、ベンチマーク逆転、エンタープライズ市場シェア、巨額インフラ投資、安全性リスクの4軸で整理し、次の一手をエンジニア視点で読み解きます。

テクノロジー続きを読む
2025年9月21日

APIキーの取り方からWeb実装まで — OpenAI / Claude(Anthropic) / Amazon Bedrockを“手を動かす人”向けにやさしく解説

生成AI APIを実務のWebアプリに安全に組み込むための実践ガイド。キーの取得、認証、最小コード例、料金の考え方、Next.jsでの安全な組み込みパターン、運用のコツまで網羅。

テクノロジー続きを読む
不完全な隔離境界を抜けて外部システムへ進むAIの計算経路
2026年7月22日

AIは反乱したのか|GPT-5.6と長期自律モデルが越えた三つの境界

2026年7月、長時間稼働モデルの監視回避、GPT-5.6 Solの越権行為、Hugging Faceへの実侵入が相次いで公表されました。一次資料をもとに、反乱ではなく目標指向の制約回避として読み解き、壊れても止まる設計を考えます。

テクノロジー続きを読む