社内文書を検索して生成AIに答えさせる「RAG」を業務に入れた組織にとって、検索対象のインデックスに攻撃者が数件の文書を紛れ込ませるだけで、AIの回答を意図した内容にすり替えられる——これがRAGポイズニングです。2026年8月13日にarXivで公開された査読前の研究が、この毒入り文書を「正解ラベルも信頼できる参照コーパスも使わずに」検知する手法を提案しました。実測では攻撃成功率を67.4%から14.0%まで下げています。ただし、残る14%と「正常文書の5%を巻き添えで消す」という代償の読み方が実務では肝心です。
この記事でわかること
- RAGポイズニングが「自社にも起こりうる」と言える条件（脅威モデル）
- 提案手法RAGSieveの仕組み（検索時のRSQ／コーパス側のRSG）
- 攻撃成功率67.4%→14.0%という数字の正しい読み方と代償
- 情シスが今日から着手できるインデックスの棚卸しと、参照すべき公的指針
RAGポイズニングとは何か
RAGポイズニングとは、生成AIが参照する検索対象（社内Wiki・共有フォルダ・ベクトルDBなど）に細工した文書を投入し、AIの回答を攻撃者の望む内容に誘導する攻撃です。モデル本体もプロンプトも改ざんしません。触るのは「AIが読みに行く資料」だけです。
「うちは大丈夫」と即断しにくいのは、この攻撃に必要な権限が驚くほど低いからです。今回の論文が置く脅威モデルは、攻撃者を「コンテンツを投稿できる立場の人」——つまり社内Wikiに書き込める従業員、共同編集できる委託先、あるいはRAGが取り込んでいる外部フィードの発信者——と想定しています。管理者権限もサーバ侵入も要りません。ターゲットにしたい質問1件あたり、投入する文書は最大5件です。
言い換えると、RAGの検索対象に「不特定多数が書き込める場所」を1つでも含めていれば、この攻撃の前提条件は成立しているということになります。攻撃の全体像はRAGポイズニングとは？AIエージェントを乗っ取る攻撃で詳しく整理しています。
どんな研究か
一文で言えば、「毒入り文書のラベルも、汚染されていないことが保証された参照コーパスも持たないまま、検査対象のRAGシステム自身の中から比較基準を作り出して毒を炙り出す」検知フレームワークを提案・評価した研究です。手法名はRAGSieve（RAG＋ふるい）。
本論文はarXivに投稿された査読前（プレプリント）であり、結果は今後の査読や追試で変わりうる点に留意してください。
| 項目 | 内容 |
|---|---|
| 論文 | RAGSieve: Self-Referenced Local Contrast for Knowledge-Poison Detection in Retrieval-Augmented Generation |
| 著者 | Xinlong Xu、Yoshua Y. Li |
| 公開日 | 2026年8月13日（arXiv:2608.13010、査読前） |
| 評価データ | Natural Questions（約12.8万文書）、HotpotQA、MS MARCO。各1,000問中100問を攻撃対象に設定 |
| 再現した攻撃 | PoisonedRAG（ブラックボックス／ホワイトボックス）、CEM（連続型・分散型）、CPA-RAG、CamoDocs の計6構成 |
| 検索モデル | BGE-M3、E5-large-v2、all-MiniLM-L6-v2 |
| 生成モデル | deepseek-v4-flash |
既存の検知手法（論文中ではGMTPやCleanBaseと比較）は、「汚染されていない正解コーパス」や「特定の攻撃が残す痕跡」に依存していました。実務で困るのはまさにそこです。自社のRAGインデックスが「汚染前」の状態でスナップショットを取ってあることは、まずありません。この研究が「自己参照」にこだわったのは、その実務ギャップを埋めるためです。
RAGSieveはどう検知するのか
手法は2つの部品に分かれており、見ている場所が違います。
RSQ：検索したその場で、6〜20位を物差しにする
RAGは通常、検索結果の上位数件だけをAIに渡します。RSQ（RAGSieve-Query）は、AIに渡す上位5件と、渡されない6〜20位の文書群とを引き比べます。毒入り文書は「特定の質問で必ず上位に来て、特定の答えを押し出す」ように作られているため、上位5件の答えが不自然に一点集中していたり、6〜20位の顔ぶれと傾向が断絶していたりする。この局所的なコントラストを異常として捉える発想です。物差しを外部から持ってこず、同じ検索結果の下位から調達するので「自己参照」と呼ばれます。
RSG：コーパス全体で、不自然な密集を探す
RSG（RAGSieve-Graph）はインデックス全体を対象に、「意味は似ているのに使っている単語が違う文書」が一箇所に密集していないかを監視します。毒入り文書は検索に引っかかるよう同じ主張を言い換えて複数投入されることが多く、その痕跡が意味空間上の密度異常として現れる、という理屈です。
検知精度と処理コスト
結論から言うと、RSQ・RSGを併用した構成で攻撃成功率（ASR）は67.4%から14.0%に低下しました。個別の性能は下表のとおりです。
| 手法 | AUROC | 毒文書の検出率 | 処理コスト |
|---|---|---|---|
| RSQ（検索時） | 95.2% | 82.2% | 1問あたり447.3ミリ秒 |
| RSG（コーパス側） | 93.3% | 79.8% | 約12.8万文書で46.5秒（1文書0.362ミリ秒） |
この検出率は「正常な文書の除去を5%以内に抑える」という運用条件のもとでの値です。ここが実務で一番効いてきます。処理速度は既存手法CleanBaseの約5.6倍で、12.8万文書のスキャンが1分未満というのは、夜間バッチで日次回せる水準です。
現場目線の課題
数字の見栄えは良いのですが、運用側に立つと引っかかる点が3つあります。
第一に、「正常文書の5%を犠牲にする」の重さです。12.8万文書のインデックスなら、およそ6,400件の正常な社内文書が検索対象から落ちる、あるいは要確認として上がってくる計算になります。落ちた文書がたまたま就業規則や手順書だった場合、利用者には「AIが答えられなくなった」としか見えません。検知率と業務影響のトレードオフを、誰がどの基準で決めるのか——ここを詰めずに導入すると、まず現場から不満が出ます。
第二に、残る14%をどう説明するかです。67.4%が14.0%になったのは大きな前進ですが、裏を返せば7回に1回は攻撃が通ります。経営層や監査に対して「AIの回答は信頼できます」とは言えない水準です。RAGの回答をそのまま業務判断に使わせず、出典文書を必ず併記して人が確認できる導線を残す——という設計上の割り切りは、検知手法を入れても外せないと考えます。
第三に、論文が明記する検知の穴です。RSGは「自然な文章の毒が1件だけ」だと材料が乏しく弱い。RSQは「6〜20位にも毒が多数混じっている」と物差し側が汚染されて機能が落ちる。そして埋め込みを最適化して滑らかな文章を作るCPA-RAG攻撃に対して、最も高い攻撃成功率が残ったとされています。攻撃者が「静かに、少しずつ」入れてくるほど見つけにくいという構造は、そのまま内部犯行の検知の難しさと重なります。
正直なところ、限られた人員で社内Wikiの全編集履歴に目を通すのは不可能です。だからこそ、検知を仕組みに寄せる方向性そのものは正しい。ただし今回の数字は英語のオープンQAデータセットでの値であり、日本語の社内文書——表記ゆれが激しく、同じ内容の文書が部署ごとに何通りも存在する環境——で同じ密度異常検知が効くかは未検証です。「意味は似ているが語彙が違う文書の密集」は、日本語の社内文書では正常状態でも普通に起きます。誤検知率がこのまま収まるとは考えないほうが安全です。
情シスはどうすべきか
RAGSieve自体は研究段階なので、今すぐ導入する話ではありません。ただしこの研究が突いた問い——「うちのRAGは、誰が書いたものを読んでいるのか」——は今日から答えられるはずです。まずはRAGの検索対象に含めたデータソースを列挙し、それぞれについて「誰が書き込めるか」「外部から自動取り込みしていないか」「投入時の承認フローはあるか」を確認するところから始めるのが現実的です。書き込み権限の棚卸しは、AI固有の話ではなく既存のアクセス管理の延長で着手できます。
対策の枠組みは自前で作るより、公的な整理に沿わせるほうが確実で、社内説明もしやすくなります。
- IPA「AIセキュリティ」 … 「AI利用者のためのセキュリティ豆知識」「AIシステムに対する既知の攻撃と影響」など、日本語で読める入口。社内共有の最初の1本に向きます。
- IPAテクニカルウォッチ「AI利用時のセキュリティ脅威・リスク調査報告書」 … 課題認識は6割超なのに規則整備は2割未満、というギャップが示されています。稟議で「他社も未整備だから後回し」を封じる材料に使えます。
- NIST AI 100-2 E2025「Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations」 … RAGナレッジベースのポイズニングを攻撃分類として正面から扱っています。設計レビューの観点表を作るときの下敷きに。
- OWASP「LLM04:2025 Data and Model Poisoning」 … 技術者向けのチェック観点として。データ供給元の検証と出所管理が中心に置かれています。
- IPA「対策のしおり」 … 利用者側の啓発教材。「AIの回答を鵜呑みにしない」を現場に定着させる地道な教育は、技術的検知と同じくらい効きます。
関連して、社内RAGで「外部LLM事業者に何が渡っているか」という別方向のリスクは社内RAGの機密を外部LLMから隠す｜研究解説を、AIが読んだ内容によって挙動が変わる攻撃の系譜はプロンプトインジェクションの死角「状態汚染」攻撃を、基盤側の脆弱性管理についてはNVIDIA Dynamoに15件脆弱性。社内LLM基盤の確認急げも併せてご確認ください。
まとめ
- RAGポイズニングの前提条件は「検索対象に書き込める人がいること」だけ。管理者権限も侵入も不要で、質問1件あたり最大5文書の投入で成立します。自社インデックスのデータソースと書き込み権限の棚卸しが先決です。
- RAGSieveは正解ラベルも無汚染コーパスも使わず、検索結果の下位やコーパス内の密度異常を物差しにする手法。AUROCは93〜95%、併用で攻撃成功率を67.4%から14.0%に低減しました。
- ただし代償は「正常文書の5%除去」、そして7回に1回は攻撃が通る点に注意。査読前かつ英語データセットでの検証であり、表記ゆれの多い日本語の社内文書では誤検知が増える可能性があります。RAGの回答に出典を併記して人が検証できる導線は、検知手法を入れても残してください。
出典
- Xinlong Xu, Yoshua Y. Li, “RAGSieve: Self-Referenced Local Contrast for Knowledge-Poison Detection in Retrieval-Augmented Generation”, arXiv:2608.13010（2026年8月13日、査読前）
- NIST AI 100-2 E2025, Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations
- OWASP Gen AI Security Project「LLM04:2025 Data and Model Poisoning」
- IPA「AIセキュリティ」
- IPAテクニカルウォッチ「AI利用時のセキュリティ脅威・リスク調査報告書」（2024年7月4日）
