AIコーディング評価の3割が欠陥｜OpenAIが撤回

監修者伊東雄歩

株式会社ウォーカー CEO。東北大学卒。MENSA会員、JDLA認定講師、健全AI教育協会理事。生成AI×教育・学習科学を専門とし、2億円超のシステム開発プロジェクトを統括。

OpenAIが2026年7月8日、AIコーディング評価「SWE-Bench Pro」の約30%のタスクが壊れていると発表しました
公開731タスクのうち、自動検査で27.4%、人間のエンジニア5人による検査で34.1%に欠陥が見つかりました
欠陥は「厳しすぎる」「あいまいすぎる」「浅すぎる」「誤解を招く」の4種類に分類されます
OpenAIは2026年2月に自ら推奨したこのベンチマークを、わずか5か月で撤回しました
ベンチマークのスコアだけでAIを選ぶ時代は終わりつつあります。自社の業務での検証が欠かせません

「このAIはコーディング能力80点」——そんな数字を見て、モデルを選んだことはありませんか。実はその点数、テスト問題自体が壊れていたせいで意味をなさないかもしれません。OpenAIが自ら推した評価テストの3割に欠陥が見つかり、推奨を撤回しました。何が起きたのか、私たちは何を信じればいいのかを解説します。

OpenAIが「約30%が壊れている」と発表

2026年7月8日、OpenAIが「Separating signal from noise in coding evaluations（コーディング評価における信号とノイズの分離）」という調査結果を公開しました。

対象はSWE-Bench Pro。AIがどれだけプログラムを書けるかを測る、業界で最も広く使われていたテストのひとつです。

結論はシンプルで、しかも衝撃的でした。公開されている731個の課題のうち、およそ30%が「壊れている」というのです。

壊れているとは、テストの出来が悪すぎて、AIの本当の実力を測れない状態を指します。つまり点数が高くても低くても、その数字を信じる根拠がないということです。

自動検査と人間の検査、どちらも3割前後

OpenAIは2つの方法で調べました。

ひとつはAIの調査エージェント（自動で課題を点検するプログラム）による検査です。これが731タスク中200件、27.4%を欠陥ありと判定しました。

もうひとつは経験豊富なソフトウェアエンジニア5人による目視レビューです。こちらは249件、34.1%に問題を見つけました。

機械と人間、アプローチが違うのに結果はどちらも3割前後。偶然のブレではなく、テスト自体に構造的な欠陥があることを示しています。

壊れたテストの4つのパターン

OpenAIは見つかった欠陥を4種類に分類しました。それぞれ、AIの評価をどう狂わせるのかを見ていきます。

1. 厳しすぎる（Too Strict）

正しく動くコードなのに、不合格にされてしまうパターンです。

元のテストは「特定の1つの変更が正しいか」を確認するために書かれたものでした。「この問題の正解は何でもよい」という汎用的な採点基準ではありません。

だから、書き方が少し違うだけで落とされます。答案は合っているのに、模範解答と字面が違うから0点にする採点者のようなものです。

2. あいまいすぎる（Too Vague）

問題文に書かれていない条件を、隠れたテストが要求してくるパターンです。

OpenAIが挙げた具体例がわかりやすいので紹介します。OpenLibraryという実在プロジェクトの課題で、問題文には「行頭にスペースを1つ入れる」と書かれているのに、採点テストはスペース2つを要求していたのです。

指示どおりに書いたAIが不合格になります。これでは能力ではなく、運を測っていることになります。

3. 浅すぎる（Too Shallow）

逆に、点検の範囲が狭すぎて不完全な修正でも合格してしまうパターンです。

本当は10か所直すべきなのに、1か所だけ直せば通ってしまう。実務なら確実にバグが残るのに、テスト上は満点になります。スコアが実力より高く出る方向の欠陥です。

4. 誤解を招く（Misleading）

問題文がAIを間違った方向へ誘導するパターンです。

「この関数に問題がある」と書かれているのに、実際の原因はまったく別の場所にある。真面目に指示に従うAIほど、間違った場所を掘り続けて時間切れになります。

なぜこんなことが起きたのか

根本の原因は、課題の出どころにあります。

SWE-Bench Proの問題は、GitHubに実在するオープンソースプロジェクトのIssue（不具合報告や要望）から作られています。

しかしIssueは、もともと人間同士が相談するための場です。「詳しくは口頭で」「いつものアレで」といった暗黙の前提が省略されるのが当たり前。AIを公平に採点するための試験問題として書かれてはいないのです。

OpenAIはこう述べています。「それらのプロジェクトのテストは厳しすぎる傾向がある。特定の1つの変更を検証するために作られたもので、汎用的な要件として機能するようには作られていないからだ」

わずか5か月での方針転換

今回の発表がとりわけ重い理由は、OpenAI自身がこのベンチマークを推していたことにあります。

時系列を整理します。

2026年2月：OpenAIが従来の「SWE-bench Verified」の利用をやめると表明。同時に、より難しい後継として Scale AI が作った「SWE-Bench Pro」への移行を研究コミュニティに推奨
2026年7月8日：その SWE-Bench Pro について「約30%が壊れている」と発表し、推奨を正式に撤回

5か月で前言撤回。OpenAIが主要なコーディング評価を見限るのは、これで5か月間に2度目です。

前任者「SWE-bench Verified」も限界だった

そもそも、なぜ乗り換えが必要だったのでしょうか。

旧ベンチマークの SWE-bench Verified には、2つの深刻な問題がありました。

ひとつは汚染（コンタミネーション）です。問題と正解がGitHub上に公開されているため、AIの学習データにそのまま混ざってしまう。試験前に答案を見た受験生を採点するようなもので、実力を測れません。

