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

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

2024 年第 1 四半期の四半期レポート。プライバシーサンドボックスの提案と Chrome の対応について受け取ったエコシステムからのフィードバックを要約しています。

CMA への取り組みの一環として、Google はプライバシーサンドボックスの提案の関係者エンゲージメントプロセスに関する四半期レポートを一般公開することに同意しました（コミットメントの第 12 項および第 17 項（c）（ii）を参照）。プライバシーサンドボックスのフィードバック概要レポートは、フィードバックの概要に記載されているさまざまなソースから Chrome に寄せられたフィードバックを集約して生成されます。たとえば、GitHub の問題、privacysandbox.com で入手できるフィードバックフォーム、業界関係者とのミーティング、ウェブ標準フォーラムなどです。Chrome ではエコシステムからのフィードバックを歓迎しており、学んだことをデザイン上の意思決定に取り入れる方法を積極的に検討しています。

フィードバックテーマは、API ごとの普及率によってランク付けされています。具体的には、特定のテーマについて Chrome チームが受け取ったフィードバックの量を集計し、量の多い順に並べ替えます。一般的なフィードバックのテーマは、公開ミーティング（W3C、PatCG、IETF）、直接フィードバック、GitHub、Google の社内チームや公開フォームを通じて表示されたよくある質問を確認することで特定されました。

具体的には、ウェブ標準団体会議の議事録が審査され、直接フィードバックについては、Google が行った 1 対 1 の関係者会議の記録、個々のエンジニアが受信したメール、API メーリングリスト、公開フィードバックフォームが考慮されました。Google は、これらのさまざまなアウトリーチ活動に関与したチーム間で調整を行い、各 API に関連して出現したテーマの相対的な普及率を判断しました。

フィードバックに対する Chrome の回答の説明は、公開されているよくある質問、関係者が提起した問題に対する実際の回答、特にこの公開報告のための立場の決定に基づいて作成されました。現在の開発とテストの焦点を踏まえ、特に Topics、Protected Audience、Attribution Reporting API に関する質問とフィードバックが寄せられました。

現在のレポート対象期間の終了後に受け取ったフィードバックには、Chrome の回答がまだ送信されていない可能性があります。

頭字語

