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

「社内の規程やナレッジをAIに答えさせたい」。この要望に応える仕組みとして、RAGを導入する企業が増えています。RAG（検索拡張生成）とは、質問に関係する社内文書を検索して、その内容を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解析にまとめています。