社内RAGで閲覧権限を守るには？index時と検索時のACLを設計する

結論

安全なRAGはvector DBへ入れた後で画面側が隠す設計にしません。source ACLをindex metadataへ同期し、query userのidentity/groupでretrieval段階からfilterします。

まずこの表で判断する

source ACL → index metadata → query identity → ACL filter → permitted chunks → LLM

検証対象: group追加/削除、個別権限、inheritance変更、document削除、citation URL。

この判断表は、未測定の数字をそれらしく埋めるための表ではありません。価格・性能・品質など実測が必要なセルは、公式一次情報または自分の観測値だけで更新してください。

選び方・進め方

1. 判断ポイント

document-level access controlはLLMの後段ではなくretrieval時に効かせます。許可されないchunkをmodel contextへ入れない方が漏えい面で強いからです。

2. 判断ポイント

group membershipやSharePoint ACLは変化します。index作成時に一度だけcopyするのではなく差分同期と失敗alertを設けます。

3. 判断ポイント

citation URLだけ守っても本文chunk、title、metadata、summaryが漏れれば不十分です。検索結果へ含める全fieldへ同じauthorization boundaryを適用します。

実行前チェック

• identity source固定
• ACL metadata化
• query filter
• group/ACL同期
• 削除/権限縮小検証

迷ったときの優先順位

最初に不可逆な条件を確認します。契約・権限・必要メモリ・物理互換・商用権利など、後から簡単に直せない条件を先に落とし、その後に価格や操作感を比較します。逆に、価格や画面の好みから選び始めると、導入後に「そもそも要件を満たせない」状態になりやすくなります。