AIエージェント防御の自己進化｜論文解説

AIエージェント防御の自己進化｜論文解説 研究・論文

2026年8月13日にarXivで公開された論文が、AIエージェントのセキュリティ運用に効く指摘をしています。要点は次の3つです。

  • 何が起きたか：LLMエージェントの「ランタイム防御」（実行の途中に割り込んで止める仕組み）は、いま人間が手作業でルールを書いて作られている。その属人性と陳腐化が問題だと指摘されました。
  • 誰に影響するか：社内でAIエージェントにツール実行やファイル操作、外部API呼び出しをさせている、あるいはこれから任せようとしている組織。
  • 今すぐ何をすべきか：自社のガードレールを「一度作れば終わる設定」ではなく「攻撃側の変化に合わせて更新し続ける運用対象」として台帳に載せること。

この記事でわかること

  • LLMエージェントの「ランタイム防御」「ハーネス」とは何を指すのか
  • 論文が提案するHARDという枠組みが、何を自動化したのか
  • 報告された攻撃成功率の低減幅と、そこから読み取れる限界
  • 情シスが自社のAIエージェント基盤を点検するときの観点

なお本論文は査読前のプレプリントです。結果は今後変わりうる前提で読んでください。

そもそも「ハーネス」「ランタイム防御」とは何ですか

ハーネスとは、LLM本体の周りにあって「モデルに何を見せるか」と「モデルの出力をどう実行するか」を決めている土台のプログラムです。モデルそのもの（GPTやClaudeなどの重み）ではなく、その外側で入出力を仲介している部分を指します。

これは開発者向けの専門用語に見えますが、情シスにとって他人事ではありません。社内でAIエージェントを動かすとき、実体としては次のようなものがハーネスに当たります。

  • 社内チャットボットやAI業務アシスタントのバックエンド実装（検索結果や社内文書をプロンプトに詰め込んでいる箇所）
  • コーディング支援エージェントやRPA連携のツール実行部分（モデルが出した「このコマンドを実行して」を実際に走らせる箇所）
  • SaaSベンダーが提供するAIエージェント機能の内部。この場合、ハーネスはベンダー側にあり、利用者からは中身が見えません。

つまり「うちはモデルを自前で作っていないから関係ない」とはなりません。エージェントを業務に組み込んだ時点で、自社かベンダーのどちらかにハーネスが存在し、そこが防御の主戦場になります。そして「ランタイム防御」とは、このハーネスの中に検査や遮断の仕組みを埋め込み、危険な動作を実行の直前で止めるアプローチのことです。

何が問題だと指摘されているのか

論文の出発点は、既存のランタイム防御が手作り（handcrafted）に依存しているという指摘です。「このパターンの指示が来たら拒否する」「この種類のツール呼び出しは承認を求める」といったルールを、人間が経験と勘で書いています。

この方式の弱点は、現場感覚とよく一致します。

  • 書いた人しか全体像を把握していない：担当者の異動でルールの意図が失われる。
  • 攻撃の変化に追随できない：新しい迂回手口が出るたびに人手でルールを足すことになり、常に後追いになる。
  • 効果を測る枠組みがない：ルールを増やしても、それが本当に効いたのか、業務を邪魔しただけなのかが分からない。

この「ガードレールを固めても迂回される」という現象自体は、これまでも複数の研究で報告されてきました。当サイトでも、GUIエージェントのガードレールが対話の積み重ねで崩れていく研究や、LLMガードレールの限界を安全性トリレンマとして整理した論文を取り上げています。今回の論文は、その「守り切れない」問題に対して、ルールを書く作業そのものを自動化するという角度から答えようとしたものです。

論文の提案：HARDは何を自動化したのか

提案手法はHARD（Harness-based Autonomous Runtime Defense Evolution）と名付けられています。仕組みは大きく2つの部品からなります。

介入できる場所は2か所しかない、という整理

論文はまず、ハーネスにおける防御の介入点を次の2つに定式化しています。この整理自体が、実務でも点検の軸として使えます。

