プロンプトインジェクションの事例を読む　公表された被害と共通点を整理

公表されたプロンプトインジェクションの事例には、メールやWebページなど外部の文章をAIに読ませ、そのAIが社内データや操作の権限を持っていた、という共通点があります。私たちが確かめた範囲では、公式の報告の中心は弱点の発見と修正で、企業の被害額を示す例は見つかりませんでした。

今日は、社内のAIのうち「外から届いた文書やメールを読むもの⁠」⁠を書き出し、それぞれが見られる社内データを横に書いてください。この一覧が、事例を自社に当てはめる材料になります。

プロンプトインジェクションの事例はどう読むのか

OWASPは、Webサイトやファイルなど外部からの入力によってAIの動きが変わるものを、間接プロンプトインジェクションと説明しています。IPAの情報セキュリティ10大脅威 2026の解説書も、AIが動作の過程で参照したデータに不正なプロンプトが含まれる攻撃を指す言葉として説明しています。

事例を読むときは、次の3つ⁠を分けます。報道の見出しだけでは、この差が分かりません。

• 研究者が弱点を見つけて報告した例（実際の被害は書かれていないことが多い）
• Web上で攻撃の仕込みが観測された例（意図は分かるが、被害額までは分からない）
• 特定の企業で被害が確認された例（確かめた範囲では見つからなかった）

報告の多くは、セキュリティ製品を扱う会社の調査です。事実の価値は変わりませんが、製品の宣伝と隣り合わせであることは意識して読みます。

確かめられる報告を並べる

入口と、触れる恐れがあったものを表にしました。攻撃の手順には触れず、守る側に要る部分だけを書きます。

メールを読むAI：EchoLeak

2025年6月⁠に報じられたMicrosoft 365 Copilotの弱点です。IPAの解説書は、メールなどに含まれる不可視のプロンプトをAIに読み込ませ、利用者の操作なしに秘密情報を外部へ送らせるものと説明しています。

Microsoftのセキュリティ更新プログラムガイドは、CVE-2025-32711として深刻度を緊急、CVSSを9.3としています。同じページには、この脆弱性を解決するためにお客様が取るべきアクションはないと書かれています。サービス側で対応された例です。

研究者の論文は、これを本番のシステムに対する実証の事例として分析しています。読み取れるのは「起こり得た」ことで、確かめた資料に、実際に情報が流出した会社は書かれていません。

問い合わせフォームを読むAI：ForcedLeak

調査会社Noma Labsが2025年9月⁠に公表した報告です。Salesforce Agentforceで、外部の人が情報を送れるWeb-to-Leadの機能に細工した内容を入れると、社員がAIに処理させたときに、CRMのデータが外へ出る恐れがあったとしています。

深刻度のCVSS 9.4は、発見した会社が示す数字です。同じ報告は、Salesforceが2025年9月8日⁠に信頼できるURLの制限を実施したとしています。

製造業の読者には、この例が身近かもしれません。展示会の名刺や問い合わせを取り込む流れは、BtoBの営業でよく使われるからです。

Webページを読むAI：Comet

Braveが2025年8月⁠に公開した報告です。AIブラウザのCometがページを要約するとき、利用者の指示とWebページの内容を区別できず、掲示板の投稿に隠された指示に従ってしまう実証を示しました。

修正の経過も参考になります。Braveの時系列では、7月⁠に報告して修正が入ったものの再検証で不完全と分かり、公開後の追記でも、まだ完全には緩和されていないとして再報告したと書かれています。これは報告した時点の記述で、現在の状態を示すものではありません。修正が一度で終わるとは限らない、という読み方に留めます。

開発の道具：Cursor

IPAの解説書は、AIコードエディタCursorで、プロジェクト内のREADMEなどのファイルに悪意のある指示を埋め込み、開発者の権限でコードを実行させる弱点が見つかったと紹介しています。文書を読むだけの道具に見えても、実行の権限があれば影響が変わる例です。

Web上での観測はどこまで分かっているのか

弱点の報告とは別に、実際のWebを調べた報告もあります。

Palo Alto NetworksのUnit 42は、2026年3月の報告で、自社の観測データからWeb上の間接プロンプトインジェクションを分析しました。22の手法を確認し、広告審査の回避や、フィッシングサイトを宣伝する検索順位の操作などの意図を挙げています。

学術面では、2026年4月⁠に投稿された論文が、12億のURLを調べて、1万1,700ページから1万5,300件⁠を確認したとしています。5,200回⁠の実験では、従う割合は限定的で、小さなモデルの条件で最大8%でした。論文は実害の大きさを断定せず、Web上に実際に存在し、緊張の種になりつつあるとまとめています。

共通点は3つそろっていること

ここまでの例を並べると、次の3つ⁠がそろっています。

どれか1つでも欠ければ、同じ形の被害にはなりにくいと言えます。OWASPも、影響の大きさはAIの持つ権限に左右されるとしています。要約だけをする孤立したAIと、メールも顧客データも触れるAIでは、同じ細工でも結果が違います。

たとえば部品メーカーが、取引先から届く仕様書のPDFをAIに要約させ、そのAIが社内の図面フォルダも検索できる場合を考えます。外部の文章を読むことと社内データを見ることの2つ⁠がそろいます。さらに、AIがメールを送れる、外部の画像やリンクを自動で読み込むなら、3つ目もそろいます。

この場合に見直すのは、PDFを読むAIと図面フォルダを検索するAIを分けられないか、外部へ送る操作に人の承認を挟めないか、の2点です。

製品が修正されても点検が残る理由

弱点が修正された事例を見て、「更新すれば安心」⁠と⁠は言い切れません。IPAの解説書は、AIが不正なプロンプトを見分ける技術的対策で完璧なものは知られていないとしています。

英国のサイバーセキュリティ機関NCSCも、AIにはデータと指示の本質的な区別がなく、完全には緩和できない可能性に触れています。そのうえで、リスクと影響を減らす方向で考えることを求めています。

OWASPが挙げる対策は、権限を必要最小限に絞る、影響の大きい操作に人の承認を挟む、外部の内容を分けて扱う、攻撃を想定した試験をする、などです。私たちが社内のAIを見るなら、この順に点検します。

1. 外部の文章を読むAIの一覧を作る
2. それぞれの権限を、業務に必要な範囲まで減らす
3. 送信、削除、支払いなど戻せない操作に、人の確認を入れる
4. AIの入出力の記録が残るか、誰が見るかを決める
5. 提供元のセキュリティ情報を受け取る担当を決める

ブラウザにAIが組み込まれている場合は、業務のログイン状態を見られるかも確かめます。業務のWebシステムを切り分ける方法は、セキュアブラウザの比較で種類を見られます。機密情報が外へ出る経路を見張るには、DLPの製品比較が参考になります。自社のAIアプリを守る製品は、AIセキュリティ製品の比較で整理されています。製品の選び方はAIセキュリティ企業の比較の見方に、社員の利用を把握する手順はシャドーAI対策の進め方⁠に書きました。

AI全体のリスクはAIセキュリティの記事一覧⁠にまとめています。事例を読むときは社名や深刻度の数字より、自社にも同じ3つ⁠の条件がそろっているかを見てください。そろっていなければ、慌てて製品を買う必要はありません。そろっているなら、権限を減らす作業から始められます。