このページは Cloud Translation API によって翻訳されました。

フィードバックレポート - 2024 年第 1 四半期
bookmark_border コレクションでコンテンツを整理必要に応じて、コンテンツの保存と分類を行います。

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

Google は CMA との約束の一環として、プライバシーサンドボックスの提案に関するステークホルダーのエンゲージメントプロセスについて、四半期ごとに公開レポートを提供することに同意しています（約束の第 12 項と第 17 項（c）（ii）を参照）。これらのプライバシーサンドボックスのフィードバック概要レポートは、フィードバックの概要に記載されているさまざまなソース（GitHub の問題、privacysandbox.com で公開されているフィードバックフォーム、業界関係者とのミーティング、ウェブ標準フォーラムなど）から Chrome が受け取ったフィードバックを集計して生成されます。Chrome はエコシステムから寄せられたフィードバックを歓迎し、学んだことを設計上の意思決定に統合する方法を積極的に模索しています。

フィードバックテーマは、API ごとの発生頻度でランク付けされます。これは、特定のテーマについて Chrome チームが受け取ったフィードバックの量を集計し、量の降順で整理することで行われます。一般公開のミーティング（W3C、PatCG、IETF）、直接のフィードバック、GitHub、Google の社内チームと公開フォームから寄せられたよくある質問の議論のトピックを確認することで、一般的なフィードバックテーマを特定しました。

具体的には、ウェブ標準団体の会議の議事録が確認され、直接的なフィードバックについては、Google のステークホルダーとの 1 対 1 の会議の記録、個々のエンジニアが受け取ったメール、API メーリングリスト、一般公開のフィードバックフォームが検討されました。Google は、これらのさまざまなアウトリーチアクティビティに関与するチーム間で調整を行い、各 API に関連して浮上したテーマの相対的な普及度を判断しました。

Chrome のフィードバックへの対応に関する説明は、公開されているよくある質問、関係者から寄せられた問題に対する実際の回答、およびこの公開レポートの目的のために特別に決定された立場に基づいて作成されています。現在の開発とテストの重点を反映して、特に Topics API、Protected Audience API、Attribution Reporting API に関する質問とフィードバックが寄せられました。

現在のレポート期間の終了後に受信したフィードバックには、Chrome の回答がまだ考慮されていない場合があります。

頭字語の用語集

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

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

フィードバックテーマ	概要	Chrome の対応
ガバナンス	プライバシーサンドボックスのガバナンスに関する更新に関する公開コメント期間への関心	Google は、プライバシーサンドボックスの今後のガバナンスなど、プライバシーサンドボックスに関する重要な進展について、関係者からの合理的なフィードバックを受け付けています。
テスト	現在の 1% の Chrome 主導のテストに加えて、3PCD の追加のテストフェーズ。	Google は、1 月上旬から有効になっている Chrome トラフィックの 1%を超える Chrome 主導のテストを提供する予定はありません。
Web to App	ウェブとアプリの完全な相互運用性が実現される前に、モバイルデバイスで 3PCD を実施することはできません。	Google は、アプリとウェブの相互運用性をサポートすることが望ましいことに同意しており、アプリとウェブにわたるアトリビューション測定を開始し、ウェブからアプリへのターゲティングソリューションを検討しています。ただし、モバイルウェブでの 3PCD のリリースを遅らせる予定はありません。3PCD の終了時点で 100% のカバレッジを達成するという目標はありません。むしろ、Android では、クロスアプリとウェブの測定における互換性が 3PCD でかなり高く、ユーザーがスマートフォンを更新するにつれてさらに高くなると予想されます。
ブラウザのロール	Chrome が広告サーバーまたは SSP の役割を担っているようです。	Chrome は広告サーバーや SSP の役割を担うことはありません。PA API により、Chrome は広告サーバー、SSP、DSP などの広告テクノロジーが独自の入札ロジックとスコアリングロジックを組み込むためのコンテナを提供しています。
ユースケースのガイダンス	プライバシーサンドボックス API でサポートされるユースケースに関する明確なガイダンス。	プライバシーサンドボックスプロジェクトの開始当初、デベロッパー向けドキュメントは主に、すべての提案に関するディスカッションとフィードバックプロセスにデベロッパーを参加させることに重点を置いていました。そのため、コンテンツは通常、プロジェクトの背景にある動機とコンセプトの理解を中心に構成され、その後に各プロポーザルの初期開発とテストの詳細が記載されていました。これは、プロポーザルの開発において、エコシステムの実際のコラボレーションを構築するうえで効果的でした。しかし、API が一般提供に移行するにつれて、API の基盤となる開発に貢献するのではなく、API をベースに開発を行うデベロッパーが新たに登場しました。 Google は最近、プライバシーサンドボックスのデベロッパーサイトのナビゲーションを更新し、ユースケースに焦点を当てた構成に変更しました。この際、IAB Tech Lab の最近のプライバシーサンドボックスタスクフォースレポートで使用されているカテゴリに似たカテゴリを使用しています。ドキュメントに対するユースケースベースのアプローチは、今後も継続されます。
ローカル開発環境	Cookie が SameSite=Secure で、バックエンドが CDN で保護されている場合、http://localhost でフロントエンドの開発とテストを継続するにはどうすればよいですか？	この問題についてはこちらで議論しており、エコシステムからの追加のフィードバックをお待ちしております。
3PCD の緩和策	サードパーティ Cookie がブロックされているか、ヒューリスティクスが有効になっているかをプログラムで確認する方法はありますか？	Chrome では、機能検出と iframe 内で呼び出される document.hasStorageAccess の両方を使用して、iframe 内のオリジンが 3PC にアクセスできるかどうかをデベロッパーが確認できます。
動画テスト	現在、プライバシーサンドボックスで動画広告をテストすることはできません。	Chrome では、PA API で動画を実現できるいくつかの方法に関するディスカッションとデモを公開しました（GitHub のデモリポジトリの 242 と 254 をご覧ください）。なお、これらのコードは、広告テクノロジーがそのまま採用するサンプルコードではなく、PA API による VAST 動画レンダリングをサポートできる手法の概念実証とデモを目的としています。この議論の過程で、動画レンダリングはすでに可能であるものの、Chrome で PA API による実装を簡素化できる変更があることも明らかになりました。たとえば、サードパーティ広告検証ツールのブランドセーフティのユースケースに関するフィードバックに基づいてすでに対応を計画していたマクロ置換（こちらで説明）の更新は、購入者がレンダリングに使用する販売者マクロを探している動画のユースケースのフィードバックにも対応します。これまでの議論のほとんどは、VAST 動画広告のレンダリングに焦点を当てていました。ネイティブ広告のレンダリングでは、同じアプローチを使用できますが、多くの点で簡単です。現在、ネイティブ広告は動画広告よりも注目を集めていないようですが、これは広告技術業界の優先順位の問題であり、実装に関する技術的な障壁ではありません。
広告以外の測定	3PCD は、広告に関連しないオーディエンス測定ソリューションに影響する可能性があります。	測定 API では、ユースケースが広告関連である必要はありません。 ARA は一般的な広告経路に特化していますが、限定公開集計は汎用性があります。これらの 2 つの構成要素を使用して、幅広い測定アクティビティに対応できます。
コンテンツクリエイター	プライバシーサンドボックスは、コンテンツクリエイターが YouTube 向けのコンテンツをより多く作成し、自身のサイト向けのコンテンツをより少なく作成するよう促すように設計されています。	プライバシーサンドボックスイニシアチブは、オープンで自由なインターネットにおいて、ユーザーの行動のプライバシーを守ることに重点を置いています。Google は、パブリッシャー様が広告収入を頼りにコンテンツを制作し、できるだけ幅広く配信していることを理解しています。広告主は、ユーザーが興味を持つ可能性のある新しい商品や特典を見つけられるようにします。プライバシーサンドボックス機能を使用すると、コンテンツクリエイターと連携しているサイトを含むあらゆる種類のウェブサイトが、ユーザーの ID を第三者に開示することなく、ユーザーのさまざまな関係者とのアクティビティに基づいて有用な広告を表示できます。
より明確なタイムライン	プライバシーサンドボックステクノロジーのリリーススケジュールをより明確かつ詳細に示します。	プライバシーサンドボックス API のドキュメントには、API のステータスと提供状況のページが含まれています。これらのページには、今後の機能とそのタイムライン（ PA API、 ARA など）が記載されています。これらのステータスの一元的なビューはこちらにあります。
機械学習	3PCD が 1% を超えるまで、広告テクノロジーは機械学習モデルを適切にトレーニングできません。	3PCD をテスト用にさらに多くのブラウザに拡大しても、API の使用量が増えるとは限りません。これは、広告テクノロジーが機械学習モデルのさらなるトレーニングのために求めていることです。広告テクノロジーが機械学習モデルのさらなるトレーニングのためにエコシステムのより広範な使用を求めていない場合、3PCD を拡大する理由はありません。より多くのトラフィックでモデルをトレーニングしたい広告テクノロジーは、3PCD を増やすことなく、現在でもそうすることができます。これは、Chrome がスタンドスティルの終了前に 3PCD で前進しているように見えることなく行うことができます。
サポートされていないユースケース	セルフサービス DSP のユースケースは現在検討されていません。	複数のセルフサービス DSP が、API に関するフィードバックを定期的に公開しています。定期的に一般公開のフィードバックを提供する DSP のいくつかは、テスターとして登録されています。さらに、Chrome は、動画やサードパーティ広告サーバーなど、一般的なセルフサービス DSP のトピックにも積極的に取り組んでいます。これらのトピックは、最近の週次 PA API 呼び出しで取り上げられています。
オリジントライアル	3PCD のより積極的な導入とテスト範囲拡大を希望するサイトに対して OT をリクエストします。	現在 Chrome では、オリジンがサードパーティ Cookie の廃止動作をオプトインできるファーストパーティ OT を開発しています。このトライアルに登録してトークンをデプロイする最上位オリジンでは、ユーザーのデバイスでトラッキング保護が有効になっている場合と同様に、3PC がブロックされます。この OT は、CMA との協議の後に予定されているサードパーティ Cookie の段階的な廃止に先立ち、サイトがサードパーティ Cookie に代わる長期的な代替手段を幅広くテストする貴重な機会となります。 OT のリリースのタイムラインは現在調整中です。
IAB Tech Lab レポート	IAB Tech Lab レポートから寄せられたプライバシーサンドボックスに関するフィードバック。	IAB Tech Lab の報告に対して Google が行った回答は、こちらで詳しく説明しています。また、Google は「この報告では、断片的なドキュメント、商業的な要件、第三者監査、業界認定、スケーラビリティ、透明性、今後のガバナンスに関する疑問が提起されている。Google はエコシステムと連携し、公開されているよくある質問を適宜更新する」と認めました。分散したドキュメントについて以前に説明しました。商用要件については、こちらの「データ保証」で説明しています。また、一部の Google 広告サービスでは、そのアプローチを共有しています。第三者機関による監査については、こちらの「アルゴリズムの完全性保証」をご覧ください。認定に関して、これらの機関は、技術そのものではなく、技術の使用を含む製品の認定を継続することが期待されます。スケーラビリティについては、問題を示すデベロッパーからのデータを引き続き受け付けています。透明性とガバナンスについては、GitHub や W3C などのフォーラムでオープンに開発を進め、CMA とのコミットメントに基づいて連携しています。
Google ログイン	Google ログインを使用すると、Google がコミットメントに反して、複数の ID のログインデータを使用できる可能性があります。	Google は、Google へのログインによって、コミットメントに反するデータを使用することはできません。
互換性	プライバシーサンドボックス API のサポートと上位互換性 / 下位互換性に関する計画はどのようなものですか？	Chrome で一般提供が開始された機能は、引き続きサポートされる予定です。ただし、下位互換性を維持できない場合もあります。そのような場合は、既存の機能の非推奨化と削除について明確なプロセスが定められています（こちらをご覧ください）。サポートの強化が望まれるユースケースに関するエコシステムからのフィードバックに応じて、プライバシーサンドボックス API に今後も機能を追加していく予定です。このような場合、Google はなんらかの機能検出手法を含める傾向があります。これにより、新しい機能をテストすることに関心のある広告テクノロジーが、その機能がサポートされているかどうかをブラウザに直接尋ねることができます。一部の機能は Chrome のすべてのユーザーに同時にリリースされない可能性があるため、特定の Chrome バージョン番号を確認するようデベロッパーに依頼するよりも、この方法のほうが適しています。たとえば、PA API の特徴検出機能については、こちらをご覧ください。
サーバーの実装	Chrome は、独自の実装に結合するのではなく、信頼シグナルサーバー、集約サーバー、その他の必要なブラウザ以外のコンポーネントの適切な実装が満たす必要がある動作を指定する必要があります。これにより、許容されるプライバシーの範囲内でイノベーションを実現できます。	Google は、外部関係者によるイノベーションの推進を歓迎しています。Google は、すべての API とサービスにおいて、広告テクノロジーが機能を柔軟に実装できるようにすることを目指しています。たとえば、広告テクノロジーがオークションの入札ロジックを設計する際に機密のビジネス情報を使用することを許可しています。また、Google は広告テクノロジーからのフィードバックを継続的に確認し、妥当な場合は設計に組み込んでいます。高信頼実行環境で独自のコードを実行できるようにするには、プライバシーサンドボックスでコード（および変更内容）を確認し、プライバシー保証を満たしていることを確認する必要があります。これには、プライバシーサンドボックスチームによる多大な労力が必要になります。そのため、ステークホルダーが Google から得たいメリットを把握し、現在 Google が提供できていないメリットを把握したいと考えています。
ヒューリスティック	ヒューリスティックの長期的な計画	他のブラウザが示唆しているように、代替ソリューションが広く使用されるようになると、Google はこれらのヒューリスティクスを最終的に廃止する予定です。ただし、今後の実現可能性分析を条件とします。詳しくは、こちらをご覧ください。
テストボリューム	異なるディメンションを比較すると、トラフィック量が異なる。	1% テストには除外条件があり、Chrome クライアントの異なるグループ間でテストの対象となるかどうかが異なります。たとえば、このテストでは Chrome Enterprise ユーザーは除外されるため、週末にはテストラベルが付いたトラフィックの割合が高くなることが予想されます。データスライス（地域、日付、プラットフォームなど）によってトラフィックの割合が異なるのは想定内であり、これは Chrome のデータでも同様です。
3PC を手動で再有効にする	3PCD の適用後に Cookie を手動で再度有効にしたユーザーの割合（%）をサイトは把握できますか？	ユーザーは、不具合が発生した場合に、ユーザーバイパスを使用してサイトレベルでサードパーティ Cookie のアクセスを再度有効にできます。3PC は、Storage Access API などの他の手段で再度有効にすることもできます。hasStorageAccess() などの技術的な対策により、サイトは 3PC が有効か無効かを検出できます。ただし、Chrome では、ウェブサイトが再有効化の理由を把握できるようにする方法は提供されません。
トラッキング防止機能	Chrome のトラッキングプロテクション UI 機能はいつまで利用できますか？	アドレスバーのトラッキング保護 UI は、3PC のサポート終了後も引き続き使用できる予定です。
（前四半期にも報告）クロスブラウザサポート	プライバシーサンドボックス API を採用している他のブラウザベンダー。	Apple、Mozilla、Microsoft などの他のブラウザベンダーは、プライバシー原則とブラウザベースのアプローチについて議論されている公開フォーラムで積極的に活動しています。先日の W3C 年次 TPAC ミーティングや、現在進行中の W3C PATCG フォーラムなど、フォーラムでのコラボレーションによる議論は、コンバージェンスの兆候を示しており、Google はこれを歓迎しています。たとえば、Microsoft Edge は最近、PA API と ARA との「構文の互換性を最大限に高めることを目的とした」計画を発表し、デベロッパー向けの追加機能も提供しています。
3PCD 以降の互換性のない埋め込みのフォールバックオプション	サードパーティの iframe / 埋め込みが 3PCD に準拠しているかどうかを検出するための API フックを提供します。	このリクエストについてはこちらで議論しており、エコシステムからのフィードバックもお待ちしております。
テスト	カスタマイズされた動作を一時的に無効にするフラグを、管理対象の Chrome インスタンスに追加するようリクエストします。	Google では、Chrome の管理対象インスタンスに対するこのリクエストを検討しており、このようなフラグが有用と思われる場合は、エコシステムからの追加のフィードバックをお待ちしております。

