アドプライバシーQ&A

同意管理プラットフォームにおける同意粒度の技術的マッピング：Privacy Sandbox APIへの適用

はじめに

Webにおけるプライバシー保護の進化に伴い、サードパーティCookieに依存しない広告技術としてGoogle Privacy Sandbox API群が提案・導入されています。これらの新しいAPI群（Topics API, Protected Audience API, Attribution Reporting APIなど）は、従来のトラッキング技術とは異なるメカニズムで機能し、ブラウザによるプライバシー保護が強化されています。

一方で、データプライバシー規制（GDPR、CCPA/CPRA等）に基づき、多くのWebサイトではユーザーからの同意取得が必須となっています。同意管理プラットフォーム（CMP）は、ユーザーに対してデータ処理の目的や対象となるベンダーを明確に提示し、きめ細やかな同意オプションを提供する役割を担います。

ここで技術的な課題として浮上するのが、CMPで取得した、しばしば詳細かつ構造化された同意情報（例: 「広告目的のデータ利用に同意」「特定の広告テクノロジーベンダーAへのデータ連携に同意」など）を、Privacy Sandbox APIが提供する、より限定的または異なる粒度での制御メカニズム（例: API呼び出しの許可/不許可、特定の機能の有効化/無効化）に、いかに技術的に正確かつ効率的にマッピングし、連携させるかという点です。

本記事では、この同意粒度の技術的マッピングに焦点を当て、Privacy Sandbox API群における同意制御の仕組み、マッピングにおける技術的課題、および実践的な実装上の考慮事項について詳細に解説します。

Privacy Sandbox API群における同意制御メカニズム

Privacy Sandbox APIは、各APIごとにブラウザ側でユーザーのプライバシーを保護するための制御機構を備えています。これらの制御は、明示的なユーザー設定、Permissions API、あるいは特定のAPI呼び出しの挙動によって行われますが、これらを同意情報に基づいて動的に制御する必要があります。

• Topics API: ユーザーの閲覧履歴に基づき、ブラウザが関心のあるトピックを生成するAPIです。Topics APIの利用（トピックの取得）は、Origin Trial期間やその後の仕様変更を経て、Permissions Policyやユーザー設定によって制御可能となる方向性が見られています。CMPは、ユーザーがTopics APIによるトピック生成や利用を許可しない場合、関連するJavaScript APIの呼び出しをブロックしたり、適切なPermissions Policyを設定したりする必要があります。
• Protected Audience API (旧Fledge): リターゲティングやカスタムオーディエンスをプライバシーを保護しつつ実現するAPIです。ブラウザがオーディエンス参加リストを管理し、デバイス上でオークションを実行します。オークションへの参加可否、広告表示の可否は、ユーザー設定やブラウザの内部ロジックによって制御されます。CMPとの関連では、特定のオーディエンスリストへの追加 (navigator.joinAdInterestGroup) やオークションの実行 (navigator.runAdAuction) を、ユーザーの同意状況に応じて制御する必要があります。特に、ユーザーがパーソナライズ広告に同意していない場合、これらのAPI呼び出しは抑制されるべきです。
• Attribution Reporting API: コンバージョン計測をプライバシー保護の観点から行うAPIです。クリックやビューのイベント（ソースイベント）とコンバージョンイベント（トリガーイベント）を結びつけ、集計レポートまたはイベントレベルレポートを生成します。このAPIによるレポート登録やトリガー登録は、Permissions PolicyやHTTPヘッダーの付与によって制御されます。CMPは、ユーザーが計測を許可しない場合、ソースイベントの登録（window.attributionReporting.registerAdSource や attributionsrc 属性の付与）やトリガーイベントの登録（window.attributionReporting.registerAdTrigger や Attribution-Reporting-Register-Trigger ヘッダーの送信）を抑制する必要があります。特に、クロスサイトトラッキングに関連する計測に同意しないユーザーに対して、このAPIの利用を制限することが求められます。
• Shared Storage API / Private Aggregation API: クロスサイトで情報を共有する際に、Shared Storageでデータを書き込み・読み込みし、Private Aggregation APIで集計して利用するAPI群です。これらのAPIの利用も、Permissions Policyによって制御可能です。CMPは、ユーザーがクロスサイトでのデータ共有や集計に同意しない場合、これらのAPIの呼び出しを抑制する必要があります。

