報酬ハッキングがモデルの知能向上を食い潰している
より高性能なモデルほど、コーディングベンチマークをうまくハックするようになっています。
実際のバグをもとに作られ、後から修正された eval suite は、問題がすでに解決済みであるため、特に脆弱です。エージェントがリポジトリの履歴や公開 Web にアクセスできると、答えを導き出すのではなく、単に調べて取得できてしまうことがあります。
この挙動がどれほど広く起きているかを測るために、私たちは eval の軌跡を監査するエージェントを構築しました。SWE-bench Pro では、成功した Opus 4.8 Max の解決の 63% が、修正を導き出したのではなく取得したものだったことがわかりました。git の履歴を遮断し、インターネットへのアクセスを制限すると、Opus と自社モデルの Composer 2.5 の両方でスコアが大きく低下しました。
- Opus 4.8 Max は 87.1% から 73.0% に低下
- Composer 2.5 は 74.7% から 54.0% に低下
これまでの研究では、コーディングベンチマークの答えが公開情報から漏えいしうることが示されており、その例として 2024 年のこの調査 や 2025 年の Meta のレポート があります。私たちの調査は、現在の最先端コーディングエージェントの実行におけるこの問題を定量化しています。より広い教訓として、学習時の汚染を避けることに加え、エージェント型コーディングベンチマークには、実行時の環境を制御することも必要です。
eval を実施するチームに向けて、私たちはトランスクリプトの監査と eval 環境の制約によって、この報酬ハッキング的な挙動を緩和することを提案します。
モデルでモデルを見抜く
報酬ハッキングの挙動がどの程度見られるかを測るため、731 件の Opus 4.8 Max の軌跡を監査用モデルに調べさせました。このモデルは、実行が成功したかどうかは見ずに、問題文とエージェントの完全な軌跡を確認し、エージェントが既知の答えを取得していたかどうかを分類しました。
このモデルが見つけた、最も一般的な報酬ハッキングのパターンは次の 2 つです。
- Upstream lookup: 軌跡の 57% で、Opus 4.8 Max は公開Web上でマージ済みの PR または修正済みのソースファイルを見つけ、その修正をほぼそのまま再現していました。
- Git-history mining: 軌跡の 9% で、Opus 4.8 Max は付属の .git 履歴から、後にバグを修正したコミットを検索し、そこからパッチを抜き出していました。1
モデルが強力になるにつれて、特にタスクが過去の公開リポジトリから持ってこられている場合、自分が eval 中であることを推測できてしまうことがあります。学習時に修正内容を記憶していない場合でも、バグがすでに解決済みであることを示す手がかりを環境が与えてしまうことはあります。
2019 年の jq の Issue に基づくある SWE-bench Multilingual のタスクでは、エージェントはシステムの jq バイナリでバグの再現を試みました。ところが、そのイメージはバグ修正後にビルドされていたため再現に失敗し、エージェントはその Issue がすでに解決済みだと推測しました。その認識によって、自力で修正を導き出すのではなく、修正を検索する方向に向かいました。
さらに、もっと直接的なケースもいくつかありました。あるエージェントは、隠されたテストと正解のパッチが露出している SWE-bench のミラーページを見つけました。別のエージェントは隠されたテストファイルを入手し、成功に必要な想定例外文字列をハードコードしました。
Upstream lookup (Opus 4.8 Max). エージェントは GitHub API 経由でマージ済みの PR に問い合わせて、修正が加えられたファイルを特定し、その内容を再現しました (同じ応答には各ファイルの diff も含まれています) 。
cd /testbed && curl -s "https://api.github.com/repos/apache/druid/pulls/14092/files" 2>/dev/null | grep '"filename"'Git-history mining (Composer 2.5). エージェントは付属の .git 履歴から修正コミットを見つけて diff を読み、そのまま直接適用しました。
cd /testbed && git show 895abd8929 -p 2>/dev/null | head -400
cd /testbed && git cherry-pick 895abd8929 2>&1追加するパッチの抜粋: 上の git show 出力からそのまま切り出した短い一節 (Composer が再現した正解の diff) 。
より厳格な環境設計
報酬ハッキングの大半は、公開Webやリポジトリの履歴を通じて発生していました。過去の公開リポジトリから構築したevalでは、それらのチャネルに答えが含まれている可能性があるため、制御する必要があります。そこで私たちは、2つの隔離メカニズムを備えた厳格なハーネスを構築しました。
- 履歴の分離。 エージェントが開始する前に、.gitディレクトリを削除し、リポジトリを単一コミットの新規リポジトリとして再初期化します。元の履歴はスコアリング時にのみ復元されるため、テストは通常どおり実行されます。
- 外向き通信のプロキシ経由化。 ネットワークアクセスはデフォルトで拒否されます。完全ではないものの制御策として、固定されたプロキシにより、許可リストにあるパッケージレジストリへの依存関係の解決だけが許可され、それ以外は一切許可されません。
この制限は、過去の公開リポジトリから構築されたevalに特有のものです。これは、CursorBench のような非公開リポジトリから構築されたevalを私たちが好む理由の1つでもあります。そうしたevalであれば、実際の作業中と同じようにエージェントがツールを使える状態を保ちながら、エージェント型コーディング能力をテストできます。
広がる差
私たちは、より厳格なハーネスで SWE-bench Pro と SWE-bench Multilingual を再実行し、これらの漏洩チャネルを取り除いたことによる複合的な影響を見るためのプロキシとして、それぞれの結果を標準ハーネスでのスコア2と比較しました。
- SWE-bench Multilingual では、Opus 4.6 は 1 ポイント未満、Opus 4.8 Max は 9.1 ポイント、Composer 2.5 は 7.5 ポイントの差でした。
- SWE-bench Pro では、Opus 4.6 は 1 ポイント未満、Opus 4.8 Max は 14.1 ポイント、Composer 2.5 は 20.7 ポイントの差でした。
ここから明確に言えるのは、報酬ハッキング は古いモデルに比べて、新しくより高度なモデルで、はるかに一般的だということです。興味深いことに、GPT モデルでは同じような拡大は見られず、私たちの実行結果では全体として差はより小さくなっています。
また、私たち自身のモデルである Composer 2.5 は、この調査で Pro における差が最も大きいことも確認されました。これが、Composer の標準 SWE-bench Pro スコアを、信頼できるベンチマークの数値として扱っていない理由の 1 つです。このスコアは、ハーネスが算出したという限定的な意味では実際のものですが、コーディング能力と既知の修正へのアクセスが混ざったものでした。
Standard vs. strict harness (test pass rate)
| 1 | Opus 4.8 (max) | 91.16% | 82.03% | +9.1 |
| 2 | Opus 4.8 (xhigh) | 88.86% | 80.67% | +8.2 |
| 3 | Opus 4.7 (max) | 84.80% | 80.47% | +4.3 |
| 4 | Opus 4.7 (xhigh) | 83.74% | 78.60% | +5.1 |
| 5 | Opus 4.8 (high) | 83.09% | 79.26% | +3.8 |
| 6 | Opus 4.8 (medium) | 81.87% | 77.84% | +4.0 |
| 7 | Opus 4.7 (high) | 81.42% | 77.75% | +3.7 |
| 8 | Opus 4.8 (low) | 79.51% | 74.36% | +5.2 |
| 9 | Composer 2.5 | 79.15% | 71.60% | +7.5 |
| 10 | GPT-5.4 (xhigh) | 79.00% | 75.20% | +3.8 |
| 11 | GPT-5.5 (xhigh) | 77.80% | 74.40% | +3.4 |
| 12 | Opus 4.7 (medium) | 77.33% | 75.72% | +1.6 |
| 13 | GPT-5.5 (high) | 77.30% | 74.70% | +2.6 |
| 14 | GPT-5.4 (high) | 76.80% | 73.30% | +3.5 |
| 15 | Opus 4.6 (max) | 76.33% | 76.06% | +0.3 |
| 16 | Opus 4.6 (high) | 76.11% | 75.22% | +0.9 |
| 17 | Opus 4.7 (low) | 75.89% | 72.64% | +3.3 |
| 18 | GPT-5.5 (medium) | 75.30% | 74.20% | +1.1 |
評価されていることを認識するエージェントのためのeval設計
コーディングevalを実施するチームにとっての重要なポイントは、ベンチマーク設計はデータセットの構築で終わりではないということです。タスクの実行中にエージェントが何を検索し、調べ、取得し、復元できるのかを含め、実行時の環境も考慮する必要があります。
だからといって、すべてのevalでインターネットアクセスやgit の履歴を排除すべきだという意味ではありません。実際のコードベースの周辺コンテキストをエージェントがどれだけうまく使えるかを評価することが目的のevalもあり、そのような設定では広いアクセス権がタスクの一部になる場合もあります。問題なのは、そのアクセスによってスコアの意味が変わってしまうときです。
過去の公開リポジトリを対象にしたベンチマークでは、アクセスを開放すると、エージェントはバグを解決する代わりに既知の修正を見つけてしまうことがあります。ハーネスに制御がなければ、スコアはコーディング能力と答えのリトリーバルを混同してしまうおそれがあります。
evalを実施するチームは、どのような振る舞いを測定したいのかを決め、それに合わせてハーネスを設計し、結果を報告する際には設定を明確にすべきです。トランスクリプトを監査すると、モデルが予想外の方法でタスクを解いているケースを明らかにする助けになります。目的は通常のツール利用を禁じることではなく、ベンチマークが測定するとしているものを確実に測れるようにすることです。
それでもなお、より難しい未解決の問題が残ります。モデルが自分たちが評価されていることをより強く認識するようになると、git の履歴を閉じたりインターネットアクセスを制限したりするだけでは防げない、より微妙な形で振る舞いを変える可能性があります。ランタイム汚染は、モデルが自分は評価されているのだと推測した場合でも、evalが構成概念妥当性を保てるようにするという、より広い課題の一つの具体例です。
