> ## Documentation Index
> Fetch the complete documentation index at: https://adcp-docs-ja.pier1.co.jp/llms.txt
> Use this file to discover all available pages before exploring further.

# プライバシー考慮事項

> AdCP 実装者、コンプライアンスレビュアー、CISO のためのクロスプロトコルのプライバシー入口 — 各プロトコルが何を運び、何を運ばないか、実装者が自分でプライバシーを扱わなければならない場所。

このページは AdCP におけるプライバシーのクロスプロトコルの入口です。実装者とコンプライアンスレビュアーが考える必要のあるカテゴリーを名指しし、各 AdCP プロトコルが何を運び何を運ばないかを要約し、より深いリファレンスにリンクします。それらのいずれも置き換えません。

特定のドメインの深いアーキテクチャの全体像が必要なら、リンクをたどってください。AdCP はプライバシー影響評価テンプレートを公開しません。デプロイヤーの DPO が自身の評価を組み立てるのに必要な入力については、下記の [For DPOs and procurement reviewers](#for-dpos-and-procurement-reviewers) を参照。

## What AdCP's privacy posture is — and isn't

AdCP はエージェント間のワイヤープロトコルを仕様化します。次を仕様化しません:

* エンドユーザー認証または同意取得（上流で扱われる）
* データ主体の権利ワークフロー（バイヤーの責任）
* データレジデンシー（個々のエージェントの設定と契約のプロパティ）
* 保持ポリシー（オペレーターの責任）

AdCP が仕様化するのは、各プロトコルが運ぶものの*形状*、運んではならないものの禁止、プロトコルがプライバシー敏感な場所に適用される構造的分離です。実装者は、プロトコル自体が強制しないすべての境界でのプライバシー制御に責任を負います。

## Privacy posture by domain

AdCP のプライバシー保証はプロトコル間で一様ではありません。完全な表については [ドメインをまたぐプライバシー姿勢](/docs/protocol/architecture#privacy-posture-across-domains) を参照。要約:

* **Trusted Match Protocol（TMP）** — **構造的分離**。Context Match と Identity Match は分離されたコードパスで実行される。スキーマがクロスオーバーを禁止する。TEE アテステーション（デプロイされたとき）が分離を独立に検証可能にする。[TMP privacy architecture](/docs/trusted-match/privacy-architecture) を参照。
* **Media Buy、Creative、Signals、Governance** — **契約的機密性**。データを交換する当事者は、プロトコルレベルの分離ではなくアカウントの条件に拘束される。
* **Sponsored Intelligence** — **セッションごとの同意**。ユーザーはセッションごとに同意する。セッションをルーティングするネットワークはルーティングメタデータを見ることがある。[SI networks](/docs/sponsored-intelligence/networks) を参照。
* **Brand / Registry** — **設計上公開**。`brand.json` は `/.well-known/brand.json` で発見可能。レジストリは公開エンティティ解決を公開する。

ガバナンスゲーティング（キャンペーンガバナンス経由）はプライバシー姿勢と独立して動作します: それは予算、ポリシー、ブランドセーフティの根拠で人間の承認を要求できますが、基底のドメインが運ぶデータを変えません。

## Privacy categories to think about

### Data minimization

AdCP は、できる場所でプロトコル境界を越えるデータを最小化します:

* `sync_audiences` で `hashed_email` または `hashed_phone` を使うとき、バイヤーは転送前に正規化された値を SHA-256 ハッシュ化しなければなりません（MUST） — それらのフィールドのスキーマは平文を受け入れません。他の空間のために非ハッシュ識別子タイプが存在します。実装者は email または phone を転送するときハッシュ化タイプを選ばなければなりません（MUST）。
* TMP Context Match はユーザーアイデンティティを運びません。TMP Identity Match はページコンテキストを運びません。両方ともスキーマレベルで強制されます。
* `governance_context` トークンは、バイヤーのコンプライアンス姿勢が敏感なとき、インライン決定の代わりに `policy_decision_hash` を使えます。

実装者は、`ext` または `context` に追加する任意のフィールドが、プロトコルが最小化して除いたデータを再導入するかをレビューすべきです（SHOULD）。

### Unsalted hashed identifiers are pseudonymous, not anonymous

`hashed_email` と `hashed_phone` は **仮名 PII** です。email と E.164 名前空間は、事前計算された辞書と商用逆引きサービスがソルトなし SHA-256 ハッシュから平文を回復できるほど小さいです。ハッシュ化識別子は匿名化識別子と等価ではありません。

規範的帰結:

* オペレーターのドキュメント、データ処理契約、コンプライアンス開示は、ソルトなしの `hashed_email` または `hashed_phone` を「プライバシー保護」「匿名」「非識別化」と記述してはなりません（MUST NOT）。ハッシュ化はトランスポート境界でのデータ最小化であり、匿名化ではありません。
* `hashed_email` と `hashed_phone` は、保持、同意、アクセス制御、データ主体アクセス（GDPR 第 15 条）、消去（GDPR 第 17 条）のワークフローについて PII として扱われなければなりません（MUST）。email アドレスの主体アクセスリクエストは、オペレーターが対応するハッシュ化レコードを保持する場合、そのハッシュでキー付けされたレコードに解決されなければなりません（MUST）。（真に再識別できないオペレーター — 例えば集約されたマッチ数やブルームフィルターのメンバーシップビットのみを保存する — は GDPR 第 11 条を呼び出してもよい。そのハードルは「ハッシュ化した」より高い。）
* 上記のハッシュをセラーのアイデンティティグラフに対して照合することは、独自の合法的根拠を必要とする処理活動です — ハッシュ化はその要件を除去しません。

マッチングプロトコルが「プライバシー保護」であるというクレームは、認識されたプリミティブを必要とします — オペレーター保持のシークレットを伴うソルト付きハッシュ、クロスパーティ共有シークレットを伴う HMAC、PSI（Private Set Intersection）、またはアテストされた分離を伴う TEE。AdCP 3.0 は `hashed_email`/`hashed_phone` のソルト付きまたは HMAC バリアントを定義しません。標準化されたソルト付きバリアントは将来のマイナーリリースに向けて追跡されています。それまで、プライバシー保護マッチが必要な実装者は、上記のプリミティブの 1 つをプロトコルの上に重ねなければなりません（MUST）（例: クリーンルーム処理、PAIR、UID2/RampID オペレーターが行うアイデンティティグラフトークン化）。

### Separation

2 つの事実が組み合わさるとプライバシー被害を生む場所（例: インプレッション時のアイデンティティ + コンテキスト）で、プロトコルはそれらを分離します。構造的分離は TMP 固有です。他のドメインは契約的分離に依存します。

### Transport

すべての AdCP トラフィックは HTTPS 経由です（[Security — Identity](/docs/building/concepts/security-model#layer-1-identity--who-is-actually-calling) を参照）。署名付きリクエスト（RFC 9421）は 3.1 で規範的です。トランスポートセキュリティはベースラインの前提です。プロトコルはその上に構築されます。

### Residency

レジデンシーはプロトコルで運ばれません。エージェントのレジデンシー姿勢は設定と契約のプロパティです — 実装者はそれを文書化しなければならず（MUST）、オペレーターは該当する場合 EU / UK / その他の地域要件を満たすようそれを設定しなければなりません（MUST）。[Security Model — データ処理とサブプロセッサーのチェックリスト](/docs/building/concepts/security-model#data-handling-and-subprocessors) を参照。

### Retention

プロトコルは、冪等性のキャッシュ保持（[Layer 3: Idempotency](/docs/building/concepts/security-model#layer-3-idempotency--at-most-once-execution) を参照）とガバナンスの監査ログ保持（[Layer 5: Auditability](/docs/building/concepts/security-model#layer-5-auditability--the-trail-survives-the-transaction) を参照）を記述します。他のデータ — クリエイティブアセット、キャンペーン状態、LLM プロンプト、会話ログ — の保持はオペレーターの責任です。

### Processor / controller roles

誰がコントローラーで誰がプロセッサーかはデプロイに依存します。AdCP はプロトコル層でロールを割り当てません。典型的な割り当て:

* バイヤーは、実行するキャンペーンについて通常コントローラー。
* ガバナンスエージェントは、それが提供するコントローラーのためにプロセッサーとして動作し、しばしば **マルチカスタマーの影響範囲** を持つ — デューデリジェンスでそれに応じて扱う。
* セラーは、自身のインベントリデータについてコントローラー、バイヤースコープのキャンペーンデータについてプロセッサーになりうる。
* TMP ルーターオペレーターは、通常両側のプロセッサーで、[TMP privacy architecture](/docs/trusted-match/privacy-architecture) で記述される分離保証の下で動作する。

TMP 固有のデプロイについては、[TMP Data Protection Roles](/docs/trusted-match/data-protection-roles) を参照 — バイヤーエージェントの条件付きプロセッサーポジション、コンテキスト+アイデンティティ結合が委譲されたときの SSP のロール、アイデンティティプロバイダーのリスク形状、TMP の分離保証の外に落ちるインプレッション後フローをカバーするより深い分析。

オペレーターは、各データフローについて自身のロールを文書化し、それを反映する各当事者との DPA を持たなければなりません（MUST）。

### Subprocessors and LLM providers

すべての LLM 駆動エージェントはサブプロセッサーを持ちます: LLM プロバイダー自体、加えて任意の検索サービス、埋め込みストア、ツール統合。各プロバイダーとの DPA は、プロンプト、ブランドアセット、ファーストパーティシグナル、クリエイティブメタデータが保持されるかモデル訓練に使われるかについて明示的でなければなりません。[Security Model — データ処理チェックリスト](/docs/building/concepts/security-model#data-handling-and-subprocessors) を参照。

LLM サブプロセッサーは、機密性だけでなく **完全性** リスクも導入します: ブリーフ、クリエイティブメタデータ、ツール出力内の信頼できないテキストは、エージェントに認証情報を漏らさせ、認可されていないツール呼び出しを発行させ、出力を改ざんさせるプロンプトインジェクションペイロードを運びうる。[エージェンティック広告に固有の脅威](/docs/building/concepts/security-model#threats-specific-to-agentic-advertising) を参照。これはプロトコルのスコープ外ですが、すべてのオペレーターのスコープ内です。

## Boundaries implementers must handle

プロトコルはこれらを強制しません。オペレーターがしなければなりません:

* **エンドユーザーの同意とデータ主体の権利**（GDPR 第 15–22 条、CCPA）。
* フィールド形状が強制するものを超えた **目的制限**。
* **越境データ転送制御**（SCC、十分性、UK IDTA）。
* **非構造化フィールドでの PII 発見**（クリエイティブメタデータ、チャットログ、ブリーフテキスト）。AdCP は `ext`、`context`、ブリーフの散文、クリエイティブアセットを PII についてスキャンしません。
* ログの **ログ保持と PII 編集**。
* 信頼できないテキストを処理する LLM 駆動エージェントの **プロンプトインジェクション封じ込め**。

## For DPOs and procurement reviewers

AdCP はプライバシー影響評価テンプレートを公開しません。PIA は、データコントローラーとその法律顧問が所有するデプロイヤーのアーティファクトです — すべてのデプロイの目的、合法的根拠、保持、レジデンシー、サブプロセッサーチェーンは異なり、それらが GDPR 第 35 条評価にとって重要な部分です。プロトコル自体はコントローラーではなく、その分析の代わりにはなれません。

AdCP が代わりに提供するのは、DPO が処理の AdCP 部分を記述するのに必要なプロトコルレベルの入力のセットです。AdCP を使うデプロイの PIA を組み立てるとき、関連する入力は:

* **各プロトコルが何を運び禁止するか** — 上記の [Privacy posture by domain](#privacy-posture-by-domain) 要約、加えて各ドメインからリンクされる深いリファレンス。
* **コントローラー / プロセッサーの割り当て** — 上記の [Processor / controller roles](#processor--controller-roles) セクション。オペレーターは依然としてデータフローごとに自身のロールを文書化し（MUST）、各当事者との DPA を持たなければならない。
* **構造的分離（TMP のみ）** — [TMP Privacy Architecture](/docs/trusted-match/privacy-architecture)、デプロイされたときの TEE アテステーションを含む。
* **脅威モデルと運用制御** — [Security Model](/docs/building/concepts/security-model)、[データ処理とサブプロセッサーのチェックリスト](/docs/building/concepts/security-model#data-handling-and-subprocessors) を含む。
* **LLM プロバイダーのサブプロセッサー考慮事項** — 上記の [Subprocessors and LLM providers](#subprocessors-and-llm-providers) セクション、機密性（保持、訓練）と完全性（プロンプトインジェクション）の両方をカバー。
* **明示的な非目標** — [既知の制限](/docs/reference/known-limitations)、プロトコルが何をしないか（プロトコルレベルの PII トランスポートなし、レジデンシーメカニズムなし、侵害通知 SLA なしなど）を名指しし、デプロイヤーがどの制御を所有するかを知る。

レジデンシー、保持、同意取得、データ主体の権利ワークフロー、越境転送メカニズム、目的制限はデプロイの関心事です — AdCP はプロトコル層でそれらを強制せず、テンプレートはデプロイ固有にならずにそれらを意味あるようにカバーできません。

## Related references

* **[TMP Privacy Architecture](/docs/trusted-match/privacy-architecture)** — 構造的分離モデル、TEE アテステーションの詳細付き
* **[Security Model](/docs/building/concepts/security-model)** — 脅威モデル、多層防御、デプロイチェックリスト
* **[Security（実装リファレンス）](/docs/building/by-layer/L1/security)** — 認証、冪等性、SSRF、ガバナンス検証の規範的ルール
* **[ドメインをまたぐプライバシー姿勢](/docs/protocol/architecture#privacy-posture-across-domains)** — 要約表
* **[既知の制限](/docs/reference/known-limitations)** — プロトコルがプライバシーについて何をしないか