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

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

Google は、競争・市場庁（CMA）に対するコミットメントの一部として、第 12 条、第 17 条（c）（ii）、第 32 条（a）に基づき、この四半期レポートを作成しました。この報告書では、Google のプライバシー サンドボックスの提案の進捗状況、予定時期の更新、Google がサードパーティの観察結果をどのように考慮したかの詳細な説明、Google と CMA のやり取りの概要（CMA からのフィードバックと、Google がフィードバックに対応する方法）について説明します。

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

IP の故意の無視

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

フィードバック テーマ	概要	Chrome の対応
ユーザーの選択	ユーザーの選択を尊重するための Google の新しいアプローチの内容、ユーザーへの表示方法、オプトイン/オプトアウトの見込み率は不明です。サードパーティ Cookie のサポート終了と区別するには、追加の情報が必要です。	2025 年 4 月に、Google は Chrome におけるプライバシー サンドボックスとトラッキング防止機能の今後のステップに関するブログ投稿を公開し、Chrome でサードパーティ Cookie をユーザーに提供する現在のアプローチを維持し、サードパーティ Cookie 用の新しいスタンドアロン プロンプトをリリースしないことを発表しました。 新しい情報が入り次第、お知らせいたします。
フィンガープリント	Google は、よりリスクの高い消費者 ID を共通のマッチキーとして使用せずに、Google の広告システムの代替手段を活用する方法について、パブリッシャーやマーケティング担当者と情報を共有していません（例: フィンガープリント）。	Google 広告システム以外のいくつかのソリューションを紹介しました。これらのソリューションは、プライバシー サンドボックス API を一部に使用してパブリッシャーとマーケティング担当者に提供されています。これには、市場やチャネルを問わず、Google 以外の広告システムが含まれます。詳細と事例については、privacysandbox.com のビジネス リソース セクション（こちら）をご覧ください。
プライバシー サンドボックス	プライバシー サンドボックス API は、インターネット データの要素を Google 独自の完成品に置き換えます。Google が提示する代替手段は API であるため、Google が所有、管理するプロダクトへのアクセスを提供するものであり、Google の裁量で規約が適用されます。これは、他者が独自の完成品を製造するために使用するコンポーネントに代わるものではありません。	プライバシー サンドボックス API は、規制当局や幅広いエコシステム ステークホルダーとの広範な連携に基づいて開発、実装されています。他のプラットフォーム技術と同様に、プライバシー サンドボックス API は、他の完成品のコンポーネントとして使用されることを考慮する必要があります。Google は、プライバシー サンドボックス API と連携する追加の技術を開発するためのエコシステムの取り組みを歓迎します。
ユーザー選択	Chrome でのサードパーティ Cookie に対する Google の更新されたアプローチが、ステークホルダーの同意管理プラットフォームの使用に影響する可能性がある特定の規制要件を満たすかどうかに関する情報の提供をリクエスト。	2025 年 4 月に、Google は Chrome におけるプライバシー サンドボックスとトラッキング防止機能の今後のステップに関するブログ投稿を公開し、Chrome でサードパーティ Cookie をユーザーに提供する現在のアプローチを維持し、サードパーティ Cookie 用の新しいスタンドアロン プロンプトをリリースしないことを発表しました。 新しい情報が入り次第、お知らせいたします。
プライバシー サンドボックスのタイムラインと導入	広告テクノロジーは、プライバシー サンドボックス API のテストを一時停止し、プロダクトとマーケティング活動のためにこれらのテクノロジーに再投資するより強い理由を探しています。再投資の判断は、ユーザー選択のタイムラインの明確化の必要性、Protected Audience API（PA API）のレイテンシと B&A のロードマップに関する懸念に大きく影響されます。また、CMA のコミットメントの審査についても懸念が寄せられています。特に、サードパーティ識別子に依存しないプライバシー サンドボックス技術の主な推進者としての Google の役割と、投資戦略に反映するためのイニシアチブの今後の方向性について懸念が寄せられています。	2025 年 4 月に、Google は Chrome におけるプライバシー サンドボックスとトラッキング防止機能の今後のステップに関するブログ投稿を公開し、Chrome でサードパーティ Cookie をユーザーに提供する現在のアプローチを維持し、サードパーティ Cookie 用の新しいスタンドアロン プロンプトをリリースしないことを発表しました。新しい情報が入り次第、お知らせいたします。 Chrome PA API オークションの速度は前年比で 35% 向上しました。さらに、並列オークションの使用が大幅に増加し、オークションの成果がさらに向上しています。 現在の B&A ロードマップについては、こちらをご覧ください。
プライバシー サンドボックスのスケジュール	プライバシー サンドボックスのタイムライン ページで更新された内容	Topics API の概要が、プライバシー サンドボックスのタイムライン ページに追加されました。
プライバシー サンドボックス	プライバシーと有用性に関する研究論文で、プライバシー サンドボックスが収益に与える影響について説明しているものはありますか？	これらの質問に答える関連するマーケット ケース スタディはこちらで、プライバシー サンドボックス API のテスト結果はこちらでご覧いただけます。
プライバシー サンドボックスの導入	早期導入者から、大規模な企業による導入が遅れているため、プライバシー サンドボックス API の初期段階で問題が発生し、テストのリリースに影響が出ていると報告されています。ただし、プライバシー サンドボックス チームの協調的なアプローチとフィードバックへの迅速な対応は高く評価されました。	早期導入者の皆様からのフィードバックをお待ちしております。Google は、早期導入者と連携することに全力で取り組んでおり、エコシステムをサポートするプライバシー サンドボックス技術の役割を評価するとともに、エコシステムと連携してフィードバックを収集し続けます。
Chrome テスト	テストラベルの削除後にプライバシー サンドボックスのテストを引き続き効果的に実施できるかどうかに関する懸念。サードパーティ Cookie が無効になっている Chrome（モード B）と、Chrome の設定でサードパーティ Cookie を個人的に無効にしているユーザーとでは、トラフィックの品質に大きな違いがあることが明らかになっています。	Google の回答は、前四半期と同様です。 プライバシー サンドボックス チームは、企業がCookie のサポート終了ラベルを引き続き使用したいと考えていることを理解しています。ラベルの提供を延長するプロセスは、オリジン トライアルの延長と同様です。ラベルのサポートは、これまでに何度か延長されています。Cookie のサポート終了ラベルのサポートをさらに拡張することを提案する予定です。最新情報は blink-dev で公開します。

登録と構成証明

今四半期にフィードバックはありませんでした。

関連性の高いコンテンツと広告を表示

トピック

フィードバック テーマ	概要	Chrome の対応
オプトイン/オプトアウト	Google 検索が Topics API のオプトアウトをサイトの判断で使用しないことを Google が確認したことで、Topics API のオプトインをサイトの判断で使用することが制限されることになりますか？	回答は前四半期と同様です。 プライバシー サンドボックス チームは、ウェブサイトが Topics API を採用するインセンティブとしてページ ランキングを使用するよう、検索チームと調整したり、検索チームにリクエストしたりしていません。Google 検索では、Topics API をサポートする（またはサポートしない）というサイトの判断は、ランキング シグナルとして使用されません。
使用状況のオブザーバビリティ	SSP または一般的な広告テクノロジーの可観測性メカニズムをリクエストして、Topics API の実装がウェブで使用されているかどうかを確認する。	Google ではこの機能のサポートを検討しており、この機能が優先度が高い場合は、エコシステムから追加のフィードバックをお寄せください。
プライバシー	同意と再識別の可能性に関する質問。	現在、この問題についてこちらで議論しており、皆様からのフィードバックをお待ちしております。

