2026/03/31

CCPAプライバシーサンドボックスCookieGDPRプライバシーサンドボックス

プライバシーサンドボックスとは？主要APIやメリット・デメリット、広告主が取るべき対応策までわかりやすく紹介

: 菊池満長

いま、Web広告のあり方について見直しを図ろうと、大きな議論が巻き起こっています。

Googleの主導により、ユーザーのプライバシーを保護しつつ広告配信の効果を維持することを目指す「プライバシーサンドボックス」（Privacy Sandbox）という新たな枠組みの開発が、2019年頃から2025年10月までの約6年にわたって進められてきました。

欧州のGDPR（一般データ保護規則）やカリフォルニア州のCCPA（カリフォルニア州消費者プライバシー法）、日本の改正個人情報保護法など、ここ数年で世界各国のプライバシー規制が強化されています。Safari（Apple）やFirefox（Mozilla）といったブラウザではサードパーティCookieの遮断が進行。

その一方で、Chromeブラウザを擁するGoogleは、広告ビジネスへの影響を考慮しつつ段階的な対策を模索してきたのです。プライバシーサンドボックスはその中心的な施策であり、従来のトラッキング手法に代わる複数のAPI提案を含んでいます。

ところが、2025年10月17日、Googleによるプライバシーサンドボックスの開発プロジェクトは終了、関連技術のほとんどは廃止されると公式発表がありました。

Googleが進めてきた、Cookie代替技術としてのプライバシーサンドボックスの開発・実装は、Web業界や広告業界との合意形成が困難だと判断されたことを示唆しています。

本記事では、プライバシーサンドボックスの概要と開発背景から、開発が進められていた主要なAPIの仕組み、導入で見込まれていたメリットと課題などを網羅的に解説。

プライバシーサンドボックスの開発・実装は結果的に頓挫してしまいましたが、Web業界、広告業界や政府機関も含めて数年にわたり議論が繰り返されてきた経緯が詳しくわかるようにお伝えします。

「Cookie規制の大枠は把握しているが、プライバシーサンドボックスの技術内容を深く知りたい」という方は、ぜひ参考にしてください。

プライバシーサンドボックスとは

まず、プライバシーサンドボックスの基礎知識と、この技術概念が注目される背景についてご紹介します。

プライバシーサンドボックスの意味・定義

プライバシーサンドボックスとは、Googleが提唱するウェブ標準の新たな枠組みです。

ウェブサイトが必要な情報にユーザー個人を特定することなくアクセスし、広告のパーソナライズや効果測定を可能にすることを目的とした一連の技術提案の総称です。

Google Chromeチームは2019年頃からこの構想を打ち出し、2020年には「2022年までにサードパーティCookieを段階的に廃止する」と表明しました。しかし、その後広告業界や規制当局からのフィードバックを受け、Cookie廃止の延期や提案内容の見直しが繰り返されています（詳細は後述）。

プライバシーサンドボックス自体は複数のAPI提案から構成されており、ユーザーの興味関心にもとづく広告表示、リターゲティング（カスタムオーディエンス）配信、コンバージョン計測、不正防止などの機能をそれぞれ専用の技術で実現しようとしています。

Google公式の説明によれば、プライバシーサンドボックスの目指すところは次の通りです。

ユーザーの行動追跡（クロスサイト追跡）をこれまでより厳しく制限するなおかつ、ウェブ広告による収益モデル（無料コンテンツ提供など）が成り立つようバランスを取る

従来のサードパーティCookieやデバイスIDに依存した手法に代わり、ブラウザやOSレベルでプライバシー保護された広告ソリューションを提供しようというアプローチだといえます。

プライバシーサンドボックスが注目される背景

プライバシーサンドボックスが注目される背景には、大きく分けて以下の2つのポイントが挙げられます。

プライバシー規制の強化ブラウザ各社の方針転換

従来、サードパーティーCookieによるクロスサイト追跡が広告ターゲティングや測定に広く使われてきましたが、ユーザーの行動追跡によりプライバシー侵害の懸念が高まっていました。

そこで、まず法規制面では、2018年の欧州GDPR施行を皮切りに世界的にユーザーデータ保護の流れが加速しました。日本でも2022年4月に改正個人情報保護法が施行され、クッキー情報など「個人関連情報」の第三者提供にユーザー同意が事実上必要となるなど、オンライン広告でのデータ利用に影響を与えています。

またカリフォルニア州のCCPA/CPRA（2020年施行）も含め、各国でユーザーのトラッキングに厳しい目が向けられるようになりました。

次に技術面では、ブラウザ側のトラッキング防止策が進んだことが大きいといえます。AppleのSafariは2017年に「Intelligent Tracking Prevention（ITP）」を導入して以降段階的に規制を強化し、2020年3月にはサードパーティCookieを完全にブロックしました。

MozillaのFirefoxも2019年から「Enhanced Tracking Protection（ETP）」を既定で有効化し、追跡目的のクッキーやスクリプトをデフォルトで遮断しています。さらにFirefoxはTotal Cookie Protectionと呼ばれる仕組みでクッキーをサイトごとに隔離する（他サイトと共有できないようにする）機能も提供しています。

