フィードバック レポート - 2025 年第 2 四半期

プライバシー サンドボックスの提案と Chrome の対応について寄せられたエコシステムのフィードバックをまとめた 2025 年第 2 四半期の四半期レポート。

Google は、第 12 項、第 17 項（c）（ii）、第 32 項（a）に基づく競争・市場庁（CMA）へのコミットメントの一環として、この四半期レポートを作成しました。このレポートでは、プライバシー サンドボックスの提案に関する Google の進捗状況、更新されたタイミングの想定、Google が第三者による意見をどのように考慮したかの実質的な説明、CMA からのフィードバックや Google がフィードバックに対応するアプローチなど、Google と CMA の間のやり取りの概要について説明します。

Google は、コミットメントの第 17 条（b）項に従って予定されている定期的なステータス会議で、プライバシー サンドボックスの提案の進捗状況について CMA に最新情報を伝えてきました。また、チームはデベロッパー向けドキュメントを管理しています。このドキュメントでは、コアのプライベート広告機能とCookie の変更の概要、API の実装、ステータス情報について説明しています。主な更新情報はデベロッパー ブログで共有され、個々のデベロッパーのメーリング リストにも対象を絞った更新情報が共有されます。

第三者による観察結果を考慮する

略語集

ARA
Attribution Reporting API
CHIPS
Cookies Having Independent Partitioned State
DSP
デマンドサイド プラットフォーム
FedCM
Federated Credential Management
IAB
Interactive Advertising Bureau
IDP
ID プロバイダ
IETF
インターネット技術特別調査委員会
IP
インターネット プロトコル アドレス
openRTB
リアルタイム ビッダー
延長
オリジン トライアル
PA API
Protected Audience API（旧 FLEDGE）
PatCG
プライベート広告テクノロジー コミュニティ グループ
RP
証明書利用者
RWS
関連ウェブサイト セット（旧称: ファーストパーティ セット）
SSP
サプライサイド プラットフォーム
UA
ユーザー エージェント文字列
UA-CH
User-Agent Client Hints
W3C
World Wide Web Consortium
WIPB
Willful IP Blindness

一般的なフィードバック（特定の API/テクノロジーなし）

フィードバックのテーマ 概要 Chrome Response
プライバシー サンドボックスの今後 3PC のユーザー選択メカニズムの導入を進めないという発表を踏まえると、3PC が存在する場合に有用な API もあれば、有用にするために進化が必要な API もあります。プライバシー サンドボックス API 以外にも、Chrome への投資の可能性のある分野はあります。 いただいたフィードバックに感謝いたします。Google は、Chrome でユーザーに 3PC の選択肢を提供する現在の方法を維持するという 2025 年 4 月の発表を踏まえ、プライバシー サンドボックス API が今後果たす役割を評価し、将来の投資対象となる新たな分野を検討するため、関係者との連携を継続しています。
プライバシー サンドボックス 一部のエコシステム参加者は、3PC のユーザー選択メカニズムの導入を進めないという発表に失望していますが、達成された作業を誇りに思っており、プライバシー サンドボックス内の技術的な課題を認識しています。また、Chrome との協力関係の価値と、市場テスト助成金の有用性を強調しています。 フィードバックをいただきありがとうございます。Chrome は、広告をサポートするインターネットを維持しながらオンライン プライバシーを強化する技術を開発するために、デベロッパーと協力できるし、協力すべきであるというご意見に同意いたします。
ブラウザのデータ共有 ブラウザを介したデータ共有は、市場の非効率性や信頼性の問題に対処できる可能性を秘めた魅力的なテクノロジーです。ブラウザは、コラボレーションのためのサードパーティの実行コンテキストとして価値があります。 フィードバックをいただきありがとうございます。Chrome は、共同作業を行うデベロッパーとユーザー間の信頼を高めるテクノロジーの作成をデベロッパーが支援するうえで、役割を果たすことができるし、果たすべきであるという点に同意します。
Chrome トラフィック Chrome での Cookie なしトラフィックの割合と、シークレット モードのトラフィックの割合はどのくらいですか？ CMA が「コミットメントのリリースに関する意向通知」で指摘しているように、シークレット モードはブラウジング アクティビティのほんの一部にしか影響しません。英国と EEA のそれぞれにおいて、Chrome シークレット モードは、Android オペレーティング システムを搭載したデバイスでのナビゲーションの 10% 未満、Windows オペレーティング システムを搭載したデバイスでのナビゲーションの 10% 未満を占めています。これらの指標は、英国と EEA の Chromium ベースの Chrome でのナビゲーションのみを対象としています。
3PC をブロックするブラウザに関するデータは共有されません。
デベロッパーは、ストレージ アクセス ヘッダーを使用して Cookie がパーティション分割されるタイミングを判断し、利用可能な緩和策を適宜使用できます。
Chrome テストラベル 2024 年にテスト用に有効化された Cookie を使用しないトラフィックの 1% について、Chrome はどのような計画を立てていますか？ 現時点でお伝えできる予定はございませんが、入手次第、公開する予定です。
Chrome Testing 現在のテストラベルの設定には、サードパーティ Cookie とプライバシー サンドボックス API の両方が利用可能なシナリオのトリートメントが含まれていますか？ 現在のテストラベルの設定には、モード A の形式で 3PC とプライバシー サンドボックス API の両方のトリートメントが含まれています。
プライバシー サンドボックス 一部の広告主様は、プライバシー サンドボックス API が複雑であると感じており、以前の準備演習で無関心になったり、早期導入者のメリットをどのように定量化すればよいのか疑問に思ったりしています。また、リターゲティング、新規顧客開拓、測定の効果について知りたいと考えています。 フィードバックをお寄せいただきありがとうございます。技術的な複雑さや準備演習に関するご意見を承知いたしました。
現在のプライバシー サンドボックス技術のパフォーマンスを把握することについて、テスト結果から、プライバシー サンドボックス ソリューションのパフォーマンスを把握するうえでエコシステムの参加が重要な要素であることがわかりました。小規模なテストでは、市場の動向や、テクノロジーを大規模に使用するインセンティブを再現できませんでした。