Protected Audience API

フィードバック テーマ	概要	Chrome の対応
PA API と GAM/AdX	Google は、競合他社のパブリッシャー広告サーバーを利用するパブリッシャーに GAM/AdX のデマンドを送信しません。Google は、競合するパブリッシャーが代替のトップレベルの PA API オークション販売者を選択して最終的なオークションを制御できるようにする必要があります。PA API の情報は GAM で利用できます。ただし、競合する SSP では制限されます。そのため、パブリッシャーは、AdX や PA API に統合された SSP など、PA API を介して調達したデマンドのパフォーマンスを GAM で比較することはできません。	Chrome の回答: PA API 標準は柔軟性を重視して設計されており、さまざまな関係者がトップレベル オークションを実施できます。この選択は、パブリッシャーの広告サーバー（GAM または他のもの）と、エコシステムに参加している他の企業が提供する特定の実装と機能によって異なります。 PA API のプライバシー重視の設計により、すべての参加者の詳細なレポートが常に制限されます。PA API オークションから報告される特定のデータには、SSP を含むすべての参加者に対して、API で定義されたプライバシー保護ルールと制限が適用されます。 パブリッシャーは、PA API のプライバシー保護集計レポートを使用してパフォーマンスを評価します。これにより、PA API を介して調達されたデマンドの全体的な貢献度を評価し、API のプライバシー バイ デザインの原則に沿って他のデマンド チャネルと比較できます。 Google アド マネージャーから提供された回答: AdX デマンドにアクセスするために、パブリッシャーが GAM の広告サーバー機能を使用する必要はありません。また、PA API は、単一販売者と複数販売者の両方の設計において、オークションを開始する販売者に依存しません。
トップレベルの販売者	トップレベル販売者（TLS）は、他のコンポーネント販売者がアクセスできない情報にアクセスできるため、情報へのアクセスの不平等に関する懸念が提起されています。TLS には任意のエンティティを使用できますが、AdX の広告需要にアクセスするには、パブリッシャーはパブリッシャー広告サーバーとして GAM を使用する必要があります。これにより、パブリッシャーが Google アド マネージャーを広告サーバーとして使用することが促進され、Google の競争力が強化されます。	Chrome の回答: PA API の設計では、TLS として機能できるエンティティは指定されていません。TLS ロールでは、オークションの調整と、API の構造に従って関連するオークション情報へのアクセスが必要です。 Google アド マネージャーから提供された回答: Google は長年にわたり、オークションの公平性に重点を置いてきました。その一環として、非保証型の広告申込情報の価格など、パブリッシャーの非保証型広告ソースの価格を、オークションで入札する前に他の購入者と共有しないことを約束しています。この約束は、フランス競争当局への Google のコミットメントで改めて確認されています。 PA API オークションでは、Google は約束を守り、マルチセラー オークションでオークションが終了するまで、オークション参加者の入札価格を他のオークション参加者と共有することはありません。なお、こちらの最新情報で説明したとおり、Google はコンテキスト オークションの価格を、Google 自身のコンポーネント オークションを含むどのコンポーネント オークションとも共有しません。また、Google は、コンポーネント オークションの構成に関する情報（購入者が SSP に提供するシグナルなど）を、Google 独自のオークションで使用しません。 また、前述のとおり、アド マネージャーでは、パブリッシャーが AdX デマンドにアクセスするために広告サーバー機能を使用する必要はありません。 最後に、Google の 2024 年第 2 四半期 / 第 3 四半期レポートで以前に説明したように、Google の購入側プラットフォーム（Google 広告（旧 AdWords）とディスプレイ＆ビデオ 360）は、PA API 経由を含む Google 以外のエクスチェンジからインプレッションを購入しています。
PA API と GAM/AdX	オプションのラベル付けから目的が明確にならないため、パブリッシャーは広告枠の 100% で PA API を有効にすることを理解することが困難です。広告枠へのアクセス手段として、多くの場合 GAM が TLS として機能するマルチレベル オークションを使用する SSP の場合、GAM の対象となることなく PA API を介してテストを実施したり収益化したりすることは実質的に不可能です。	Chrome の回答: PA API 標準では、技術的な役割（TLS やコンポーネント セラーなど）とオークション プロセスが定義されており、これらの役割を実行するプラットフォームを柔軟に選択できます。 構成、調整、契約などの運用作業は、PA API フレームワークを使用した参加を容易にするために、実装側（パブリッシャー、SSP、TLS プロバイダ）によって管理されます。 Google アド マネージャーから提供された回答: ヘルプセンターに記載されているとおり、アド マネージャーには、API を使用できるパブリッシャーの広告枠の 100% で、Google 以外のコンポーネント販売者（他の SSP など）によるテストを有効にするための管理機能が用意されています（GAM が適用するサンプリングやスロットリングをオーバーライドします）。 パブリッシャーがこのコントロールを有効にすると、Google 以外のコンポーネント ベンダーがオークション構成を提供した場合、GAM は、パブリッシャーが必要なユーザーの同意を得ている場合に、提供されたコンポーネント オークションを含むトップレベル オークションの実行を試みます。GAM では、このコントロールがパフォーマンスに影響する可能性があることをパブリッシャーに明示しているため、パブリッシャーは十分な情報に基づいて判断できます。
サーバーサイドとオンデバイス	入札とオークション（B&A）などのサーバーサイド ソリューションは、プライバシーを維持しながらトラフィック シェーピングを解決する可能性があります。サーバーサイド ソリューションが唯一の現実的な方法であり、Google はオンデバイス ソリューションを放棄すべきです。	プライバシー サンドボックスは、サーバーサイド（B&A サービス）とオンデバイス オークション ソリューションの両方をサポートし、さまざまな広告テクノロジーのニーズとユースケースに対応するオプションを提供することを目的としています。
オークションのセキュリティ	PA API 入札に対する攻撃は、基本的にオンデバイス入札とオークションの資格を失うことになります。この問題はステークホルダーから解決済みとは見なされておらず、PA API 入札の改ざんを防ぐための技術的な保証と、リアルタイムのインシデント検出と効率的なデバッグを行うための包括的なデバッグモードの提供が引き続き求められています。	プライバシー サンドボックスでは、潜在的な攻撃の軽減など、PA API オークションの完全性を確保することに重点を置いています。API の設計には完全性測定が組み込まれています。具体的な懸念事項について、技術的な議論をさらに深めていただければ幸いです。 2024 年 5 月の W3C 不正行為防止コミュニティ グループ ミーティングで、PA API に対する潜在的な攻撃の詳細なリストとその緩和策について発表し、議論しました。潜在的な「PA API 入札への攻撃」について、皆様からのさらなるご意見やフィードバックをお待ちしております。
Cookie レス トラフィック	テストやその他の目的で、Cookie を使用しないトラフィックでのみ PA API を有効にする方法はありますか？	広告テクノロジーは、3PC が存在するかどうかを特定できます。詳細については、こちらをご覧ください。
座席 ID	Seat ID の提案について、Seat ID の知識はほとんどの入札リクエストに不可欠であり、Seat ID をクリエイティブ登録に関連付けることについて懸念が寄せられています。また、この設定は「メイン広告」にのみ適用されますか？それともコンポーネント広告にも適用されますか？	BuyerAndSellerReportingId プロポーザルは、メイン広告のクリエイティブ登録時に購入者のシート ID が指定されないという懸念に対処しています。この識別子は、購入者のシート ID を販売者に伝えることを目的としています。コンポーネント広告のサポートについては現在検討中です。
モニタリングとレポート	リアルタイム モニタリング（RTM）の機能リクエスト: （1）キャンセルされたオークションの RTM レポートの送信、（2）ブラウザに入力された新しいバケットで、どのようなキャンセルが発生したかを明確にします。	RTM は、参加率の調査には適したソリューションではないようです。RTM は、低レイテンシのモニタリング API として、重大な突然の一時的なサービス停止を検出するように設計されています。一方、参加率では低レイテンシのレポートは必要ありません。また、重大な突然の一時的な停止でもありません。参加率に関する懸念は、購入者がブラウザで調査するのではなく、購入者が連携している販売者が最も効果的に回答できます。 さらに、オークションのキャンセルは非常に頻繁に発生するため、ブラウザがキャンセルされたオークションごとに RTM レポートを生成する場合は、実際の停止に関する RTM レポートが埋もれてしまう可能性があります。
ドキュメント 明確化	PA API の説明で、ノンスは UUID 文字列である必要があると記載されているが、実際にはプロミスを返すというドキュメントの不一致に関する報告。	こちらに明確化案が提示されています。
凍結された コンテキスト	凍結コンテキストで作業する場合、（1）バンドル、（2）外部ライブラリ、（3）サポートされていないデータ型に関連する問題や課題に対処するには、どのようなオプションがありますか？	この質問に対する回答はこちらにあります。
仕様	Private Aggregation API に汎用の contributeToHistogramOnEvent オペレーションが追加されました。その結果、PA API の定義はオーバーロードされたオペレーションになりました。Web IDL オペレーションは「インターフェース、部分インターフェース間でオーバーロードしてはならない」ため、その定義は無効になりました。	この問題は、両方の API で類似の変更を統合する際に、PA API と Private Aggregation の仕様が一時的に不整合になることを示しています。この問題に対処するため、pull リクエストを統合しました。
インタレスト グループ	キャンペーンを停止する際に、インタレスト グループ（IG）の入札参加を終了するための推奨の方法とリソース効率の高い方法について、ガイダンスをリクエストします。	以下に、いくつかの提案をご紹介します。 レイテンシが最も低く、永続性が最も低く、リソースの解放が最も少ないメカニズムは、リアルタイム入札シグナルを使用して入札を停止するよう generateBid() に通知することです。 リソースをより少なく使用する 2 つ目の方法は、リアルタイム入札シグナル レスポンスでその IG の優先度を負に設定することです。これにより、generateBid() が呼び出されなくなります。 3 つ目の方法は、リソースをさらに少なく抑えることができる Instagram から広告を削除することです。広告のない IG では generateBid() が呼び出されません。 4 つ目のオプションは、IG から biddingLogicURL を削除することです。これにより、さらにリソースを削減できます。この時点では、IG を更新または再加入して再び有効にすることができます。 その他のオプションは、leaveAdInterestGroup() または clearOriginJoinedAdInterestGroups() による IG からの離脱、または IG の有効期限切れに関するものです。 上記で説明したように、オプションによってレイテンシへの影響とリソース消費量が異なります。広告テクノロジーは、特定のユースケースに最適なトレードオフを選択できます。
オーディエンス	作成したオーディエンスに対して論理演算を実行するメカニズムのリクエスト（例: IG A と IG B の交差をターゲティングする機能）	PA API では、現在、同じサイトのオーディエンスに論理演算を実行できます。Google のプライバシー モデルで説明されているように、プライバシー上の考慮事項から、現在のところ、異なるサイトのオーディエンスの論理演算はサポートされていません。Google では引き続きこの分野の調査を進めており、進捗状況に応じて最新情報をお知らせします。
機能のリクエスト	事前に TLS を把握することを必要とする追加入札の制限を削除する提案。	現在、この提案についてこちらで議論しており、皆様からのフィードバックをお待ちしております。
Chrome での 3PC へのアプローチの更新	PA API などのプライバシー サンドボックス API は、すべての Chrome Stable ユーザーに一般提供されるままになりますか？それとも、API（または API のサブセット）は、サードパーティ Cookie を拒否したユーザーにのみ使用可能になりますか？	ユーザーがサードパーティ Cookie を拒否しても、Chrome Stable でプライバシー サンドボックス API を利用できることに影響はありません。
拡張シグナリング	TLS が PA API オークションを実行するかどうかを示す機能を追加する予定はありますか？	Google では現在、この機能のサポートを検討しています。時期については、準備ができ次第お知らせいたします。このリクエストについて、ご意見やご感想をお寄せください。
取引 ID	取引 ID の提案における KV サーバー要件が、費用と時間のかかるサーバーサイド プロセスになる可能性があるという懸念。	取引 ID プロポーザルにより、SSP は PA オークション中に選択した取引 ID のメタデータを Key-Value サーバーからクエリできるため、取引に関連するすべてのメタデータをデバイスにプリロードする必要がなくなります。この提案は SSP からのリクエストに応じて開発されています。エコシステムからの追加のフィードバックはこちらからお寄せください。 鍵値サーバーの設定には手間がかかりますが、全体的には広告テクノロジー企業にとってメリットが大きいと考えております。このプロセスをより簡単に行うためのフィードバックやご提案をお待ちしております。
Instagram 間のフリークエンシー キャップ	PA API を介した Instagram 間のフリークエンシー キャップのリクエスト。	Instagram 間のフリークエンシー キャップには、解決策が見つからない難しいプライバシー特性があります。 この機能が優先度が高い場合は、エコシステムからの追加のフィードバックをお待ちしております。
取引 ID とシート ID のレポート	集計レポートに取引 ID またはシート ID を取得する機能をリクエストする。	こちら で現在開発中のレポート ID 機能により、取引 ID とシート ID のレポートが可能になります。 selectedBuyerAndSellerReportingId は reportResult() に提供されるため、イベントレベル レポート（sendReportTo() に渡される URL に取引 ID をエンコードする）を使用してレポートするのが最も簡単な方法です。集計レポートを使用することもできます。 現在、Reporting ID 機能は Chrome Stable チャンネル トラフィックの 10% で有効になっています。リリースを 100% に拡大することを検討しています。
インタレスト グループ	IG の選択と評価の両方で同じ優先順位を使用し、すべての評価モードでその優先順位を使用します。	現在、この件についてこちらで議論しており、皆様からのフィードバックをお待ちしております。
インタレスト グループ	プライバシー サンドボックス API の導入を促進するために、オーディエンスの有効化と委任を使用するよう提案する。	複数の関係者から寄せられたこのリクエストは認識しており、解決策を調査しています。 エコシステムからのフィードバックをお待ちしております。
インタレスト グループ	PA API IG の作成に関する課題（特に、複数の購入やパブリッシャーに代わって行動する場合の委任と所有権に関する課題）。	複数のステークホルダーから、より高度な IG 委任をサポートするようリクエストを受けており、このプロセスに SSP が貢献する付加価値があると考えています。 Google では、さまざまな関係者がオーディエンス拡張プロセスに参加できる最適なソリューションを見つけるための調査を行っています。エコシステムからのフィードバックをお待ちしております。
クライアントサイドのパフォーマンス	インフラストラクチャの費用とレイテンシを最適化するために、trustedBiddingSignals のクライアントサイド キャッシュを容易にする方法に関するガイダンスをリクエストします。	現在、この件についてこちらで議論しており、皆様からのフィードバックをお待ちしております。

