データ保護ロール
このページは TMP のアーキテクチャを GDPR データ保護ロール（コントローラー、プロセッサー、共同コントローラー）にマップします。各参加者が個人について何を決定できて何を決定できないか、アーキテクチャの境界がどこでプロセッサーポジションをサポートし、どこでしないかを説明します。 これはアーキテクチャの分析であり法的助言ではありません。組織は特定の状況について資格のあるデータ保護顧問に相談すべきです。TMP プライバシーアーキテクチャ への習熟が前提とされます — 構造的分離、TEE アテステーション、パッケージセット相関除去、時間的相関除去のような概念はそこで定義されます。Verdict at a Glance
Background: Controller vs. Processor
GDPR の下で、コントローラー は個人データ処理の目的と手段を決定します。プロセッサー はコントローラーに代わって個人データを処理します。共同コントローラー は 1 つ以上の他のコントローラーと目的と手段を共同で決定します。 区別が重要なのは、コントローラーがより重い義務を負うからです: 処理の法的根拠、データ主体の権利、DPIA、直接責任。鍵となる問いは「誰がデータに触れるか」ではなく「誰がそれで何が起こるかを決めるか」です。 広告では、仲介者がコントローラーと見なされるリスクは次のとき増加します:- それが知っているか推論する何かに基づいて特定の人に広告を表示すると決める
- 識別子が特性を持つと判断してセグメントを構築または投入する
- サードパーティのセグメントデータを他のデータと結合して新しいプロファイルを作る
- 特定のキャンペーン指示を超えた任意の目的にデータを使う
- データ主体またはデータプロバイダーと直接の関係を持つ当事者からの指示の下でデータを処理する
- 任意のセグメントまたはオーディエンスデータの権原を保持しない
- データを独立して、または自身の目的で使わない
- 新しいマッピングを作るためにソースをまたいでデータを結合しない
Why TMP’s Posture Is Unusual
バイヤーエージェントのプロセッサーポジションは、ad tech 業界が通常どう運営するかに対して珍しいです。ほとんどの DSP は、MSA がプロセッサーステータスを主張するときでさえ、自身の最適化目的のために共同コントローラーまたは独立コントローラーとして機能します。IAB Europe TCF フレームワークは、チェーンの各ベンダーに別々の目的と法的根拠を割り当てることでこれを反映します。 TMP のアーキテクチャは、従来の DSP が信頼できるかたちで主張できないバイヤーエージェントプロセッサーポジションを 可能にします。なぜなら:- バイヤーはユーザーアイデンティティとページコンテキストを一緒に決して受け取らない（DSP はすべての入札リクエストで両方を受け取る）
- バイヤーはアイデンティティに基づいてインプレッションごとの価格を設定しない（DSP はユーザーデータに基づいた入札価格を提出する）
- バイヤーはスコア付けされた入札ではなくバイナリの適格性を返す（DSP はユーザーの評価をエンコードする価格を返す）
The TMP Router: Processor
TMP ルーターはインフラです。ターゲティング決定を下さず、プロファイルを構築せず、ユーザーを評価しません。パブリッシャーからリクエストを受け取りバイヤーエージェントにファンアウトします。レスポンスを受け取りマージします。マージされた結果をパブリッシャーに返します。 ルーターが Context Match パスで見るもの:- コンテンツシグナル（トピック、キーワード、センチメント）
- プレースメント識別子
- 地理的コンテキスト（粗い）
- いかなる種類のユーザーアイデンティティもなし
- 不透明なユーザートークン
- パッケージ識別子
- 同意シグナル
- いかなる種類のページコンテキストもなし
- ユーザーが広告を見るべきかを評価する
- フリークエンシーキャップやオーディエンスメンバーシップを確認する
- ユーザープロファイルを構築または保存する
- コンテキストデータをアイデンティティデータと結合する
- 価格決定を下す
- リクエスト/レスポンスのライフサイクルを超えてデータを保持する
結論: ルーターは信頼できるかたちでプロセッサーステータスを主張できます。TEE アテステーションにより、これは独立に検証可能です。TEE なしでは、オペレーターの完全性とコード監査に依存します。
The Buyer Agent: Processor Conditional on Operational Discipline
TMP は、バイヤーが受け取るもの（アイデンティティを伴うコンテキストなし）と返すもの（適格なパッケージ ID、それ以上なし）をアーキテクチャ的に制約します。バイヤーが見るトークン、構築する露出履歴、実行する独自モデルで内部的に何をするかは制約しません。 したがってプロセッサーポジションは条件付きであり、アーキテクチャ的ではありません。それはバイヤーエージェントの運用上の選択とそれを統治する DPA に依存します。ほとんどのバイヤー側組織は、TMP が可能にするエンベロープの内側に留まるために意図的な選択をする必要があります。 アーキテクチャが提供するもの:- バイヤーはアイデンティティを伴うページコンテキストを決して受け取らない。Identity Match リクエストはページ URL、コンテンツシグナル、トピック ID を運ばない。
- バイヤーはインプレッションごとの価格を設定しない。Identity Match レスポンスは適格なパッケージ ID とキャッシュ TTL — 価格なし、入札なし、スコア付けされたレスポンスなし。
- バイヤーは提供決定を下さない。パブリッシャーが結合を実行する（または委譲する — the SSP question を参照）。
- 独自の適格性スコアリング。 適格性をスコア付けするために ML モデルを使うバイヤーエージェント — 広告主データのみで訓練されたモデルでさえ — は処理の手段を決定しています。「広告主基準を適用する」と「最適化エンジンを運用する」の間の線が、プロセッサーと共同コントローラーの間の線です。独自のオプティマイザーを実行し ない バイヤーエージェントは、既存の DSP に対して競争力がありません。これはエッジケースではなくベースケースです。
- クロス広告主データ結合。 複数の広告主を提供するバイヤーエージェントは、彼らのデータを分離して保たなければなりません。プロファイルを豊かにするために広告主をまたいでセグメントメンバーシップを結合することはコントローラーの動作です。
- 観察からのオーディエンス構築。 広告主提供のオーディエンスリストを適用する（プロセッサー）ことは、行動を観察してオーディエンスを構築する（コントローラー）ことと異なります。Risks requiring DPA scrutiny を参照。
- クロスパブリッシャー露出履歴。 クロスパブリッシャーフリークエンシーキャッピングは TMP の目玉ユースケースであり かつ 目玉のデータ保護エクスポージャーです。コンテキストがなくても、多くのパブリッシャーにわたってユーザートークンに結びついた露出履歴は、CJEU の判例の下で行動プロファイルを構成します。プロトコルはこれを除去しません — それを分離します。
結論: TMP はバイヤーエージェントプロセッサーポジションを可能にします。強制はしません。広告主とバイヤーエージェントの間の DPA は、バイヤーが見るトークンで何をしてよいか、露出履歴がどう有界化されるか、独自モデルが広告主データとどう相互作用するかを指定しなければなりません。
The Publisher and the SSP Join
パブリッシャーはファーストパーティです。ユーザーと直接の関係を持ちます。同意を収集します。コンテキスト（ユーザーが見ているもの）とアイデンティティ（ユーザーが誰か）の両方を保持します。TMP はパブリッシャーのコントローラーステータスを変えません。 パブリッシャーのコントローラー責任には次が含まれます:- Identity Match リクエストで同意シグナルを収集し送信する
- ユーザートークンが不透明でバイヤーエージェントによって PII に逆変換できないことを保証する
- コンテキストとアイデンティティの間の結合をローカルで実行する（または委譲する）
- 提供前に同意ロジックを適用する
- ルーターがどのプロバイダーを呼ぶかを設定する（データプロセッサー選択）
- どのアイデンティティプロバイダーのトークンを使うかを選択する（コントローラーレベルの決定 — Publisher configuration choices を参照）
結論: パブリッシャーはコントローラーのままです。結合が SSP またはラッパーに委譲される場合、その当事者は結合ステップの共同コントローラーになり、DPA チェーンで対処されなければなりません。
Pricing and Real-Time Decisions
コントローラー/プロセッサー分析の重要な要因は、仲介者がユーザーアイデンティティに基づいてリアルタイムの価格設定または入札決定を下すかどうかです。 TMP はアイデンティティに基づくリアルタイム価格設定を含みません。 プロトコルで価格設定が起こる箇所は次です:
TMP のどの参加者も「この特定のページのこの特定のユーザー」に基づいて価格を設定しません。Context Match パスは可変価格を含むかもしれません（バイヤーは一般的なコンテンツよりハイキングコンテンツをより高く評価するかもしれません）が、これはアイデンティティではなくコンテンツに基づきます。Identity Match パスは価格ではなく適格性を決定します。
事前交渉された価格モデルはアイデンティティと経済的成果の間のリンクを減らしますが、完全には除去しません。パブリッシャー（または SSP）が context match オファーを identity match 適格性と結合しパッケージをアクティベートするとき、経済的結果は、このページのこのユーザーがこの価格でこの広告を見たということです。規制当局は個々のプロトコルメッセージを検査するのではなくシステムを全体論的に評価するかもしれません。アーキテクチャの区別は、単一の仲介者が結合されたユーザー+コンテキストの価格決定を下さないことです。
これは、入札者がユーザーアイデンティティとページコンテキストを一緒に受け取りインプレッションごとの入札価格を提出する OpenRTB とは異なります。そのモデルでは、入札者はユーザーが誰かと彼らが何を見ているかを結合してリアルタイムの価格決定を下 せます。それをするかはキャンペーンに依存します — 多くの入札者は主にコンテキストで価格を設定しアイデンティティはフリークエンシーキャッピングにのみ使い、それはプロセッサーパターンに近いです。構造的な懸念は、OpenRTB がこの結合を 可能にし、プロセッサーポジションがアーキテクチャではなく契約上の制約に依存することです。TMP はこれらの関心をプロトコルレベルで分離します。
Out of Scope: Post-Impression Flows
TMP はリアルタイム決定のみをカバーします。 インプレッションが提供された後、配信レポート、コンバージョンイベント、アトリビューション、測定データがどう流れるかは仕様化しません。 これが重要なのは、すべてのキャンペーンがコンバージョントラッキング、ビュースルーアトリビューション、MMM 入力、インクリメンタリティ測定を必要とするからです。これらのフローは、インプレッションレベルのデータ — 通常ユーザートークン、クリエイティブ ID、タイムスタンプ、コンバージョンイベントを含む — をアトリビューションシステム（CM360、Innovid、Flashtalking）、DSP ネイティブのアトリビューションスタック、測定ベンダー（DV、IAS、iSpot、Nielsen）にルーティングします。これらのベンダーは通常、受け取るデータのコントローラーまたは共同コントローラーです。 オペレーターが既存のインプレッションログパイプラインを TMP 決定のキャンペーンに接続する場合、彼らは広く開いたインプレッション後のパイプに取り付けられたプライバシー保護のリアルタイム決定を構築したことになります。前面のアーキテクチャ保護は背面に届きません。 2 つのパスがこれに対処します:- スコープ制限デプロイ。 インプレッション後フローを、広告主、測定ベンダー、任意のクリーンルームオペレーターの間の既存の DPA によって統治される別個のデータ保護問題として扱う。TMP はアトリビューションプライバシーを解決するレバーではありません。既存のフレームワーク（クリーンルーム、測定 API、集約レポート）がそうです。
- 互換なアトリビューションを採用する。 バイヤーブラインドのコンバージョン API、クリーンルームで結合されるパブリッシャー側のコンバージョンログ、または TMP 自体と同じ分離規律を維持する集約測定システムを使う。これは新興領域です。AdCP はまだ「TMP 互換アトリビューション」パターンを仕様化していませんが、続くかもしれません。
Comparison: AXE (Deprecated) vs. TMP
TMP の前身 AXE は、より弱いデータ保護姿勢を持っていました:
AXE の設計は、エンドポイントオペレーター（通常オーケストレーター）がユーザーアイデンティティとページコンテキストを同じリクエストで受け取ることを意味しました。オペレーターのプロセッサーポジションは、結合されたデータを悪用しないという契約上のコミットメントに依存しました。TMP はこれを構造的分離に置き換えます — ルーターは一緒に決して保持しないデータを悪用できません。
Comparison: RTD Modules (Prebid Real-Time Data)
RTD モジュールは、オークション時に入札リクエストを豊かにするベンダー固有の Prebid 拡張です。各モジュールは完全な OpenRTB BidRequest（2-10KB）をベンダーエンドポイントに送り、それがエンリッチメントデータ（オーディエンスセグメント、コンテキスト分類、ブランドセーフティスコア）を返します。 データ保護の懸念: RTD モジュールはユーザーアイデンティティとページコンテキストを一緒に各ベンダーに送ります。ベンダーのプロセッサーポジションはアーキテクチャではなく契約に依存します。累積的なエクスポージャーは重大です: 5 つの RTD モジュールを使うパブリッシャーは、インプレッションごとに完全なユーザー+コンテキストのペイロードを 5 つの異なるベンダーエンドポイントに送ります。各ベンダーのプロセッサーポジションは独立して契約上のものです。 TMP は、ベンダー固有の RTD モジュールを分離を強制する標準化されたプロトコルに置き換えます。すべてをすべてのベンダーに送る代わりに、TMP はコンテキストをコンテキストパスに、アイデンティティをアイデンティティパスに送ります。結果は同じ（パッケージがアクティベートするかしないか）ですが、データエクスポージャーは構造的に最小化されます。Risks Requiring DPA Scrutiny
これらは DPA が対処しなければならない運用上のリスクです。アーキテクチャはそれらを制約しません。 1. クロスパブリッシャー露出履歴（目玉のバイヤーエージェントリスク）。 クロスパブリッシャーフリークエンシーを追跡するバイヤーエージェントは、ユーザートークンに結びついた露出履歴を維持します。ページコンテキストがなくても、これは行動プロファイルを構成します: このユーザーがいくつのプロパティに現れるか、どのくらい頻繁に、どのパブリッシャーカテゴリーにわたって。CJEU の Meta Platforms 決定（Case C-252/21）は、サービスをまたいでデータを結合することが、深いプロファイリングなしでもコントローラーレベルの処理を構成しうると確立しました。 これは脚注リスクではありません — それは目玉の TMP ユースケースの目玉のデータ保護エクスポージャーです。プロトコルはそれを除去しません。それを分離します。広告主とバイヤーエージェントの間の DPA は、法的根拠、保持期間、目的制限、消去フローを指定しなければなりません（第 17 条の権利が適用されます: 消去を行使するユーザーは、そのトークンに結びついたバイヤーの露出履歴が削除可能でなければならないことを意味します）。 2. リターゲティングオーディエンス構築。 オーディエンスを 適用する（ユーザートークンを広告主提供のリストに対して確認 — プロセッサーパターン）ことと、オーディエンスを 構築する（観察された行動に基づいてユーザートークンが特性を持つと判断 — コントローラーパターン）の間には区別があります。バイヤーエージェントがコンバージョンイベントやサイト訪問シグナルを受け取りリターゲティングプールを構築する場合、それはオーディエンスを構築しています。 リターゲティングオーディエンスがどうシステムに入るかが重要です。バイヤーが機械的に確認する広告主提供のリストはプロセッサーポジションをサポートします。観察された行動からのバイヤー構築オーディエンスはしません。 3. 独自の適格性スコアリング。 適格性をスコア付けするために ML モデルを使うバイヤーエージェント — 広告主データのみで訓練されたモデルでさえ — は処理の手段を決定しています。DPA は、バイヤーが実行してよいモデル、それらを訓練するデータ、それらの出力がどう制約されるかを指定すべきです。 4. 測定とアトリビューションフロー。 Out of Scope でカバー。TMP 自体とは別個のワークストリームとして扱う。Publisher Configuration Choices
これらはデータ保護の含意を持つパブリッシャー側の設定決定です。それぞれがパブリッシャーが下すコントローラーレベルの決定です。 1. アイデンティティプロバイダー選択。 TMP はアイデンティティプロバイダーからトークンを消費しますが、プロバイダーは交換可能ではありません。異なるグラフ動作は根本的に異なるリスク形状を作ります:
アイデンティティプロバイダーの選択自体がコントローラーレベルの決定です。決定論的クロスサイトトークンの選択は、バイヤーエージェントのクロスパブリッシャー相関サーフェスを拡大します。パブリッシャー DPA と同意フローは、すべての
uid_type 値を等価に扱うのではなく、プロバイダーの特定の姿勢を反映すべきです。
2. 完全なアーティファクトを伴う Context Match。
パブリッシャーが分類されたシグナル（context_signals）ではなく完全なコンテンツ（artifact フィールド）を送るとき、バイヤーエージェントは実際のコンテンツを受け取ります。context_signals（事前分類されたトピック、センチメント、キーワード）はプライバシー保護のベースラインです。完全なアーティファクトは、バイヤーがコンテンツを直接評価する必要のあるケース（例: 分類だけでは不十分な AI アシスタント会話）のために存在します。
3. キャッシュセマンティクス。
Identity Match レスポンスは ttl_sec キャッシュコントラクトを含みます。キャッシュウィンドウ中、ルーターはバイヤーに再クエリせずにキャッシュされた適格性を返します。キャッシュされた適格性は個人データです（ユーザートークンに結びついています）。仕様 は、推奨クランプ 3,600 秒で最大 86,400 秒（24 時間）の TTL を許します。ルーターは短い TTL を強制すべきで、有効期限を超えてキャッシュされたデータを保持してはならず、同じトークンの後続の Identity Match リクエストへの応答以外の任意の目的にキャッシュされた適格性を使ってはなりません。
4. コンテキストの可変価格。
Context Match オファーは OfferPrice を含められます。Context Match はアイデンティティを運ばないため、これはコンテキスト価格 — ユーザーごとの価格ではありません。しかし、パブリッシャーの context_signals が個人を識別するのに十分具体的（例: 一意の AI 会話 summary）な場合、コンテキストパスは事実上のアイデンティティを運びうる。パブリッシャーは context_signals が PII や一意に識別するコンテンツを含まないことを保証すべきです。
5. 結合の委譲。
パブリッシャーが context+identity 結合を SSP、ヘッダービッダーラッパー、またはサードパーティモジュールに委譲する場合、その当事者は結合ステップの共同コントローラーになります。パブリッシャーはより広い提供決定のコントローラーのままですが、DPA チェーンで委譲先の役割を対処しなければなりません。