RAGの情報漏えい対策のやり方：ログ・マスキング・監査で安全運用する設計

RAGで「情報が漏れる」と言われる理由：生成AIより“つなぎ方”が危ない

RAG（Retrieval-Augmented Generation）は、社内文書やナレッジを検索して、その結果を生成AIに渡し、回答を作らせる仕組みです。便利な反面、情報漏えいの多くは「モデルが勝手に覚える」よりも、検索・連携・運用の設計が甘いことで起きるケースが中心です。特に情シス・管理部門の立場では「APIを使っているから安全」「クラウドだから大丈夫」と考えがちですが、RAGは社内データを扱う“配管”が増えるため、漏えいポイントも増えます。

典型的な漏えい経路は次の通りです。まず、検索対象（SharePoint、ファイルサーバ、CRM、チケット管理など）から取り込む段階で、アクセス権を無視して全文をベクトル化してしまうと、権限外ユーザーが検索で引ける状態になります。次に、検索結果（コンテキスト）をプロンプトとしてLLMに渡す際、必要以上の文書を丸ごと渡すと、回答に不要な個人情報・契約情報が混入します。さらに、アプリ側が残すログ（リクエスト本文、検索結果、生成結果、エラー）に機密が平文で残り、監視ツールや運用担当の閲覧権限が甘いと二次漏えいになります。

もう一つ重要なのが「外部サービスへの送信」です。RAGはLLM APIや埋め込み（embedding）APIを使うことが多く、設定次第でデータが外部に送られます。多くの事業者は学習に使わない設定を用意していますが、“学習されない＝漏れない”ではありません。通信経路・保存期間・サポート時のアクセス・障害時のログ収集など、契約と実装の両面で確認が必要です。

本記事では、専門知識が深くなくても実務として進められるように、「ログ」「マスキング」「監査」を軸に、RAGの情報漏えい対策を設計・導入・運用まで一気通貫で整理します。結論から言うと、RAGの安全運用は、(1)データに触れる範囲を最小化し、(2)残る情報を減らし、(3)後から追える状態を作る、の3点に尽きます。

設計の全体像：守るべきデータと“境界線”を先に決める

RAGの情報漏えい対策は、技術よりも「何を守るか」と「どこまでをシステム内と見なすか」を最初に決めるのが近道です。まず対象データを棚卸しし、機密度（公開・社内限定・秘・個人情報など）をラベルで分類します。中小企業でも、最低限「個人情報（氏名・住所・電話・メール）」「契約・単価・見積」「人事評価」「顧客の機密」「ソースコード・鍵情報」は別扱いにしてください。RAGに入れる前提のナレッジでも、個人情報や契約書を混ぜると一気に難易度が上がります。

次に“境界線”を決めます。境界線とは、どこから先が外部で、どこまでが自社の統制下か、という線引きです。例として「社内ネットワーク内の検索基盤＋アプリは自社管理、LLM APIは外部」などです。境界線が曖昧だと、ログの保存場所、アクセス制御、監査責任の所在がブレます。特に情シスでは、SaaS利用規程・個人情報保護・委託先管理の観点から、外部に送る情報の種類と条件を文書化しておくことが重要です。

全体のアーキテクチャは、ざっくり次の要素に分けて考えると漏えいポイントを漏らしません。

• データソース：社内文書、FAQ、議事録、顧客対応履歴など
• 取り込み（ETL）：抽出・整形・分割・メタデータ付与・アクセス権の引き継ぎ
• ベクトルDB：検索用インデックス（本文とメタデータ、権限情報）
• 検索（Retriever）：ユーザー権限に応じたフィルタ、上位N件、スコア閾値
• 生成（Generator）：LLMへ渡す文脈の最小化、出力制御
• ログ・監査：誰が何を検索し、何が返り、どこまで残すか

この分解に沿って「保存する・送る・表示する」の3行為ごとに機密を扱う場面を洗い出すと、対策が具体化します。例えば、表示はOKだが保存はNG（チャット画面に一時表示するがログには残さない）、送信はOKだが全文はNG（LLMに送るのは要約だけ）、などのルールが作れます。RAGの情報漏えい対策は、ここで決めたルールをログ・マスキング・監査の仕組みに落とし込む作業です。

ログ設計：残すほど危ない、でも残さないと守れない

RAG運用で最も漏えいが起きやすいのがログです。理由は単純で、RAGは「質問」「検索結果」「生成回答」という“機密になりやすい文章”が毎回流れるからです。しかも、エラー解析や改善のために、開発者がつい全文を記録してしまいます。一方でログを減らしすぎると、インシデント時に追跡できず、監査にも耐えません。したがって、「目的ごとに最小限のログを定義」し、段階的に権限を分けるのが現実解です。

まず決めたいのは「業務ログ」と「セキュリティログ」を分けることです。業務ログは利用状況の把握（利用者数、処理時間、失敗率）に必要な統計情報が中心で、本文は極力持たない。セキュリティログは不正アクセス・権限逸脱・データ持ち出し兆候の検知に必要で、誰が何にアクセスしたかの証跡を持つ。ただし本文はハッシュ化・要約・マスキングして保持する、といった設計にします。

