【実務・中級編】生成AI利用時の機密情報漏洩を防ぐDLP(Data Loss Prevention)統合 – ガバナンス・リスク管理 & 生成AIセキュリティ防御ガイド

生成AI時代のDLP：プロンプトに潜む「デジタルな生贄」をどう防ぐか

現場で戦うエンジニア諸君、お疲れ様。
最近、「社内ツールにChatGPTを組み込んだので、あとはよろしく」という無茶振りをされたことはないか？多くの現場で、LLMの利便性に目が眩み、セキュリティというブレーキを後付けで考えようとしている。だが、AI時代において「とりあえずアクセス制限」という旧態依然としたアプローチは、もはや無防備に等しい。

今日は、プロンプトを介した情報漏洩を防ぐための「AIゲートウェイ」の実装について、泥臭い実務の視点から話そう。

1. なぜDLPゲートウェイが必要なのか？（攻撃者の視点）

攻撃者は、LLMのAPIを直接ハックするような派手なことはしない。彼らが狙うのは「インジェクション」と「学習データ汚染」だ。

例えば、ユーザーがチャット画面で「このソースコードのバグを見つけて」と、顧客の個人情報が含まれたログや、ハードコードされたAPIキーを無意識に貼り付ける。これがLLM側の学習データに吸い上げられたら最後、プロンプト・インジェクションによって他人がその情報を引き出せるようになる。これが「デジタルな生贄」の正体だ。

我々が実装すべきは、LLMにデータが届く手前で、特定のパターン（PIIや秘密鍵）を検知し、マスキングまたはブロックする「中継層（ゲートウェイ）」である。

2. Pythonによる軽量ゲートウェイの実装例

複雑なDLP製品を導入する前に、まずはプロキシ層で正規表現とライブラリを組み合わせた簡易マスキングを実装しよう。ここでは、Pythonの FastAPI を用いたプロキシの構成例を示す。

import re
from fastapi import FastAPI, Request
import httpx

app = FastAPI()

# マスキング対象のパターン（例：クレジットカード番号、AWSアクセスキー）
PII_PATTERNS = {
    "CREDIT_CARD": r"\b(?:\d[ -]*?){13,16}\b",
    "AWS_KEY": r"AKIA[0-9A-Z]{16}"
}

def mask_pii(text: str) -> str:
    """プロンプト内の機密情報を検知し、[MASKED]に置き換える"""
    for label, pattern in PII_PATTERNS.items():
        text = re.sub(pattern, f"[{label}_MASKED]", text)
    return text

@app.post("/chat")
async def chat_proxy(request: Request):
    data = await request.json()
    raw_prompt = data.get("prompt", "")
    
    # 送信前にマスキング処理
    safe_prompt = mask_pii(raw_prompt)
    
    # ここでLLMのAPI（OpenAI等）を呼び出す
    # async with httpx.AsyncClient() as client:
    #     response = await client.post("https://api.openai.com/...", json={"prompt": safe_prompt})
    
    return {"status": "success", "processed_prompt": safe_prompt}

3. 「完璧」を求めすぎないための運用ルール

このコードを見て「これだけで十分か？」と思った君は鋭い。実際、正規表現だけでPIIを100%防ぐことは不可能だ。名前や住所といった非定型データは、spaCy や Presidio といったNLPライブラリを使って、名前、組織名、住所を識別する「エンティティ認識」を組み合わせるのが正攻法だ。

しかし、現場で重要なのは「完璧な検知」よりも「責任の所在を明確にする境界線」だ。

ログの分離: マスキング前のプロンプトをアプリ側のログに絶対に残すな。これはインシデント発生時の証拠になるが、同時に宝の山だ。アクセス権限を厳格に絞れ。
エラーハンドリング: マスキング処理が重すぎてレイテンシが発生すると、ユーザーは設定をバイパスしようとする。タイムアウト設定と、検知時の「警告表示」をUI側に必ず実装しろ。

4. インフラ層で守る：WAFの活用

もし君たちがNginxやAWS WAFを使っているなら、特定の通信パターンをフィルタリングする設定を追加しておこう。例えば、AWS WAFであれば、Regex Match Set を活用して、明らかに機密情報の構造を持つリクエストが外向きに流れていないか監視するルールを適用する。

# Nginxで特定のキーワードを含むPOSTを弾く（簡易的な抑止策）
location /api/v1/ask-ai {
    if ($request_body ~* "password|secret|key") {
        return 403 "Security Violation: Sensitive data detected in prompt.";
    }
    proxy_pass http://backend_service;
}

最後に：セキュリティは「納得感」の積み重ねだ

後輩諸君に言いたい。DLPやゲートウェイを導入すると、開発スピードが落ちると文句を言うPMや他チームが出てくるはずだ。しかし、セキュリティ担当者の仕事は「NO」と言うことではない。「この制約を入れれば、安心してLLMで遊べるようになる」という納得感を設計することだ。

今回紹介したコードは、あくまで「最初の一歩」だ。PIIの定義はプロジェクトごとに異なる。まずは自分たちの扱っているデータが何なのか、何が漏れたら会社が死ぬのかを特定することから始めてくれ。

セキュリティは、コードではなく「設計思想」に宿る。明日からの開発で、少しだけその視点を意識してみてほしい。健闘を祈る。