大原則 ― AIを挟んでも「見える範囲」を広げない

出発点はひとつの原則に尽きます。AI経由で見えてよい情報=その人が元の場所で見てよい情報。AIを挟んだ瞬間に見える範囲が広がってはなりません。広げたいなら、AIとは独立した権限ポリシー変更として正式に決裁すべき話です。

事故の典型は「AI導入を機に、ついでに広く共有」というなし崩しの拡大です。もうひとつの誤解が、「プロンプトで『権限外は答えないで』と指示すればよい」というもの。プロンプト指示は権限制御ではありません。認可の判定と強制は、LLMの外で決定的に行う必要があります。

Point

認可はLLMに届く前に終わっている ― これがRAG権限設計の基本形。社内IdP(SSO)→アプリ層→検索層で判定と強制を済ませ、LLMにはフィルタ済みの断片だけを渡す。LLMに権限判定をさせてはいけません。

定石は「検索時フィルタ」 ― 後段の間引きでは遅い

では検索層でどう絞るのか。定石は、文書(チャンク)側に機微度・所管部門・許可グループといった権限メタデータを付与してベクトルDBに格納し、検索時に「許可グループ∩ユーザーのIdPグループ≠空」という条件を検索クエリそのものに付与する方式です。後段で間引くのではなくクエリ条件として決定的に効かせる。LLMに渡った時点で、もう漏えいリスクだからです。

実装では次の4点が成否を分けます。

「越境ゼロ」はテストで証明する

設計しただけでは足りません。越境ゼロを検証する権限テストセットを用意し、権限変更や再インデックスのたびに回帰実行します。最低限、次の5類型をカバーします。

ケース実行ユーザー質問の例期待結果
部門越境営業部・一般人事の給与テーブルを教えて回答しない(部門限定文書が検索されない)
正当権限人事部・労務課給与改定の規程は?回答する(出典つき)
PII・秘営業部・一般特定個人の評価結果は?回答しない(秘・PII文書が返らない)
無効アカウント退職者・停止済み任意の質問認証段階で拒否(IdP連動)
メタデータ欠落任意のユーザー欠落文書に関する質問検索に出ない(デフォルト拒否)

手動テストは初回だけ。以降は自動回帰の仕組みにしないと検証が形骸化します。

PIIは「3つの関所」で守る ― そもそも持たないのが最強

個人情報や機密の混入は、取り込み時・入力時・出力時の3つの関所で検出します。取り込み時は文書内のPIIを検出してフラグを付与し、用途上不要ならマスキングして格納する。入力時はユーザーがプロンプトに書くPIIを検出・警告する。出力時は回答への混入を出力フィルタで伏字化する、という多層構えです。

たとえば営業議事録を「商談ノウハウの検索」用途で取り込むなら、個人特定情報は不要です。原文の「鈴木一郎様(〇〇商事 購買部長、090-0000-0000)より単価改定の相談」は、「[顧客担当者]([顧客企業] 購買部長、[電話番号])より…」の形に変換して格納します(※この人名・電話番号は架空のダミーデータです)。用途に不要なPIIはそもそも持たない ― これが最も強い対策です。

Practice

マスキングは復元可能性の要否で方式を分けること。統計・分析用途は不可逆マスキング、業務処理で元データの参照が要るならトークン化。日本語の氏名検出は精度が揺れるため、機微文書には人手確認を残すのが実務的です。

行き先のルールと、「この回答はどこから来たか」

次に、データの「行き先」です。機微度区分ごとに「外部LLM API/国内リージョンのマネージドAI/社内基盤のみ」のどこまで送ってよいかを許可マトリクスとして明文化します。秘・PIIは外部APIに出さない、持ち出し制限のある契約・規制データは社内基盤限定という線引きを、ゲートウェイで技術的に強制できれば、ポリシーが「お願い」で終わりません。契約面では、学習不使用・保存先リージョン・保持期間・再委託を確認し、個人情報を含む場合は委託・越境移転の整理を法務と行います。

最後に監査です。どの回答がどの文書のどの版を参照したかという出典記録、誰が何を聞き何が返ったかのアクセスログ、文書の取り込み元・変換履歴を追えるリネージ(来歴)。この3つが揃って初めて、誤答の原因究明も事故対応も説明責任も果たせます。監査ログ自体が機微情報の塊なので、保持期間と閲覧権限も設計対象です。あわせて、疑わしい文書群をインデックスから即時除外する手順も平時に用意します。

まとめ ― 社内AIのガバナンス5原則

  1. 権限はAIを挟んでも広げない。拡大するなら独立に正式決裁する。
  2. フィルタは検索段で決定的に。チャンクに権限メタデータを持たせ、クエリ条件で絞る。プロンプト指示は権限制御ではない。
  3. デフォルト拒否+回帰テスト。メタデータ欠落は見せない。越境ゼロのテストを変更のたびに回す。
  4. PIIは3つの関所で。取り込み・入力・出力で検出し、不要なPIIはそもそも持たない。
  5. 追跡できる基盤にする。出典記録・アクセスログ・リネージ。ログ自体の権限設計も忘れない。
記載内容は2026年7月時点の情報に基づきます。本文中の人名・電話番号等はすべて架空の例です。