- 公開日
AIの接続アカウントが資料を読めても、その資料を今回の利用者へ見せてよいとは限りません。社内検索では、利用者本人の権限と、処理のために使うアカウントの権限を分け、許可されない資料を検索候補や回答の根拠へ入れないようにします。判断はモデルの外で行い、情報を渡す前に強制する必要があります。
「社内につながっている」「ログイン済み」「検索結果に出てきた」は、それぞれ接続や処理の状態を示すだけです。その資料を、その人が、その目的で使えるという認可の確認を置き換えません。読み取り専用のAIでも、見せてはいけない情報を取得・要約すれば問題が起きるため、更新権限の有無だけでは評価できません。
接続のための主体と、回答を受け取る主体を分ける
技術的な到達性とは、ネットワークや認証情報、検索索引を通じて資源へ届くことです。認可は、特定の主体が特定の資源へどの操作をしてよいかを判断することです。社内検索のサービスアカウントが全社資料を取り込めるのは、索引を作る業務に必要な権限かもしれませんが、その権限をすべての検索利用者へ移してよいことにはなりません。
NIST SP 800-207は、ネットワーク上の位置や所有関係だけで暗黙の信頼を与えず、資源へのアクセスを重視するゼロトラストの考え方を説明しています。社内ネットワークにいるという事実だけで、全資料へのアクセスを許すべきではないという整理の根拠になります。Zero Trust Architecture
この区別は、チャットの表示名だけでは実現できません。「営業担当です」という本文を本人確認の代わりにせず、認証されたセッションから利用者の識別子を取得します。検索を代行するサービス、元の依頼者、結果を表示する相手を、処理を通じて対応付けます。
一人の利用者が複数の組織に属する場合は、利用者IDだけでは境界が足りません。どの組織のデータを使う依頼かも確定させます。同じメールアドレスで複数の作業領域へ参加していても、ある組織で得た資料を別組織の会話へ自動的に持ち込まない設計にします。
同じ質問へ、異なる許可範囲で答える
架空の社内検索を考えます。検索用アカウントは、全社員向けの「出張手続」、営業部向けの「案件管理手順」、人事部限定の「評価運用メモ」を読めるとします。利用者甲は営業部所属で、最初の二つだけを参照できます。利用者乙は人事部の対象担当者で、全社員向け資料と評価運用メモを参照できます。
二人が同じく「今期の申請や承認の手順を整理して」と質問しても、AIへ渡してよい材料は同じではありません。甲には出張手続と案件管理手順の範囲で答え、乙には出張手続と、依頼に関係する評価運用メモの範囲で答えます。人事部所属という属性だけで人事資料すべてを読めるとはせず、資料ごとの実際の許可に従う前提です。
検索用アカウントが三資料を読めるからといって、すべてをAIへ渡し、「甲には人事情報を書かないで」と後から頼む方法では、取得とモデル入力の段階で境界を越えています。回答に現れなくても、モデルへ渡された情報、処理ログ、会話履歴へ残る可能性を別に考える必要があります。
この例で望む結果は、甲の検索では、人事資料の本文だけでなく、機密性がある題名や要約も利用者向けの候補から除かれることです。「関連する非公開資料が一件あります」と知らせること自体が、その存在を明らかにする場合があります。拒否の説明は、利用者へ開示してよい範囲で行います。
候補を作る段階から権限を適用する
検索では、入力した質問から候補を取り出し、並べ替え、本文を集め、AIへ渡し、回答を表示する工程があります。認可を回答の直前だけに置くのではなく、候補と本文が外へ渡る位置を確認します。検索基盤の内部処理として許された範囲と、利用者やモデルに返す範囲も区別します。
実装上は、利用者の権限に対応した検索条件をシステム側で付与し、許可された資料だけを返す方法があります。MicrosoftのAzure AI Searchの公式資料は、グループや利用者の識別子を文書に関連付け、検索結果を絞るセキュリティフィルタの方式を説明しています。同資料は、この方式の識別子はフィルタ用の文字列であり、それ自体で本人確認や認可が行われるわけではないことも明記しています。また、この方式を、文書単位の認可に組み込みのACL機能を使えない場合の手段として位置付けています。Security filters for trimming results
したがって、AIや画面から任意のグループIDを受け取り、そのままフィルタに入れるだけでは不十分です。どのグループに属しているかは信頼する認証・権限情報から取得し、フィルタの欠落や書き換えを許さないようにします。フィルタ方式を使ったという名称だけで、安全性が成立したことにはなりません。
対象文書に権限情報がない場合も注意が必要です。「空欄だから全員に公開」とするかどうかをモデルに判断させません。少なくとも、公開と確認できない資料を利用者へ返さない方針を定め、所有者が権限情報を修正するまで検索対象から外します。既知の公開資料には、その状態を明示的に付けるなど、欠損と公開を区別します。
モデルへ渡す直前でも、対象と権限を照合する
検索結果が権限制御されていても、後続処理が別の経路で本文を取得すると、同じ制限が保たれない場合があります。例えば検索結果の文書IDを使い、権限の広い取得APIで本文を取り直す構成です。本文取得でも、元の利用者と対象の組み合わせを検証します。
OWASPの認可ガイドは、権限確認を信頼できるサーバー側など適切な場所で行い、利用者側の表示制御だけに頼らないことを推奨しています。AIシステムでも、モデルが「許可済み」と返した文章を認可結果として使うのではなく、実行側の判定を使用します。Authorization Cheat Sheet
文書を短い断片に分けて検索する場合は、断片にも元文書の権限と来歴を対応付けます。本文だけを別の索引へコピーして権限情報を落とすと、元資料を制限していても別経路から出てしまいます。添付ファイル、要約、翻訳も、元の情報を含む限りはアクセス条件を引き継ぐ必要があります。
ただし、元文書の権限を付ければ常に足りるわけでもありません。複数資料をまとめた回答には、それぞれ異なる開示条件が含まれ得ます。回答を見せる相手が、使用したすべての情報を受け取ってよいかを確認し、条件が違う相手へそのまま転用しないようにします。
実行中に変わる権限を扱う
利用者の異動、共有解除、文書の機密区分変更などで、権限は検索開始後にも変わり得ます。検索時点で許可されたからといって、長時間後の回答生成や再表示にも同じ許可が続くと仮定しません。処理の長さと情報の重要性に応じて、どの段階で再確認するかを定めます。
例えば甲が案件管理手順を検索した後、部門変更によって参照権限を失ったとします。まだモデルに資料を渡していないなら、取得済みの内容を入力へ進めず、権限を再評価します。既に渡してしまった場合は、回答を止めるだけで情報の送信が取り消されたとは扱えません。どこまで処理されたかを確認し、必要な記録と担当者への引き継ぎを行います。
このとき、対象の本文を広くログへ転記して事故調査を進めると、別の情報拡散を作るおそれがあります。記録には利用者、処理ID、対象ID、判定、時刻、使用した権限情報の版などを残し、内容自体の保存は調査に必要な範囲とアクセス権で管理します。
失効の反映に遅延がある仕組みでは、その遅延中に何が起こり得るかを把握します。許可情報の更新頻度を上げる、重要資料は表示前に原本の権限を再確認するなどの方法がありますが、応答時間や運用費用も増えます。そのため、資料の重要度ごとに失効を何分以内に反映させたいかを決め、実装していない即時失効を利用者や管理者へ約束しないようにします。
拒否、資料なし、確認不能を分けて返す
検索結果が空でも、「その情報は社内に存在しません」とは限りません。利用者に許可された範囲で見つからなかったのか、検索に失敗したのか、認可を確かめられなかったのかを分けます。利用者向けの説明では、非公開資料の存在を明かさないよう「確認できる範囲では見つかりませんでした」とまとめることがありますが、運用側の記録では原因を区別できるようにします。
架空の検索での分岐は次のように設計できます。これは確認項目の例で、試験済みの結果ではありません。
| 状態 | モデルへ渡す情報 | 利用者への応答と次の対応 |
|---|---|---|
| 甲の許可範囲から関係資料を取得できた | 許可資料の必要部分 | その範囲で回答し出典を示す |
| 許可された範囲に該当資料がない | 資料を作って補わない | 確認できる範囲では見つからないと伝える |
| 利用者の識別が不明 | 保護資料を渡さない | 本人確認の回復まで保留する |
| 権限判定サービスが応答しない | 未確認の資料を渡さない | 認可確認の障害として止める |
| 取得後に対象の許可が取り消された | 未送信分は渡さない | 対象処理を停止し、必要なら許可資料のみで作り直す |
| 本文取得の応答が返らない | 取得できたと仮定しない | 結果不明を記録し、権限を再確認して再取得を判断する |
検索は読み取りでも、問い合わせ内容や資料を処理先へ送る行為を伴います。応答が返らないからといって、相手側が何も受け取っていないとは限りません。再試行を決める際は、送信先、対象、依頼の有効性、APIの利用制限を確認し、不要な情報を繰り返し送らないようにします。
保留したままでは利用者が次に何をすればよいか分からないため、確認先を具体化します。資料の権限情報が欠けているなら文書管理者、利用者の所属情報が取れないなら認証基盤の担当者へ引き継ぎます。AIが代わりの広いアカウントを探して処理を通すことは、回復手段にしません。
キャッシュと共有会話にも境界を残す
一度作った回答を保存して再利用する場合、質問文だけをキーにすると、甲への回答が乙に返る可能性があります。回答キャッシュには、利用主体、組織、許可範囲、元資料の版など、アクセス判断に必要な条件を含める設計を検討します。条件が一致しないなら、同じ質問でも結果を共用しません。
逆に、利用者IDを含めれば終わりでもありません。同じ人の権限が変わった後に、以前の回答を再表示してよいかを判断する必要があります。キャッシュを無効化する条件と、表示前の再認可を組み合わせ、古い回答が失効後も入口にならないようにします。
共有チャットでは、依頼者本人が閲覧できることと、会話の参加者全員が閲覧できることが異なります。個人向けに許可された資料を、共有の場へ自動投稿しない設計にします。必要なら、共有可能な資料だけで答える、許可された個人向けの経路へ切り替えるなど、送信先の条件に合わせます。
これらの制限は、検索性能の調整とは別の問題です。関連性の高い資料でも認可されていなければ使用できず、認可されていても質問と無関係なら入力する必要がありません。アクセスの適否と、回答に必要かどうかの二つを通して、渡す資料を選びます。
正当な回答が残ることまで確認する
導入時には、架空の部署、利用者、文書を作り、同じ質問に対して許可範囲だけが変わる例を確認します。試験では検索候補、本文取得、モデル入力、引用、キャッシュ、共有先まで追い、拒否対象の内容がどの段階にも利用者向けに漏れないかを見ます。漏えいするかの確認に、実在の機密資料は使いません。
同時に、甲が閲覧できる案件管理手順まで一律に止まっていないかも確認します。権限外の情報を遮断できても、正当な検索がすべて失敗するなら業務では使いにくいためです。拒否と正当な継続を別に記録し、欠損した権限情報や絞り込み条件を修正します。
単一の正常例だけでは、索引更新の遅れやキャッシュの誤用は見つかりません。権限を取り消した後、利用者を切り替えた後、検索基盤が部分的に応答しないときの例も用意します。期待する判定と実際のログが一致しなければ、公開範囲を広げずに原因を直します。この記事で述べた確認は設計案であり、特定の製品構成の合格を示すものではありません。
「アクセスできた」から「回答に使ってよい」へ進む間には、利用主体、対象、処理時点、出力先の確認があります。接続アカウントの広い権限を利用者へそのまま渡さず、候補から回答の再利用まで境界を保つことで、社内検索を実際の業務権限と結び付けられます。
AIエージェントの認証・認可・委任の基本は「AIは誰の権限で動くのか 認証・認可・委任の基本」で解説しています。
基本から確認する：この記事の前提になる考え方は、「AIエージェントの安全設計（権限・外部資料・承認・検証の基本）」にまとめています。