登録と証明書

今四半期にフィードバックは寄せられていません。

関連性の高いコンテンツや広告を表示する

トピック

フィードバックのテーマ 概要 Chrome Response
Topics API のパフォーマンスとユーティリティのインタレスト（機能強化あり） 購入サイドの利害関係者からのフィードバックによると、Topics API は価値のあるシグナルであり、広告主のキャンペーンで 3PC オーディエンスの CPM と同程度の CPM を得ることができます。一部のパブリッシャーは、Topics API のシグナルを標準のオープン ウェブ シグナルよりも高品質であると見なしています。Topics API の有用性に関するフィードバックを踏まえ、関係者は、分類法の忠実度と一貫性の向上、パブリッシャーの制御の拡大など、より幅広い導入を促進するための機能強化を求めています。 Google は、Chrome でユーザーに 3PC の選択肢を提供する現在の方法を維持するという 2025 年 4 月の発表を踏まえ、プライバシー サンドボックス API が今後果たす役割を評価するにあたり、このフィードバックを考慮しています。
さまざまなタイプの
関係者にとっての
有用性		 現在、Topics 分類子はページのホスト名のみを使用して対応するトピックを定義しているため、コンテンツが多様な大規模サイトは一般的なトピックを提供し、小規模サイトは広告価値の高いニッチなトピックを提供しています。 回答は前四半期と同様です。
3PC と同様に、サイトによって提供される情報の価値には差があります。ニッチな興味関心サイトは、価値の貢献度が一定ではありません。すべてのニッチな興味関心サイトに商業的に価値のあるコンテンツがあるわけではないため、価値の貢献度が低くなります。Topics API のメリットを享受できるサイトは次のとおりです。Google はサイト単位ではなくページ単位の分類の可能性も検討しましたが、そのような分類にはプライバシーとセキュリティに関する重大な懸念が多数あります。
トピックの分類の粒度が十分でない Topics API は、1 つのドメイン内に多様なコンテンツ セクションを持つニュース メディアにとって十分な粒度を提供しておらず、広告ターゲティングにおける API の有用性を制限する可能性があります。 Google は、Chrome でユーザーにサードパーティ Cookie の選択肢を提供する現在の方法を維持するという 2025 年 4 月の発表を踏まえ、プライバシー サンドボックス API が今後果たす役割を評価するにあたり、このフィードバックを考慮しています。
分類器の改善 パブリッシャーが Chrome に、ページ コンテンツ（見出し、本文など）に基づいてトピックを分類する権限を付与できるようにします。 このリクエストについては現在検討中です。こちらから追加のフィードバックをお送りいただけます。
ポリシー Topics API と 3PC 情報を組み合わせて使用する場合のガイドラインに関する説明を求めるリクエスト。 Topics API は 3PC の機能のサブセットを提供するため、Topics API と 3PC の両方を使用しても問題はありません。
Observe-Browse-Topics ヘッダー Observe-Browse-Topics ヘッダーの実装に関する明確化のリクエスト。具体的には、ヘッダーを継続的に返すことで問題が発生するかどうか。 Observe-Browse-Topics: ?1 ヘッダーを継続的に返しても、技術的な問題は発生しません。
ブラウザはこのシグナルを効率的に処理し、重複やエラーを引き起こすことなく、ページ訪問がトピックの計算の対象となることを記録します。すべてのページで必須ではありませんが、すべての最上位ドキュメントで標準ヘッダーとして送信することは、有効でシンプルな戦略です。
分類カテゴリ 新しいトピックで最新のトピック分類を更新するリクエスト。 Google はこのリクエストを検討しており、エコシステムからの追加のフィードバックをこちらで受け付けています。
Null 値 Topics API のパフォーマンスを改善する方法と、フィルタリングや機密性などの null レスポンスの理由を理解するためのガイダンスのリクエスト。 なお、Topics API からの null レスポンスまたは空のレスポンスは、エラーではなく、プライバシー機能として想定されているものです。
null レスポンスは、次の原因で発生する可能性があります。
• プライバシー ルール: 5% の確率で null がランダムに発生するか、スクリプトがそのトピックに関連するサイトでユーザーを「観察」していないため。
• ユーザーの状態: 閲覧履歴が不十分、シークレット モードの使用、または Chrome の広告のプライバシー設定でユーザーがオプトアウトしている。
• 技術的なエラー: パブリッシャー サイトは Observe-Browse-Topics: ?1 ヘッダーを送信する必要があり、呼び出し元の iframe には allow="Browse-topics" 権限が必要です。
調査するには、chrome://topics-internals デバッグページを使用して、ブラウザが計算したトピックとその理由を確認します。
プライバシー機能により、100% のフィルレートは実現できませんが、次の方法でパフォーマンスを向上させることができます。
• パブリッシャーとの連携: パートナーがサイトで Observe-Browse-Topics: ?1 ヘッダーを正しく送信していることを確認します。
• コードの確認: iframe を使用している場合は、allow="Browse-topics" ポリシーが設定されていることを確認します。