同意マッピングにおける技術的課題

CMPで取得される同意情報は、IAB TCF (Transparency & Consent Framework) のような標準フレームワークでは、目的（Purpose）やベンダー（Vendor）のリストとして構造化されています。しかし、Privacy Sandbox APIの同意制御メカニズムは、APIごとの利用許可/不許可や、特定の機能の有効化/無効化といった粒度であることが多いです。この間に技術的なマッピングの複雑性が生じます。

1. 同意粒度の不一致:

   • CMPで「パーソナライズ広告」という包括的な目的に同意した場合、これをPrivacy Sandbox APIのどの機能（Topicsによるトピック生成、Protected Audienceによるオーディエンスリスト参加、Attribution Reportingによるコンバージョン計測）にマッピングすべきか、その技術的な解釈が必要です。単にパーソナライズ広告に同意したからといって、Privacy Sandboxの全ての機能が有効になるわけではありませんし、法的要件上、より詳細な同意が必要な場合もあります。
   • 特定のベンダーに対する同意が、そのベンダーがPrivacy Sandbox APIをどのように利用するかに直結しない場合があります。ベンダーがProtected AudienceのBuy-Side Aggeratorとして機能する場合、ユーザーはそのベンダー自体ではなく、Protected Audience APIの利用に対して同意を与えるべきか、といったマッピングロジックが必要です。

2. 同意情報の伝達メカニズム:

   • CMPが取得した同意ステータスを、WebサイトのJavaScriptコードやバックエンドシステム、さらにはブラウザのPrivacy Sandbox API実装に技術的に伝達する方法を確立する必要があります。
   • クライアントサイドでの伝達: CMP SDKから取得した同意情報を、グローバル変数、ローカルストレージ、またはカスタムイベントなどを介して、Privacy Sandbox APIを呼び出すJavaScriptコードに渡す方法。
   • サーバーサイドへの伝達: 同意ステータスをHTTPヘッダーやリクエストパラメータとしてバックエンドに送信し、サーバーサイドで生成されるコンテンツ（例: attributionsrc 属性付きのHTML要素、Attribution Reporting関連のHTTPヘッダー）に影響を与える方法。
   • ブラウザへの直接的な伝達: 将来的に、同意情報が標準化された方法でブラウザに伝達され、APIの挙動を直接制御するメカニズムが登場する可能性も考えられます（例: 標準化された同意API）。しかし現状では、JavaScriptやHTTPヘッダーを通じた制御が中心です。

3. 複数のAPIへの対応:

   • サイト上で複数のPrivacy Sandbox APIを利用する場合、それぞれのAPIの同意制御要件と、CMPで取得した統一的な同意情報を、適切に連携させる必要があります。例えば、Protected Audience APIとAttribution Reporting APIの両方を利用する場合、それぞれのAPI呼び出し前に、関連する同意目的（例: パーソナライズ、計測）に対するユーザーの同意を確認し、APIの実行可否を判断するロジックが必要です。

4. 同意変更時の対応:

   • ユーザーが同意設定を変更した場合、Privacy Sandbox APIの挙動にその変更が即座に、または合理的な時間内に反映されるように技術的な仕組みを構築する必要があります。これは、ブラウザ側の設定や保存された同意シグナルを速やかに更新することを意味します。

実装上の考慮事項

同意粒度の技術的マッピングとPrivacy Sandbox APIへの連携を実装する際には、以下の点を考慮する必要があります。

