> ## 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.

# プライバシーアーキテクチャ

> TMP がどうユーザーアイデンティティをページコンテキストから分離するか、各当事者が何を学べて何を学べないか、TEE アテステーションがどう保証を格上げするか。

# プライバシーアーキテクチャ

TMP のプライバシーモデルは構造的であり、ポリシーベースではありません。プロトコルはユーザーアイデンティティをページコンテキストから分離し、バイヤーが両方を一緒に受け取ることが決してないようにします。TEE なしでは、この分離はコードによって強制されます: コンテキストコードパスは決してアイデンティティデータにアクセスせず、逆も同様です。コードはオープンソースで監査可能です。TEE ありでは、アテステーションが期待されるコードが変更されずに実行されていることを証明し、保証を「監査可能」から「独立に検証可能」に格上げします。

このページは、分離とは何か、それが何を防ぐか、保証がどこから来るかを説明します。TMP はプライバシーを構造的に強制する唯一の AdCP ドメインです — これが他のドメインとどう比較されるかについては [ドメインをまたぐプライバシー姿勢](/docs/protocol/architecture#privacy-posture-across-domains) とクロスプロトコルの [プライバシー考慮事項](/docs/reference/privacy-considerations) ページを参照。

## 分離原則

TMP ルーターは、2 つの構造的に分離されたコードパスを持つ単一のバイナリです: 1 つはコンテキスト用、1 つはアイデンティティ用。

|                    | Context Path                 | Identity Path         |
| ------------------ | ---------------------------- | --------------------- |
| **Inputs**         | ページ URL、コンテンツシグナル、トピック ID    | 不透明なユーザートークン、パッケージ ID |
| **Never receives** | 任意のユーザーアイデンティティ              | 任意のページコンテキスト          |
| **Returns**        | アクティベートされたパッケージ、エンリッチメントシグナル | 適格なパッケージ ID + TTL（秒）  |

コンテキストコードパスはアイデンティティデータへのアクセスを持ちません。アイデンティティコードパスはコンテキストデータへのアクセスを持ちません。2 つのパスは状態を共有しません: 共有メモリなし、共有データベースなし、通信チャネルなし、共有ログやテレメトリなし。

### TEE なし

分離はコード自体によって強制されます。コンテキストパスは、アイデンティティデータが渡されず、コンテキストパスが到達できるどの場所にも保存されず、コンテキストパスが処理するどのデータ構造でも参照されないため、それを読めません。アイデンティティパスには逆が同じように適用されます。

これはソースコードを読むことで検証可能です。ルーターはオープンソースです。誰でもそれを監査して 2 つのコードパスが分離されていることを確認できます。しかしこれは信頼と監査のモデルです: デプロイされたバイナリが公開されたソースに一致し、実行時に変更が導入されていないことを信頼しています。

### TEE あり

TEE（Trusted Execution Environment）アテステーションは、オペレーターを信頼する必要を除去します。アテステーションドキュメントは、エンクレーブ内で何のコードが実行されているかの正確な暗号学的に署名された声明です。パブリッシャーまたは監査者は:

1. ルーターからアテステーションドキュメントを取得する。
2. TEE ベンダーのルート認証局に対して署名を検証する。
3. 実行中のコードが公開・監査されたソースに一致することを確認する。

これは分離を独立に検証可能にします。誰もルーターオペレーターが正しいバイナリをデプロイしたというクレームを信頼する必要はありません。ハードウェアがそれを証明します。

TEE はアップグレードパスであり前提条件ではありません。プロトコルはそれなしで機能します。独立検証が必要なパブリッシャーは TEE アテスト済みルーターを要求でき、コード監査と運用信頼で快適な人はそうする必要はありません。

## 各当事者が学ぶもの

### バイヤーエージェントが学ぶもの

**Context Match リクエストから**、バイヤーエージェントは学びます:

* どのパブリッシャープレースメントとコンテンツアーティファクトが存在するか
* `context_signals`（トピック、センチメント、キーワード、言語、ブランドセーフティティア、summary、embedding）経由のコンテンツシグナル — パブリッシャーによって事前計算
* 地理的コンテキスト（国、地域、メトロ） — パブリッシャー制御の粒度

**Identity Match リクエストから**、バイヤーエージェントは学びます:

* どのユーザートークンが存在するか（不透明、パブリッシャースコープ）
* 各ユーザーがバイヤーの各アクティブパッケージに適格かどうか
* **パブリッシャーのビュー内でのクロスアイデンティティ等価性**: IMR が複数の `identities` エントリを運ぶとき、バイヤーはそれらのトークンがこのパブリッシャーの観点から同じユーザーに解決されることを学びます。これは意図的なマッチ率最適化ですが、バイヤーが以前持っていなかったアイデンティティグラフのエンリッチメントでもあります。クロスグラフ結合の開示を避けたいパブリッシャーは、マッチ率を犠牲にして IMR ごとに単一の `(user_token, uid_type)` を送れます。
* **機微トークンの露出**: `hashed_email` や類似の強く再識別するトークンは、不透明なプロバイダー ID より高い再識別リスクを運びます。パブリッシャーは、包含をデフォルトではなくデプロイ判断として扱うべきです（SHOULD）。バイヤーエージェントが TEE アテスト済みデプロイで実行されるとき、リスクサーフェスは、ログされたペイロードが事後的に明かせるものではなく、バイヤーのモデルがマッチ結果から推論できるものに縮小します — TEE は開示を除去しませんが、オフライン保持ベクターを閉じます。非 TEE デプロイは、法的/同意姿勢に対して `hashed_email` の包含を秤にかけるべきです。

バイヤーは、フリークエンシーキャップ、オーディエンスメンバーシップ、購入履歴、または持っている任意のシグナルから適格性を内部で計算します。彼らは適格なパッケージ ID のリストと TTL を返します。パブリッシャーは、ユーザーが適格かどうかの理由を学びません。

**バイヤーができないこと:**

* ユーザートークンをページ URL やコンテンツシグナルと関連付ける
* 特定のユーザーが特定のページを訪れたと判断する
* 任意のユーザーのクロスページ閲覧プロファイルを構築する

これらの制限は、バイヤーがアイデンティティとコンテキストを同じリクエストで決して受け取らず、下記の相関除去メカニズムが事後にそれらを結合するのを防ぐため、成立します。

### ルーターオペレーターが学ぶもの

コンテキストコードパスはコンテンツシグナルとパッケージリストを見ます。それはこれらをバイヤーエージェントにファンアウトし、レスポンスをマージします。ユーザートークンを決して処理しません。

アイデンティティコードパスはユーザートークンとパッケージ ID を見ます。それはこれらをバイヤーエージェントにファンアウトし、レスポンスをマージします。コンテンツシグナルを決して処理しません。

TEE なしでは、オペレーターは理論的にバイナリを変更して 2 つのパスを橋渡しできます。コードはオープンソースで監査可能ですが、オペレーターがそれを変更せずに実行することを信頼しています。TEE ありでは、アテステーションがバイナリが公開されたソースに一致することを証明し、その信頼要件を除去します。

### アイデンティティフィルタリングのためのルーター信頼境界

ルーターは Identity Match 転送のための信頼境界内にあります。ルーターがプロバイダーごとに `identities` 配列をフィルターする（プロバイダーの宣言された `uid_types` が含むトークンのみを送る）とき、プロバイダーはパブリッシャーが元々送ったものを独立に検証できません — 彼らはルーターによって署名されたフィルターされたサブセットのみを見ます。これは意図的な信頼配置です: ルーターは既に 2 つのコードパスの構造的分離を実行し、アイデンティティトークンのフィルタリングはコードパスの分離より単純な保証です。

ルーターはアイデンティティトークンを追加、置換、変換してはなりません（MUST NOT）。転送された `identities` はパブリッシャー起源の配列のサブセットでなければなりません（MUST）。この不変条件は、コード監査から証明可能（TEE なし）で、アテステーション測定から暗号学的に検証可能（TEE あり）です。非 TEE デプロイを実行するオペレーターは、この不変条件の基礎としてコード監査を受け入れます。TEE アテスト済みデプロイを実行するオペレーターは独立検証を得ます。

バイヤーはプロトコル層で残余リスクを閉じます: 複数のアイデンティティタイプが存在するとき、バイヤーは `hashed_email` や他の強く再識別するトークンより不透明なプロバイダー ID を優先すべきです（SHOULD）。そうすれば `hashed_email` 以外すべてを剥がすルーターでも影響力を得ません（[Identity Match への応答](/docs/trusted-match/buyer-guide#responding-to-identity-match) を参照）。

### パブリッシャーが保持するもの

パブリッシャーはコンテキストとアイデンティティの両方を持ちます。彼らはファーストパーティです: ユーザーは彼らのページ上、彼らのアプリを使用、彼らの会話中です。TMP はパブリッシャーのデータ姿勢を変えません。バイヤーと仲介者が同じ結合されたビューを得るのを防ぎます。

パブリッシャーは両方のレスポンスが到着した後、結合をローカルで実行します。彼らは自身のインフラで同意ロジック、フリークエンシー管理、関連性ランキングを適用できます。

### TMPX 露出トークンと構造的分離

Identity Match レスポンスは、TMPX トークン — ユーザーの解決されたアイデンティティトークンを含む HPKE 暗号化された blob — を運ぶ `tmpx` フィールドを含められます。このトークンは、ユーザーごとの露出トラッキングのため、クリエイティブトラッキング URL を通じてバイヤーのインプレッションピクセルに流れます。

このデータフローはアイデンティティとコンテキストのパスを橋渡しします: TMPX トークンは Identity Match によって生成され、Context Match オファーから発生するクリエイティブトラッキング URL 経由で消費されます。しかし、橋渡しは **パブリッシャー側** で起こります — パブリッシャーは 2 つのレスポンスをローカルで結合し、広告配信中に TMPX 値をトラッキング URL に代入します。バイヤーの読み取りレプリカが暗号化トークンを生成します。バイヤーのインプレッションピクセルがそれを受け取ります。パブリッシャーは不透明な blob のみを見て、その値をパース、ログ、またはそれに基づいて決定してはなりません（MUST NOT）。

TMPX トークンは構造的分離に違反しません。なぜなら:

* ルーターは決して復号された内容を見ません — 不透明な `tmpx` フィールドを通過させます。
* パブリッシャーはそれを解釈せずに値をトラッキング URL に代入します。
* バイヤーのクラスターマスターのみがトークンを復号できます（HPKE `mode_base` — マスターの公開鍵で暗号化、マスターの秘密鍵のみが復号可能）。
* Identity Match リクエストの `country` ルーティングディレクティブは、転送前にルーターによって剥がされます — バイヤーエージェントはユーザーがどの国にいるかを決して見ません。

## パッケージセット相関除去

コンテキストパスがこのページに関連するパッケージのみを送り、アイデンティティパスが同じパッケージのみを送ったら、バイヤーは 2 つのセットを比較しアイデンティティリクエストがどのページから来たかを推論できます。TMP は構造的に異なるセットを要求することでこれを防ぎます:

* **Context Match** はパッケージリストを送りません。プロバイダーはプレースメントの同期されたパッケージセットを評価します — プレースメントごとに安定、すべてのユーザーで同じ。リクエストごとにパッケージが送られないため、パブリッシャーはパッケージフィルタリングを通じて誤ってアイデンティティを漏らせません。
* **Identity Match** は `package_ids` を送ります（または完全に省略、その場合バイヤーは `seller_agent_url` の完全な登録済みアクティブセットに対して評価）。送られるとき、構成は現在のプレースメントと統計的に独立でなければなりません（MUST） — all-active（このパブリッシャーでのこのバイヤーのすべてのアクティブパッケージ）または fuzzed（バイヤーが黙って落とす合成の存在しない ID で任意にパディングされたランダムサンプル）のいずれか。バイヤーはこのセットに対してユーザーを評価し、ページ固有のサブセットだけに対してではありません。

コンテキストセットは 1 つのプレースメントにスコープされます。アイデンティティセットは 1 つのバイヤーの全アクティブインベントリにスコープされます。2 つのセットは構造的に異なり、どちらも他についての情報を明かしません。

パブリッシャーは交差をローカルで実行します: どのパッケージが context match によってアクティベートされ、かつ identity match によって適格だったか。

## 時間的相関除去

別々のコードパスと異なるパッケージセットがあっても、Context Match と Identity Match リクエストが同じパブリッシャーから同じ瞬間に — または常に同じ順序で — バイヤーに到着したら、タイミングまたは順序の相関が可能です。TMP は両方に対処します:

* パブリッシャーはコンテキストとアイデンティティのリクエスト間にランダムな遅延を導入すべきです（SHOULD）。推奨範囲は 100-2000ms、一様分布。
* パブリッシャーは順序もランダム化すべきです（SHOULD）: 各機会は context match が先か identity match が先かのほぼ等しい確率を持つべき。遅延がランダム化されても、固定順序は順序を通じてペアリングを漏らします。
* パブリッシャーは複数のページビューにわたって Identity Match リクエストをバッチしてもよく（MAY）、各アイデンティティリクエストがどのコンテキストリクエストに対応するかをさらに不明瞭にします。
* パブリッシャーはコンテキストとアイデンティティのリクエストを異なるネットワークパス経由でルーティングしてもよい（MAY）。

時間的相関除去は多層防御です。それは主要な分離メカニズムではありません。構造的分離とパッケージセット相関除去がそうです。しかしそれはタイミングのサイドチャネルを閉じます。

## TEE アテステーションの詳細

TMP のリファレンスアーキテクチャは AWS Nitro Enclaves をターゲットにしますが、プロトコルは TEE 非依存です。検証可能なアテステーションドキュメントを生成する任意の TEE が互換です。

### アテステーションが証明するもの

* エンクレーブ内で実行されるルーターバイナリが、公開・監査されたソースコードに一致する。
* コンテキストとアイデンティティのコードパスが、共有状態なしに構造的に分離されている。
* バイナリがオペレーター、ホスティングプロバイダー、または任意のランタイムプロセスによって変更されていない。

### アテステーションが証明しないもの

* バイヤーエージェントが受け取ったデータを責任を持って扱うこと。TMP はバイヤーが受け取るものを制限します。彼らがそれで何をするかは制御しません。
* パブリッシャーの結合ロジックが正しいこと。パブリッシャーはファーストパーティで、TMP の分離モデルに制約されません。
* コードがバグから自由であること。アテステーションはコードが公開されたソースに一致することを証明します。そのソースが正しいかは別の問題で、オープンソース監査によって対処されます。

### アテステーション測定

各アテステーションドキュメントは、実行中の環境の暗号学的ハッシュを含みます:

| Measurement          | What it covers                               |
| -------------------- | -------------------------------------------- |
| **Image hash**       | エンクレーブイメージのハッシュ。バイナリが期待されるビルドに一致することを確認。     |
| **Kernel hash**      | 動作環境のハッシュ。                                   |
| **Application hash** | アプリケーションレベルのコードのハッシュ。                        |
| **Role hash**        | エンクレーブの権限が期待に一致することを確認（例: 外部データベースへのアクセスなし）。 |

パブリッシャーまたは監査者は、これらの測定を公開されたビルドアーティファクトに対して検証できます。この検証は自動化され継続的に実行できます。

## OpenRTB との比較

| Signal            | OpenRTB             | TMP                                    |
| ----------------- | ------------------- | -------------------------------------- |
| ユーザー ID + ページ URL | 同じ入札リクエスト           | 別々のコードパス、決して結合されない                     |
| デバイスフィンガープリント     | 入札リクエストに含む          | 決して送らない                                |
| IP アドレス           | 入札リクエストに含む          | 決して送らない                                |
| 生の cookie         | 入札リクエストに含む          | 決して送らない                                |
| GPS 座標            | 入札リクエストに含む          | 決して送らない                                |
| 閲覧履歴              | cookie sync 経由で構築可能 | 構築不能: バイヤーはアイデンティティ + コンテキストを一緒に決して見ない |
| 分離の検証             | エクスチェンジを信頼          | コード監査（TEE なし）または TEE アテステーション（TEE あり）  |

OpenRTB では、入札リクエストはすべてのバンドルです: ユーザーアイデンティティ、デバイスシグナル、ページコンテキスト、行動データ。オークションのすべての参加者が完全なバンドルを受け取ります。プライバシーは、データを悪用しないという契約的約束に依存します。

TMP はプロトコルレベルでバンドルを分割します。バイヤーはコンテキストまたはアイデンティティを受け取り、決して両方ではありません。分離は構造的であり契約的ではありません。

## 規制姿勢

TMP の構造的分離は、GDPR、CCPA、ePrivacy、類似の規制が要求するデータ最小化原則に整合します:

* バイヤーエージェントはコンテンツコンテキストとペアになったユーザーアイデンティティを決して受け取りません。最小化はポリシーではなくプロトコルによって強制されます。
* パブリッシャーは、直接のユーザー関係を持つファーストパーティとして、結合を制御します。データセットを結合する前に同意ロジックを適用できます。
* TEE アテステーションにより、分離は独立に検証可能で、規制当局に監査可能な証拠を提供します。

これはアーキテクチャの観察であり法的助言ではありません。パブリッシャーとバイヤーエージェントは、規制コンプライアンスについて自身の法律顧問に相談すべきです。

TMP のアーキテクチャが GDPR コントローラーとプロセッサーロールにどうマップするかの詳細な分析については、[データ保護ロール](/docs/trusted-match/data-protection-roles) を参照。クロスプロトコルのプライバシーガイダンスについては、[プライバシー考慮事項](/docs/reference/privacy-considerations) を参照。