ARA: Attribution Reporting API
CHIPS: Cookie に独立したパーティション状態がある場合
DSP: デマンドサイドプラットフォーム
FedCM: Federated Credential Management
FPS: ファーストパーティセット
IAB: Interactive Advertising Bureau（IAB）
IDP: ID プロバイダ
IETF: インターネット技術特別調査委員会
IP: インターネットプロトコルアドレス
openRTB: リアルタイムビッダー
OT: オリジントライアル
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 のテストフェーズが追加されます。	1 月初旬以降、現在の Chrome トラフィックの 1% を超えて Chrome を利用したテストを実施する予定はありません。
ウェブからアプリ	モバイルデバイスでの 3PCD は、ウェブとアプリの完全な相互運用性が実現されるまでに実施すべきではありません。	Google は、アプリとウェブの相互運用性をサポートすることが望ましいことに同意し、アプリとウェブをまたぐアトリビューション測定を開始し、ウェブからアプリへのターゲティングソリューションを検討しています。ただし、モバイルウェブでの 3PCD の提供を遅らせる予定はありません。3PCD の終了時に 100% のカバレッジを実現するという目標はありません。むしろ、Android でのアプリとウェブのクロス測定の互換性は 3PCD でかなり高く、ユーザーのスマートフォンのアップデートに伴い、時間の経過とともに向上することが期待されます。
ブラウザの役割	Chrome が広告サーバーまたは SSP の役割を担っているようです。	Chrome は広告サーバーや SSP の役割を担うわけではありません。PA API により、Chrome は広告サーバー、SSP、DSP などの広告テクノロジーにコンテナを提供し、独自の入札とスコアリングのロジックを導入します。
ユースケースに関するガイダンス	プライバシーサンドボックスの API でサポートされるユースケースに関する明確なガイダンス。	プライバシーサンドボックスプロジェクトが始まった当初、デベロッパー向けドキュメントは主に、すべての提案についてデベロッパーにディスカッションとフィードバックのプロセスに参加してもらうことに重点を置いていました。つまり、コンテンツは通常、プロジェクトの動機とコンセプトを理解したうえで、各提案の早期開発とテストの詳細を中心として構成しました。これは提案の開発において実際のエコシステムのコラボレーションを構築するうえで効果的でしたが、API の一般提供が進むにつれ、基盤の開発に貢献するのではなく、主に API で構築する開発者が新たに増えています。たとえば、最近の IAB の [Tasks Force] のナビゲーションが、 developer.google.com/privacy と IAB の [技術分類] レポートに更新されました。今後もドキュメントへのユースケースベースのアプローチを継続していきます。
ローカル開発環境	Cookie が SameSite=Secure で、バックエンドが CDN が前面にある場合に、http://localhost でフロントエンドの開発とテストをローカルで継続するにはどうすればよいですか？	この問題についてはこちらで議論しており、エコシステムからのフィードバックもお待ちしております。
3PCD 対策	3PC がブロックされていることを、またはヒューリスティックがいつアクティブであるかをプログラムで把握する方法はありますか？	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 は、パブリッシャーがコンテンツを制作し、可能な限り幅広いユーザーに公開するために広告に依存していることを認識しています。広告主は、ユーザーが探している新しい商品や特典を見つけるのに役立ちます。プライバシーサンドボックス機能を使うと、あらゆる種類のウェブサイト（コンテンツクリエイターと提携しているウェブサイトを含む）が、ユーザーの身元を明かすことなく、さまざまな関係者とのアクティビティに基づいて有用な広告を表示することができます。
タイムラインの明確化	プライバシーサンドボックステクノロジーのリリーススケジュールがより明確で詳細になりました。	プライバシーサンドボックス API のドキュメントには、API のステータスと提供状況のページが記載されています。このページには、リリース予定の機能とそのタイムライン（ PA API、 ARA など）が記載されています。これらのステータスはこちらで一元管理されています。
機械学習	3PCD が 1% を超えるまで、広告テクノロジーは ML モデルを適切にトレーニングできなくなります。	テスト用に 3PCD を利用できるブラウザを増やしても、API の使用量が増えるとは限りません。これはおそらく、広告テクノロジーが ML モデルをさらにトレーニングするために求めているものでしょう。広告テクノロジーが ML モデルをさらにトレーニングするために、より広範なエコシステムの利用を求めている場合は、3PCD を拡張する理由はありません。より多くのトラフィックでモデルをトレーニングしたい広告テクノロジーは、現在 3PCD を増やすことなくそれを行うことができます。これは、Chrome が停止状態の終了前に 3PCD で処理を進めているように見えない状態で実行できます。
サポートされていないユースケース	セルフサービス DSP のユースケースは、現時点では検討されていません。	セルフサービス DSP は複数あり、API に関する公開フィードバックを定期的に提供しています。定期的に公開フィードバックを提供している DSP のいくつかは、テスターとして登録されています。さらに Chrome は、動画や第三者広告サーバーなどの一般的なセルフサービス DSP トピックにも積極的に取り組んでいます。これらのトピックについては、最近の PA API 呼び出しに関する週次記事をご覧ください。
オリジントライアル	3PCD の積極的な立ち上げとテストカバレッジを希望するサイトの OT のリクエスト。	Chrome は現在、ファーストパーティの OT を開発しています。これにより、オリジンが 3PC の段階的廃止動作にオプトインできるようになります。このトライアルに登録してトークンをデプロイするトップレベルのオリジンは、ユーザーのデバイスでトラッキング保護が有効になっているかのように、3 台の PC がブロックされます。この OT は、CMA との協議を経て 3PC の最終的な段階的廃止に先立って、3PC に代わる長期的かつ広範なテストを行うサイトにとって貴重な機会となります。現在、OT のロールアウトのスケジュールの最終決定に向けて取り組んでいます。
IAB Tech Lab レポート	プライバシーサンドボックスに関するフィードバックは、IAB Tech Lab レポートからお送りします。	IAB Tech Lab のレポートについて詳しくは、こちらをご覧ください。また、「このレポートは断片化されたドキュメント、商業要件、第三者監査、業界の認定、スケーラビリティ、透明性、将来のガバナンスなどに関する疑問を投げかけており、エコシステムと連携し、それに応じて、公開されているよくある質問を更新する」ことも認めました。以前、断片化されたドキュメントに対処しました。Google はデータ保証に基づく商業要件に対処しており、一部の Google 広告サービスではそのアプローチを公開しています。こちらの「アルゴリズムの整合性保証」に基づいて第三者監査に対応しています。認証に関しては、各機関が単独でテクノロジーではなく、テクノロジーの使用を含め、プロダクトの認証を継続することが期待されます。スケーラビリティについては、問題を示すデベロッパーからのデータを引き続き受け付けています。透明性とガバナンスについては、コミットメントに基づいて CMA と連携しながら、GitHub や W3C などのフォーラムで公開で開発を続けています。
Google ログイン	Google ログインにより、Google はコミットメントに反して相互識別ログインデータを使用する可能性があります。	Google ログインは、Google がコミットメントに反するデータを使用できるようにするものではありません。
互換性	プライバシーサンドボックスの API のサポートや、上位 / 下位互換性の今後の計画について教えてください。	Chrome で機能の一般提供が開始された後も、その機能のサポートを維持することを目指しています。もちろん、後方互換性を維持することは必ずしも不可能です。そのような場合、Google にはこちらに記載のとおり、既存機能のサポート終了と削除に関する明確なプロセスがあります。サポートの改善によるメリットがあるユースケースに関するエコシステムからのフィードバックを受け、プライバシーサンドボックス API には今後も機能を追加していく予定です。そのような場合、新しい機能のテストに関心のある広告テクノロジーが、その機能がサポートされているかどうかを直接ブラウザに問い合わせることができるように、なんらかの特徴検出技術を導入する傾向があります。一部の機能は Chrome のすべてのユーザーに同時にロールアウトされない可能性があるため、特定の Chrome のバージョン番号を確認するようデベロッパーに依頼するよりも、この方法をおすすめします。たとえば、PA API の機能検出に関する作業については、こちらをご覧ください。
サーバーの実装	Chrome では、独自の実装と組み合わせるのではなく、Trusted Signals Server、Aggregation Server、その他の必要なブラウザ以外のコンポーネントの満足のいく実装が満たさなければならない動作を指定する必要があります。これにより、許容されるプライバシー境界の範囲内でイノベーションが可能になります。	Google は外部関係者によるイノベーションの要望に感謝し、歓迎します。Google は、すべての API とサービスについて、広告テクノロジーに機能を実装するための柔軟性を提供することを目指しています。たとえば、広告テクノロジーがオークションの入札ロジックを設計する際に、機密性の高いビジネス情報を使用することは許可されています。さらに、広告テクノロジーからのフィードバックにも継続的に取り組んでおり、妥当な場合はデザインに組み込みます。高信頼実行環境で他のユーザーが独自のコードを実行できるようにするには、プライバシーサンドボックスがコード（および変更）を審査し、プライバシー保証を満たしていることを確認する必要があります。これには、プライバシーサンドボックスチームの多大な労力が必要になります。したがって、ステークホルダーが現在私たちが満たしていないメリットは何かを把握する必要があります。
ヒューリスティック	ヒューリスティックの長期的な計画はどのようなものですか。	他のブラウザによる指摘を踏まえ、代替ソリューションが広く利用されるようになったため、Google では、さらなる実現可能性分析を経て、これらのヒューリスティックを最終的に廃止する予定です。こちらで共有いたしました。
テスト量	異なるディメンションを比較した場合、トラフィック量が異なる。	1% のテストでは除外基準が設定されており、Chrome クライアントの母集団によってテストの適格性に違いが生じる。たとえば、このテストでは Chrome Enterprise ユーザーが除外されているため、テストラベルの付いたトラフィックの割合は週末に多くなることが予想されます。さまざまなデータスライス（地域、日付、プラットフォームなど）でトラフィックの割合が異なることが想定されており、これは Chrome のデータで確認できる内容と一致しています。
3PC を手動で再度有効にする	3PCD の適用後に、Cookie を手動で再度有効にしたユーザーの割合（%）を把握できるようになりますか？	障害が発生した場合、ユーザーはユーザーバイパスを使用してサイトレベルで 3PC アクセスを再度有効にすることができます。3PC は、Storage Access API などの他の手段によって再度有効にすることもできます。hasStorageAccess() などの技術的な手段により、サイトは 3PC が有効か無効かを検出できます。ただし、Chrome では、ウェブサイトが再度有効にした理由を把握することはできません。
トラッキング防止機能	Chrome のトラッキング防止 UI 機能はいつまで利用できますか？	アドレスバーのトラッキング防止 UI は、3PC のサポート終了後も引き続き表示されることが見込まれます。
（前の四半期でも報告されています）クロスブラウザサポート	プライバシーサンドボックスの API を導入している他のブラウザベンダー。	Apple、Mozilla、Microsoft といった他のブラウザ・ベンダーも、プライバシーの原則やブラウザベースのアプローチが議論されている公開フォーラムに積極的に参加しています。最近の W3C の年次 TPAC 会議や進行中の W3C PATCG フォーラムなど、フォーラムでの共同議論に励みになり、収束の兆しが見えています。たとえば、Microsoft Edge は最近、PA API と ARA との「構文の互換性を最大化すること」を目指し、デベロッパー向けの追加機能を提供する計画を発表しました。
3PCD 以降に互換性のない埋め込みを行うためのフォールバックオプション	サードパーティの iframe や埋め込みが 3PCD に準拠しているかどうかを検出する API フックを提供する。	リクエストについてはこちらで検討しております。エコシステムからのフィードバックもお待ちしております。
テスト	カスタマイズされた動作を一時的にオフにする、Chrome のマネージドインスタンスで追加のフラグをリクエストします。	Google では、Chrome のマネージドインスタンスに対するこのリクエストを検討しています。このようなフラグが役立つのであれば、エコシステムからの追加のご意見を歓迎いたします。