登録と構成証明

フィードバックテーマ	概要	Chrome の対応
証明書検証	Google はどのようにして構成証明の真正性を確保しますか？	すべての登録者は、API の使用中は証明書ファイルを所定の場所に保持する必要があります。Google は、ファイルが存在し、構文が正しいことを検証しますが、構成証明言語に関する広告テクノロジーの動作を検証することはありません。
Private Aggregation API の登録プロセス	Private Aggregation API の登録ステータスを確認する方法はありますか？	登録が承認されると、登録サポートチームから登録が確認されたことを知らせるメールが届きます。登録手続き中に登録者に質問があった場合は、サポートチーム（登録フォームの送信時に連絡先が提供されます）にお問い合わせいただけます。サポートチームが返信し、質問に回答し、必要な追加のガイダンスを提供します。

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

トピック

フィードバックテーマ	概要	Chrome の対応
（前四半期にも報告）分類システムのタイムラインとドキュメント	分類を確認するメカニズムや、少なくとも分類モードでカテゴリを決定する方法の透明性を高めるメカニズムが必要です。	回答は前四半期から変わっていません。「サイトの誤分類により、トピックシグナルの全体的な有用性が若干低下する可能性がありますが、誤分類された特定のサイトが他のサイトよりも損害を受けることはありません。これは、サイトのオークションではサイトのコンテキスト情報が常に利用可能であり、誤分類された場合でも、正しいトピックと同等の情報が提供されるためです。この件についてご意見がございましたら、こちらからお知らせください。」
Google アドマネージャー	Google アドマネージャーはすでにほとんどのサイトに埋め込まれており、サイトに掲載されている競合他社よりも、ユーザーのトピックに関する情報がはるかに広範にわたります。	オブザーバビリティの要件は、Topics API が置き換える技術（サードパーティ Cookie を含む）よりも多くのエンティティでユーザーデータが共有されないようにするためのものです。Prebid などの他の業界ソリューションは、数千ものサイトに対応しており、市場参加者は自社のテクノロジーを通じて Topics API を呼び出すことができます。また、週に 5 つのトピックまでという上限は、3PC を使用して 5 つを超えるトピックを学習できる可能性のある、多くのサイトに存在する市場参加者の機会を均等にするという効果もあります。
（前四半期にも報告）さまざまなタイプの関係者にとっての有用性	トラフィックのレベルやコンテンツの専門性によって、サイトが創出する価値とその価値の分配に関する懸念。	専門的なサイトは、一般的な興味 / 関心のドメインよりも詳細なトピックに貢献する可能性が高いことを認識しています。ただし、専門サイトのすべてが商業的に価値のあるトピックを提供しているわけではありません。また、この動向は現状を反映したものであり、Chrome での 3PC のサポート終了とはまったく無関係です。また、現在の環境でも、サードパーティ Cookie ベースの広告関連性システムにおいて、サイトによって価値に差異があります。また、専門サイトのトピックは相互にメリットをもたらす可能性があります。さまざまな広告主様がさまざまなトピックセットでキャンペーンを実施でき、入札ロジックは幅広いトピックで価値を把握できるためです。
ホスト名と完全な URL	ウェブサイトのホスト名に基づく分類は十分に効果的で、完全な URL と比較してプライバシーリスクを軽減できますか？	Google は、ホスト名に加えて情報の URL やページのタイトルを使用することを検討しましたが、潜在的なメリットよりもユーザーのプライバシーとセキュリティに対するリスクの方が大きいと判断しました。ユーザーのプライバシーリスクの例としては、URL やページのタイトルに含まれる機密情報がユーザーのトピックに分類されることがあります。
トピックをシグナルとして活用	Topics を他のシグナルと組み合わせる方法や、役立つ他のシグナルについて、ガイダンスをリクエストします。	広告テクノロジーソリューションは、コンテキストデータ、クリエイティブデータ、ファーストパーティデータに加えて、機械学習や、プライバシー保護に関する API からのプライバシーに配慮したシグナルなど、利用可能なすべてのツールを組み合わせることで最善の結果を得ることができます。詳しくは、こちらをご覧ください。

Protected Audience API（旧 FLEDGE）

