本番LLM/AIアプリのデータプライバシー＆コンプライアンス実装ガイド 2026｜PII最小化・プロバイダのデータ利用・APPI/GDPR

生成AIを本番のプロダクトに載せるとき、多くの企業が最後に足を止めるのが**「顧客データ・PII（個人情報）をどう守るか」**です。プロンプトに個人情報を入れてよいのか、外部のLLMプロバイダに送ったデータは学習に使われるのか、日本の個人情報保護法（APPI）やGDPRに触れないのか——ここが曖昧なままだと、法務が止め、プロジェクトは進みません。

結論から言えば、本番LLMアプリのプライバシーは次の3つの設計判断に集約されます。

1. プロバイダのAPIは既定で学習に使わない——ただし例外を正しく知る。
2. PIIは「送る前」に最小化・マスキングする。 プロバイダのポリシーに依存しない多層防御。
3. 越境移転（APPI 第28条）とDPA（GDPR 第28条）を、後付けでなく設計に織り込む。

この記事は、APPI準拠の計測基盤やアプリケーションセキュリティ（LLMアプリのセキュリティ）を実装してきた立場から、各プロバイダの公式ポリシーと規制の一次情報を検証した上で、TypeScriptの実コードで「プライバシー・バイ・デザイン」を設計します。これは、セキュリティ・MCP・評価に続く「信頼できる本番AI」の第4の柱です。

⚠️ 本記事はエンジニアリングのガイドであり、法的助言ではありません。規制の適用は事案により異なります。重要な判断は必ず一次情報と法務専門家に確認してください。プロバイダのポリシーは更新されるため、実装前に各出典を再確認してください。

まず誤解を解く：APIは既定で「学習に使わない」——ただし例外がある

「LLMに送ったデータは全部学習される」は、API/商用層では誤解です。主要プロバイダは、API・商用・エンタープライズ層について、既定であなたのデータをモデル学習に使わないと明言しています（各社公式で検証済み）。これは無料のconsumer層とは対照的です。

ここが落とし穴（例外を正しく知る）:

• Googleは「有料/Vertex」だけが no-train。 課金アカウントに紐づかない無料のGemini API / AI Studio は、あなたのデータを学習に使い得ます。「Geminiは安全」と一括りにしない。
• Vercelのプロバイダ側 no-train / ZDR は“オプトイン”。 ゲートウェイ自体は保持しませんが、上流プロバイダへ no-train ルーティングするには disallowPromptTraining / zeroDataRetention を明示的に有効化します。
• Bedrockに固定の公開保持日数はない（あなたのログ設定・KMSで制御）。数値を仮定しない。
• 既定no-trainは「送っていい」を意味しない。 一定期間のログ保持は残り、そもそもPIIを外部へ送ること自体が越境移転・第三者提供の論点になります（後述）。

プライバシー・バイ・デザイン：PIIを「送らない」設計

最も確実なプライバシー対策は、そもそも不要なPIIをプロンプトに載せないことです。プロバイダのポリシーは第2防衛線であって、第1防衛線は自分たちのアーキテクチャです。

(1) データ最小化——必要なフィールドだけ送る（GDPR Art.5(1)(c) の工学版）。生の氏名や住所ではなくIDや参照を渡し、結果はアプリ側で再解決します。

import { z } from "zod";

// 送信ペイロードは「必要なフィールドだけ」。生PIIではなくIDを渡し、
// 表示に必要な氏名・住所はアプリ側（信頼境界の内側）で再解決する。
const PromptContext = z.object({
  orderId: z.string().uuid(),       // ← 顧客レコード全体ではなく参照だけ
  itemCount: z.number().int(),
  region: z.enum(["JP", "US", "EU"]), // 属性の粒度も最小化
});

// これで「氏名・住所・電話・カード番号」はそもそもプロンプトに存在しない。

(2) それでも自由文を送るなら、送信前にPIIを匿名化する。 Microsoft Presidio のような検出器で、氏名・住所・電話・メール等を検出してマスクします（検出は完全ではないので他の対策と併用）。

// 自由文（問い合わせ本文など）はプロバイダに渡す"前"にマスクする。
// これはプロバイダのZDRに依存しない多層防御（送る前に消す）。
async function redactPii(text: string): Promise<string> {
  const findings = await analyzePii(text); // 例: Presidio Analyzer（PERSON/EMAIL/PHONE…）
  return findings.reduce((masked, f) => masked.replaceAll(f.text, `<${f.entityType}>`), text);
}

ゼロデータ保持（ZDR）とデータレジデンシー

送るデータを絞ったら、次はプロバイダ側の保持と所在を締めます。

• ZDRを取得する。 機微データを扱うなら、OpenAIのZDR対象エンドポイント（要申請）や、Vercel AI Gateway の zeroDataRetention を有効化し、リクエスト後の保持をなくします。
• リージョンを固定する（データレジデンシー）。 BedrockやVertexは指定リージョン内でデータを処理・保存できます。リージョンを固定すれば、そもそも越境が発生しない設計にでき、APPI/GDPRの負担を構造的に減らせます。

