Schrems II とトラッキングピクセル：2026年に DPF が残す位置

2020年7月、CJEU はSchrems II（C-311/18）を下しました。2016年以来 EU-US データ転送のデフォルトメカニズムだったプライバシーシールドが無効にされました。一夜にして、Meta Pixel または Google タグを実行しているすべてのマーケティングチームは、有効な法的メカニズムなしにデータを転送しているか、標準契約条項（SCC）を締結するために慌てているか、または GDPR がユーザーのブラウザの JavaScript スニペットに何らかの形で及ばないという楽観的な解釈に依存しているかのどれかになりました。

その後、補足措置ガイダンス、転送影響評価（TIA）テンプレート、監督機関の執行措置が3年間続きました。そして2023年7月、欧州委員会はEU-US データプライバシーフレームワーク十分性決定を採択し、DPF 認証を受けた米国企業への十分性を回復しました。Meta、Google、Salesforce、HubSpot はすべてリストに掲載されています。

2026年のマーケティングとコンプライアンスチームへの問いは「DPF は存在するか」ではありません - 存在します。問いは、実際に何をカバーしているか、残余リスクがどこにあるか、そして潜在的な DPF への挑戦に耐えうる転送アーキテクチャが実際にどのようなものかです。

TL;DR#

• プライバシーシールド（2016年）は2020年7月に Schrems II によって無効にされました。SCC に補足措置を加えたものが2020年から2023年のギャップをカバーしました。
• EU-US データプライバシーフレームワーク（2023年7月）が現在の十分性決定です。DPF 認証企業への転送は SCC や TIA を必要とせずに十分性の恩恵を受けます。
• DPF 認証ベンダーへのクライアントサイドピクセルは、受信エンティティが認証されており、データ主体が通知を受け、ePrivacy 同意が必要な場合に整備されていれば、2026年において法的に防御可能です。
• DPF は法的挑戦が予想される対象です。デュアルモードトラッキング - DPF カバレッジ下のクライアントサイド、EU インフラからのサーバーサイド転送を構造的なフォールバックとして - は第三の Schrems 判決を生き残るアーキテクチャです。

Schrems II が実際に言ったこと#

判決はサマリーを通じてではなく直接読む価値があります。要旨は段落180〜202にあります。核心的な判断は、米国データ転送が本質的に違法というわけではありません。米国の監視法 - 具体的には FISA 702 と大統領令12333 - が米国の情報機関に EU データ主体の個人データへのアクセスを与えており、その方法がそれらの主体に対して GDPR 第77〜79条の下での実効的な救済を提供しないということです。

GDPR 第44条は、第V章のメカニズムのいずれかが適用されない限り、第三国への転送を禁止しています。プライバシーシールドは第45条の下での十分性決定でした。プライバシーシールドが無効であるとの裁判所の認定は、それに依存するすべての転送から十分性の根拠を剥奪しました。

標準契約条項は無効にされませんでした - しかし裁判所は同じ判決で、SCC は米国への転送に自動的に十分ではないと判示しました。SCC を使用するコントローラーまたはプロセッサーは、ケースバイケースで、宛先国の法制度が SCC レベルの保護が実際に機能するのを妨げるかどうかを確認しなければなりません。その要件が転送影響評価です：米国の監視法とそれが転送されるデータに与える影響の文書化された評価です。

補足措置に関する EDPB 勧告 01/2020 はこの要件を運用化しました。6ステップのプロセスと補足措置のカタログ - 技術的（暗号化、仮名化）、契約的、組織的 - が示されました。コントローラーは米国転送に SCC を依拠する際にこれらを評価すべきです。標準的なマーケティングピクセルの場合、ほとんどの技術的措置は実際には不可能でした：Meta が広告インプレッションへのコンバージョンをアトリビュートできるようにすることが目的のペイロードを意味のある形で暗号化することはできません。

これが2020年7月から2023年7月までマーケティングチームが生きたアーキテクチャです。SCC が署名されました。TIA が試みられました。オーストリア、フランス、イタリアの DPA は、特定の実装 - 特に Google Analytics - が SCC にもかかわらず補足措置が不十分であるとして非準拠であると判断しました。

データプライバシーフレームワークで何が変わったか#

EU-US データプライバシーフレームワーク（委員会決定（EU）2023/1795、2023年7月10日発効）は GDPR 第45条の下での十分性決定です。その法的前提は、米国の法制度 - バイデン大統領の大統領令14086とデータ保護審査裁判所を設立した後続の規則で修正された - が EU で保証されているのと本質的に同等の保護レベルを提供するというものです。