フィードバックテーマ	概要	Chrome の対応
テストトラフィック量	テスターから、PA API オークションの入札レスポンスの量が少ないとの報告が寄せられています。	1. 入札単価密度は、PA API のエコシステム参加と相関しており、2024 年以降も引き続き増加すると予想されます。キャンペーン予算の割り当て方法は、最終的には広告主、広告代理店、テクノロジープロバイダが決定します。一部のエコシステム参加者は、3PCD 後まで、PA API を含むさまざまな「Cookie を使用しない」ソリューションへの投資を遅らせる可能性があります。そのようなソリューションへのキャンペーン予算の割り当てを増やす可能性があります。 2. PA API オークションでの入札リクエスト数は、（1）によって影響を受ける可能性があります。パブリッシャーとその広告テクノロジープロバイダは、需要が低いと判断した場合、PA API オークションを開始しない場合があります。ページの更新と参加の優先順位は、パブリッシャーが判断してください。パブリッシャー様は、こうした理由から、テストに時間をかけてトラフィックを段階的に増やしていくことを想定しています。このレポートには、PA API への参加に関するパブリッシャーの管理機能について、Google アドマネージャーからの回答も含まれています。
（前四半期にも報告）不正行為 / 不正使用	エコシステムは、リスクを軽減し、不正な行為者や購入者が望ましいオーディエンスとしてポジショニングするのを防ぐにはどうすればよいでしょうか。	PA API 広告のレポートメカニズムでは、現在人間と bot のトラフィックを区別するために使用されている情報が保持されます。さらに、ドメインの追加または除外に関する現在のドメインベースの手法は、PA API で使用できます。詳しくは、IAB Tech Lab のプライバシーサンドボックスに関するレポートに対するGoogle の回答をご覧ください。
IG オーナーと入札ロジック URL に対する同一オリジンの制限	同一オリジンの要件により、IG 所有者のエンドポイントは同じロードバランサを経由することになり、リダイレクトが拒否される可能性があります。	スクリプトの読み込みに対する同一オリジンの要件は、重要なセキュリティ保護対策です。エコシステムからのフィードバックとその他の考慮事項のバランスを取りながら提案されているソリューションの詳細については、こちらをご覧ください。
マルチスロットプライベートオークション	ノイズを使用したり、広告の現在の手法とより緊密に統合したりすることで、プライバシーの境界内でマルチスロットプライベートオークションを許可する余地は十分にあります。	Google は、このフィードバックを検討し、この機能に関連する複雑性の増加とプライバシーリスクを考慮して、マルチタグオークションのリクエストを評価しています。この問題については、こちらの PA API Web Incubator Community Group（WICG）のコールでも詳しく説明しています。
トップレベルの販売者	PA API の現在の構造では、トップレベルの販売者は、パブリッシャーやコンポーネント販売者よりもはるかに多くのデータと、インプレッションの相対的な価値に関する理解を得ることができます。	複数販売者オークションでは、各販売者の最高入札単価が設定されます。また、パブリッシャー様が、提携している各販売者の最適な入札単価の横に、直接販売デマンドも検討したいと考えていることが、エコシステムからわかりました。どの広告を配信するかを判断するには、これらの収益化の可能性をすべて検討する必要があります。配信する広告を選択するために、あるアクタがすべてのオプションを表示する必要があるという状況は、PA API より前のものでした。 PA API は、複数の販売者のオークションと、直接販売の広告キャンペーン（該当する場合）の横に各販売者の最高入札単価を検討したいというパブリッシャーの要望をサポートすることを目的としています。つまり、現在のように、収益化の機会の中から選択できるメカニズムが必要になります。配信する広告を選択するのはブラウザの役割ではないと判断しました。そのため、多くの可能性の中から落札広告を選択するには、最上位の販売者というコンセプトが必要になります。この最上位の販売者のロジックは、パブリッシャーが提携する各販売者の最適な入札単価を考慮できる必要があります。販売者のロジックでは、パブリッシャーの直接販売キャンペーンに関する情報が利用可能な場合は、その情報を提供することもできます。これらの情報はすべて、最上位の広告選択ロジックで考慮できます。つまり、最上位のロジックは、PA API オークションの最良の入札単価と、該当する場合はパブリッシャーの直接販売広告オプションを参照して落札者を決定します。 Google アドマネージャーでは、最上位の販売者として PA API を実装しています。この実装について詳しくは、このレポートの「情報へのアクセス」をご覧ください。
競合他社の広告の分離	競合するブランドの広告が隣り合わせに表示されないようにするなど、競合する広告の分離をリクエストする。	現在のプログラマティック入札のマルチベンダー型デジタル広告エコシステムにおいて、競争の分離を確実に行う方法は確認されていません。ただし、PA API を使用すると、クリエイティブのスコアリング時に scoreAd() で使用できる、renderURL とホスト名（パブリッシャーのドメインを表す）の組み合わせに基づいて、ベンダーが追加のリアルタイムシグナルを取得できます。販売者は、パブリッシャーがこのルールを適用することを前提として、競合するブランドの広告が隣接して表示されないようにするために、このルールを使用できます。
限定的な情報	PA API では、広告価値、コンポーネント購入者名、広告主名、ランディングページ URL、クリエイティブのサイズ、レスポンス時間、入札単価、落札しなかった入札単価など、パブリッシャーが利用できる情報が削減されます。	こちらに、考えられる解決策をいくつか提案しています。エコシステムからのフィードバックも歓迎いたします。
イベントレベルのレポート	イベントレベルレポートの PA API のサポート終了後、パブリッシャーは配信された広告に関する十分な情報を取得できなくなります。	イベントレベルレポートのサポート終了後も、引き続きサポートする必要があるさまざまなレポートのユースケースがあることは認識しています。そのため、イベントレベルレポートのサポート終了は 2026 年以降を予定しています。移行期間中は、Google がエコシステムと連携して、プライバシーを保護しながら情報を取得するための新しいアイデアなど、持続可能な今後の道筋を模索する際に、積極的にご参加ください。
複数の SSP	複数の SSP を使用するメリットがパブリッシャーにとって低すぎる。	Google は、この主張が正しいとは思っておらず、この主張の根拠を理解するために、エコシステムからの追加のフィードバックをお待ちしております。
キュレーションアクティビティ	PA API ではキュレーションアクティビティは行えません。	販売者が PA API を使用して、ウェブ全体の購入者にオーディエンス情報を提供できる機能（オーディエンス拡張）について、フィードバックが寄せられています。ビジネス契約とともに PA の委任機能を使用すれば、現在でもこのことが可能であると考えています。同時に、このようなユースケースをより適切にサポートできるかどうか、またその方法について積極的に検討しています。
購入者のオプトアウト	購入者のデフォルトのオプトアウトにより、コンポーネントオークションの成果が低下する可能性があります。	単一販売者または複数販売者の PA オークションを定義する場合にかかわらず、販売者は AuctionConfig の interestGroupBuyers フィールドに購入者を明示的にリストする必要があります。これは、販売者が一部の購入者と契約を結んでおり、他の購入者と契約を結んでいないため、オークションに含める購入者を明示的に制御する必要があるというエコシステムからのフィードバックに基づいています。 GitHub でさらにご意見をお聞かせください。
広告サイズ	adsize と adSlotSize に基づく事前フィルタリングを実行できません。	Google ではこの機能の追加に取り組んでおります。詳細については、こちらをご覧ください。
Instagram のターゲット除外のサポート	除外 IG ターゲティングをサポートする API: ユーザーが IG に属していない場合にのみ広告を表示します。	この GitHub の問題では、特定の広告リクエストに対して有効にする除外ターゲティングルールをブラウザが広告サーバーに直接指示する、除外ターゲティングの実装方法の代替案が提案されています。これは魅力的なアプローチに思えますが、Google が調査したこのアイデアのすべてのバージョンでは、サーバーがユーザーを一意に識別できるようになります。
デジタルサービス法	パブリッシャーは、フェンスドフレームを使用して、デジタルサービス法の対象となる情報を含むレスポンスのレンダリングを防ぐにはどうすればよいですか？	他の新しいテクノロジーと同様に、プライバシーサンドボックスの使用が法律に準拠していることを確認する責任は各企業にあります。Google は、法律に関する助言を提供することはできません。Google は、API ごとに詳細な技術ドキュメントを公開しています。これは、必要な法的評価を行うための基礎となるものです。フェンス付きフレームは、2026 年より前に PA API で使用する必要はありません。これにより、関係者は、この技術の使用が関連するすべての法律に準拠していることを確認するための時間を確保できます。
ドキュメント	updateAdInterestGroups() は一時的なものですか？	updateAdInterestGroup のサポート終了に関する計画は発表していません。今後、他の IG 更新メカニズムについて公表しているプライバシー保護と同様の保護を適用する場合があります。たとえば、IP アドレスをプロキシとして使用したり、更新前に一定の遅延を追加したりするなどです。
DSP 以外の購入側のメタデータとロジックの所有権のサポート	DSP のプロキシとして機能する方法のリクエスト。	DSP 以外のセグメントからのこのフィードバックは認識しており、このリクエストを検討しています。エコシステムからのフィードバックをお待ちしております。
レポート	非公開集計レポートのシグナルバケット / 値にカスタムハンドラ機能を追加するようリクエストしました。	この機能リクエストは、今後の調査のためにキューに登録されています。エコシステムからの追加のフィードバックは、こちらからお寄せください。
ドキュメント	広告主様と（委任された）所有者ドメインで設定する必要があるすべてのレスポンスヘッダーを確認できるリンクはありますか？	これを明確にするためにドキュメントの更新を予定しており、エコシステムからのフィードバックをお待ちしております。
マルチタワー入札	PA API のコンテキストでマルチタワーアプローチがどのように想定されているかについて、アーキテクチャ / ブロック図を使用してワークフロー（トレーニングと推論）の説明をリクエストします。	フィードバックにご協力いただきありがとうございます。この件に関するプレゼンテーションがいくつかあり、それらから追加のドキュメントを作成していく予定です。
ターゲット除外	プライバシーサンドボックスが、ギャンブルなどの不適切な広告からデリケートなオーディエンスと未成年者を保護する機能。	PA API では、表示される広告のコンテンツは考慮されません。これは、Protected Audience を使用する広告テクノロジーデベロッパーが管理します。通常、パブリッシャーとその広告テクノロジープロバイダは、ページのコンテキスト情報とパブリッシャーのルールセットを使用して、Protected Audience オークション内の広告クリエイティブをブロックできます。これは、Google が現在、こうした課題に対するエコシステムのアプローチをどのように理解しているかを反映しています。購入者にとって、IG の除外ターゲティング機能は、コンプライアンス関連のユースケースで役立つ場合があります。
API 設計	Google は、許可されている異なる IG で異なる biddingLogicURL を使用するのではなく、広告テクノロジーがユニバーサル入札機能を使用することを推奨しています。これによりレイテンシが増加します。	オークションのレイテンシについて説明する際に、購入者のすべての IG で同じスクリプトを再利用すると、その購入者の入札が高速化されることを強調しました。詳しくは、こちらをご覧ください。また、PA API オークションのレイテンシを改善するためのその他の推奨事項も記載されています。
アカウントベースのマーケティング	PA API は、アカウントベースのマーケティングのユースケースに適したクリーンな API ではありません。	実現できないと思われる特定のユースケースについて、エコシステムからフィードバックをお寄せください。エコシステムの参加者は、公開 GitHub リポジトリまたは毎週の電話会議を通じて、この議論を継続することをおすすめします。
A/B テスト	現在、パブリッシャーの GAM で PA API を設定する場合、すべての広告枠または広告枠なしのいずれかで有効にする必要があります。これにより、パブリッシャーが有効な A/B テストを実施する能力が制限されます。	Google アドマネージャーから提供された回答: Google アドマネージャー（GAM）内の PA API の制御は、API が使用可能な場合、GAM が API を使用できるかどうかに影響します。そのため、パブリッシャーは Chrome の権限ポリシー機能を使用して、トラフィックのサブセットで API の使用を無効にし、A/B テストのコントロールグループとして使用することで、A/B テストを実施できます。
機械学習	パブリッシャーは、GAM で提案されている機械学習の使用をより細かく管理する必要があります。	Google アドマネージャーから提供された回答: 2024 年 1 月に、パブリッシャー様が機械学習スロットルを無効にし、すべてのトラフィックで Google 以外の販売者との PA API オークションを有効にできる管理機能をリリースしました。この管理機能について詳しくは、ヘルプセンターをご覧ください。
（前四半期にも報告）最上位オークション	Google のパブリッシャー向け広告サーバーを、GAM にトップレベルの PA API オークションの制御権限を付与しなくても使用できる。	Google アドマネージャーから提供された回答: Google の 2023 年第 3 四半期レポートで説明されている理由により、GAM の PA API 統合計画では、トップレベルオークションを制御せずに GAM をパブリッシャー広告サーバーとして使用しているパブリッシャーのサポートは含まれません。
情報へのアクセス	GAM は、コンテキストオークションの価格、PA API オークション用に購入者が SSP に提供するシグナル、SSP の構成パラメータなど、競合他社から有益な情報を入手できます。	Google アドマネージャーから提供された回答: Google は長年にわたり、オークションの公正性に重点を置いてきました。その一環として、非保証型広告申込情報の価格など、パブリッシャーの非保証型広告ソースの価格を、オークションで入札する前に他の購入者と共有しないことを約束しています。この約束は、フランス競争当局への Google のコミットメントで改めて確認されています。 PA API オークションでは、Google は約束を守り、マルチセラーオークションでオークションが終了するまで、オークション参加者の入札価格を他のオークション参加者と共有することはありません。なお、こちらの最新情報で説明したとおり、Google はコンテキストオークションの価格を、Google 自身のコンポーネントオークションを含むどのコンポーネントオークションとも共有しません。また、Google は、コンポーネントオークションの構成に関する情報（購入者が SSP に提供するシグナルなど）を、Google 独自のオークションで使用しません。実際、Google は、コンポーネント販売者がトップレベルの販売者から難読化された方法でコンポーネントオークション構成を指定できるように、PA API を変更することを歓迎します。
コンポーネントオークション	GAM は最上位レベルのオークションとして、各広告オポチュニティのコンポーネントオークションを実行する SSP を制御します。	Google アドマネージャーから提供された回答: パブリッシャーの広告サーバーとして、GAM はパブリッシャーが Google パブリッシャータグ（GPT）API を介してコンポーネントオークションの設定を指定するために連携する SSP 向けの軽量な API を提供しています。詳しくは、こちらをご覧ください。 SSP がこの API を介してコンポーネントオークション構成を提供すると、その広告機会のコンポーネントオークションのリストに含まれます。GAM では、含まれるコンポーネントオークションに制限は適用されません。コンポーネントオークションを実施したい SSP は、パブリッシャーのページで必要なコードを実行することをパブリッシャーが許可していれば、実施できます。
コンポーネントオークション	GAM は、各コンポーネントオークションの落札入札単価に特定の非公開の下限を適用する場合があります。	Google アドマネージャーから提供された回答: Google アドマネージャーでは、長年にわたりオークションの公正性に重点を置いてきました。公正で透明性の高いオークションを維持するため、デマンドの特定のセグメントにのみ適用される最低入札額はサポートされていません。これは Google のプロダクトの一貫した原則であり、PA API オークションでも引き続き適用されます。
第三者広告サーバー	サードパーティの広告サーバーは、Google が参加する上位レベルのオークションにアクセスできなくなるため、PA API のコンテキストで Google SSP の需要を活用する能力が制限されます。	Google アドマネージャーから提供された回答: 現在、GAM では、こちらで説明されている API を介して、GAM で複数の販売者による Protected Audience API のテストがサポートされています。現在のところ、他のトップレベルオークションにコンポーネントオークションとして GAM が参加することはできません。
（前四半期にも報告） PA API オークションのパフォーマンス	PA API オークションのレイテンシが高いという報告がテスターから寄せられています。	レイテンシに関する懸念の声を多数いただいておりました。そのため、SSP が DSP レイテンシの上限を設定できるだけでなく、レイテンシを短縮できる改善も可能にする、PA API の一部として多くの機能を開発しました。これらの機能を活用する方法について詳しくは、最近更新されたレイテンシのベストプラクティスガイドをご覧ください。また、新しいレイテンシ改善の開発も継続しており、その一部はこちらでご覧いただけます。
（前四半期にも報告）動画のレンダリング	PA API とフェンスドフレームを使用した動画レンダリングのサポート。	1 月に、PA オークションでインストリーム動画がどのように機能するかのデモを公開し、代替のアプローチについて詳しく説明しました。また、エコシステムのプレーヤーが、統合するパートナー向けに動画レンダリングの仕組みを提案し始めています。たとえば、動画対応の renderURL の作成に関する GAM の提案や完全な E2E プロセスなどです。さらに、Google は、採用を促進するために実施できる変更について、エコシステムからのフィードバックにも耳を傾けています。そのような変更の 1 つが GitHub で詳しく説明されています。 Google は、採用の障害となる可能性のあるその他の問題を特定し、タイムリーに対応するため、エコシステムと積極的に連携しています。
（前四半期にも報告あり）データ処理に関するポリシー	IGs / PA API のデータ処理ポリシーを教えてください。	PA API の設計では、IG に保存されるデータ、またはユーザーがどの IG に属しているかに関するデータはすべて、（i）デバイス上に残るか、（ii）高信頼実行環境（TEE）内で実行される入札とオークション（B&A）サービスで処理されます。どちらの場合も、データは他のパーティによって読み取られることはなく、オークションで入札を作成する以外の方法で使用されることはありません。 Chrome で検討されているプライバシー強化の一部では、Google が運営する k-匿名性サーバーとのやり取りが含まれます。このインタラクションでは、ユーザーに関する情報を共有しないように慎重に設計されており、広告エコシステム全体で情報の均一性を確保するために TEE で実行されます。 Google は、Google 自身のビジネスを優先して競争を歪めない方法でプライバシーサンドボックスの提案を設計し、実装すること、デジタル広告の競争とパブリッシャーと広告主への影響を考慮することを CMA に約束しています。Google は、これらの義務に準拠するよう、CMA と引き続き緊密に連携してまいります。
（前四半期にも報告） Instagram の総再生時間	IG の有効期間を 30 日から 90 日に延長するようリクエストします。	このような変更を行うには、業界へのメリットと Chrome ユーザーやその他の関係者への影響を慎重に検討する必要があります。このリクエストについて現在検討中です。こちらから追加のフィードバックをお寄せください。
（前四半期にも報告） modelingSignals	ディスプレイとクリックの情報のみをエンコードできる modelingSignals に加えて、新しいフィールドをリクエストします。	このフィードバックに対し、こちらで反論の提案をしています。Google は、提案内容について業界の意見を積極的に聞き取り、現在、業界へのメリットと Chrome ユーザーやその他の関係者への影響を比較検討しています。
reportWin() の追加ビット	3PCD より前の現在の上限 12 ビットから、reportWin() で追加のビットを提供。	Google では現在、このユースケースをサポートする方法を検討しています。長期的なプライバシー計画を確実に策定できるアプローチを模索しているため、時間がかかっています。
オークション設計	レンダリング URL と対応するスコアを返す単一オークションのリクエスト。	1 つの PA オークションから複数の renderURL とそれぞれのスコアを共有することも検討しましたが、プライバシーに関する懸念から実装しませんでした。同じページで同じ広告をユーザーに複数回表示しないようにしたいというご要望はよくわかります。GitHub で引き続きご意見をお聞かせください。
reportWin	reportWin() 関数で任意のフィールドをログに記録します。	これは、現在テスト期間中に行われています。Chrome で 3PC のサポートが終了すると、API の forDebuggingOnly バージョンが移行され、ダウンサンプリングされたデバッグが有効になります。これはこちらで指定されています。
コンポーネント販売者	独自のインプレッションやその他のイベントをカウントする独立したメカニズムがあり、広告テクノロジーのレポートにのみ依存する必要がない。	この機能リクエストは、さらに調査するためのキューに登録されています。Chrome 主導のテスト期間中にこの問題に対処することは予定されていません。
クリック単価のお支払い	PA API にクリック単価の課金を実装。	このリクエストはこちらで検討中です。現在、このリクエストは、現在の API サーフェスで実装する方法に関する提案を求めているリクエストと見なしています。
browserSignals	販売者のレポートの browserSignals 仕様に incomingBidInSellerCurrency を追加。	このリクエストについて現在検討中です。こちらから追加のフィードバックをお寄せください。
DSP 以外のバイサイドのメタデータとロジックの所有権のサポート	API の現在の設計では、商品単位のリターゲティングキャンペーンに大きな変化が生じる可能性があります。キャンペーンを DSP と DCO プロバイダの両方として機能するプラットフォームに移行する必要が生じる可能性があります。	Google では現在この問題について検討中です。こちらから追加のフィードバックをお寄せください。
DSP 以外のバイサイドのメタデータとロジックの所有権のサポート	DSP が IG の所有者ではない例を共有します。	入札者以外のお客様は、インタラクティブグラフの一部機能を利用したいものの、他の機能は利用したくないとのご意見があることは理解しております。Google では、こうしたユースケースに対応するための方法を積極的に検討しています。こちらからフィードバックをお寄せください。
タイムアウトの管理	パブリッシャーは、参加できる IG の数とトップレベルのタイムアウト / グローバルタイムアウトを指定できる必要があります。	トップレベルの販売者とコンポーネント販売者間のタイムアウト制御と可視性を強化したいというご要望があることは認識しており、現在、このリクエストを検討しています。
マルチ広告サイズ	複数の広告サイズのユースケースに対する PA API のサポート。	YouTube ではこのリクエストを検討しており、エコシステムからの追加のフィードバックをお待ちしております。
ドキュメント	k-匿名化の対象となる IG 属性のリストはありますか？	この質問への回答はこちらをご覧ください。
デバッグ	PA API のデバッグ機能を改善しました。	Google は、PA API を扱うデベロッパーにとって、堅牢なデバッグツールの重要性を認識しています。Google は、.well-known ファイルの取得をデベロッパーツールとより適切に統合する方法を模索し、デベロッパーエクスペリエンスの向上に取り組んでいます。開発環境内での可視性とトラブルシューティング機能を強化することが目標です。この問題について詳しくは、こちらをご覧ください。ご意見やご感想をお寄せください。
ラベル	モード B の処理ラベルのすべてのユーザーでプライバシーサンドボックス API が有効になっていますか？	Chrome テストグループへの割り当てはランダムに決定され、ユーザーが設定した Chrome の設定とは独立しています。これらの API は、特定の治療グループ（treatment_1.* など）内のユーザーが利用できる場合があります。ただし、その機能は Chrome の設定で変更または無効にできます。モード B の control_2 グループ: このグループに含まれると、プライバシーサンドボックスの関連性と測定に関する API が自動的に無効になります。この設定は、ユーザーが Chrome の設定でオーバーライドすることはできません。
API 使用量	reportWin() の呼び出しと広告のレンダリングは、並行して行われますか？それとも順番に行われますか？	reportWin() は、runAdAuction() の完了直後に呼び出されます。同時に、オークションの結果が iframe または Fenced Frame 内に配置されると、広告のレンダリングプロセスが開始される場合があります。reportWin() の実行が完了し、広告のレンダリングが開始されると、sendReportTo() に指定された URL が取得されます。
（前四半期にも報告） A/B テストのサポート	PA API A/B テストのサポートをリクエストします。	このリクエストについては、こちらで議論されており、追加のフィードバックをお待ちしております。
トラフィックシェーピング	Google から提案された KV サーバー経由で必要な意思決定を管理する提案は役に立ちません。販売者はバックエンドを操作できないため、トラフィックシェーピングが困難になります。	GitHub の問題で説明されているように、個々の DSP に IG が存在するかどうかを公開すると、ユーザーのフィンガープリントに関する懸念が生じる可能性があります。他の代替方法も問題の件で提案しておりますが、さらにご提案いただければ幸いです。
トラフィックシェーピング	キャッシュメカニズムにより複雑さが大幅に増加し、DSP が入札するトラフィックの実際の形状を把握できなくなります。	キャッシングメカニズムは、単なる提案として提示されました。広告テクノロジーは、ユースケースに適した推奨事項を選択できます。詳しくは、こちらをご覧ください。
ラベル	Chrome は、購入者と販売者の信頼できるサーバーに送信するリクエストで、パラメータとしてラベルを共有する必要があります。	これは、責任ある IG データの利用という目標と広く合致していると思われるため、妥当なリクエストと思われます。ただし、Google は社内審査を条件にリクエストを検討しており、議論が進展するにつれてこの件について公開情報をお知らせします。
API 使用量	「テストに関するサードパーティ向けの追加の CMA ガイダンス」ドキュメントで、「control_1」グループの明示的な定義を明確にしました。具体的には、文言の変更により、control_1 からすべてのプライバシーサンドボックス API を除外することが義務付けられていると誤解される可能性があるという懸念があります。	この点については、こちらの GitHub スレッドで Google の考えを表明しています。ただし、YouTube は CMA の代理人ではありません。テストに関するガイダンスの解釈に関する問題については、CMA に直接お問い合わせいただくことをおすすめします。
API 使用量	Chrome では、別のリソースにリダイレクトしながら、空白のページで joinAdInterestGroup() を呼び出すことができますか？	ユーザーがサイトにアクセスしている場合、サイト所有者は joinAdInterestGroup を呼び出す権限をサードパーティに委任できます。この委任により、サードパーティは空白ページを介したリダイレクトを追加しなくても IG を作成できます。意図された委任メカニズムを使用する代わりに、リダイレクトの途中で IG を作成する具体的な理由について、フィードバックをお寄せください。
API 使用量	エクスチェンジは、提携しているパブリッシャーが所有するページに IG を書き込み、その IG に入札する権限を特定の購入者または DSP に委任できる必要があります。	いただいたフィードバックに基づき、このようなリクエストをサポートできるかどうかを検討しております。エコシステムからのフィードバックをお待ちしております。
API 使用量	PA API オークションで落札者がいなかった場合、デバッグによる落札失敗の通知はありません。	Chrome の reportWin 関数と reportResult 関数は、プライバシーオークション（PA）システム内でのイベントレベルの落札レポート用に設計されています。PA オークションですべての入札が拒否された場合、落札者が決定されないため、これらの関数が呼び出されることはあまりありません。 Chrome の最近の更新により、forDebuggingOnly.reportAdAuctionLoss() に渡された URL が DevTools の [ネットワーク] パネルに表示されないという不一致が発生する可能性があります。この機能は、Chrome の Canary チャンネルまたは Dev チャンネルビルドを使用して確認することをおすすめします。
API 使用量	generateBid から返される adCost が負になることがありますか（すでに確率的に 2 バイトに丸められています）？	AdCost は、generateBid() から reportWin() に渡される広告主のクリックまたはコンバージョン費用です。この値は null または double です。負の値は無視され、渡されません。値は渡されたときに確率的に丸められます。
API の改善	Chrome ブラウザではなく、信頼できる暗号化されたエグゼキューションサーバーでターゲティング、コホート、アトリビューション、オークションを処理できますか？	この問題に対処するには、PA API の TEE ベースのコンポーネントとオプション（KV サーバーや B&A サービスなど）と、アトリビューションレポートと限定公開集計の TEE ベースのコンポーネント（集計サービスなど）を検討することをおすすめします。
API の改善	プライバシーサンドボックスのオークションレスポンスは、広告レスポンス（広告タグなど）ではなく、入札レスポンス（ヘッダー入札など）にできますか？	この種の変更は PA API のプライバシープロパティを根本的に変更するため、現在検討中ではありません。
サイト運営者 / パブリッシャーの管理設定	パブリッシャーは、ページで PA API クリエイティブをブロックできますか？	Chrome にはリアルタイムのクリエイティブスキャンの提案がありますが、まだテストできません。この機能はまだ利用できません。しかし、ほとんどの SSP がこの機能を実現するソリューションを作成しています。
API 使用量	perBuyerSignals のサイズ制限はどのくらいですか？	従来の形式の perBuyerSignals には、Chrome 内での固有のサイズ制限はありません。主な制約は、データが JSON シリアル化可能であり、過度のメモリ消費が発生しないことです。ただし、非常に大規模で複雑な perBuyerSignals はパフォーマンスに悪影響を及ぼす可能性があることに注意してください。 directFromSellerSignalsHeaderAdSlot を介して perBuyerSignals を渡す方法もあります。この方法では、ヘッダー内で perBuyerSignal を送信します。ヘッダーレスポンス全体の最大サイズの上限は 10 KB です。また、個々のサーバーでヘッダーの最大サイズに独自の制限が適用される場合があります。
ドキュメント	generateBid 内から registerAdBeacon を呼び出すドキュメントを変更する必要があります。	このドキュメントは 2 月 17 日に更新されました。
API 使用量	reportEvent は、登録されている複数のオプションから適切なビーコン URL を選択する仕組み	各オークションで個別の設定が作成され、個別のレポートマップが作成されます。個々のオークション（およびその結果のフレーム）は完全に分離されており、データを共有しません。このトピックについて詳しくは、フェンスドフレーム広告レポートをご覧ください。
Chrome UI	Chrome DevTools の [Application] -> [Interest groups] タブにフィルタを追加し、IG 所有者（または IG 名）でフィルタできるようにします。	Google では現在、このリクエストを評価しており、エコシステムからの追加のフィードバックをお待ちしております。
ヘッドレス Chrome	ヘッドレス Chrome での PA API のサポート。	PA API には、Google のサーバーへの k-anon 呼び出しなど、Chrome に関連付けられているコンポーネントがいくつかあります。これらのコンポーネントは、「古い」ヘッドレス Chrome では動作しない可能性があります。 Chrome 112 でリリースされた「新しい」バージョンのヘッドレス Chrome では、この問題が解決される可能性があります。
API 使用量	reportAdAuctionLoss で損失を報告する場合、多くの場合「topLevelWinningBid=0」と表示されます。この解釈は正しいですか？	topLevelWinningBid の値は、最上位の販売者コンポーネント内の scoreAd() 関数から取得されます。この値は、最上位オークションの結果を決定するうえで重要な役割を果たします。説明のとおり、topLevelWinningBid の値が 0 または負の値の場合、対応する広告はオークションの落札対象外であることを示します。このメカニズムは、コンテキストターゲティングの候補を上回らないインタレストグループターゲティング広告を除外する場合などに使用できます。 topLevelWinningBid の値がゼロの場合、コンテキストオークションが優先されたことを示している可能性がありますが、PA API の仕様では、この結果に他の要因が影響している可能性があることを認めています。
モードの A/B テスト	モード B とモード A のトラフィック選択とオプトアウトプロンプトの明確化。	モード A とモード B の対象条件は同じです。プライバシーサンドボックス API とラベル付け方法をサポートしている限り、通常の Chrome トラフィックを代表するグループを作成することが目標です。一部のクライアント構成は互換性がありません。テストの目的のために、ラベル付きトラフィックのみと他のラベル付きトラフィックを比較することが重要です。モード B のユーザーはトラッキング保護機能が有効になっているため、その機能に関する通知を受け取ります。
API の改善	「lifetimeMs」を joinAdInterestGroup 呼び出し内の直接プロパティとして含めたり、別個の引数として管理したりできますか？	Google は、PA API の提案における「joinAdInterestGroup」機能について、ウェブ開発コミュニティからのフィードバックを慎重に検討しています。主な議論のポイントは、IG の存続期間を管理するための最適な方法です。Google では、「lifetimeMs」パラメータに個別の引数を追加することのメリットを検討しています。これにより、将来仕様が拡張された場合に柔軟性と適応性が向上します。この問題についてはこちらで議論しており、追加のフィードバックをお待ちしております。
API 使用量	エントロピーの低いブラウザ ID との衝突により、PA API フレームワークで誤検出率が増加する可能性がある。	Chrome チームは、PA API フレームワークの継続的な改良に積極的に取り組んでいます。ブラウザ ID の競合によって生じる可能性のある誤検出率について、ご意見をお寄せいただきありがとうございます。YouTube は、このフィードバックを慎重に評価し、更新された分析に関連するすべての要因が包括的に反映されるように取り組んでまいります。Google は、精度と信頼性を維持しながら、望ましいプライバシーの結果を達成するソリューションに取り組んでいます。この問題についてはこちらで議論されており、追加のフィードバックをお待ちしております。
API 使用量	k-匿名性システムで、クライアントが同じオブジェクトに対して「結合」リクエストを繰り返し送信しないようにするには、エントロピーの低いブラウザ識別子が必要ですか？	Google は、k-匿名化システムの実装におけるブラウザ識別子の使用について、現在進行中の議論を認識しており、その議論に感謝しています。このような ID がプライバシーに及ぼす可能性のある影響について、懸念が寄せられていることを理解しています。最初の実装では、不正使用防止メカニズムとして低エントロピー ID を使用していましたが、Google は、システムの完全性を維持しながらユーザーのプライバシーを優先する、匿名カウントトークンなどの代替手法を積極的に模索しています。Google は、責任あるデータ使用と堅牢なプライバシー保護のバランスを取るソリューションの開発に取り組んでおり、研究コミュニティとの継続的な対話を歓迎しています。こちらでこの問題について議論しており、皆様からのフィードバックをお待ちしております。
API 使用量	AMP（Accelerated Mobile Pages）は PA API に対応していますか？	現在、AMP は PA API をネイティブにサポートしていません。AMP によるサポートが優先事項である場合は、エコシステムからの追加のフィードバックをお待ちしております。
API の改善	k-匿名性チェックから型を削除することを検討してください。	Google は、k-匿名化リクエスト構造の最適化に関するフィードバックを慎重に検討しています。パラメータを統合し、必要に応じてタイプを統一してプロセスを効率化するというご提案はよく理解しております。Google は効率性とメンテナンス性を重視しており、プライバシーソリューションの開発を継続する中で、すべてのオプションを検討しています。この問題についてはこちらで議論しており、追加のフィードバックをお待ちしております。
Chrome UI	技術に詳しくないユーザーが、自分が所属する IG を簡単に表示、管理できるメカニズム（オプトアウトするためのウェブサイトレベルのコントロールなど）をリクエスト。	Google は、IG を理解して管理するためのユーザーフレンドリーなツールを提供することが重要であると認識しています。Google はさまざまな方法を慎重に検討した結果、参加したウェブサイトによって IG を識別することが、明確さとプライバシー保護のバランスが最も取れた方法であると判断しました。現在、IG のグローバル管理は Chrome の設定内にあります。Google は、この分野のユーザーエクスペリエンスをさらに向上させる方法を常に模索しています。この問題についてはこちらで議論されており、追加のフィードバックをお待ちしております。
API の安全性	PA API は、フェンスドフレームのコンテキスト内でも、クリエイティブ広告インタラクションによるプライバシー漏洩のリスクがありますか？	Google は、高度な広告インタラクションによって情報漏洩が発生する可能性があることを認識しています。Google は、フェンスドフレーム、PA API、潜在的な攻撃ベクトル間の相互作用を積極的に調査しています。プライバシーリスクの軽減は最優先事項であり、Google はイノベーションとユーザー保護のバランスを取った堅牢なソリューションの開発に取り組んでいます。この問題についてはこちらで議論されており、追加のフィードバックをお待ちしております。
レイテンシ	購入者の入札ロジックのデフォルトのタイムアウト（50 ms）は現実的な値ですか？	入札ロジックのネットワークリクエストの仕様とタイミングの不一致に関する懸念について、Google は認識しています。Google は、仕様の精度を確保するため、仕様を積極的に審査しています。また、パフォーマンスと実現可能性のバランスを取るために、最適なデフォルトのタイムアウト設定を調査しています。この問題についてはこちらで議論しており、追加のフィードバックをお待ちしております。
ドキュメント	ウェブサイトが広告が k-匿名性のしきい値を満たしていないかどうかを推測できる仕様で、タイミングリークが発生する可能性、およびクロスサイトトラッキングへの潜在的な影響。	タイミングリークの可能性に関する問題を認識しております。仕様との不一致が確認されました。Google は、このような漏洩を防ぐため、オークションの前に広告の k-匿名性ステータスが決定されるようにするための措置を講じています。Google はこれらの懸念を真摯に受け止め、これらの変更を反映して仕様を更新します。この問題についてはこちらで議論しており、追加のフィードバックをお待ちしております。
API 使用量	PA API 内で SSP 拒否リストを実装する方法。	Google は、SSP による広告制限を管理するメカニズムの必要性を認識しています。デバイス上の評価を優先し、既存の広告メタデータを活用して、柔軟性を維持しながらユーザーのプライバシーを保護するソリューションを検討することをおすすめします。Google は、デベロッパーと連携して PA API 内で最適なアプローチを特定することに取り組んでいます。この問題についてはこちらで議論されており、追加のフィードバックをお待ちしております。
API 使用量	サイトが検出できない方法で、PA API を実行しているようにブラウザに指示することはできますか？	現状では、PA API のオプトアウトがウェブサイトによって検出される可能性があることを認識しています。Google は、プライバシーを強化し、検出不能なオプトアウトオプションを提供できるよう、追加入札や除外ターゲティング、フェンスドフレームレンダリングなどの機能の開発に積極的に取り組んでいます。この問題についてはこちらで議論されており、追加のフィードバックをお待ちしております。
モードの A/B テスト	処理 1.1 と称するデータセンタートラフィック。	Chrome チームは GAM チームと連携し、このトラフィックがテストから除外されていることを確認しました。この問題についてはこちらで議論されており、追加のフィードバックをお待ちしております。
API 使用量	PA API での interestGroupBuyers の実装の効率性と公平性。	Google は、PA API オークションの「interestGroupBuyers」フィールドの効率性と公平性について、現在も議論が続いていることを認識しています。Google は、効率性、プライバシー、市場の公平性の間にトレードオフがあることを認識しています。販売者は購入者とのビジネス関係を管理する必要がありますが、Google はマッチングプロセスを最適化する方法を検討しています。たとえば、リアルタイムデータやハイブリッドモデルに基づく動的調整などです。Google は、ユーザーのプライバシーを優先し、競争力のある広告エコシステムをサポートするソリューションの開発に引き続き取り組んでまいります。この問題についてはこちらで議論されており、追加のフィードバックをお待ちしております。
Chrome UI	Chrome の IG に関連するメモリに関する懸念と UI の明確性。	DevTools での IG の表示について、ご懸念をお寄せいただきありがとうございます。現在のビューには、過去のトラッキング用にすべての IG イベントが反映されていますが、保存されている IG の現在の状態をより明確に把握できるメリットがあることも認識しています。デベロッパー向け分析情報を改善するため、最適化と UI の改善を検討しています。メモリ管理については、IG の実装はメモリリークを防ぐように設計されていますが、リソース使用量は継続的にモニタリングされ、最適化されています。この問題についてはこちらで議論されており、追加のフィードバックをお待ちしております。
ドキュメント	元の投稿者は、「joinAdInterestGroup」関数の「sizeGroup」フィールド内で名前付き広告サイズを直接使用しようとするとエラーが発生しています。これは想定どおりの動作かどうかをお客様が知りたい場合。	Google は、「joinAdInterestGroup」関数内で広告の設定を効率化することの意義を認識しています。Google は現在、この制限事項の解消に取り組んでおり、今後のアップデートでこの機能を有効にする予定です。この機能強化は、デベロッパーに柔軟で効率的な広告管理ツールを提供するという Google の取り組みの一環です。この問題についてはこちらで議論されており、追加のフィードバックをお待ちしております。
Chrome 主導のテストのラベル	テストを継続的に追跡できるように、モード A とモード B に関する直接データと、sendReportTo の正確なラベルをリクエストします。	このリクエストについては、こちらで議論されており、皆様からのフィードバックをお待ちしております。
ドキュメント	販売者のドメイン名は、検証目的で販売者の信頼できるサーバーに送信されるリクエストに含まれていますか？	Protected Audience KV Server API のドキュメントからホスト名パラメータが最初に省略されていたことを認識しています。販売者の信頼できるサーバーのリクエストに、販売者のドメイン名が自動的に含まれるようにすることで、デベロッパーの安心をサポートします。この機能は、堅牢な広告検証プロセスに不可欠です。この不注意に対処するため、ドキュメントを更新しました。今後も、デベロッパーコミュニティの明確性と透明性を最優先にします。この問題についてはこちらで議論されており、追加のフィードバックをお待ちしております。
API 使用量	レポート作成のために、広告インプレッショントラッキング呼び出し内に IG 名を含める方法。	Google は、堅牢な報告メカニズムの必要性とユーザーのプライバシーという基本原則のバランスを取ることに取り組んでいます。広告インプレッショントラッキングに IG 名を含める場合、個人の特定を防ぐために k-匿名性保護機能が適用されます。Google は、こうしたプライバシー上の制約の中で、革新的なレポートソリューションの開発に引き続き取り組んでまいります。この問題についてはこちらで議論されており、追加のフィードバックをお待ちしております。
API 機能	購入者の信頼できるサーバーがクライアントヒント HTTP ヘッダーを受信するようリクエストします。	この機能リクエストの処理状況のトラッキング用シート: こちら
API 使用量	ブラウザの IG メンバーシップ動作を規定する「Access-Control-Allow-Origin」ヘッダーを読み込むために、委任ファイルにヘッダーが必要かどうか。	Google は、ウェブセキュリティのベストプラクティスに準拠することをお約束します。委任ファイルに「Access-Control-Allow-Origin」ヘッダーが必須であることにより、CORS の原則との整合性が確保され、機密情報の意図しない漏洩を防ぐことができます。Google は、強力なセキュリティ対策を維持しながら、このプロセスを最適化する方法を模索しています。この問題についてはこちらで議論されており、追加のフィードバックをお待ちしております。
API 使用量	広告サーバーによる PA API フレームワーク内でのクリエイティブのパーソナライズを有効にします。	Google は、広告サーバーによるクリエイティブのパーソナライズが果たす役割を認識しています。Google は、入札と広告クリエイティブの選択ロジックを組み合わせることができる「共同 IG」モデルなど、PA API 内で広告サーバーを強化するソリューションを積極的に検討しています。Google の目標は、堅牢な広告クリエイティブ機能の実現とユーザーのプライバシー保護のバランスを取ることです。すべての関係者のニーズに対応できるよう API を進化させるため、こちらからご協力とフィードバックをお待ちしております。
プライバシーに関する問題	代替の識別子（コンテキスト入札リクエストで RampID や ID5 などの ID を使用すると、クロスサイトデータ収集が容易になり、PA API のプライバシー目標が損なわれる可能性があります。	Google は、クロスサイト識別子と PA API のプライバシー目標の間に潜在的な緊張関係があることを認識しています。パブリッシャーはこうした ID を共有することもできますが、PA API の設計は基本的に、広告選択とクロスサイトトラッキングを切り離すことを目的としています。Google は、プライバシー重視の広告エコシステムの構築に取り組んでおり、デベロッパーの皆様には PA API アプローチを優先することをおすすめします。この問題についてはこちらで議論されており、追加のフィードバックをお待ちしております。
キャッシュ	複数のオークションで入札スクリプトを再利用しないようにする方法はありますか？	Google は、PA API フレームワーク内で入札スクリプトのキャッシュ保存動作が確認されていることを認識しています。標準の HTTP キャッシュメカニズムはサポートされていますが、デバイスの停止動作と入札エグゼキュータの設計により、オークション間でスクリプトが再利用される可能性があります。Google は、購入者がスクリプトキャッシュをより細かく制御して入札戦略を効果的に管理できるようにするソリューションを調査しています。この問題についてはこちらで議論されており、追加のフィードバックをお待ちしております。
API 使用量	ユーザーのプライバシーを尊重しながら、DSP のすべての IG にわたる入札アクティビティのレポートを一元化します。	Google は、PA API の設計においてユーザーのプライバシーを最優先しています。クロスサイトトラッキングによるリスクがあるため、個々の入札イベントを直接レポートすることはできませんが、共有ストレージやプライベート集計などのメカニズムをご利用いただけます。これにより、DSP はユーザーのプライバシーを保護しながら、入札アクティビティに関する集計分析情報を得ることができます。
API 使用量	reportResult() の sendReportTo() からの取得は、forDebuggingOnly.reportAdAuctionWin() で登録された取得に比べて、94% の確率でのみ行われます。	タイミングは同じではないものの、両方の URL が同時に取得されることもあります。コンポーネントセラーのワークレットが破棄された場合は、reportResult() 関数を実行するために再読み込みする必要があります。ただし、スコアリングロジックの取得時間も、ワークレットの再読み込み時間も、reportResult() の 50 ミリ秒のタイムアウトには影響しません。Chrome は、ワークレットの再読み込みが必要な場合に、キャッシュヘッダーを使用して取得動作を定義します。 PA オークションの各フェーズについて詳しくは、こちらをご覧ください。
k-匿名性	インタレストグループの名前が広告配信の k-匿名性に影響しないことを確認するためのリクエスト。	クリエイティブが k-匿名と見なされるには、過去の期間（w）に IG 所有者の URL、入札スクリプトの URL、クリエイティブの URL、広告サイズの組み合わせが指定されたしきい値（k）を満たしている必要があります。k-匿名性のステータスは定期的に更新されます（p）。
Chrome UI	多くの MVC、ORM などのフレームワークが提供する「内部可視性」のタイプを提供するための提案。たとえば、Dev Tools の [Application] > [Application] セクションで、選択した内部イベントを新しいパネルに簡単にロギングします。	この提案についてこちらで議論しています。追加のフィードバックもお待ちしております。
Chrome UI	Dev Tools IG の参加で、優先度に関連する要素が表示されない。	この問題については、こちらで説明しています。
API の改善	クリエイティブ広告サーバーで独自のイベントをトラッキングすることをおすすめします。許可されるトラッキングドメインのリストを設定できますか？	提案はこちらで公開しています。エコシステムからの追加のフィードバックをお待ちしております。
API 機能リクエスト	PA API を拡張して、RTB 以外のメディア取引をサポートし、広告配信や DCO などの重要なユースケースを維持することはできますか？	この問題についてはこちらで議論されており、皆様からのフィードバックをお待ちしております。
パブリッシャーのオークションのタイムアウト	パブリッシャーは、特に広告が順番に選択されるヘッダー入札の設定で、インプレッションの損失を防ぐためにオークションの時間を管理する必要があります。	Google は、広告オークションのタイムアウトをパブリッシャー様が細かく管理できることの重要性を認識しています。Google は、エッジケースを慎重に検討しながら、「auctionConfig」オブジェクト内にグローバルオークションのタイムアウトメカニズムを実装する方法を積極的に検討しています。この機能は、パブリッシャーのインプレッションフィリップ率を最適化することを目的としています。Google は、最適なソリューションを見つけるために、引き続きコミュニティと連携していきます。この問題についてはこちらで議論されており、皆様からのフィードバックをお待ちしております。
API の改善	PA API の IG の現在の設計では、renderURL が長くなるため、メタデータのサイズが大きくなります。テスターは、これらの URL を圧縮して効率性を高める方法を希望しています。	Google は、特に費用対効果に敏感な広告オークションにおいて、IG メタデータのサイズを最適化することが重要であると認識しています。レンダリング URL を圧縮するテンプレートベースのソリューションは、大きな可能性を秘めていると考えています。Google は、提案されたテンプレートのデザインを慎重に評価し、実装されるソリューションに、ブラウザの安定性を維持するための堅牢な不正使用防止メカニズムが含まれていることを確認します。ウェブ標準コミュニティと連携して、これらの考慮事項を念頭に置き、最適なアプローチを開発することが引き続き優先されます。この問題についてはこちらで議論されており、皆様からのフィードバックをお待ちしております。
API 使用量	ネイティブ広告フォーマットを扱うテスターは、1 回の呼び出しで複数の広告結果を取得することでプライバシーサンドボックスのオークションプロセスを最適化し、ネットワークの負荷を軽減して広告のレンダリング速度を向上させたいと考えています。	Google は、プライバシーサンドボックスでのネイティブ広告のレンダリングに関するパフォーマンスに関する懸念を認識しています。Google は、効率性とユーザーのプライバシー保護の強化のバランスを保つことに全力で取り組んでいます。スコアが満点の広告を複数返すことはプライバシーを侵害しますが、Google はオークションプロセスを最適化する方法を積極的に模索しています。 Google は、ネイティブ広告フォーマットに対する PA API のサポートを強化し、プライバシーサンドボックスの厳格なプライバシー制約内で効率を高めるための代替メカニズムを調査しています。この問題についてはこちらで議論されており、皆様からのフィードバックをお待ちしております。
API 使用量	プライバシーサンドボックス内での広告入札単価のスコアリングと並べ替えの柔軟性（特に優先レベルやプライベートマーケットプレイスのルールを表現する場合）。	Google は、特に複雑な入札シナリオにおいて、プライバシーサンドボックス内での広告のスコアリングと並べ替えをきめ細かく制御する必要があることを理解しています。Google は、タプルと数学関数を使用してユーザーのプライバシーを損なうことなく多面的なスコアリングを実現するソリューションが提案されていることを認識しています。これらのアプローチは開発者の負担を増やす可能性がありますが、必要な表現力を提供します。 Google は、高度なオークションロジックにプライバシーサンドボックス機能を最適に使用できるように、ヘルパー関数やガイドラインなどを通じて、これらのプロセスを効率化する方法を検討しています。この問題についてはこちらで議論されており、追加のフィードバックをお待ちしております。
reportEvent()	広告クリエイティブを含むフレームが初期化されたときにブラウザによって発行される新しい予約済みイベント（自動ビーコンなど）を追加します。	このリクエストについては、こちらで議論されており、追加のフィードバックをお待ちしております。
adCost	adCost の内訳を許可。	各費用値は、オークションから限定された量の情報を送信する機会です。これらの費用のリスト全体を許可すると、ユーザー ID 全体を送信できるため、クロスサイトトラッキングが可能になります。この件についてはこちらで議論しており、皆様からのフィードバックをお待ちしております。
resolveToConfig	resolveToConfig は最上位から継承され、browserSignals で公開されるべきですか？	このリクエストについては、こちらで議論されており、追加のフィードバックをお待ちしております。
ツールの強化	chrome://topics-internals に似たものが PA API にはありますか？	完全に同じものはありません。ただし、PA API 用の豊富なデベロッパーツールがあります。
ラベル	Chrome はラベルを使用して、20% の k-anon ユーザーを識別できますか？	YouTube ではこのリクエストを検討しており、エコシステムからの追加のフィードバックをお待ちしております。
ドキュメント	プライバシーサンドボックスオークションワークレットは標準のワークレットタイプになりますか？	独自のプライバシーとセキュリティの要件により、これらのワークレットは標準のブラウザワークレットタイプとは大きく異なるため、HTML 仕様内で標準のワークレットタイプになることはすぐには見込まれません。 Google は、オークションワークレットの実装環境と実行環境について明確に説明することで、デベロッパーリソースを強化し、プライバシーサンドボックスの参加者がこの情報をより簡単に利用できるように取り組んでいます。詳しくはこちらをご覧ください。
お客様所有サーバー（BYOS）の Key-Value（KV）サーバー	ユーザーが結合した複数の IG（同じオーナーの IG）を、BYOS KV サービスの設定で KV サービスクエリを介して第三者が知ることができる可能性があります。	KV サーバーが TEE で実行される場合、これはできなくなり、公開された信頼モデルに準拠できるようになります。
userBiddingSignals	「userBiddingSignals」の一部を更新し、他の部分は維持する。	これは、API の変更を必要とせずにすでに可能です。
API 使用量	プライバシーサンドボックス内の複数の IG にフリークエンシーキャップを実装します。KV サーバーまたは変更された「prevWinsMs」データを使用する場合があります。	プライバシーサンドボックスに高度なフリークエンシーキャップ機能をご希望の点は承知しております。Google は、IG 間でのデータ共有に関する現在の制限が、これらの戦略の実装に課題をもたらす可能性があることを認識しています。 KV サーバーは適切なプライバシー保護機能を備えたメカニズムを提供しますが、デベロッパーには単一の IG モデル内でのソリューションの検討をおすすめします。この問題についてはこちらで議論されており、追加のフィードバックをお待ちしております。
API 使用量	コンポーネント販売者（プライバシーサンドボックス内のネストされたオークションに参加する販売者）は、独自の設定を最適化し、不要な遅延を回避するために、最上位オークションのタイムアウトを把握する必要があります。	Google は、プライバシーサンドボックス内で、最上位の販売者とコンポーネント販売者間のタイムアウトの調整を改善する必要があること認識しています。Google は、オークション全体のタイムアウトの可能性など、新しいタイムアウトメカニズムの追加を積極的に調査しており、コンポーネントオークションに最上位のタイムアウトを適用する方法も検討しています。Google の目標は、プライバシーサンドボックスのオークションプロセスのすべての参加者の効率性と予測可能性を高めることです。この問題についてはこちらで議論されており、追加のフィードバックをお待ちしております。

