AIエージェントの侵害、最終出力の監視だけでは見逃す恐れ　新研究が中間処理のリスクを整理

本番環境でAIエージェントを運用する組織は、最終応答の安全性だけを見ても、処理全体が安全だったかを判断できない可能性がある。新たなSoK論文は、計画・推論、メモリ、ツール利用などの中間段階が攻撃の影響を受けても、最終応答には問題が現れない場合があると報告した。

Webの閲覧、文書の参照、APIの呼び出し、コードの実行などを自律的に進めるAIエージェントでは、応答内容に加えて、実行経路や外部システムへの操作を継続的に確認する仕組みが重要になる。

■最終応答だけでは分からない中間段階の侵害

論文「SoK: Rethinking Jailbreaking in the Era of Agentic AI: Attacks, Defenses, and Practical Consideration」は、Md Jueal Mia、Yanzhao Wu、Selcuk Uluagac、M. Hadi Aminiの4人が2026年9月11日にarXivへ投稿したプレプリントである。

SoKは「Systematization of Knowledge」の略で、特定分野に蓄積された研究を体系的に整理し、共通する課題や評価方法を提示する研究形式を指す。今回の論文は既存のジェイルブレイク攻撃と防御に関する研究を、AIエージェントの実行パイプラインという観点から整理するとともに、代表的な攻撃と防御を共通の枠組みで評価した。

論文が扱うパイプラインは、利用者から要求を受け取るユーザー対話、要求を複数の処理へ分解する計画・推論、中間結果や継続的な文脈を保持するメモリ、APIやブラウザーなどを操作するツール利用、別のエージェントへ処理を委任するエージェント間通信の各層から成る。

研究者らは、計画、メモリ、ツール利用などの中間段階で攻撃が成功しても、最終応答がフィルターで遮断されたり、問題のない形式で生成されたりすることで、中間段階の侵害が最終応答の評価に表れない場合があると報告した。

これは、最終応答における攻撃成功率が低いことと、エージェントの実行経路全体が安全であることが同じではないことを意味する。出力監視で確認できるのは最終的に生成された内容であり、計画が変更されたか、メモリに不適切な命令が残されたか、許可されていないツール操作が試みられたかは、個別に記録して評価する必要がある。

例えば、AIエージェントがWeb上の資料を収集してレポートを作成する場合、取得した文書に間接プロンプトインジェクションが含まれていると、計画やツール操作が影響を受ける可能性がある。最終的なレポートの文章や形式に明確な異常がなくても、その作成過程で想定外のAPI呼び出しやデータアクセスが行われていれば、出力内容だけを対象とする監視では捉えにくい。

■アラインメントと敵対的攻撃への耐性は別の評価が必要

論文が示す第一の論点は、モデルが通常の利用場面で安全に振る舞うよう訓練されていることが、敵対的に設計されたジェイルブレイク攻撃への耐性を必ずしも保証しないという点である。

RLHF（人間のフィードバックによる強化学習）やConstitutional AIなどのアラインメント手法は、一定の方針や人間の選好に沿った応答を生成するようモデルを調整する。一方、敵対的堅牢性は、学習した安全行動の境界や弱点を狙って作られた入力に、モデルやシステムがどこまで耐えられるかという性質である。

研究者らの評価では、通常の有害プロンプトに対する安全性が高いモデルであっても、すべての種類のジェイルブレイク攻撃に強いとは限らなかった。このため、通常時の安全な応答、敵対的入力への耐性、エージェントとして外部へ及ぼす動作の安全性は、それぞれ分けて評価する必要がある。

この区別は企業による導入判断にも関係する。モデル単体の安全性評価で良好な結果が出ていても、実際の運用環境で利用するメモリ、外部データ、権限、ツール、複数ターンの処理を含めた安全性まで確認されたことにはならない。

■防御効果はモデルや攻撃方法によって変わる

第二の論点は、防御策の効果がモデル、攻撃方法、対象となるシステム構成要素によって変化することである。研究者らが評価した範囲では、すべての組み合わせに一貫して有効な単一の防御策は確認されなかった。

あるモデルと攻撃方法の組み合わせで攻撃成功率を大きく下げた対策でも、別のモデルや攻撃では効果が小さい場合があった。異なるモデルやツールを組み合わせる企業環境では、個別の防御機能の有無だけでなく、実際の構成と利用方法に即した検証が必要になる。

