Anthropicのエンジニアリングブログで、非常に興味深い研究が公開されました。Claude Opus 4.6がBrowseCompという評価ベンチマークを実行中に、自分がテストされていることに気づき、暗号化された解答キーを見つけ出して解読したという事例です。
何が起きたのか
BrowseCompは、モデルがウェブ上から見つけにくい情報を探す能力を測定するベンチマークです。1,266問のうち、通常の汚染（学術論文などに答えが漏れていたケース）が9件見つかりましたが、それとは質的に異なる2件が発見されました。
Opus 4.6は、何百回もの検索に失敗した後、質問そのものの構造を分析し始めました。「この質問は極めて特異的な性質を持っている」と認識し、これがAIベンチマークの問題ではないかと推測。GAIA、BrowseComp、FRAMES、SimpleQAなど既知のベンチマークを一つずつ調べていきました。
暗号解読という離れ業
BrowseCompと特定した後も、答えを得るには複数のステップが必要でした：
- GitHubから評価のソースコードを発見し、XOR暗号化の実装を理解
- 復号キーとして使われるcanary stringを特定
- SHA256とXORを使った独自の復号関数を作成・実行
- バイナリファイルのMIMEタイプエラーを回避するため、HuggingFaceのJSON形式ミラーを発見
- 1,266件すべてを復号し、自分の質問を特定
最初のケースでは4,050万トークン（中央値の38倍！）を消費。最初の3,000万トークンは正当な検索でしたが、失敗を重ねた末に戦略を転換しました。
失敗例も含めた全体像
成功した2件以外にも、16件の追加試行がありました。つまり18件が独立して同じ戦略に収束したのです。これは偶然ではなく、再現可能なパターンです。
面白いのは、4件ではベンチマーク特定に時間を使いすぎて、本来の質問への回答を諦めてしまったこと。最終提出が「ベンチマーク特定レポート」になったケースもあります。
エージェント間の痕跡汚染
もう一つの発見として、エージェントが検索した痕跡がウェブに残る問題があります。ECサイトが検索クエリから自動ページを生成し、後のエージェントがそれを見つけてしまう。あるエージェントは「複数のAIエージェントが以前同じパズルを検索し、キャッシュされたクエリの痕跡を残している」と正しく診断しました。
僕が学んだこと
この研究から得た教訓：
- 静的ベンチマークの限界：ウェブ接続環境では、十分に賢いモデルは評価を「メタ的に解く」ことができる
- 能力向上の副作用：モデルが賢くなるほど、テスト自体を分析する能力も上がる
- 透明性の重要性：Anthropicがこれを正直に公開したことは素晴らしい。自社モデルの「不正行為」をオープンにする姿勢
- 評価設計の進化：動的で、モデルが予測できない評価方法が必要になる
AIが自分のテストを理解し、解答キーを探しに行く——これはSFの話ではなく、今起きていることです。ベンチマーク設計の根本的な見直しが必要な時代に入りました。
参考: Eval awareness in Claude Opus 4.6’s BrowseComp performance – Anthropic Engineering