Protected Audience API

フィードバックのテーマ 概要 Chrome Response
費用と複雑さにより PA API の導入が妨げられている 導入企業は、運用コスト、広告主様の需要の不足、取引所からの在庫量の少なさを理由に、Protected Audience API（PA API）の統合の優先順位を下げたり、ロールバックしたりしています。
PA API のメリットとして、高いマッチ率による持続的なオーディエンスの配信や優れたリーチの実現といった、PA API の潜在的な能力を挙げるフィードバックもありました。		 Google は、Chrome でユーザーにサードパーティ Cookie の選択肢を提供する現在の方法を維持するという 2025 年 4 月の発表を踏まえ、プライバシー サンドボックス API が今後果たす役割を評価するにあたり、このフィードバックを考慮しています。
クロス プラットフォーム機能 プラットフォーム間で PA API を活用して、クロスプラットフォーム機能をサポートし、リターゲティングとオーディエンス ターゲティングの機能を強化する必要があります。Google は、Chrome に登録されたインタレスト グループ（IG）がネイティブ環境やウェブビューで広告を配信する際にアクセスできるようにし、Android に登録されたインタレスト グループが Chrome のオークションで利用できるようにする必要があります。 Google は、Chrome でユーザーにサードパーティ Cookie の選択肢を提供する現在の方法を維持するという 2025 年 4 月の発表を踏まえ、プライバシー サンドボックス API が今後果たす役割を評価するにあたり、このフィードバックを考慮しています。
directFromSellerSignals コンテキスト オークションで利用できる情報の量を制限することで、オークション参加者は常に Google の広告サーバーを経由します。パブリッシャーは、まずすべてのエクスチェンジ パートナーを呼び出し、次に Google アド マネージャー（GAM）を呼び出してコンテキスト オークションを実行し、最後に GAM が IG オークションを呼び出すことを許可する必要があります。コンテキスト オークションの結果をリアルタイムで把握していなければ、競合他社は公平にトップレベルの決定を調整できません。

