アドプライバシーQ&A

Privacy Sandboxにおける広告集計技術の比較：Attribution Reporting, Private Aggregation, Shared Storageの技術的差異とデータプライバシー規制への適合性

はじめに

デジタル広告の世界は、サードパーティCookieの段階的廃止をはじめとするブラウザ側のプライバシー強化、およびGDPR、CCPA/CPRA、LGPDといったデータプライバシー規制の強化により、大きな変革期を迎えています。ユーザーレベルの個別データの収集・利用が制限される中で、広告のパフォーマンス測定、フリークエンシーキャップ、オーディエンス分析といった多くの機能は、個人を特定できない形での「集計データ」の活用に依存するようになっています。

Googleが提案するPrivacy Sandboxは、ブラウザ内でプライバシーを保護しながらこれらの広告機能を実現するためのAPI群を提供しています。中でも、集計データの生成に関わる主要なAPIとして、Attribution Reporting API、Private Aggregation API、そしてShared Storageと連携するAggregation Serviceが挙げられます。これらのAPIは、それぞれ異なる目的と技術的アプローチで集計機能を提供しており、その技術的な差異と、それがデータプライバシー規制の要件にどのように適合するのかを理解することは、ポストCookie時代の広告技術を実装する上で不可欠です。

本稿では、Privacy Sandboxにおけるこれら3つの主要な集計関連技術について、それぞれの技術仕様、集計メカニズム、プライバシー保護手法を詳細に比較分析し、さらにデータプライバシー規制、特にGDPRにおけるデータ最小化、目的制限、仮名化といった原則への技術的適合性について考察を加えます。

Privacy Sandboxにおける主要な集計関連APIの概要

Privacy Sandboxにおける集計機能は、ユーザーのブラウザ内で発生するイベントやデータをもとに、Aggregation Serviceという信頼された環境で集計処理を行い、ノイズを付加した集計レポートを生成するという共通のパターンを持ちます。しかし、ブラウザ内でAggregation Serviceに送信するデータがどのように生成されるか、またどのような種類のデータが集計されるかにおいて、各APIは大きく異なります。

• Attribution Reporting API (ARA): 広告のクリックやビューといったソースイベントと、コンバージョンといったトリガーイベントを結びつけ、アトリビューションレポートを生成するためのAPIです。イベントレベルレポートと集計レポートの二つの形式がありますが、プライバシー保護の観点から、ユーザー数を多く含む集計レポートがより推奨されています。集計レポートは、複数のユーザーからのデータをまとめて統計的な洞察を得ることを目的とします。
• Private Aggregation API (PAA): クロスサイト環境において、任意の離散的な値（バケット）と、それに関連付けられた集計可能な数値（値）のヒストグラムを作成し、集計レポートとして送信するためのAPIです。これは汎用的な集計手段として設計されており、Protected Audience APIのBidding and Scoring Workletや、Shared StorageのWorklet内から呼び出されることを想定しています。
• Shared Storage + Aggregation Service: Shared Storageに保存されたクロスサイトでアクセス可能なデータ（ただしキーバリュー形式で、値の直接読み出しには制限がある）を、Worklet内でPrivate Aggregation APIを介して集計し、レポートとして送信するパターンです。これにより、クロスサイト環境で特定のデータを集計的に利用することが可能になります。例えば、フリークエンシーキャップのカウントや、A/Bテストのグループ割り当てなどが考えられます。

各APIの技術仕様と集計メカニズムの詳細

これらのAPIは、Aggregation Serviceに送る前の段階で、ブラウザ内でユーザーの行動に基づいた集計用のデータを準備します。

Attribution Reporting API (ARA)

ARAにおける集計レポートは、設定された「集計キー」と「集計値」のペアに基づき生成されます。