Protected Audience サービス

フィードバックテーマ	概要	Chrome の対応
高信頼実行環境（TEE）	オンプレミスの広告テクノロジーデータセンターと比較して、パブリッククラウドで TEE を実行する方が費用は高くなりますか？	Google の回答は前四半期と同様です。 Google の現在の TEE セキュリティモデルは、パブリッククラウド実装のプラクティスを活用しています。特に、現在のハードウェアベースの TEE は、すべての物理攻撃を防御するものではありません。Google がサポートしている既存のパブリッククラウドプロバイダである AWS と Google Cloud は、社員によるものを含む物理的なアクセスリスクを軽減する対策を設計して実装しています。オンプレミスサポートについては、以下をご覧ください。クラウドサービスの運用は、オンプレミスの広告テクノロジーデータセンターよりも費用がかかる、と広告テクノロジー企業から指摘されています。Google はこれらの主張を評価する立場にはありませんが、費用に関する追加のフィードバックをお寄せいただければ幸いです。また、TEE のサポートを拡大するためのオプションを引き続き評価していきます。
TEEs	パブリッククラウド以外の環境での TEE のサポート	回答は前四半期と同様です。 Google は、パブリッククラウドベースのソリューション以外のオプションのサポートを継続的に検討していますが、現時点ではオンプレミス TEE をサポートする予定はありません。この段階では、プライバシーサンドボックスのセキュリティ要件と、オンプレミスデプロイメントに伴う重大な課題を考慮すると、クラウドベースのデプロイメントの拡大と改善（AWS に加えて Google Cloud のサポートなど）を継続することがエコシステムにとって最も有益であると考えています。ただし、プライバシーとセキュリティの制約を考慮して、このような要件がなぜ必要で実現可能なのかについて、追加のフィードバックをお寄せください。
他のクラウドプロバイダ	他のクラウドプロバイダのサポート	他のクラウドプロバイダの提案には常にオープンですが、3PCD が適用される時点では、少なくとも Google Cloud と AWS をサポートする予定です。詳しくは、こちらの説明をご覧ください。
B&A Services API	B&A Services API の今後の方向性について教えてください。デバイスオークションで、Chrome ブラウザの Protected Audience よりも優先されるのか、それとも優先されないのか	回答は前四半期と同様です。 Google は、現在のプロテクテッドオーディエンスのデバイス上の入札設計に引き続き取り組んでいます。B&A サービスは、デバイスの計算能力やネットワーク速度が制限される可能性があるユースケースのサブセットをサポートするためのソリューションの検討を目的としています。
標準化	B&A サービスは標準化プロセスを経ていません。	B&A サービスの提案は標準化プロセスの 1 つのフェーズを終えようとしています。この目標達成に向けて、さらに多くの皆様のご参加をお待ちしています。この提案は（以前の提案に基づく）提案から始まり、W3C で広範な公開ディスカッションを通じて公開的にインキュベートされています。関心をお持ちのデベロッパーは、この提案を試用してフィードバックを提供できます。これは、こちらのブログ投稿に記載されているように、ウェブ機能の開発では一般的なパターンです。
KV サーバー	コンテンツ / コンテキスト / サイトターゲティング用に、購入者の KV サーバーに完全な URL を公開します。	このリクエストについては、こちらで議論しています。エコシステムからのフィードバックもお待ちしております。
ドキュメント	GitHub の「信頼できるコンポーネント/強制コンポーネントとオプションコンポーネント」のドキュメントは、独自のデプロイイメージとインフラストラクチャを持つ一部の広告テクノロジーで混乱を招いています。	Google は「信頼できるコンポーネント/強制コンポーネントとオプションコンポーネント」のドキュメントを改善しようとしています。このような作業に優先順位を付ける必要があるかどうか、エコシステムからご意見をお聞かせください。
API の改善	KV サーバー呼び出しの HTTP ステータスコードも、scoreAd() 関数でパラメータとして使用できる必要があります。	Google では現在、このリクエストを評価しており、エコシステムからの追加のフィードバックをお待ちしております。
ドキュメント	UDF の実行で JS ワークロードと WASM ワークロードがどのように正確に処理されるかについて、詳細情報を提供してください。	こうした情報を提供できるよう現在調査中です。こちらからフィードバックをお寄せください。
ドキュメント	リポジトリ名の更新リクエスト。	リポジトリの名前を「protected-auction-key-value-service」に変更しました。これは、このリポジトリが属するサービスのコレクションの用語に沿ったものです。このリポジトリには、Protected Audience サービスのディスカッションや Protected Auction サービスのドキュメントなどの他のリポジトリもあります。
ドキュメント	bidding_auction_services_gcp_guide.md から Cloud デバッガ API への参照を削除しました。	ドキュメントを更新し、該当する記述を削除しました。
API 使用量	KV ルックアップによって発生するレイテンシが 50 ミリ秒を超えている。100 ミリ秒近くかかります。他の販売者で効果的だった方法について、何かアドバイスはありますか？タイムアウトとタイミングを測定する方法について、何かご提案はありますか？	KV サーバー呼び出しは、スクリプトランナーのコンテキスト（Chrome ブラウザ内の特別な保護環境）内で行われます。これは、これらのスクリプトランナー内の情報を API 以外のアクセスから保護することを目的としています。詳しくは、こちらをご覧ください。
API 使用量	KV サーバーが特定の時間内に応答するためのタイムアウトはありますか？	販売者は、オークション構成で「perBuyerCumulativeTimeouts」フィールドを指定できます。このタイムアウトには、信頼できる入札シグナルの取得に必要な時間も含まれます。
レイテンシ	プライバシーサンドボックスチームはレイテンシの問題にどのように取り組んでいますか？	レイテンシを許容上限内に保つために検討している戦略については、こちらをご覧ください。