Protected Auction（B&A サービス）

フィードバック テーマ	概要	Chrome の対応
K/V サービス	ブラウザから販売者の KV サーバーに送信されるリクエストはどのようにバッチ処理されますか？販売者にとって、ブラウザからのリクエストは GET リクエストと POST リクエストのどちらになりますか？また、k-匿名性の要件について、いくつかの明確化が必要です。	v1 の場合、Chrome は販売者の KV サービスに GET リクエストを送信し、リクエストのクエリ パラメータ内のシグナルを使用して trustedScoringSignalsURL を取得します。パラメータには hostname、renderUrls、adComponentRenderUrls、experimentGroupId が含まれます。現在、クリエイティブ スキャン用の追加情報を送信する拡張機能のテストを行っていますが、まだリリースされていません。 maxTrustedScoringSignalsURLLength を 0 に設定すると、Chrome はすべてのシグナルを 1 つのリクエストにバッチ処理する可能性があります（サーバーの URL 長の制限を超える可能性があります）。ただし、必ずしもそうとは限りません。現在、Chrome では、リクエストが 10 ミリ秒以内に送信可能であれば、同じバッチに含めるように選択していますが、現在、これを最適化する方法を調査しています。 trustedScoringSignals を使用する場合は、Chrome がキャッシュ ヘッダーを尊重することを覚えておくと便利です。Stale-While-Revalidate「Cache-Control」ヘッダーなどのヘッダーを使用すると、Chrome がキャッシュに保存されたコピーを使用できるようにし（次のオークション用にキャッシュを更新）、シグナルの取得をクリティカル パスから効果的に削除することで、平均レイテンシを短縮できます。 最後に、k-匿名性について、説明の特定のセクションが古くなっているように思われます。当初は、信頼できるシグナルの URL を k-匿名にすることを義務付ける予定でしたが、この要件は廃止されました。この文は説明文から削除します。
B&A サービス	B&A の最新バージョンにアップグレードする時間が長い。ビルド時間の短縮やビルド済みイメージの使用が有益です。	広告テクノロジーは、バイナリを独自にビルドし、提供されたハッシュを使用して検証できます。事前構築済みのアーティファクトの提供やビルド時間の短縮については、今後検討いたします。
API 機能リクエスト	ローカル開発とテストを容易にするため、入札とオークション サービス（B&A）のビルド スクリプト、コンテナ イメージ、呼び出しツールの macOS 互換性をリクエスト。	現在、amd64 をサポートしています。これは、サポートされているクラウド プラットフォーム（GCP と AWS）へのデプロイに十分です。今後、他のアーキテクチャのサポートも検討される可能性があります。
AWS	本番環境ビルドに IAM ロールを作成することは必須ですか？	はい。適切な権限とコーディネーターとの通信には IAM ロールが必要です。鍵は、こちらに記載されているように、デバイスで生成された ProtectedAudienceInput 暗号テキストの復号に使用されます。また、これらのロールは、同じコーディネーターを使用して本番環境ビルドのサーバー/TEE 構成証明に合格する必要があります。これについては、セルフサービス ガイドで詳しく説明しています。
B&A フラグ	利用可能な B&A フラグの定義をドキュメントに記載するようリクエストしています。現在、これらの定義は Terraform コード、cc ファイル、proto ファイルにありますが、広告テクノロジーは、デプロイをカスタマイズする方法を理解するための信頼できる情報源として、これらのフラグのドキュメントを活用できます。	Terraform フラグの説明をドキュメント化することを検討しており、こちらで追加のフィードバックをお待ちしております。
AWS bidding service	AWS の入札サービスと、デフォルトのロギング動作と構成に関するガイダンスを求めています。	TEE 内の入札サービス（入札サービスなど）をデバッグする場合は、広告テクノロジーの同意を得たデバッグを使用することをおすすめします。これにより、詳細なロギングを有効にして、特定のテスト リクエストのリクエスト/レスポンス データをクライアントから直接キャプチャし、デバッグに役立てることができます。
TEE K/V ドキュメント	デベロッパー サイトに記載されている TKV の適用開始について、明確な説明を求めています。	TEE の使用が必須となる場合は、事前に十分な通知をいたします。それまでは、リアルタイムの Key-Value シグナルに独自のサーバーを引き続き使用できます。
テストと分析	費用対効果が悪く、本番環境に適していない。	詳しく調査するには、費用分析と、本番環境への移行の準備状況の評価に至った要因に関する追加情報をご提供いただく必要があります。
トラステッド サーバーの最適化	コンポーネント販売者に固有のパラメータを 1 つの inputsPerSeller パラメータに統合し、その値に JSON 文字列を使用する提案。	この提案について現在検討中です。こちらから追加のフィードバックをお寄せください。
セキュリティ	B&A を使用して TKV のセキュリティ リスクを軽減する方法	TKV への外部呼び出しを防止できます。これは現在、GCP で完全にサポートされており、構成可能です。 AWS では、以前にこれを可能にしていた AWS App Mesh が非推奨になったため、追加のサポートを開発する必要があります。フィードバックはこちらからお寄せください。
B&A サービス	B&A の最適化における HTTP ストリーミングの価値に関する説明/コミュニケーションの明確化をリクエストしています。	プライバシー サンドボックスは、B&A データを転送するストリーミング機能をサポートしており、この機能を利用する広告テクノロジーのレイテンシを改善します。混合モードの場合は、パフォーマンスの最適化は省略可能です。
Prebid	エコシステムで PA API B&A 機能を有効にするために、オープンソースの Prebid ライブラリへのコントリビューションに関する最新情報をリクエストします。	2025 年 3 月、Chrome は B&A の公開ロードマップ（2025 年 3 月を参照 ）に記載されているように、Prebid 優先の最適化を Stable 版でリリースしました。
トラフィック シェーピング	B&A が受信したコンテキスト シグナルを記録するメカニズムのリクエスト。これにより、IG が有効になっているタイミングを把握し、コンテキスト レスポンスでの「入札の意図」ロジックを改善できます。これにより、ネットワーク リソースをより効率的に使用して「無駄なトラフィック」（トラフィック シェーピング）を回避できます。	現在、 こちらで提案について議論しており、追加のフィードバックをお待ちしております。
ドキュメント 明確化	B&A テスト統合のセットアップで検出された「Service/Vsock proxy is not reachable」エラーについて、明確化が必要です。	これは、最小メモリ要件が原因です。この要件を反映するように、AWS 構成の説明が更新されました。

