INSIGHT
AIへの攻撃は、読ませる情報に紛れ込む——観測・実証・実被害を分けて読む
攻撃報告は、自分のAIが読む情報と実行できる操作の何を確かめる材料になるか。
調査用のAIに、Webサイトや届いたメールを読ませる。「閲覧と要約だけで、社内システムは操作させない」と聞けば、影響は小さく見える。ところが、その文章の中に、利用者の依頼とは別の指示が埋め込まれていたらどうだろう。AIにとっては、調査対象の文章も入力の一部である。
この話題では、「攻撃が見つかった」「実験で動いた」「被害が起きた」が一続きに語られやすい。だが、三つは証拠が違う。公開Webで不審な文が見つかっても、AIが従ったとは限らない。限定した実験で動作しても、同じ条件が自社にあるとは限らない。損害の可能性を説明した場面も、実際の被害報告とは限らない。
外部情報に紛れた指示の報告は、見つかった試み、成立条件の実証、確認された被害を分けて読む。そのうえで、自社のAIが何を読み、どこまで操作できるかへ問いを戻す。
「何が起きたか」を一段ずつ読む
最初に、記事や調査報告の記述を四つに仕分ける。
- 観測：Webページやメールなどに、AIへ働きかける文が存在した
- 研究・検証：特定の製品、設定、手順で、その文に従う動作を再現した
- 実被害：情報流出、削除、誤送信、金銭損失などが実際に確認された
- 将来予測や説明例：起こり得る影響を示すために、報告者が可能性を述べた
これは危険を小さく見せるための区別ではない。対策を選ぶための区別である。観測だけなら、まず自社の入力経路に似たものがあるかを探す。実証なら、製品、版、権限、操作手順が自社と重なるかを確かめる。実被害なら、侵入経路、影響範囲、復旧状況まで追う。予測なら、発生事実として引用せず、検討するシナリオに置く。
自分の確認メモには、強い見出しだけを転記しない。「観測対象」「確認方法」「成功を確認したか」「損害を確認したか」「調査に含まれない範囲」を一組で載せる。分からない欄は空白にせず、「資料では確認できない」と書く。証拠がないことと、起きていないことも同じではないからだ。
公開Webの観測は、攻撃成功率ではない
Googleの公開Webにおける調査 は、英語圏の公開Webを収録したCommon Crawlを対象に、間接プロンプトインジェクションらしい文を探索したものだ。候補をパターンで抽出し、分類を経て、人が確認する方法を説明している。調査では、宣伝、AIによる取得の妨害、データ持ち出しや破壊を狙うような文が観測された。
ただし、資料自身が対象範囲と限界を示している。ログインが必要な多くのSNSなどは対象外で、抽出方法は珍しい書き方を見落とし得る。検出された文には研究や教育目的の記述も多く、誤検出を減らす工程が必要だった。データ持ち出しを狙う例には、サイト作成者による実験と判断されたものも含まれる。破壊を促す例についても、Googleは成功しにくい単純な指示と評価している。
したがって、この調査から言えるのは、公開WebにAIへの働きかけを試みる文が置かれている、という観測である。検出数や増減を、自社AIが操作される確率、情報が流出した件数、利用者が受けた損害の割合へ置き換えることはできない。
「悪意をうかがわせる文があった」と「その文でAIが動き、被害が出た」の間には、動作と影響を確かめる工程が残る。
推薦を操る試みと、説明用の損失場面を分ける
MicrosoftのAI Recommendation Poisoningの報告 は、「AIで要約する」と見せたリンクなどに、将来の推薦へ影響させようとする指示が埋め込まれていた事例を調べている。同社は、メール通信で観測したAI向けURLと公開Web上のパターンを分析し、複数の企業による宣伝目的の試みを報告した。一方で、効果や持続性は対象サービスと時期により異なるとも述べている。
記事に登場するCFOが推薦に従って多額の契約を結ぶ場面は、影響を説明するための想定である。同じ記事の「現実に観測した試み」と混ぜて、実際の財務被害として紹介してはいけない。健康、投資、子どもの安全などの場面も、起こり得る結果を考える材料であり、確認済みの被害一覧ではない。
この区別から、自社では二つの問いを作れる。一つは、社員が外部の「AIで開く」「AIで要約」といったリンクから、どの情報をAIへ渡すのか。もう一つは、AIの記憶や推薦結果が、仕入先選定や承認資料へどのように使われるのかである。推薦結果を複数資料で検証する、重要な選定理由を原典へ戻す、保存された記憶を確認・削除できるか調べる、といった運用は、実被害率を推測しなくても決められる。
危険は「読む内容」と「使える権限」の組合せで変わる
外部の文章を読ませることだけで、必ず大きな被害になるわけではない。AIが従ってしまう可能性に加え、そのAIが何を参照でき、どんな操作を実行できるかで結果が変わる。公開Webの要約しかできないAIと、社内ファイルを検索し、メールを送り、台帳を書き換えられるAIでは、同じ不審な文を読んだ後の到達範囲が違う。
OWASP Top 10 for Agentic Applications 2026 は、行動するAIについて、目標や指示の乗っ取り、ツールの悪用、権限、記憶、外部との連携などのリスクを整理した実務資料である。すべての製品で事故が起きたという統計でも、個別サービスの安全性を認定する資料でもない。自社の構成を点検する見取り図として使うのがよい。
まず、自分が使う構成でAIが読む入口を列挙する。Web、メール本文、添付、社内検索、取引先の文書、会話履歴である。次に、AIが使える出口を列挙する。画面への表示、ファイル保存、社内検索、社外送信、登録、変更、削除である。入口と出口を一枚にし、外部の未確認情報を読む経路から、高い影響を持つ出口へ直接届かないようにする。
外部情報を読む機能と、送信・更新・削除の権限を同じ承認で渡さない。出力は下書きとして受け、人の確認や、AIの判断とは別に定めた規則による検証を経てから実行へ進める。
自分のAIが読む情報と、実行できる操作を確かめる
自分が作るAIの構成について、読む情報、参照できる社内情報、呼び出せる操作、実行前の確認、外部通信、記録、停止の相談先を書き出す。「攻撃が増えているようだ」で終えず、報告と重なる経路があるかを確かめる。分からない設定は推測せず、管理担当へ確認する。
最初の利用は、公開情報の要約、外部送信なし、更新権限なし、結果は人が確認、というように狭くできる。不審な指示を見つけたら、入力元、AIの出力、呼び出そうとした操作、実際に実行された操作を分けて残す。単に「プロンプトインジェクションを検知」と記録するだけでは、試みで止まったのか、動作したのか、影響が出たのかを後で判断できない。
読み取りだけの利用でも、要約や推薦が人の判断を誤らせる経路は残る。操作権限を外せば報告内容も信用できる、という関係ではない。仕入先や契約の選定に使うなら、推薦理由を原資料と照合する担当を残す。
利用範囲を広げるときは、報告記事の件数ではなく、自社で確認した事実を使う。未確認の入力で重要操作が起動しないこと、許可外のデータへ届かないこと、実行前に内容と送信先を確認できること、ログから操作を追えること、停止方法を担当者が試したことを確かめる。ここまで具体化すれば、外部の報告を過大評価も過小評価もせず、導入条件へ変えられる。
攻撃の報道を、自社のAIが読める情報と動かせる操作に照らす
外部情報には、読む人向けの内容と、AIへ働きかける指示が同居し得る。その事実を知るだけでは、利用を止めるにも進めるにも足りない。
自分のAIが読む入口を一つ選び、そこから表示・送信・更新のどこへつながるかを確かめる。報告で確認された試みと、自分の環境で確認できた動作を混ぜない。設定や停止方法を変える必要があれば、担当と許可された範囲で進める。外部の報告は、その一件を調べる材料にできる。