• ソースイベント登録: attribution-reporting ヘッダーを用いて、広告クリックやビューに関連するデータをブラウザに登録します。このデータには、後続の集計に使用する情報（例えば、広告キャンペーンID、地理情報など）をエンコードした集計キーの一部や、レポートに含めるためのメタデータが含まれます。
• トリガーイベント登録: コンバージョンイベント（例えば、商品購入）が発生した際に、同様にattribution-reporting ヘッダーを用いてイベントを登録します。このトリガー登録時にも、集計キーの残りの部分や、コンバージョンに関する値（例えば、売上金額）をエンコードした集計値が指定されます。
• 集計キー (Aggregatable Key): ソースイベントとトリガーイベントの情報から構築される最大128ビットのキーです。このキーは、レポートが集計される際のグループ（バケット）を定義します。例えば、「キャンペーンX」「製品Y」「地域Z」といった組み合わせをキーで表現し、そのキーに対応するコンバージョン数や売上を集計するといった利用が想定されます。
• 集計値 (Aggregatable Value): トリガーイベントに関連付けられる数値です。これは、アトリビューションの対象となるイベントの重みや売上などを表すことが想定されます。
• レポート生成: ブラウザは、設定されたルール（例えば、特定のソースイベントに紐づくトリガーイベントが発生した場合）に基づいて、対応するソース・トリガーペアから集計キーと集計値を収集し、これらを暗号化してAggregation Serviceに送信するためのペイロードを生成します。このペイロードは、複数のユーザーからのものが集まって一定数に達するか、あるいは特定の期間が経過した後にまとめて送信されます。
• 差分プライバシー: ARAの集計レポートには、差分プライバシーのメカニズムが適用されます。これは、個々のユーザーのデータが集計結果に与える影響を抑制するために、ノイズを付加することによって実現されます。各ユーザーにはグローバルなプライバシー予算が付与されており、この予算内で集計値の貢献が制限されます。

Private Aggregation API (PAA)

PAAはより汎用的な集計ニーズに対応します。これは主にWorklet環境（Protected AudienceのBidding/Scoring WorkletやShared Storage Worklet）から呼び出されます。

• Worklet実行環境: PAAは、ユーザーのブラウザ内で隔離されたJavaScript実行環境であるWorklet内で利用されます。この環境は、Workletの所有者（広告主やSSPなど）が提供するスクリプトを実行しますが、スクリプトから直接ユーザーの識別子やクロスサイトデータにアクセスすることは厳しく制限されています。
• sendHistogramReport() メソッド: Worklet内で利用できるPAAの主要メソッドです。このメソッドは、集計するデータのヒストグラムを定義するバケット（bucket）と、集計対象の値（value）のペアのリストを受け取ります。
  • bucket: 64ビットの離散値であり、集計のキーとなります。Attribution Reporting APIの集計キーよりもビット数が少ない点に注意が必要です。
  • value: 32ビットの非負整数であり、集計対象となる数値です。
• レポート生成: sendHistogramReport() が呼び出されると、ブラウザは指定されたバケットと値のペアを収集し、これもまた暗号化してAggregation Serviceに送信するためのペイロードを生成します。ARAと同様に、このペイロードも一定数集まるか時間が経過した後にまとめて送信されます。
• ノイズ付加: Aggregation Serviceでの集計処理において、差分プライバシーの原則に基づきノイズが付加されます。PAAのノイズモデルは、ARAとは独立している可能性がありますが、基本的な考え方は同様です。

Shared Storage + Aggregation Service

Shared Storageは、ブラウザのオリジンごと、かつクロスサイト環境でデータの書き込みと読み出し（ただし読み出しにはWorklet経由などプライバシー制限がある）を可能にするストレージメカニズムです。このストレージに保存されたデータを集計するためにPAAが利用されます。

• Shared Storageへの書き込み: sharedStorage.set() メソッドなどを用いて、オリジン内でキーバリュー形式のデータを保存します。このデータは、他のオリジンからのWorkletからも間接的にアクセス可能です。
• Workletの利用: Shared Storage Worklet (sharedStorage.run()) を実行し、Workletスクリプト内でShared Storageに保存されたデータを読み出します（sharedStorage.get()）。
• PAAの呼び出し: Workletスクリプト内で読み出したデータを基に、Private Aggregation APIのsendHistogramReport() を呼び出します。例えば、Shared Storageに保存されたフリークエンシーカウントを読み出し、特定のバケット（広告キャンペーンIDなど）に対応する値としてPAAに渡すといった利用が可能です。
• 集計: PAAを通じてAggregation Serviceに送信されたデータは、他のユーザーからのデータと集計され、ノイズが付加されたレポートとして出力されます。

技術的差異の比較

| 特徴 | Attribution Reporting API (ARA) | Private Aggregation API (PAA) | Shared Storage + PAA | | :------------------- | :---------------------------------------------- | :------------------------------------------------ | :---------------------------------- | | 主な目的 | コンバージョンアトリビューション測定 | 汎用的なクロスサイト集計（Workletから利用） | Shared Storageデータのクロスサイト集計 | | 入力データソース | ソースイベント(クリック/ビュー), トリガーイベント(コンバージョン) | Workletスクリプト内のデータ | Shared Storage内のデータ | | 集計単位 (キー) | Aggregatable Key (最大128ビット) | Bucket (64ビット) | Bucket (64ビット, SSキーから導出可) | | 集計値 (値) | Aggregatable Value (非負整数) | Value (32ビット非負整数) | Value (32ビット非負整数, SS値から導出可) | | プライバシー保護 | 差分プライバシー予算管理, ノイズ付加 | ノイズ付加 | ノイズ付加 | | レポート形式 | 集計レポート (Aggregatable Report) | ヒストグラムレポート (Histogram Report) | ヒストグラムレポート | | レポート送信遅延 | 数日〜数週間 | 数時間〜数日 | 数時間〜数日 | | Aggregation Service | 利用 | 利用 | 利用 | | API連携 | なし (イベントトリガーでブラウザがペイロード生成) | Protected Audience/Shared Storage Workletから呼び出し | Shared Storage Workletから呼び出し |

