アドプライバシーQ&A - クロスサイトデータ活用のためのShared Storage APIとPrivate Aggregation API連携：技術詳細と実装課題

クロスサイトデータ活用のためのShared Storage APIとPrivate Aggregation API連携：技術詳細と実装課題

Tags: Privacy Sandbox, Shared Storage API, Private Aggregation API, クロスサイトデータ, データプライバシー

はじめに：ポストCookie時代のクロスサイトデータ活用における課題

サードパーティCookieの廃止は、広告技術エコシステムにおけるクロスサイトでのユーザー行動追跡やデータ共有の根幹を揺るがしています。これまでサードパーティCookieに依存していた多様なユースケース（例: クロスサイトでの頻度制限、オーディエンスターゲティングのための情報共有、コンバージョン計測後のレポート最適化など）は、新たなプライバシー保護技術による代替を必要としています。

Googleが提唱するPrivacy Sandboxは、こうした課題に対する一連の新しいAPI群を提供しています。中でも、Shared Storage APIとPrivate Aggregation APIは、クロスサイト環境下で特定の限定的な情報を保存し、その情報をプライバシー保護された形で集計レポートとして出力するための重要なコンポーネントです。これらのAPIを連携させることで、個々のユーザーを識別することなく、サイトを跨いだ集計データを活用する道が開かれます。

本記事では、Shared Storage APIとPrivate Aggregation APIのそれぞれの技術仕様、そしてそれらがどのように連携して機能するのかを詳細に解説します。また、これらの技術を実装する上で直面しうる具体的な課題、プライバシー保護のメカニズム、および関連する法規制への影響についても考察します。専門家レベルの知見を持つ読者の方々が、これらの新しいAPI群を理解し、自身のシステム設計やクライアントへのアドバイスに役立てられることを目指します。

Shared Storage APIの技術仕様と機能

Shared Storage APIは、クロスサイトトラッキングを可能にすることなく、クロスサイトのコンテキストで特定の情報を保存および読み出すためのブラウザAPIです。これはオリジンごとにパーティション化されないストレージを提供しますが、このストレージに直接アクセスできるのは、定義された特定の「Worklet」内からのみという厳格な制限があります。

1. 目的と概要

Shared Storage APIの主な目的は、プライバシーを保護しながら、限定された特定のクロスサイト操作を可能にすることです。例えば、ユーザーが複数のサイトを訪問した際に、その訪問履歴や特定のアクション（例: 特定の広告表示回数）に関する情報を、個々のユーザーを識別せずに集計やレポート作成に利用するなどが考えられます。

2. ストレージの仕組み

Shared Storageは、キーとバリューのペアを保存できるシンプルなデジタルストレージです。これは通常のブラウザストレージ（LocalStorageなど）と異なり、トップレベルフレームからは直接読み書きできません。読み書き操作は、Fetch APIをサポートするJavaScript環境である「Worklet」と呼ばれる隔離された環境内でのみ許可されます。

3. Workletの役割

WorkletはShared Storage APIの中核をなすセキュリティメカニズムです。Workletで実行されるスクリプトは、ネットワークアクセスや他のブラウザAPIへのアクセスに厳しい制限を受けます。特に、Workletから直接ユーザーIDやストレージ内の生データを外部に送信することはできません。許可されている主な操作は以下の二つです。

run(): ストレージ内のデータを読み出し、そのデータに基づいて特定の処理（例: データ集計の下準備、オーディエンスリストの更新など）を実行しますが、処理結果を直接外部に出力することはできません。
selectURL(): ストレージ内のデータを読み出し、そのデータに基づいて複数の提供されたURLの中から一つを選択します。この選択は、Fenced Frames APIと連携してプライベートな広告表示などを実現するために使用されます。

Private Aggregation APIとの連携においては、主にrun()メソッドを利用し、Worklet内でストレージの値を読み取り、その値をPrivate Aggregation APIに渡して集計レポート用のデータを作成します。

4. 制限事項

Shared Storage APIにはいくつかの重要な制限があります。

