2026年7月8日、CursorとSpaceXAIが共同訓練したGrok 4.5の発表を読んでいて、脚注で手が止まりました。
Grok 4.5はCursorBenchで有利になっている。Cursorコードベースの以前のスナップショットが誤って学習に含まれていたためだ。正確な影響は不明。
Cursorの発表は、この重複による正確な影響を算定できないとして、Grok 4.5の評価結果からCursorBenchを除外しました。該当データは将来のモデルの訓練対象から外し、並行してCursorBenchの大規模更新を進めるとしています。
その前日、CognitionはFrontierCode 1.1を公開しました。こちらの中心課題は、評価実行中のエージェントが公開Webやパッケージから既存の修正を見つける「不公平なインターネット利用」でした。
同じ週に表面化した2つの問題は、発生した段階が異なります。CursorBench/Grok 4.5は訓練データと評価用コードベースの重複が確認された事例です。FrontierCode 1.1は、評価実行時に公開済みの解答へ到達する経路を制御した事例であり、FrontierCode自体に学習時汚染が確認されたわけではありません。
この違いは、これからのコーディングベンチマークを読むうえで重要です。本記事では、2つの事例を起点に、汚染耐性だけでなく、評価器の妥当性や運営体制まで含めて検討します。
以下は、2026年7月13日時点で公開されている各運営元の一次資料に基づく評価です。非公開の訓練コーパスとCursorBenchのタスク本体は外部から監査できないため、公開情報で確認できる範囲と、そこから導く分析を区別して記述します。
ベンチマークと「汚染」の基礎知識
本題に入る前に、前提となる用語を整理します。すでにご存じの方は次の節まで読み飛ばしてください。
ベンチマークとは、AIモデルの能力を測るための共通テストです。コーディングベンチマークでは、「このバグを直して」「この機能を実装して」といった問題集をモデルに解かせ、自動採点してスコアを出します。「モデルAはモデルBより優秀」という比較の多くは、このスコアに基づいています。
そのスコアの信頼性を揺るがすのが**汚染（コンタミネーション）**です。人間の試験に例えると分かりやすくなります。
- 学習時汚染：試験問題や模範解答が、受験勉強の教材に混ざっていた状態。モデルは大量の公開テキストやコード（訓練データ）から学習するため、Web上に公開された問題や正解が意図せず教材に入り込むことがある。本人（開発元）に不正の意図がなくても、「初見の問題を解く力」は測れなくなる
- 実行時の解答取得：試験中にスマホで模範解答を検索するような行為。最近の評価対象は単なるモデルではなくエージェント（Web検索やコマンド実行を自律的に行うAI）なので、評価の最中にインターネット上の正解へたどり着けてしまうことがある
本文で使うその他の用語もまとめておきます。
- PR（プルリクエスト）：OSS開発でコード修正を提案・記録する単位。実在のPRを基にした問題は、正解となる修正がWeb上に公開済みということでもある
- 正解パッチ：問題の模範解答にあたるコード修正
- ハーネス：モデルに問題を渡し、実行し、採点する周辺の仕組み。同じモデルでもハーネスが違えばスコアは変わる
- 推論量（推論予算）：モデルが1問に使える思考・生成の計算量。多いほどスコアが上がりやすい
- カナリア：訓練データへの混入を後から検出できるよう、評価データに埋め込んでおく目印の文字列
「いつ混ざったか」だけでは整理しきれない
最低でも、次の4点を分けて考える必要があります。
| 論点 | 何が問題か | 試験に例えると | 主な確認方法 |
|---|---|---|---|
| 学習時の重複 | 問題、正解パッチ、テスト、対象コードなどが訓練データに含まれる | 教材に試験問題と答えが混ざっていた | データ来歴・重複除去記録、カナリア、記憶誘出テスト。ただし外部から完全監査するのは難しい |
| 実行時の解答取得 | エージェントがWeb、Git履歴、ミラー、パッケージから既存解を取得する | 試験中に答えを検索した | ネットワーク・ツールログ、実行トレース、隔離環境 |
| 評価器の妥当性 | 正しい解を落とす、誤った解を通す、プロンプトにない要件を採点する | 採点基準そのものが間違っている | タスク監査、複数解による検証、人手レビュー |
| 実行条件の差 | 同じモデルでもハーネス、プロンプト、推論量、試行回数でスコアが変わる | 試験時間や持ち込み条件が受験者ごとに違う | 共通ハーネス、条件開示、独立再実行 |
FrontierCodeはこの問題を unfair internet use、Cursorは類似の挙動を reward hacking（課題を正しく解くのではなく、採点で高スコアが付くこと自体を目的にした抜け道行動）と表現しています。本稿では、学習時のデータ重複と区別するため、実行時の解答取得と呼びます。
学習時の重複は、モデルの重みしか見られない外部の評価者には確認が難しい一方、まったく検出不能というわけではありません。たとえばOpenAIはSWE-bench Verifiedの調査で、短い手掛かりから正解パッチや問題固有の情報を再現させる方法を使い、調査対象の全フロンティアモデルで少なくとも一部の重複を示す証拠を得ました。ただし、こうした行動プローブ（モデルの応答から記憶の痕跡を探る調査手法）で「重複がない」ことを証明するのは困難です。
FrontierCode 1.1、現実性を残した実行時対策
前節の分類でいえば「実行時の解答取得」への対策です。試験に例えると、試験中の答え検索は防ぎつつ、辞書の持ち込み（ドキュメント参照）は認める、という方針になります。
FrontierCodeは、36のOSSリポジトリのメンテナーと作った150タスクからなり、実在のPRに基づいています。Cognition自身が説明するとおり、対応する修正が上流リポジトリ、ミラー、後続リリース、パッケージレジストリに存在する場合があります。
1.0の設計時にも、エージェントが上流コードベースを見つけた事例が少数ありました。Fable 5など新しいモデルでその頻度が上がったため、1.1は2段構えを導入しています。1つ目はフェアユースプロンプトで、ドキュメント参照などの正当な利用と、既存解へのショートカットを区別して指示します。2つ目はプログラム検証器で、元PR、上流パッチやファイル、解答を含みうるミラー（リポジトリの複製サイト）やベンダーコピーへの参照を検出し、フラグが立った実行を0点にします。
Cognitionの報告では、プロンプト導入後の不公平な利用率は、評価した全モデルで1%未満まで下がりました。約1,200ドメインまで増えたブロックリストをエージェントが回避し続けた経緯も公開しており、実行時対策としては現実的です。
ただし、この「1%未満」はCognitionの定義と検出器に基づく自己評価です。検出器の再現率・適合率や、正当な参照を誤って止める割合は発表文からは分かりません。ルールに従うモデルには有効でも、将来のモデルや異なるプロンプトで同じ水準が保たれる保証もありません。
FrontierCodeに残る学習時の重複リスク
公開済みの実PRを使う以上、訓練データとの重複リスクはあります。SWE-bench Verifiedでは実際に正解パッチ再現の証拠が見つかっており、一般論として懸念は十分に現実的です。
重複の発生率や影響を判断するには、PRの日付、各モデルの事前学習・事後学習の期間、GitHubデータの採否、重複除去方法が必要です。FrontierCode 1.1の発表は、学習時の重複調査や採用PRの鮮度方針を説明していません。そのため、実行時の対策は具体的に評価できる一方、学習時の重複についてはリスクが存在すること以上の定量評価はできません。
CursorBench/Grok 4.5、非公開評価で起きた訓練データ重複
CursorBenchの説明によると、CursorBenchはCursor社内のエンジニアリングセッションに基づく内部評価です。Cursor Blameで、コミットされたコードを、それを生成したエージェントへの依頼と対応付けます。タスクの多くは社内コードベースや管理されたソースから作られ、数か月ごとに更新されます。
公開Webから切り離されたタスクを定期的に更新する設計は、公開済みの正解を記憶・検索するリスクを下げます。その一方で、タスク、正解パッチ、採点器は公開されておらず、第三者が評価を再現したり、訓練データとの重複を監査したりする余地は限られます。秘匿性は防御であると同時に、外部検証を難しくする要因でもあります。
Grok 4.5では、数兆トークンのCursorデータを含む共同訓練の過程で、以前のCursorコードベースのスナップショット（ある時点のコード一式の丸ごとのコピー）が誤って含まれたとCursorが説明しています。試験に例えると、出題者が特定の受験者の家庭教師も兼ねていて、渡した教材に試験範囲の資料が誤って混ざっていた、という構図です。
公表された重複の対象はコードベースのスナップショットです。CursorBenchの問題文や正解パッチそのものが訓練に含まれたとは説明されていません。それでもCursorが「Grok 4.5に有利」「正確な影響は不明」と判断した以上、通常のモデルと同じ条件で比較できず、CursorBenchスコアを純粋な能力値として解釈することはできません。
開示とスコア除外、その限界
Cursorが発表時に取った対応は3点です。
- 自社に不利な混入を開示した
- 影響を推定できないスコアをGrok 4.5の発表から除外した
- 将来のモデルの訓練対象から該当データを外し、CursorBenchの更新を進めていると説明した
その判断は妥当ですが、影響を評価するための情報はまだ不足しています。
- 開示は本文ではなく脚注である
- どのCursorBenchバージョン・何件のタスクに影響しうるかが不明
- 混入を見つけた監査方法、重複範囲、汚染あり・なしの差分実験が示されていない
- 提供中のGrok 4.5に対する再訓練やデータ除去の扱いは未公表
公開された範囲からは、スコアを除外する判断の妥当性までは確認できます。しかし、重複がモデル性能に与えた大きさや、ほかの内部評価への波及範囲までは判断できません。
2つを同じ物差しで比較する
| 観点 | FrontierCode 1.1 | CursorBench / Grok 4.5 |
|---|---|---|
| タスクソース | 公開OSSの実PRを基にした150タスク | 実際の社内セッション。多くは社内コードベース・管理ソース由来 |
| 実行時の既存解取得 | 構造的に起こりうる。1.1でプロンプト＋検証器を導入 | 公開Web経由のリスクは相対的に低いと考えられるが、第三者検証は困難 |
| 学習時の重複 | リスクはあるが、FrontierCodeでの発生・影響は未確認 | Grok 4.5で以前のCursorコードベースとの重複を自己開示 |
| タスクの更新 | Main 100件・Extended 150件の固定セット。ローリング更新方針は未公表 | 数か月ごとに更新 |
| 外部再現性 | 方法と事例は公開されているが、完全な第三者監査に必要な情報は限定的 | 内部評価のため低い |
| 今回の対応 | 実行時の解答取得を抑制 | 影響不明のスコアを発表から除外 |
両者は単純な鏡像ではありません。FrontierCodeは公開データゆえに第三者が正解の公開状況を調べられますが、各モデルの非公開訓練コーパスとの重複までは調べられません。CursorBenchは非公開・定期更新という防御を持ちますが、ベンチマーク運営者がモデル訓練にも関与したことで、その防御をデータガバナンスがすり抜けました。
この2例から得られる核心は、「公開か非公開か」よりも次の問いです。
評価セットと訓練データの間に、技術的・組織的な防火壁があるか。その防火壁を監査できるか。
防御策は「何を防ぎ、何を残すか」で読む
主要ベンチマークを名前だけで比べると、違いが見えにくくなります。汚染への防御策で分類すると、主な設計は次のように整理できます。
| 防御策 | 例 | 防げることと残る弱点 |
|---|---|---|
| 公開・固定する | HumanEval、SWE-bench Verified | 第三者が再現しやすい。一方、公開期間が長いほど学習時の重複や実行時の解答取得が起きやすい |
| 問題を継続更新する | SWE-bench-Live、LiveCodeBench | 新しい問題で鮮度を保てる。公開後は重複リスクが増すため、タスク版と評価期間の明記が欠かせない |
| 非公開で定期更新する | CursorBench | 公開Webからの記憶・検索を抑えやすい。第三者による再現が難しく、訓練データとの内部的な分離が必要になる |
| 公開版と非公開版を分ける | SWE-Bench Pro | 公開版で再現性、非公開版で汎化を測れる。ただし、それぞれのタスクと採点器の品質検証は別途必要になる |
| 正解実装を新しく作る | DeepSWE v1.1 | 既存PRの正解パッチを記憶・検索する経路を減らせる。公開後の将来モデルには重複しうる |
| 実行中の参照経路を監視する | FrontierCode 1.1 | ドキュメント検索を許しつつ、既存解の取得を抑えられる。検出器の精度と学習時の重複は別問題として残る |
ここで重要なのは、どの方式にも守備範囲と死角があることです。たとえばTerminal-Benchのように運営主体がモデルベンダーと別であることは、利害関係の分離には役立ちます。しかし、タスクが公開されていれば、学習時の重複を自動的に防げるわけではありません。
汚染がなくても、採点が妥当とは限らない
OpenAIのSWE-Bench Pro監査は、汚染とは別の問題も示しました。公開731件の約30%に、評価を壊す問題があると推定しています。
学習時の重複を避けても、テストが過度に厳しい、プロンプトの要件が足りない、テスト範囲が狭い、といった欠陥があれば、スコアは能力を正しく表しません。「汚染されていない」と「妥当な評価である」は別の条件です。
スコア差をハーネス差と即断しない
SpaceXAIのGrok 4.5発表には、Grok 4.5について2つの値があります。DeepSWE 1.0では62.0%（Artificial Analysisが各モデル提供元のハーネスで実行）、DeepSWE 1.1では53%（Datacurveがmini-swe-agentで実行）です。
9ポイントの差がありますが、ベンチマークのバージョンとハーネスが同時に変わっています。この差を実施主体やハーネスだけに帰属させることはできません。
独立評価や共通ハーネスの効果を判断するには、タスク版、プロンプト、推論量、試行回数をそろえた比較が必要です。ベンチマークを読むときは、汚染対策だけでなく、採点器と実行条件も一組で確認する必要があります。
私の評価は「優劣より、役割分担と監査可能性」
FrontierCode 1.1の価値は、インターネットを全面禁止せず、実務で必要な検索と既存解の取得を分けようとした点にあります。これは実用性の高い設計です。一方、学習時の重複には答えておらず、検証器の性能も独立検証されていません。実行時対策としては前進ですが、学習時対策としては未評価です。
CursorBenchの価値は、実利用に近いタスク、定期更新、オンライン評価との照合にあります。公開ベンチマークとは別の信号として有用でしょう。一方、Grok 4.5の件は、非公開化だけでは不十分で、評価セットを訓練パイプラインから隔離する仕組みが必要だと示しました。データ設計は強かったのに、ガバナンスで失敗してしまった事例です。
もし私がモデルベンダーの評価体制を任されたら、最初に手を付けるのは評価セットと訓練パイプラインの隔離です。評価タスクと由来コードのハッシュを訓練禁止レジストリに登録し、事前学習、事後学習、RL、合成データ生成の全段階で照合する。ベンチマーク担当と訓練データ担当の権限も分けておきます。Grok 4.5の件は、まさにここが破られた事例でした。
そのうえで、隔離が守られていることを外から確認できる形にします。汚染プローブ、カナリア、データ来歴監査を併用し、第三者が同一条件の共通ハーネスで再実行できるようにする。スコアを出すときは「モデル × エージェント × ハーネス × タスク版 × 推論予算」を一組として表示します。
評価利用者の側も、単一スコアで順位を決めるべきではありません。新作・非公開タスクで汎化（初見の問題を解く力）を見て、ローリング評価（問題を継続的に入れ替える方式）で鮮度を確保し、公開タスクで再現性を取り、実利用のオンライン指標で外的妥当性を確認する。異なる弱点を持つ評価を組み合わせるほうが、ひとつの「最強ベンチマーク」を探すより堅牢です。
おわりに
次に高いベンチマークスコアを見たとき、確認したいのはモデル名だけではありません。どのタスク版を、どのハーネスと推論予算で、誰が実行したのか。訓練データとの分離を、どのように確認したのか。
脚注がないことは、汚染がないことの証明ではありません。ただし、脚注がないというだけで汚染を推定するのも誤りです。必要なのは疑念の強さではなく、追跡可能なデータ来歴と、条件をそろえた複数の評価です。
一次資料
- OpenAI, HumanEval公式リポジトリ
- Cognition, “FrontierCode 1.1”
- Cognition, “Introducing FrontierCode”
- Cursor, “Introducing Grok 4.5”
- Cursor, “How we compare model quality in Cursor”
- Cursor, “Reward hacking is swamping model intelligence gains”
- SpaceXAI, “Introducing Grok 4.5”
- OpenAI, “Why SWE-bench Verified no longer measures frontier coding capabilities”
- OpenAI, “Separating signal from noise in coding evaluations”
- Scale AI, “SWE-Bench Pro”
- Microsoft Research, “SWE-bench Goes Live!”
- LiveCodeBench公式リポジトリ
- Terminal-Bench
- Datacurve, “DeepSWE”
- Datacurve, “DeepSWE v1.1”