実際的な目的のために、DPF はこれを意味します：DPF 認証を受けた米国企業への転送は十分性の恩恵を受けます。SCC は必要ありません。TIA は必要ありません。受信エンティティがDPF 参加者リストに掲載されていることを確認する必要があります。これは公開で検索可能で、ほぼリアルタイムで更新されます。

Meta Platforms, Inc. は DPF 認証を受けています。Google LLC は DPF 認証を受けています。Salesforce, Inc. は DPF 認証を受けています。HubSpot, Inc. は DPF 認証を受けています。これらのベンダーへの広告と analytics に関連した EU 個人データの転送は、それらが DPF 認証の資格で受信している限り、2023年7月以降に十分性でカバーされます。

2つの明確化が重要です。まず、DPF 認証は任意です。EU データを処理するすべての米国企業が自己認証しているわけではありません。参加者リストが権威ある情報源です。認証を前提としないでください。次に、DPF 認証は特定の活動をカバーします。DPF 認証を受けた企業は、データタイプと目的によって、認証されたスコープの下または異なる法的根拠の下でピクセルデータを処理する場合があります。ピクセルを介した標準的なマーケティングアトリビューションには、DPF スコープがカバーします。

実際のマーケティングピクセルへの意味#

DPF カバレッジが整備されている状態で、認証ベンダーへのクライアントサイドマーケティングピクセルの法的態勢は次のようなものです。

クライアントサイドの Meta Pixel が Meta Platforms Inc.（DPF 認証済み）に発火するとき、それは十分な宛先への転送です。転送メカニズムは SCC ではなく DPF 十分性決定です。Meta Pixel の第30条の処理記録（RoPA）エントリは転送根拠を「SCC」ではなく「十分性決定（DPF）」として文書化します。SCC パスで必要だった TIA は必要ありません。

同じ分析は、Google LLC に発火する Google タグマネージャーと GA4、HubSpot Inc. に発火する HubSpot のトラッキングピクセル、Salesforce Inc. に発火する Salesforce Marketing Cloud のアトリビューションイベントにも適用されます。

ただし、十分性はマルチレイヤーのコンプライアンス像の1つの層です。この態勢が成立する前に3つの追加要件が整備されていなければなりません。

ePrivacy の同意。 ePrivacy 指令2002/58/EC第5条(3)は、ユーザーの端末機器での必須でない保存またはアクセスの前に同意を要求します。マーケティングピクセルは必須ではありません。同意バナーは問題のピクセルに特定的で、自由意志に基づき、撤回可能でなければなりません。転送先が DPF 十分であることは ePrivacy 同意要件に影響しません。これらは別々の法的文書です。

データ主体への透明性。 GDPR 第13条は、収集時に、データ受信者と第三国への転送について、コントローラーがデータ主体に通知することを要求します。DPF はこの透明性の義務を変更しません。プライバシーポリシーに「Meta Pixel を使用しています」と「米国への転送は十分性でカバーされます」と記載されている場合、それで十分です。米国への転送がまったく言及されていない場合、十分性決定は第13条のギャップを修正しません。

ベンダーとの第28条 DPA。 ピクセルベンダーは依然として GDPR 第28条の下でプロセッサーです。DPF は転送メカニズムをカバーします。DPA の代わりにはなりません。Meta、Google、HubSpot の標準的なデータ処理条件が、ピクセル関係の第28条文書です。これらが実行されていることを確認してください。

残余リスク#

DPF は永続的な解決ではありません。それは加盟国の裁判所、欧州議会、または国家監督機関によって CJEU に提訴できる十分性決定です。Max Schrems と NOYB は DPF に挑戦する意図を公に示しています - 潜在的な Schrems III です。その挑戦の法的理論は Schrems II に似ています：大統領令14086とデータ保護審査裁判所が実質的に EU 法で利用可能なものと同等の救済手段を提供しないというものです。

監督機関は CJEU の判決を待っていませんでした。オーストリア DSB の判決は、2022年 - DPF が発効する前 - の Google Analytics の実装について、SCC と補足措置が不十分であるため転送が違法であるとしました。フランスの CNIL とイタリアの Garante も同様の判断を下しました。これらの判決は DPF 以前の制度下でのものですが、監督パターンを確立します：DPA は単に契約書類だけでなく、ピクセルベースの転送の技術的な仕組みを検証する意志があります。DPF 以降の挑戦の下での将来の判決は、大統領令14086が確立した法的秩序が認証企業の保存データへの FISA 702 アクセスを真に制限するかどうかを検証する可能性があります。