具体的に「何をログに残すか」の推奨例です。

• 必須（推奨）：ユーザーID/部署、認証方式、日時、リクエストID、処理の成否、レイテンシ、参照したデータソースID、検索クエリの“分類タグ”（例：人事/契約/IT）
• 条件付き：検索クエリ本文（短文なら可、個人情報が含まれる可能性があるならマスキング後）、生成回答本文（原則は保存しない、保存するなら要約＋マスキング＋短期保管）
• 原則禁止：検索で取得した原文の全文、APIキー、認可トークン、個人情報や契約情報の平文

また、RAG特有のログとして「どの文書断片を何件渡したか（chunk IDs）」は重要です。本文は持たずにIDだけを残すことで、後から「その回答がどの社内文書に基づくか」を追えるようになります。これにより、誤回答の原因調査や、権限逸脱（本来見せてはいけない文書IDが混ざった）の検知が可能になります。

保管期間も漏えいリスクに直結します。一般論として、運用改善用の詳細ログは短期（例：7〜30日）、監査・不正調査に必要な証跡は中期（例：3〜12か月）で、内容は最小化します。保管場所はアプリサーバのローカルではなく、アクセス制御されたログ基盤（SIEM等）に集約し、閲覧権限を“運用者全員”にしないことが大切です。情シスの実務としては「閲覧できる人」「持ち出せる人」「削除できる人」を分け、削除は承認制にします。

加えて、LLMやベクトルDBなど外部・別基盤のログも盲点になりがちです。利用しているクラウドの監査ログ（API呼び出し履歴、管理画面操作履歴）を有効化し、RAGアプリのログとリクエストIDで突合できるようにしておくと、事故対応のスピードが段違いに上がります。

マスキングと最小化：送る前・残す前・見せる前に“削る”

RAGの情報漏えい対策で効果が高いのが、マスキング（秘匿化）とデータ最小化です。難しい暗号技術よりも、まずは「そもそも個人情報や機密をLLMに渡さない／ログに残さない」を徹底するだけでリスクは大きく下がります。マスキングは、質問文・検索結果・生成回答の3箇所に適用する発想が重要です。

現場で起きがちな例として、ユーザーが「山田太郎さんの契約単価を教えて」と入力すると、質問文そのものが個人情報＋契約情報です。これをそのままログ保存すると、ログが機密の塊になります。よって、入力段階でPII（個人識別情報）検知を行い、「氏名」「電話」「メール」「住所」「口座」などをトークン置換（例：<NAME_1>）した上で、アプリ内部の一時領域にのみ元データを保持し、LLMへは必要最小限だけ送る、という設計が有効です。

次に検索結果（コンテキスト）。RAGは検索で引いた文書断片をLLMに渡しますが、ここで「上位10件をそのまま全文投入」してしまうと、不要な情報まで混ざります。対策としては、(1)検索件数を絞る、(2)スコア閾値を設ける、(3)断片の最大文字数を制限する、(4)要約してから渡す、(5)特定カテゴリ（人事・契約など）は強制マスキングしてから渡す、などの“最小化”が効きます。

生成回答にもマスキングを入れると、うっかり表示漏えいを減らせます。例えば「個人情報が含まれる回答は、末尾に『個人情報のため表示できません。担当部署へ確認してください』と出す」などのガードです。実務では、完全に自動判定できないため、重要領域は「回答に根拠文書IDを必ず出す」「根拠文書が機密ラベルなら回答を要約に留める」といった制約の方が安定します。

情シス・管理部門向けに、マスキング設計を進める際のチェックリストをまとめます。

• 検知対象：個人情報、取引先情報、金額、契約ID、秘密鍵・トークン、顧客固有語
• 方式：正規表現だけに頼らず、辞書（社員名簿）＋ルール＋LLM/分類器の併用を検討
• 置換：完全削除、部分伏字（例：メールの@前を伏字）、トークン化（後で戻せる）
• 適用箇所：入力、検索結果、回答、ログ、監視通知、サポート用ダンプ
• 例外運用：法務・人事など閲覧権限がある人は解除できるか（解除は監査ログ必須）

なお「マスキングしたら安全」という誤解もあります。文脈から推測できる情報（例：部署名＋役職＋案件名）で個人が特定される場合もあるため、機密ラベルが高い領域では「RAGに入れない」「回答を作らない（参照先リンクのみ）」という選択肢も含めて検討してください。

監査とガバナンス：誰が何を引いたかを追える仕組みが“最後の砦”

RAGの情報漏えい対策は、事前防止だけでは不十分です。運用が長くなるほど、権限変更・データ追加・組織変更・委託先追加などが起き、想定外の参照が発生します。そこで必要なのが監査です。監査とは、利用状況を可視化し、不正・事故の兆候を早期に発見し、発生時に原因を追跡できる状態を作ることです。監査は「信頼できる運用」を説明するための武器にもなります。

