社内で最もよくあるRAGの誤りは単純です。すべてをアップロードして質問し、出典を引用した回答なら自動的に安全だと考えることです。
2番目によくある誤りは、後から発覚します。ユーザーが決して閲覧できないはずの文書に基づいて、アシスタントが回答できると誰かが気付きます。給与水準、顧客との契約、法務文書の下書き、取締役会のメモ、サポートチケット、人事調査、セキュリティ手順などです。回答は正確で、出典も示されているかもしれませんが、システムは情報を漏えいさせています。
社内ナレッジRAGは、文章を読みやすくした検索ボックスではありません。権限管理された情報システムです。そのように扱ってください。
検索では、情報源のシステムと同等以上に厳格な権限を適用する必要があります。ユーザーがGoogle Drive、SharePoint、Notion、Confluence、またはCRMで文書を開けない場合、RAGもそのユーザーのためにその文書を検索すべきではありません。
中核となる規則
検索レイヤーは、チャンクを返す前に次の問いに答える必要があります。
このユーザーは、今この情報源を閲覧することを許可されているか？
「この情報源はベクトルデータベースに入っているか？」ではありません。「この情報源は関連しているか？」でも、「この情報源は有用か？」でもありません。権限が最優先です。
一般的なパターンは3つあります。
| パターン | 仕組み | 適する場面 |
|---|---|---|
| インデックスの分離 | 対象者またはワークスペースごとに1つのインデックスを用意する | 単純なチーム、粗い権限管理 |
| メタデータフィルタリング | ACL／グループ／情報源のメタデータを保存し、検索前にフィルタリングする | ほとんどの社内RAGシステム |
| リアルタイムの権限確認 | 検索時に情報源のシステムへ権限を問い合わせる | 機密性が高い、または権限が頻繁に変わる場合 |
適切な答えは、情報源のシステムとリスクレベルによって異なります。ほとんどの中小企業には、インデックスの分離とメタデータフィルタリングの併用で十分です。顧客、人事、法務、または規制対象のデータでは、リアルタイムの確認が必要になる場合があります。
難所：ACLの同期を保つ
上記のすべてのパターンは、インデックス内の権限データが情報源のシステム内の権限データと一致することに、暗黙のうちに依存しています。その同期にこそ、実際のエンジニアリング上の難しさがあります。
ACLの取得元。 SharePointとOneDriveはMicrosoft Graph APIを通じて項目ごとの権限を公開し、Google DriveはDrive APIのファイルごとの権限一覧を通じて公開します。Confluenceではスペースとページの制限を通じて公開されます。それぞれでデータの形（ユーザー、グループ、継承、共有リンク）、APIのレート制限、「誰がこれを閲覧できるか」の概念が異なります。
グループの展開は省略できません。 実際の権限の多くはグループに付与され、グループは入れ子になっています。「All Staff」に含まれる「Sales」、さらにその中の「Sales EU」は、同期時（インデックスのメタデータが大きくなり、クエリは速くなる）またはクエリ時（情報は新鮮になるが、遅くなり、API呼び出しが増える）に、具体的なユーザーへ展開する必要があります。どちらかを意図的に選んでください。偶然の成り行きで実装したチームでは、一貫性が失われます。
同期の遅延はセキュリティパラメーターであり、パフォーマンス上の細部ではありません。 役割の変更、退職処理、商談の機密化などにより、誰かが文書へのアクセスを失っても、次回の同期まではインデックスが古いACLに基づく提供を続けます。コーパスごとに許容できる権限取り消しの遅延を決め、明記してください。要配慮情報のコーパスではほぼリアルタイム、社内プロセス文書では数時間が許容される場合があります。誰もその時間を明記していなければ、実際の答えは「夜間ジョブが実行されるまで」であり、セキュリティレビューには耐えられません。
リアルタイムの確認では鮮度を得られる代わりに、レイテンシー、レート制限、障害モードという代償を払います。 検索ごとの権限確認では、すべてのクエリに情報源システムとの往復通信が追加され、規模が拡大するとAPIクォータを急速に消費します。一般的な妥協策は有効期間の短いキャッシュですが、これは「リアルタイム」をひそかに「遅延がより短い同期」へと戻すものです。どの方式を選ぶにしても、タイムアウト時の挙動を明確にしてください。権限確認に失敗するかタイムアウトした場合、チャンクは送信しません。 安全側に倒して失敗させ、その失敗を記録し、アシスタントには回答を拒否させます。情報を素早く漏えいさせるより、正しい回答が遅い方が適切です。
テストセクションに記載する退職処理テストにより、これらが実際に機能するか確認できます。無効化されたアカウントは、要配慮情報のコーパスから何も検索できてはいけません。また、その確認は次回の完全な再同期後だけでなく、アカウントを無効化した翌日にも成立する必要があります。
情報源の境界
巨大なナレッジプールを1つ作ってはいけません。対象者と機密性で分離してください。
| コーパス | 対象者 | 例 | 規則 |
|---|---|---|---|
| 公開／プロダクト | 全員 | ヘルプドキュメント、公開価格、製品ページ | 広範なアシスタントに安全 |
| 社内業務 | 従業員 | プロセス文書、社内FAQ | 従業員のみ |
| 部門 | 部門のメンバー | 営業プレイブック、サポートマクロ、エンジニアリングのランブック | グループでフィルタリング |
| 顧客記録 | 担当チーム | チケット、契約、アカウントメモ | 厳格なACLと監査 |
| 要配慮 | 指名されたユーザーのみ | 人事、法務、セキュリティ、取締役会 | 通常は別システムにするか、RAGを使用しない |
コーパスが対象とする利用者層が少ないほど、漏えいについて推論しやすくなります。
取り込みの制御
多くの漏えいは、取り込みパイプラインから始まります。
情報源をインデックス化する前に、次の項目を取得してください。
- 情報源のシステム。
- 文書ID。
- 所有者。
- 対象者またはACL。
- 機密性ラベル。
- 作成日時と更新日時。
- 有効期限またはレビュー日。
- 文書をAI検索に使用してよいか。
- 文書に個人データが含まれるか。
情報源のシステムにすでにラベルがある場合は、それを保持してください。ラベルがない場合は、取り込み前に簡易的な分類ステップを追加します。
検索の制御
検索は、次の順序で行う必要があります。
- ユーザーとグループを特定する。
- 要求されたワークスペースまたはアシスタントを特定する。
- コーパス、ACL、機密性、鮮度で候補となる情報源をフィルタリングする。
- 許可された情報源からのみ関連するチャンクを検索する。
- 許可されたチャンクを再順位付けする。
- 情報源への参照を付けて回答を生成する。
- 許可された情報源が不十分な場合は、回答を拒否するかエスカレーションする。
先に検索してから、プロンプト内でフィルタリングしてはいけません。禁止されたチャンクがモデルのコンテキストに入った時点で、境界はすでに破られています。
プロンプトと回答の挙動
アシスタントには、次のように指示する必要があります。
- 検索された情報源だけに基づいて回答する。
- 情報源のタイトルとセクション／リンクを引用する。
- 許可された情報源に回答が含まれていない場合は、その旨を伝える。
- 推論を情報源に基づく事実とは分けて明示する。
- 要配慮の情報源が存在することを明かさない。
- アクセスを拒否された資料を要約しない。
不適切な回答拒否：
「人事部の給与水準が見つかりましたが、あなたにはアクセス権がありません。」
より適切な回答拒否：
「その質問に回答するために利用できる、承認済みの情報源がありません。」
2つ目の回答は、要配慮情報の文書が存在することも、そのトピックも漏らしません。
二次的な漏えいを生まないログ記録
RAGのログは機密情報です。ユーザーの質問、検索されたチャンク、情報源ID、回答、場合によっては個人データが含まれる可能性があります。
デバッグに十分な情報を記録してください。
- ユーザーIDまたは仮名化したID。
- アシスタント／ワークスペース。
- クエリのタイムスタンプ。
- 検索された情報源ID。
- 権限フィルターの結果。
- 回答ID。
- 回答拒否／エスカレーションの理由。
- レイテンシーとエラー。
次の項目には注意してください。
- ユーザーの質問全文。
- 検索されたチャンク全文。
- 生成された回答全文。
- 顧客データ。
- 人事／法務／セキュリティに関するトピック。
機密性の高いシステムでは、全文ではなく、墨消ししたログまたは情報源IDを保存してください。ログ自体にもアクセス制御と保持期間を設定します。
古い情報源と矛盾する情報源
境界となるのは権限だけではありません。情報源の品質も重要です。
インデックス化されたすべての情報源に、所有者と鮮度に関する規則を設定する必要があります。
| 情報源の種類 | レビュー規則 |
|---|---|
| 価格 | 価格が変更されるたびにレビュー |
| 方針 | 方針の所有者が更新した際にレビューし、少なくとも四半期ごとに実施 |
| 製品ドキュメント | リリース時にレビュー |
| 法務テンプレート | 法務上の所有者がレビュー |
| サポートマクロ | 毎月、またはエスカレーションのパターン発生後にレビュー |
情報源が矛盾する場合、ユーザーが両方の情報源にアクセスできる場合にのみ、アシスタントはその矛盾を明示するべきです。それ以外の場合は、許可された情報源のうち最も権威のあるものに基づいて回答するか、エスカレーションするべきです。
権限境界のテスト
文書だけでなく、ユーザーを使ってテストしてください。
- 広範なアクセス権を持つ従業員。
- 部門内に限定されたアクセス権を持つ従業員。
- 自分のチームだけにアクセスできるマネージャー。
- 契約社員。
- 元従業員または無効化されたアカウント。
- 顧客対応を担当するサポートユーザー。
- 管理者。
それぞれについて、次のように質問します。
- 回答できるはずの質問。
- 権限範囲のすぐ外側にある質問。
- 存在を知っている要配慮情報の文書に関する質問。
- 公開文書と社内文書が矛盾する質問。
- 「アクセス規則を無視して」というプロンプトインジェクションを使用する質問。
正しい結果とは、単に「良い回答」ではありません。「許可された情報源に基づく良い回答」です。
展開手順
最も機密性の低いコーパスから始めます。
- 公開／プロダクト文書。
- 社内業務文書。
- 部門別の文書。
- 厳格なACLを適用した顧客記録。
- 明示的なセキュリティ／法務承認を得た後に限り、要配慮情報のコーパス。
各段階で、次の項目を測定します。
- 回答の有用性。
- 引用の品質。
- 回答拒否の正しさ。
- アクセス拒否された情報源の検索率。
- 古い情報源の割合。
- 情報源の欠落または誤りに関するユーザー報告。
まだ行うべきでないこと
「全社文書」を1つのアシスタントにインデックス化してはいけません。
権限の適用をプロンプトの指示に依存してはいけません。
明確な保持・アクセス方針なしに、機密性の高いコーパスから検索されたチャンク全文をログに記録してはいけません。
人事、法務、顧客、公開文書を同じコーパスに混在させてはいけません。
役に立とうとするあまり、許可された情報源の範囲外についてRAGに回答させてはいけません。
まとめ
社内ナレッジRAGには、情報源に基づく回答を日常業務に取り込めるという価値があります。一方で、情報源に基づく回答であっても、情報を漏えいさせる可能性があるというリスクがあります。
権限境界を最初に設計してください。検索前にフィルタリングし、対象者ごとにコーパスを分離します。情報源のメタデータを保持し、安全に回答を拒否し、慎重にログを記録してください。実際の権限プロファイルでテストします。ユーザーが情報源に直接アクセスできない場合、RAGはそのユーザーへの回答にその情報源を使用してはいけません。