トラッキングピクセルに関する特定の懸念は法的メカニズムを超えています。クライアントサイドピクセルは認証企業にデータを転送する以上のことをします。ユーザーのブラウザで JavaScript を実行し、ピクセルドメインのコンテキストでファーストパーティとサードパーティのクッキーを設定し、ブラウザから直接データを送信します。ブラウザを離れるデータはあなたのコントロール外にあります - 出発前に識別子をハッシュ化できず、どのフィールドが入力されるかを制限できず、ネットワーク検査なしにピクセルが実際に実行時に送信するものを確認できません。DPF の十分性は宛先をカバーします。転送前にピクセルが収集するものは対処されません。

この組み合わせ - DPF への潜在的な法的挑戦、書類だけでなく仕組みに対する監督機関の精査、クライアントサイドピクセルの動作についてコントローラーが確認できることの構造的制限 - は、単一トラックのクライアントサイド戦略がアーキテクチャ上脆弱であり続ける理由です。

実際の態勢：デュアルモードトラッキング#

DPF と潜在的な DPF 無効化の両方で成立するアーキテクチャはデュアルモードです。

最初のモードは、ePrivacy 同意が整備された現在の十分性の下で動作する DPF 認証ベンダーへのクライアントサイドピクセルです。これは DPF が成立している限り最も広いアトリビューションシグナルを提供します。ほとんどのマーケティングチームにとって、これは今日アトリビューションダッシュボードを埋めているモードです。

2番目のモードは EU インフラからのサーバーサイドコンバージョン転送です。ユーザーがリンクをクリックすると、Elido の EU リージョンのエッジがクリックを受け取り、EU の分析インフラに記録し、コンバージョンシグナルをサーバー間で広告プラットフォームのコンバージョン API（Meta CAPI、GA4 Measurement Protocol、またはそれに相当するもの）に転送します。ユーザーのブラウザは US エンドポイントに接触しません。EU インフラを離れるデータはハッシュ化されています（Meta CAPI が要求する通り、メールアドレスと電話番号に SHA-256）。転送はユーザーのブラウザで実行されるコードからではなく、あなたのコントロール下のインフラから発信されます。

DPF が無効にされた場合、代替フレームワークが整備されるまでクライアントサイドピクセルは非準拠の転送メカニズムになります。EU インフラで処理し、出発前に識別子をハッシュ化し、アトリビューションシグナルに狭くスコープを絞った補足措置付きの SCC を通じて実行されるサーバーサイドパスは、法務チームが一貫した TIA で防御できるフォールバックです。サーバーサイドパスは最初に EU インフラでデータを処理するため、転送はブラウザから米国エンドポイントへの直接転送としてではなく、コントローラー対プロセッサーとして文書化できます。

利用可能な場合は、ベンダーの EU エンドポイントを優先してください。data_collection_endpoint を region1.google-analytics.com に向けた GA4 は、Google 自身のドキュメントによると一部の処理は依然として米国インフラで行われるものの、Google の EU インフラでより多くの処理が行われます。Meta CAPI は現在 EU リージョンエンドポイントを提供していません。サーバー間転送は関係なく米国向けです。補足措置は識別子ハッシュ化であり、エンドポイントの地理ではありません。

ショートリンクのクリックアトリビューションとのサーバーサイド転送パスの統合の完全な仕組みについては、クッキーレスアトリビューションの解説で技術的なアーキテクチャを説明しています。マーケティングツールスタックで「EU ホスト」がどこから始まりどこで止まるかという EU 居住地の広い視点については、マーケティング向け EU データ居住地がコンパニオン投稿です。

DPF 下でのサブプロセッサーの同意#

すべての DPF 認証ピクセルベンダーは依然として GDPR 第28条の下でプロセッサーです。DPF 十分性決定は転送メカニズムをカバーします。並行して適用されるプロセッサー義務については何も言いません。

これはコントローラーが各ピクセルベンダーと第28条(3)(a)〜(h)の義務をカバーするデータ処理契約を締結する必要があることを意味します。Meta の標準的な広告データ条件、Google のデータ処理補遺、HubSpot の DPA がここでの文書です。これらは利用規約に同意するときに参照によって組み込まれた事前署名済みです。問いは、その契約をコンプライアンス記録に文書化しているかどうかです。

