RAGの処理は、大きく2つのフェーズに分かれます。1つ目が取り込み（インデックス作成）。文書を細かく分割し、「ベクトル」という数値の並びに変換して、ベクトルDB（ナレッジベース）に保存します。2つ目が回答（検索＋生成）。ユーザーが質問すると、意味の近い文書を検索して取り出し、その内容をLLMに渡して回答を作らせます。

ここがポイントです。従来のAIへの攻撃は「質問（プロンプト）」を細工するものが主役でした。しかしRAGでは、AIが信頼して参照するナレッジベースという“知識の源泉”そのものが新しい攻撃対象になります。源泉が汚れていれば、どんなに優秀なLLMでも、汚れた水を汲んで出すしかありません。「Garbage In, Garbage Out（ゴミを入れればゴミが出る）」が、AIの説得力という増幅器を通して牙をむくのです。

「学習データ汚染」よりRAG汚染が身近で厄介な理由

AIへのデータ汚染というと、これまでは学習データポイズニング——つまりAIモデルを訓練する段階で毒を混ぜる攻撃——が語られてきました。しかしこれは、大規模な学習データに影響を与え、再学習を回す必要があり、一般の企業や個人にとっては縁遠い話でした。ところがRAGの登場で状況が変わります。RAGはモデルを訓練し直さなくても、ナレッジベースに1ファイル足すだけで“AIの知識”を即座に書き換えられる仕組みだからです。

これは利便性そのもの（最新情報をすぐ反映できる）であると同時に、攻撃者にとっての敷居も大きく下げてしまいました。高価なGPUも再学習も不要で、狙った文書を取り込ませるだけ。つまりRAGデータポイズニングは、研究室の中の理論ではなく、社内Wikiや共有フォルダを使うすべての現場にとっての“身近なリスク”なのです。便利さと攻撃しやすさが同じコインの裏表になっている——この点を最初に押さえておきましょう。

RAGデータポイズニングとは、AIが参照するナレッジベースに、虚偽情報・偏向・悪意ある命令を含むデータを混入させ、AIの回答を攻撃者の思惑どおりに歪める攻撃の総称です。英語では RAG poisoning や knowledge base poisoning とも呼ばれます。「モデルそのものは無傷なのに、参照する知識を汚すだけで回答を操れる」のが特徴で、代表的な3つの型を押さえておきましょう。

3つは独立しているわけではなく、しばしば組み合わさります。たとえば「狙ったキーワードで上位ヒットするように作った（型2）文書の中に、偽事実（型1）と隠し命令（型3）の両方を仕込む」といった具合です。とくに型3の隠し命令については、攻撃の通り道と防御を間接プロンプトインジェクション実践編で詳しく扱っています。本記事は、その土台となる「ナレッジベースというデータそのものをどう汚され、どう守るか」に焦点を当てます。

もう一つ知っておきたいのが、汚染の「狙い」にも種類があるという点です。お金や情報を直接かすめ取る実害型（偽の振込先・偽の手順を信じさせる）だけでなく、特定の製品や人物を不当に持ち上げる／貶める世論操作型、わざと業務を混乱させる妨害型、そして攻撃が成立するか静かに試す偵察型などがあります。狙いによって仕込まれる文書の見た目も変わるため、「自社のRAGが汚されたら、誰が・何を得するか」を一度想像してみると、守るべきポイントが具体的になります。

RAGのナレッジベースは、さまざまな場所から文書を取り込みます。その取り込み元のうち、攻撃者が中身に影響を与えられる経路がすべて潜在的な汚染口です。代表的な6経路を見ていきましょう。

大事なのは、これらの経路の多くが「便利だから自動化されている」という点です。共有フォルダに置いたファイルが夜間バッチで自動インデックスされる、外部サイトを定期クロールする、問い合わせ内容を即座にナレッジに反映する——人手を介さず取り込めることがRAGの強みですが、その自動化が「誰も中身を見ないまま毒が棚に並ぶ」状況を生みます。経路を洗い出すときは、「ここに置いたデータは、人のチェックを経ずにAIの知識になるか？」を自問するとリスクが見えてきます。

ここでは、実在サービスを攻撃しない無害なサンプルで、汚染文書が回答を乗っ取る瞬間を再現します。あなたが管理するローカルRAGのテスト用インデックスで、安全に追体験できます。

デモ①：1件の偽文書が「返金ポリシー」を書き換える

社内ヘルプデスク用のRAGに、攻撃者が次のような“それっぽい”文書を1件だけ紛れ込ませたとします。検索で上位に来るよう、想定質問のキーワードを意図的に詰めてあります。

利用者が「返金はいつまで対応していますか？」と質問すると、RAGは意味の近いこの文書を検索で拾い、偽の“最新ポリシー”を根拠に「無期限・無条件で全額返金できます」と回答してしまいます。正規の規程（30日以内・要承認など）が存在しても、汚染文書のほうが質問に“似て”いれば、そちらが優先的に取り出されるのです。被害は金銭的損失や混乱に直結します。