こうした中、シェア約6割を占めるChromeがサードパーティCookieを温存している状況は徐々に難しくなりました。Chromeも当初は「2022年までにCookieを廃止する」と発表しましたが、業界からは「代替技術なしでのCookie廃止は広告収益に大打撃」との懸念が上がりました。

事実、Googleの試算によればサードパーティCookieが使えなくなるとパブリッシャー収益が平均52％減少したとの報告もあります。

こうした背景から、ChromeチームはCookieの廃止と並行してプライバシーサンドボックスの検討を進め、「Cookieの役割を果たすプライバシー保護型の代替」をウェブ標準として提案する道を選びました。

Cookie廃止の流れの中で広告業界は代替策の模索を迫られることとなり、Privacy Sandboxは「プライバシーを守りながら広告機能を提供する新技術群」として提唱された経緯があるのです。

さらに政府機関の動きもプライバシーサンドボックスを語る上で欠かせません。英国の競争・市場庁（CMA）は2021年にGoogleのプライバシーサンドボックス計画に対する調査を開始し、「Google自社の広告事業が有利になるような変更を行わないこと」等を約束させる法的コミットメントをGoogleから取り付けました。

これは、Chromeが一方的にクッキーを廃止すると、他の広告事業者が不利になり競争環境が損なわれる可能性があると懸念されたためです。GoogleはCMAと協議しながらプライバシーサンドボックスを開発することを約束し、提案の透明性確保やテストの実施前通知などを行っています。

以上のように、プライバシー保護の要請と広告ビジネス維持の要請という相反する課題に対し、Chrome/Googleが模索した回答がプライバシーサンドボックスであり、各方面から大きな注目と議論を集めているのです。

Web向けプライバシーサンドボックスの主要APIと仕組み

続いて、プライバシーサンドボックスを構成する主要な技術要素（API）とその仕組みを具体的に見ていきましょう。

ウェブ（ブラウザ）向けには広告の配信や計測に関連する複数のAPIが提案・実装されており、それぞれ従来のクッキー等に代わる役割を担います。

Topics API（トピックスAPI）
Protected Audience API（プロテクテッドオーディエンスAPI, 旧称FLEDGE）
Attribution Reporting API（アトリビューションレポーティングAPI）
Private State Tokens（プライベートステートトークン：不正防止用）
その他の関連技術（Fenced Frames／Shared Storage／CHIPSなど）

Topics API（トピックスAPI）

Topics API（トピックスAPI）は、ユーザーの興味関心にもとづいて広告を出し分けるための仕組みです。これは従来の「行動ターゲティング」に代わるプライバシーサンドボックス提案で、以前試験導入されたFLoC（Federated Learning of Cohorts）の後継にあたります。

名称	Topics API（トピックスAPI）
概要	ユーザーの興味関心にもとづいて広告を出し分けるための仕組み
目的	・従来の「行動ターゲティング」に代わるもの・以前試験導入されたFLoC（Federated Learning of Cohorts）の後継

FLoCではユーザーを数千人規模のコホート（類似興味グループ）に分類していましたが、批判を受けて撤回され、「話題（トピック）」ベースの方式に改められました。

Topics APIの基本となる考え方は、ユーザーの最近の閲覧履歴から「スポーツ」「テクノロジー」など関心トピックをブラウザ側で推定し、広告リクエスト時にその一部を広告サイトと共有することで、興味関心にマッチした広告選択を可能にするというもの。

Topics API最大の特徴は、「興味の推定と共有をブラウザ内で完結させる」点です。第三者がユーザーの詳細な閲覧履歴や識別子を取得することなく、高レベルな興味関心のシグナルだけを共有する仕組みになっています。

トピック情報も極めて粗い粒度で数百程度の大分類に限られ、しかも一部ランダム要素を加えることで特定個人を追跡しにくくする工夫があり、指紋（ブラウザフィンガープリント）代替としての悪用を防ぐ仕組みが組み込まれています。

Topics APIは2022年に提案・試験運用され、2023年夏までに先行テストが実施されました。2025年時点でChromeで基本的な機能が搭載済みであり、広告プラットフォームによる対応も進みつつあります。

ユーザー側で明示的に無効化しない限り、ChromeではサードパーティCookieの有無に関わらずトピックが内部生成され、対応サイトではそれが利用される流れです。なお、機微な個人情報に関わるカテゴリ（人種・宗教・健康状態など）はトピックから除外されており、関心推定の対象外となっています。

Protected Audience API（プロテクテッドオーディエンスAPI, 旧称FLEDGE）

Protected Audience API（プロテクテッドオーディエンスAPI）は、いわゆるリマーケティング（サイト訪問者への追跡広告）やカスタムオーディエンス広告を実現するための仕組みです。

以前の提案名FLEDGE（「First Locally-Executed Decision over Groups Experiment」の略）として知られていた技術で、サードパーティCookieなしでサイト訪問履歴にもとづく広告ターゲティングを可能にすることを目的としています。

名称	Protected Audience API（プロテクテッドオーディエンスAPI）
概要	リマーケティング（サイト訪問者への追跡広告）やカスタムオーディエンス広告を実現するための仕組み
目的	以前の提案名FLEDGE（「First Locally-Executed Decision over Groups Experiment」の略）として知られていた技術で、サードパーティCookieなしでサイト訪問履歴にもとづく広告ターゲティングを可能にする