DPO が確認するサブプロセッサーリストはこれらのベンダーをカバーします。各ピクセルベンダーはリンクトラッキングプラットフォームと広告プラットフォーム間のアトリビューションチェーンのサブプロセッサーになります。Elido の公開サブプロセッサーリストは5つのベンダーを名指ししています。ピクセルベンダーは Elido 層ではなくコントローラー層のサブプロセッサーです。第30条の RoPA には別途列挙すべきです。

1つのニュアンス：GDPR 第28条(2)はプロセッサーがサブプロセッサーを関与させる前にコントローラーの承認を得ることを要求します。ピクセルの関係では、あなたがコントローラーとして Meta または Google と直接関与しています - これはチェーンサブプロセッサー関係ではなくコントローラー対プロセッサーの関係です。第28条 DPA はあなたとピクセルベンダーの間です。サーバーサイド転送の部分 - Elido のエッジがあなたに代わって Meta CAPI にイベントを転送する場合 - はサブプロセッサー関係です：Elido がプロセッサー、Meta CAPI がサブプロセッサーであり、DPA の義務は Elido の標準DPAを通じて流れます。

この区別は RoPA にとって重要です。記録を審査する DPA コンプライアンスチームは、2つの別々のエントリを見たいのです：1つは Elido プロセッサーの関係（リンク層のクリックイベントをカバー）、1つは各ピクセルベンダーの関係（ブラウザサイドのアトリビューションデータをカバー）。これらを混同すると、どちらの方向にも正確でない RoPA エントリが作成されます。

条文レベルの完全な GDPR プロセッサー義務については、URL ショートナーの GDPRがこのクラスターのコーナーストーン投稿です。

ピクセルベンダーの DPO の調達チェックリスト#

調達時にすべてのトラッキングピクセルベンダーに聞く5つの質問です。これらは DPF 時代のレビュー向けに書かれています。これを読んでいる時点で DPF のステータスが変わっている場合は、転送メカニズムの質問を調整してください。

1. 御社は現在 DPF 参加者リストに掲載されており、認証はどの活動をカバーしていますか？

リストはdataprivacyframework.govにあります。包括的な「はい、認証を受けています」ではなく、特定の認証スコープを求めてください。認証は活動スコープ付きです。ベンダーは人事データについては DPF 認証を受けているが商業的なクリックアトリビューションデータについては受けていない場合があります。

2. ピクセルを通じて送信するデータは実際にどこに保存されますか？使用できる EU リージョンエンドポイントはありますか？

DPF は認証された米国受信者への転送をカバーします。EU リージョンエンドポイントが利用可能な場合、それを使用すると転送の露出が減り、DPF が後で挑戦を受けた場合の TIA 分析に影響する可能性があります。RoPA エントリに回答を文書化してください。

3. 御社の標準データ処理契約は何ですか？第28条(3)(a)〜(h)の義務を明示的にカバーしていますか？

利用規約で参照によって組み込まれる事前署名された DPA は問題ありません。DPA が存在すること、どこで見つけるかを知る必要があります。DPA は転送メカニズムとは独立してプロセッサー関係を規定します。

4. 第17条の下での削除を特にピクセルで収集されたデータについて、どのようにデータ主体の権利リクエストを処理しますか？

クライアントサイドピクセルの場合、削除は通常プラットフォームのプライバシーコントロール（Meta のプライバシーセンター、Google のマイ広告センター）によって処理されます。即興せずにデータ主体のリクエストに回答できるようプロセスを文書化してください。

5. DPF が無効にされた場合、どのフォールバック転送メカニズムを提供しますか？どのタイムラインで？

この質問はベンダーが緊急時対応計画を持っているかをテストします。プライバシーシールドから SCC への移行（2020〜2021年）では、一部のベンダーは契約の更新が遅かった。補足措置を指定した DPF 無効化フォールバックとして SCC を文書化済みのベンダーはこの作業を終えています。「必要な場合に DPA を更新します」と言うベンダーはそうではありません。

Elido 固有の実装について：サーバーサイドコンバージョン転送は今日利用可能で、データが EU インフラを離れる前に SHA-256 識別子ハッシュ化があります。設定はワークスペースごとで、/legal/dpaの標準 DPA に文書化されています。DPF リスク許容度が低い場合、サーバーサイドパスはフォールバックだけでなく、主要な転送メカニズムとして利用可能です。