デジタル広告の測定

Attribution Reporting（およびその他の API）

フィードバック テーマ	概要	Chrome の対応
リアルタイム データ	リアルタイム データの欠如は、業界全体に影響します。リアルタイム データの遅延は広告主にとって深刻な問題です。Google アナリティクスは、オーディエンスにリーチしたことを証明できる唯一の場所であるため、購入者は Google アナリティクスを搭載したプラットフォームに移行しています。	Attribution Reporting API（ARA）の一部であるリアルタイム データの遅延は、広告テクノロジーがイベントレベル レポートを使用してサイト間でユーザーを追跡する能力を低減するためのプライバシー保護メカニズムとして実装されています。ただし、ARA では、イベントレベル レポートのレポート期間を 1 時間以上に設定したり、集計レポートを遅延なく広告テクノロジーに即座に送信したりできるため、アトリビューション レポートの配信方法を柔軟に設定できます。
API の使用量	クロスウェブアプリ アトリビューション フローの正しい構成について確認を求める。特に、ウェブ間アトリビューションとウェブからアプリへのアトリビューションを並行して運用している場合。	ウェブからウェブとウェブからアプリのキャンペーンを同時に実施する場合、重複カウントを防ぐため、広告テクノロジーは、各ソースまたはトリガーを登録するプラットフォームを 1 つだけ選択する必要があります。ウェブソースとトリガーが正しく委任されている限り、OS はウェブ間とウェブからアプリへのアトリビューションの両方を実行できるため、可能な限りオペレーティング システム（OS）を使用することを強くおすすめします。つまり、ソースの場合は Attribution-Reporting-Register-OS-Source ヘッダーで、トリガーの場合は Attribution-Reporting-Register-OS-Trigger ヘッダーで応答します。 Attribution-Reporting-Support ヘッダーを使用すると、Chrome レベルまたは Android レベルのサポートがあるかどうかを特定できます。Attribution-Reporting-Info ヘッダーは、リクエストに Attribution-Reporting-Support ヘッダーがない場合にも役立ちます。この場合、ブラウザはユーザーのデバイスでプラットフォームがサポートされているかどうかに基づいて、プラットフォームの登録を決定します。
API の仕様	Attribution Reporting API によって設定される Attribution-Reporting-Support HTTP リクエスト ヘッダーについて、プラットフォームに関係なく、ヘッダーに web キーと os キーの両方が含まれることを意図しているかどうかの明確化を求めています。	Attribution-Reporting-Support ヘッダーには、サーバーが仕様に準拠した構造化ヘッダー パーサーを使用するように、ブラウザが「GREASE」パラメータを追加する場合があります。このヘッダーでは、構造化辞書キーのみを解釈する必要があります。値とパラメータは現在使用されていません。例については、こちらをご覧ください。
サードパーティ製のレポート	広告キャンペーンの ARA とサードパーティ トラッキング プロバイダ（3PC）の測定結果の差異のトラブルシューティング方法に関するガイダンスをリクエストしている。	ARA は、不一致のトラブルシューティングとデバッグに使用できる 2 種類のデバッグ レポートをサポートしています。アトリビューション成功デバッグ レポートを使用すると、ARA の結果と他の測定テクノロジーの結果を簡単に比較できます。詳細デバッグ レポートを使用すると、詳細情報を取得して、アトリビューション登録で発生する可能性のある問題のトラブルシューティングを行うことができます。
API 使用量	ARA のテスト中に、特定の問題が見つかりました。具体的には、レポートの詳細度が不十分でデータのノイズが多く、キャンペーンの最適化が柔軟にできない、基準額が高すぎて小規模な広告主様が除外される、主要指標が一致しないためキャンペーンを比較しにくい、といった問題です。	ARA は、広告テクノロジーが特定の測定ユースケースを実現するためにカスタマイズできる複数のパラメータを備えており、柔軟性を提供します。イベントレベル レポートは、柔軟なイベントレベル レポートをサポートしています。これにより、広告テクノロジーはレポート期間、受信できるレポート数、測定するトリガーデータをカスタマイズできます。これにより、データに対するノイズの影響を変え、さまざまなユースケースを実現できます。同様に、集計レポートでは、トラッキングするディメンションの数、バッチ処理の頻度、貢献度予算の使用方法など、広告テクノロジーで設定をカスタマイズするさまざまな方法があり、ノイズの影響を変更してさまざまなユースケースを実現できます。
API の仕様	ARA のサードパーティ プロバイダへの依存関係に関する質問。特に、これらのサードパーティ プロバイダを必要とするテストフェーズに留まっているかどうかについて。	ARA はサードパーティ Cookie とは別に有効になりますが、ARA の移行用デバッグ レポートで ARA の結果と Cookie ベースのアトリビューションの結果を比較するには、サードパーティ Cookie を有効にする必要があります。
API 使用量	ARA を使用して古い Android バージョン（11、12、13）でアプリからウェブのアトリビューションのソースを登録する方法についてお問い合わせいただいた件につきまして、ご連絡いたします。	ARA は現在、Android S 以降（12 以降）でサポートされています。
API 使用量	ARA のオプトイン率と配信の詳細をリクエストします。	回答は前四半期から変わっていません。 「この情報をエコシステムと共有する予定はありません。デベロッパーは、コードをデプロイしている API を呼び出して、プライバシー サンドボックス API の可用性を推定できます。」
API の可用性	ARA が有効になっている場合、3PC は有効か無効か	ユーザーのブラウザで ARA が有効になっていても、ユーザーの Cookie 設定には影響しません。ARA が有効で、ユーザーが Cookie を有効または無効にしている場合もあります。
レポート	[Attribution-reporting-support] ヘッダーで受け取れる値の事前定義リストはありますか？	ガイダンスに記載されているように、この値は構造化されたヘッダー ディクショナリであり、現在定義されているセマンティクスは OS キーとウェブキーの有無のみです。ヘッダーの他の部分は無視する必要があります。つまり、解析には、単純な文字列照合ではなく、構造化ヘッダー パーサーを使用する必要があります。