// データレジデンシー：リージョンを固定し、"越境そのものを設計で防ぐ"。
// 東京固定なら、日本の個人データが国外に出ない構成にできる。
const bedrock = new BedrockRuntimeClient({ region: "ap-northeast-1" });
// OpenAI: ZDR対象エンドポイント（要事前申請）。Vercel: team/リクエストで zeroDataRetention を有効化。

越境移転とコンプライアンス（APPI 第28条 / GDPR 第28条）

海外のLLM APIにPIIを送ることは、法的には**「外国にある第三者への個人データの提供」**に当たり得ます。ここは設計の初期に押さえます。

APPI（日本）:

• 第三者提供（第27条） は原則、本人の同意が必要。ただし委託（第27条第5項）や共同利用は「第三者」に当たらない扱い。
• 越境移転（第28条） は原則、本人の事前同意が必要。例外は (a) PPCが指定する相当な保護水準の国、または (b) 受領者がPPC基準に適合する体制を備える場合。同意による場合は、移転先の国名やその国の個人情報保護制度等を本人に事前提供する必要があります。
• 加工の区分：個人情報（識別可能）／仮名加工情報（他情報と照合しなければ識別不可・依然規制対象）／匿名加工情報（復元不可・識別不可で、より緩やかな規律）。

GDPR:

• LLMプロバイダや観測ベンダーは通常 processor（処理者）。**Art.28のDPA（データ処理契約）**を締結し、「十分な保証」を持つprocessorだけを使う。
• Art.5(1)(c) データ最小化——目的に必要なデータだけを処理する。
• 可逆な仮名化は依然『個人データ』（前文26）。トークン化（氏名→<PERSON>）で復元マップを持つなら、それは匿名化ではありません。可逆なマスキングを「匿名化済み」と称さないこと。

実務の要点：リージョン固定＋PII最小化で「そもそも越境するPIIを減らす」と、同意取得やDPA運用の負担が構造的に小さくなります。コンプライアンスは、契約だけでなくアーキテクチャで達成するのが本筋です。

盲点：ログ・トレース・評価データセットのPII

PIIは、プロンプト本文だけでなく可観測性の経路から漏れます。トレース基盤・評価フィクスチャ・ダッシュボードは、生PIIが静かに溜まる典型です。

対策は明快で、ログ/評価の境界の“前”でマスクすること。マスク済みのペイロードだけを記録します。

// トレース/評価データにも生PIIを残さない（ログ境界の"前"でマスク）。
logger.info("llm_call", {
  route: "support.reply",
  // prompt: rawUserMessage,                         // ❌ 生PIIがトレースに残る
  promptRedacted: await redactPii(rawUserMessage),   // ✅ マスク後だけ記録
  tokens: usage.totalTokens,
  latencyMs,
});

観測ベンダー（トレース/評価SaaS）も通常はprocessorなので、DPAの対象です。可観測性の設計は OpenTelemetryによる本番可観測性 と、機密の取り扱いは Next.jsの秘密情報の漏洩防止 を合わせて設計します。

導入チェックリスト（本番投入前）

• プロバイダ層の確認 — 使うのはAPI/商用層か（既定no-train）。無料Gemini/AI Studioなど学習される層を業務データに使っていないか。
• データ最小化 — 生PIIではなくID/参照を送り、必要な属性だけに絞っているか。
• PIIマスキング — 自由文はプロバイダに渡す前にredactしているか。
• ZDR — 機微データでゼロデータ保持を有効化/取得しているか。
• データレジデンシー — リージョンを固定し、越境の発生自体を減らしているか。
• 越境移転（APPI 28条） — 同意 or 相当国 or 基準適合体制のいずれで正当化されるか整理したか。
• DPA（GDPR 28条） — LLM/観測ベンダーとDPAを締結したか。
• ログ/評価のPII — トレース・評価データセットにマスク後だけを記録しているか。
• 仮名 vs 匿名 — 可逆なマスキングを「匿名化」と誤って扱っていないか。

まとめ

本番LLMアプリのプライバシーは、契約書の文言よりもアーキテクチャで決まります。**「送らない・残さない・越境させない」**を設計で達成することが、法務を通し、企業導入を進める最短路です。

• プロバイダのAPIは既定で学習に使わない——が、無料層やopt-in設定の例外を正しく知る。
• PIIは送る前に最小化・マスキングし、ZDRとリージョン固定で多層に締める。
• 越境（APPI 28条）とDPA（GDPR 28条）を設計に織り込む。 可逆な仮名化は匿名化ではない。

セキュリティ・MCP・評価・プライバシー——この4本柱が揃って、生成AIは「速く作れて、安全で、壊れず、信頼できる」本番システムになります。速く作ることと、守り切ることは、正しく設計すれば両立します。