登録と認証

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

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

トピック

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

Protected Audience API（旧 FLEDGE）

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

Protected Audience サービス

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

デジタル広告の測定

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

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

集計サービス

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

Private Aggregation API

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

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

ユーザーエージェントの情報量削減/ユーザーエージェント Client Hints

今四半期はフィードバックを受け取っていません。

IP 保護（旧 Gnatcatcher）

フィードバックのテーマ	概要	Chrome レスポンス
解決策 ID	プライバシーサンドボックスは、IP に基づいて構築されることが多い解決 ID が広告主にとって持続可能ではないことをより明確に伝える必要があります。	プライバシーサンドボックスは、クロスサイトトラッキングの削減を目指していることを明確に示しています。Cookie にとどまらない Google の公開イニシアチブは、privacysandbox.com と GitHub の両方で公開されています。Google では、IP アドレスに基づくクロスサイトトラッキングを含め、クロスサイトトラッキングの削減に努めています。ただし、クロスサイトトラッキングを有効にするかどうかは、最終的には個々のウェブサイトによって決まります。規制遵守に対する監視がますます厳しくなる中、個々の企業が自社のサービス・プロバイダーが採用している慣行を理解しておくことは賢明です。
Chromecast	IP Protection は Chromecast や他の Chrome デバイスに影響しますか？	現在のところ、Chromecast デバイスに IP 保護を適用する予定はありません。
IP 保護リスト	ウェブ全体のクロスサイトトラッキングに IP アドレスを使用している可能性があると特定された第三者のリストは公開されますか？	こちらに記載されているとおり、リストは確定次第、公開されます。

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