デジタル広告の測定

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

フィードバックテーマ	概要	Chrome の対応
手動によるキャンペーンの最適化	ARA では、キャンペーンの手動最適化はサポートされていません。	Google は、このシナリオについて広告テクノロジーと話し合い、ARA を使用して手動によるキャンペーンの最適化をサポートする方法を示しました。ARA は、広告テクノロジーをカスタマイズし、さまざまな広告テクノロジーユースケースを柔軟に解決できるように構築されています。提案されたいくつかのヒントには、さまざまな柔軟なイベントレベルの構成を使用する、イベントレベルレポートと概要レポートを使用してノイズの影響を軽減し、手動と自動の最適化ニーズを満たす、などがあります。ARA 構成のカスタマイズ性と柔軟性について、エコシステムからご意見をお寄せください。
コンバージョンの種類	Google で許可されているコンバージョンタイプは 8 種類のみで、制限されています。	柔軟なイベントレベルレポートの大部分を実装しました。これにより、広告テクノロジーは、レポート期間の数、アトリビューションレポートの数、使用できるトリガーデータのビット数に関して、より柔軟に設定できるようになります。広告テクノロジーは、最大 32 種類のコンバージョンタイプを測定できる構成を選択できます。
集計可能レポートのイベントの上限	集計可能なレポートごとに 20 件以上のコンバージョンイベントという数値の最小要件は、予算が限られている小規模な広告主様にとっては現実的ではありません。	集計可能なレポートごとに必要なコンバージョンイベントの最小数はありません。また、小規模な広告主様向けに集計可能なレポートを最適化するために、トラッキングするキー構造やディメンションの変更、さまざまなレベルのエプシロンのテスト、バッチ処理の頻度の長いテスト、測定目標間での貢献度予算のさまざまな割り当てのテストなど、さまざまな設計上の決定を行うことができます。小規模な広告テクノロジーでは、ノイズの影響を軽減するために、イベントレベルのレポートと概要レポートを組み合わせてテストすることもできます。
リアルタイムデータ	DSP が入札戦略の調整やキャンペーンの有効性の向上に使用するリアルタイムデータ（クリック、セッション、コンバージョンなど）を DSP から奪うことは、既存の機能を維持するという Google の取り組みに反するものです。	ARA を適用しても、クリックとセッションはリアルタイムで記録されます。コンバージョンは、サードパーティ Cookie を使用している場合でも、常に事後で記録されます。
未入力のフィールド	完全フレキシブルイベントのロールアウトで、i）通貨フィールド、ii）orderID / TransactionID フィールドの要件が満たされていません。	現時点では、完全なフレキシブルイベントレベルの一部として、通貨フィールドやオーダー ID / トランザクション ID フィールドをサポートする予定はありません。これは、現在のイベントレベルレポートですでにこれらのフィールドを取得できるためです。これらのフィールドに関するフィードバックをお寄せいただければ幸いです。また、これらのフィールドが必要なユースケースが他にもある場合は、再検討いたします。 ARA の現在の設計を使用して通貨と注文 ID の種類の情報を測定する方法は次のとおりです。 1. フィードバックに基づくと、通貨はユーザーの位置情報によって決まります。この位置情報は、使用された通貨を特定するために source_event_id の一部として追加できます。 2. フィードバックに基づき、コンバージョンと値が誤って重複してカウントされないようにするために、オーダー ID フィールドが必要となります。これは、重複除去キーを使用して行うことができます。
プライバシーバジェット	ARA プライバシーバジェットでは、複数のディメンションにまたがる測定機能が制限される	ARA は、アドテックが独自の ARA 構成をカスタマイズして、さまざまなアトリビューションシナリオに対応できるように設計されています。現在の ARA 設計では、広告テクノロジーは、測定に最も重要なディメンションと、ノイズがデータに与える影響とのトレードオフについて検討する必要があります。測定対象のディメンションの粒度に応じてデータにノイズを追加することは、プライバシー保護のために不可欠です。 Google は、さまざまなディメンションにまたがって測定できる機能について、エコシステムから追加のフィードバックをお待ちしておりますが、そのためには、これを必要とする具体的なユースケースを把握する必要があります。
仕様の更新	Google はイベントレポートの期間を固定から柔軟に変更したと発表していますが、これは Google の技術仕様に反映されておらず、現在も最小期間は 1 時間となっています。	現在、広告テクノロジーは柔軟なイベントレベルレポートを使用して、ソースイベントあたりのアトリビューションレポートの数、トリガーデータのビット数、レポート期間の数と長さを変更できます。ARA では、イベントレベルのレポートの最小レポート期間は引き続き 1 時間です。これは、プライバシーを維持し、特定の種類の履歴再構築攻撃を軽減するために不可欠です。概要レポートは集計情報を提供するため、広告テクノロジーは、ユースケースに応じて、集計レポートを遅滞なくすぐに受け取るようにオプトインできます。
API 設計	コンバージョンレポートの情報が減り、ノイズが増えることで、Google よりもエコシステムに大きな影響が及ぶ可能性があるという懸念。	Google は、CMA に対して、Google 自身のビジネスを優遇して競争を歪めない方法でプライバシーサンドボックスの提案を設計し、実装すること、およびデジタル広告の競争と、あらゆる規模のパブリッシャーと広告主への影響を考慮することを約束しています。
アトリビューションの修正	ARA では、技術プロバイダが正しいアトリビューションを管理、検証することはできません。	ARA には、検証機能を提供する多くのソリューションが用意されています。 1. 広告テクノロジーは、ARA の動作が想定どおりであることを確認できます。 – ARA クライアントサイドコードはオープンソースです。 – ARA サーバーサイドコードもオープンソースであり、コーディネーターは、集計可能なレポートを復号して処理できるのは、許可されたバージョンの集計サービスのみであることを確認します。 2. Chrome では、アトリビューションの動作を確認するためのシミュレーションライブラリを広告テクノロジーに提供しています。広告テクノロジーは、モック環境で ARA がアトリビューションをどのように実行するかをテストできます。 3. ARA は、想定どおりの処理が行われなかったかどうか、またその理由を確認するのに役立つ、さまざまなデバッグシグナルをサポートしています。
（前四半期にも報告あり）ノイズ	ノイズレベルが高すぎて、レポートの有用性に影響しているというフィードバック。	Google は、この点について広告テクノロジー企業と話し合い、ノイズがあってもユースケースに合わせて ARA をカスタマイズできる方法を特定しました。広告テクノロジーと協議した設計上の決定とカスタマイズのほとんどが記載されたデベロッパー向けドキュメントがあります。 ARA は、広告テクノロジーが独自の ARA 設定をカスタマイズして、さまざまなアトリビューションシナリオに対応できるように設計されています。ただし、広告テクノロジーは、測定に最も重要なディメンションと、データに対するノイズの影響とのトレードオフについて検討する必要があります。 Google は、ノイズの影響に関するエコシステムからのフィードバックを受け付けており、ノイズの影響を変更するために使用できる ARA レバーに関するガイダンスを提供できます。
クロスドメインアトリビューション	クロスドメインのアトリビューションをトラッキングするにはどうすればよいですか？	広告テクノロジーは、このユースケースに対応するために、別のレポート URL にリダイレクトできます。ARA のこの設計に関するエコシステムからのフィードバックをお待ちしております。
API の改善	ARA 概要レポートのアトリビューションを登録する際に使用するスケーリングファクタを定期的に変更します。	GitHub での議論に基づくと、Aggregation Service で複数のスケーリングファクタを処理すると、現在の機能と比較して概要レポートに追加されるノイズの量が増加する可能性があります。集計可能なレポートの一部としてスケーリングファクタの必要性について、引き続きフィードバックをお寄せください。ただし、ノイズの増加とトレードオフになる可能性がある点にご注意ください。また、今後の ARA の他の機能がこのユースケースの解決に役立つかどうかも検討しています。
API 使用量	アトリビューションイベントをすべての参加者と共有する方法を一元化できるため、SSP、DSP などにメリットがあります。	Google は、広告テクノロジーと連携して、広告テクノロジープロバイダからのフィードバックや、広告テクノロジープロバイダが直面している制限事項を把握する予定です。
テストトラフィック量	すべての Chrome のモード B のテストトラフィックは安定していますか？	テストグループへの参加は、Chrome の設定の影響を受けません（独立しています）。
ドキュメント	Google Pixel の ARA をサポート。	このユースケースをサポートする方法については、情報を公開しています。エコシステムからの追加のフィードバックもお待ちしております。
API 使用量	コンバージョンが最後のタッチによって行われなかった場合、e コマースプラットフォームのサードパーティ販売者の ARA は、正しいソースに帰属されないことがあります。	企業はフィルタを使用して、不正確なアトリビューションが発生しないようにすることができます（コンバージョンレポートが生成されないため）。また、このユースケースに対応するアトリビューション前フィルタリングのプロポーザルにも取り組んでいます。
対応ブラウザ	ARA は他のブラウザでもサポートされますか？	他のブラウザがプライバシーサンドボックス API を採用することを歓迎し、Google は W3C でオープンに Google のアプローチについて議論することに引き続き時間を割いています。 Google は、ARA のリリース目標として相互運用性を明記しており、ARA の設計は、プライバシーに関するスタンスが異なるベンダー向けにベンダー指定の値を柔軟に設定できる、ブラウザに依存しないことを意図しています。他のブラウザは、コンテンツとサービスのデジタルエコシステムをサポートできるクロスサイト識別子に代わる有効な代替手段を提供するかどうかを独自に選択しています。Microsoft Edge が ARA をサポートすることを示唆していることは朗報です。
API 使用量	registerAdBeacon/reportEvent（および navigation_start/commit 自動ビーコン）の ARA ソース登録で想定されるソースの種類は何ですか？	これらのビーコンが自動か手動かによって異なります。 - 予約済み。*イベント（自動イベント）をナビゲーションソースタイプにします。 - 手動でトリガーされたイベントで、イベントソースタイプ。
API 使用量	ソースごとに 20 件の集計レポートという上限は、ソースイベントごとに 20 件ということですか？この上限はグローバルですか？それとも 1 日あたりですか？上限を引き上げる予定はありますか？	ソースごとに 20 件の集計レポートという上限は、ソースごとに 20 件の集計レポートを作成できるというグローバルな上限です。この上限はブラウザによって設定され、変更できません。この上限の目的は、null レポートで実際のアトリビューションレポートの保護を不正使用しないようにすることです。詳しくはこちらをご覧ください。
API 使用量	ARA を使用したメールマーケティングのサポート。	現在、ARA ではこのユースケースを直接サポートしていません（メールホスティングサイトを管理していない場合）。この件についてはこちらで議論しており、皆様からのフィードバックをお待ちしております。
Epsilon	Aggregate API のイプシロン値はいつ決定されますか？	現在のイプシロン値は、プライバシーサンドボックスで定義された事前定義のしきい値（現在は 64）まで、広告テクノロジーで設定できます。さまざまなイプシロン値をテストし、独自のユースケースの変化点を見つけてフィードバックを提供することをおすすめします。イプシロン値の範囲を変更する際は、事前に広告テクノロジーに通知いたします。
API の改善	広告主様が trigger_data フィールドに識別子を挿入して外部 CRM データと照合し、コンバージョンの質を確認できるユースケースをサポートします。	リクエストについて現在検討中です。こちらから追加のフィードバックをお寄せください。
API 使用量	リダイレクト URL をリンク先 URL として処理する方法。	広告テクノロジーは、次のいずれかを行います。 1. 最終的なリンク先 URL をリンク先フィールド（ 2）に入力します。[リンク先] フィールドには最大 3 つの URL を指定できるため、複数の URL を指定できます。どちらのオプションでも、最終的なリンク先 URL を把握している必要があります。詳しくは、こちらをご覧ください。

