生成AIのDLP設計｜入力・出力・検索・ログで機密データを止める【2026】

生成AIのデータ漏えい対策を「利用者に注意してもらう」だけで終えると、貼り付けたprompt、参照した文書、外部検索へ渡った語句、モデルが返した回答、運用ログのどこから漏れたのかを説明できません。DLP（Data Loss Prevention）は、機密データらしき値を検知する製品機能の名前であると同時に、どの境界で検知し、何を止め、誰が例外を判断するかという設計です。

重要なのは、すべてのデータを一律に遮断することではありません。業務に必要な情報まで止めれば、利用者は管理外の経路へ移ります。反対に、検知だけして送信を続ければ、DLPはアラートを増やすだけになります。データ区分、送信先、操作目的、外部公開の有無に応じて、block、警告、マスキング、承認、記録を分けます。

第一の境界は、モデルへ送る前の入力

prompt、添付ファイル、toolに渡す引数は、最初に外部へ出る可能性がある地点です。Cloudflare AI GatewayのDLPは、providerへ送るpromptと返ってくる応答の両方を検査する機能を示しています。ここでは、個人番号や認証情報など、用途を問わず送信させない区分はblockします。一方、契約番号など業務上必要な値は、送信先・利用目的・契約条件が満たされる場合だけ許容し、検知した事実を残します。

検知対象は、既製のパターンだけでは足りません。顧客コード、社内の案件名、製品の未公開名称のように、組織固有の値は分類ルールへ追加する必要があります。Google Cloud Sensitive Data Protectionは、正規表現、辞書、保存済みの大規模辞書などのcustom detectorを提供しています。DLPを導入する前に、何を個人情報、営業秘密、認証情報、外部公開不可として扱うかを、業務・法務・情シスで定義します。

検索・groundingは別の経路として制御する

機密値を含むpromptを止めても、エージェントが外部web検索、外部メール、RAGの文書を根拠にすれば、別の漏えい・影響経路が残ります。Microsoft Purview DLPは、機密情報を含むpromptでは外部web検索をgroundingに使わせない、機密ラベル付きのファイルやメールを処理に使わせない、といった制御を案内しています。外部メールをgroundingから除外する機能は、信頼できないコンテンツがprompt injectionとして影響する経路を減らす目的でも説明されています。

ここでDLPを認可の代わりにしないことが大切です。RAGの権限漏れを防ぐで扱うように、「誰がその文書を参照してよいか」は認可の問題です。DLPは、認可済みの情報でもどの経路へ出してよいかを補助的に判断します。document、利用者、モデル、外部接続先ごとの境界を混ぜないでください。

回答とログにも、別の方針を置く

回答側では、入力に含まれていない機密情報をRAGやtoolから取り出して表示するリスクがあります。出力スキャンは、表示・送信の直前に検知してblockまたはreviewへ回す境界です。ただし、streaming応答でCloudflare AI Gatewayのresponse scanningを有効にすると、providerの応答全体をbufferしてから検査します。応答をすぐ表示する体験との両立、timeout、失敗時の画面表示を実装前に確認します。

ログも独立した境界です。AIエージェントの監査ログ設計のとおり、調査に必要な実行ID、model、tool、statusは残しても、promptと応答の全文を既定で保存する必要はありません。AI Gatewayは、payload保存を止めながら、token使用量、model、provider、status、cost、durationといったメタデータを残せます。検知した原文を調査目的で保存する場合は、閲覧権限、暗号化、保持期限、削除手順を分離します。

まず監視し、例外を調整してから止める

初日から広いルールで全件blockすると、通常業務まで止めて回避経路を生みます。MicrosoftのCopilot向け既定DLP policyもsimulation modeでは検知を記録し、実際にprompt処理をblockするにはenforce modeへ切り替える設計です。これは検知ルールが安全でないという意味ではなく、対象業務に不要な検知を外し、影響を確認してから強制する工程が必要だということです。

運用では、検知件数だけを成功指標にしません。どのデータ区分・経路で検知したか、block後に正当な業務が止まったか、例外申請が繰り返されていないか、検知されずに事故が起きていないかを分けて見ます。Google Cloudが示すマスキング、置換、tokenizationといった変換も、目的に応じて選びます。分析で同一人物・案件を結び直す必要がある場合だけ、鍵管理を分離した可逆tokenを検討し、不要なら削除・非可逆化を優先します。

導入前の最小チェックリスト

prompt、添付、tool引数、grounding、回答、ログの各経路を書き出したか
データ区分ごとにblock、警告、マスキング、承認、記録のどれを使うか決めたか
固有の顧客コードや案件名を、検知対象へ追加する責任者を決めたか
simulationの結果から、誤検知・業務影響を確認してからenforceへ進むか
DLP、認可、データ保持と削除を別の制御として設計したか

TechWorkerでは、内製AIツールで扱うデータを棚卸しし、モデル呼出し、検索、tool、ログのそれぞれに必要なDLPと権限境界を設計します。利用を止めるためではなく、業務に必要な情報を必要な経路だけで安全に扱える状態を作ります。

限界と確認範囲

DLPのpattern検知には誤検知・見逃しがあります。機密語を含まない営業秘密、文脈に依存する個人情報、画像や暗号化された添付は、設定だけで完全に判定できません。DLPは、送信先との契約、目的外利用、利用者の権限、prompt injectionを単独で解決するものでもありません。高影響の送信・公開には認可、承認、監査を重ね、検知ルールと製品の対応範囲を導入時に公式資料で再確認してください。

一次情報と確認範囲

確認日：2026年9月11日。製品仕様・制度は更新されるため、導入時はリンク先の最新版を再確認してください。海外の制度・職業規範は日本へ直接適用せず、相違点と限界を本文に明記しています。