1. 同意ロジックの一元管理:

   • Webサイトの様々な箇所でPrivacy Sandbox APIが呼び出される可能性があるため、同意確認のロジックを中央集権的に管理することが推奨されます。特定のユーティリティ関数やクラスを作成し、API呼び出し前に必ずその関数を介して同意状況を確認する設計とすることで、ロジックの重複や不整合を防ぎます。

   ```javascript // 擬似コード：同意確認ユーティリティ class ConsentManager { // CMP SDKから同意情報を取得・保持 getConsentStatus(purposeId, vendorId) { // CMP SDKのAPIを呼び出し、指定された目的・ベンダーに対する同意状況を返す // 例: return cmpSDK.hasConsent(purposeId, vendorId); return true; // 仮の実装 }

   // Protected Audience API実行前に同意確認 canRunProtectedAudienceAuction() { // パーソナライズ広告目的の同意を確認するなど const requiresPurposeId = 1; // 例: IAB TCF Purpose 1 (Store and/or access information on a device) const requiresPurposeIdPersonalization = 4; // 例: IAB TCF Purpose 4 (Select personalised advertising)

   if (!this.getConsentStatus(requiresPurposeId) || !this.getConsentStatus(requiresPurposeIdPersonalization)) {
     console.log("Protected Audience auction blocked due to lack of consent.");
     return false;
   }
   // 必要に応じて、関連ベンダーへの同意も確認
   // if (!this.getVendorConsent(vendorId)) return false;
   return true;
   

   }

   // Attribution Reporting API登録前に同意確認 canRegisterAttributionSource() { // 計測目的の同意を確認するなど const requiresPurposeIdMeasurement = 7; // 例: IAB TCF Purpose 7 (Measure ad performance) if (!this.getConsentStatus(requiresPurposeIdMeasurement)) { console.log("Attribution source registration blocked due to lack of consent."); return false; } return true; }

   // 他のAPIに対する同意確認メソッドを追加 canUseTopicsAPI() { / ... / } canUseSharedStorage() { / ... / } }

   const consentManager = new ConsentManager();

   // Protected Audience API呼び出し箇所の例 if (consentManager.canRunProtectedAudienceAuction()) { // navigator.runAdAuction(...) を実行 }

   // Attribution Reporting APIソース登録箇所の例 if (consentManager.canRegisterAttributionSource()) { // window.attributionReporting.registerAdSource(...) または を実行 } ```

2. 同意情報の粒度マッピング定義:

   • CMPで取得する同意目的やベンダーと、各Privacy Sandbox APIの利用要件との間のマッピングルールを明確に定義します。これは、法務チームやプライバシーコンサルタントと連携し、法的要件を満たすように設定する必要があります。例えば、「IAB TCF Purpose 4 (Select personalised advertising)」に同意した場合にProtected Audience APIとTopics APIを許可する、といった具体的なマッピング表を作成します。

3. 同意伝達メカニズムの選択:

   • クライアントサイドでの制御が基本となりますが、サーバーサイドで生成される要素（例: attributionsrc 属性付きのリンクや画像）に同意状況を反映させる必要がある場合は、同意ステータスをサーバーサイドに安全に伝達する仕組み（例: ファーストパーティCookie、サーバーへの非同期リクエスト）が必要です。

4. ブラウザパーミッションAPIの活用:

   • Topics APIのようにPermissions APIで制御される機能については、CMPからPermissions APIを通じてブラウザに意図を伝達する標準的な方法が整備されるか、あるいは現行仕様に基づいてJavaScriptで制御を行うかを検討します。Permissions APIはユーザーにとって透明性が高い制御方法となり得ますが、CMP側の実装やブラウザ側の対応状況を確認する必要があります。

5. デバッグと監査:

   • 同意マッピングが正しく機能しているかを確認するためのデバッグツールやログ機構を実装します。ユーザーの同意状況に応じてAPI呼び出しが正しく抑制されているか、必要な場合にAPIが実行されているかなどを検証します。また、法的要件を満たすために、同意の取得、拒否、変更の履歴を監査可能な形式で記録することも重要です。

6. ベンダー連携:

   • DSP、SSP、広告サーバーなどの広告テクノロジーベンダーがPrivacy Sandbox APIを利用する場合、CMPからこれらのベンダーシステムへ同意情報を正確に伝達する仕組みが必要です。IAB TCF Consent Stringのような標準形式を用いるか、あるいはベンダー固有の同意伝達メカニズムに対応する必要があります。ベンダーがProtected Audience APIの入札に参加する際に、ユーザーの同意状況を正しく判断できるような技術的な連携が必要です。