RAGの回答から個人情報を消せば、安全と言えるのか？
顧客対応を支援する検索AIで、氏名や連絡先を回答から除く仕組みを導入しました。画面には個人情報が出ません。
ところが異動した担当者から、以前の部署の情報に基づく回答が返るという報告が上がります。元の文書の権限は、すでに外していたはずでした。
これは、検索と権限の関係を考えるための想定場面です。問題が回答に現れたとき、表示のマスキングだけを調整してよいのでしょうか。検索の途中で何が取得され、その時点でどの権限が使われたかを追う必要があります。
回答で情報を見せないことと、権限外の情報を取得させないことを分けて設計します。保存元の権限を変えたとき、検索用の複製や過去の結果へどう反映するかまで確かめておきましょう。
RAGは、回答の前に情報を取り込む
RAGは、関連する資料を検索し、その内容を使って回答を作る仕組みです。利用者の質問を受け、資料を探し、必要な内容をモデルへ渡し、回答を表示します。最終回答に出ない情報でも、この過程のどこかで取得されている場合があります。
出力のマスキングは、画面へ出す情報を抑えるための制御として意味があります。しかし、それだけで、モデルへ渡す前の取得や、別の処理への送信を防いだことにはなりません。防ぐ対象が異なるためです。
ここで、検索を使うだけで必ず情報が漏れるという意味にはしません。構成、利用するサービス、データの区分によって、情報が届く範囲は変わります。自社でどこまで許可し、どこを制限するかを明らかにする必要があります。
保存が必要な情報でも、AIに参照させる必要があるとは限りません。この記事では、参照を許す範囲の中でも、どの利用者へどの資料を取得させるかを扱います。保有の判断から、一回ごとの検索の判断へ進みます。
権限は、文書と一緒に運ばれているか
検索のために元の文書を別の場所へ取り込む構成では、本文だけでなく、誰が参照してよいかという情報も管理する必要があります。検索しやすい複製を作っても、元の許可条件が自動的に維持されるとは限りません。
MicrosoftのAzure AI Searchの公式文書は、文書単位のアクセス制御として、フィルターを用いる方法や、権限情報を取り込んで照会時に評価する方法を説明しています。対応するデータ源や方式により条件があり、一部はプレビューです。
この事実から、製品名だけで安全性を判断しないことが重要になります。どの方式を採用し、何の権限情報を使い、どの時点で更新し、検索時の利用者を何で識別するかを確認します。ある製品に機能があることと、自社の構成で有効になっていることは違います。
文書を短い断片に分けて検索する場合も、その断片が元の文書の許可条件を引き継ぐかを確かめておきましょう。本文の一部になったことを理由に、権限の判断から外れてよいわけではありません。
異動の日、検索の許可はいつ切り替わるか
冒頭の想定場面を時系列で考えます。担当者が異動し、保存元の文書から参照権限が外れました。ところが検索基盤が使う権限情報は、前の取込み時点のままだったとしたら、同じ利用者には何が返るでしょうか。
公式文書にも、検索時の判断が、すでに取り込まれた権限情報を使い、元の変更が反映されるには同期が必要な方式があると説明されています。検索の時点で確認するという言葉だけでは、参照する権限情報の新しさまではわかりません。
AILの提言は、権限を外した時点と、検索で取得できなくなる時点を、別々に確認することです。元の設定変更、検索基盤の更新、利用者の状態、保存された検索結果など、関係する段階を追います。
業務上どれだけの反映遅延を許容するかも決める必要があります。全件を即時に更新できない場合は、対象の機微性に応じ、検索を一時制限する、必要な範囲だけ先に反映するなどの方法を検討します。採用製品で実現できる範囲を確認した上で選びます。
過去の回答を見られることは、同じ許可なのか
権限の取消しを検索へ反映できても、以前の会話履歴や保存された回答が残る場合があります。ここは、元文書の権限と同じ仕組みで管理されているとは限りません。
利用者が当時正当に取得した情報をどこまで保存・再表示できるかは、業務や規程による判断が必要です。権限を外したら必ずすべての記録を即時に消す、と一律には決められません。一方、別の利用者へ過去の結果が共有される仕組みは、追加の確認が必要になります。
例えば、よくある質問への回答を共通に保存して再利用する構成を想定します。一般的な案内文なら再利用できても、個人ごとの契約状況が含まれる回答を同じ扱いにしてよいかは別です。回答の再利用が、利用者の境界を越えないようにする必要があります。
そのため、取得時の権限だけでなく、再表示や再利用の条件も整理しておきましょう。誰向けに生成された結果か、何を含むか、いつまで使うか、変更や取消しをどう反映するかを確認します。検索が止まっただけで対応完了としない理由です。
マスキングの役割を、取得制御と混ぜない
個人情報を表示する必要がない回答なら、マスキングや出力の検査は役立ちます。ただし、見えなくする項目を増やすことで、元の資料への過大なアクセスを隠してしまってはなりません。
逆に、業務上必要な表示まで機械的に隠すと、担当者が元システムへ再照会し、画面の外へコピーする作業が増えるかもしれません。表示を制限した効果と、実際の業務で増えた別の経路も確認する必要があります。
ここでの評価は、マスキングの精度を上げるだけでは足りません。取得してよい情報、モデルへ渡してよい情報、画面へ出してよい情報を分け、それぞれの許可条件を決めます。重なる部分があっても、同じものとして管理しません。
読取りを許可するが外部送信は認めないというデータも考えられます。その場合、表示を隠す前に、どのサービスへ内容が渡るかを確かめます。RAGの回答を見ているだけでは、その境界は判定できません。
検索で見つからない原因を、権限不足と決め付けない
運用では、反対の問題も起きます。必要な資料が見つからないと、権限の制限を緩めたくなります。しかし、検索の関連性、取込みの失敗、文書の分割、権限の設定は、異なる原因です。
想定場面の担当者が、新しい部署の資料を見つけられないとします。そこで全社の資料を検索可能に変えるのではなく、まず対象資料が取り込まれているか、本人に許可があるか、許可情報が反映されているかを分けて見ます。
必要な権限が反映されていないなら、その範囲を直します。検索の条件が合っていないなら、その条件を調整します。業務の役割そのものが変わったなら、情報の所有者へ許可の判断を戻します。回答品質の改善を理由に、一括でアクセスを広げないようにしましょう。
この切り分けには、資料の内容をすべて報告へ添付する必要はありません。対象文書の識別情報、取込みの状態、権限の判定、検索結果の有無など、原因を追うのに必要な記録を選びます。点検用の資料にも個人情報を増やし過ぎないことが重要です。
四つの時点を持つ試験を、一組用意する
RAGのアクセス制御を確かめるなら、許可された状態の一回だけで終えません。以下のように、同じ利用者と資料の関係が変わる場面を、許可された試験環境で用意できます。
1. 権限を持つ利用者が、必要な資料を取得できます。
2. 権限のない利用者が、同じ資料を取得できません。
3. 権限を変更した後、合意した条件と時間で検索へ反映されます。
4. 過去の回答や共通の保存結果が、別の利用者へ渡りません。
三つ目の確認では、元の設定を変えた時点と、検索側に反映した時点を残します。四つ目では、履歴の保持という別の要件があるなら、その条件を明記します。すべての情報を消すことだけを正解にせず、決めた利用範囲が守られるかを見ます。
本番で安易に権限を変えて試す必要はありません。代表する利用者や資料を準備し、現実の構成との差を未確認事項として残します。どの機能や版を使った結果かも、後から比較できるようにしましょう。
文書一件の権限と、回答一件の権限は一致しない
検索対象が、部署ごとに分かれた文書だけとは限りません。一つの議事録に、複数の顧客や案件の記録が混在している場合もあります。文書全体の閲覧を許すことが、含まれるすべての個人情報を顧客向け回答へ使ってよいことになるかは、業務の条件から確かめておきましょう。
想定例の会社で、異動後の担当者が共通資料を検索できたとしても、その中に別部門の顧客対応履歴が混ざっていたなら、資料の分類から見直す余地があります。検索の権限設定だけで解決できる範囲と、元資料を分割したり、顧客向けに別の資料を整備したりする範囲を分ける必要があります。
逆に、複数の許可された資料を組み合わせた回答が、業務上は見せたくない推測を生むことも考えられます。氏名を削除しても、限られた店舗、日時、購入内容の組合せから対象者がわかる場面はないでしょうか。文字列としての個人情報検出とは異なる、回答の利用場面に沿った評価になります。
そのため、試験には文書単位の許可・拒否に加え、回答として許される内容も記載します。元資料の参照が正しくても、顧客への説明に不要な情報を含めば、別の改善が必要です。一方で、出力の問題だけを直して、取得範囲の問題を閉じてはいけません。
資料を細かく分ければ必ずよいとも限りません。文脈が切れて誤った案内をするなら、正確性への影響も確かめます。権限を守った状態で必要な回答を作れる資料構成を、業務担当と検索担当が共同で選びます。その判断を残すことが、異動や組織変更のたびに同じ議論をやり直す負担を減らします。
まず、元文書の権限変更を一件たどる
最初の点検には、最近権限を変えた一件を選ぶ方法があります。保存元で何が変わり、検索のための複製へいつ反映され、どの利用者が何を取得できる状態かを、運用担当者と確認します。
その結果、想定どおり反映されていれば、根拠として残せます。反映の条件がわからなければ、製品の公式仕様と現在の設定を照合します。プレビュー機能や特定の接続方式に依存する場合は、本番利用の判断もその条件込みで行います。
画面から個人情報が消えていることは、出力についての一つの結果です。必要な人だけが必要な資料を取得し、権限の変更が実際の検索へ届くことまで確認できれば、RAGを業務に使う判断はより具体的になります。
資料を読めることと、その中の指示へ従ってよいことは、さらに別の境界になります。
参考情報
公表情報の確認基準日：2026年10月22日。異動や会話履歴の場面はAILによる想定例です。製品の機能が自動的に全権限・全保存先へ適用されると主張するものではありません。
AILのサービス・プロダクトについて
AILでは、人材育成、実践知の蓄積・活用、導入に向けたコンサルティング、プロダクトの提供を通じて、企業のAI活用を支援しています。自社の課題に合った支援を、サービス紹介ページでご覧いただけます。
AI Librariumについて
本記事は、AI Librarium（アイブリウム）株式会社が発信しています。
AILは、専門家の知見や判断基準を、実務で使えるAI Skillとして届け、研修やコンサルティングを通じて企業の業務変革を支援します。その実践で得られた成果や課題を、AI Skillの改善と人材育成に活かし、次の変革につなげていくことを目指しています。
