個々のAIモデルが「安全」でも、複数のエージェントを連結したシステムはそのまま安全にはなりません。プランナー・ワーカー・検証役・統合役をつなぐ「エージェント間のやり取り」は、多くの場合だれも監視していない通路であり、そこに攻撃者が指示を紛れ込ませられる——2026年7月20日にarXivで公開された査読前論文「ChannelGuard」は、この見落とされがちな穴を実験で示しました。本記事は情シス担当者向けに、何が問題で、自社でAIエージェントを使う際に何を確認すべきかを噛み砕きます。
この記事でわかること
- 「安全なモデルを組み合わせれば安全」という前提がなぜ崩れるのか
- エージェント間チャネルという新しい攻撃面の位置づけ
- 提案手法ChannelGuardの仕組みと実験結果、そして限界
- 自社でAIエージェントを導入・運用する際の実務上の勘所
※本記事はarXivのプレプリント（査読前の研究）を基にしています。結果は今後の査読・追試で変わりうる点にご注意ください。
どんな研究か（1文で）
複数のLLMエージェントを連結したアプリでは、エージェント同士の受け渡し部分が無防備な攻撃通路になるため、その各通路に軽量な「関所」を置いて悪意ある指示を止める、という提案です。著者はElias Hossainら5名（Md Mehedi Hasan Nipu、Fatema Tuj Johora Faria ほか）です。
何が問題なのか
Q. 安全なモデルを組み合わせれば、システムも安全ではないのか？
A. いいえ。個々のモデルの安全性は、連結したシステム全体の安全性を保証しません。
いまの多エージェント構成は、ざっくり次のような分業パイプラインになっています。
- プランナー：依頼を分解し、作業計画を立てる
- ワーカー：計画に沿ってツール実行や情報収集を担う
- 検証役（verifier）：出力の妥当性をチェックする
- 統合役（synthesizer）：結果をまとめて最終回答にする
問題は、このエージェント間の「ホップ（受け渡し）」が監視されていないことです。攻撃者は、ワーカーが読み込んだ外部データや別エージェントの出力に指示を仕込み（プロンプトインジェクションやツール汚染）、下流のエージェントを操れます。入口だけを守る既存の防御（入力境界のフィルタ類）は、この内部の通路を素通しにしてしまいます。
論文が鋭いのは、「一見すると完全に安全に見える無防備なパイプラインは、その安全性のほとんどをクラウド事業者のサーバ側フィルタに依存している」と指摘した点です。つまり自前の設計で守れているわけではなく、基盤側の善意に乗っているだけ、という状態が起こりうるということです。
提案手法ChannelGuardの仕組み
Q. ChannelGuardは何をするのか？
A. エージェント間の各通路に「情報のしぼり関所」を置き、危険な文面を通過・圧縮・遮断に振り分けます。
具体的には、受け渡される文章を「攻撃に使われがちな表現の辞書（adversarial phrase bank）」と埋め込みの類似度で照合し、スコアに応じてそのまま通す／情報量を絞って圧縮する／遮断するを決めます。判定は決定的（ランダム性なし）で、しかも追加のLLM呼び出しを必要としないため、コストと遅延を抑えられるのが実務上の利点です。多エージェント全体を「境界だけでなく内部も守る」多層防御（defense-in-depth）の発想と言えます。
実験結果
論文が報告する主な数値は次のとおりです（査読前のため参考値）。
| 観点 | 結果 |
|---|---|
| ツール汚染（Tool Poisoning）攻撃の遮断 | 3種のモデル基盤で30/30を一貫して遮断 |
| プロンプトインジェクションの成功率 | 約50%低減（0.333 → 0.167） |
| 通常タスクの精度維持（GSM8K） | 0.867を維持（防御による大きな劣化なし） |
| 評価全体のコスト | 総額 $47.36 |
ツール汚染をほぼ完全に止めつつ、正規タスクの精度を保てている点がポイントです。防御を足すと使い勝手が落ちる（過検知で正常な処理まで止まる）のがこの種の対策の悩みどころなので、精度を維持できたことには意味があります。
限界・留意点
Q. これで攻撃は防げるようになったのか？
A. いいえ。特に巧妙な言い換え攻撃には弱く、万能ではありません。
論文自身が認める大きな限界は、内部構造を知ったうえで表現を言い換える適応的攻撃（white-box adaptive paraphrasing）には、埋め込みベースの関所が回避されうることです。実際、複数回ゆらして多数決を取る系統の別手法（perturb-and-vote）のほうが、こうした高度な言い換えに対しては頑健だったと報告されています。プロンプトインジェクション成功率も「半減」であって「ゼロ」ではありません。単一の対策で完結させず、複数の防御を重ねる前提で捉えるべき研究です。
情シスはどう受け止めるべきか（現場目線）
この研究が実務に突きつけるのは、「AIエージェントを社内に入れるとき、私たちは境界（入口）ばかり気にして、エージェント同士が何を受け渡しているかをほとんど見ていない」という現実です。RPAやワークフロー自動化の延長でエージェントを組むと、内部のやり取りはブラックボックス化しがちで、ログすら残っていないことも珍しくありません。人員の限られた情シスにとって、外部境界の監視だけでも手一杯なのに、内部チャネルまで面倒を見るのは正直つらい——というのが率直なところでしょう。
だからこそ、次の観点を導入時のチェックに加えることをおすすめします。
- エージェント間のやり取りをログに残せるか（後から追跡・監査できるか）
- 外部データやツール出力が、そのまま下流の指示として解釈されない設計になっているか（データと指示の分離）
- 「基盤モデル側のフィルタ頼み」になっていないか（自社側の防御の有無を棚卸し）
- ツールの実行権限を最小化しているか（汚染された指示が届いても被害を限定できるか）
これは新しいようで、実はゼロトラストの発想（内部も信頼しない・最小権限・すべてを検証）をAIエージェント間に当てはめる話でもあります。プロンプトインジェクションは公的にもLLM特有のリスク筆頭として整理されており（OWASPの生成AI/LLM向けリスク一覧「LLM Top 10」でも最上位に位置づけられています）、基礎的な考え方はOWASP Top 10 for LLM Applicationsで確認できます。組織全体の情報セキュリティ管理としては、IPA「中小企業の情報セキュリティ対策ガイドライン」や利用者啓発のIPA「対策のしおり」もあわせて参照し、地道な運用ルールとユーザ教育の土台を固めておくのが現実的です。
関連記事
- AIエージェントの「停止」は効くのか 承認ゲートの穴を検証
- AIコーディング補助を狙う「設定汚染」攻撃
- RAGの情報漏えいは質問で変わる｜査読前の新研究
- MCPサーバの脆弱性を実行証拠で検出｜研究解説
まとめ
- 「安全なモデル＝安全なシステム」ではない。多エージェント構成では、エージェント間の無防備な通路が新しい攻撃面になる。
- ChannelGuardは各通路に軽量な関所を置き、ツール汚染をほぼ遮断・インジェクション成功率を半減させつつ通常精度を維持したが、巧妙な言い換え攻撃には弱く万能ではない（査読前の研究）。
- 情シスはエージェント間のログ取得・データと指示の分離・最小権限・基盤フィルタ依存の棚卸しという「内部にもゼロトラスト」の視点を導入チェックに加えるべき。
出典
- Elias Hossain, Md Mehedi Hasan Nipu, Fatema Tuj Johora Faria, Tasfia Nuzhat Ornee, Maleeha Sheikh. “ChannelGuard: Safe Models Do Not Compose into Safe Multi-Agent Systems.” arXiv:2607.19430（2026年7月20日、査読前プレプリント）https://arxiv.org/abs/2607.19430
- OWASP Top 10 for Large Language Model Applications：https://owasp.org/www-project-top-10-for-large-language-model-applications/
- IPA「中小企業の情報セキュリティ対策ガイドライン」：https://www.ipa.go.jp/security/guide/sme/index.html
