社内AIチャット権限管理の設計｜フィルタ方式と分離方式の選び方

社内文書を対象にしたRAG構成の社内AIチャットを検討すると、必ず「部署ごとに見せてよい情報が違う」という壁に当たります。本記事では、社内AIチャットの権限管理を実現する代表的な2つの方式「メタデータフィルタ方式」と「インデックス分離方式」を比較し、自社の組織構造と運用体制に合った選び方を整理します。

社内AIチャットのPoCが成功した後、本格展開の段階でほぼ確実に問題になるのが「アクセス制御」です。人事の給与テーブル、経営会議の議事録、開発中製品の図面。これらが検索対象に混ざったまま全社展開すれば、AIチャットは便利なツールではなく情報漏えいの経路になります。 一方で、権限を厳しくしすぎると「聞いても何も出てこないチャット」になり、利用率が落ちて定着しません。この記事では、RAG構成の社内AIチャットで部署別アクセス制御を実現する2つの代表的な方式と、その組み合わせであるハイブリッド方式を比較し、どんな組織にどの方式が向くかを具体的に示します。

比較の前提：社内AIチャットの権限管理はどこで効かせるか

まず前提を揃えます。RAG構成では、ユーザーの質問に対して(1)文書を検索し、(2)ヒットした文書をLLMに渡して回答を生成します。権限管理の要点は「LLMに渡る前の検索段階で、そのユーザーが見てよい文書だけに絞ること」です。 ここで一つ、設計上の落とし穴を先に指摘しておきます。「検索は全文書に対して行い、回答生成後に権限のない文書の引用を隠す」という後段フィルタ方式は避けるべきです。文書本文がLLMのコンテキストに入った時点で、回答文の中に権限外の情報が織り込まれてしまうためです。引用リンクを隠しても「来期の組織再編で〇〇部は統合予定です」といった回答が出れば、漏えいとしては同じことです。 したがって比較すべきは、検索段階で制御する次の2方式です。

• メタデータフィルタ方式：全社文書を1つのインデックスに入れ、検索時にユーザーの所属・権限で絞り込む
• インデックス分離方式：部署や機密レベルごとにインデックス(ナレッジベース)自体を分け、ユーザーごとに接続先を切り替える

方式1：メタデータフィルタ方式（単一インデックス＋検索時フィルタ）

全社の文書を単一のベクトルDBに格納し、各チャンクに「所有部署」「公開範囲」「機密レベル」などのメタデータを付与します。検索時には、認証基盤(Entra IDなど)から取得したユーザーの所属グループをフィルタ条件に変換し、ベクトル検索と同時に適用します。

メリット

• 部署横断で共有すべき文書(全社規程、品質マニュアルなど)を二重登録せずに扱える
• 人事異動や組織改編は、メタデータとIDグループの更新だけで追従できる
• 権限グループが20、30と増えても、インデックスの数は増えない

デメリットと注意点

• フィルタの実装ミスが即漏えいに直結する。単一障害点になるため、権限別のテストユーザーで検索結果を検証する自動テストが実質必須
• 文書登録時のメタデータ付与ルールを運用に落とし込む必要がある。「フォルダ構造から自動判定 + 例外だけ手動」の設計にしないと形骸化する
• ベクトルDB側がメタデータフィルタとベクトル検索の同時実行(pre-filtering)に対応している必要がある。post-filteringしかできない構成では、ヒット件数が不安定になったり権限外文書が混入するリスクがある

現場感としては、製造業で「品質保証部の是正処置報告書は品証と製造の管理職まで」「設備台帳は保全と製造全員」のように公開範囲が文書種別で決まっている組織と相性がよい方式です。文書種別と公開範囲の対応表を先に作れるなら、この方式の運用は安定します。

方式2：インデックス分離方式（部署別にナレッジベースを分ける）

「人事用」「経理用」「製造・保全用」のようにインデックス自体を物理的に分け、ユーザーの所属に応じて検索先インデックスを切り替える方式です。チャットのUI自体を部署ごとに分ける構成もこれに含まれます。

メリット