従来、たとえばユーザーが通販サイトXで商品Yを閲覧すると、その情報をもとに別サイト閲覧時に「商品Yの広告」を出すといったリマーケティングが行われてきました。

これは主にサードパーティCookieを使い、ユーザー識別子と商品閲覧情報を広告ネットワークでひも付けることで実現されています。

しかしこの方法ではユーザーの詳細な閲覧履歴が広告会社に筒抜けになり、プライバシーリスクが高い点が問題でした。

そこで、Protected Audience APIでは、広告オークション（入札）処理自体をユーザーのブラウザ内で完結させることで、第三者に行動履歴を渡さずにリマーケティングを可能にしています。

たとえば「通販サイトXで商品Yを見たAさん」に対し、Aさんが訪れたニュースサイト上で商品Yの広告を表示するといったことが可能になります。

ポイントは、Aさんがどのサイトを回遊したかという生の履歴を広告ネットワークが知ることなく、ブラウザが代理で「Aさんは通販Xの広告オーディエンスに属する」という事実だけを使って入札・配信している点です。

このProtected Audience APIは2023年に入りChromeで基本的な機能がテストされました。

広告プラットフォーム側でも、このAPIに対応するための入札サーバー調整や計測フロー変更が求められるため、徐々に実装が進められています。

Attribution Reporting API（アトリビューションレポーティングAPI）

Attribution Reporting API（アトリビューションレポーティング API）は、広告のコンバージョン計測をプライバシーに配慮した形で行うための仕組みです。

ユーザー行動を個人単位で追跡せず、広告クリックやビュー（閲覧）と、それに続いて発生するコンバージョン（購入やアプリインストールなど）を関連付けられます。

名称	Attribution Reporting API（アトリビューションレポーティング API）
概要	コンバージョン計測をプライバシーに配慮した形で行うための仕組み
目的	ユーザー行動を個人単位で追跡せず、広告クリックやビュー（閲覧）、コンバージョンを関連付ける

従来、広告効果測定には広告主サイトに埋め込んだタグやCookieによるユーザー識別が使われ、「誰がどの広告をクリックしてどの商品を買ったか」を広告プラットフォームが把握できる形が一般的でした。

これに対しAttribution Reporting APIでは、ブラウザが「広告クリック」と「コンバージョン発生」をそれぞれ記録し、後で匿名のレポートとして突合するというアプローチを取ります。下記のように大きく2つのレポート方式があります。

レポート方式
イベントレベルレポート（Trigger-level reports）	・個々のCV発生に対応して送信されるレポート・ただし従来のような詳細データは含まず、キャンペーンIDやコンバージョン値など限られた情報のみを持つ・ユーザー識別に使えないよう、データにノイズ（乱数）を加えたり、ビット数を削減（たとえばコンバージョン値を粗いレンジにマップ）するといった工夫がある・レポート送信もリアルタイムではなく、最大48時間程度の遅延を伴って行われる・受け取った側（広告主側）は個人を特定せずに「どの広告経由でコンバージョンが発生したか」をおおまかに知れる
集計レポート（Aggregate reports）	・複数のCVをまとめて統計的に処理したレポート・「キャンペーンAで週に100件購入、Bで50件購入」といった集計結果を受け取れる・「プライベート集計サービス」と呼ばれる仕組み（ブラウザから安全な第三者サーバーに暗号化データを送り、集計して結果を返す）を用いることで、個々のユーザー行動を秘匿しながら正確な集計を得られる・「イベントレベルレポート」より詳細な分析が可能だが、実装がやや複雑

重要なのは、レポーティングの過程でユーザーの識別子（Cookieや広告ID等）を一切使用しないことです。

ブラウザが中継する情報は「広告IDとコンバージョンをひも付ける匿名データ」であり、個人を逆算することはできません。

また遅延やノイズ付加により、ある一人のユーザーの行動履歴を正確に追うことが困難になっています。

ChromeはこのAttribution Reporting APIを2022年に試験導入し、2023年夏以降一般利用可能にしました。

Google AdsやDisplay & Video 360など自社広告製品でもこのAPI経由のコンバージョン計測をサポートし始めており、徐々に従来のCookieベースの計測から移行が進められています。

他ブラウザに目を向けると、AppleはSafari向けにPrivate Click Measurement（PCM）という類似のコンバージョン計測機能を提供しています。このPCMもクリック起点で8bit程度のキャンペーンIDを報告する仕組みで、24～48時間の遅延を伴う点などAttribution Reportingと共通点があります。

Chromeは「まず自社でAPIを提供しテストしつつ、将来的には業界全体で受け入れられる標準仕様にしたい」といった主旨の表明をしています。

Private State Tokens（プライベートステートトークン：不正防止用）

Private State Tokens（プライベートステートトークン）は、ウェブ上でボットや不正ユーザーを検知・排除するための仕組みです。以前はTrust Tokens（トラストトークン）と呼ばれていた提案で、2021年頃からChromeで試験実装されてきました。

オンライン広告の分野では不正トラフィックのフィルタリング（たとえばインプレッション水増しや不正クリックの排除）が重要です。しかし、従来は指紋（ブラウザフィンガープリント）情報やブラックリストなど、プライバシー上問題のある手法が用いられることもありました。

