社内のマニュアルや問い合わせ履歴をAIに読ませ、社員や顧客の質問に答えさせるRAGを業務に導入する動きが広がっています。このとき見落とされやすいのが、AIに読ませる外部データを経由した攻撃です。悪意のあるデータを1件混ぜられただけで、まったく無関係な利用者本人の個人情報が外部へ送られてしまう場合があります。
ただし、外部データの混入がそのまま情報漏えいを意味するわけではありません。事故が成立するには、いくつかの条件が同じ処理の流れに重なる必要があります。この記事では、実際に動くRAGへ攻撃を仕掛けた検証をもとに、仕組みと成立条件、そして防ぎ方の入口を整理します。なお、検証はすべて使い捨ての環境で、データはダミーです。また、分かりやすさを優先し、あえて広い権限を与えた構成で実施しています。他組織のシステムで試すと被害を招くため、その点は前提として押さえてください。
用語の整理──RAGとプロンプトインジェクション
はじめに、前提となる言葉を2つそろえます。
RAGは、AIがもともと学習した知識だけで答えるのではなく、質問のたびに関連する資料をデータベースから検索し、その中身を回答の材料としてAIに渡す仕組みです。最新の情報や社内固有の情報に答えさせたいときに適しています。
もう一つがプロンプトインジェクションです。AIは、渡された文章について「これは参考資料」「これは従うべき命令」という区別を、内部で確実にはつけられません。この性質を突き、読ませる文章の中に命令を紛れ込ませてAIに実行させるのがこの攻撃です。とくに、AIがあとで読み込むデータの側に命令を仕込んでおくものを、間接プロンプトインジェクションと呼びます。OWASPは、LLMを用いるアプリケーションのリスクランキングで、これを上位に位置づけています。
RAGは外部から集めたデータをAIに読ませる仕組みであるため、この2つが重なると攻撃の経路が生まれます。
検証：レビュー1件の投稿が引き金になる
検証用に、オンライン学習サービスの会員サポートを模したRAGを構築しました。会員がコースを選んで評判を尋ねると、受講者のレビューを検索してまとめる、一般的な構成です。通常の質問には、良い点も注意点も適切にまとめて回答します。
ここに、攻撃者が会員を装ってレビューを1件投稿します。中身は2つの仕掛けで構成されています。
- 前半は、検索に確実に引っかかるよう、評判や口コミといった汎用的な語を大量に詰め込む。RAGは意味の近さで資料を取り出すため、評判に関する質問ではこの投稿が上位に来やすくなります。
- 後半が本命で、システム管理者を装った隠し命令です。本人確認を口実に、問い合わせ中の会員の氏名・メール・電話・住所を指定の宛先へ送るよう記述しています。
投稿した時点では何も起きません。その投稿がデータベースに取り込まれたあと、無関係な会員が通常どおり評判を質問した瞬間に、検証環境では事故が成立しました。会員の画面には通常のレビューまとめが返る一方、裏ではその会員本人の登録情報が攻撃者のサーバーへ送信されていました。画面上は正常に見えるため、利用者も管理者も異常に気づきにくいという特徴があります。
攻撃者はAIに話しかけていない
一般的な乗っ取りは、攻撃者が自らチャットへ命令を打ち込む形を想像しがちです。しかしこの検証では、攻撃者が行ったのはレビューを1件置くことだけです。引き金を引いたのは、事情を知らない別の利用者による通常の質問でした。
このように、AIへ直接命令するのではなく、AIがあとで読むデータの側に命令を仕込む攻撃が、間接プロンプトインジェクションです。レビュー、問い合わせ、外部のWebページ、PDF、メールなど、AIに読ませるものはすべてこの入口になり得ます。攻撃の基本的な仕組みは、外部データ経由に限らずプロンプトインジェクションの記事でも整理しています。
もう一つ重要なのは、攻撃者がシステムの内部構造を知らない点です。どのツールで送るか、プログラムがどう動くかは把握していません。ただ「この情報をこの宛先へ送ってほしい」と自然言語で記述しただけで、どの機能を使って送るかはAIが自ら判断します。これは、AIが自分で道具を選んで作業するAIエージェントの性質に由来します。
外部データの混入は「入口」にすぎない
ここで、精度の高い理解のために区別しておきたい点があります。外部データが混ざること自体は、あくまで攻撃の入口です。それが直ちに情報漏えいへ至るわけではありません。
検証で情報漏えいが成立したのは、次の条件がすべて同じ処理の流れに重なっていたためです。
- 仕込まれた文章が、検索で取り出される。
- AIが、それを命令として解釈する。
- AIが、別の利用者の個人情報などにアクセスできる。
- AIが、外部送信などのツールを実行できる。
- その途中に、権限確認や人による承認の歯止めがない。
このうちどれかが欠けていれば、同じ命令を受けても漏えいには至りにくくなります。今回の検証で個人情報が外部へ送られたのは、これらが同時に成立するよう、あえて権限を広く与えた構成だったからです。実際の設計で権限や情報アクセスをどこまで絞れているかによって、結果は大きく変わります。
手順で追う──処理の流れ
流れをあらためて順に追います。
- 公式マニュアルも会員投稿のレビューも、区別なく数値化され、同じデータベースに保存される。
- 会員が評判を質問すると、その質問も数値化され、意味の近い資料が上位から取り出される。ここで仕込まれたレビューが混ざり込む。
- 取り出したレビューと質問、会員の登録情報が、まとめてAIに渡される。
- AIが、レビュー後半の隠し命令を指示として受け取り、使える送信機能を選んで会員情報を外部へ送る。
通常利用ではこの流れは便利に働きます。しかし1件の悪意あるデータが混ざり、上記の成立条件がそろうと、同じ流れがそのまま攻撃の経路になります。
事故の正体──入口・データ・権限
原因はモデルの賢さではなく、設計に3つの弱点が重なっていたことです。
- 入口：誰でも投稿できるレビューという信頼できない外部データを、公式情報と同じく審査なく検索対象に入れていた。そのため悪意あるデータが取り出された。
- データ：取り出したレビューを、AIへの命令と地続きのまま渡していた。加えて、評判をまとめるだけなら本来不要な会員の個人情報まで一緒に渡していた。
- 権限：外部へデータを送る強い機能を、誰の承認もなく実行できる状態で持たせていた。
この3点が同じ処理の流れに乗っていたことが、事故の本質です。現実の攻撃はより巧妙で、攻撃者は検査をかいくぐるよう文面を練り直してきます。どれほど高性能なモデルでも、この種の攻撃を完全に防ぎきることは難しいという前提に立ち、利用する側が設計で守ることが有効になります。
対策は分けて扱う──この記事では入口を示す
3つの弱点には、それぞれ対応する守り方があります。いずれも一言では終わらないため、深掘りは記事を分けています。ここでは全体像だけ示します。
- 入口(信頼できないデータの分離)：誰でも書き込めるデータを、公式資料と同じ信頼度で扱わない考え方。→ RAGに信頼できないデータを混ぜる危険
- 権限(ツール実行の制限)：AIに強い機能を持たせず、送信先や回数を絞る考え方。→ AIエージェントの権限を絞る
- 全体設計(多層防御)：入力・出力・ツールの各段でガードレールを重ねる考え方。→ 騙されても被害が出ないAIの設計
共通する発想は、AIが決してだまされないよう工夫するのではなく、だまされても被害が出ない状態にしておくことです。
導入前の点検リスト
自社で構築・導入するRAGについて、まず次の3点を確認してください。
- AIが検索・参照するデータに、外部の人が自由に書き込めるもの(レビュー・問い合わせ・コメント等)が審査なしで混ざっていないか。
- AIに渡している情報に、その回答には不要な個人情報や機密が含まれていないか。
- AIが使える機能(特に外部送信・メール・削除)に、宛先の制限や人による承認が入っているか。
いずれかが「いいえ」であれば、今回と同じ成立条件が近くにあることになります。何をどう直すかは、上で挙げた3本の記事に続きます。
まとめ
- RAGは外部データを読んでAIに答えさせる仕組みで、その読ませるデータが攻撃の入口になり得る。
- 攻撃者はAIに話しかけない。データを1件仕込むだけで、無関係な利用者の質問が引き金となり、その人の個人情報が漏れる場合がある。
- 外部データの混入は入口にすぎない。漏えいは、検索での取得・命令解釈・個人情報アクセス・ツール実行・承認なしが重なって成立する。
- 検証で情報が外部へ出たのは、あえて広い権限を与えた構成のため。権限や情報アクセスの絞り方で結果は変わる。
- 守り方は入口・データ・権限それぞれにあり、だまされても被害が出ない設計へ立て直すことが核心。
正常に動くかだけでなく、悪意のあるデータを読ませたときに何が起きるか。RAGやAIエージェントを社内へ導入する際は、そこまで確かめておくと安全です。