• 権限境界が物理的に分かれているため、フィルタのバグで越境するリスクが構造的に低い。監査部門への説明もしやすい
• 実装がシンプルで、PoC段階から本番までの距離が短い
• 部署ごとにチャンクサイズや検索パラメータを個別チューニングできる。図面中心の設計部門と規程中心の総務では最適設定が違うため、これは実務上の利点になる

デメリットと注意点

• 部署横断の文書を各インデックスに重複登録するか、共通インデックスを併設して複数インデックス横断検索にする必要があり、後者は結局フィルタ方式に近い複雑さになる
• 「製造部と品証部の両方の情報が必要」な質問に一発で答えられない構成になりやすい
• インデックス数が増えると更新パイプラインが多重化し、運用工数が線形に増える。目安として5〜6個を超えると管理が苦しくなる

方式3：ハイブリッド方式（機密レベルで分離、部署はフィルタ）

実務でよく落ち着くのがこの形です。人事・経営・M&Aなどの高機密情報だけ独立インデックスに分離し、それ以外の業務文書は単一インデックス＋メタデータフィルタで運用します。 「1件でも漏れたら重大インシデントになる情報」と「漏れても影響が限定的な情報」では、求められる保証レベルが違います。前者はフィルタの正しさをテストで担保するより、物理分離で構造的に守るほうが説明責任を果たしやすい。後者はフィルタ方式の柔軟さを活かす。この使い分けがハイブリッド方式の本質です。

3方式の比較表

運用面では、権限変更(異動・組織改編・退職)への追従工数の差が積み重なります。フィルタ方式はIDグループ連携で自動化しやすい一方、分離方式は「どのインデックスにどの文書を再配置するか」の人手判断が発生しがちです。

ケース別の推奨

ケース1：まず1〜2部署でスモールスタートしたい

インデックス分離方式を推奨します。例えば「設備保全部門の点検要領書・故障履歴」だけを対象に始めるなら、そもそも権限境界が1つしかなく、フィルタ設計は過剰投資です。ただし、全社展開時にフィルタ方式へ移行する可能性を見越して、文書登録時から所有部署と公開範囲のメタデータだけは付けておくことを強く勧めます。後付けのメタデータ整備は、文書1万件規模になると数週間単位の作業になります。

ケース2：全社展開で部署横断の質問が多い

メタデータフィルタ方式が本命です。「この不具合の是正処置と、関連する設備の保全履歴を教えて」のような横断質問は、社内AIチャットの価値が最も出る場面であり、分離方式では答えられません。認証基盤のグループと文書メタデータの対応表を設計の起点にし、権限パターンごとのテストユーザーを最低でも部署数×役職階層ぶん用意して、リリース前に検索結果を検証してください。

ケース3：人事・経営情報も対象に含めたい

ハイブリッド方式一択です。高機密情報を一般文書と同じインデックスに入れる構成は、技術的に可能でも、情報セキュリティ部門や監査の承認が下りにくく、プロジェクトが止まる原因になります。「高機密は物理分離しています」と言えるかどうかが、社内稟議の通りやすさを大きく左右します。

選択の決め手：権限の「真実の源泉」と漏えい時の影響度

最後に、方式選定の決め手を2つに絞ります。 1つ目は、権限情報の真実の源泉(Source of Truth)を一元化できるか。Entra IDやActive Directoryのグループが整備されており、それをそのままフィルタ条件に使えるなら、フィルタ方式の運用は安定します。逆に、権限がファイルサーバーのフォルダ設定や各部署の暗黙ルールに散らばっている組織では、フィルタ方式は「誰が正しいのか分からない権限表」との戦いになります。その場合は、境界の少ない分離方式で始めながらID基盤の整備を並行するのが現実的です。 2つ目は、越境が1件起きたときの影響度。影響が「気まずい」で済む情報ならフィルタ方式の柔軟さを取り、「懲戒・訴訟・株価」に関わる情報なら物理分離で構造的に守る。この線引きを情報資産の棚卸しとして最初にやっておくと、方式選定だけでなく、対象文書の優先順位付けや稟議資料にもそのまま使えます。権限設計は後から直すほど高くつく領域です。チャットの回答精度より先に、まずこの線引きから着手することをお勧めします。