Chrome Privacy SandboxとTopics API：同意、ターゲティング、計測に関する2026年パブリッシャーガイド
過去10年の大半において、デジタル広告は単純な前提のもとで運営されていました。サードパーティCookieは常に存在し、ウェブ全体でユーザー識別子を静かに運び続けるというものです。その前提は今や崩れています。Chromeの廃止パスは何度も変わりましたが、進行方向は変わっていません。サードパーティCookieによるクロスサイトトラッキングは終わりを迎えており、GoogleのPrivacy Sandboxがパブリッシャーと広告主に採用してほしい代替手段です。Sandboxは単一製品ではありません。Topics、Protected Audience、Attribution Reporting、Fenced Frames、Shared StorageなどのブラウザAPIのセットであり、それぞれがCookieがかつてカバーしていた特定のユースケースを置き換えます。パブリッシャーにとって難しいのは、APIを個別に理解することではありません。Privacy Sandboxのフロー、GDPRコンプライアンス、州プライバシー法をすべて同時に整合させた同意レイヤーとマネタイズパスを構築することです。このガイドでは2026年の可動部分と、同意スタックがどのように見える必要があるかを解説します。
Privacy Sandboxが実際に何を置き換えるか
サードパーティCookieには4つの広告機能がありました。興味関心ベースのターゲティング、リターゲティング、コンバージョン計測、フリークエンシーキャップです。Privacy Sandboxはこれらをそれぞれ独自の同意プロファイルを持つ個別のAPIに分割します。
Topics API — 興味関心ベースのターゲティング
Topics APIは各ブラウザに粗粒度の興味関心トピックの小さなセットを割り当てます。数百のカテゴリのキュレートされたタクソノミーから週5トピック程度です。パブリッシャーがdocument.browsingTopics()を呼び出すと、ブラウザはクロスサイト識別子なしでアドテックエコシステムがコンテキスト向けパーソナライズに使用できる最大3つのトピックを返します。トピックはローカルで計算され、デバイスに保存され、毎週ローテーションされ、chrome://settings/adPrivacyのユーザーコントロールに従います。
Protected Audience API — リターゲティングとリマーケティング
旧称FLEDGEのProtected Audienceは、共有されたクロスサイト識別子なしでリターゲティングを維持します。広告主は自社サイトでユーザーをインタレストグループに追加し、ユーザーが参加パブリッシャーにアクセスするとFenced Frame内でオンデバイスオークションが実行されてクリエイティブが選択されます。落札広告はパブリッシャーにどのインタレストグループが一致したかを知らせることなくレンダリングされます。
Attribution Reporting API — コンバージョン計測
Attribution Reportingは計測ユースケースのサブセットでコンバージョンピクセルを置き換えます。イベントレベルレポート（ノイズあり、損失あり、コンバージョンごと）と集計サマリーレポート（統計的に偏り補正されたロールアップ）をサポートします。レガシーピクセルとは異なり、個別のユーザーとコンバージョンのリンクを公開しません。
Shared StorageとFenced Frames
Shared Storageは、フリークエンシーキャップやA/B実験の一貫性などのクロスサイトユースケース向けに、どこでも書き込み可能でSandbox内で読み取るキーバリューストアです。Fenced Framesは、周囲のページがレンダリングされた広告やインタラクションデータを読み取るのを防ぐ隔離されたiframeです。
Privacy Sandboxには同意が必要か？
これは2026年のアドテックで最も誤解されている問題であり、答えは管轄区域によって異なります。
GDPRとePrivacyのもとで
欧州データ保護委員会は包括的な立場を表明していませんが、各国当局はより明確です。英国ICO、イタリアのGarante、フランスのCNILはすべて、TopicsとProtected Audienceは個人データを処理する場合、ユーザーのデバイスへの書き込みや読み取りを含むあらゆる処理において事前のオプトイン同意が必要という見解をとっています。その論理は次のとおりです。ブラウザは依然としてインタレストトピックとインタレストグループをローカルに保存しており、document.browsingTopics()の呼び出しは推定された個人データをサードパーティに送信します。これはePrivacy指令第5条第3項によって規制されており、要請されたサービスに厳密に必要な範囲を超えたユーザーの端末機器へのアクセスまたは保存には同意が必要です。
Googleの立場はより許容的です。APIはプライバシー保護設計であり、すべてのコンテキストで同意要件が適用されない場合もあると主張しています。これは規制当局の立場ではありません。ヨーロッパでPrivacy Sandboxを同意免除として扱うことは高リスクな姿勢です。
CCPA、CPRA、米国州法のもとで
米国では、Privacy SandboxフローはCPRAのもとでコンテキスト横断的な行動広告のための個人情報の共有として一般的に扱われます。つまり、オプトアウト権を引き起こし、Global Privacy Control信号やその他のユニバーサルオプトアウトメカニズムを通じて遵守する必要があります。Topicsデータがサードパーティブローカーから売却されるのではなくブラウザから派生しているという事実は、これを免除しません。
Chrome独自のコントロール
Chromeはchrome://settings/adPrivacyでTopics、Protected Audience、Attribution Reportingのユーザー向けトグルを提供しています。これらのユーザーの選択はCMPの同意状態の代わりではなく、その隣に位置します。バナーで広告Cookieにノーと言ったがChromeのグローバル設定でTopicsにイエスと言ったユーザーは、依然としてバナーを通じてノーを伝えています。スタックは2つの信号のうちより厳格な方を尊重する必要があります。
実際に必要な同意レイヤー
本番グレードの2026年同意スタックは、Privacy Sandbox APIをそれぞれIAB TCFの目的または同等の州法カテゴリを通じてゲートされた個別の処理アクティビティとして扱います。
Sandbox APIのTCF目的へのマッピング
- Topics API — IAB TCF目的2（基本広告の選択）と目的3（パーソナライズ広告プロファイルの作成）が最低限。トピックがターゲティングを提供する場合は目的4（パーソナライズ広告の選択）も。
- Protected Audience — 目的3と4、さらにオークションが結果データを使用する場合は目的7（広告パフォーマンスの計測）も。
- Attribution Reporting — 目的7（広告パフォーマンスの計測）と目的9（統計による視聴者の理解）。
- フリークエンシーキャップ用のShared Storage — パーソナライズを提供する場合は目的3、純粋にフリークエンシー制御の場合は正当な利益の根拠。
Google Consent Mode v2へのマッピング
Google Consent Mode v2信号はPrivacy Sandboxの動作にマッピングされます：
- ad_storage拒否 — TopicsとProtected Audience APIの呼び出しを完全に無効化
- ad_user_data拒否 — Attribution Reportingによるユーザースコープデータの送信をブロック
- ad_personalization拒否 — ターゲティングロジックへのTopics入力をスキップ
米国州のシグナル処理
米国トラフィックの場合、同意レイヤーはGlobal Privacy Controlと適用される州のオプトアウト信号を検査する必要があります。米国ユーザーが共有をオプトアウトした場合、document.browsingTopics()を抑制し、joinAdInterestGroupを呼び出さず、Attribution Reporting登録ヘッダーを削除します。
実践的な実装パターン
Privacy Sandboxを展開済みのパブリッシャーは一般的に2つのアーキテクチャパターンのいずれかに従います。
パターン1：サーバーサイドオーケストレーション
オリジン上のファーストパーティタグマネージャーが同意状態、ユーザーの管轄区域、シグナルオーバーライドを収集し、条件付きでPrivacy SandboxフックをページにレンダリングしますAd serverとSSPはビッドリクエストを通じて同意フラグを受け取り、Topics、Protected Audienceを呼び出すかどちらも呼び出さないかを決定します。このパターンはロジックを一元化し、同意状態を権威あるものに保ちます。
パターン2：ヘッダービディングラッパー統合
Prebid.jsや他のヘッダービディングラッパーはPrivacy Sandboxモジュールをサポートするようになりました。ラッパーは同意信号を読み取り、Topicsの呼び出し動作を設定し、許可された場合はProtected Audienceを通じてオークション結果を転送します。このアプローチはデプロイが軽量ですが、クライアントにより多くのロジックを押し込み、ラッパーのリリースサイクルへの依存を強めます。
監査すべき項目
- CMPの広告同意が肯定的でオプトアウト信号が存在しない限り
document.browsingTopics()が呼び出されないことを確認する joinAdInterestGroupとrunAdAuctionが同じ条件でゲートされていることを確認する- Attribution Reporting登録ヘッダーが計測を許可する同意状態のユーザーへの応答にのみ送信されることを確認する
- TCF文字列のベンダーリストがインベントリでSandbox APIを使用しているSSPとDSPと一致していることを確認する
- プライバシーポリシーがTopics、Protected Audience、Attribution Reportingを法的根拠と保持期間を含む個別の処理アクティビティとして記載していることを確認する
Privacy Sandboxがしないこと
いくつかの一般的な誤解は、予算を立てる前に払拭する必要があります。
同意の回避策ではない
APIは広告主に公開される個人データを減らしますが、欧州法のもとで基礎となる処理を同意免除にはしません。SandboxのadoptionによってCMPをスキップできるというコンプライアンス理論は、すべてのEU/EEA管轄区域で誤りです。
現在Cookieの完全な代替ではない
Topicsは通常Cookieベースのオーディエンスよりも弱い粗くて損失のあるターゲティング信号を提供します。Protected Audienceのリターゲティングスケールはまだ成熟中です。Attribution Reportingには小規模なコンバージョン増加を隠す可能性がある計測ノイズフロアがあります。今日すべてのマネタイズをSandboxに移行するパブリッシャーは、典型的なインベントリでCookieベースのスタックと比較してRPMが10〜30パーセント低下することを想定すべきです。
現在の形では恒久的ではない
Privacy Sandbox仕様はまだ進化中です。Topicsのタクソノミーは拡大中で、Protected Audienceのインタレストグループ制限は改定中であり、規制対応は進行中です。現在の仕様にハードコードするのではなく、設定ドリブンになるよう同意レイヤーを設計してください。
2026年の正しい姿勢
Privacy Sandboxは、ファーストパーティデータ、セラー定義オーディエンス、コンテキストターゲティング、サーバーサイドヘッダービディングと並ぶ、より広いCookieless戦略の一層として最もよく理解されます。2026年に勝つパブリッシャーは、同意を障壁ではなく裁定者として扱うパブリッシャーです。法律とユーザーの選択が許可する場合にのみSandbox APIを提供し、それ以外の場所ではクリーンにコンテキストにフォールバックし、アイデンティティを想定しないツールで両方のパスにわたって結果を計測します。
最悪の姿勢は様子見です。規制当局はすでに次の規制の波を書いています。英国Competition and Markets AuthorityのSandboxコミットメント、継続中のCNILガイダンス、EU AI Actのプロファイリング条項はすべてこの領域に触れています。2026年に適切にゲートされた同意スタックにPrivacy Sandboxを組み込むパブリッシャーは、これらの規制に備えることができます。土壇場のCookie代替として取り付けるパブリッシャーは、プレッシャーのもとで書き直すことになるでしょう。