社内文書を検索して生成AIに答えさせる「RAG」を業務に入れる企業が増えています。しかし見落とされがちな穴があります。検索でヒットした社内文書は、そのまま外部のLLM事業者に送信されているという点です。2026年8月13日にarXivで公開された査読前の研究が、この問題に「機密の実体を別名に置き換えてから外部に渡す」という手法で挑みました。実測では機密の秘匿に成功したのは約85〜90%、ユーザーに正しい答えが返ったのは約80〜84%。有望ですが、そのまま統制として使える水準ではありません。
この記事でわかること
- 社内RAGで「外部LLM事業者に何が渡っているか」という見落としがちなリスクの構造
- 提案手法SEAGの仕組み（ローカルで別名化 → 外部で生成 → ローカルで復元）
- 実測値の読み方と、実務で採用を判断するときの限界・留保
- 情シスが今日から着手できる棚卸しと、参照すべき公的指針
どんな研究か
一文で言えば、「社内文書と質問文の機密部分を、意味の通る別名にすり替えてから外部LLMに投げ、返ってきた答えを手元で元に戻す」フレームワークを提案・評価した研究です。手法名はSEAG（Sensitive Entity Alias Generator、機密エンティティ別名生成器）。
なお本論文はarXivに投稿された査読前（プレプリント）であり、結果は今後の査読や追試で変わりうる点に留意してください。
| 項目 | 内容 |
|---|---|
| 論文 | Privacy-Preserving RAG by Concealing Sensitive Information from External LLMs |
| 著者 | Saleh Almohaimeed ほか5名 |
| 公開日 | 2026年8月13日（arXiv:2608.12675、査読前） |
| 分類 | cs.AI / cs.CR |
| ローカル側モデル | Qwen-3（4B）、LLaMA-3.2（3B）、Phi-4（3B）をQLoRAで微調整 |
| 外部側モデル | GPT-5、Claude-4 sonnet |
なぜ「外部LLMに見えている」ことが問題なのか
論文が指摘するのは、既存のRAGプライバシー研究の偏りです。これまでの関心は主に「権限のない利用者が機密文書を引き出せてしまう」ことに向いていました。しかしRAGの構成上、検索でヒットした文書と利用者の質問文は、生成を担当する外部LLM事業者にそのまま渡っています。攻撃者ではなく、正規の取引先が全部見ている、という構造です。
実務上ここが厄介なのは、契約で「入力データを学習に使わない」と取り付けても、リスクが消えたわけではないからです。ログの保持期間、サブプロセッサの範囲、保存リージョン、事業者側アカウントの侵害——いずれも「送らない」ことでしか根本的には潰せません。個人情報を含むプロンプトの入力については、個人情報保護委員会も利用目的の範囲内にとどめるよう注意喚起しています（出典参照）。
この論点は、RAGの情報漏えいは質問で変わる｜査読前の新研究で扱った「質問の仕方によって漏れる情報が変わる」問題とは別の面です。あちらが利用者側からの漏えい経路なら、今回は事業者側に渡る経路の話になります。入力内容が外部サービス経由で露出しうる例としては、VoiceTraに脆弱性、入力内容が漏れる恐れも参考になります。
SEAGはどう動くのか
肝は、マスキング（伏せ字）ではなく「別名（エイリアス）」への置換である点です。「××株式会社」を [MASK] に潰すと外部LLMは文脈を失って推論できません。そこで意味的に自然な架空の社名・人名に入れ替え、外部LLMには「普通の文書」として処理させます。外部LLM側は置換が行われたことに気づきません。
| 手順 | 処理場所 | 内容 |
|---|---|---|
| 1〜2 | 社内 | 利用者が質問し、リトリーバが社内データから関連文書を取得 |
| 3 | 社内 | 微調整済みの小型モデルが機密エンティティを特定し、「元の語→別名」の置換表を生成 |
| 4 | 社内 | 置換表を使い、質問文と取得文書の機密語を別名に置換 |
| 5 | 外部 | 別名化済みのプロンプトを外部LLM（GPT-5 / Claude-4 sonnet）に送信し、回答を生成 |
| 6 | 社内 | 置換表を逆引きし、回答中の別名を元の語に復元して利用者に返す |
復元は必ず手元で行われるため、外部LLMは最後まで実データに触れません。社内に置くのは3〜4B程度の小型モデルだけで済む設計になっており、この規模なら現実的なGPU1枚で動かせる範囲です。
評価データは6分野・計600問（300文書×各2問）を人手で作成し、「機密情報を使わないと答えられない質問」になるよう設計されています。うち4分野は微調整時に登場しない未知分野で、丸暗記では解けない条件になっています。
精度はどれくらいか
結論から言うと、機密の秘匿は約85〜90%、利用者への正答は約80〜84%です。評価は3指標で行われています。ORG（無加工のまま外部LLMに渡したときの正答率＝上限値）、Privacy（答えに必要な機密が外部LLMから隠せた割合）、User（隠したうえで復元後に利用者へ正答が届いた割合）です。
| 外部LLM | ローカルモデル | ORG | Privacy | User |
|---|---|---|---|---|
| Claude-4 sonnet | Qwen-3 | 99.33 | 88.83 | 83.00 |
| Claude-4 sonnet | LLaMA-3.2 | 99.33 | 89.67 | 83.67 |
| Claude-4 sonnet | Phi-4 | 99.33 | 87.17 | 81.17 |
| GPT-5 | Qwen-3 | 99.67 | 87.50 | 83.00 |
| GPT-5 | LLaMA-3.2 | 99.67 | 88.50 | 83.00 |
| GPT-5 | Phi-4 | 99.67 | 84.83 | 80.17 |
最良はLLaMA-3.2×Claude-4 sonnetの組み合わせ（Privacy 89.67%、User 83.67%）でした。また文書中の機密エンティティを一つ残らず隠しきれた割合は、Qwen-3が77.83%、LLaMA-3.2が76.73%、Phi-4が74.91%です。
この数字の読み方は慎重にしてください。ORGが99%台ということは、別名化によって失われた正答率は約16〜19ポイントということです。そして「全エンティティを隠せた割合が約75〜78%」は裏返すと、4文書に1文書は機密がどこか取りこぼされていることを意味します。
現場目線の課題
正直に言えば、この数字のまま社内統制として導入するのは難しいと感じます。情シスが機密の外部送信について経営層や監査に説明する場面で、「4回に1回は取りこぼします」という前提の仕組みは通しにくい。統制は「ほぼ効く」では足りず、効かなかったときに検知できるかまで問われるからです。
加えて、別名置換の長所がそのまま短所になる面があります。外部LLMから見て自然な文章に見えるということは、送信ログを人間が後から見ても「機密が混じっていた」ことに気づきにくいということです。伏せ字なら見れば分かりますが、架空の社名に化けていると、置換漏れとの区別が目視ではつきません。監査証跡の設計は別途必要になります。
一方で、比較の基準を「完璧」ではなく「現状」に置くと評価は変わります。多くの現場では、社内文書を無加工のまま外部APIへ丸投げしているのが実態でしょう。そこと比べれば、8〜9割の機密を手前で止める層が入る意味は小さくありません。ゼロトラスト的な多層防御の一枚として見るなら価値がある——というのが現時点での妥当な位置づけだと考えます。
日本企業にとって最大の留保は「日本語未検証」
論文自身が挙げる限界も明確です。実験は平均約300語・機密エンティティ約15個程度の文書が前提で、それより長大・高密度な文書では未評価だと明記されています。著者らは、文書が長くなるほど「特定・置換・一貫した復元」が難しくなり、秘匿性と回答品質の双方に影響しうると述べています。社内規程、議事録、設計書といった実務文書は300語では収まりません。
さらに多言語環境は今後の課題とされており、日本語での検証は行われていません。日本語は固有名詞の表記ゆれ（漢字・カナ・英字・略称）が激しく、「株式会社◯◯」「◯◯社」「◯◯」を同一エンティティとして一貫置換・一貫復元できるかは、英語より明らかに難しい問題です。この論文の数字をそのまま日本語の社内RAGに当てはめることはできません。
情シスはどうすべきか
SEAG自体はまだ研究段階なので、今すぐ導入する話ではありません。ただしこの研究が突いた問い——「うちのRAGは、外部LLMに何を渡しているのか」——は今日から答えられるはずです。まずはRAGの検索対象インデックスに何を入れたかの棚卸しと、利用中のLLMサービスの契約条件（学習利用の有無、ログ保持期間、サブプロセッサ、保存リージョン）の確認から始めるのが現実的です。
対策の枠組みは自前で作るより、公的な指針に沿わせるほうが確実で、社内説明もしやすくなります。
- デジタル庁「テキスト生成AI利活用におけるリスクへの対策ガイドブック（α版）」 … 企画・調達・設計・運用の工程ごとにリスクと軽減策が整理されています。RAG導入の稟議や設計レビューの下敷きに使えます。
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」 … 個人情報を含むプロンプト入力の考え方。法務・コンプラ部門との合意形成に必須の一次情報です。
- OWASP「LLM02:2025 Sensitive Information Disclosure」 … 機密情報の露出リスクを体系的に整理した定番。技術者向けのチェック観点として。
- IPA「中小企業の情報セキュリティ対策ガイドライン」 … 体制・ルール整備の土台。AI利用ルールも既存の情報資産管理の延長に置くと運用が回りやすくなります。
そして地味ですが効くのが利用者側の啓発です。統制をどれだけ組んでも、担当者が個人アカウントの生成AIに社内文書を貼り付けてしまえば意味がありません。IPA「対策のしおり」のようなエンドユーザ向け教材を使い、「何を入力してよいか」を具体例で示す地道な教育を並行させてください。関連して、RAGの検索対象そのものが汚染される攻撃についてはRAGポイズニングとは？AIエージェントを乗っ取る攻撃を、AIが業務データを過剰に把握してしまう構造についてはLLMエージェントが「知りすぎる」問題も併せてご確認ください。
まとめ
- RAGの見落としがちな穴は「外部LLM事業者に社内文書がそのまま渡っていること」。不正利用者対策とは別の経路であり、契約条項だけでは根本的に潰せません。
- 提案手法SEAGは、伏せ字ではなく自然な別名に置換して外部に投げ、手元で復元する方式。機密の秘匿は約85〜90%、利用者への正答は約80〜84%で、無加工時（約99%）から16〜19ポイント落ちます。
- 査読前の研究であり、約300語の文書・英語のみで検証されている点に注意。長文と日本語は未検証のため、日本の社内RAGに数字をそのまま当てはめず、まずは「何を外部に送っているか」の棚卸しから着手してください。
出典
- Saleh Almohaimeed et al., “Privacy-Preserving RAG by Concealing Sensitive Information from External LLMs”, arXiv:2608.12675（2026年8月13日、査読前）
- デジタル庁「テキスト生成AI利活用におけるリスクへの対策ガイドブック（α版）」
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」（令和5年6月2日）
- OWASP Gen AI Security Project「LLM02:2025 Sensitive Information Disclosure」
- IPA「中小企業の情報セキュリティ対策ガイドライン」