PA API の directFromSellerSignals 機能では、オークション情報に関する透明性が欠けている可能性があり、必要なデータにアクセスする能力が妨げられるおそれがあります。Google は、directFromSellerSignals を削除するか、広告サーバーのオークション落札価格を隠すために使用できないように更新する必要があります。たとえば、コンテキスト価格は、すべてのオークション参加者（およびパブリッシャー）がアクセスして検証できる、透過的で不変の署名付きフィールドを介して Chrome から渡すことができます。		 回答は前四半期から変更ありません。
Chrome の回答:
販売者が独自の iframe から runAdAuction() を呼び出さない限り、runAdAuction() に渡される情報が販売者からのものかどうかはわかりません。マルチセラー オークションでは、すべての販売者が runAdAuction() を呼び出すフレームを作成することはできません。directFromSellerSignals は、販売者のオリジンから読み込まれたサブリソース バンドルからコンテンツを読み込むことで、この問題に対処しました。これにより、販売者オークション構成からオークションに渡される情報の真正性と完全性が操作されることはありません。パブリッシャーが PA API を使用して、テクノロジー プロバイダが PA オークションに渡している情報を把握したい場合は、テクノロジー プロバイダにこの機能の提供を依頼できます。
Google アド マネージャーの回答:
Google は長年にわたり、オークションの公平性を重視してきました。たとえば、パブリッシャーの非保証型広告ソース（非保証型広告申込情報の価格など）の価格が、オークションで入札する前に別の購入者に共有されることはないという約束をしています。この約束は、後にフランス競争当局へのコミットメントでも再確認されています。
Protected Audience オークションでは、directFromSellerSignals を活用することで、約束を守り、マルチセラー オークションでオークションが完了する前に、オークション参加者の入札額を他のオークション参加者と共有しないようにします。なお、こちらの最新情報で説明しているように、コンテキスト アクションの価格を Google 独自のコンポーネント アクションと共有することもありません。
レポート 一元的なレポート作成を可能にするため、分析/レポート エンティティを追加するリクエスト。 このリクエストについてはこちらで議論しています。追加のフィードバックをお待ちしております。
buyerReportingId の k-匿名性 「buyerReportingId」の k 匿名性に基づいて入札を破棄し、オーディエンスのキュレーションと第三者データ プロバイダとのレポート義務を容易にする機能。 Google は、Chrome でユーザーにサードパーティ Cookie の選択肢を提供する現在の方法を維持するという 2025 年 4 月の発表を踏まえ、プライバシー サンドボックス API が今後果たす役割を評価するにあたり、このフィードバックを考慮しています。
generateBid スクリプトのデバッグ機能の改善 プロセスが失敗している generateBid スクリプト内の特定のステージまたは「ブレークポイント」を迅速に特定するメカニズムをリクエストします。 オンデバイス オークションのブレークポイント設定メカニズムとしてのリアルタイム測定の望ましい使用法については認識しています。Google は、Chrome でユーザーに 3PC の選択肢を提供する現在の方法を維持するという 2025 年 4 月の発表を踏まえ、プライバシー サンドボックス API が今後果たす役割を評価するにあたり、このフィードバックを考慮しています。
runAdAuction 状態をモニタリングするためのイベント リスナー 広告オークションのライフサイクルのモニタリングを改善するため、PA API の navigator.runAdAuction 関数にイベント リスナーのサポートを追加する提案。 このリクエストについては現在検討中です。エコシステムからの追加のフィードバックはこちらからお寄せください。
API 使用量 PA API と Attribution Reporting API（ARA）が、3PC がない状況でウェブ広告のユースケースをどのようにサポートできるか、特に 3PC はオプトアウトしているがプライバシー サンドボックス API はオプトアウトしていないユーザーの場合や、Cookie の同期が失敗した場合や WebView を使用する場合のシナリオについて、明確な説明を求めるリクエスト。 Google は、Chrome でユーザーにサードパーティ Cookie の選択肢を提供する現在の方法を維持するという 2025 年 4 月の発表を踏まえ、プライバシー サンドボックス API が今後果たす役割を評価するにあたり、このフィードバックを考慮しています。
レイテンシ PA API に関連するレイテンシが高すぎると、パブリッシャーが PA API を無効にする可能性があるため、導入が妨げられる可能性があります。 過去数四半期にわたり、デバイス上のレイテンシを改善するためのさまざまな取り組みが行われてきました。入札およびオークション（B&A）サービスの構築とスケーリングは、必要に応じて継続されます。レイテンシのベスト プラクティス ガイドが更新され、これらの機能を活用する方法に関する情報が追加されました。また、レイテンシを改善する新しい方法の開発も検討しています。その一部については、こちらでご確認いただけます。
B&A でのロギングの動作（テストと本番環境） B&A サービスのテストモードと本番環境モードのロギング動作の違いに関する説明。具体的には、クラウドログの可用性と、本番環境モードがロギングに与える影響です。 まず、本番環境ビルドと非本番環境ビルドと、ハードコードされたテスト暗号鍵を有効にするだけの TEST_MODE パラメータを区別することが重要です。以下の説明では、ビルドタイプに焦点を当てています。
非本番環境ビルドでは、B&A サーバーはロギング用に構成可能な詳細レベルを備えています。これらの詳細ログは、標準の stdout/stderr ストリームに書き込まれます。Google Cloud では、ネイティブのロギング インターフェースからアクセスできます。Amazon Web Services では、アタッチされたコンソールログで確認できます。
本番環境ビルドの場合、ロギングの動作はより制限されます。詳細レベルは固定されており、変更できません。サーバーの起動メッセージやほとんどのクラッシュ エラーなど、プライバシーに関連しないログは stdout/stderr に出力されますが、リクエスト固有のログはこのチャネルでは利用できません。本番環境ビルドからのリクエストごとのログは、同意済みのデバッグ トークンを含むリクエストのみで、OpenTelemetry 経由でのみエクスポートされます。同意を得たデバッグは、トラフィックの増加によってサーバーのパフォーマンスが低下し、ヘルスチェックが失敗する可能性があるため、慎重に使用することが重要です。
指標については、すべて OpenTelemetry 経由でエクスポートされます。プライバシーに配慮する必要のない指標は、ノイズ処理なしでそのままエクスポートされます。逆に、プライバシーに配慮した指標は、本番環境モードで実行されているサーバーからエクスポートされるときに常にノイズが追加されます。特定のテレメトリー構成によって、これらのプライバシーに配慮した指標がノイズあり、ノイズなし、または両方としてエクスポートされるかどうかが決まります。
ブランド セーフティの信頼できる入札シグナルにページの完全なパスを含める PA API の更新をリクエストして、trustedBiddingSignals の取得リクエストで、ホスト名に加えてトップレベル ページの完全な URL パスを含めるようにします。
主なユースケースは、ブランド保護をよりきめ細かく制御できるようにすることです。広告主様は、ドメイン全体は問題ないものの、ドメインの特定のセクション（news-site.com/politics など）に広告が表示されないようにブロックする必要があることがよくあります。これらのブロックリストは数百万件のエントリになる可能性があるため、サーバーサイドで評価する必要があります。現在の仕様ではホスト名のみが送信されるため、trustedBiddingSignals サーバーでこの必要なパスレベルの評価を行うことができず、ブランド セーフティ機能が制限されます。		 この問題については、現在こちらで議論しています。以前の議論については、こちらで確認できます。追加のフィードバックも歓迎します。
ただし、この情報の追加を検討しているのは、trustedBiddingSignals のフェッチが信頼できる実行環境（TEE）内で実行されているサーバーに送信される場合に限られます。

Protected Auction（入札およびオークション サービス）