集計サービス

フィードバックテーマ	概要	Chrome の対応
鍵検出メカニズム	鍵検出メカニズムのリクエスト	鍵検出の提案があり、この提案についてエコシステムからのフィードバックをお待ちしています。
API 使用量	集計サービスのオブザーバビリティのロードマップ	Google は、より多くのオブザーバビリティをサポートするオプションを検討しており、エコシステムからのフィードバック（こちら）を歓迎しています。
API の改善	レポートの再クエリをリクエストする。	集計サービスでは、広告テクノロジーがレポートごとにエプシロンを分割できるリクエストプロポーザルの開発に取り組んでいます。これにより、クエリごとにノイズが増える可能性がありますが、広告テクノロジーが再クエリを行い、プライバシーを維持できるようになります。
API の改善	複数のオリジンを同じ AWS ID に関連付けたい。	アグリゲーションサービスで、同じクラウドアカウント（Google Cloud または AWS）に複数のサイトをオンボーディングできるようになりました。これにより、広告テクノロジーは、複数のサイトや同じサイトの複数のオリジンからのレポートの処理に、同じ Aggregation Service エンクレーブを使用できるようになります。
API 使用量	集計可能なバッチが失敗した場合、予算が消費されたかどうか、バッチを再処理できるかどうかが不明です。集計サービスで重複するレポートの予算エラーが発生すると、残りのレポートはすべて失われます。この損失を最小限に抑えるにはどうすればよいですか？	通常、ジョブ全体が失敗した場合、予算は消費されません。予算が消費されるというまれなエラーが発生した場合、広告テクノロジーは予算の回復をリクエストできます。広告テクノロジーで、予算不足のエラーでジョブが頻繁に失敗する場合は、バッチ処理戦略を確認する必要があります。正しく一括処理して、重複するレポートやエラーを回避する方法については、こちらをご覧ください。予算の回復に関するフィードバックは、こちらからお寄せください。
API 使用量	こちらで説明されているトリガーで Private Aggregation API を使用すると、オークションごとに集計可能なレポートが生成されます。Aggregation Service のスケーリング機能は何ですか？	Aggregation Service 自体では、バッチ内のキー数やレポート数に上限はありませんが、必要なメモリ量が原因で、現在、10^14 件のレポートと 10^12 個のキーのスケールはサポートされていません。サイズ設定のガイダンスでは、想定される負荷とサポートされているクラウド VM インスタンスタイプを考慮して、最適なパフォーマンスを得るためにテスト済みの範囲が示されています。
データ処理	暗号化されたデータに個人情報が含まれている場合、暗号化されたデータを集約サービスに提供する法的根拠は何ですか？コーディネーターが暗号化されたデータにアクセスしないことが保証されているかどうか、教えていただけますか？	集計サービスは、暗号化されたデータやユーザーデータをコーディネーターと共有しません。集約サービスは、鍵管理とアカウンティングにコーディネーターを使用します。コーディネーターについて詳しくは、こちらをご覧ください。会計の場合、集計サービスは、予算使用量について PBS と共有 ID とレポート送信元のみを共有します。マルチサイトがリリースされると、origin は site に置き換えられます。集計サービスは TEE で実行されます。TEE は、クライアントからのレポートを復号できる唯一の場所です。TEE で実行されるコードはオープンソースであり、こちらに記載されているように外部関係者によって監査されています。

