規制・社会

監視AIでも防げないAIエージェント攻撃とは

記事バナー画像

POINT

  • AIエージェントを「監視AI」で見張っても、Agent-as-a-Proxy攻撃によってその監視ごと回避される脆弱性が2026年2月の論文で示された
  • エージェントが高速・大量にタスクをこなせるようになるほど、1つの攻撃が及ぼす被害範囲も比例して広がる
  • 「監視をつければ安全」という前提が崩れた今、企業がエージェント導入前に確認すべき判断軸を整理する

「代理で動く」ことの意味を、もう一度考える

AIエージェントとは、ユーザーの指示を受けてメール送信・ファイル操作・ウェブ検索・予約といった一連の作業を自律的にこなすシステムだ。「やっておいて」と言えば、後は勝手に進める。便利さの本質はここにある。

ただし、「代理で動く」ということは、エージェントが外部の情報を読み込み、その内容に基づいて判断し、実際のシステムを操作する、という連鎖を意味する。この連鎖のどこかに悪意ある指示が紛れ込んだとき、被害はエージェントが持つ権限の範囲まで広がる。

問題は「紛れ込む経路」が想像以上に多いことだ。添付ファイル、ウェブページの本文、メールの署名欄。エージェントが読む可能性のあるテキストすべてが、攻撃の入口になりうる。

「監視AIが見張っている」では不十分な理由

多くの企業や研究者が採用してきた対策は、エージェントの行動を別のAIが監視するアーキテクチャだ。エージェントが何を考え(Chain-of-Thought)、どのツールを使ったかを監視AIがチェックし、ユーザーの意図とずれていれば止める、という仕組みである。

この前提を正面から崩したのが、2026年2月4日に公開された論文Bypassing AI Control Protocols via Agent-as-a-Proxy Attacksだ。

論文が示した攻撃手法「Agent-as-a-Proxy(AaP)」は、エージェントを「配達メカニズム」として利用し、エージェントと監視AIの両方を同時に回避する。監視AIが見ているのは、エージェントが出力した思考ログとツール呼び出しの記録だ。AaP攻撃はその記録自体を正当に見せかけながら、裏で意図しない操作を実行させる。

Qwen2.5-72Bという大規模な監視モデルでも、GPT-4o miniやLlama-3.1-70B程度の能力を持つエージェントに回避されたと論文は報告している。「フロンティア規模の監視AIを使えば安心」という期待は、少なくともこの研究では成立しない。AgentDojoベンチマーク上では、AlignmentCheckとExtract-and-Evaluateという2種類の監視手法に対して、いずれも高い攻撃成功率が確認されている。

Agent-as-a-Proxy (AaP) 攻撃の仕組み
通常フロー AaP攻撃フロー ユーザーからの正常な指示 エージェント 正常な思考ログ(CoT)を生成 ツールを呼び出し 監視AI ログをチェックし ユーザーの意図と一致か確認 承認・正常実行 悪意ある命令を含む 外部データ エージェント 正常な思考ログ(CoT)を偽装 裏で不正なツール操作を実行 監視AI 偽装されたログのみを見て 正常な動作だと誤認する 監視をすり抜け 被害発生 Qwen2.5-72B規模の監視モデルでも回避され、主要な監視手法に対して高い攻撃成功率を示す 通常フロー AaP攻撃フロー 正常なユーザー指示 エージェント 正常なCoTログ生成 ツール呼び出し 監視AI ログをチェックし 意図を確認 承認・正常実行 悪意ある命令を含む 外部データ エージェント 正常ログを偽装 裏で不正操作 監視AI 偽装ログを見て 正常と誤認 監視を抜け被害発生 Qwen2.5-72B規模の監視モデルでも回避され、 主要な監視手法に対し高い攻撃成功率を示す
AaP攻撃は、エージェントの思考ログ(CoT)を偽装し、監視AIを欺いて不正操作を実行する。

処理速度が上がるほど、被害の規模も広がる

攻撃手法の話と並行して、エージェントの処理能力は急速に上がっている。H Companyが公開したHolotron-12Bは、単一のH100 GPUで毎秒8,900トークンを処理し、同社の前世代モデルHolo2-8Bの5,100トークン/秒を大きく上回った。100件の同時リクエストを処理しながらこの数値を出している。

処理速度が上がることは、業務効率の観点では歓迎すべき話だ。しかし攻撃耐性の観点では別の意味を持つ。

エージェントが1秒間に処理できる量が増えるほど、1回の攻撃が引き起こせる被害の規模も比例して広がる。 100件を同時処理するシステムが乗っ取られれば、100件分の操作が悪意ある方向へ向く。人間が承認を挟む余地はない。

Holotron-12Bはウェブナビゲーション精度をベースモデルの35.1%から80.5%まで引き上げ、画面理解・UI操作のベンチマークでも改善を示した。エージェントが「より賢く、より速く」なるほど、セキュリティの前提条件を整備する側の責任も重くなる。

速さが上がるほどリスクが広がる構造
スループット比較 (tokens/s) 5,000 10,000 Holo2-8B 5,100 Holotron-12B 8,900 条件: 単一H100 GPU / 最大同時実行 100 / vLLM 0.14.1 WebVoyager精度 ベースモデル 35.1% Holotron-12B 80.5% 処理能力向上に伴うリスク拡大 100件の同時リクエストを高速処理 乗っ取り発生 100件分の悪意ある操作が 瞬時に実行される スループット比較 (tokens/s) 5,000 10,000 Holo2-8B 5,100 Holotron-12B 8,900 条件: 単一H100 GPU / 最大同時実行 100 / vLLM 0.14.1 WebVoyager精度 ベースモデル 35.1% Holotron-12B 80.5% 処理能力向上に伴うリスク拡大 100件の同時リクエストを高速処理 乗っ取り発生 100件分の悪意ある操作が瞬時に実行
スループットと精度の向上は業務効率を高める一方、システムが乗っ取られた際の被害規模も比例して拡大させる。

導入前に確認すべき3つの軸

「監視をつけても回避される」という事実は、エージェントを使うな、という結論を意味しない。リスクの性質を正確に把握したうえで、権限設計と運用フローを組み立てる、ということだ。

エージェントに与える権限を最小化する

メール送信、ファイル削除、外部API呼び出し。これらをすべて同一エージェントに与えると、1回の乗っ取りで被害が連鎖する。タスクごとに権限の範囲を分割し、「読む権限」と「書く権限」を別エージェントに持たせる設計が、現実的な防衛線になる。

外部データを読み込む前に人間の目を入れる

IPI攻撃の入口は、エージェントが読む外部テキストだ。ウェブ取得・添付ファイル解析・メール本文の読み込みといった入力フローに、人間の確認ステップを挟む。全件確認は非現実的でも、「未知ドメインからのデータ」や「高権限操作の直前」に絞れば運用負荷は抑えられる。

監視AIの判断を「安全の確定証明」として扱わない

今回の研究が示したのは、監視AIの判断が偽装によって狂いうるという事実だ。監視ログは「異常を検知する手がかり」として使いつつ、定期的な人間によるサンプル確認を組み合わせる。監視AIが「問題なし」と判断した操作ログを週次・月次でランダム抽出して人が確認する体制が、現実的な解になる。

まとめ

2026年2月の研究は、「監視AI付きなら安全」という設計思想に明確な穴を開けた。エージェントの能力が上がるスピードは、防御側の整備速度を上回っている。導入判断の基準は「使えるか」ではなく、「権限・入力経路・監査フローを整備できるか」に置くべきだ。その準備が整わないままフル自動化を走らせることは、施錠されていない場所に重要な書類を積み上げるのと変わらない。