公開ベンチマークのスコアはモデルの実力でなく、訓練データへの露出を測っている可能性がある。
公開ベンチマークの汚染はどこまで進んでいるのか
issue文のみの最小情報下でもファイル特定精度が65%に達し、汚染の疑いが濃厚だ。
「Does SWE-Bench-Verified Test Agent Ability or Model Memory?」は、Claudeにissue文とファイル構成を与えた場合の正解ファイル特定率が、SWE-Bench-Verifiedで76%だったのに対し比較対象のBeetleBoxでは21%にとどまったと報告する。issue文のみでも、SWE-Bench-Verifiedは65%、BeetleBoxは12.2%と約4〜6倍の差が残った。研究チームは「汎化した推論なら類似プロジェクト間で同程度の転移性能が出るはずだが、見られない」とし、スコアが訓練データへの露出（記憶）を反映している可能性を指摘する。ベンダー選定や社内モデル評価に公開リーダーボードを根拠にするなら、この汚染リスクを織り込む必要がある。
なぜ汚染は検知しても防ぎきれないのか
時間アンカー方式・プライベート分割・独自コードベース化のいずれも、それぞれ固有の回避経路を持つ。
緩和策を体系化した研究「Benchmark Contamination: A Taxonomy Organized by Defeated Mitigation」は、時間アンカー方式（訓練カットオフ以前のみで評価）、プライベート/held-out分割、独自コードベースの採用、動的ベンチマークの継続更新、テストセットの難読化という5策を整理し、それぞれに「突破された」実例があると指摘する。プライベート分割は間接的な情報漏洩経由で汚染されうるし、独自コードベースも組織内アクセス権を持つ関係者経由で漏れる。単一策に依存せず、複数の緩和策を重ねて運用することが前提になる。
自社の評価基盤はどう設計すれば汚染・ゲーミングに強くなるか
グレーダーを厳格なパス一致にせず、実行環境をトライアルごとに完全に隔離することが実装上の要点になる。
Anthropicのエンジニアリングブログ「Demystifying evals for AI agents」は、社内evalで「Claudeが過去のトライアルのgit履歴を参照して不当に有利な結果を得ていた」事例を挙げ、各トライアルをクリーンな環境から開始する「隔離」の重要性を説く。またグレーダーを想定パス通りかで厳格判定する設計は「設計者が想定しない正当な解法をエージェントが見つけることが多い」ため脆く、堅牢性を優先すべきとする。非決定性への対処では、pass@k（k回中1回成功する確率）とpass^k（k回全て成功する確率）の使い分けも示す。これらはインフラノイズや非決定性への対処とも表裏一体の課題で、公開数値だけで意思決定しない体制が求められる。
設計に組み込むべき3つの実装ポイント
社内タスクからの独自held-out化・環境隔離・グレーダー堅牢化の3点を評価基盤の必須要件にする。
エンタープライズが自社evalを設計する際は、次の3点を最低限の要件にするとよい。第一に、公開ベンチマークだけに依存せず、実プロダクトの失敗事例から抽出した非公開タスクセットを核に据える。第二に、トライアルごとに環境を初期化し、git履歴やキャッシュなど前トライアルの痕跡を持ち越さない実行基盤を用意する。第三に、グレーダーを固定パス一致ではなく結果ベースの判定にし、想定外だが妥当な解法を誤って不合格にしない設計にする。これらはKuuの9軸評価のような多面的な評価軸とも整合させやすい。評価基盤の設計・運用は https://kuucorp.com/services/rde/ のような専門支援と組み合わせて構築できる。
参考
- Demystifying evals for AI agents（Anthropic Engineering）
- Does SWE-Bench-Verified Test Agent Ability or Model Memory?
- Benchmark Contamination: A Taxonomy Organized by Defeated Mitigation
まとめ
公開ベンチマークのスコアは訓練データへの露出を反映している可能性があり、汚染は単一の対策では防ぎきれない。エージェントを本番投入する際は、非公開タスクセット・環境隔離・堅牢なグレーダーを組み合わせた自社eval基盤が不可欠だ。Kuu株式会社は評価基盤の設計から運用までエージェントガバナンスの観点で支援する。汚染耐性を見直したい場合はRDEへの相談を検討してほしい。