Private Aggregation API

フィードバックテーマ	概要	Chrome の対応
API 使用量	コンポーネント販売者が TEE 内の複数の集計サーバーにレポートを送信する機能。	現在の Private Aggregation API のステータスでは、この機能はサポートされていません。この問題について詳しくは、こちらをご覧ください。
ドキュメント	Google のトライアルで使用されるイプシロン値はどれですか？	Private Aggregation API の場合、集計サービスクエリで指定された ε 値は、10 分単位で適用される L1 コントリビューションバジェット 2^16 に対応します。また、24 時間単位で適用される 2^20 の「バックストップ」L1 コントリビューションバジェットもあります。つまり、プライバシーパラメータは、10 分単位で ε であり、24 時間単位で 16ε です（144ε ではありません）。集計サービスは現在、さまざまな集計戦略をテストし、プライベート集計やその他の API のさまざまなプライバシーパラメータを使用してシステムの有用性に関するフィードバックを提供する目的で、テスト用の ε の範囲（最大 64）をサポートしています。Google は、テスターからのフィードバックを得て、プライバシーバジェットをより効率的に使用できる機能を追加するとともに、許容される最大イプシロン値を今後見直す予定です。

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

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

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

IP 保護（旧 Gnatcatcher）

フィードバックテーマ	概要	Chrome の対応
解決 ID	プライバシーサンドボックスは、IP に基づいて構築されることが多い解決 ID が広告主様にとって持続可能ではないことを、より明確に主張する必要があります。	プライバシーサンドボックスでは、クロスサイトトラッキングの削減を目指していることを明確に示しています。Google の一般公開イニシアチブは、Cookie 以外のものも含め、privacysandbox.com と GitHub の両方で公開されています。Google は、IP アドレスに基づくトラッキングなど、クロスサイトトラッキングを減らすよう努めています。ただし、クロスサイトトラッキングを事前に有効にするかどうかは、最終的には個々のウェブサイトの判断に委ねられます。規制遵守に対する監視が強化されている時代において、個々の企業がサービスプロバイダが採用している手法を理解することは賢明な選択です。
Chromecast	IP 保護は Chromecast やその他の Chrome デバイスに影響しますか？	現在のところ、Chromecast デバイスに IP 保護を適用する予定はありません。
IP 保護リスト	ウェブ全体のクロスサイトトラッキングに IP アドレスを使用している可能性があると特定されたサードパーティのリストは公開されますか？	リストは、こちらで説明されているように、確定次第公開されます。

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