集計サービス

フィードバック テーマ	概要	Chrome の対応
機能のリクエスト	集計サービスの機能リクエスト: サーバー間統合、クロスデバイス測定、マルチタッチ アトリビューションと貢献度レポートの簡素化、オムニチャネル アトリビューション、高度な ML 最適化ループのサポート（プライベート モデル トレーニング）。	これらのリクエストは現在審査中です。詳細が決まり次第お知らせいたします。 これらのリクエストが優先事項であるかどうかについて、エコシステムからの追加のフィードバックをお待ちしております。
機能のリクエスト	集計サービスセットの更新時にリセットに関する懸念を軽減するため、Terraform 環境で EBS delete_on_termination パラメータを true に設定するようリクエストします。	本件については現在審査中です。詳細が決まりましたらお知らせいたします。 このリクエストが優先事項であるかどうかについて、エコシステムからこちらからフィードバックをお寄せください。
ドキュメント 明確化	変更可能な項目（モニタリングしきい値など）と変更しない項目について、ガイダンスをリクエストする。	集計サービスの利用可能なカスタマイズに関する追加のドキュメントとガイダンスの公開を検討しています。
デプロイ	bazel コマンドでの新しいデプロイの失敗に関する明確な説明をリクエストします。	デプロイが失敗する原因として、環境で使用されている Bazel のバージョンが考えられます。 ドキュメントを調整して、Terraform の失敗のデバッグと、必要な bazel バージョンを示すようにします。

Private Aggregation API

