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

> 生成AI/LLMを本番投入する企業向けに、データプライバシーとコンプライアンスをアーキテクチャで担保する実践ガイド。主要APIプロバイダ（OpenAI/Anthropic/Google/Bedrock/Vercel）のデータ利用・保持ポリシー、PII最小化・マスキング、ゼロデータ保持、データレジデンシー、APPI（第28条 越境移転）とGDPR（第28条 DPA・データ最小化）まで、TypeScript実コードで解説します。

- 公開日: 2026-07-23
- 著者: 友田 陽大
- タグ: 生成AI, LLM, セキュリティ, プライバシー, コンプライアンス, PII, APPI, GDPR, AI駆動開発, アーキテクチャ設計
- URL: https://tomodahinata.com/blog/llm-application-data-privacy-compliance-pii-appi-gdpr-guide
- カテゴリ: 本番LLMアプリ実装（信頼できるAI）
- 総合ガイド: https://tomodahinata.com/blog/production-llm-application-engineering-guide

## 要点

- 主要プロバイダのAPI/商用層は『既定で学習に使わない』——OpenAI・Anthropic・Google（有料）・Bedrock・Vercelで検証済み。ただし無料のGemini API/AI Studioは学習に使われ得るなど例外あり。
- 既定no-trainでも十分ではない。PIIは『送る前』に最小化・マスキングし、ゼロデータ保持（ZDR）とリージョン固定を多層で組み合わせる。
- 越境移転はAPPI第28条で原則同意（例外: PPC相当国 or 基準適合体制）。GDPRではプロバイダ＝processorなのでArt.28のDPAとArt.5(1)(c)データ最小化が必須。
- 可逆な仮名化は依然『個人データ』（GDPR前文26 / APPI仮名加工情報）。不可逆な匿名化と混同しない。
- ログ・トレース・評価データセットは生PIIの盲点。ログ境界の『前』でマスクし、観測ベンダーとはDPAを結ぶ。

---

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

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

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

この記事は、APPI準拠の計測基盤やアプリケーションセキュリティ（[LLMアプリのセキュリティ](/blog/llm-application-security-owasp-top-10-prompt-injection-guide)）を実装してきた立場から、**各プロバイダの公式ポリシーと規制の一次情報を検証**した上で、TypeScriptの実コードで「プライバシー・バイ・デザイン」を設計します。これは、セキュリティ・[MCP](/blog/mcp-model-context-protocol-production-server-guide)・[評価](/blog/llm-application-evaluation-testing-llm-as-judge-ci-guide)に続く「**信頼できる本番AI**」の第4の柱です。

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

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

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

| プロバイダ（API/商用層） | 既定で学習に使う？ | 保持 | ゼロデータ保持(ZDR) |
|---|---|---|---|
| **OpenAI API** | **No**（2023年3月以降・明示オプトイン時を除く） | 不正監視ログを最大30日 | あり（対象エンドポイント・要申請） |
| **Anthropic API** | **No**（商用製品の入出力を既定で学習に使わない） | フィードバック提出分は保持あり | あり（一部Platform/Enterprise契約） |
| **Google Gemini（有料）/ Vertex AI** | **No（有料のみ）** | 不正監視ログ最大30日（学習には未使用） | Vertexに存在 |
| **AWS Bedrock** | **No**（基盤モデルの学習に使わない・第三者提供なし） | 自リージョン内に暗号化保存（固定の公開日数なし） | リージョン内設計 |
| **Vercel AI Gateway** | **No**（Vercelは学習/保持しない） | ZDRでリクエスト後に削除 | あり（`zeroDataRetention`） |

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

- **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や参照を渡し、結果はアプリ側で再解決**します。

```ts
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](https://presidio.dataprivacystack.org/) のような検出器で、氏名・住所・電話・メール等を検出してマスクします（検出は完全ではないので他の対策と併用）。

```ts
// 自由文（問い合わせ本文など）はプロバイダに渡す"前"にマスクする。
// これはプロバイダの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の負担を構造的に減らせます。

```ts
// データレジデンシー：リージョンを固定し、"越境そのものを設計で防ぐ"。
// 東京固定なら、日本の個人データが国外に出ない構成にできる。
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は、プロンプト本文だけでなく**可観測性の経路**から漏れます。トレース基盤・[評価フィクスチャ](/blog/llm-application-evaluation-testing-llm-as-judge-ci-guide)・ダッシュボードは、生PIIが静かに溜まる典型です。

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

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

観測ベンダー（トレース/評価SaaS）も通常はprocessorなので、**DPAの対象**です。可観測性の設計は [OpenTelemetryによる本番可観測性](/blog/opentelemetry-observability-production-tracing-metrics-logs) と、機密の取り扱いは [Next.jsの秘密情報の漏洩防止](/blog/nextjs-env-secret-leak-prevention-public-vars-guide) を合わせて設計します。

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

- [ ] **プロバイダ層の確認** — 使うのは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は「速く作れて、安全で、壊れず、**信頼できる**」本番システムになります。速く作ることと、守り切ることは、正しく設計すれば両立します。