フィードバックのテーマ	概要	Chrome レスポンス
シングルサインオン（SSO）の免除	バウンストラッキング対策（BTM）は、SSO のユースケースの適用除外をどのように検証しますか？	BTM は Chrome ヒューリスティックによって無効になります。詳しくはこちらをご覧ください。
サポート終了トライアル	3PC のサポート終了トライアル中のサイトで BTM は有効になっていますか？	いいえ。こちらで説明されているように、BTM はサポート終了トライアルによって作成された Cookie の例外を受け入れます。

プライバシーバジェット

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

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

フィードバックのテーマ	概要	Chrome レスポンス
機能のリクエスト	CHIP やストレージパーティショニングには、Storage Access API やユーザーの操作なしで、RWS を介したアクセスが自動的に許可されます。	この機能を実行できる機能のメリットと実現可能性を検討しています。考慮事項の 1 つは、ブラウザ間の相互運用性に潜在的なギャップがあることです。RWS は、Storage Access API を活用することでこの問題に対処します。現在のところ、他のブラウザでは、リクエストされたこの機能に相当するものはありません。こちらからディスカッションを円滑に進められるよう、この問題のユースケースを送信することをおすすめします。
非準拠セットの削除	コンプライアンス違反になったセットをリポジトリから削除するプロセスは、どのようなものですか。	現在、このプロセスの定義に取り組んでおり、利用可能になり次第、最新情報をお知らせいたします。
施行プロセス	RWS の適用プロセスにおける Google の主観的な役割が不明確である。	RWS は進行中のプロジェクトであり、新たな提出物が引き続き寄せられているため、プロセスの側面と基準はまだ確定していません。提出ガイドラインでは、提出の要件を完全に説明することが重要であることは同意します。今後は、あいまいさや混乱を避けるために、提出ガイドラインに詳細を追加する予定です。 Google は、人手による関与を段階的に減らし、完全に自動チェックに依拠できるように、提出プロセスを可能な限り技術的にすることを目指しています。今回のような PR では、予想外の行動が含まれるため、人と人のやり取りが必要になりますが、自動化の領域を増やし、今後このような問題を回避するガイドラインを修正する方法を特定できます。
データの共有	ユーザーの同意を得たうえで、サードパーティも RWS データを共有することをドメイン所有者が示せる機能のリクエスト。	リクエストされた機能は、FedCM などの API や、ユーザーが権限プロンプトに同意した後に認証済み ID にアクセスできるようにする Storage Access API を通じてすでに利用できます。不可能と思われる特定のユースケースについて、エコシステムからのフィードバックをお待ちしています。
その他のストレージ方法	ローカルストレージやセッションストレージに保存された情報も 3PC と解釈されますか？	Chrome のバージョン 115 以降、サードパーティのコンテキスト内で使用されるローカルストレージ、セッションストレージ、およびその他の形式の非 Cookie ストレージは、Chrome ではパーティション分割されています。詳しくは、こちらのブログ投稿をご覧ください。
関連セットの上限	「関連付けられているサイトの数が 5 つに制限されている」にもかかわらず、5 個を超えるドメインを送信している組織はどうなりますか？	これらのセットは GitHub プロセスを介して受け入れられますが、ブラウザ（Chrome）は Storage Access API の自動付与ルールを最初の 5 つのドメインにのみ適用し、残りのドメインは無視します（こちらを参照）。
find_robots_txt	find_robots_txt チェックはリダイレクトでは機能しません。	この問題を解決するための修正がこちらに送信されました。
ユーザー操作	accessStorage() に対するユーザー操作の要件を削除しました。	この要件は、requestStorageAccess API について、すべての主要なブラウザで実施されている同様の設計に基づいて作成されました。このリクエストの優先順位付けと、ブラウザをまたいだディスカッションを可能にするため、こちらの GitHub の問題で追加のフィードバックやユースケースをお寄せください。
ユーザー操作	Chrome や OS の再起動後、サードパーティのストレージへのアクセスを許可するにはユーザージェスチャーが必要ですか？	はい。ただし、この動作を変更するかどうかについて、エコシステムからのフィードバックをこちらからお寄せください。

