2026年10月22日に、Privacy Sandboxの公式ブログ、Chrome 153のリリースノート、Privacy Sandboxの機能ステータス表、そしてChrome Platform Statusの公式データを読み直しました。確認の目的は「もう撤去されたのか」でしたが、分かったのはそこではありませんでした。撤去の理由として公式が書いているのは、技術的な失敗ではないということです。
仕様として成立し、ブラウザに実装され、出荷までされた仕組みが、使われなかったという理由で畳まれる。この記事が置きたい問いは、では何を前提にして計測を設計すればよかったのかです。
30秒で要点
- 公式が挙げた撤去理由は「期待される価値についてのエコシステムからのフィードバックの評価」と「採用率の低さ」である。技術的に機能しなかったという記述はない
- 撤去対象として列挙されたのは10項目。CHIPSとFedCMは継続が明言されており、「Privacy Sandboxが終わった」という要約はこの区別を潰す
- Chrome 153のリリースノートは、該当5項目をいずれも「撤去が予定されている」と書いている。「Chrome 153で撤去された」と明記されているのは、同じ節の別項目だけである
- 撤去の完了日は、どの一次情報にも書かれていない。公式ステータスは2026年10月22日時点で「提案中」のままである
- 前提にできるのは仕様の正しさではなく、採用の実績と、止まったときの代替経路の有無である
撤去の理由として公式が書いたこと
Googleは2025年10月17日の公式ブログで、Privacy Sandboxの一群の技術を retire すると発表しました。理由として書かれているのは2つです。期待される価値についてエコシステムから寄せられた意見を評価した結果であること、そして採用率が低い水準にあったことです。ここに「動かなかった」「安全でなかった」「性能が足りなかった」という記述はありません。仕様は成立していました。実装も出荷もされていました。それでも畳まれました。
なお、この発表は1年前のものです。現在の状況を語るときの起点としては使えますが、「先日の発表」として扱うと時系列が狂います。
何が畳まれ、何が残ったのか
撤去対象として列挙されたのは次の10項目です。Attribution Reporting API（計測用の集計の仕組み。ChromeおよびAndroid）、IP Protection、On-Device Personalization、Private Aggregation（Shared Storageを含む）、Protected Audience（ChromeおよびAndroid）、Protected App Signals、Related Website Sets（requestStorageAccessFor と Related Website Partition を含む）、SelectURL、SDK Runtime、Topics（ChromeおよびAndroid）。
一方で、残るものも明言されています。CHIPSとFedCMについて、公式ブログは広く採用され他ブラウザからの支持も得ているとして、継続して支援すると述べています。今後の機能強化の機会も検討するとしています。Private State Tokensも維持されます。計測については、相互運用可能なAttribution標準をW3CのPrivate Advertising Technology Working Groupを通じて追求するとしています。
ただし「他ブラウザでも使える」とは書けません。機能ステータス表はFedCMについて、他ブラウザではまだ対応していないと明記しています。Mozillaがプロトタイプを実装中、Appleは一般的な支持を表明した、という段階です。
この差は、冒頭の理由と並べると意味を持ちます。残った2つは「広く採用された」ことが継続の根拠として挙げられ、畳まれた側は「採用率が低い」ことが撤去の根拠として挙げられています。 判定に使われたのは、仕様の質ではなく使われ方でした。
「Chrome 153で撤去された」と書けない理由
ここが、この題材で最も間違えやすい場所です。
Chrome 153のリリースノート（安定版は2026年9月8日）には「Deprecations and removals」という節があり、Protected Audience、Related Website Sets、Shared Storage API、document.requestStorageAccessFor、Attribution Reporting API の5項目が並んでいます。節の見出しだけを見れば、撤去済みの一覧に見えます。
しかし各項目の本文は、5つすべてが「撤去が予定されている（is planned for deprecation and removal）」という表現です。完了を示す書き方はしていません。
そして同じ節の中に、_current を対象とした非標準の挙動を扱う項目があり、そちらだけが「この機能はChrome 153で撤去された」と明記されています。つまりこのページは、「予定」と「153で撤去済み」を自分で書き分けています。
公式のステータスも同じ方向を示します。Chrome Platform Statusの公式データでは、Protected Audienceの撤去とAttribution Reporting APIの撤去はいずれも実装ステータスが Proposed（提案中）で、マイルストーン値は153です。同じ応答に含まれる出荷済みの機能は Enabled by default（既定で有効）と表示されており、両者は区別されています。2026年10月22日時点では、撤去側は提案中のままでした。
Privacy Sandboxの機能ステータス表（ページ記載の更新日は2026年8月14日）も、該当機能に Intent to Deprecate and Remove（撤去する意向）というラベルを付けています。完了を示すラベルではありません。
なぜ「もう撤去された」と読んでしまうのか
誤読には理由があります。一覧の見出しは、中身の状態を要約したラベルとして読まれるからです。「Deprecations and removals」という見出しの下に項目が並んでいれば、そこにあるものは済んだことだと感じます。各項目の本文まで読んで時制を確認する作業は、見出しが与える確信の前では省略されやすい。
もうひとつ。1年前に撤去が宣言され、目標マイルストーンも過ぎている、という時間の経過が確信を強めます。「あれだけ時間が経ったのだから、もう終わっているはずだ」という推測は、確認の代わりに使われます。
ただし、この誤読は題材を弱めません。宣言から1年が経ち、目標マイルストーンも通過したのに、公式ステータスがまだ提案中であるという状態そのものが、この記事の論点を補強しています。撤去の進行は、外からは正確に追えません。
前提にできるのは、仕様の正しさではない
ここから判断軸を出します。
計測の将来像を描くとき、「標準になりそうだから前提にしてよい」という判断は機能しませんでした。Privacy Sandboxの撤去対象は、仕様として成立し、実装され、出荷されていました。それでも畳まれました。判定基準は採用でした。
だとすれば、前提にできるのは次の2つです。
第一に、採用の実績。 構想や仕様の段階ではなく、実際に使われている量です。CHIPSとFedCMが継続された根拠はここにありました。
第二に、止まったときの代替経路の有無。 提供元が撤去を決めたとき、何に切り替えるのかが先に書けているか。書けていない依存は、相手の判断ひとつで設計全体が宙に浮きます。
この2つは、どちらもベンダーの発表を読む作業ではありません。自社の構成を点検する作業です。
自社の計測設計を点検する
測る単位を決めます。
- 分母: 現在の計測で使っているデータ取得経路の数（単位：経路）
- 分子: そのうち、単一の提供元に依存していて、かつ提供が止まったときの切り替え先が文書に書かれていない経路の数
この分数は、ベンダーの方針が変わるたびに計算し直す必要がありません。構成が変わったときだけ変わります。
最小検証: 計測で使っている取得経路を3つ書き出し、それぞれについて「提供元が来月やめると発表したら、何に切り替えるか」を一行で書いてください。書けない経路が出たら、それが点検の出発点です。書ける経路については、切り替え先が同じ提供元に属していないかを確認します。
この作業の過程で「版の予定」と「版の実績」を混ぜない習慣が必要になります。Chromeのリリース周期そのものを扱ったChromeの2週間リリースが変えた検証の前提では、予定された周期と実際に降りてきた更新を分けて見る話を扱っています。今回のリリースノートの読み方は、その延長にあります。
確かなことと、まだ確かでないこと
確かなこと（いずれも一次情報で確認、2026年10月22日時点）
- 撤去の理由として公式が挙げたのは、エコシステムからのフィードバックの評価と採用率の低さである
- 撤去対象として列挙されたのは10項目。CHIPS・FedCM・Private State Tokens は継続される
- Chrome 153のリリースノートは、該当5項目を「撤去が予定されている」と書いている
- 公式ステータス上、Protected AudienceとAttribution Reporting APIの撤去は提案中である
まだ確かでないこと
- 撤去がいつ完了するか。公式ブログは「ChromeとAndroidのプロセスに従う」と述べるにとどまり、完了日はどの一次情報にも書かれていません
- 採用率がどの程度だったか。公式は「低い水準」と定性的に書くだけで、数値は示していません。推定値を当てはめて語ることはできません
- W3Cでの標準化がどこまで進んだか。公式ブログが「Working Groupを通じて取り組む」と述べていることまでが確認できる範囲です
この分け方が、そのまま計画の作り方を決めます。完了日が不明なものに対して日付入りの移行計画は書けません。書けるのは、「止まったら何に切り替えるか」という条件の側です。
出荷されたことは、残ることの保証ではなかった
この記事は、計測の個別の設定方法を扱っていません。扱ったのは、何を前提として置けるかという一段手前の話です。
仕様が通り、実装され、出荷された。その3つが揃っても、残るとは限りませんでした。残った側の根拠が「広く採用された」であり、畳まれた側の根拠が「採用率が低い」であったことは、設計者にとって扱いにくい事実です。品質で決まらないものは、品質を上げる努力では守れません。
自社の計測が、どの判断に乗っているのか。それを確認しておくと、次に同じ発表が来たときの作業量が変わります。
次の一手：版の予定と実績を分けて読む