Endpoint to Prompt時代のDLP設計: 企業向け生成AIデータ保護

Cloudflareが示した「endpoint to prompt」という考え方は、生成AI時代の本質を突いています。機密情報の流れは、もはやDBやSaaS保存先だけを見ていても追えません。実際には、端末、ブラウザ、プロンプト、RAG、モデル応答、そして再共有先まで連鎖します。

つまり企業のデータ保護は、“どこに保存されているか”中心の発想から、“いつ・誰が・何を・どの文脈で扱ったか”中心の発想に移行する必要があります。

従来DLPが足りなくなる理由

従来の経路は比較的固定でした。

端末 → 業務アプリ → DB

一方、生成AIでは可変経路が増えます。

社員がチャットUIへ入力
RAGが複数データソースから文脈を組み立て
出力がチケット/ドキュメント/コードへ貼り付け
エージェントが別ツールへ再投稿

この構造では、境界防御だけでは漏えいを止められません。

実装すべき4層の制御

1. 端末・ID起点のアクセス制御

プロンプト送信前に以下を判定します。

ユーザーIDとロール
端末健全性（管理端末/非管理端末）
セッションリスク（場所、時刻、挙動）
利用可能モデルの範囲

同じ社員でも、管理端末と私物端末で権限を同一にしないことが重要です。

2. プロンプト時点での分類・マスキング

送信中の本文を検査し、ポリシーを即時適用します。

APIキー/認証情報パターン
ソースコード内シークレット
個人情報（PII/PHI）
機微な経営情報（法務・M&A・決算関連）

判定結果は「許可 / マスク / 承認要求 / ブロック」を明示的に返す設計が有効です。

3. RAGの権限整合

現場で最も事故が多いのはRAG権限の不整合です。

ベクトル索引が過剰共有される
元システムACL変更が索引側へ反映されない
取り込み時に機密区分メタデータが欠落する

対策は単純で、取り込み時だけでなく検索時にも文書単位の認可を再評価することです。

4. 出力側の統制

入力が安全でも、出力が安全とは限りません。

応答を表示前に再分類
出力に由来情報（provenance）を付与
外部ツールへのコピー/エクスポートを制御

法務・人事・セキュリティ業務では、この出力統制が特に効果を持ちます。

リスク階層ごとの運用

全社共通の単一ルールは破綻しやすいため、3階層で設計します。

Tier 1（低リスク）: 公開情報、一般調査、軽微な開発補助
Tier 2（管理対象）: 顧客関連情報、社内設計資料、ロードマップ
Tier 3（高リスク）: 財務、法務特権、本番機密、規制対象データ

階層ごとに、利用モデル、保持期間、監査粒度、承認フローを分けるのが実務的です。

インシデント対応をAI前提で再設計する

漏えいをゼロにはできません。重要なのは封じ込め速度です。

異常なプロンプト/応答パターンを検知
高リスクセッションを即時凍結
生成物の拡散先（PR/Doc/Chat）を追跡
露出シークレットのローテーション
事後分析でポリシーとテストを更新

この手順を決めていない組織は、初動で必ず遅れます。

指標設計

ポリシー別ブロック率
マスキング誤検知率
アラート初動時間
RAG権限不整合件数
セッション1,000件あたりの機密出力流出件数

導入効果は「使われた回数」ではなく、事故率を抑えながら業務速度を維持できたかで評価してください。

参考トレンド

Cloudflare Blog: From the endpoint to the prompt
Cloudflare Blog: endpoint enforcement / insider threat対策関連記事