外部コンテンツに埋め込まれた指示の実行(間接プロンプトインジェクション)

この失敗は何か

AIエージェントを業務ツールに接続すると、エージェントは「ユーザーが入力した文章」以外のものを大量に読むようになります。受信トレイのメール本文、共有ドキュメント、検索で取得したWebページ、リポジトリの画像ファイル。これらはユーザーが書いたものではなく、第三者が中身を自由に決められるデータです。

そこに命令文が書かれていたとき、モデルには「処理すべきデータ」と「従うべき指示」を確実に区別する仕組みがありません。攻撃者はこの性質を利用して、ユーザーの意図とは無関係な操作をエージェントに実行させます。

危険なのは注入そのものではなく、注入されるエージェントが「接続されている」ことです。メールを送れる、ファイルを読める、外部APIを呼べる、脚を動かせる。命令を受け取る経路と、行動する権限が同じ場所にあることが、この失敗を成立させています。

同じ構造が、あらゆる入力経路で再現する

このパターンがいちばん重要な理由は、件数の多さではなく再現のしかたにあります。エージェントが新しい種類の入力を読めるようになるたび、同じ失敗がその入力経路で作り直されています。

指示を隠した場所	事例	到達した先
カレンダー招待・共有コンテンツ	Gemini 接続ツールへの cross-tool injection	接続されたツールの操作
メール本文	M365 Copilot のゼロクリック流出経路	信頼境界を越えたデータ流出
URLパラメータと連携アカウント	Copilot Personal のコマンドインジェクション(CVE-2026-24301)	Gmail・Google Drive からの機密データ流出
画像のメタデータ	Opus 5 / Claude Code へのステガノグラフィ注入	リモートコード実行(12回中10回成功)
PNG画像	Ghostcommit 攻撃	.env の秘密情報をソースコードへ書き出し
表計算のセル(白文字)	偽の為替レートによる誤判断	割高な見積を「最良」と誤判定
表計算のセル(青地青文字)	CellShock	IMAGE 数式経由で財務データを外部送信
環境音	音声チャネルへの同時注入	マルチモーダルエージェントの操作(成功率69.1%)
法的文書の白色3ptフォント	コネチカット州裁判所への申立書	AI支援による判決の操作(未遂・制裁)
ソースコードのコメント	VirusTotal Code Insights API	セキュリティ分析結果の偽装・無効化
ロボットのカメラ映像	Gemini Robotics VLA モデル	特定の物体を検知したら有害動作(スリーパー)

上から下へ、1年あまりで「メールを読むアシスタント」から「パイナップルを見つけたら動くロボット犬」まで到達しています。媒体は毎回違いますが、構造はどれも同じです。データとして渡したはずのものが、指示として読まれている。

だからこのサイトでは、媒体でパターンを分けていません。分けてしまうと、新しい入力形式が出るたびに「新しい失敗」が生まれたように見えてしまい、同じ設計上の欠陥がずっと放置されているという事実が見えなくなるからです。

研究上の実証だけではない

この一覧の多くは研究者による実証報告です。ただし、実際に使われた形跡のあるものも含まれています。

コネチカット州の事例は、裁判所に提出された本物の申立書に隠し指示が埋め込まれていたもので、裁判官は当該当事者に電子申立の禁止という制裁を科しました。Copilot Personal の事例には CVE 番号が割り当てられ、Microsoft がパッチを公開しています。VirusTotal の事例は Google の AI VRP で受理されました。

重大度はS1(ヒヤリハット)からS3(重大な影響)まで、情報確度はC2からC5まで幅があります。「実証されただけ」の段階のものと、実害や公式対応まで至ったものが同居しているのが、このパターンの現在地です。

なぜ「ゼロクリック」になりうるのか

利用者が不審なリンクを踏む必要はありません。メールを受け取るだけ、画像をリポジトリに置かれるだけで条件が揃います。攻撃コンテンツを読ませる操作が、「受信トレイを要約して」「このコードをレビューして」といった正常な利用そのものだからです。

Ghostcommit の事例が分かりやすい例です。PNG画像に隠された指示は人間のコードレビューでは見えません。レビューを通過して取り込まれ、後日その画像をエージェントが処理したときに初めて発動します。攻撃の実行と、攻撃コンテンツの混入が、時間的に切り離されています。

なぜ防ぎにくいのか

これは修正パッチで塞げる種類のバグではありません。「外部のコンテンツを読んで、内容に応じて気を利かせる」ことは、エージェントの仕様どおりの動作だからです。バグではなく設計の性質に起因しているため、個別の入口を塞いでも別の入口が残ります。当サイトがこの型の原因種別を「設計上の限界」、残存リスクを「高」としているのはそのためです。

入力のフィルタリングやプロンプトによる防御も、攻撃者が言い回しを無限に変えられる以上、確率を下げることはできても保証にはなりません。表計算の事例が示すとおり、単純な埋め込みは検出できても、書式を周囲に合わせて既定の行高では見えない位置に置くだけで回避されています。Ghostcommit では一部のツールが防御に成功していますが、同じ攻撃が他のツールでは通っています。

媒体ごとに追加で必要になること

対策の骨格は共通ですが、入口ごとに前処理が1つ増えます。

• 画像 — メタデータ(XMP/IPTC/EXIF)の除去。本文が無害でも、メタデータに指示が残ります
• 表計算 — セルの書式を無視した読み取り。文字色・行高・列幅で隠されるため、見た目ではなく値を見る必要があります
• 音声 — 入力チャネルの分離。環境音と利用者の発話が同じストリームで届く設計だと区別できません
• ソースコードのコメント — 解析対象からコメントを除外するか、コメントを明示的にデータとして扱う
• カメラ映像 — 視野内に他者が文字列を提示できる前提で設計する。物理空間では入力を制御できません

実務的な対策

効果の大きい順に挙げます。上ほど設計に踏み込みますが、その分確実です。

1. 権限を分離する — 未信頼のコンテンツを読むエージェントに、送信・書き込み・外部呼び出しの権限を同時に持たせない。読む役と、行動する役を分けるのが最も確実です
2. 承認ゲートを置く — 取り消しにくい操作(送信、公開、外部送出)は人間の確認を必須にする。その際「何を、どこへ」送るのかを確認画面に明示します
3. 未信頼コンテンツを隔離する — 外部由来のデータを指示と同じ入力欄に連結せず、データとして明示的に区別して渡す。完全な防御にはなりませんが、成功率は下がります
4. 外向き通信を制限する — 情報を盗み出すには、ほぼ必ず外部への通信経路が要ります。送信先を許可リスト方式にすると、注入が成立しても持ち出しの段階で止められます
5. 影響の記録を残す — どのコンテンツを読んだ後にどの操作が行われたかを追跡できるようにする。事後に経路を特定できなければ、再発防止の判断ができません

当サイトではこの型の「対処すべき層」を運用の変更としています。ベンダーの修正を待つ話ではなく、権限設計と承認フローの側で抑えるしかない、という判断です。

関連するパターン

• 注入された指示が、用意されていた承認ゲートや許可リストを破って特権操作に至る場合は注入された指示による承認ゲート・許可リストの迂回
• 読んだ文章に従うのではなく、ファイルに書かれた設定やコマンドがそのまま実行される場合はリポジトリ・設定・メタデータファイルの記述をエージェントが検証せず実行
• 着地点が機密情報の外部送信である場合はエージェント経由のローカル機密情報の外部持ち出し