フィードバックテーマ	概要	Chrome の対応
シングルサインオン（SSO）の免除	バウンストラッキング緩和（BTM）は、免除対象の SSO のユースケースをどのように検証しますか？	BTM は Chrome ヒューリスティクスによって無効になります。詳しくは、説明をご覧ください。
非推奨トライアル	サードパーティ Cookie の廃止トライアルに参加しているサイトでは BTM が有効になりますか？	いいえ。BTM は、こちらで説明されているように、サポート終了トライアルで作成された Cookie 例外を尊重します。

プライバシーバジェット

GitHub の説明とデベロッパーサイトに記載されているとおり、プライバシーバジェットはプライバシーサンドボックスの提案の一部として積極的に検討されていません。

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

フィードバックテーマ	概要	Chrome の対応
機能のリクエスト	Storage Access API やユーザー操作を必要とせずに、RWS 全体で CHIP やストレージパーティショニングへのアクセスが自動的に許可されます。	Google では、この機能を実行する機能のメリットと実現可能性を検討しています。考慮すべき点の一つは、クロスブラウザの相互運用性に潜在的なギャップがあることです。RWS は Storage Access API を活用することで、この問題に対処しています。現時点では、他のブラウザでサポートされている、リクエストされた機能に相当するものはありません。デベロッパーの皆様は、この問題に関するユースケースをこちらに送信して、ディスカッションに参加することをおすすめします。
ポリシーに準拠していないセットの削除	ポリシーに準拠しなくなったセットをリポジトリから削除するプロセスを教えてください。	Google では、このプロセスの定義に取り組んでおり、最新情報が入り次第お知らせいたします。
違反措置の適用プロセス	RWS 違反措置プロセスにおける Google の主観的な役割が明確ではありません。	RWS は継続的なプロジェクトであり、新しい申請が引き続き寄せられているため、プロセスの一部と基準は現在も固められています。送信ガイドラインに送信要件を明記することは重要であると認識しており、今後は、あいまいさや混乱を避けるために、送信ガイドラインに詳細を追加していく予定です。送信プロセスをできるだけ技術的にすることで、人間の関与を段階的に廃止し、自動チェックに完全に依存することを目的としています。このような PR には予期しない動作が含まれているため、人間による操作がより必要になりますが、自動化の対象となる領域や、今後このような問題を回避するためにガイドラインを修正する方法などを特定できます。
データの共有	ドメイン所有者が、ユーザーの同意を得て、サードパーティが RWS データを共有することを希望できる機能のリクエスト。	リクエストされた機能は、ユーザーが権限プロンプトを承認した後に認証済み ID へのアクセスを可能にする FedCM や Storage Access API などの API ですでに利用できます。実現できないと思われる特定のユースケースについて、エコシステムからのフィードバックをお待ちしています。
その他のストレージ方法	ローカルストレージまたはセッションストレージに保存された情報も、サードパーティ Cookie として解釈されますか？	ローカルストレージ、セッションストレージ、その他の Cookie 以外のストレージは、サードパーティコンテキスト内で使用される場合、Chrome バージョン 115 以降でパーティショニングされています。詳しくは、こちらのブログ投稿をご覧ください。
関連セットの上限	「関連付けられたサイトは 5 つまで」と定められていますが、5 つを超えるドメインを登録した場合、どうなりますか？	これらのセットは GitHub のプロセスで承認されますが、ブラウザ（Chrome）は、こちらで説明されているように、最初の 5 つのドメインにのみ Storage Access API の自動付与ルールを適用し、残りのドメインは無視します。
find_robots_txt	find_robots_txt チェックはリダイレクトでは機能しません。	この問題を解決するための修正がこちらに送信されました。
ユーザージェスチャー	accessStorage() のユーザージェスチャーの要件を削除。	この要件は、requestStorageAccess API ですべての主要ブラウザに実装されている同様の設計に基づいています。この GitHub の問題で、このリクエストの優先度を決定し、ブラウザ間の議論を可能にするために、追加のフィードバックとユースケースをお寄せください。
ユーザージェスチャー	Chrome または OS の再起動後にサードパーティストレージへのアクセス権を付与するには、ユーザー操作が必要ですか？	はい。ただし、この動作を変更するかどうかについて、エコシステムからの追加のフィードバックをお待ちしております。こちらからご意見をお寄せください。

Fenced Frames API

フィードバックテーマ	概要	Chrome の対応
adComponent	フェンスドフレームを使用した AdComponent の使用に関するドキュメントと柔軟性の欠如。	このユースケースに関するドキュメントを今後公開する予定です。また、広告コンポーネントは、こちらの仕様で説明されている getNestedConfigs() を使用して、フェンスドフレームでサポートされています。
（前四半期にも報告） adComponent をレンダリングする	フェンスドフレームで adComponents をレンダリングする方法のサンプルコードをリクエストする。	サンプルコードについては、こちらで共有する予定です。
サードパーティによる広告検証	フェンスドフレームのコンテキストにおける第三者広告検証の役割について、特にコンテキスト/ブランド保護について詳しく説明する必要があります。	現在、フェンスドフレーム広告レポートでは、レンダリング後のブランドセーフティのチェックと課金のために、DSP がインプレッションとオークションのイベントレベルのデータを第三者広告検証ツールに送信できます。
エキスパンド広告	エキスパンド広告のサポートをリクエストする。	広告を同じアスペクト比の 2 つのサイズ間で切り替える必要があり、2 つのサイズに機能的な違いがない（サイズのみが異なる）場合は、埋め込み元が 2 番目の広告サイズでフェンスドフレームのサイズを変更できます。ブラウザはそれに応じてフェンスドフレーム要素をスケーリングします。
（前四半期にも報告）動画広告枠とネイティブ広告枠のサポート	フェンスドフレームは動画とネイティブ広告枠に対応していますか？	回答は前四半期と同様です。 PA API は、iframe に依存するメカニズムを使用して動画のレンダリングをサポートしています。ただし、フェンスドフレームに対応した動画広告とネイティブ広告のレンダリングソリューションはまだ設計されていません。これが、フェンスドフレームの適用を 2026 年に延期することにした理由の一つです。つまり、パートナーが今すぐフェンス付きフレームの適用を決定した場合、そのパートナーは動画とネイティブのサポートを失うことになります。
アドバイザリーボード	ネイティブ広告ベンダーのアドバイザリーボードを設置し、フェンスドフレームの実装が業界標準に準拠するよう求める。	2026 年より前に PA API でフェンス付きフレームを使用する必要はありません。この追加の期間により、Google は業界と連携して、より幅広い重要なユースケースのサポートを設計、実装できるようになります。以前お知らせしたとおり、Google は、PA API で動画広告とネイティブ広告のサポートを維持するための要件に先立って、フェンスドフレームを進化させます。Google は、CMA との約束に基づき、このような変更について CMA と連携し、CMA に通知します。また、フェンスドフレームの必須化に先立ち、エコシステムからのフィードバックを引き続き受け付けます。W3C や IAB Tech Lab などの広告標準化団体における Google のエコシステムエンゲージメントモデルでは、あらゆる業界の専門家が、必要になる前に設計をガイドできます。
（前四半期にも報告）プラットフォーム間でのサイズの違い	フェンスドフレームに表示されるコンテンツのサイズが、パソコンとスマートフォンで異なると報告されています。	これは Chromium の既知の問題であり、現在調査中です。フィードバックはこちらからお寄せください。
API の改善	ネイティブ広告がプライバシーサンドボックスでサポートされるようになったため、フェンスドフレームの要件が 2025 年に延期されましたか？	2026 年以降に予定されているフェンス付きフレームの適用について、公開のお知らせで説明したとおり、フェンス付きフレームに「対応するための多大な努力」が広範囲にわたって行われていることを確認いたしました。ネイティブ広告がその要因の一つであることは確かですが、それが唯一の要因ではありません。ネイティブを含む主なユースケースをサポートするエコシステムの準備を整えるために、より多くの時間を確保することが目的でした。

Shared Storage API

フィードバックテーマ	概要	Chrome の対応
パフォーマンス	ワークレット外の共有ストレージの返却時間は、ワークレット内のアクティビティに依存しているようです。	このテスト結果については、こちらで説明しています。
より広範な導入	共有ストレージは、ブラウザ間で利用できる業界標準である必要があります。	いただいたフィードバックは、今後の参考にさせていただきます。Chrome は、WICG など、W3C フォーラムに積極的に参加し、提案を推進し、フィードバックを求め、採用を促進しています。
入札ワークレット	generateBid（すでにワークレットで実行中）内で共有ストレージから読み取り、クロスサイト情報に基づいて広告の決定 / ビジネスロジック（フリークエンシーキャップなど）を適用し、広告のサブセットを選択することはできますか？	いいえ。入札ワークレット内で共有ストレージから読み取ることはできません。

CHIPS

フィードバックテーマ	概要	Chrome の対応
パーティションの容量	パーティション容量を超えた場合の動作を明確にしました。	容量に達すると、最も古い Cookie が、直近でアクセスされていない Cookie から強制排除され、上限を超えなくなるまでメモリが解放されます。デベロッパーは、後続のリクエストで更新された Cookie ヘッダーを確認できます。
サードパーティの iFrame へのアクセス	同じサードパーティサイトへの新しいタブ/ウィンドウを開く埋め込みサードパーティ iFrame コンテンツは、開いたサイトと同じパーティショニングされた Cookie にアクセスできる必要があります。	Google ではこのユースケースについて検討中です。こちらからエコシステムからの追加のフィードバックをお待ちしています。
重複する Cookie	同じ名前のパーティション Cookie とパーティションなし Cookie がある場合、ブラウザはどちらのキー値を送信することにしますか？	同じ名前の Cookie が 2 つある場合（1 つはパーティショニングされ、もう 1 つはパーティショニングされていない場合）、両方の Cookie が取得されます。残念ながら、どちらがどちらであるかを区別する方法はありません。この点に関する RFC 仕様はこちらで入手できます。この仕様では、Cookie が送信される順序に依存しないことが説明されています。
機能のリクエスト	オリジンパーティション Cookie を有効にする。	Google では現在、このリクエストを検討中です。エコシステムからの追加のフィードバックはこちらからお寄せください。

FedCM