フィードバック テーマ	概要	Chrome の対応
API 使用量	共有ストレージの制限によるデータ損失の可能性、複雑な集計サービスの許可リスト（ワイルドカード推奨）を必要とする高カーディナリティの難しさ、集計サービスの「重複なし」ルールによるテストの遅延など、実装に関する課題に関するガイダンスをリクエストします。	共有ストレージの制限事項について、20 件の投稿の上限（詳しくはこちら）は 1 回の実行あたりの上限であり、1 か月あたりの上限ではありません。また、API 呼び出し元はこの上限をオーバーライドできます。この上限は、集計サービスでレポートの処理コストを管理するために設定されており、レポート ユーティリティを制限するものではありません。 ワイルドカード クエリについては、現在このリクエストを評価中です。詳細が決まり次第お知らせいたします。 「重複なし」ルールについては、テストを可能にするために、このルールを回避する目的でデバッグモードを一時的にサポートしています。詳しくは、こちら をご覧ください。
フィルタ ID とバケット	2 つの異なる集計実行で、2 つの異なるフィルタ ID を持つ同じバケットを集計サービスにリクエストすることはできますか？つまり、フィルタ ID をドメインの補足的なパーティショニングとして使用できますか？	はい、この機能はサポートされています。集計を実行すると、ジョブ パラメータのリストに一致するフィルタ ID を持つコントリビューションのみが処理され、残りは別の実行で処理できます。
マルチタッチ アトリビューション	マルチタッチ アトリビューション（MTA）の実装について、次のような質問が寄せられました。 1）集計値が 2^16 を超えない場合、貢献度の上限はありますか？ 2）特定のコンテキストに保存できる一意の集計キー（バケット）の数に上限はありますか？ 3）MTA でよくあるように、各ユーザー エージェント（ブラウザ）に一意の集計キーがある場合、集計サービスはサマリー レポートをどのように処理しますか？	1）デフォルトの拠出上限が設定されていますが、こちらで説明されているように、API 呼び出し元がオーバーライドするオプションがあります。上限の目的は、API 呼び出し元が集計サービスでレポートの処理コストを管理できるようにすることです。 2）そのような制限はありませんが、広告テクノロジーは、こちらで詳しく説明されているように、シグナル対ノイズ比を改善するために集計キーの粒度を考慮する必要があります。 3）こちらのガイダンス、特に上記の 2）に記載されているシグナル対ノイズ比のガイダンスをご覧ください。

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

User-Agent の情報量削減/User-Agent Client Hints

フィードバック テーマ	概要	Chrome の対応
機能のリクエスト	コンテンツの適応、セキュリティ、分析のために、サーバーが自動化されたトラフィックを識別できるように、User-Agent Client Hints（UA-CH）に Sec-CH-UA-Robot を追加するようリクエスト。	これは、他の標準グループで議論されている重要なユースケースです（詳しくはこちら をご覧ください）。関心をお持ちの方は、フィードバックを提供して参加することをおすすめします。ただし、HTTP リクエスト ヘッダーは自動化されたトラフィックによって簡単に操作できるため、UA-CH は適切なソリューションではないと考えています。

IP 保護（旧 Gnatcatcher）