フィードバックのテーマ 概要 Chrome Response
利用可否のテスト Chrome と B&A の両方の環境でテスト用の Key/Value（KV）v2 を利用できるかどうかに関する情報。 KV v2 は B&A と Chrome の両方で利用できます。追加のガイダンスはこちらをご覧ください。
KV サーバーの実装 KV サーバーの使用に関する説明を求めるリクエスト。具体的には、クリエイティブ レンダリング URL をリクエスト データにマッピングすること、レンダリング URL でパラメータを定義するために SSP と DSP の間で調整する必要があること、KV モードで必要な調整とデータ ストレージの概要を説明するドキュメントが利用可能であることについて。 KV サービスは renderURL をキーとして使用します。URL が新しい場合は、保存されます。存在する場合は、その値が返され、scoreAd で使用されます。戻り値の形式は設定によって異なります。「Bring Your Own Server」（BYOS）では任意の値を使用できますが、Trusted KV サービスではユーザー定義関数が必要です。
必ずしも必要ではありませんが、マクロ置換（${AD_WIDTH}) を renderURL に追加します。これにより、動的広告のカスタマイズと検証が可能になります。
まず 1 つの DSP を使用した簡単なテストから始め、必要な連携レベルを判断することをおすすめします。また、KV ドキュメントの更新も進めており、完成次第一般公開する予定です。
B&A の BYOS B&A には KV の BYOS モードのような BYOS モードがないのはなぜですか？ B&A は TEE を必要とするため、BYOS モデルは使用できません。これは、B&A がプライバシー メカニズムの適用を必要とする機密性の高いデータの組み合わせを処理するためです（下記を参照）。
DSP の場合:
B&A は、パブリッシャーのコンテキスト（オークション シグナル / 購入者ごとのシグナル経由で販売者から明示的に送信された場合は完全な URL の可能性あり）と、ユーザーの IG の詳細なデータを組み合わせて処理します。TEE は、この組み合わせを安全に処理し、ユーザーの再識別を防ぐために不可欠です。KV BYOS では、完全な URL を送信できません。
SSP の場合:
オークションに参加している IG（およびその DSP 所有者）の組み合わせを知るだけでも、識別可能なシグネチャを生成できます。そこで、TEE の使用を必要とする chaffing ソリューションが役立ちます。
そのため、これらの組み合わせた機密性の高いシグナルの安全な処理とプライバシー メカニズムの適用には、TEE の制御された証明済みの環境が必要です。

デジタル広告の測定

アトリビューション レポート（およびその他の API）

