AI に社内ナレッジをどこまで引かせるか — 境界は「判定主体 × 遮断位置」で引く

結論: 境界は「判定主体 × 遮断位置」の表で引く

私たちは、社内ナレッジを AI に参照させる前に、「何を根拠に許可するか」と「どの処理で止めるか」を並べて決めることを提案する。以下の表は、本記事の設計用の整理であり、業界標準や製品の機能一覧ではない。

Microsoft の資料では、利用者のアクセス権限を基礎とし、感度ラベルを追加の保護層としている。ラベルと権限は同じものではない。¹ また、プロンプトと応答の機微情報を分類する機能も説明されている。分類結果を得ることと、操作を許可することも分けて考えたい。²

すべての欄に製品を追加することが目的ではない。自社の情報経路に必要な制御と、その担当を明らかにするための表である。

判定主体は 4 つに割れる

ここでは判定の根拠を、権限、ラベル、内容の検出、構造による分離の 4 つに整理する。相互に排他的な分類ではない。

権限とラベルを重ねる例が Microsoft の設計である。¹ 内容の検出では、Amazon Macie が機微データの種類に対応する識別子を提供する。ただし、データを検出できることだけで、LLM への参照許可が自動的に決まるわけではない。³

構造による分離の例には Pinecone の namespace がある。読み書きや検索は指定した namespace を対象とするため、顧客ごとにデータを分けられる。どの利用者にどの namespace を選ばせるかは、アプリケーション側で設計する必要がある。⁴

これらを「AI が安全か」という問いだけで一括評価すると、責任の所在が曖昧になる。まず、自社の各処理が何を判定根拠にしているかを書き出したい。

分類軸は、どこを起点にするかで形が変わる

分類体系を選ぶときには、その体系が何を分類しているかを確認する。Microsoft の感度ラベルには、機微性の段階と共有範囲を組み合わせた親子ラベルの例がある。これは設定例であり、すべての組織に同じ区分を求めるものではない。⁵

NIST SP 800-60 は情報の種類とセキュリティカテゴリの対応を扱う。FIPS 199 は機密性、完全性、可用性への影響を評価する枠組みである。⁶⁷ これらを、そのまま AI の閲覧権限表とみなすことはできない。

自社の分類表には、分類の目的と、その分類を受け取って動く制御をセットで書くことを提案する。「人事情報」という種類と「誰が閲覧できるか」という許可条件は、別々に記録した方が設計を点検しやすい。

遮断位置は 4 か所に配れる

本記事では、取り込み、検索、モデルへの受け渡し、外部操作という 4 つの位置で制御を点検する。これは処理を見落とさないための整理である。

Kendra は文書と一緒に ACL を取り込み、検索時の利用者情報を使って結果を絞る。取り込み時に情報を持たせることと、検索時にそれを使うことを分けて設計している。⁸

Microsoft は、感度ラベルで暗号化したデータを AI が返す条件として VIEW と EXTRACT の使用権を説明している。これは権利の検査であり、生成後の文章を分類器で検査する処理とは異なる。⁹

MCP の 2025-06-18 版認可仕様では、サーバーはリクエスト処理前にアクセストークンを検証し、自分を対象に発行されたものか確認する。¹⁰ 認可を使う HTTP 通信についての規定であり、すべてのローカルツール呼び出しに同じ仕組みが自動適用されるわけではない。¹¹

実装例を同じ 2 軸へ並べる

特に Kendra は、user context filtering 自体は認証・認可の制御ではないと明記している。検索に渡す利用者情報が正しいという前提を、呼び出し側が満たさなければならない。¹²

この比較から提案したいのは、製品の機能名の隣に「自社アプリが担う責任」を書くことだ。表にない機能を、その製品に存在しないと断定するための比較ではない。

粒度は細かくするほど良いわけではない

Microsoft の感度ラベルの資料は、利用者が扱うラベルとサブラベルを少数に抑えることを勧めている。分類の細かさを決める際には、利用者が選べるか、運用を維持できるかも確認したい。¹⁴