フィードバック テーマ	概要	Chrome の対応
IP アドレスのプライバシー	IP アドレスを Google が使用できるようにすることは、Google が宣言しているプライバシー目標に反しています。Google は IP 保護によってデータを匿名化すると主張していますが、IP 保護を使用するには Chrome にログインする必要があるため、ユーザーの ID は引き続き Google に知られます。	ログインの理由は、不正行為や不正使用を防止するためであり、主にプロキシへのアクセスをレート制限しています。 さらに、認証要件のコンテキストでユーザーのプライバシーを保護するため、Google のトークンはブラインド署名されています。つまり、ログイン時に発行されたトークンはプロキシ時に使用されるトークンと異なるため、発行されたトークンを後でユーザーの Google ID にリンクすることはできません。つまり、不正行為防止のために認証が義務付けられているにもかかわらず、ユーザーのトラフィックがシークレット モードでプロキシされている場合、Google はユーザーが誰であるかを把握できません。
IP アドレスのプライバシー	IP を使用することは、間違った方向への一歩です。Cookie のようにブラウザから削除することはできず、ユーザーは Cookie と同様の透明性管理を行うことはできません。Cookie が廃止されると、業界はプライバシーよりも自衛を優先し、IP を代替ソリューションとして使用するように移行するでしょう。	プラットフォームとしての Chrome は、ウェブでのブラウジング エクスペリエンスを向上させる機能をユーザーに提供することを目的としています。シークレット モードでのブラウジングを選択した Chrome ユーザーに対しては、サードパーティのコンテキストで IP アドレス情報の利用を制限することで、クロスサイト トラッキングに対する保護を強化します。
マスクされたドメインリスト	マスクされたドメインリスト（MDL）の選択基準は何ですか？	Chrome では、MDL に登録し、サードパーティ コンテキストでマスクされた IP アドレスを受け取るドメインを特定するための基準を策定しています。Google は、他のウェブブラウザとも連携している、インターネット プライバシーのリーダーである Disconnect.me と提携しています。Chrome は Disconnect.me を利用して、Chrome の確立された基準に沿ったドメインを特定します。また、Chrome では、安定した高エントロピーのウェブ API から一貫した出力を提供する、広く使用されている JavaScript 関数を特定する手法が開発されています。この手法により、高エントロピーの確率的識別子を構築できます。これらの関数は、サードパーティのコンテキストでウェブサイトに読み込まれたときに検出されます。これにより、これらの特性を持つスクリプトを提供するドメインのリストが作成され、MDL の一部となり、プロキシされます。API の不正使用のこのようなパターンを探す検出パイプラインは、Google 独自のドメインを含むすべてのドメインを考慮します。
不正の防止	提案されている 24 時間の開示遅延と開示率がリアルタイムの不正行為検出を妨げるという、確率的開示トークン（PRT）に関するフィードバック。遅延時間を短く（1 時間遅延）し、レートを高く（少なくとも 2 桁）リクエストします。その他の提案には、リスクシグナル（VPN、自動ブラウザ）に基づく差別レートの有効化や、特定のトークンのターゲット設定された開示の許可が含まれます。	インタビューしたほとんどのデベロッパーは、顧客に 1 時間ごとのレポートを提供しており、1 日のうちに複数回 IP ブロックリストを更新しています。遅延時間を短くすると、更新頻度を高めることができます。1 時間未満にすると、1 時間ごとの統計情報で IVT 測定を再度有効にできますが、ユーザーが再識別される可能性も高まります。YouTube は、エコシステムの調査やステークホルダーからのフィードバックに基づいて、遅延期間の短縮や公開率の変更を検討しています。こちらからフィードバックをお寄せください。
マスクされたドメインリスト	広告のユースケースがないにもかかわらず、ドメインが MDL に登録されていることに関する質問。これにより「IP ブリッジング」が有効になり、IP アドレスに基づいてプロファイルが作成される可能性があるという懸念。	YouTube は、リストベースのアプローチに対して再審査請求プロセスを実装することの重要性を認識しています。再審査請求により、企業は MDL に登録されているドメインが除外基準を満たしておらず、削除されるべきであると主張できます。これにより、そのドメインは引き続き、シークレット モードのサードパーティ コンテキストでユーザーの元の IP アドレスを受信できます。 Chrome Stable のシークレット モードでの IP 保護のリリースに先立ち、ドメイン所有者が再審査請求を申請し、決定を受け取るのに十分な時間を確保できるよう、再審査請求プロセスを開始しました。 再審査請求プロセスについて詳しくは、こちらをご覧ください。
マスクされたドメインリスト	パブリッシャーが、パートナーが MDL に含まれることの影響を調査しているというフィードバック。IP 保護に関する説明の GeoIP に関する規定により安心した。	Chrome は、位置情報に基づくユースケースをサポートすることの重要性を認識しています。プロキシは、ユーザーの大まかな位置情報（国など）を表す IP アドレスを割り当てます。詳しくは、IP 位置情報の説明をご覧ください。
マスクされたドメインリスト	MDL に関する質問: 国レベルのターゲティングは引き続き利用可能かどうか。	Chrome は、位置情報ベースのユースケースをサポートすることの重要性を認識しています。プロキシは、ユーザーの大まかな位置情報（国など）を表す IP アドレスを割り当てます。詳しくは、IP 位置情報の説明をご覧ください。
不正行為の検出	IP 保護が不正検出システムに与える影響に関する懸念。ユーザーにはプロキシ IP とヘッダーのどちらが表示されますか？特定の使用に対して、SSP と DSP に同じプロキシ IP アドレスが表示されますか？不整合があると、不正行為の検出や OpenRTB に影響する可能性があります。	IP 保護を有効にしてシークレット モードでブラウジングしているユーザーが MDL 上のドメインにリクエストを送信すると、定義されたジオフィードに基づいてプロキシ IP アドレスが送信されます。組織は、プロキシされたトラフィックで PRT を追加ヘッダーとして渡すようにリクエストできます。この場合、遅延期間の後に元の IP の小さなサンプルが公開されます。多くの SSP は、サーバーサイド入札リクエストでプロキシされた IP アドレスをデマンド パートナーに渡すと思われますが、落札した DSP がインプレッション時に同じプロキシ IP アドレスを認識するとは限りません。
不正行為の検出	IP 位置情報ファイルの更新頻度、不正行為や PRT の報告に関する詳細の更新タイミング、広告テクノロジーで不正行為を検出する方法に関する質問。	PRT の説明は公開されています。プロキシ IP アドレスとそのマッピングされた地域のリストも公開されています。IP アドレスは時間の経過とともにローテーションされるため、このファイルを定期的にチェックして更新や変更を確認することをおすすめします。不正行為を報告するための公開メールアドレスは、リリースが近づいたらお知らせします。
位置情報	プロキシに使用される IP アドレスのパブリック リストのリクエスト。	IP 保護のために IP アドレスを大まかなロケーションにマッピングするファイルは、こちらから入手できます。このファイルは定期的に更新されます。
API 使用量	IP 保護がデフォルトでオンになっているように見え、ユーザーがオプトアウトするオプションが提供されていないという主張。	IP 保護は、Android とパソコンのプラットフォームで Chrome のシークレット モードを使用しているユーザーが利用できます。ユーザーは IP 保護を無効にできます。企業で管理されているバージョンの Chrome では、IP 保護を有効にできますが、デフォルトではオフになっています。
API 使用量	Chrome Canary と Chrome Beta リリースで IP 保護を有効にしてテストするための試験運用版フラグの提供状況に関するお問い合わせ。	現在、IP 保護機能全体をテストするための試験運用版フラグはありません。実施している機能テストでは、Google ドメインに送信されるプロキシ トラフィックのみを対象としています。
IP アドレスのプライバシー	ブラウザがシークレット モードに移行した場合、サードパーティ Cookie プロンプトの設定はどのように機能しますか？	シークレット モードでは、サードパーティ Cookie はデフォルトでブロックされます。
シークレット モード	ユーザーが Chrome にログインしていない場合、シークレット モードで IP 保護機能が機能するかどうかについて、明確にしてください。	ユーザーがシークレット モードを起動する前に Chrome にログインしていない場合、IP 保護は有効になりません。これは、不正行為や不正使用を防止するため、プロキシへのアクセスをレート制限するためです。IP Protection は、クライアント認証を使用して、不正な行為者がプロキシを悪用して MDL 上のサービスに対する攻撃を増幅する能力を制限します。そのため、IP 保護は、新しいシークレット ウィンドウを開く前に Chrome ブラウザでログインしている Google アカウントを使用して認証されたユーザーのみが利用できます。
シークレット モード	リリース前に IP 保護の影響を評価するためのリクエスト: （1）ブラウザの状態フラグまたは API レポートの集計を使用して、シークレット モードの使用状況を定量化することを提案。 （2）機能を有効にする前に一定期間 IP 保護ヘッダーを送信。 （3）推定のために、トラフィックのごく一部に機能をリリースする。	Google は、IP 保護の規模と影響を理解し、測定できるエコシステムのニーズを理解しています。ただし、Chrome は、ユーザーがシークレット モードでブラウジングすることを選択した場合、そのブラウジングが非公開になるように機能します。Chrome には、シークレット モードでブラウジングしているユーザーを検出するメソッドは公開されていません。また、ユーザーのブラウジング モードを特定する可能性のある他のシグナルを制限する措置も講じています。 Google は、シークレット モードでブラウジングするユーザーのプライバシーに影響を与えることなく、このテストを容易にする方法を検討しています。エコシステムからさらにフィードバックをお寄せいただければ幸いです。

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

フィードバック テーマ	概要	Chrome の対応
コンプライアンス	Google が、データ保護法に準拠したバウンス トラッキング緩和（BTM）手法の使用を許可しないことには法的根拠がなく、プライバシー サンドボックスの再審査請求プロセスが無意味になります。	前回のフィードバック レポートでお伝えしたとおり、コンプライアンス ステータスは BTM の適用とは関係ありません。また、Google は BTM の実装におけるコンプライアンスに関していかなる決定も行いません。BTM は、他の Chrome プライバシー保護機能と同様に、データの共有の可否と方法をユーザーがより細かく管理できるようにすることに重点を置いています。 CMA の第 2 四半期/第 3 四半期レポートで言及されている第三者管理の再審査請求プロセスは、Google が個々の企業のリストへの掲載または除外について判断している地域に固有のプロセスです。
コンプライアンス	GDPR のコンテキストで、ブラウザがユーザーが明示的に同意したアクション（リダイレクトや Cookie の設定など）を抑制し、法的同意とブラウザのプライバシー設定の間に矛盾が生じるシナリオをハイライトする、ブラウザが法的同意を得たアクションに準拠する方法に関するディスカッション。	ブラウザは、ユーザーとウェブサイトの関係の性質を把握できません。また、現在の BTM の動作では、ユーザーが特定のサイトからの離脱トラッキングに明示的に同意するための回避策がすでに存在します。 コンプライアンスに関する詳細については、プライバシー関連のコンプライアンスに関するよくある質問をご覧ください。
二重使用サイト	WebView またはアプリからウェブ（Chrome）への遷移が BTM で「二重使用サイト」と見なされるかどうかについて、明確にしたい。	ブラウザでは、バウンス チェーンが WebView からの遷移で始まったのか、アプリからの遷移で始まったのかを把握できません。 そのため、BTM では、そのようなフローは特別な処理を受けません。代わりに、このフローは「about:blank」から始まるクロスサイト バウンスとして解釈され、標準の動作が続行されます。

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