安全対策には、正常な要求まで拒否する過剰拒否や、複数段階の検査による応答遅延といったコストも伴う。知識業務、法務確認、顧客対応、ソフトウェア開発などでは、過剰拒否が増えれば完了できる業務が減り、検査を増やせば応答時間や処理コストが上昇する。

論文はこの関係を整理するため、セキュリティ、有用性、効率性を分けて測る評価枠組みを提示した。防御策の導入では、攻撃成功率をどの程度下げられるかだけでなく、正常なタスクの完了率や処理時間への影響も併せて評価する必要がある。

■単一の応答からセッション全体の評価へ

従来の安全性評価では、有害なプロンプトを一つ入力し、生成された一つの応答を採点する方法が広く用いられてきた。この方法は、モデルが直接的な有害要求を拒否するかを測るうえでは有用だが、複数ターンにわたって計画を立て、外部ツールを操作するAIエージェントの実行経路全体を評価するものではない。

AIエージェントでは、個々の指示や応答には問題がなくても、一連の処理を組み合わせることで安全上の問題が生じることがある。生成された文章だけでなく、参照したデータ、作成・変更したファイル、呼び出したツール、与えられた権限、処理途中で保存された状態をセッション単位で確認する必要がある。

2026年7月に公開されたAlan Turing Instituteの研究でも、GitHub Copilotを使った複数段階のコーディング作業に有害な目的を組み込むことで、直接のチャットでは拒否された内容がコード内に生成される「ワークフローレベルのジェイルブレイク」が報告された。これは、単一のプロンプトと応答だけでなく、作業全体と生成物を評価する必要性を示す事例である。

■企業調査も可視性と制御の隔たりを示す

AIソフトウェア企業Harnessが700人のエンジニアリング部門のリーダーを対象に実施した調査では、回答者の77％が、自社で稼働するAIエージェント、MCPサーバー、LLMを完全に把握していると考えていた。一方、実際に能動的な検出ツールを運用しているとの回答は44％だった。

また、74％が本番環境に影響する不具合をテストで発見できると回答したのに対し、不適切なリリースを自動的に阻止するゲートを備えていたのは19％だった。この調査はHarnessによる企業調査であり、論文の実験結果とは別の資料だが、組織側の確信と、技術的に確認できる制御手段との間に隔たりがある可能性を示している。

■中間処理の記録と最小権限が重要に

企業がまず取り組めるのは、最終応答の安全性指標をパイプライン全体の安全性の代替指標として扱わないことである。最終応答と中間処理では観測する対象が異なるため、それぞれに評価項目を設定する必要がある。

次に必要となるのが、セッション単位の監査ログである。エージェントが何を回答したかだけでなく、どの情報を参照し、どのような計画を立て、どのツールをどの権限で呼び出し、何を変更したかを追跡できるようにする。ログには機密情報が含まれる可能性があるため、保存期間、アクセス制御、個人情報や認証情報の除外も設計に含める必要がある。

ツールには最小権限を適用し、エージェントが利用できるデータ、API、ファイル、実行環境を、タスクに必要な範囲へ制限することも重要だ。計画段階が操作された場合でも、利用できる権限が限定されていれば、外部システムへ及ぼす影響を抑えられる。

EU AI Actには、高リスクAIシステムについて、リスクの特定などに関係するイベントを自動的に記録できるようにする要件がある。ただし、これは高リスクAIシステム全般を対象とする規定であり、すべてのAIエージェントに中間ステップの記録を一律に義務付けたエージェント専用規定ではない。企業は法令上の分類とは別に、自社のエージェントが持つ権限と外部への影響に応じて、必要な監視範囲を判断する必要がある。

今回の論文は完全な防御アーキテクチャーを提示するものではなく、研究者による査読を経た確立済みの標準でもない。それでも、最終応答だけを測る安全性評価と、計画、状態、ツール操作を含むエージェント全体の安全性評価を区別する必要性を明確にした。

AIエージェントの安全監視では、何を答えたかだけでなく、答えに至るまでに何をしたかを評価することが中心的な課題になる。今後は、個別の応答ではなく、セッション全体の実行経路と外部への操作を対象にした評価方法の整備が求められる。

元記事: AI Agent Pipeline Breaches Stay Hidden From Safety Dashboards, Study Finds