ストレージサイズには上限があります。
Workletの実行には時間制限があります。
Worklet内からは、ネットワークリクエストの送信や他のブラウザAPI（DOM操作など）へのアクセスが制限されます。
ストレージへの直接的なアクセスは禁止されており、Worklet経由での限定的な操作のみが可能です。

これらの制限は、プライバシー保護と悪用防止のために設計されています。

Private Aggregation APIの技術仕様と機能

Private Aggregation APIは、クロスサイト環境で収集されたデータに対して、プライバシー保護された形で集計レポートを作成するためのAPIです。Shared Storage APIやProtected Audience APIなどの他のPrivacy Sandbox APIと連携して使用されることが想定されています。

1. 目的と概要

Private Aggregation APIの主な目的は、個々のユーザーレベルのデータ漏洩を防ぎつつ、特定のイベントに関する集計レポート（例: ある広告が複数のサイトで表示された合計回数、特定のアクションを実行したユーザーの合計数など）を生成することです。これは、集計サービス（Aggregation Service）と呼ばれる信頼できるサーバー環境によって実現されます。

2. レポートの仕組み

Private Aggregation APIは、ブラウザ内で「集計可能な値」（aggregatable value）と「集計キー」（aggregation key）を含む「集計可能なレポート」（aggregatable report）を生成します。このレポートは暗号化されており、ブラウザから直接読み取ることはできません。

この暗号化されたレポートは、収集オリジン（レポートを生成したサイト）から収集サーバー（例: 広告主や広告測定プロバイダーのサーバー）に送信されます。収集サーバーは、複数のブラウザから送られてきた集計可能なレポートを一定量まとめて、集計サービスにバッチで送信します。

集計サービスは、これらの暗号化されたレポートを復号し、共通の集計キーを持つ値の合計を計算します。集計サービスは、機密計算環境（Trusted Execution Environment: TEE）内で動作することが推奨されており、ベンダーによるデータの不正利用を防ぐ設計となっています。

最後に、集計サービスは合計値にノイズ（差分プライバシーの概念に基づいたランダムな値）を加えた「サマリーレポート」（summary report）を生成し、収集サーバーに返します。このサマリーレポートは、個々のユーザーの行動を特定できない形で、特定の集計キーに対する合計値を提供します。

3. API呼び出し

Private Aggregation APIは、Shared Storage WorkletやProtected Audience APIのWorklet内から呼び出すことができます。主なAPIは以下の通りです。

sharedStorage.run('worklet.js', { data: {...} }) または navigator.runAdAuction({...}) などのコンテキスト内で、以下のメソッドを使用します。
privateAggregation.sendHistogramReport(report: ReportRequest): 集計キーと値のペアを含むレポートリクエストを送信します。
- report.buckets: 集計キーを表現します。BigInt形式またはUint32Array形式で指定します。例えば、広告キャンペーンIDやイベントタイプなどをハッシュ化した値が利用されます。
- report.values: 集計する値を表現します。Uint32形式で指定します。例えば、イベント発生回数などをカウントした値が利用されます。

Private Aggregation APIが呼び出されると、ブラウザは指定された集計キーと値を元に暗号化された集計可能なレポートを生成し、キューに入れます。レポートは非同期的に指定された収集サーバーに送信されます。

4. 制限事項

Private Aggregation APIにもいくつかの制限があります。

集計キーと値のサイズには上限があります。
報告される値にはノイズが加えられます。
集計サービスによる集計レポートの生成には、一定のデータ量（k-anonymity閾値など）が必要です。閾値未満のデータは報告されない可能性があります。
レポートの送信は即時ではなく、遅延が発生します。
デバッグが困難な場合があります。

Shared Storage APIとPrivate Aggregation APIの連携

Shared Storage APIとPrivate Aggregation APIは、クロスサイトでの限定的なデータ利用とプライバシー保護された集計レポート作成という、共通の目的のために密接に連携します。典型的な連携パターンは、Shared Storage Worklet内でPrivate Aggregation APIを呼び出すというものです。

1. 連携のアーキテクチャ