関連ウェブサイト セット（旧称: ファーストパーティ セット）

フィードバック テーマ	概要	Chrome の対応
API 使用量	IP 保護と組み合わせた RWS の不正使用の可能性に関する懸念。RWS セット内の組織に IP アドレスを公開すると、組織が複数の RWS セットに参加して、持ち運び可能な IP アドレスデータにアクセスし、シークレット ユーザーを追跡するインセンティブが生じます。	関連サイト、サービスサイト、セット全体に設定された要件は、自動検証によって適用され、複数のセットへの参加を試みる動機を軽減します。 IP アドレスを介してセット間でユーザー アクティビティを結合するには、セットに MDL ドメインを含める必要があります。これを行うには、セット オーナーとドメイン オーナーの調整が必要です。このリスクは、MDL ドメインと連携する単一サイト（RWS が関与していないサイト）にも適用されます。 この質問について詳しくは、こちらをご覧ください。

Fenced Frames API

フィードバック テーマ	概要	Chrome の対応
ネイティブ広告	フェンスド フレームの現在の設計では、広告を周囲のコンテンツに合わせて柔軟に調整する必要があるネイティブ広告のビジネスモデルに対応していないというフィードバック。	Google は、エコシステムのニーズと現在の Fenced Frames の提供内容の評価を継続しています。いずれにしても、前述のとおり、フェンスド フレームは 2026 年以降に必須となります。

Shared Storage API

フィードバック テーマ	概要	Chrome の対応
API バグ	Shared Storage API の予算化メカニズムによって selectURL オペレーションの実行が妨げられた場合、Chrome でエラーがログに記録されることが報告されています。これは想定内の動作です。エラーは呼び出し元が対処できないため、Chrome にロギング レベルをエラーから警告または情報にダウングレードするようリクエストします。	この変更は Chrome M134 に実装されており、2025 年 3 月 4 日より利用可能になっています。

CHIPS

フィードバック テーマ	概要	Chrome の対応
API ドキュメント	パーティショニング Cookie が提供するセキュリティ保護が、SameSite=Lax/Strict Cookie と比較してどのように異なるかについて、明確にする必要があります。パーティショニングされた Cookie は、SameSite=Lax/Strict Cookie と同じレベルの XSS 攻撃と CSRF 攻撃からの保護を提供しないことを、ドキュメントに明記することを提案。	パーティション化された Cookie が提供するセマンティクスと保護機能を明確にするため、説明と仕様を更新します。

FedCM

フィードバック テーマ	概要	Chrome の対応
UI とセキュリティ	FedCM の UI が Google の以前のワンタップ ログインと類似しすぎている、パッシブ プレゼンテーション トラッキングがないため FedCM のパフォーマンスを定量化するのが難しい、PKCE に関するドキュメントの表現をより明確にすることをおすすめする、などのフィードバックが寄せられています。	Google は、関係者からのフィードバックに対応するため、積極的に取り組んでいます。現在検討中の内容には、IDP が FedCM のパフォーマンスをトラッキングできるように、より優れた指標を提供する方法や、サブスクリプションのユースケースに関する FedCM の新しいユースケースに対応するための機能強化が含まれます。
API 使用量	ユーザーがページを更新して navigator.credentials.get を呼び出してログインすると、ポップアップ ウィンドウが表示され、ユーザーがクリックして続行する必要があります。これにより、ユーザー エクスペリエンスに影響する遅延が発生します。信頼できる当事者（RP）は、navigator.credentials.get によって返されたトークンをキャッシュに保存して、ユーザー エクスペリエンスを改善できますか？	RP は独自の Cookie を使用してトークンを保存できます。RP は、navigator.credentials.get を呼び出す前に、独自の Cookie をチェックしてユーザーがログインしているかどうかを判断できます。詳しくは、こちらをご覧ください。
複数の IDP の選択	ブラウザは、FedCM で複数の ID プロバイダ（IdP）のログイン オプションをどのように表示しますか？	複数の IdP の表示方法については、デベロッパー向けドキュメントをご覧ください。関係者は、chrome://flags で fedcm-multi-idp フラグを有効にすることで、この機能をテストできます。
ブラウザと IdP	Chrome などのブラウザが IdP として機能することは可能ですか？ブラウザは、保存されているアカウント データとプロファイル データを信頼できる認証ソースとして使用できます。	ブラウザは（拡張機能などによって）変更できるため、ブラウザによって直接行われたメール確認の申し立ては、追加のサーバーベースの確認なしでは信頼できません。そのため、純粋にクライアント ベースのソリューションはおすすめしません。 この問題について詳しくは、こちらをご覧ください。
API の仕様	IdentityCredential.disconnect() アルゴリズムのパラメータを必須にするのか、省略可能にするのかについて議論しています。	この問題は解決済みです。詳しくはこちらをご覧ください。
API セキュリティ	RP に XSS の脆弱性がある場合、FedCM ログイン プロセスでトークンが漏洩する可能性がある。攻撃者は、悪意のあるコードで navigator.credentials.get を実行してトークンを取得する可能性があります。	FedCM は新しい XSS リスクを生み出すものではありません。これらのリスクは、ウェブ アプリケーションと既存の認証プロトコルに固有のものです。こうしたリスクを軽減するには、RP は ID トークンの aud クレームを確認し、独自のオリジンで発行されたアサーションをのみ受け入れる必要があります。こちらで説明されているように、現在、このトークン交換を保護するためのベスト プラクティスが広く確立されており、FedCM で使用できます。 さらに、Storage Access API は FedCM で使用できます。また、FedCM 呼び出しが先行すると、Storage Access API 呼び出しが自動的に許可されます。これにより、GitHub の問題で説明されている埋め込みリダイレクト フローが有効になります。
API の仕様	client_metadata_endpoint は、FedCM の config エンドポイント レスポンスの必須フィールドです。空のオブジェクトは有効なレスポンスであり、Chromium は 404 レスポンスを黙って無視します。これは、エンドポイントが実際には省略可能として扱われていることを示しています。	これを反映して仕様を変更し、client_metadata_endpoint をオプション フィールドにすることは妥当であると考えます。
API 使用量	DOM からアクセスできないブラウザ制御のユーザー インターフェースが原因で、FedCM の実装をテストするのが難しいという懸念。	リグレッション テストでは、これらの懸念事項に対処できるブラウザ自動化 API がサポートされています。これらの API については、こちらをご覧ください。
API の仕様	config エンドポイントのレスポンスの必須部分である login_url パラメータが、仕様のセクション 3.2 に記載されていませんでした。	ドキュメントの 3.2 セクションに login_url パラメータを追加する更新を送信しました。
API 仕様	FedCM の潜在的なトラッキング ベクトルに関する懸念。IdP は、構成エンドポイント レスポンスで指定されたエンドポイント（accounts_endpoint、client_metadata_endpoint）に ID をパス パラメータとして挿入し、これらの ID を使用してアカウント リクエストとクライアント メタデータ リクエストを関連付けることができます。	こうしたエンドポイントに ID が挿入されているという証拠は見つかっていませんが、こちらでこの問題に対処するための緩和策を積極的に検討しています。

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

Private State Tokens API（および他の API）

今四半期にフィードバックはありませんでした。