Fenced Frames API

フィードバックのテーマ	概要	Chrome レスポンス
adComponent	フェンス付きフレームで AdComponents を使用する際の文書化と柔軟性の欠如	このユースケースに関するドキュメントをさらに公開する予定です。また、広告コンポーネントは getNestedConfigs() を使用してフェンス付きフレームでサポートされています。詳しくは、こちらの仕様をご覧ください。
（前の四半期でもレポートされています） adComponent をレンダリングする	フェンス付きフレームで adComponents をレンダリングする方法に関するサンプルコードのリクエスト。	現在、いくつかのサンプルコードをこちらで公開できるよう取り組んでいます。
第三者による広告の確認	フェンス付きフレームのコンテキストにおける第三者の広告確認の役割については、特にコンテキスト/ブランド保護に関して、より詳細な情報が必要です。	現在、フェンス付きフレームの広告レポートでは、DSP がインプレッションとオークションのイベント単位のデータを第三者広告検証ツールに送信し、レンダリング後のブランド保護チェックと請求を行うことができます。
エキスパンド広告	エキスパンド広告をサポートするリクエストです。	広告で同じアスペクト比の 2 つのサイズを切り替える必要があり、両者に機能的な違い（サイズのみ）がない場合、埋め込みは 2 番目の広告サイズでフェンス付きフレームのサイズを変更し、それに応じてブラウザはフェンス付きフレームの要素をスケーリングします。
（前の四半期にも報告されています）動画広告枠とネイティブ広告枠のサポート	フェンス付きフレームは動画広告枠とネイティブ広告枠に対応していますか？	対応は前の四半期と同様です。 PA API は iframe を使用するメカニズムを使用した動画のレンダリングをサポートしています。ただし、フェンス付きフレームと互換性のある動画およびネイティブ広告のレンダリングソリューションはまだ設計されていません。これが、フェンス付きフレームの適用を 2026 年まで延期することを決定した理由の一つです。つまり、パートナーが今すぐフェンス付きフレームを適用することを決定した場合、そのパートナーは動画とネイティブをサポートできなくなります。
諮問委員会	フェンス付きフレームの実装が業界標準に準拠していることを確認するために、ネイティブ広告ベンダーの諮問委員会の設立をリクエストします。	2026 年より前は、PA API でフェンス付きフレームを使用する必要はありません。さらに時間の余裕をもって、引き続き業界と協力して、より幅広い重要なユースケースのサポートを設計、実装することができます。PA API で動画広告とネイティブ広告のサポートを維持するための要件に先駆けて、フェンス付きフレームを進化させることを事前にお伝えしました。Google のコミットメントに基づき、このような変更については CMA に通知し、引き続きエコシステムからのフィードバックを確認したうえで、Fenced Frames を必須にします。W3C や IAB Tech Lab などの広告標準化団体のエコシステムエンゲージメントモデルにより、あらゆる種類の業界エキスパートが設計が必要になる前にガイドできます。
（前の四半期でもレポートされています）プラットフォーム間のサイズの違い	フェンス付きフレームに表示されるコンテンツのサイズがパソコンとスマートフォンで異なると報告されています。	これは Chromium の既知の問題であり、現在調査中です。こちらからフィードバックをお寄せください。
API の改善	プライバシーサンドボックスでネイティブ広告をサポートするため、フェンス付きフレームの要件は 2025 年に戻されましたか？	2026 年より早く、フェンス付きフレームの適用に関する公式発表でお知らせしたとおり、Google は、フェンス付きフレームへの「対応に多大な労力」を費やしていることを知りました。確かに、そのうちの 1 つはネイティブでしたが、それだけが要因ではありません。その目的は、エコシステムが主要なユースケース（ネイティブユースケースを含むがこれらに限定されない）をサポートするための準備態勢を整えるための時間を十分に確保することでした。