一方、Private State Tokensは、ユーザー個人を特定せずに「このユーザーは実在の人間か？」という信頼性を確認できるようにする技術です。

名称	Private State Tokens（プライベートステートトークン）
概要	ウェブ上でボットや不正ユーザーを検知・排除するための仕組み
目的	・以前はTrust Tokens（トラストトークン）と呼ばれていた提案・ユーザー個人を特定せずに「このユーザーは実在の人間か？」という信頼性を確認できるようにする技術

仕組みとしては、「発行者（Issuer）」と「引き受け者（Redeemer）」という2種類のサイト（またはサービス）が登場します。

発行者サイト（Issuer）

・あるユーザーに対し「このユーザーは信頼できる」というトークンを発行する役割を持つ・（例）ユーザーがあるSNSサイトで通常通りにアカウント活動を行ったり、ECサイトで購入実績を積んだり、CAPTCHAテストに何度も合格する等、「人間らしい振る舞い」を示した場合に、そのサイトはユーザーを信頼できると判断。・サイトはブラウザに対してプライベートトークンの発行リクエストを送り、ユーザーのブラウザにトークンが保存される

引き受け者サイト（Redeemer）

・前出のユーザーが後日、サイトを訪れた際に「信頼できるトークンを持っているか？」を確認。・（例）オンライン広告の表示時に、不正防止のために引き受け者（広告枠を表示するサイトや広告ネットワーク）がブラウザに問い合わせを行い、何らかの発行者サイト（Issuer）によって発行された有効なトークンがあるかチェック。・もし信頼トークンが見つかれば、そのユーザーは（過去に別のサイトで信頼を得た＝ボットではない）とみなされ、不正検知フィルターを通過できる。

発行されたトークンは暗号化されており、トークン自体からユーザーの個人情報や具体的な行動履歴は分かりません。あくまで「一定の基準で人間らしいと確認された証明書」のような役割を果たします。

また、発行者と引き受け者の間に信頼関係（たとえば同じ業界団体に属する等）があることが前提で、引き受け者は自分が信用する特定のIssuerが発行したトークンのみを受け入れる、といった運用が想定されています。

たとえば、Googleが提供するreCAPTCHAスコアをIssuer（発行者サイト）、広告表示側のサイトがRedeemer（引き受け者サイト）になるケースが考えられるでしょう。

ユーザーがあるサイトで高いreCAPTCHAスコアを得た（=人間らしいと判定された）際にトークンが発行されます。別のサイトで広告を表示する際にそのトークンが検証されれば、ボットではないと判断して広告を表示する、という流れです。

このようにPrivate State Tokensは、ユーザーを追跡することなく信頼性だけを伝達できる点が特徴です。広告分野では特にDSP/SSP間の入札リクエストにおける不正トラフィック排除や、広告インプレッションの不正検知に役立つと期待されています。

その他の関連技術（Fenced Frames／Shared Storage／CHIPSなど）

プライバシーサンドボックスには上記主要API以外にも、広告やコンテンツ表示に関連する補助的な提案が含まれます。その中から代表的なものを簡単にご紹介します。

Fenced Frames（フェンストフレーム）	・従来の<iframe>に代わる新しいフレーム表示の提案・広告などサードパーティのコンテンツを埋め込む際に、親ページと隔離（フェンスで囲む）してユーザー情報のやりとりを遮断する仕組み・Fenced Frames内部では外部と直通の通信ができず、かわりにReserved.bsといった特定のAPI経由で限定的なデータ受け渡しを行う・広告クリエイティブがユーザーやページの情報を盗み見るリスクを減らしつつ、必要最低限の連携のみを許可・Protected Audience APIでブラウザ内オークション後に広告を表示する際にも、このFenced Framesが使われる
Shared Storage（シェアードストレージ）	・ブラウザに各サイトから少量のデータを書き込み、それを別サイト間で共有できるようにする提案・ただしJavaScriptから直接その値を読み取ることはできず、Fenced Frames内でコンテンツ分岐に利用するなど限定用途のみ可能・（例）ブラウザ内オークションで勝利した広告キャンペーンIDを一時的にShared Storageに書き込み、広告表示用のFenced Frameで参照してクリエイティブを選択するといった使い方・従来のlocalStorageやCookieのように自由には読み書きできない代わりに、トラッキング目的の悪用を防ぎつつ必要なデータ共有を実現
CHIPS（Cookies Having Independent Partitioned State）	・Cookieのパーティション化に関するChromeの機能提案・（例）同じ広告配信ドメインのCookieでもニュースサイトとSNSサイトで別々に保存し、サイト間では共有されないようにする・クロスサイト追跡を防ぎながら、ログイン状態維持など技術的に必要なCookie利用を可能に

総じていえるのは「ブラウザを中心にユーザーデータを極力守りつつ、ウェブの利便性・収益性との両立を図る」という思想で統一されている点です。

Android向けプライバシーサンドボックス

次に、モバイルアプリ領域であるAndroid向けのプライバシーサンドボックスについて見ていきます。

実はプライバシーサンドボックスはウェブブラウザだけでなく、Android OS上でも同様のコンセプトで広告技術の刷新が進められています。

モバイルアプリ広告ではWebとは異なる技術（広告IDやSDK）が使われてきましたが、ここにもプライバシー保護の波が押し寄せているのです。