監査設計の要点は、(1)誰の操作か（認証とID統合）、(2)何に触れたか（データソースID・文書ID・機密ラベル）、(3)どこへ出たか（画面表示・ダウンロード・外部送信）、の3点を揃えることです。RAGでは「検索」自体が閲覧に近い意味を持つため、検索クエリとヒットした文書IDの紐付けが重要になります。

具体的な監査項目の例です。

• 権限逸脱の兆候：機密ラベルが高い文書への参照が急増、普段使わない部署が人事カテゴリを検索
• 持ち出しの兆候：短時間に大量の質問、同一テーマの繰り返し、夜間・休日の連続アクセス
• 設定変更：検索対象ソースの追加、権限フィルタの無効化、ログレベル変更、例外ユーザー追加

監査を実務に落とすには「月次レビュー」「アラート運用」「インシデント手順」の3点セットが必要です。月次レビューは、利用部門と情シスで「上位検索カテゴリ」「機密ラベル参照件数」「例外解除件数」を確認し、必要なら検索対象やプロンプトを調整します。アラート運用は、しきい値（例：1時間に50回以上の質問、機密ラベル“秘”の参照が連続）を決め、通知先と一次対応（アカウントロック、追加本人確認、調査チケット発行）を定義します。インシデント手順は、ログがマスキングされていても原因追跡できるよう、リクエストIDで追える設計と、エスカレーション先（法務・人事・広報）を明文化します。

技術面では、ID管理（SSO）と連携して「退職者の無効化が即時反映される」「委託先は期限付きアカウント」「部署異動で権限が変わる」状態を作ることが、RAGの監査と相性が良いです。RAGだけ頑張っても、認証が弱いと意味がありません。

安全運用の実装パターン：中小企業でも回せる現実的な落としどころ

ここまでの対策を全部やろうとすると、初期導入が重くなります。そこで「予算はあるが詳しくない」情シス・管理部門向けに、段階的に強化できる実装パターンを提示します。ポイントは“最初から完璧を狙わず、事故が起きやすい順に潰す”ことです。

パターンA：社内限定ナレッジRAG（まずは安全に始める）
対象データを「社内公開レベルの手順書・FAQ・規程・製品資料」に限定し、個人情報・契約書・顧客固有情報は入れない。ログは統計中心で本文は保存しない。検索結果は上位3件、断片は短め、回答は根拠リンク付き。監査は月次レビューから開始。これだけでも社内問い合わせ対応（情シス、総務、営業支援）の工数削減に効きます。

パターンB：部門限定RAG（権限と監査を強める）
データソースを部門単位で分け、ベクトルDBに機密ラベルとアクセス権メタデータを付与。検索時に必ず権限フィルタを適用し、例外解除は承認制。ログは「文書ID・機密ラベル・クエリ分類タグ」を保存し、クエリ本文はマスキング後に短期保管。アラート（大量アクセス、深夜利用）を設定。人事・法務のような高機密部門は、回答を要約中心にし、原文表示はリンク先で権限チェックさせます。

パターンC：顧客データを扱うRAG（最小化と二重の防御）
CRMや問い合わせ履歴を扱う場合は、入力・検索結果・回答のすべてにマスキングを適用し、LLMへ渡すのは要約＋必要項目のみ。可能なら顧客IDをトークン化し、回答画面側で復元する方式を検討。ログは本文を持たず、照会IDと操作証跡中心。監査は週次の例外レビューと、インシデント手順（顧客連絡フロー）まで整備します。このレベルは設計ミスが致命傷になりやすいので、社内で経験がなければ外部支援を入れるのが安全です。

どのパターンでも共通する“失敗しやすいポイント”があります。1つ目は、PoCで作ったRAGをそのまま本番にしてしまい、ログがデバッグモードのまま残ること。2つ目は、ベクトルDBへの取り込み時にアクセス権が落ちてしまうこと。3つ目は、利用部門が増えたのに監査とレビュー体制を増やさないことです。RAGは導入直後より、利用が広がった半年後に事故が起きがちです。だからこそ、ログ・マスキング・監査を“運用できる形”で設計する必要があります。

まとめ

RAGは「社内データを検索して生成AIに渡す」仕組みのため、情報漏えい対策はモデル選定よりも、検索・連携・運用の設計が鍵になります。安全運用の要点は、データに触れる範囲を最小化し、残る情報を減らし、後から追える状態を作ることです。

• ログ：本文をむやみに残さず、文書ID・機密ラベル・リクエストID中心に。閲覧権限と保管期間を設計する
• マスキング：入力・検索結果・回答・ログに適用し、LLMへ送る文脈は絞る（要約・上位件数・文字数制限）
• 監査：誰が何を参照したかを追跡できる証跡を整え、月次レビューとアラート運用、インシデント手順まで用意する

「まずは社内FAQから始める」「人事・契約は後から」「例外解除は承認制」など段階的に強化すれば、専門知識が深くなくてもRAGの情報漏えいリスクを現実的に下げられます。自社のデータ分類や運用体制に合わせた設計が必要な場合は、要件定義の時点で一度立ち止まり、境界線とログ方針を固めるのが最短ルートです。