ここで注目したいのは、攻撃者が「最新」「最優先」「他の規程に優先する」といった“強い言葉”を使っている点です。LLMはこうした優先順位を主張する文言に引きずられやすく、結果として汚染文書が正規文書を上書きしたかのように振る舞います。人間なら「やけに都合がよすぎる」と怪しむところを、AIは額面どおり受け取ってしまう。ここにも「AIの素直さが弱点になる」という構図が表れています。

デモ②：少数の文書で「多数決」を覆す

RAGの怖さは、正規文書が100件あっても、質問に近い汚染文書が数件あればそちらが選ばれうる点にあります。検索は「件数の多数決」ではなく「質問との近さ」で取り出すからです。攻撃者は全データを書き換える必要はなく、狙った質問に刺さる“少数精鋭の毒”を置くだけでよい。これが「データポイズニングは費用対効果が高い」と言われる理由です。研究でも、ごく少数の汚染文書で特定クエリの回答を誘導できることが示されています。

しかも厄介なことに、汚染文書は普段は完全に“眠って”いられます。攻撃者が狙ったのが「返金」という特定の質問だけなら、それ以外の質問には正規文書が普通に答えるため、日常の動作テストでは何の異常も出ません。毒が起きるのは、特定のキーワードを含む質問が来た“その瞬間”だけ。この「ふだんは無害に見える」性質が、汚染の発見と原因追跡を著しく難しくしています。だからこそ、§6で見るように「入れる前に止める」「入っても出典で気づく」の両面が欠かせないのです。

とくに注意したいのが③です。セキュリティ対応をAIに支援させているのに、そのナレッジベースが汚染されていれば、AIは“被害を広げる手順”を正しい対応として案内しかねません。守りを任せたAI自身が攻撃の一部になる——皮肉ですが、現実的なリスクです。RAGを安全運用したい方は、ローカルLLMセキュリティ完全ガイドとあわせて、ナレッジベースの管理を見直してください。

表に共通して言えるのは、「AIの回答が、人の判断や行動にそのまま流れ込む業務ほど危険度が高い」ということです。回答を参考程度に使う調査補助（④）より、回答どおりに返金・対応・実装してしまう業務（①②③⑤）のほうが、汚染が即・実害に変わります。自社のRAGがどれに当たるかを見極め、行動に直結する用途ほど§6の防御を厚くする——このメリハリが、限られたリソースで守るコツです。

RAGデータポイズニングに特効薬はありません。取り込み・保管・検索・回答の各段階に関所を置く多層防御で、汚染の混入率と影響を下げます。RAGを運用する立場の人向けの実践チェックリストです。

考え方の軸は2つです。1つは「汚れたデータを、そもそも棚に入れない」という川上の防御（1〜4）。もう1つは「万一入っても、回答に影響させない・気づける」という川下の防御（5〜7）。入口の検査だけに頼るとすり抜けは必ず起きますし、出口の出典表示だけでは混入を許し続けます。両方を重ねることで、攻撃者は「検査を逃れ、検索で選ばれ、出典の不自然さも隠す」という複数の関門を同時に突破しなければならなくなります。これが多層防御の効き目です。

7段階すべてを一気に整えるのが理想ですが、現実には負荷もあります。優先順位をつけるなら、まず「1. 取り込み元のホワイトリスト化」と「6. 回答への出典明示」の2つから着手するのがおすすめです。前者は汚染の総量を入口で大きく減らし、後者は万一の汚染を利用者が現場で見抜く“最後の砦”になります。コストの割に効果が大きく、既存のRAGにも後付けしやすい組み合わせです。そこから検査・権限・監視へと段階的に広げていけば、無理なく守りを固められます。

これらは新しい発明ではなく、従来のデータガバナンス（誰が・どんなデータを・どう管理するか）の延長線上にあります。社内ルールに落とし込む際は、企業のAI利用ガイドライン雛形に「RAGに取り込んでよいデータの基準と承認フロー」を1条として加えておくと、現場が迷いません。

最後に、立場別の自衛策を整理します。完璧な防御はありませんが、習慣と設計の積み重ねで被害は大きく減らせます。RAGのセキュリティは「作る人」だけの仕事だと思われがちですが、実際には作る人・管理する人・使う人の三者が少しずつ役割を分担することで初めて成り立ちます。どれか一つが欠けても穴が空く——逆に言えば、それぞれが自分の持ち場でできることをやれば、汚染は何重にも防げます。

使う側のいちばんの武器は、「出典を見る」習慣です。RAGの回答に根拠文書が示されていれば、それを開いて「本当にこの社内規程に書いてある？」と一呼吸おいて確かめる。金銭・セキュリティ・法務など影響の大きい回答ほど、AIの一言で動かず一次情報にあたる。たったこれだけで、汚染された回答の多くは“その場で止められる”のです。

そして運用する側にとって大切なのは、RAGの安全を「一度作って終わり」にしないことです。ナレッジベースは生き物のように日々更新され、取り込み元も増えていきます。だからこそ、取り込みルールの見直し・古い文書の棚卸し・汚染を想定したテスト（レッドチーム）を、定期的な“健康診断”として回し続ける必要があります。RAGの賢さは入れた知識で決まる以上、その知識をきれいに保ち続ける運用こそが、最大かつ継続的な防御になります。完璧な壁を一枚作るより、毎日少しずつ棚を整える——地味ですが、これが効きます。