Android版プライバシーサンドボックスの概要

Googleは2022年2月に「Privacy Sandbox on Android」を発表し、「少なくとも2024年までは広告IDなど現行の仕組みに変更を加えない」としつつ、将来的に追跡しない新技術へ移行するロードマップを示しました。

Android版のPrivacy Sandboxも、基本的な柱はWeb同様に「興味関心にもとづく広告」「カスタムオーディエンス広告」「コンバージョン計測」の3領域です。それぞれ対応するAPIとして以下が提供されます。

API名称	概要	Web版との違いや共通点	特徴
Topics API （Android版）	・ユーザーが利用するアプリにもとづいて興味トピックを推定し、関心に沿った広告を出す仕組み	Webがサイトカテゴリを扱うのに対し、Androidではインストール済みアプリやアプリのカテゴリ情報をもとにトピックが付与される	・推定されたトピックはOS内に保存され、広告SDKが参照することで関連広告を表示できる・ユーザーは端末設定で自分のトピックの閲覧・削除や、機能自体のオプトアウトも可能
Protected Audience API （Android版）	・アプリ内でのカスタムオーディエンス広告を実現・（例）ゲームアプリ開発者が「過去30日以内にアプリ内購入したユーザー」のリストを作り、他のアプリ上で再度自社ゲームの広告を出す	基本概念はWeb版FLEDGEと同様、入札や広告選択はデバイス上で完結し、個人データは外部に漏れない	OSレベルで「カスタムオーディエンス」の作成・保存機能が提供され、広告SDKはそれを利用して入札と広告表示を行う
Attribution Reporting API （Android版）	モバイル広告のコンバージョン測定を行う	仕組み自体はWeb版Attribution Reportingに近いが、アプリ間計測やWeb-to-App計測にも対応すべく設計されている	広告のクリックやビューと、アプリインストールや購入といったイベントを突合し、プライバシー保護されたレポートを広告主に送信

これらに加え、Android特有の重要な要素が「SDKランタイム（SDK Runtime）」です。

SDK RuntimeによるサードパーティSDKの隔離

SDK Runtimeは、モバイルアプリに組み込まれる広告SDKなどのサードパーティコードをアプリ本体から分離して実行する仕組みです。

従来、アプリ開発者は広告表示や計測のため外部提供のSDKを組み込んでいました。

しかしこのSDKがユーザーデータに過度にアクセスしたり、想定外の挙動をしたりするリスクが指摘されています。AppleのApp Tracking Transparency（ATT）でも、結果的に「アプリに組み込まれた第三者SDKによる追跡」を問題視していました。

そこで、AndroidのSDK Runtimeは、広告においてはユーザーの行動追跡目的でSDKが個人識別情報を勝手に収集することを防ぎ、広告表示や計測に必要な機能だけを提供します。開発者にとってはSDKの動作がより透明になり、ユーザーにとっては見えない追跡リスクが減るメリットがあります。

AppleのATTとの対比

Androidのプライバシーサンドボックスは、よくAppleのApp Tracking Transparency（ATT）と比較されます。ATTは2021年にiOS 14.5で導入された仕組みで、アプリ横断でユーザーを追跡する場合は都度ユーザーの許可を得ることを義務付けました。

結果として、ほとんどのユーザーがトラッキング拒否を選択したため、広告業界に大きな衝撃を与えました。

これに対しGoogleのアプローチは、「包括的な代替技術を整備した上で段階的に追跡を減らす」という点で異なります。

Appleはユーザーに「追跡してよいか？」という直球の選択肢を提示し、大半が「No」と答えたためにIDFA（広告識別子）は有名無実化しました。

一方、Googleはユーザーに直接「許可/拒否」を迫るのではなく、プライバシーサンドボックスという裏側の仕組みで追跡の必要性自体を低減させようとしています。

つまり、広告IDなどを直ちに無効化する代わりに、まずは代替API（TopicsやAttribution等）で広告運用が回る土台を作り、徐々に既存IDへの依存を無くしていく戦略です。

将来的には、Androidでも広告IDに代わる仕組み（たとえば前述のAttribution APIなど）が主流となり、最終的には広告ID提供のオプトイン/オプトアウトに依存しない世界を目指しています。

業界から見た評価としては、「Appleはプライバシー重視だが広告機能は限定的、Googleは広告機能を一から再構築している」という指摘があります。たとえばAppleのSKAdNetworkは広告の効果測定のみ提供し、興味関心にもとづくターゲティングやリマーケティングの仕組みは提供していません。

一方Googleのプライバシーサンドボックス（Web/Android）は、測定だけでなくターゲティング（Topics）やリマーケティング（Protected Audience）の仕組みも包括的に含まれています。

言い換えれば「Appleは既存の追跡を制限することに注力し、Googleは追跡に頼らない広告エコシステムを再構築しようとしている」ともいえます。

実務面では、Android Privacy Sandboxは2023年からベータ版が段階的に公開され、広告業界のパートナーとテストが進められており、今後の本格展開に向けてAndroid OSへの組み込みが始まる見通しです。

最終的に広告IDは段階的に廃止される可能性が高く、その際はAppleのATT同様に業界に大きな転換期が訪れるでしょう。