データ保存: サイトAでユーザーが特定のアクション（例: 商品の閲覧）を行った際、その情報をShared Storageに保存します（Shared Storage Worklet経由）。例えば、閲覧した商品のカテゴリIDなどを保存できます。このデータはサイトAのオリジンからは直接読み取れませんが、Shared Storage内で維持されます。
データ利用トリガー: サイトBでユーザーが別の特定のアクション（例: 関連広告の表示）を行った際、サイトBのページからShared Storage Workletを起動します。
Workletでの処理: Shared Storage Workletが起動され、サイトBのコンテキストから渡された情報と、Shared Storageに保存されているサイトA由来の情報（例: 閲覧カテゴリID）を組み合わせて処理を行います。
Private Aggregation API呼び出し: Worklet内で、組み合わせた情報（例: サイトAで閲覧したカテゴリとサイトBで表示された広告タイプ）を元に、集計キーと値を生成します。そして、privateAggregation.sendHistogramReport()メソッドを呼び出し、このキーと値を含む集計可能なレポートを生成します。
レポート収集と集計: 生成された集計可能なレポートは、ブラウザによって暗号化され、収集サーバーに送信されます。収集サーバーは、同様のレポートを複数集めて集計サービスに渡し、サマリーレポートを受け取ります。
レポート利用: 収集サーバーは集計サービスから受け取ったサマリーレポートを利用して、サイトを跨いだ集計データ（例: カテゴリXの商品を見たユーザーに広告Yを表示した合計回数）を分析に活用します。

このフローにより、サイトAとサイトBの間でユーザーレベルのデータを共有することなく、サイトを跨いだ行動に基づいた集計指標を取得することが可能になります。

2. 具体的なユースケース例

フリークエンシーキャップ（集計ベース）: Shared Storageに広告表示回数を保存し、Worklet内でPrivate Aggregation APIを使って集計報告することで、サイトを跨いだ集計表示回数に基づいたフリークエンシー分析を行う。
k-anonymity閾値未満のコンバージョン集計: Attribution Reporting APIではk-anonymity閾値未満のコンバージョンデータはレポートに含まれない場合があります。Shared Storageに一時的にその情報を保存し、Private Aggregation APIで集計することで、閾値未満のデータも含めた集計レポートを作成する補完的な手段として検討する。
カスタムオーディエンスの除外リスト集計: Protected Audience APIでオークションに参加させたくないユーザーリストをShared Storageに保存し、Private Aggregation APIで集計することで、除外リストの規模などをプライバシー保護された形で把握する。

技術的な実装課題と考慮事項

Shared Storage APIとPrivate Aggregation APIを連携させる実装は、いくつかの技術的な課題を伴います。

1. Workletの開発とデバッグ

Shared Storage Workletは隔離された実行環境であり、標準的なデバッグツール（ブラウザの開発者ツールなど）が利用しにくい場合があります。Worklet内のコードの挙動確認、Private Aggregation APIへの値の受け渡し、エラーハンドリングなどが複雑になる可能性があります。専用のデバッグツールや手法が必要になります。

2. 集計キーと値の設計

Private Aggregation APIの集計キーと値の設計は、レポートの粒度とプライバシー保護のバランスに大きく影響します。あまりに詳細なキー設計は、集計結果がk-anonymity閾値を満たさずレポートされないリスクを高めます。逆に粗すぎる設計は、得られるインサイトの価値を損ないます。目的に応じた適切な粒度を見極める必要があります。

3. 集計サービスとの連携と運用

集計サービスはPrivacy Sandboxエコシステムの重要なコンポーネントであり、現状はGoogle Cloudなどで提供されるサービスを利用することが一般的です。この集計サービスへのレポート送信、バッチ処理、サマリーレポートの受信と解析には、サーバーサイドの実装が必要です。また、集計サービスの運用コストや可用性、セキュリティについても考慮が必要です。

4. APIの進化とブラウザサポート

Privacy Sandbox API群はまだ開発段階であり、仕様変更や機能追加が今後も予想されます。ブラウザ間のサポート状況も異なる場合があります。最新の仕様を継続的に追随し、実装のアップデートを行う必要があります。

5. パフォーマンスへの影響