最も大きな技術的差異は、集計の目的と入力データソース、そして集計キーのビット長です。ARAはアトリビューションに特化し、ブラウザが自動的にイベントを紐づけて集計データを生成するのに対し、PAAはWorklet内の任意のデータに基づいてより汎用的な集計を可能にします。Shared Storageとの組み合わせは、クロスサイト状態を持つデータの集計という特定のユースケースに対応します。また、集計キーのビット長の違いは、集計できるデータの粒度や次元数に直接影響します。

データプライバシー規制（GDPR/CCPA/CPRA等）への技術的適合性分析

これらのPrivacy Sandbox APIが提供する集計機能は、データプライバシー規制の原則に技術的に貢献することを目指しています。特にGDPRを例に、いくつかの重要な原則への適合性を分析します。

• データ最小化 (Art. 5(1)(c)): Privacy Sandbox API群は、ユーザーレベルの生データを広告主や測定ベンダーに直接渡すのではなく、ブラウザ内での処理とAggregation Serviceでの集計を通じて、個人を特定できない、集計レベルの情報のみをレポートとして提供します。これにより、収集・処理される個人データの量を最小限に抑える設計となっています。ARAのイベントレベルレポートは例外的に個人データを扱いますが、厳しいプライバシー閾値とデータ制限が課せられています。PAAやShared Storage+PAAは、設計上、個人を特定しうる直接的なデータをWorklet外に持ち出したり、Aggregation Serviceに送信したりすることを防ぐメカニズムを持っています。
• 目的制限 (Art. 5(1)(b)): 各APIは特定の目的に特化しています。ARAはアトリビューション、PAAは汎用的な集計、Shared Storage+PAAはShared Storageデータの集計です。APIの設計上、収集された集計データが当初の目的（例えば、アトリビューション測定）以外の目的（例えば、個人のプロファイリング）に容易に転用されることを技術的に困難にしています。Aggregation Serviceから出力されるレポートも、集計レベルであり、個人の特定には繋がらないように設計されています。
• 正確性 (Art. 5(1)(d)): Privacy Sandboxの集計レポートにはノイズが付加されます。これはプライバシー保護のための重要な技術的手段ですが、同時にレポートの「正確性」に影響を与えます。法規制上の正確性要件は、状況によって解釈が異なりますが、広告測定の文脈では統計的な精度が求められることが多いです。Privacy Sandboxは、ノイズのレベルとレポートの有用性のバランスを取るよう設計されていますが、高精度な個人の行動に基づく測定と比較すると、精度は低下します。実装者は、ノイズの影響を理解し、レポートの解釈においてその点を考慮する必要があります。
• 透明性 (Art. 5(1)(a), Art. 12): ユーザーに対し、どのようなデータが収集され、どのように処理・集計されるのかを透明性をもって説明する必要があります。Privacy SandboxのAPIはブラウザの機能として提供されるため、技術仕様は公開されています。しかし、これらのAPIがどのように動作し、どのような情報がAggregation Serviceに送信され、ノイズがどのように付加されるのかを、技術的知識を持たないユーザーに分かりやすく伝えることは容易ではありません。CMPなどを通じて、ユーザーがこれらのAPIによるデータ処理に同意またはオプトアウトできるメカニズムを提供することが、法規制への適合のために重要となります。また、同意取得時には、どのAPIがどのような目的で利用されるのかを、明確かつ具体的に説明する必要があります。
• 仮名化/匿名化 (Recital 26, Art. 4(5)): Privacy Sandboxの集計メカニズムは、ユーザーの識別子を直接扱わず、データを集計レベルで処理します。Aggregation Serviceでノイズが付加された最終的なレポートは、個人を特定できる可能性を大幅に低下させます。これは、法規制における「匿名化」や「仮名化」のアプローチと整合します。特にノイズ付加は、個人の再特定リスクを低減するための技術的・組織的措置の一つと見なすことができます。Aggregation ServiceがTrusted Execution Environment (TEE) で実行されることも、処理中のデータの機密性を高める技術的対策として重要です。

