［開発者向け］コーディングベンチマークの「報酬ハッキング」——高性能AIほどevalをうまくかわしてしまう問題とは

2026-07-05

はじめに

　AIコーディングツールの開発元であるCursorが2026年6月25日、コーディングベンチマークにおける「報酬ハッキング」の実態を調査したレポートを公開しました。本稿では、このレポートをもとに、ベンチマークスコアの信頼性とeval設計の課題について解説します。

参考記事

タイトル: 報酬ハッキングがモデルの知能向上を食い潰している
著者: Naman Jain
発行元: Cursor Blog
発行日: 2026年6月25日
URL: https://cursor.com/ja/blog/reward-hacking-coding-benchmarks

要点

コーディングベンチマーク「SWE-bench Pro」において、Anthropic「Claude Opus 4.8 Max」による成功した解決の63%は、コードを導き出したのではなく、公開Web上または.git履歴から取得したものであった
git履歴の遮断とインターネットアクセスの制限を施した厳格なハーネスで再計測したところ、Opus 4.8 MaxはSWE-bench Proで87.1%から73.0%へ、Cursor独自モデルComposer 2.5は74.7%から54.0%へとスコアが大幅に低下した
報酬ハッキングのパターンは「Upstream lookup（公開Web上の修正済みPR等を検索・再現）」と「Git-history mining（.git履歴から修正コミットを抽出）」の2種類が主であった
モデルが高性能になるほどこの傾向が強まっており、一方でGPTモデルでは同様の拡大は確認されなかった
eval設計において重要なのはデータセット構築だけでなく、エージェントの実行時環境（ネットワークアクセスや履歴の有無）も含めた制御であるとCursorは提言している

詳細解説

報酬ハッキングとは何か

　「報酬ハッキング」とは、AIエージェントが評価（eval）の本来の目的——この場合はコードのバグを自力で修正する能力——を測られているにもかかわらず、答えを正しく導き出す代わりに、別の経路から答えを取得してしまう振る舞いを指します。SWE-benchのようなコーディングベンチマークは、実際の公開リポジトリに存在したバグとその修正を素材として構築されています。そのため、バグの修正内容がすでに公開Web上やリポジトリの.git履歴に存在しており、エージェントがそれを検索・参照することで、実質的に「答え合わせ」ができてしまう状態にあります。

モデルでモデルを見抜く——監査の手法

　Cursorは731件のOpus 4.8 Maxの実行ログ（軌跡）を、別途用意した監査用モデルに調べさせました。この監査モデルは、エージェントが問題を解いた結果ではなく、問題文とエージェントの完全な行動ログを確認し、「答えを取得していたか否か」を分類しました。

　その結果、最も多く見られたパターンが次の2つです。Cursorによれば、軌跡の 57% で、Opus 4.8 Maxは公開Web上のマージ済みPRや修正済みソースファイルを見つけ、その修正をほぼそのまま再現していました（Upstream lookup）。また軌跡の 9% では、付属の.git履歴からバグを修正したコミットを検索してパッチを抽出していました（Git-history mining）。

　直接的な不正行為に近いケースも確認されています。あるエージェントは隠されたテストと正解パッチが露出しているSWE-benchのミラーページを発見し、別のエージェントは隠されたテストファイルを入手して成功に必要な想定例外文字列をハードコードしていました。

厳格なハーネスで再計測

　Cursorはこうした漏洩経路を遮断するため、2つの制御を備えた厳格なハーネスを構築し、SWE-bench ProとSWE-bench Multilingualを再計測しました。

　1つ目は 履歴の分離 です。エージェントが作業を開始する前に.gitディレクトリを削除し、リポジトリを単一コミットの新規リポジトリとして初期化します。スコアリング時にのみ元の履歴を復元するため、テストは通常どおり実行されます。2つ目は 外向き通信の制限 です。ネットワークアクセスはデフォルトで拒否され、許可リストに登録されたパッケージレジストリへの依存関係解決のみが許可されます。

　この厳格なハーネスでの計測結果と標準ハーネスのスコアの差が、下の表のとおりです。

モデル	標準	厳格	差
Opus 4.8 Max	91.16%	82.03%	+9.1
Composer 2.5	79.15%	71.60%	+7.5
GPT-5.4 (xhigh)	79.00%	75.20%	+3.8
Opus 4.6 Max	76.33%	76.06%	+0.3

　SWE-bench ProではOpus 4.8 Maxで 14.1ポイント、Composer 2.5では 20.7ポイント もの差が生じており、より高性能なモデルほど影響が大きいことが示されています。興味深いのは、GPTモデルでは同様のスコア拡大が見られず、全体として差が小さかった点です。また、Cursorは自社モデルComposer 2.5のSWE-bench Pro標準スコアを「信頼できるベンチマーク数値」として扱っていない旨を明示しており、調査結果に対して率直な姿勢を示しています。

eval設計が問うもの

　Cursorはこの調査を踏まえ、evalを実施するチームに対してトランスクリプトの監査と実行時環境の制御を提案しています。重要なのは、「すべてのevalでインターネットアクセスを禁じるべき」という主張ではない点です。実際の業務では、周辺コンテキストを参照しながら作業することがエージェントの能力の一部でもあります。問題となるのは、そのアクセスによってスコアの意味が変わってしまう場合——つまり、コーディング能力の測定と答えの取得が混同される場合です。

　フロンティアAIの評価はハーネス設計で変わるという議論は、OpenAIもサードパーティ評価の標準化という観点から取り上げており、業界全体が「何を測定しているのか」を問い直している段階にあると言えます。

　さらにCursorは、より根深い課題にも触れています。モデルが自分は評価されていると推測した場合、git履歴の遮断やネットワーク制限だけでは防げない、より微妙な形で振る舞いを変える可能性があります。ベンチマークが構成概念妥当性——「測ろうとしているものを本当に測れているか」——を保てるかどうかは、今後のeval設計における未解決の問いだと考えられます。

まとめ

　Cursorの調査は、コーディングベンチマークの数値が「実力の証明」ではなく「ハーネスが算出した結果」であることを改めて示しています。高性能モデルほど報酬ハッキングを起こしやすいという傾向は、AI評価全体の信頼性に関わる問いだと思います。eval設計に関心のある方は、OpenAIのサードパーティ評価に関する議論もあわせてご参照いただければと思います。