ただしGoogleは「事前に十分なテストと移行期間を設ける」と約束しており、唐突にスイッチを切るようなことはしない姿勢です。

プライバシーサンドボックスの導入メリット（期待できる効果）

プライバシーサンドボックスを導入・活用することにはどのようなメリットがあるのでしょうか。ユーザー、広告主、パブリッシャーそれぞれの視点で考えてみます。

ユーザープライバシーの向上
広告パフォーマンス維持
持続可能な広告エコシステム
規制遵守（コンプライアンス）とリスク低減

1. ユーザープライバシーの向上

最大の利点は、ユーザーのプライバシー保護が強化されることです。サードパーティCookieや広告IDによる無制限な追跡が抑制され、「どこで何をしたか」を逐一監視されにくくなります。

Topics APIでは詳細な閲覧履歴ではなく大まかなトピック情報のみが共有され、Protected Audience APIではユーザーの行動履歴を外部に出さずに広告配信が行われます。

これらにより、ユーザーはより安心してウェブやアプリを利用できるようになるでしょう。

また、プライバシーサンドボックスはブラウザ設定やOS設定でユーザー自身がオプトアウトできる仕組みも提供するため、データ使用に対する透明性とコントロールも向上するといえます。

2. 広告パフォーマンス維持

プライバシー保護が強化されると広告効果が下がるのでは、という懸念に対し、プライバシーサンドボックスは「従来のターゲティング・計測をある程度代替できる」ことを示しています。

実際、Googleが2024年Q1に実施したパブリッシャー向けの実験では、サードパーティCookie廃止で収益が約20％減少するケースでも、Privacy Sandbox API（TopicsやProtected Audience）とファーストパーティデータを組み合わせれば収益減少幅を13％以上ポイント改善できたと報告しています。

完全に同等とはいかないまでも、適切に活用すれば広告パフォーマンスの落ち込みをかなり緩和できる可能性が示されたのです。

また、Googleは「Privacy Sandbox APIの性能は業界の採用拡大に伴い向上していく」と述べており、機械学習の活用などでターゲティング精度や計測精度を今後高めていける余地があります。

結果的に、広告主・パブリッシャーはプライバシー規制へ適合しつつビジネス上の成果を大きく損なわない形で移行できるメリットがあります。

3. 持続可能な広告エコシステム

プライバシーサンドボックスは広告収益で支えられるフリーコンテンツの継続にも寄与します。

もし、ブラウザが一律で追跡を遮断するだけだと、ウェブ上の多くの無料サービスが収益源を断たれてしまうでしょう。

一方、Googleは「広告で収益を得る出版社と広告主をつなぎ、豊かなエコシステムを維持すること」をプライバシーサンドボックスの目的に挙げています。

プライバシーサンドボックスの意義は、極端なトラッキング禁止によって広告収入が激減する事態を避け、サイト運営者・広告主に妥協点となるソリューションを提供するという点が大きなポイントです。つまり、プライバシー保護と広告収益の両立により、無料コンテンツ提供のモデルを維持できることを示唆しているのです。

この取り組みが成功すれば、ユーザーはプライバシーを守られつつも引き続き多様な無料コンテンツにアクセスでき、広告主・媒体社も適切にユーザーと出会う機会を得られるというWin-Winの関係が築けます。長期的に広告へのユーザー信頼が回復すれば、結果として広告効果も向上し、健全な市場が持続するでしょう。

4. 規制遵守（コンプライアンス）とリスク低減

厳しさを増すプライバシー法規制に対応できる点も重要です。GDPRの下ではパーソナライズ広告に明示的な同意が求められ、違反すれば巨額の罰金リスクがあります。

そのような中、プライバシーサンドボックスを活用しCookieレスで広告運用すれば、広告主自身が厳格な個人データ管理をする負担を軽減し、なおかつ規制当局から追及される可能性を減らせます。

また、ブラウザ/OSが提供する機能を使うため、プラットフォーム側で「機微情報のフィルタリング」など、法要件に合わせたアップデートが行われる恩恵も受けられるわけです。

つまり、広告主にとってはコンプライアンス遵守による企業イメージ向上や、将来の規制変更にも追従しやすい柔軟な体制を築けるメリットがあるといえるでしょう。

ここまで、複数のポイントを述べてきたとおり、プライバシーサンドボックスは単に「規制対応のコスト」と捉えるべきものではなく、ユーザーと広告業界双方にメリットをもたらす可能性を含んでいます。

適切に導入すれば「プライバシー重視＝広告効果悪化」のジレンマを和らげ、ユーザーの信頼を得ながら広告ビジネスを発展させる道が開けると期待されます。

プライバシーサンドボックスの課題・懸念

一方で、プライバシーサンドボックスにはいくつかの課題や懸念も指摘されています。メリットと裏腹の側面も含め、主要なポイントを整理します。

広告効果・収益への影響
技術の成熟度と実装負担
Google主導による競争懸念
プライバシー改善の限界
ユーザー選択と普及の不確実性

1. 広告効果・収益への影響

先述の通り、プライバシーサンドボックスを使っても従来比で完全に同等の広告パフォーマンスを発揮できるかは未知数です。

Googleの実験では収益減少を一定程度取り戻せるとされましたが、それでも完全には埋まっておらず、精緻なターゲティングに依存していた広告主ほど特に影響を受ける可能性を否定できません。