Workletの実行やレポートの生成・送信は、ブラウザやデバイスのパフォーマンスに影響を与える可能性があります。特に多くのイベントを報告する場合や、Worklet内で複雑な処理を行う場合は、パフォーマンスボトルネックにならないよう注意深い設計とテストが必要です。

プライバシー保護のメカニズムと法規制への影響

Shared Storage APIとPrivate Aggregation APIの連携は、設計上、いくつかのプライバシー保護メカニズムを内包しています。

1. ストレージのパーティション化とWorklet制限

Shared Storage自体はオリジン間でパーティション化されませんが、Workletによるアクセス制限と、Workletから外部へのデータ送信制限により、個々のユーザーを識別可能な情報を直接読み出したり送信したりすることを防ぎます。

2. 集計サービスの利用とレポートの匿名化

Private Aggregation APIが集計サービスを利用し、ノイズを加えたサマリーレポートのみを出力する仕組みは、差分プライバシーの考え方に基づいています。これにより、特定の個人に関する情報がレポートから推測されるリスクを低減します。レポートは集計サービスによって処理されるため、収集サーバー側で個人の集計可能なレポート内容を知ることはできません。

3. 法規制（GDPR/CCPA等）への適合性

これらの技術は、個人の特定を困難にすることを目的として設計されていますが、完全に匿名化されたデータとして扱えるか、あるいは統計データとして扱えるかは、具体的な実装方法、収集・集計されるデータの種類、および各法規制の定義・解釈によって異なります。

同意管理: これらのAPIを利用したデータ収集および集計が、ユーザーの同意を必要とする処理に該当するかどうかは、法的評価が必要です。多くの場合、ユーザーのデータを利用する目的（例えば、広告効果測定やコンテンツのカスタマイズなど）については、既存の同意管理システム（CMP）を通じて適切な同意を取得する必要が生じると考えられます。特に、Private Aggregation APIによって集計されるデータが、特定の目的（例: パーソナライズ広告の評価）に利用される場合は、同意が必須となる可能性があります。
データ主体の権利: 集計データであっても、その生成過程で個人データが利用されている場合、データ主体のアクセス、訂正、削除などの権利が適用される可能性があります。Private Aggregation APIによって出力されるサマリーレポートは匿名化されていますが、その元となるWorkletでの処理やShared Storageへのデータ保存が、法的にどのように評価されるかは、より詳細な検討が必要です。
目的の特定と透明性: これらのAPIを利用してどのようなデータを収集し、どのような目的で集計・利用するのかを、プライバシーポリシーなどでユーザーに明確に開示する必要があります。

これらの技術の導入にあたっては、単なる技術的な実装だけでなく、法規制の専門家と連携し、自社のデータ処理活動全体における位置づけと法的リスクを十分に評価することが不可欠です。

まとめと今後の展望

Shared Storage APIとPrivate Aggregation APIの連携は、ポストCookie時代において、クロスサイト環境でのプライバシー保護されたデータ活用を実現するための有望なアプローチの一つです。Shared Storageによる限定的な情報保存と、Private Aggregation APIによる安全な集計レポート作成の仕組みを組み合わせることで、個人のプライバシーを尊重しつつ、広告効果測定やコンテンツ最適化に必要な集計データを取得することが可能になります。

しかしながら、これらのAPIはまだ進化の途上にあり、技術的な実装、デバッグ、集計キーと値の設計、集計サービスの運用など、克服すべき課題も少なくありません。また、法規制への適合性についても、継続的な評価と適切な同意管理・情報開示の仕組み構築が求められます。

Privacy Sandbox API群は全体として複雑なエコシステムを形成しており、Shared Storage APIとPrivate Aggregation APIはその一部です。他のAPI（Protected Audience API, Attribution Reporting APIなど）との連携を理解し、それぞれのユースケースに最適な技術選択と組み合わせを検討することが重要です。

今後、これらのAPIが広く普及し、ツールのサポートやベストプラクティスが整備されるにつれて、実装のハードルは下がっていくと予想されます。Web開発者やプライバシーコンサルタントは、最新の技術動向と法規制の変更を常に注視し、ポストCookie時代のデータ活用戦略において、これらの新しい技術をどのように位置づけ、活用していくかを検討していく必要があります。