実装上の考慮事項

プライバシー重視の広告測定および集計機能をPrivacy Sandbox APIを用いて実装する際には、以下の点を考慮する必要があります。

1. API選択: 測定したい指標や利用したいデータソース（イベント、Worklet内データ、Shared Storageデータ）に基づいて、最適なAPIを選択します。アトリビューションにはARA、汎用的なカウントや統計にはPAA、クロスサイトでの状態管理と集計にはShared Storage+PAAが適しています。
2. 集計キー/バケット設計: 必要な集計粒度とプライバシー予算（特にARA）やバケット数の制限（PAA）を考慮して、集計キーまたはバケットを設計します。粒度を細かくしすぎると、ノイズの影響が大きくなったり、レポートが出力されなかったりする可能性があります。
3. Aggregation Serviceのセットアップと運用: 集計レポートを受け取り、復号、集計、ノイズ付加を行うAggregation Serviceは、クラウド環境にデプロイする必要があります。そのセットアップ、運用、監視、セキュリティ対策は実装者の責任となります。
4. 同意管理システム (CMP) との連携: GDPRやCCPA/CPRAでは、多くの場合、広告目的のデータ処理にはユーザーの同意が必要です。CMPを通じて取得した同意情報を、Privacy Sandbox APIの呼び出し制御や、Aggregation Serviceへのレポート送信の判断に適切に反映させる必要があります。Consent Mode v2のような標準化されたメカニズムも存在しますが、Privacy Sandbox APIとの具体的な連携ロジックを詳細に検討する必要があります。
5. ノイズの影響評価: 生成される集計レポートにはノイズが含まれるため、レポートの値をそのまま解釈するのではなく、ノイズの影響を考慮した分析手法を検討する必要があります。レポートの信頼区間などを理解し、測定データの不確実性を考慮した上で意思決定を行うことが重要です。
6. データプライバシー規制への継続的な適合性確認: Privacy Sandbox APIの仕様は進化する可能性があり、またデータプライバシー規制の解釈や適用も変化する可能性があります。実装後も、継続的に技術仕様の変更を追跡し、法規制の専門家と連携しながら、実装が最新の要件に適合しているかを確認する必要があります。特にDPIA/PIAは、これらの新しい技術を導入する際に実施が強く推奨されるプロセスであり、技術的なリスクと法的な要件を結びつけて評価するために重要です。

将来の展望と課題

Privacy Sandboxの集計技術はまだ発展途上にあり、今後の仕様変更や機能追加が予想されます。例えば、Aggregation Serviceの機能強化、異なるAPI間でのプライバシー予算の共有メカニズム、より高度な集計手法の導入などが考えられます。

主な課題としては、ノイズによる測定精度の限界、Aggregation Serviceの運用コストと複雑性、そしてこれらの技術をユーザーに分かりやすく説明し、適切な同意を得るためのUX設計が挙げられます。また、これらのブラウザベースの技術と、サーバーサイドでデータを処理する他のプライバシー保護技術（例：データクリーンルーム、セキュアマルチパーティ計算）との連携も、今後の重要な検討事項となるでしょう。

まとめ

Privacy SandboxのAttribution Reporting API、Private Aggregation API、そしてShared Storage+PAAは、ポストCookie時代における広告測定や分析に不可欠な集計機能を提供するための異なる技術的アプローチです。それぞれのAPIは、目的、入力データ、集計方法、プライバシー保護メカニズムにおいて差異があり、ユースケースに応じて適切に選択し、実装する必要があります。

これらの技術は、ユーザーレベルの直接的なデータ利用を回避し、集計レベルでの情報提供に焦点を当てることで、GDPRやCCPA/CPRAといったデータプライバシー規制におけるデータ最小化や目的制限といった重要な原則に技術的に貢献します。しかし、ノイズによる精度への影響や、ユーザーへの透明性確保といった課題も存在します。

フリーランスのWeb開発者やプライバシーコンサルタントとしては、これらのAPIの技術仕様を深く理解し、それぞれの集計がもたらすプライバシー保護レベルやデータの制約を正確に把握することが求められます。そして、クライアントのビジネス要件と適用される法規制を照らし合わせながら、最適なPrivacy Sandbox APIの活用方法を設計・実装し、ユーザーのプライバシーを尊重した広告エコシステムの構築に貢献していくことが重要となります。継続的な学習と、技術および法規制の最新動向への注意が不可欠な分野と言えるでしょう。