フィードバックのテーマ 概要 Chrome Response
騒音に関するポリシー ARA の実装は一部の市場参加者にとって有益であり、Google は引き続きイベントレベルのレポートを維持すべきです。Google は、ARA と 3PC の両方が利用可能なシナリオでは、ノイズ ポリシーの緩和を検討すべきです。パフォーマンス広告主は、ARA フレックス イベントの現在の「値」フィールドの実装をますます使用するようになっています。ノイズ ポリシーの制限を緩和することで、遅延や不正確なレポートを減らすことができます。 このメカニズムは、個々のユーザーのトラッキングを防ぐことでユーザーのプライバシーを保護することを目的とした ARA の設計の基礎となる部分です。Google は、ノイズによってレポート作成が困難になるというフィードバックを考慮しつつ、Chrome でユーザーに 3PC の選択肢を提供する現在の方法が維持されるという 2025 年 4 月の発表を踏まえ、プライバシー サンドボックス API が今後果たす役割と、将来的な機能強化の可能性について引き続き評価しています。
ロードマップと長期サポート 3PC のユーザー選択メカニズムの導入を進めないという発表を踏まえ、ARA のプロダクト ロードマップと、長期的な投資とサポートの確認をリクエストします。 プライバシー サンドボックス チームは、プライバシー サンドボックス API が今後果たす役割を把握し、将来の投資を評価するため、エコシステムと連携しています。
クロス環境の測定（アプリからウェブ） ARA を活用して環境をまたいだ測定を容易にし、よりクリーンで信頼性の高いデータフローを実現し、さまざまなプラットフォームでユーザー インタラクションを関連付ける機能を強化するソリューションのリクエスト。 同じデバイスでのアプリからウェブへのリンクは、ARA で既にサポートされています。アプリとウェブにわたる測定ソリューションについて詳しくは、こちら とこちらをご覧ください。
クロスブラウザ アトリビューション ARA のブラウザ横断的な統一アプローチは、オープンウェブでの ROI の測定能力を大幅に向上させ、規制の変更が起こる前に安定した代替手段を提供します。Chrome は、このような解決策について Safari チームと協力する必要があります。 W3C の PATCG グループと PATWG グループでは、他のブラウザ ベンダーと相互運用可能な API についてすでに検討を進めています。この作業は予備的なものであり、ステークホルダーは こちらで進捗状況を確認できます。
クロスデバイス/オフライン測定 ARA 内でクロスデバイス コンバージョンの測定をサポートできないことは、大きな制約となります。オンラインからオフラインへのコンバージョンの測定も非常に重要であり、ブラウザは測定ベンダーとの連携において役割を果たす可能性があります。 Google は、Chrome でユーザーにサードパーティ Cookie の選択肢を提供する現在の方法を維持するという 2025 年 4 月の発表を踏まえ、プライバシー サンドボックス API が今後果たす役割を評価するにあたり、このフィードバックを考慮しています。
マルチタッチ アトリビューション 広告主様がプライバシー サンドボックスのデータを偏りのない「グラウンド トゥルース」として使用し、既存のアトリビューション モデルを検証して調整できるようにするリクエスト。これは、ARA のブラウザ提供データを信頼できるキャリブレーション シグナルとして使用し、真実のベースラインを作成することで実現できます。 Google は、Chrome でユーザーにサードパーティ Cookie の選択肢を提供する現在の方法を維持するという 2025 年 4 月の発表を踏まえ、プライバシー サンドボックス API が今後果たす役割を評価するにあたり、このフィードバックを考慮しています。
同意なし/オプトアウトしたトラフィックの測定 Interoperable Private Attribution などのプライバシー保護ソリューションを使用すると、同意のないトラフィックの測定が可能になります。これにより、トラッキングをオプトアウトしたユーザーのデータも含まれるため、キャンペーンのパフォーマンスをより包括的に把握できるようになります。また、同意要件によって生じた測定の大きなギャップを解消できます。 Google は、Chrome でユーザーにサードパーティ Cookie の選択肢を提供する現在の方法を維持するという 2025 年 4 月の発表を踏まえ、プライバシー サンドボックス API が今後果たす役割を評価するにあたり、このフィードバックを考慮しています。
サーバー間アトリビューション 高度なサーバーサイド インフラストラクチャを備えた広告テクノロジーが、ユーザーのプライバシーを維持しながら、クライアントサイドのみでは管理が難しいユースケースに対応できるよう、より柔軟な方法で ARA と統合することを許可するリクエスト。 Google は、Chrome でユーザーにサードパーティ Cookie の選択肢を提供する現在の方法を維持するという 2025 年 4 月の発表を踏まえ、プライバシー サンドボックス API が今後果たす役割を評価するにあたり、このフィードバックを考慮しています。
マルチドメイン登録 ARA で複数のドメインを登録する際の制限事項と注意点について、特に集計サービスとクロスオリジン アトリビューションについて明確にしてほしい。 複数のドメインで ARA を使用する場合の主な制限事項は次のとおりです。
• アトリビューションは単一のオリジンに限定されます。ドメインの 1 つのクリックを別のドメインのコンバージョンに照合することはできません。アトリビューションは、ソースとトリガーの両方で同じオリジンにサンドボックス化されます。
• 集計サービスは、マルチオリジン バッチ処理をサポートしていません。異なるオリジンのレポートは、バッチ処理を別々に行う必要があります。今後、この機能をサポートする方法を検討しています。
簡単に言うと、1 つのエンティティに複数のドメインを登録できますが、現在、アトリビューションや集計などのすべての ARA 関数は、オリジンごとに処理する必要があります。

集計サービス

今四半期にフィードバックは寄せられていません。

Private Aggregation API

フィードバックのテーマ 概要 Chrome Response
制限とノイズレベル Private Aggregation API 内の集計キーのサイズと集計値の制限に関する懸念。 集計キーと値のサイズは、ネットワークとストレージのコストを抑えながら、高い粒度を実現するように選択されています。柔軟性を最大限に高めるため、キーを割り当てる際にはハッシュ化を使用することをおすすめします。
ユーザーデータを保護する他の要素もありますが、ノイズの追加は Private Aggregation API のプライバシー保護の重要な要素です。
Google は、フィードバックを考慮し、Google が 2025 年 4 月に発表した、Chrome でユーザーに 3PC の選択肢を提供する現在の方法を維持するという発表を踏まえ、プライバシー サンドボックス API が今後果たす役割を検討するとともに、適切なパラメータの選択肢を評価し続けます。
プライバシーと有用性 プライバシー サンドボックスのアプローチでは、利便性よりもプライバシーが優先されるため、導入が妨げられる可能性があります。測定と広告のパーソナライズの精度を高めるため、ユーザーの同意を得てより詳細なデータを共有できるようにする提案。 集計キーと値のサイズは、ネットワークとストレージのコストを抑えながら、高い粒度を実現するように選択されています。柔軟性を最大限に高めるため、キーを割り当てる際にはハッシュ化を使用することをおすすめします。
Google は、Chrome でユーザーにサードパーティ Cookie の選択肢を提供する現在の方法を維持するという 2025 年 4 月の発表を踏まえ、プライバシー サンドボックス API が今後果たす役割を評価するにあたり、このフィードバックを考慮しています。

隠れたトラッキングの制限

ユーザー エージェント文字列削減/ユーザー エージェント クライアントのヒント

フィードバックのテーマ 概要 Chrome Response
スパムの検出 スパム検出システムを使用するウェブサイトからの最初のリクエストがクライアント ヒントに依存している場合、トラッキング システムや検出システムがリクエストを識別または適切に分類できない可能性があります。 最初のリクエストで User-Agent Client Hints（UA-CH）にアクセスすることを前提とするユースケースでは、クリティカル クライアント ヒントを使用する必要があります。
API に関するフィードバック Sec-CH-USA-Wow64 は現代のウェブには関連性がなくなったため、非推奨にすることを検討してください。 このリクエストについては現在検討中です。こちらから追加のフィードバックをお送りいただけます。また、wow64 を Windows 以外にも拡張すると便利だというフィードバックも寄せられています。