もうひとつは飽和です。上位モデルが軒並み80%前後に固まり、各社のモデルが小数点以下の差でひしめく状態になりました。差がつかない物差しは、物差しとして機能しません。

OpenAIはその解決策として SWE-Bench Pro を推しました。ところが、その代替もまた壊れていた——というのが今回の話です。

主要ベンチマークの比較

コーディング評価によく使われる指標を整理します。それぞれ得意・不得意があり、1つに頼るのは危険です。

SWE-bench Verified：実在のPython Issueを解かせる定番。汚染と飽和で、OpenAIは2026年2月に利用を停止
SWE-Bench Pro：Scale AI製の後継。より長く現実的な作業を課す設計だったが、公開731タスクの約30%に欠陥が判明
ライブ型ベンチマーク：締切後に公開された新しい問題だけを使う方式。学習データへの混入を避けやすい
社内評価（自社ベンチ）：自社のコードベースと業務タスクで測る。手間はかかるが、実務との一致度は最も高い

ちなみに、SWE-Bench Pro は言語の偏りも指摘されています。課題の多くがPython中心で、Java・Go・TypeScriptといった主要言語のカバーが薄い。日本企業で多いJava案件の実力は、そもそも測れていない可能性があります。

日本の企業・開発者への影響

「アメリカの研究者の話でしょう」と思うかもしれません。しかし影響は、日本の現場に直接届きます。

モデル選定の根拠が揺らぐ

ある製造業のIT部門を想像してください。担当者が稟議書に「SWE-Bench Proで最高スコアのモデルを採用します」と書き、年間数千万円のAI開発ツール導入を決裁したとします。

その根拠が、今回のニュースで揺らぎました。上司から「その点数、壊れたテストの結果じゃないの？」と聞かれたとき、答えられるでしょうか。

スコアの順位が実務の使いやすさの順位と一致する保証は、もうありません。

ベンダーの「業界最高性能」を鵜呑みにできない

SIerやツールベンダーの提案書には、必ずと言っていいほどベンチマークのグラフが載っています。

これからは「そのスコアはどのベンチマークですか」「タスクの欠陥率は検証しましたか」と聞き返す姿勢が必要です。数字を出す側ではなく、数字を読む側のリテラシーが問われます。

結局、自社での実測が最強になる

都内のWeb制作会社が、AIコーディングツールを比較検討する場面を考えてみましょう。

ベンチマークの表を見比べる代わりに、自社の過去のバグ修正タスクを20件選び、各モデルに実際に解かせる。修正の正確さ、レビュー工数、手戻りの回数を記録する。1週間ほどの手間はかかりますが、得られる数字は自社の現実そのものです。

公開ベンチマークが信用を失った今、この地道な実測こそが最も確実な判断材料になります。

では、良いベンチマークとは何か

OpenAIは今回、特定の代替ベンチマークを「これを使え」と指名しませんでした。代わりに、業界全体で新しい評価基準を作ろうと呼びかけています。

掲げられた条件は主に3つです。

経験豊富な開発者の手で作られていること：現場を知る人が、採点基準まで含めて設計する
ゲームしにくい（hard to game）こと：問題を丸暗記したり、テストの穴を突いたりして点を稼げない
信頼でき、実際の能力を反映していること：スコアの高さが、実務での使いやすさに素直につながる

言い換えれば、これまでのベンチマークは「拾ってきた問題」で作られていました。これからは「測るために設計された問題」が必要だ、というのがOpenAIの主張です。

冷ややかな見方もある

一方で、この発表を全面的に歓迎する声ばかりではありません。

X（旧Twitter）では、タイミングを疑う声も上がりました。自社モデルの成績が振るわないベンチマークを、都合よく「壊れている」と言っているだけではないか、という見方です。

評価基準を作る側が最有力プレイヤーでもあるという構造には、確かに難しさがあります。とはいえ、指摘された欠陥の中身（スペース1つと2つの矛盾など）は具体的で、反論しにくいものが多いのも事実です。

よくある質問（FAQ）

Q1. SWE-Bench Proとは何ですか？

AIがどれだけプログラムを書けるか、直せるかを測るテストです。Scale AIという企業が作りました。GitHubの実在プロジェクトから課題を集め、AIにバグ修正や機能追加をさせて合否を判定します。従来のSWE-bench Verifiedより難しく、現実的な作業を課す設計でした。

Q2. 「タスクが壊れている」とは具体的にどういう意味ですか？

テスト問題として成立していない状態です。たとえば問題文が「スペース1つ」と指示しているのに、採点側が「スペース2つ」を求めている。正しく答えたAIが不合格になり、点数がAIの実力を反映しません。OpenAIはこうした欠陥を「厳しすぎる」「あいまい」「浅い」「誤解を招く」の4つに分類しました。

Q3. これまで発表されたモデルのスコアは、すべて無意味になったのですか？

すべてが無意味というわけではありません。ただし順位の細かい差は信頼できません。壊れたタスクが3割あると、スコア差が数ポイント程度のモデル同士では、実力差なのかテストの欠陥なのか区別がつかないためです。大まかな傾向として参考にする程度が安全です。

Q4. これからAIモデルを選ぶとき、何を見ればいいですか？

3つをおすすめします。第一に、公開ベンチマークは1つだけでなく複数を見比べること。第二に、締切後の新問題を使うライブ型の評価を重視すること。第三に、最も大事なこととして、自社の実際のタスクで小さく試すことです。5〜10件の実務タスクを解かせるだけでも、ベンチマークの表より多くのことがわかります。