Shared Storage API

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

CHIPS

フィードバックのテーマ	概要	Chrome レスポンス
パーティション容量	パーティション容量を超過した場合の動作を明確にしました。	容量に達すると、最も長い間アクセスされていない Cookie から最も古い Cookie がメモリに排出され、上限を超えなくなるまでメモリが解放されます。更新された Cookie ヘッダーは、後続のリクエストで確認できます。
サードパーティの iFrame アクセス	同じサードパーティのサイトへの新しいタブまたはウィンドウを開く埋め込みサードパーティの iFrame コンテンツでは、オープナーと同じパーティション化された Cookie にアクセスできる必要があります。	このユースケースについては説明しておりますので、こちらでエコシステムからのフィードバックをお待ちしています。
Cookie の重複	パーティション化された Cookie とパーティション分割されていない Cookie が同じ名前の場合、ブラウザはどの Key-Value を送信するかを決定します。	同じ名前の Cookie が 2 つ（1 つはパーティション分割され、もう 1 つは分割されていない場合）は、両方の Cookie が作成されます。残念ながら、どちらがどちらであるかを区別することはできません。これに関する RFC 仕様については、こちらをご覧ください。Cookie の送信順序に依存すべきではないことが説明されています。
機能のリクエスト	オリジンパーティション分割 Cookie を有効にする。	Google ではこのリクエストを検討しております。こちらからエコシステムからのフィードバックをお待ちしています。

FedCM