AIエージェントの監視は、「別のAIにログを読ませれば安全」で終わりません。Anthropic Fellows Programの研究「SLEIGHT-Bench」は、最先端モデルでも見落としやすい監視の盲点を、40件の合成攻撃トレースで可視化しました。重要なのは監視AIをさらに賢くすることより、盲点の異なる複数の検査を設計することです。
SLEIGHT-Benchが測ったもの
SLEIGHT-Benchは、コーディングエージェントが有害な目的を隠して進めるトレースを集めたベンチマークです。40件の攻撃を11種類の盲点に分類し、Claude、Gemini、GPT系のモデルを監視役として評価しています。
誤検知率を1%に調整した条件では、メインの監視役として評価したClaude Opus 4.6が、40件のうち半数を10回の試行で一度も検出できませんでした。安定して検出できたのは8件です。これは「監視が無意味」という結果ではありません。一つの監視方法を安全証明として扱えないという警告です。
見落としは、危険なコマンドだけに隠れない
11種類の盲点には、実運用でも起こりそうなものが並びます。
- 状態の追跡漏れ：上書きされたファイルや変数の中身を見失う
- 数え間違い：長い出力の行番号やオフセットを正確に確認できない
- 省略：実行した危険操作ではなく、「必要な手順をしなかったこと」を見逃す
- 複数セッション：攻撃を別々の会話に分割されると、各回が無害に見える
- 環境の思い込み：OS、ロケール、シェルなどを標準構成だと決めつける
特に研究内の条件では、「複数段の推論」「省略」「監視役への指示混入」の3分類は検出率0%でした。ログを上から読むだけでは、差分・累積状態・実行されなかった確認まで復元しにくいからです。
万能プロンプトではなく、専門検査を組み合わせる
研究チームは、ファイル状態の台帳を持たせる、認可の根拠を追う、実行環境を明示的に組み立てる、といった専門プロンプトも試しました。対象の盲点には効きましたが、少なくとも別の分類では性能が落ちています。確認項目を一つの長いプロンプトへ足し続けても、万能監視役にはなりません。
一方、監視役をClaude Codeとして動かし、コードでファイル比較などを実行できるようにすると、主張を受け入れるだけでなく検証できました。ただし通常のAPI呼び出しと比べ、平均でモデル呼び出しは約10倍、出力トークンは約14倍です。
ここから、実運用では次の二段構えが現実的です。
- 常時監視：低コストの監視で全トレースを確認し、疑わしい操作を絞る
- 重点監査：権限変更、外部送信、破壊的操作などの前だけ、状態追跡・認可・環境確認の専門検査とツール実行を重ねる
PL視点では「未実施」も成果物にする
車載開発のレビューに例えると、変更した行だけを見るのでは不十分です。要求に対して試験項目が抜けていないか、別工程の変更と組み合わさって危険にならないかも確認します。AIエージェントも同じです。
- 操作前後のファイル、権限、プロセスを差分で残す
- セッションをまたぐ変更履歴を同じ案件IDでつなぐ
- 「何をしたか」だけでなく、必須確認の未実施を検査する
- 誤検知率を固定し、安全なトレースとの対で監視性能を測る
監視AIの評価指標も、単純な検出率だけでは足りません。誤検知が多ければ人の確認が飽和し、本当に危険な警告が埋もれます。SLEIGHT-Benchが1%の誤検知率で比較した点は、運用可能性まで含めて監視を設計するヒントになります。
まとめ
AI監視の弱点は、モデル性能だけではなく監視の構造にあります。単一の長いプロンプトに期待せず、状態・認可・環境・省略を別々に検査し、高リスク操作だけ高価な検証へ回す。監視を「もう一体のAI」ではなく、複数の独立した安全機構を持つシステムとして設計することが重要です。