介入点 役割 現場で対応するもの
コンテキスト構成 モデルに何を見せるかを制御する 外部から取り込んだ本文の区切り方、信頼できないデータの明示、不要情報のフィルタ
アクション解釈 モデルの出力を実際の操作にどう変換するかを制御する ツール実行の可否判定、危険な操作の遮断、承認フローへの引き上げ

言い換えると、「入力側で汚染を持ち込ませない」か「出力側で危険な実行を止める」か、防御はこの二択に整理できるという主張です。自社のエージェント基盤を点検するとき、この2か所それぞれに何らかの検査が入っているかを確認するだけでも、抜けが見つかりやすくなります。

失敗した実行ログから、防御ルールを自動で書き直す

HARDの中核は、防御の作成を人手ではなく自動の進化プロセスに置き換えた点です。論文が示す流れは3段階です。

  1. 失敗の収集：攻撃を含むタスクをエージェントに実行させ、防御が破られた実行トレースを集める。
  2. 失敗の振り分け：LLMベースの振り分け役が、その失敗を「方針（semantic）を直すべきか」「具体的な遮断条件（gate）を直すべきか」に分類する。
  3. 防御の更新：それぞれ担当のLLMが、失敗の内容をフィードバックとして防御ルールを書き直す。

要するに「破られたログを教材にして、次はそれを止められるようにルールを自動で書き足す」という発想です。人間のセキュリティ担当者がインシデント後にルールを見直す作業を、機械のループとして回そうとしていると理解すると分かりやすいでしょう。

どこまで効いたのか

実験は、ツール利用型エージェントのベンチマークAgentCanaryを主軸に、実行役のエージェントをDeepSeek-V4-Flashに固定して行われています。安全性と有用性の判定にはGLM-5が使われました。論文は次の結果を報告しています。

攻撃の種類 どんな攻撃か HARD適用時の攻撃成功率
直接プロンプトインジェクション 利用者の入力に直接、指示の乗っ取りを仕込む 15.4%
間接プロンプトインジェクション エージェントが読むWebページや文書に指示を仕込む 1.0%
メモリポイズニング エージェントの記憶に嘘の情報を残して後から効かせる 6.7%
スキルポイズニング エージェントが使うツール・スキルの定義側を汚染する 10.2%

論文は、これを従来の手作り防御の13〜66%という幅と比較し、優位だと主張しています。同時に、攻撃を含まない通常業務での有用性（benign utility）は91.9〜95.0%を維持したとされています。「安全にしたら業務が回らなくなった」を避けられているかを同時に測っている点は、実務的に評価できる設計です。

なお、間接プロンプトインジェクションが1.0%と際立って低い一方、直接プロンプトインジェクションが15.4%残っている点は示唆的です。外から流し込まれた汚染データは機械的に区切って無害化しやすいのに対し、利用者自身の入力に紛れ込んだ乗っ取りは切り分けが難しい、という構図が読み取れます。関連して、プロンプトインジェクションがSSRFのような従来型の攻撃に化ける研究も併せて読むと、被害の出口側がイメージしやすくなります。

現場目線：数字の見た目より重要な点

ここからは、記事として都合の良い数字だけを拾わないための注意点です。実務で判断材料にするなら、むしろこちらが本題だと考えています。

攻撃側が適応してくると、成功率は一桁には戻らない

論文は、防御に合わせて攻撃側が手を変えてくる「適応攻撃」も評価しています。動的に攻撃を進化させる設定（DAE）では、HARDの攻撃成功率は26.5%でした。最良の手作り防御の30.1%より改善しているとはいえ、4回に1回は通ってしまう水準です。

ここは冷静に受け止めるべきところだと思います。自動進化させても、攻撃側が同じように適応してくる状況では、ランタイム防御は「攻撃を止める壁」ではなく「多層防御の一枚」にとどまります。エージェントに渡す権限を最小化する、実行結果を監査ログで追えるようにする、といった外側の設計を省く理由にはなりません。

防御を足し合わせれば強くなる、とは限らない

