RAGと社内データ — 検索拡張生成がつくる新しい情報経路のリスク

「社内の規程やナレッジをAIに答えさせたい」——この要望に応える仕組みとして、RAGを導入する企業が増えています。RAG（検索拡張生成）とは、一言でいえば質問に関係する社内文書を検索して、その内容をAIの回答に使う仕組みです。AIが社内事情を踏まえて答えてくれる便利さの一方で、これは「社内データがAIを経由して流れる新しい経路」を社内につくる行為でもあります。危険だと断定するためではなく、導入前に整理しておきたい論点をまとめる記事です。

RAGがつくる情報の流れ

RAGを導入すると、情報はおおまかに次の経路をたどります。

社内文書 →（検索）→ AIへの入力 →（生成）→ 回答として出力 → 利用者・連携先へ

従来、社内文書は「アクセス権を持つ人がファイルサーバーや文書管理システムで開く」ものでした。RAGはここに、文書の内容が検索・抽出され、AIの入力に混ぜられ、回答という別の形で出力されるという流れを追加します。文書そのものを渡していなくても、内容は回答に乗って移動します。この経路がどこを通り、どこで終わるのか——それが整理すべき対象です。

整理すべき3つの論点

論点	問い	起きうること
① 検索対象の権限	質問した本人が読めない文書まで検索対象に入っていないか	権限のない情報が回答に混ざって「見えてしまう」
② 処理の場所	検索基盤や埋め込み処理（文書を検索用データに変換する処理）は社内か、外部サービスか	文書の内容が処理のために社外へ送信される
③ 出力の行き先	回答はどこへ届くか。チャット画面だけか、他システムや外部連携にも流れるか	回答経由で社内情報が想定外の場所に蓄積・転送される

特に①は見落とされがちです。文書管理システム側では部署ごとに細かくアクセス権を設定していても、RAGの検索対象として一括投入した時点でその権限設計が引き継がれていなければ、AIが「権限の壁を迂回する読み取り口」になってしまいます。検索時に利用者本人の権限で絞り込めるか、は導入前に必ず確認したい点です。

②と③は、LLMへの入力データの行き先と同じ構図です。外部のAIサービスや検索サービスを使う構成なら、社内文書の内容が送信先でどう保持・利用されるかを、契約とサービスごとに個別に確認する必要があります。

ネットワーク層から見える部分・見えない部分

この3つの論点のうち、ネットワーク層の可視化・制御が手伝えるのは一部です。

見える部分 — RAGを構成するサーバーが、実際にどの外部サービスへ接続しているか。設計書の上では「埋め込み処理は社内で完結」のはずが、実態として外部のAPIへ通信していた、といったずれは接続先の観測で発見できます。RAG基盤の置かれたセグメントの接続先を許可リストで絞れば、想定外のサービスへ文書内容が流れる経路自体を狭められます（考え方はegress 制御入門を参照）。

見えない部分 — 権限の正しさです。検索が本人の権限どおりに絞られているか、回答に混ざった情報が見せてよいものか、は通信の宛先からは判定できません。許可済みの正規サービスへの通信に乗って出ていく内容も同様です。

多層での手当て

RAGの安全性は、どれか一つの対策では成立しません。

1. 権限の設計（アプリケーション層） — 検索時に利用者本人のアクセス権を反映させる。投入する文書の範囲を最初は狭く始める
2. 処理場所の確認（契約・構成） — 検索基盤・埋め込み処理・生成のそれぞれがどこで動き、データがどこへ送られるかを構成図に書き切る
3. 接続先の可視化と制御（ネットワーク層） — RAG基盤の外向き通信を観測し、構成図とのずれを検出する。想定外の宛先への経路を絞る
4. 記録 — どのシステムがどこへ接続したかの記録を残し、監査や説明の材料にする

まとめ

• RAGは「社内文書 → AI → 出力」という新しい情報経路を社内につくる。便利さとセットで経路の整理が要る
• 論点は3つ: 検索対象の権限管理・処理の場所・出力の行き先
• 権限が引き継がれない検索対象の一括投入は、アクセス権の迂回路になり得る
• ネットワーク層で見えるのは「どの外部サービスへ繋いでいるか」。権限の正しさは見えない
• アプリ層の権限設計・契約の確認・ネットワーク層の可視化と制御の多層での手当てで考える

Tate（盾）は、RAG基盤やAI関連サーバーが実際にどの外部サービスへ接続しているかを可視化し、記録に残すことを支援します。詳しくは可視化・AI解析をご覧ください。