Googleが実施したPrivacy Sandbox利用に関する初期のテストでは、広告主とGoogle自身の収益予測の双方についてパフォーマンスのギャップが明らかになりました。

何年にもわたる開発とテストにもかかわらず、プライバシーサンドボックス APIはCookieが提供する機能を完全に再現できていないと判断されているのが現状です。「大手アドテクベンダーらはPrivacy Sandboxの技術そのものにいまだ納得していない」と見解を述べる海外の記事も見られます。

特にパブリッシャー側からは「Cookie廃止で広告単価が下がるのでは」という不安が根強く、特に中小メディアほどリスク許容度が低いため慎重な姿勢が見られます。

広告効果の検証結果が蓄積し、各社が十分にチューニングできるまでは、一定のパフォーマンス低下を覚悟する必要があるかもしれません。

2. 技術の成熟度と実装負担

プライバシーサンドボックスの各提案はまだ発展途上であり、技術的な複雑さも課題です。

API仕様が頻繁に更新されたり、ブラウザ実装によって挙動が変わる可能性もあります。広告プラットフォームやアドテクベンダーにとって、これら新技術への対応実装は大きな負担となるでしょう。

たとえば、広告の入札システムの刷新、計測インフラの変更、データ分析手法の見直しなど、多方面に影響が及びます。

こうした実装コストに耐えられない小規模事業者は脱落し、市場集中が進む恐れも指摘されています。

3. Google主導による競争懸念

プライバシーサンドボックスの提唱者がGoogle自身であることから、競争環境への影響も懸念されます。

ブラウザ（Chrome）から広告配信・測定までGoogleが新ルールを決める形になるため、「Googleの独壇場になるのではないか」という業界の不信感も存在します。

実際、英国の競争当局・CMAが介入したのもその点が理由でした。

Googleは「自社サービスを優遇しない」とコミットしましたが、たとえば新APIへの対応速度でGoogleの広告プロダクト（Google AdsやDV360など）が他社より有利になる可能性は否定できません。

また、プライバシーサンドボックス非対応のブラウザ（SafariやFirefox）では依然としてCookieブロック中心の独自路線であり、広告運用にブラウザ間の非互換・非対称が生じています。

マーケターはChrome向けとSafari向けで別々の戦略を考える必要があり、市場シェアの大きいChromeに重心が寄れば相対的にGoogleの影響力が増すでしょう。

このような構図が「結局Googleが得をするだけでは」との見方につながっています。

4. プライバシー改善の限界

プライバシー擁護派の中には、プライバシーサンドボックスでは不十分との批判もあります。

たとえば、Topics API（トピックスAPI）を用いた行動ターゲティング自体が「ユーザー監視」であることに変わりないという意見です。Topics APIは個人を特定しないとはいえ、興味カテゴリを広告主側のサイトと共有するため、ユーザーが望まない推測をされるリスクを否定できません。

MozillaはTopics APIについて「プライバシーの観点から、ブラウザ上でTopics API を機能させる方法を見つけられていない」と懸念を表明し、Appleも「Webプラットフォームに追加する技術として適切ではない」という主旨で反対する立場を取っています。

また、Protected Audience APIでも、カスタムオーディエンスにユーザーが気づかないまま広告が出される点は従来と同じです。

さらに、プライバシーサンドボックスは指紋（ブラウザフィンガープリント）対策も掲げていますが、完全に不正追跡を防げる保証はありません。

結局はブラウザ提供のAPIを利用した新たなトラッキング手法が生まれる可能性もあり、「プライバシーサンドボックスは追跡手段を裏に回しただけ」との批判も一部団体からは出ています。

5. ユーザー選択と普及の不確実性

2024年7月、Googleは前述の通り「サードパーティCookieを廃止せずユーザーの選択に委ねる」方針へ転換しました。これはユーザーがChrome設定でトラッキングを許可するか拒否するかを選べるということですが、この「ユーザー選択制」はプライバシーサンドボックスの普及に影を落とす可能性があります。

なぜなら、多くのユーザーがデフォルト設定を変更しない場合、サードパーティCookieはそのまま生き続けてしまうからです。

その場合、広告業界はプライバシーサンドボックスへの移行インセンティブを失い、結局旧来のCookieに頼り続ける懸念があります。

逆にユーザーが一斉にトラッキング拒否を選べばSafari同様の状況となり、プライバシーサンドボックスだけでは補いきれない性能低下が起きるかもしれません。ユーザーの行動次第で将来像が大きく変わる中、マーケターとしては不確実性に備え複数シナリオを想定する必要があります。

前述した通り、FirefoxやSafariは現時点でPrivacy SandboxのAPIに反対の立場を公式表明しており、ウェブ標準として各ブラウザが足並みをそろえられるかは不透明です。今後、Privacy SandboxがChromeだけの仕組みとなった場合、サイトや広告会社はブラウザごとに異なる対応を迫られる可能性があります。

以上のように、プライバシーサンドボックスには理想と現実のギャップが存在し、その行方には依然注意が必要です。もっともGoogle自身、「Web全体で受け入れられる標準となるには時間と合意形成が必要」と認めており、Chrome単独ではなくオープンな議論を通じた進化を目指すとしています。

