RAGは、社内に蓄積された文書を検索し、その内容をもとに回答を生成する仕組みである。便利な反面、検索対象となる文書には、個人情報や取引先の機密、社外秘の資料が混ざっていることが多い。RAGはそうした文書を読み取り、外部のLLMに渡して回答を組み立てる。つまり、どの情報をどこまで扱うかを設計しておかないと、見せるべきでない情報が回答に出たり、想定していない場所に送られたりする。
本記事は、RAGを導入・連携する前に確認しておきたいセキュリティと個人情報の項目を、発注者の視点で整理する。想定読者は、中小企業の経営者、DX担当、情シス担当、事業責任者である。セキュリティというと専門的に聞こえるが、発注者として「何を、どこに送り、どこに残すのか」を整理できれば、開発会社と実のある話ができる。なお、法令名に触れる場面もあるが、本記事は一般的な考え方を示すものであり、個別の法解釈は専門家や所管の確認を前提とする。
結論：送る範囲・残す場所・残すログを発注前に決める
RAGのセキュリティで最初に押さえるべきは、データの「流れ」を見える化することである。文書がどこから読み取られ、どこに送られ、どこに残るのか。これが曖昧なまま進めると、後から線を引き直すのは難しい。GXOがRAGのセキュリティで重視するのは、次の3点である。
- 外部API（クラウドLLM）に送るデータと、送らないデータの線を引く
- データの保存場所と保存される国を把握し、社内方針と照らす
- 検索・回答のログを誰がどこまで取得し、どう監査するかを決める
これらは、RAGを動かし始めてから考えると手戻りが大きい。何を扱う仕組みなのかが固まる発注前に、方針を決めておきたい。
なぜセキュリティと個人情報の確認が重要か
RAGは、検索対象の文書をそのまま回答の材料にする。検索対象に含めた情報は、条件次第で回答に表れうるということである。設計が甘いと、次のような問題につながる。
- 一部の担当者しか見られない文書が検索対象に入り、権限のない利用者の回答に混ざる
- 個人情報を含む文書が、想定せず外部APIに送られる
- どの質問でどの文書が使われたかが残らず、問題が起きたときに範囲を特定できない
RAGは、社内の情報を横断して引き出せることに価値がある。その横断性が、扱う範囲を絞らなければそのままリスクになる。検索対象に何を含めるか、誰が何を見られるかは、回答の品質と同じくらい、安全性に直結する。RAGに載せる前のデータ整備についてはRAG導入前のデータ品質管理でも扱っている。
外部APIに送るデータの線を引く
RAGは、回答の生成にクラウドのLLMを使う構成が多い。この場合、検索で取り出した文書の一部や、利用者の質問文が、外部のAPIに送られる。ここで「何を送り、何を送らないか」を決めておくことが、個人情報保護の起点になる。
| データの種類 | 外部APIへの扱い | リスク | 確認の観点 |
|---|---|---|---|
| 一般的な業務文書 | 回答生成のため送られうる | 内容の社外送信 | 利用規約上の取り扱いを確認 |
| 個人情報を含む文書 | 送る前に方針を決める | 個人情報の外部送信 | マスキングや対象除外を検討 |
| 取引先の機密・社外秘 | 原則として線引きが必要 | 守秘義務との抵触 | 検索対象から外す判断も |
| 利用者の質問文 | 多くの場合送られる | 質問経由の情報入力 | 入力時の注意喚起を設計 |
すべてを一律で外部APIに送る設計は、簡単だが線引きがない。個人情報や社外秘を含む文書は、検索対象から外す、該当箇所を伏せる（マスキング）、あるいは外部に送らない構成を選ぶ、といった選択肢がある。送る前提か、送らない前提かは、利用するLLMの選び方とも関わる。社内に閉じた構成と外部API利用の比較は社内向けLLMゲートウェイの内製化とコストで扱っている。
データの保存場所と国を把握する
RAGは、文書を検索しやすい形に変換して蓄える。元の文書、変換後のデータ、検索用の索引、ログなど、複数の場所にデータが残る。これらが「どこに」「どの国に」保存されるかは、社内の方針や取引先との約束に関わる重要な点である。
- 元データの保管先：社内のサーバか、クラウドか。クラウドなら事業者と地域はどこか。
- 変換後データの保管先：検索用に変換したデータがどこに残るか。
- 外部APIに送ったデータの扱い：送ったデータが事業者側に残るのか、残るならどれくらいか。
- 保存される国・地域：データが国内に留まるのか、国外に渡るのか。
保存場所と国は、社内のセキュリティ方針や、取引先と交わした守秘の取り決めと照らし合わせて確認したい。「データは国内に置く」「特定のデータは外部に出さない」といった方針がある場合、それを満たせる構成かどうかは、発注前に開発会社へ確認しておくべき論点である。後から保存場所を変えるのは、移行の手間が大きい。
検索・回答のログと監査を設計する
RAGを安全に運用するには、「誰が」「どんな質問をして」「どの文書が使われ」「どんな回答が返ったか」を記録しておくことが望ましい。問題が起きたとき、範囲を特定し、説明責任を果たすための土台になる。
- アクセスログ：誰がいつ利用したかを残す。
- 質問と回答のログ：どんな質問にどう答えたかを残す。
- 参照文書のログ：その回答にどの文書が使われたかを残す。
- 保存期間と閲覧権限：ログをいつまで残し、誰が見られるかを決める。
ただし、ログには質問文や回答が含まれるため、ログ自体が個人情報や機密を含みうる。ログを取れば安全という単純な話ではなく、ログの保存場所、保存期間、閲覧できる人の範囲もあわせて設計する必要がある。記録を残すことと、記録を守ることは両輪である。誰がログを見られるかを絞り、不要になったら消す方針まで決めておきたい。
プロンプト経由の漏えいと不正利用に備える
RAGでは、利用者が入力する質問文（プロンプト）が新たな経路になる。ここには、想定外の情報が入り込んだり、不正な指示が紛れ込んだりする可能性がある。発注前に、次のような点を意識しておきたい。
| 注意したい経路 | 起こりうること | 備えの方向性 |
|---|---|---|
| 質問への機密入力 | 利用者が機密を質問文に書き込む | 入力時の注意喚起、ログの保護 |
| 不正な指示の混入 | 回答を逸脱させる指示を入力される | 想定外の指示への耐性を確認 |
| 権限を越えた引き出し | 見えない文書を聞き出そうとする | 権限と検索対象の連動を確認 |
| 回答の社外転用 | 回答を社外に持ち出される | 利用範囲のルール整備 |
これらは、技術だけで完全に防げるものではなく、利用ルールと組み合わせて備えるものである。利用者への注意喚起、権限による検索対象の制御、ログによる事後確認を重ねて、リスクを下げていく。完璧を目指すよりも、起こりうる経路を洗い出し、それぞれに歯止めを用意する姿勢が現実的である。
導入前チェックリスト
- RAGが扱う文書に、個人情報や社外秘が含まれるか棚卸ししたか
- 外部API（クラウドLLM）に送るデータと送らないデータの線を引いたか
- 個人情報を含む文書のマスキングや対象除外を検討したか
- データの保存場所と保存される国を把握したか
- 社内のセキュリティ方針・守秘の取り決めと照らし合わせたか
- 検索・回答・参照文書のログを残す方針を決めたか
- ログの保存期間と閲覧できる人の範囲を決めたか
- 質問文経由の情報入力や不正利用への備えを想定したか
開発会社に確認する質問
| 質問 | 確認したいこと |
|---|---|
| 外部APIに送るデータを限定できますか | 送信範囲の制御 |
| 個人情報のマスキングや対象除外はできますか | 機微データの保護 |
| データの保存場所と国を指定できますか | 保存先の選択 |
| 検索・回答・参照文書のログを残せますか | 監査・追跡 |
| ログの保存期間と閲覧権限を設定できますか | ログの保護 |
| 利用者の権限に応じて検索対象を絞れますか | 権限と検索の連動 |
「クラウドのサービスなので安全です」という説明だけで済ませず、何がどこに送られ、どこに残るのかを具体的に確認したい。ここを言語化できる開発会社は、設計の見通しも立てやすい。
相談前に整理しておくとよい情報
- RAGに載せたい文書と、その中に含まれる個人情報・機密の有無
- 社内に「国内保管」「外部に出さない」などのデータ方針があるか
- 取引先との守秘の取り決めで、扱いに制約がある情報があるか
- ログをどこまで残したいか、誰が見る想定か
- 利用者の範囲（全社か、特定部署か）と、それぞれが見てよい情報
これらが整理されていなくても相談は可能である。載せたい文書と、その中の機微な情報の有無が見えていれば、送る範囲と残す場所の線引きを一緒に設計できる。
関連記事
よくある質問
Q1. クラウドのLLMを使うと、社内文書はすべて外部に渡ってしまうのですか
すべてが一律に渡るわけではない。RAGの構成では、検索で取り出した一部と質問文が外部APIに送られることが多く、何を検索対象に含めるか、何を送る前に伏せるかを設計できる。送る範囲を限定する構成や、社内に閉じる構成も選択肢になる。
Q2. 個人情報を含む文書は、RAGに載せないほうがよいですか
一概に載せないほうがよいとは言えない。業務上必要なら、アクセスできる利用者を絞り、外部に送る箇所を伏せ、ログを残すといった備えとセットで扱う方法がある。重要なのは、含まれていることを把握したうえで、扱い方を決めることである。
Q3. ログを残せば、セキュリティは十分ですか
ログは事後の確認に役立つが、それだけで十分とは言えない。ログ自体が機密を含むため、保存場所や閲覧権限の保護も必要になる。送る範囲の線引き、保存場所の把握、ログの取得と保護を重ねて、はじめて運用に耐える設計になる。
RAGのセキュリティと個人情報の扱いを一緒に確認しませんか
GXOでは、外部APIへ送るデータの線引き、保存場所、ログと監査、個人情報の扱いを含め、RAGのセキュリティ設計を発注前にご支援します。
※ 初回相談では、営業資料の説明よりも現状整理とリスク確認を優先します。