長期にわたって段階的に仕掛ける攻撃（LPA）では、方針側だけを進化させた構成が4.8%だったのに対し、方針と遮断条件の両方を進化させた構成は12.1%と、むしろ悪化していました。複数の防御部品を同時に育てると相互作用が起き、単純な足し算にならないということです。

これは現場の実感とよく合います。検知ルールやブロック設定を積み増した結果、互いに干渉して例外だらけになり、かえって穴が空くという経験は珍しくありません。ルールを増やしたら、増やした後の全体で測り直すという当たり前の作業から逃げられない、ということでもあります。

評価そのものをLLMが行っている

この実験では、攻撃が成功したかどうかの判定にもLLMが使われています。判定役のモデルが見落とせば、成功率は実態より低く出ます。LLMの自己申告や自己評価の信頼性については、AIの確信度が当てにならないことを示した研究でも触れました。ベンチマーク上の数値を、そのまま自社環境で再現する期待値として扱わないことをおすすめします。

情シスは何をすべきか

この論文単体で明日から入れられる製品が出てくるわけではありません。それでも、自社の点検には使えます。

  • エージェントの棚卸し：社内で稼働しているAIエージェント／AI機能を洗い出し、それぞれが「外部データを読むか」「ツールを実行するか」「記憶を持つか」を記録する。記憶を持つものは、記憶が汚染・干渉されるリスクまで含めて評価対象になります。
  • 2つの介入点で点検する：入力側（信頼できないデータの区別）と出力側（実行の遮断・承認）に、それぞれ検査が入っているかを確認する。ベンダー製品なら、どちらの対策を提供しているかを質問項目にする。
  • ガードレールを運用対象として台帳に載せる：作成日・作成者・最終見直し日を管理し、定期的に見直す。放置されたルールは、あるだけで安心を生む分だけ危険です。
  • 体制と規程を先に整える：技術的な防御以前に、AI利用のルールが明文化されていない組織が多いのが実情です。IPAのAIセキュリティに関する情報ページや、「AI利用時のセキュリティ脅威・リスク調査報告書」は、自社の規程整備が業界の中でどの位置にあるかを測る材料になります。
  • 利用者への啓発を並行させる：直接プロンプトインジェクションが残っている以上、利用者が不審な指示文をそのまま貼り付ける行動自体を減らす必要があります。IPAの「対策のしおり」のような啓発資料を、社内教育の土台に使えます。

正直なところ、エージェント基盤の細部まで情シスが把握しきるのは簡単ではありません。開発部門が入れたツールや、SaaSの新機能として勝手に増えるAI機能まで含めると、把握そのものが追いつかないのが実態でしょう。だからこそ、全部を見ようとするより「外部データを読み、かつツールを実行できるもの」から優先的に押さえるのが現実的な順序だと考えています。

限界と留意点

  • 査読前のプレプリントです。今後の査読で結果や主張が変わる可能性があります。
  • 実行役のエージェントは1つのモデルに固定されており、他のモデルで同じ効果が出るかは分かりません。進化を担当するモデルを変えた追加実験では、結果に差が出たことが報告されています。
  • 評価はベンチマーク環境上のものであり、実際の業務システムの複雑さは反映されていません。
  • 商用LLMのAPIには非決定性があるため、同じ手順でも結果が完全には再現しない点が論文中でも触れられています。
  • 1本の論文の結果を、AIエージェント防御全般の結論として一般化しないでください。

まとめ

  1. LLMエージェントのランタイム防御は現在ほぼ手作りで、属人化と陳腐化という構造的な弱点を抱えています。論文はこれを自動進化させる枠組みHARDを提案し、静的な攻撃では成功率を1.0〜15.4%まで下げつつ、通常業務の有用性を91.9〜95.0%維持したと報告しています。
  2. ただし攻撃側が適応してくる設定では成功率26.5%が残り、防御部品を足し合わせると逆に悪化する場合もありました。ランタイム防御は多層防御の一枚と位置づけるべきです。
  3. 情シスとしては、エージェントの棚卸しと「入力側／出力側」の2点検、そしてガードレールを見直し対象として台帳管理することから始めるのが現実的です。

出典

タイトルとURLをコピーしました