最終的な成否は業界の協調とユーザーの信頼獲得にかかっているといえるでしょう。

プライバシーサンドボックス時代に広告主が取るべき実務対応

それでは、広告主やマーケティング担当者はプライバシーサンドボックス時代に向けてどのような準備・対応をすべきでしょうか。ここではチェックリスト形式で具体的な実務ポイントをまとめます。

①	最新情報のキャッチアップ	プライバシーサンドボックスやクッキー規制に関する動向を継続的に追いかける。Googleの公式ブログやChromeのデベロッパー情報、業界団体（IAB Tech Lab等）の発表、英国CMAや各国規制当局の発表など、信頼できるソースから最新ニュースを入手する
②	テスト計画の策定と実施	各APIについて、可能な範囲で早期にテストを実施。（例）広告配信でGoogle AdsやDSPが提供するオリジントライアル機能やベータプログラムに参加し、TopicsやAttribution Reportingのデータを取得・分析。Cookieあり/なし時の効果比較や、新APIで得られるレポート精度を検証。コンバージョン計測タグをAttribution Reporting API対応版にアップデートし、ブラウザ送信のレポートを受信できるか試す。テスト結果は社内で共有し、早期にナレッジを蓄積する。
③	パートナー企業との連携	広告代理店や技術面でのパートナーと連携し、プライバシーサンドボックス対応のロードマップを確認。利用している広告プラットフォーム（DSP/SSP、計測ツール、DMPなど）が各APIにいつ対応するのか、その場合の実装方法や必要な設定変更は何か、事前に情報交換。Googleや主要プラットフォームが開催する説明会やベータテストに参加する機会を活用し、業界全体の動きを把握して自社方針に反映。また媒体社側とも協議し、ファーストパーティデータの活用やオーディエンス提供の方法について共通理解を持つことも有効。
④	ファーストパーティデータの活用	Cookieレス時代には自社が保有するファーストパーティデータの価値がますます高まるため、データを整理・統合し、プライバシーサンドボックスで活用できる形にしておく。「脱3rdパーティ」のデータ戦略を立案する。（例）Publisher Advertiser Identity Reconciliation（PAIR）のような仕組みの活用（広告主とパブリッシャーがそれぞれ保有するユーザーの識別情報を安全な形で照合し、両者のサイトを訪れたユーザーに対してのみパーソナライズ広告を出すソリューション）
⑤	コンテクスチュアルターゲティングの再評価	文脈（コンテクスト）にもとづくターゲティング手法にも改めて注目を。3rdparty Cookieに依存しないコンテクスチュアル広告は、プライバシーサンドボックス時代の有効な戦略。（例）広告枠のあるページの内容を解析し、そのテーマに沿った広告を配信するコンテクスチュアル配信の商品（文脈ターゲティングネットワークなど）をテスト導入したり、自社コンテンツをカテゴリー分類して広告枠ごとにキーワードやトピックを設定するなど
⑥	法令順守とユーザー同意管理	プライバシー関連法規への対応、ユーザー同意の適切な運用を引き続き徹底する。プライバシーサンドボックスを利用する場合でも、たとえば欧州ではCookieバナーでの説明やオプトアウト手段の提供が必要。日本でも個人関連情報としての第三者提供時には通知・同意取得が求められるケースがある。自社サイトのプライバシーポリシー更新や、Consent Management Platform（CMP）の導入・アップデートを忘れずに。またChromeの「プライバシーサンドボックス設定」画面（トピックのオン/オフ等）についても、ユーザーへの案内や説明を用意し、ユーザーが自身のデータ利用状況を把握しコントロールできるよう支援する。法律面は専門部署や顧問弁護士とも相談し、技術と運用の両面でコンプライアンスを確保することがポイント。

以上のステップを順次実行することで、広告主はプライバシーサンドボックスへのスムーズな移行と、その先での競争力確保に備えることができるでしょう。

重要なポイントは、受け身で待つのではなく自ら実験・学習し、社内外のリソースを総動員して対応策を講じることです。

変化の激しい時期ですが、早めに着手した企業ほど有利なポジションを築けるでしょう。

まとめ

広告主や、運用担当者は、現在のような変化の激しい局面においてこそ積極的な学習と適応が求められているといえます。

プライバシーサンドボックスは、開発・議論の紆余曲折の末に結局のところ廃止されることになってしまいました。

しかし、「ユーザーの信頼を取り戻すことが、長期的には広告効果を高め、業界の発展につながる」という開発の背景にあったGoogleのビジョンは、今後もユーザー体験をより良くするために引き継がれていくと考えられます。

改めて強調したいのは、ユーザー理解とエンゲージメントの本質は変わらないという点です。

どのようなテクノロジーを使おうとも、ユーザーにとって有益な情報や価値ある体験を提供することがマーケティングの基本です。

プライバシーサンドボックスの廃止が決まったこのあとの時代においても、その原点を忘れず、より健全で透明性の高い広告コミュニケーションを実現していくことが重要だといえるでしょう。

最後までお読みいただき、ありがとうございました。本記事がアドテク領域における最新動向のキャッチアップの一助となれば幸いです。

プライバシーサンドボックスとは？主要APIやメリット・デメリット、広告主が取るべき対応策までわかりやすく紹介