Pinecone ではメタデータが検索フィルタの材料になる。何をフィルタ可能にするかは、データ設計時に考える事項である。¹⁵ これはラベル数の推奨とは別の論点なので、混ぜて扱わない。

私たちの提案は、まず代表的な利用者と文書の組み合わせについて期待結果を決め、その区別に必要な属性を揃えることだ。分類を増やす前に、条件が欠けた文書や利用者をどう扱うかも決めておく。

分類漏れと過剰遮断、どちらが起きやすいかは比較できない

今回の設計資料だけでは、分類漏れと過剰遮断の発生率は比較できない。たとえば Kendra の資料はフィルタリングの仕組みと責任範囲を説明するもので、自社の誤許可率や誤拒否率を示す資料ではない。¹²

そこで、権限内の要求が通るかと、権限外の要求が止まるかを、同じ評価セットで記録することを提案する。利用者や文書の種類を揃えず、外部の事例件数だけで優先順位を決めることは避けたい。

拒否の件数だけでなく、正しく拒否したのか、許可すべきものまで拒否したのかを確認する。本文に挙げた製品の性能順位は、この資料からは付けられない。

漏えい経路は入力・出力・ツール利用の 3 つ

点検の入口として、入力、出力、外部ツール利用の 3 経路を分ける。これは本記事の確認用の整理であり、発生件数による順位ではない。

入力側では、Microsoft がブラウザ経由で生成 AI サイトへ機微情報を貼り付ける操作に対し、Endpoint DLP で警告または遮断する例を示している。¹⁶

出力側を含む監視では、プロンプトと応答の双方を機微情報の検出対象としている。検出と実際の遮断を同じ機能として扱わず、どのポリシーが操作を止めるか確認したい。²

外部ツール利用では、MCP の認可仕様が求める宛先検証に加え、受け取ったトークンを下流 API にそのまま渡さないことも確認点になる。¹⁷ サービス間の認可を、検索結果のフィルタだけで代替することはできない。

まとめ: 表の空白を埋める順に設計する

最初に、利用者、文書、検索先、外部操作を並べ、誰が何を許可するかを記録する。次に、アプリケーションと接続先の責任を分ける。Kendra のフィルタに利用者認証を任せられないという注意書きは、この分担を具体的に示している。¹²

そのうえで、許可すべき要求と止めるべき要求を試し、満たせない条件を修正する。私たちは、ラベルを先に増やすより、この確認表を埋める順で設計を進めることを提案する。空欄には、未対応なのか、今回の構成では不要なのか、その理由も残したい。

Footnotes

1. Microsoft Purview data security and compliance protections for Microsoft 365 Copilot and other generative AI apps ↩ ↩²

2. Microsoft Purview data security and compliance protections for Microsoft 365 Copilot and other generative AI apps ↩ ↩²

3. Discovering sensitive data with Macie - Amazon Macie ↩

4. Index data overview - Pinecone Docs ↩ ↩²

5. Learn about sensitivity labels ↩

6. Guide for Mapping Types of Information and Information Systems to Security Categories ↩

7. Standards for Security Categorization of Federal Information and Information Systems ↩

8. Filtering on user context - Amazon Kendra ↩ ↩²

9. Microsoft Purview data security and compliance protections for Microsoft 365 Copilot and other generative AI apps ↩

10. Authorization - Model Context Protocol ↩ ↩²

11. Authorization - Model Context Protocol ↩

12. Filtering on user context - Amazon Kendra ↩ ↩² ↩³ ↩⁴

13. Index data overview - Pinecone Docs ↩

14. Learn about sensitivity labels ↩

15. Index data overview - Pinecone Docs ↩

16. Microsoft Purview data security and compliance protections for Microsoft 365 Copilot and other generative AI apps ↩

17. Authorization - Model Context Protocol ↩