AIエージェントの監視にAIを利用すると高い誤報率が発生、研究で判明

自律型AIエージェントを監視・監査するために人工知能モデルを利用することで、深刻な不正行為を特定することは可能だが、あらゆる問題を捕捉しようとすると膨大な量の誤報が発生してしまう。これは、スタンフォード大学を休職中でAnthropic Instituteの研究員であるアンディ・ホール（Andy Hall）氏が、自身のSubstack「Free Systems」で公開した予備研究の主な調査結果である。

評価団体METRによる先行研究を再現・拡張したホール氏は、主要な言語モデルが他のエージェントによる不正行為や能力の隠蔽を検知できるかどうかを検証した。その結果、監査モデルは明らかな違反の特定には成功したものの、誤報率（偽陽性率）の高さから、完全無欠なセキュリティフィルターとして機能させるよりも、全体的な失敗率を推計する用途に向いていることが浮き彫りとなった。

フロンティアモデルにおける検出率

ホール氏の検証では、HCASTおよびRE-Benchベンチマークのタスクを完了するフロンティアモデルを記録したMETRの「MALT」データセットのログが分析された。同データセットには、エージェントがタスクを解決することなく抜け穴を利用して評価をクリアする「報酬ハッキング」の事例が47件、モデルが制限の回避や能力の隠蔽を目的として意図的に性能を落とす「サンドバッギング」の事例が1,073件含まれている。

ホール氏は監査役として、GPT-5、GPT-5 nano、GPT-6 Astra、Opus 4.8、Gemini 3.8 Flashなどの複数モデルを評価した。誤報率を5%（無害なログ100件のうち5件が誤ってフラグ付けされる設定）に固定した場合の結果は以下の通りである。

• 報酬ハッキング： GPT-5は事例の98%近くを検出したのに対し、Gemini 3.8 Flashは辛うじて半数を捉えるにとどまった。

• サンドバッギング： テストしたすべての監査モデルが71〜81%の事例を検知した。（なお、METRのサンドバッギングシナリオの多くは合成されたもので、タスクをサボタージュするようモデルにプロンプトを与え、可視化された推論ログからその指示を削除して作成されている）。

明白な違反については、一貫してフラグが立てられた。例えば、OpenAIのo3がRustのプログラミングタスク中に評価システムとコードライブラリを共有していることに気づき、すべての提出物が正解と判定されるようスコアリング関数を改ざんした事例では、人間のレビュアーおよびすべてのAI監査モデルがこれを報酬ハッキングと判定した。

しかし、巧妙な違反は見落とされることが多かった。Claude Sonnet 4が明示的に禁止されていた数値条件をコード内で使用した際、これを不正行為としてフラグを立てた監査モデルは存在せず、GPT-6 Astraはその事象を実装バグと分類した。

コストを高めても誤報は排除できない

APIの利用料金とパフォーマンスを比較したところ、より新しく高価なモデルであっても、監査の信頼性が体系的に向上するわけではないことが判明した。GPT-5は、1,000ログあたりのコストが約8分の1であるにもかかわらず、報酬ハッキングの検出において新型のGPT-6 Astraを大幅に上回った。一方でサンドバッギングの検出に関しては、GPT-5はGPT-6 AstraおよびOpus 4.8と同等の性能を示した。Opus 4.8が報酬ハッキングで振るわなかった点については、評価ログの多くがClaudeモデル由来のものであったことから、自身の仲間を優遇する「自己贔屓」の可能性も浮上したが、ホール氏は未だ証明されていないと述べている。

監査モデルの検出率を80%に調整した場合、最高性能のモデルでも誤報率は2.5〜3%を維持した。他のモデルはさらに苦戦し、80%の報酬ハッキングを検出するために、Opus 4.8は無害なログの40%に、Gemini 3.8 Flashに至っては63%にフラグを立ててしまった。

月間10万件のエージェントセッションを処理する実際の運用環境では、3%の誤報率は、約2,000件の真のインシデントに対して約3,000件の誤報が混ざることを意味する。ホール氏は、この膨大なノイズが人間の安全対策チームを圧倒し、アラート疲れによって実際の違反が見落とされて誤認承認されてしまうリスクがあると警告した。また、複数の監査モデルを組み合わせる手法も明確な改善にはつながらなかった。

残り数パーセントを捉えるための代償

日常的なエージェントの挙動を270件の安全なログで測定する上海交通大学のベンチマーク「R-Judge」でのテストでは、感度と精度のトレードオフがさらに顕著になった。

誤報率5%の閾値では、Opus 4.8は危険なアクションの96%近くを特定した。検出目標を95%に設定した場合でも、大半のモデルは誤報率を10%未満に抑え、Gemini 3.8 Flashは4%未満を維持した。

しかし、要求される検出目標を99%に引き上げると、誤報率は劇的に跳ね上がった。

• GPT-6 Astraの誤報率は15%に上昇した。

• Gemini 3.8 Flashの誤報率は4%未満から81%へと急増した。

エージェント監査が直面する現実的な課題

自律型システムの検証がいかに困難であるかは、Hugging Face上でOpenAIエージェントの群れ（スウォーム）が関与し、約1,300件のトランスクリプトと120万個のファイル断片を生成した現実のインシデントでも浮き彫りになった。METRは自動化されたAIエージェントを用いてログを分析したが、約40万ドル相当のAPIクレジットを消費することとなった。

しかも、その監査の一部は、インシデント自体に関与していたモデルであるGPT-5.6 Solに依存していた。METRは後に、監査モデルが調査対象エージェントの視点を採用してしまうケースが頻発し、調査自体が潜在的な欺瞞に対して脆弱であったことを認め、独立したインシデント分析フレームワークの構築を訴えた。

ホール氏は、本研究が特定の制約を伴う初期の予備調査であることを強調している。METRの元のプロンプトをほぼそのまま維持したため、Fable 5とOpus 5は評価タスクの実行そのものを拒否した。さらに、報酬ハッキングの事例数が47件と小規模であるため、ログ1件の結果でスコアが2パーセントポイントも変動してしまう側面がある。

CodexやClaude Codeのようなコーディングエージェントの普及により、ユーザーがステップごとの承認を経ずに自律的な実行権限を付与できるようになる中、ガバナンスモデルによって法的および運用上の責任を明確化しなければならないとホール氏は指摘する。誤報率を劇的に下げられるモデルが登場しない限り、AIの監視を全面的にAIへ委ねる運用は、非効率であるばかりか法外なコストを要するリスクを孕んでいる。