IP 保護（旧称 Gnatcatcher）

フィードバックのテーマ 概要 Chrome Response
コントロール シークレット モード以外でサイトごとに IP 保護をオン / オフできるようにするリクエスト。 フィードバックをお寄せいただきありがとうございます。この問題に関する追加情報がございましたら、こちらからお寄せください。
違反行為 確率的開示トークン（PRT）が NULL 値になった場合、プラットフォームの不正行為について警察が IP アドレスの開示を要求したときに、加害者の特定を妨げることになりますか？ ドメインが不正行為と不正使用の検出専用に使用されている場合、そのドメインはマスクされたドメインリスト（MDL）に含まれていない可能性が高く、IP 保護の影響を受けません。そのため、これらのドメインには PRT は必要ありません。
ドメインが MDL に含まれている場合、現在、プロキシ リクエストの元の IP アドレスを取得する唯一の方法は PRT です。PRT は個々の識別ではなく、集計分析をサポートするように特別に設計されているため、ほとんどの場合、PRT に IP アドレスが含まれないのは事実です。ただし、IP 保護はサードパーティ コンテキストでのみ適用されるため、オンライン プラットフォームのサイトにユーザーがアクセスするなど、ファーストパーティのインタラクションについては、パブリッシャーはプロキシなしの IP アドレスを引き続き受け取ることになります。そのため、このシナリオでの影響は限定的であると予想されます。
不正対策 IP 保護の不正行為対策の具体的な内容（プロキシへのアクセスと認証トークンの発行のレート制限の詳細など）と、PRT の具体的なユースケースを教えてください。 IP 保護のレート制限と認証トークンは、不正行為防止とスパム対策の戦略で詳しく説明されているように、ボットがプロキシに過剰にアクセスして広告の不正行為を行うのを防ぐように設計されています。PRT のその他のユースケースについては、PRT の説明ドキュメント（こちら）をご覧ください。
シークレット モード シークレット モードでの IP 保護は、第 3 四半期にリリースされる予定ですか？ 現時点では、シークレット モードでの IP 保護のリリースに関する第 3 四半期のタイムラインに変更はありません。

バウンス トラッキング対策

フィードバックのテーマ 概要 Chrome Response
API に関するフィードバック Chrome は、バウンス トラッキング軽減策（BTM）を適用する際に、Cookie/ストレージをパーティショニングするのではなく、アクセスをブロックする必要があります。Safari の「パーティショニング」方式による意図しない動作や混乱を理由としています。 この提案は歓迎します。現在、BTM では Cookie/ストレージのパーティショニングは行われず、猶予期間後に削除されます。BTM の今後の設計で Cookie に対する即時的なアクションが必要になる場合は、Cookie のパーティショニングよりも Cookie のブロックを優先する予定です。

クロスサイト プライバシー境界の強化

今四半期にフィードバックは寄せられていません。

Fenced Frames API

今四半期にフィードバックは寄せられていません。

Shared Storage API

フィードバックのテーマ 概要 Chrome Response
API 機能リクエスト 共有ストレージに広告の表示回数とクリック回数を追加するリクエスト。 Google は、Chrome でユーザーにサードパーティ Cookie の選択肢を提供する現在の方法を維持するという 2025 年 4 月の発表を踏まえ、プライバシー サンドボックス API が今後果たす役割を評価するにあたり、このフィードバックを考慮しています。

CHIPS

フィードバックのテーマ 概要 Chrome Response
API に関する質問 Chrome の 3PC 制御と CHIPS の相互作用に関する説明のリクエスト。特に、3PC が無効になったときにパーティション分割されていない Cookie がパーティション分割された Cookie に変換されるかどうか、およびパーティション分割された Cookie がアクティブなままかどうか。 3PC が無効になっている場合、パーティション分割されていない Cookie はサードパーティ コンテキストで保存、取得、送信されません。ただし、パーティション化された Cookie は、3PC を無効にするブラウザ設定の影響を受けないため、引き続きサードパーティ コンテキストで保存、取得、送信されます。
プライバシーに関する懸念 シングル サインオンなどの永続的な識別子を持つ埋め込みパーティは、パーティション分割された Cookie を使用していても、埋め込みと埋め込みパーティの両方がグローバル デジタル識別子を取得できる可能性がある。 埋め込みパーティには永続的な識別子がある場合がありますが、この識別子がパーティション化された Cookie に保存されている場合、その Cookie が埋め込みによって設定されたサイトでのみアクセスできます。この識別子をサイト間で結合するにはログイン操作が必要ですが、パーティション分割された Cookie を使用しなくても、認証トークンの形式で識別子を交換できます。

FedCM

