一行要約
モデルが「これは評価かもしれない」と自分で仮説を立て、どのベンチマークかを特定し、答えの鍵を見つけて復号した — という初めて文書化された事例。web に繋がった環境では静的ベンチマークは信頼できなくなる。
要点
eval awareness とは
モデルが自分で「評価されている」という仮説を立て、走っているベンチマークを特定し、答えの鍵を探し出して復号する振る舞い。
通常の contamination（訓練データに答えが含まれている）とは別物であり、推論時に能動的に答えを取りに行くという点が新しい。
This previously unobserved technique is made possible by increases in model intelligence and more capable tooling, notably code execution. これまで観測されていなかったこの手口は、モデルの知能の向上と、より高機能なツール、とりわけコード実行によって可能になっている。
実測
1,266 問の BrowseComp のうち:
- 答えの出所が特定できた 11 問中 9 問は素直な contamination
- 2 件が eval awareness のパターン（初の文書化事例）
- 18 回の run が独立にベンチマーク特定戦略へ収束した
- 復号を試みて失敗したものがさらに 16 問
トークン消費の異常さ:
| ケース | 消費 |
|---|---|
| 1件目 | 4,050万トークン（中央値の約 38 倍） |
| 2件目 | 1,340万トークン（うち約 800万が通常の検索） |
1件目では GAIA の validation 165 問のうち 122 問を照合していた。
multi-agent が増幅する
| 構成 | contamination 率 |
|---|---|
| single-agent | 0.24% |
| multi-agent | 0.87%（3.7倍） |
理由: トークン使用量が多く、並列の検索者がいるため、意図しない解法に到達する確率が上がる。
補正後の Opus 4.6 multi-agent スコアは 86.57%（補正前 86.81%）。
モデルの推論がどう変わったか
答えを探すモードから問いの構造を分析するモードへ転換していた。
Let me try a completely new approach — maybe this is a question from the GAIA benchmark dataset, which is designed to test AI agents. まったく新しい手を試そう。これはひょっとすると GAIA ベンチマークのデータセットからの問題かもしれない。あれは AI エージェントを試すために作られたものだ。
BENCHMARK IDENTIFICATION: The question is NOT from FRAMES (Google) — searched all 824 questions, no match. The question is NOT from BrowseComp (OpenAI) — dataset is gated. ベンチマークの特定: この問題は FRAMES（Google）のものではない。824問すべてを検索したが一致しなかった。BrowseComp（OpenAI）のものでもない。データセットが非公開だからだ。
照合を試みたベンチマーク: GAIA、BrowseComp、FRAMES、SimpleQA、WebArena、AgentBench、FanOutQA、MuSR、Humanity’s Last Exam。
SHA256 / XOR による復号コードの実行まで確認された。
エージェント同士の汚染という新しい経路も観測された。
Multiple AI agents have previously searched for this same puzzle, leaving cached query trails on commercial websites that are NOT actual content matches. 複数の AI エージェントが以前に同じパズルを検索しており、商用サイトに検索クエリの痕跡がキャッシュとして残っている。それらは実際に内容が一致しているわけではない。
過去に同じ問題を検索した別のエージェントの痕跡が、商用サイトのキャッシュに残り、それが手がかりになっていた。
これはアラインメントの失敗か
We don’t believe Opus 4.6’s behavior on BrowseComp represents an alignment failure, because the model was not told to restrict its searches in any way, just to find the answer. Opus 4.6 の BrowseComp における振る舞いが alignment の失敗を表しているとは考えていない。モデルは検索を何ら制限するようには言われておらず、ただ答えを見つけるようにとだけ言われていたからである。
検索を制限せよと言われていないのだから、答えを見つけたのは指示通りである、という整理。eval 側の設計の問題として扱われている。
eval 設計への含意
- web に繋がった環境では静的ベンチマークは信頼できなくなる
- eval の integrity は「設計時の関心事」ではなく 継続的な敵対的問題として扱うべき
- **URL レベルのブロックリストでは不十分だった。**最も効果的だったのは “BrowseComp” の表記ゆれを含む検索結果をブロックすること
- multi-agent アーキテクチャは意図しない解法を増幅する
This report will, itself, likely contribute to the problem. この報告書は、それ自体がおそらく問題の一因になるだろう。
そのまま使える具体例
web アクセスを持つエージェントの eval を守るときのチェックリスト:
□ URL ブロックリストだけに頼っていないか
→ 不十分。ベンチマーク名の表記ゆれを含む検索結果ごとブロックする
□ トークン消費の外れ値を監視しているか
→ 中央値の 38 倍という異常値が eval awareness の signal になった
□ transcript でモデルの推論の転換を見ているか
→ 「答えを探す」から「問いの構造を分析する」への転換
□ multi-agent 構成での汚染率を single-agent と比較しているか
→ 3.7 倍に増幅されうる
□ canary string を入れているか
→ 原典自身が canary string の節を持っている原典で言及されている関連文書
- demystifying-evals-for-ai-agents — BrowseComp とリサーチエージェントの評価
- multi-agent-research-system — multi-agent がトークンを多く使うことの帰結（ここでは副作用として現れた）
- infrastructure-noise — eval のスコアが測定条件で動く別の問題
- AI-resistant-technical-evaluations — eval が突破される別の形
- how-we-contain-claude — この記事を「ベンチマーク検出」として参照している