> ## 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 のアーキテクチャが GDPR のコントローラー/プロセッサーロールにどうマップするか — 各当事者が何を決定するか、各当事者がどのデータを保持するか、リスクがどこにあるか。 # データ保護ロール このページは TMP のアーキテクチャを GDPR データ保護ロール（コントローラー、プロセッサー、共同コントローラー）にマップします。各参加者が個人について何を決定できて何を決定できないか、アーキテクチャの境界がどこでプロセッサーポジションをサポートし、どこでしないかを説明します。 これはアーキテクチャの分析であり法的助言ではありません。組織は特定の状況について資格のあるデータ保護顧問に相談すべきです。[TMP プライバシーアーキテクチャ](/docs/trusted-match/privacy-architecture) への習熟が前提とされます — 構造的分離、TEE アテステーション、パッケージセット相関除去、時間的相関除去のような概念はそこで定義されます。 ## Verdict at a Glance | Participant | Role | Confidence | Where the risk sits | | ----------------------------- | -------------------------- | ----------- | ------------------------------------------------------------------------------------------------ | | **TMP Router** | プロセッサー | 高（アーキテクチャ的） | オペレーターデプロイの完全性。TEE アテステーションで緩和。 | | **Buyer agent** | プロセッサー | 条件付き（運用上） | 独自スコアリング、クロス広告主データ結合、オーディエンス構築、クロスパブリッシャー露出蓄積。 | | **Publisher** | コントローラー | 変わらず | 同意収集、データプロセッサーの設定、最終的な提供決定。 | | **SSP / 結合を実行するラッパー** | パブリッシャーの共同コントローラーまたはプロセッサー | 条件付き | context+identity 結合を実行する者がそのステップのコントローラー責任を継承する。 | | **Identity provider** | TMP のスコープ外。トークン発行のコントローラー | プロバイダーによる | トークンスコープとグラフ動作（publisher-first-party 対 決定論的クロスサイト 対 確率的グラフ）がパブリッシャーのリスクを実質的に変える。 | | **Measurement / attribution** | TMP のスコープ外 | 該当なし | インプレッション後フローが、TMP が対処しないコントローラー分析を再導入する。[Out of Scope](#out-of-scope-post-impression-flows) を参照。 | ## 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 パスで見るもの:** * コンテンツシグナル（トピック、キーワード、センチメント） * プレースメント識別子 * 地理的コンテキスト（粗い） * いかなる種類のユーザーアイデンティティもなし **ルーターが Identity Match パスで見るもの:** * 不透明なユーザートークン * パッケージ識別子 * 同意シグナル * いかなる種類のページコンテキストもなし 2 つのパスは構造的に分離されています: 共有メモリなし、共有状態なし、通信チャネルなし。単一のコードパスが両方を保持することがないため、ルーターはユーザートークンをページ URL と関連付けられません。強制メカニズムについては [プライバシーアーキテクチャ](/docs/trusted-match/privacy-architecture) を参照。 **ルーターがしないこと:** * ユーザーが広告を見るべきかを評価する * フリークエンシーキャップやオーディエンスメンバーシップを確認する * ユーザープロファイルを構築または保存する * コンテキストデータをアイデンティティデータと結合する * 価格決定を下す * リクエスト/レスポンスのライフサイクルを超えてデータを保持する ルーターはパブリッシャーの指示（どのプロバイダーを呼ぶか、どのプロパティを提供するか）に基づいて動作するプロセッサーです。個人データ（不透明なユーザートークン）を、それらをバイヤーエージェントに配信し結果を返すためだけに処理します。 > **結論:** ルーターは信頼できるかたちでプロセッサーステータスを主張できます。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](#the-publisher-and-the-ssp-join) を参照）。 **プロセッサーポジションが侵食する箇所:** * **独自の適格性スコアリング。** 適格性をスコア付けするために ML モデルを使うバイヤーエージェント — 広告主データのみで訓練されたモデルでさえ — は処理の手段を決定しています。「広告主基準を適用する」と「最適化エンジンを運用する」の間の線が、プロセッサーと共同コントローラーの間の線です。独自のオプティマイザーを実行し *ない* バイヤーエージェントは、既存の DSP に対して競争力がありません。これはエッジケースではなくベースケースです。 * **クロス広告主データ結合。** 複数の広告主を提供するバイヤーエージェントは、彼らのデータを分離して保たなければなりません。プロファイルを豊かにするために広告主をまたいでセグメントメンバーシップを結合することはコントローラーの動作です。 * **観察からのオーディエンス構築。** 広告主提供のオーディエンスリストを適用する（プロセッサー）ことは、行動を観察してオーディエンスを構築する（コントローラー）ことと異なります。[Risks requiring DPA scrutiny](#risks-requiring-dpa-scrutiny) を参照。 * **クロスパブリッシャー露出履歴。** クロスパブリッシャーフリークエンシーキャッピングは TMP の目玉ユースケースであり *かつ* 目玉のデータ保護エクスポージャーです。コンテキストがなくても、多くのパブリッシャーにわたってユーザートークンに結びついた露出履歴は、CJEU の判例の下で行動プロファイルを構成します。プロトコルはこれを除去しません — それを分離します。 > **結論:** TMP はバイヤーエージェントプロセッサーポジションを可能にします。強制はしません。広告主とバイヤーエージェントの間の DPA は、バイヤーが見るトークンで何をしてよいか、露出履歴がどう有界化されるか、独自モデルが広告主データとどう相互作用するかを指定しなければなりません。 ## The Publisher and the SSP Join パブリッシャーはファーストパーティです。ユーザーと直接の関係を持ちます。同意を収集します。コンテキスト（ユーザーが見ているもの）とアイデンティティ（ユーザーが誰か）の両方を保持します。TMP はパブリッシャーのコントローラーステータスを変えません。 パブリッシャーのコントローラー責任には次が含まれます: * Identity Match リクエストで同意シグナルを収集し送信する * ユーザートークンが不透明でバイヤーエージェントによって PII に逆変換できないことを保証する * コンテキストとアイデンティティの間の結合をローカルで実行する（または委譲する） * 提供前に同意ロジックを適用する * ルーターがどのプロバイダーを呼ぶかを設定する（データプロセッサー選択） * どのアイデンティティプロバイダーのトークンを使うかを選択する（コントローラーレベルの決定 — [Publisher configuration choices](#publisher-configuration-choices) を参照） **実際の結合。** 「パブリッシャーが結合をローカルで実行する」は原理的には正しく実際には不完全です。ほとんどのパブリッシャーは、「提供前に 2 つのリアルタイム API レスポンスを同意ロジックで結合する」プリミティブをネイティブに公開しないアドサーバー（Google Ad Manager、Kevel、Equativ）を運用します。GAM を使うパブリッシャーは通常、結合を実行するためにヘッダービッダーラッパー、Prebid モジュール、または SSP シムを必要とします。多くはそれを SSP（Magnite、PubMatic、Index Exchange、OpenX）にアウトソースします。 結合が委譲されるとき、SSP またはラッパーは結合ステップ自体のコントローラー責任を継承します。パブリッシャーの SSP との DPA はこれを反映しなければなりません: SSP は、そのより広いサービスがどう特徴付けられるかに応じて、結合の共同コントローラー（または結合に特にスコープされたプロセッサー）になります。結合を委譲することによって「TMP が私をプロセッサーにした」と仮定するパブリッシャーは、アーキテクチャを誤読しています。 > **結論:** パブリッシャーはコントローラーのままです。結合が SSP またはラッパーに委譲される場合、その当事者は結合ステップの共同コントローラーになり、DPA チェーンで対処されなければなりません。 ## Pricing and Real-Time Decisions コントローラー/プロセッサー分析の重要な要因は、仲介者がユーザーアイデンティティに基づいてリアルタイムの価格設定または入札決定を下すかどうかです。 **TMP はアイデンティティに基づくリアルタイム価格設定を含みません。** プロトコルで価格設定が起こる箇所は次です: | Decision | When | Based on | Where | | -------------------- | --------------- | -------------------------------------------------- | --------------------------------- | | パッケージ価格 | メディアバイ交渉（オフライン） | プロダクトカタログ、ボリューム、条件 | バイヤーエージェントとパブリッシャー、任意のユーザーが評価される前 | | Context Match オファー価格 | リクエスト時 | コンテンツコンテキストのみ — ユーザーアイデンティティなし | Context Match パス（アイデンティティデータ利用不可） | | Identity Match 適格性 | リクエスト時 | フリークエンシーキャップ、オーディエンスメンバーシップ | Identity Match パス（コンテキストデータ利用不可） | | 最終提供決定 | 両レスポンスが返った後 | パブリッシャー（または SSP）が context + identity + consent を結合 | パブリッシャーインフラまたは SSP に委譲 | 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 つのパスがこれに対処します: 1. **スコープ制限デプロイ。** インプレッション後フローを、広告主、測定ベンダー、任意のクリーンルームオペレーターの間の既存の DPA によって統治される別個のデータ保護問題として扱う。TMP はアトリビューションプライバシーを解決するレバーではありません。既存のフレームワーク（クリーンルーム、測定 API、集約レポート）がそうです。 2. **互換なアトリビューションを採用する。** バイヤーブラインドのコンバージョン API、クリーンルームで結合されるパブリッシャー側のコンバージョンログ、または TMP 自体と同じ分離規律を維持する集約測定システムを使う。これは新興領域です。AdCP はまだ「TMP 互換アトリビューション」パターンを仕様化していませんが、続くかもしれません。 TMP 採用を評価する DPO は、インプレッション後フローを独立したワークストリームとして扱い、プロトコルの分離プロパティがそれらに拡張されると仮定すべきではありません。 ## Comparison: AXE (Deprecated) vs. TMP TMP の前身 [AXE](/docs/media-buy/advanced-topics/agentic-execution-engine) は、より弱いデータ保護姿勢を持っていました: | | AXE | TMP | | ---------------------- | ----------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | リアルタイムエンドポイントが受け取ったもの | 完全な OpenRTB スタイルのリクエスト: ユーザーアイデンティティ + ページコンテキスト + デバイスシグナル | 別々のリクエスト: コンテキスト **または** アイデンティティ、決して両方でない | | 誰がユーザー + コンテキストを一緒に見たか | AXE エンドポイントオペレーター | パブリッシャー（または委譲された SSP）のみ、ファーストパーティとして | | プロファイル構築リスク | オペレーターは理論的に閲覧プロファイルを構築できた | ルーターについてアーキテクチャ的に制約（どのコードパスも両方のシグナルを保持しない）。バイヤー側の相関は [相関除去メカニズム](/docs/trusted-match/privacy-architecture) によって妨げられるが、SHOULD レベルの要件へのパブリッシャーの遵守に依存 | | 価格モデル | 不透明なセグメント決定がアドサーバーターゲティングに供給 | 事前交渉されたパッケージ価格、インプレッションごとの入札なし | | 分離の強制 | 信頼と契約 | コード構造（監査可能）または TEE アテステーション（検証可能） | 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](#out-of-scope-post-impression-flows) でカバー。TMP 自体とは別個のワークストリームとして扱う。 ## Publisher Configuration Choices これらはデータ保護の含意を持つパブリッシャー側の設定決定です。それぞれがパブリッシャーが下すコントローラーレベルの決定です。 **1. アイデンティティプロバイダー選択。** TMP はアイデンティティプロバイダーからトークンを消費しますが、プロバイダーは交換可能ではありません。異なるグラフ動作は根本的に異なるリスク形状を作ります: | Token type | Risk shape | Examples | | --------------------- | --------------------------------------------------- | ------------------------------------------- | | Publisher-first-party | クロスサイトリンクなし。最低リスクプロファイル。 | `publisher_first_party`（パブリッシャーごとのハッシュ化識別子） | | 決定論的クロスサイト | 同じユーザーがサイトとデバイスをまたいで同じトークンに解決。クロスサイトプロファイリングを可能にする。 | UID2（The Trade Desk が運用、主にバイ側使用）、ID5 | | 確率的 / 商用グラフ | プロバイダーが、プロバイダーの壁の内側でトークンを PII に解決するアイデンティティグラフを運用。 | RampID（LiveRamp） | アイデンティティプロバイダーの選択自体がコントローラーレベルの決定です。決定論的クロスサイトトークンの選択は、バイヤーエージェントのクロスパブリッシャー相関サーフェスを拡大します。パブリッシャー DPA と同意フローは、すべての `uid_type` 値を等価に扱うのではなく、プロバイダーの特定の姿勢を反映すべきです。 **2. 完全なアーティファクトを伴う Context Match。** パブリッシャーが分類されたシグナル（`context_signals`）ではなく完全なコンテンツ（`artifact` フィールド）を送るとき、バイヤーエージェントは実際のコンテンツを受け取ります。`context_signals`（事前分類されたトピック、センチメント、キーワード）はプライバシー保護のベースラインです。完全なアーティファクトは、バイヤーがコンテンツを直接評価する必要のあるケース（例: 分類だけでは不十分な AI アシスタント会話）のために存在します。 **3. キャッシュセマンティクス。** Identity Match レスポンスは `ttl_sec` キャッシュコントラクトを含みます。キャッシュウィンドウ中、ルーターはバイヤーに再クエリせずにキャッシュされた適格性を返します。キャッシュされた適格性は個人データです（ユーザートークンに結びついています）。[仕様](/docs/trusted-match/specification) は、推奨クランプ 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 チェーンで委譲先の役割を対処しなければなりません。