フィードバックのテーマ 概要 Chrome Response
API 使用量 特定のエラーが発生していない複数のアカウントを持つユーザーに対して、サイレント メディエーションが失敗する。 サイレント メディエーションの動作は、利用可能なアカウントが 1 つしかないという非常に特殊なケースを想定した設計上の機能です。代わりに「オプション」のメディエーションを使用することをおすすめします。この場合、サイレント メディエーションができないと、FedCM はアカウント選択ツールをユーザーに表示するようフォールバックします。
API 使用量 navigator.credentials.get は一般的なエラーを返し、ユーザーの解任やクールダウン期間などの具体的な拒否理由をキャプチャできません。 開発者が、ユーザーが FedCM ダイアログを閉じたのか、ネットワーク エラーが発生したのか、ユーザーが以前にダイアログを閉じたために FedCM が「クールダウン期間」に入ったのかを区別できないことも、ユーザーのプライバシーを保護するための仕様です。このような機能により、ウェブサイトがさまざまな ID プロバイダ（IdP）でのユーザーのログイン状態を推測できるようになることが懸念されています。
ログイン 複数のアカウントにログインしている場合、アカウントの選択動作に一貫性がないことが確認されました。 複数のアカウントにログインしているシナリオで特定のアカウントを断続的に選択できない問題が、FedCM の断続的なバグなのか、テストシステムに関連する問題なのかは不明です。Google は、この問題を解決するために報告者と協力しており、問題をより深く理解するために詳細情報の提供を依頼しています。
API 使用量 ユーザーが FedCM での認証中にダイアログを閉じると、クールダウン状態にあることがキャッチ可能なエラーとして報告されません。 はい。その場合は、ユーザーのプライバシーを保護するために一般的なエラーコードが生成されます。
API 使用量 「自動再認証」に成功した後、FedCM が 10 分間の静止期間に入るのはなぜですか？ 自動再認証はユーザーが開始したアクションなしで行われるため、ユーザーがウェブサイトに戻って別のアカウントでログインしたい場合は、FedCM が自動再認証を行わない期間が必要になります。「静止期間」は、ユーザーが別のユーザー アカウントを使用して手動でログインする機会を提供します。この「静止期間」の詳細については、こちらのブログ投稿をご覧ください。
軽量 FedCM Lightweight FedCM の提案では、互換性のない 2 つの実装（FedCM と Lightweight FedCM）をサポートする必要があるため、IdP の複雑さが増すという懸念があります。 軽量 FedCM は従来の FedCM と互換性があります。IdP は、使用する実装方法を選択できます。両方をサポートする必要はありません。
軽量 FedCM は、FedCM のプッシュ メカニズムです。IdP がこの機能を使用することを選択した場合、ユーザーがログインしたときにアカウント情報をブラウザにプッシュできます。これにより、利用者（RP）が FedCM を呼び出すと、アカウントは IdP のアカウント エンドポイントではなく、ブラウザから取得されます。
軽量 FedCM Lightweight FedCM の提案で、名前、メールアドレス、プロフィール写真などのユーザーの個人データが RP に公開されることに関する懸念。 このフィードバックを受けて、軽量版 FedCM の提案が更新され、メソッド レスポンスから名前、メールアドレス、プロフィール画像が削除されました。
軽量 FedCM Lightweight FedCM の提案では、複数のログイン済みアカウントの管理が厳しすぎるようです。この提案では、現時点では個々のセッションの有効期間や、アカウントごとのログイン状態のニュアンスはサポートされていません。 有効期限は現在、認証情報オブジェクト内の IdP に関連付けられています。アカウントごとの有効期限は未解決の問題として認識しており、今後の開発でこのフィードバックを考慮します。
軽量 FedCM 「ログイン済み」と「選択可能」の区別が明確に定義されていないため、Lightweight FedCM 提案のユーザー エクスペリエンスに影響する可能性があります。 現在、FedCM ユーザー インターフェース（UI）でアカウントがログイン状態かログアウト状態かを区別する機能はサポートされていません。ログアウトしたアカウントは表示されません。
アカウントがログアウトしてリストに表示されている状態で、ユーザーがアクティブにログインしていないアカウントを選択した場合、継続 API を使用してユーザーに再度ログインさせることができます。
API 使用量 getUserInfo の given_name フィールドと FedCM UI での使用方法との間に不整合がある。 この問題については、getUserInfo で given_name をどのように扱うかについて合意するため、Mozilla と こちらでさらに議論しました。
API 使用量 IdentityProviderAccount の UI で使用されるすべてのフィールドが getUserInfo に提供されるわけではありません。特に tel と username は提供されません。これは、同期の必要性を示唆しています。 Mozilla や他の FedID コミュニティ グループのメンバーとの話し合いは、IdentityProviderAccount のどのフィールドを getUserInfo. に送信するかを調整するという問題について進んでいます。
Enterprise FedCM エンタープライズ IdP のユースケースに対する FedCM のサポートをリクエストします。 主な問題は、IdP がブラウザに、管理者がユーザーに特定の RP へのアクセスを許可することに事前に同意していることを通知するための、信頼できるメカニズムが必要であることです。この RP は、ウェブ トラッカーによって模倣または悪用されることはありません。この件については、4 月 22 日の FedID CG 会議で議論されました（会議のメモはこちらをご覧ください）。ブラウザ拡張機能とエンタープライズ ポリシー（管理対象デバイスの場合）の組み合わせが、潜在的な解決策として提案されました。この問題についてご意見がございましたら、こちらからお寄せください。

スパムや不正行為に対処する

Private State Token API（およびその他の API）

今四半期にフィードバックは寄せられていません。