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

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

2022 年第 3 四半期の四半期レポート。プライバシーサンドボックスの提案と 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、Fledge、Attribution Reporting API に関する質問とフィードバックが寄せられました。

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

頭字語の用語集

チップ: 独立したパーティション状態を持つ Cookie
DSP: デマンドサイドプラットフォーム
FedCM: Federated Credential Management
FPS: ファーストパーティセット
IAB: Interactive Advertising Bureau
IDP: ID プロバイダ
IETF: インターネット技術特別調査委員会
IP: インターネットプロトコルアドレス
openRTB: リアルタイムビッダー
OT: オリジントライアル
PatCG: プライベート広告技術コミュニティグループ
RP: 証明書利用者
SSP: サプライサイドプラットフォーム
TEE: 高信頼実行環境
UA: ユーザーエージェント文字列
UA-CH: User-Agent Client Hints
W3C: World Wide Web Consortium
WIPB: 意図的な IP ブラインドネス

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

フィードバックテーマ	概要	Chrome レスポンス
（第 2 四半期にも報告）さまざまなタイプの関係者にとっての有用性	プライバシーサンドボックステクノロジーは大規模なデベロッパーに好まれ、ニッチな（小規模な）サイトが汎用的な（大規模な）サイトよりも多くの貢献をするのではないかという懸念。	第 3 四半期の更新: Google は CMA に対し、Google 自身のビジネスを自己優先することで競争をゆがめない方法でプライバシーサンドボックスの提案を設計、実装し、規模に関係なく、デジタル広告およびパブリッシャーおよび広告主との競争への影響を考慮するよう努めています。YouTube は、今後も CMA と緊密に連携し、Google の取り組みがこれらのコミットメントを遵守できるようにしていきます。プライバシーサンドボックスのテストが進むにつれ、Google が評価する主な質問の一つは、新しいテクノロジーがさまざまなタイプの関係者に対してどのように機能するかということです。この点においてフィードバックは重要です。特に、技術設計のさらなる改善に役立つ具体的で実用的なフィードバックは重要です。 Google は CMA と協力して定量テストのアプローチを開発してきました。また、市場参加者により多くの情報を提供し、提案されたアプローチについてコメントする機会を提供するために、CMA がテスト設計に関する注記を公表することを支持しています。
（第 2 四半期にも報告）ドキュメントのリクエスト	テスト、分析、実装の管理方法を詳しく説明したリソースのリクエスト	第 3 四半期の更新: 現在公開している資料が皆様のお役に立てば幸いです。これからも数週間から数か月かけてさらに多くの資料を提供していく予定です。これにより、デベロッパーは新しいテクノロジーがどのように役立つかを理解できます。また、ベストプラクティスやデモを共有する公開デベロッパーオフィスアワーセッションや、プロダクト/エンジニアリングリーダーとの Q&A セッションを実施し、ライブディスカッションや質問のためのセッションを開催しました。
クロスブラウザサポート	プライバシーサンドボックス API を導入している他のブラウザベンダー。	Apple、Mozilla、Microsoft といった他のブラウザベンダーも、プライバシーの原則やブラウザベースのアプローチが議論されている公開フォーラムにも積極的に参加しています。最近の W3C の年次 TPAC 会議や、進行中の W3C PATCG フォーラムなど、収束の兆しが見えているフォーラムでの共同ディスカッションが奨励されています。
プラットフォームの違い	移行に必要なリソースを削減するために、ウェブと Android で機能セットを可能な限り調整することをリクエストします。	業界内で混乱や断片化が生じないよう、Google は Chrome と Android のアプローチを一致させるよう努めています。Google のアプローチの相違は主に、ウェブとモバイルアプリプラットフォームに必要な技術的違いによるもので、デベロッパーはすでに考慮されています。
プライバシーサンドボックス API をテストするためのリソース	十分な割り当てが困難現在の経済的逆風を考慮してプライバシーサンドボックス API をテストするためのリソースを提供する。	Google では、複雑さを緩和し、API の採用を支援するために、テスターが利用できるドキュメントとサポートを継続的に改善しています。たとえば、API 固有のメーリングリスト、公開オフィスアワー、developers.chrome.com における継続的な更新などを実施しています。
サンドボックス API のオプトアウトシグナル	広告テクノロジーとウェブサイトが使用できる「ユーザーがサンドボックス API をオプトアウトしました」というシグナルを提供するリクエスト。	「サードパーティ Cookie を無効にする」といったユーザーの選択にウェブサイトが反応して、ユーザーに設定を変更するよう強く求めるケースはこれまでに多く見られており、同意しなければウェブサイトへのアクセスがブロックされることもあります。オプトアウトシグナルは、フィンガープリントの追加のシグナルとして使用されることもあります。現時点では、Google はオプトアウトシグナルを提供する予定はありません。
（第 2 四半期にもレポート）。明確なスケジュール	より明確で詳細なリリーススケジュール	第 3 四半期の更新: 「フィードバックにお応えしての変更点」のセクションで説明したように、Google は 7 月にプライバシーサンドボックスのタイムラインを更新しました。これにより、市場に予備テストとフィードバックのための期間と、プライバシーサンドボックス API が完全リリースされてから、サードパーティ Cookie が廃止される前にテストを行うための期間を延長しました。
（第 2 四半期にもレポート）。サードパーティ Cookie のサポート終了スケジュール	サードパーティ Cookie のサポート終了に伴うさらなる遅延を回避するリクエスト	第 3 四半期の更新: Chrome は 7 月に、サードパーティ Cookie の廃止に関する新しいスケジュールを発表しました。このスケジュールは、この技術の複雑さとエコシステムにおける重要性を考慮し、責任を持って行動するという Google の取り組みを反映したものです。この変更が行われる前に規制機関や業界からのフィードバックを考慮し、Google はすべての関係者と密接に連携し続けています。
ファーストパーティの Cookie	ファーストパーティの Cookie の制限も提案されているか？そうであれば、長期的な安定性に関する懸念や、ブラウザの変更による予測が困難になるため、エンジニアリングの労力が無駄になってしまいます。	ファーストパーティの Cookie に関する制限は一切考慮していません。プライバシーサンドボックスでは、サードパーティ Cookie のサポート終了に重点を置いています。

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

トピック

フィードバックテーマ	概要	Chrome レスポンス
（第 2 四半期にもレポート）。さまざまなタイプの関係者にとっての有用性	サイトのトラフィック量やコンテンツの特化度に応じたサイトの有用性について懸念が寄せられています。	第 3 四半期の更新: API の有用性は、テストを通じて検証されます。コミットメントの第 17.c.ii 項で義務付けられているとおり、Google はかかるテストの結果を CMA と共有します。Chrome では、テスト結果に基づいて分類やその他のパラメータが進化することが想定されています。分類やパラメータの進化によって、下位互換性のない変更が不要になる場合があります。また Chrome では、サードパーティ Cookie のサポートが終了した後も、Topics API の進化に影響を与えるフィードバックが引き続き続くと予想しています。
プライバシー/ポリシー	呼び出し元ごとのトピックフィルタリング要件を削除するリクエスト。	プライバシー KOF、プライバシーアドボケイト、セキュリティエキスパート、デジタル著作権グループなどのエコシステムからのフィードバックに基づき、Chrome では、他の方法で情報にアクセスできるユーザーにのみ情報へのアクセスを許可するため、この設計を採用しました。その理由には、クロスサイドでの増分データ漏洩の制限、透明性と説明可能性の確保、実装と説明が容易なアプローチの採用、フィンガープリントのリスクの制限などが挙げられます。Topics を受け取るパブリッシャーやサードパーティは、サイトでどの情報をサードパーティと共有するかを自身で決めることができます。第三者がこの情報を共有する場合、Chrome では、そうした情報の共有についてユーザーに対して透明性を確保し、ユーザーが管理できるようにすることを強く推奨しています。
不適切なカテゴリのサイト	サイトが間違ったトピックに正しく分類されているため、広告のターゲット設定の精度が低下する可能性があります。	サイトは、最も人気のあるサイトを含むオーバーライドリストとオンデバイス ML モデルを組み合わせて分類されます。Chrome では、Topics 分類にサイトを組み込む方法を引き続き評価しています。ユーティリティを改善する場合は、プライバシーや不正使用のリスクを比較検討する必要があります。たとえば、次のようなリスクがあります。さまざまな（そしてデリケートな可能性のある）意味をトピックにエンコードする方法として、セルフラベリングを使用しているサイト金銭的な利益を得る目的でトピックを不実表示しているサイトトピックを攻撃して、他者にとっての有用性を損なう（例: ユーザーのトピックに無意味なノイズでスパム行為をする）サイト人々は chrome://topics-internals またはこちらの Colab から利用できるツールを使用して、これらのコンポーネントを検査できます。分類はテストを経て改善されていく見込みです。誤って分類されている可能性のあるサイトの例について、フィードバックをお寄せください。
アクセス要件	アクセスのためにページ上の DOM エンティティをスクリプトまたは iframe として必要とする現行の Topics 要件は、広告エコシステム内のプレーヤーによる望ましくない動作につながる可能性があります。	GitHub の説明の変更点を統合しました。HTTP ヘッダーで Topics をサポートする予定です。
Topics の分類の粒度が十分でない	現在のトピックの分類は範囲が広すぎるため、地域のトピックなど、より細かいトピックは含まれていません。	分類の改善は継続的な取り組みであり、エコシステムのテストと入力によって分類も進化することが期待されています。分類について、エコシステムに最も適した分類について積極的にフィードバックをお待ちしています。トピックの数を拡大するか、より詳細なトピックを含めるかを検討する際は、1）プライバシーへの潜在的な影響（トピックが増えるとフィンガープリントのリスクをもたらす可能性があるなど）、2）以前に観測されたトピックを取得できる機能（トピックが多いほど、アドテックが過去に選択したトピックを見た可能性が低くなる可能性がある）などの考慮事項があります。Google は #2 の拡張として、実用性とプライバシーの両立を目指し、呼び出し元が既存のフィルタ要件の範囲内で以前に確認したトピックを取得できる機能を最大化することを目指しています。
トピックの上限	ウェブサイトごとにトピックを 3 つにすると、広告主が広告を配信するのに情報が少なすぎます。	エコシステムからのフィードバック、特にオリジントライアルのテスト結果は、今後も API の進化に影響を与えます。なお、Topics は、コンテンツターゲットなど、他のシグナルを補完するもので、訪問者に適した広告を見つけるのに役立ちます。そのため、トピック以外の情報を広告主に提供できる可能性があります。
（第 2 四半期にもレポート）。ユーザーコントロールと安全	あるトピックが機密グループのプロキシである場合があり、ユーザーは、ネガティブな結果を回避するためにより詳細な制御を必要とします。	第 3 四半期の更新: トピックは、ユーザーによる制御と透明性のために大きな前進となります。ユーザーは、トピックをオプトアウトしたり、自分に割り当てられているトピックを確認したり、トピックを削除したり、特定のページでユーザーがトピックを利用している企業を把握したりできるようになります。また、トピックの抽出元となった閲覧履歴を削除して、Topics を消去することもできます。これらのコントロールは現在、Chrome ブラウザにデバイスレベルで実装されています。デベロッパーが推奨するものなど、より高度なユーザーコントロールについては引き続き議論を望みますが、新たに追加された機能は懸念事項に対処できるよう十分に調整され、部分的に変更されないようにする必要があります。
SEO への影響	パブリッシャーが Topics に合わせてウェブサイトのホスト名を調整すると、SEO に悪影響を及ぼす可能性があります。	Google では、Topics のためだけにサイトがホスト名を変更しないよう注意します。サイトは、割り当てられたトピックにこのように影響を与えることができる可能性があります。とはいえ、パブリッシャーにとってのメリットはよくはっきりしません。サイトが分類モデルを「操作」しようとすると、エコシステム全体に対する Topics の価値が損なわれます。トピックの割り当ても固定されていません。テストと入力によって分類は進化し続けると予想しています。このテストについては、正しく分類されていないサイトの例など、フィードバックをお寄せください。
不正行為、不正使用	表示されるトピックが実際にブラウザによって生成されたことをバイサイドパーティが確認する方法を用意する。	プログラマティック広告オークションで販売者から渡されたトピックを、広告テクノロジーの購入者が確認するためのメカニズムを提供していただけることを嬉しく思います。こちらから、エコシステムの活発な議論に参加するようおすすめしています。Google では現在、優先順位の高いその他の改善に重点を置いていますが、今後この設計面で重要な改善が加えられることも認識しています。
不正行為、不正使用	ファーストパーティセットの対象になるのと同じ種類の公開投稿およびレビューを通じて、Topics データの正当なユーザーである当事者の公開レビューを許可します。	このご提案に感謝し、公的な説明責任がプライバシーサンドボックスの目標達成に役立つ重要なツールであることに同意しています。Topics API の呼び出しは、誰でもサイトにアクセスして JavaScript API へのドメインの呼び出しを監視できるため、本質的に公開されます。これにより、個人や組織は該当するアクティビティを確認して、どのサイトが Topics をどのように使用しているかを評価できます。Google は、サイトの「正当性」を評価することよりも、Topics API 自体の機能にこの方法のほうが適していると考えています。
自社シグナルへの影響	Topics シグナルは価値が高い場合があり、その結果、他のファーストパーティのインタレストベースシグナルは価値が下がります。	Google は、インタレストベース広告がウェブの重要なユースケースであると考えており、Topics はそのユースケースをサポートするように設計されています。前述のとおり、エコシステムの他のステークホルダーからは、Topics が価値を提供するのに十分ではないという懸念が寄せられています。いずれの場合も、分類法の改善は継続的な取り組みであり、エコシステムのテストとインプットによって分類も進化することが期待されています。

FLEDGE

フィードバックテーマ	概要	Chrome レスポンス
FLEDGE オークション	SSP が FLEDGE オークションへの入札のために Google 広告に送信するデータの形式について説明します。	テストに参加する企業は、テスト計画に関するドキュメントを公開し、必要に応じて連携することをおすすめします。 Google は CMA と協力して定量テストに対するアプローチを開発しました。また、トライアルに参加する予定の市場参加者により多くの情報を提供し、提案されたアプローチについてコメントできる機会を提供するため、CMA によるテスト設計に関する注記の発表を支援しています。アドマネージャーチームでは、アドマネージャーを広告サーバーとして使用しているパブリッシャー様による FLEDGE のテストに関心をお持ちの販売者様向けのドキュメントを、こちらに投稿しています。その他の技術的な詳細については、こちらをご覧ください。
ネストされたフェンス付きフレーム内の FLEDGE	フェンスを使用したフレームではテストの制限が緩やかになり、将来的には制限が増えます。この未知のタイムラインは、エコシステムに課題をもたらしています。	企業は Fenced Frames を使用して FLEDGE を今すぐテストできます。オンボーディングを容易にするオプションとして、最初に FLEDGE を実装するという方法があります。FLEDGE の実装後、FLEDGE 設計でフェンス付きフレームをテストできます。
データの取り扱いポリシー	インタレストグループ / FLEDGE のデータ処理ポリシーについて教えてください。	FLEDGE の設計では、インタレストグループに保存されているすべてのデータ、つまりどのユーザーがどのインタレストグループに所属しているかに関するすべてのデータは、デバイス上に保持されます。これらのデータが Google のサーバーに送信されることはありません。 Chrome で FLEDGE 向けに計画されているプライバシー保護には、Google が実行する k-匿名性サーバーとのやり取りも含まれます。このインタラクションは、ユーザーに関する情報の共有を避け、高信頼実行環境（TEE）で実行されるように慎重に設計されており、広告エコシステム全体で情報の同等性が確保されます。 \ Google は CMA に対し、Google 自身のビジネスを自己評価することで競争をゆがさないようにプライバシーサンドボックスの提案を設計、実装し、デジタル広告の競争、およびパブリッシャーおよび広告主への影響を考慮することに取り組んでいます。Google は引き続き CMA と緊密に連携して、Google の取り組みがこれらのコミットメントを遵守するようにしています。
年齢に関するポリシー	Chrome では、FLEDGE が作成したオーディエンスが年齢制限を遵守していることをどのように保証していますか？	パブリッシャー様と広告主様は、FLEDGE を使用して作成するオーディエンスが適用される法律を遵守しているかどうかを評価していただけるのが最善です。ユーザー保護を強化するため、Chrome にログインしているユーザーに対しては、テスト期間中であっても 18 歳未満のユーザーはプライバシーサンドボックスの API を有効にしません。（ログアウトしたユーザーについては、ブラウザがユーザーの年齢を推測できるプロフィールシグナルは収集されません）。
FLEDGE の Key-Value サービス	FLEDGE の Key-Value サービスで許可される機能（鍵の数や更新頻度など）がより明確になります。	FLEDGE を使用する企業は、RAM に格納できる数だけキーを保持できます。詳しくは、こちらの説明をご覧ください。 Google では、データ変更のより迅速な方法を提供することを目指しています。また、あらゆる要件に関する提案を歓迎いたします。
テスト	Google 広告で FLEDGE をテストするのが難しい	オリジントライアルに参加してテストを行う最適な方法については、Google 広告のオンボーディングドキュメントをご覧ください。
入札とオークションサービス API	Bidding and オークション Services API に対する Google の方針はどのようなものですか？デバイスオークションで Chrome ブラウザ FLEDGE より優先されますか？それとも下優先されますか？	Google は、現在の FLEDGE オンデバイス入札の設計に引き続き取り組んでいます。入札サービスとオークションサービスは、デバイスの演算能力やネットワーク速度が制限される可能性がある一部のユースケースをサポートするソリューションとして提案されています。
集計レポート	generateBid で利用可能なすべてのシグナルに基づく集計レポートをサポートするリクエスト。	詳細については、近日中に公開する予定です。
コンテキスト広告	FLEDGE でコンテキスト広告を配信する。	Google ではこのオプションを検討しましたが、こちらの説明で説明されている理由により、現時点ではコンテキスト広告で FLEDGE を使用することはおすすめしません。
実際のテスト	実際のテストで FLEDGE をサードパーティ Cookie から分離する方法に関するガイダンス。	検査対象集団を提供する方法を検討しています。 Google は CMA と協力して定量テストのアプローチを開発してきました。また、市場参加者により多くの情報を提供し、提案されたアプローチについてコメントする機会を提供するために、CMA がテスト設計に関する注記を公開することを支持しています。
FLEDGE と Attribution Reporting API のテスト	FLEDGE で Attribution Reporting API を実装する最適な方法は何ですか？FLEDGE とアトリビューションを別々に、またはまとめてテストするのがおすすめですか？	最終的には、統合ソリューションとして FLEDGE と Attribution Reporting API の両方のテストをサポートする予定ですが、デベロッパーはまず Attribution Reporting API を個別にテストし、統合が完了したら FLEDGE でテストすることをおすすめします。
入札単価の可視性	入札単価の難読化のリクエスト。	「generateBid()」または「scoreAd()」内にブレークポイントを設定して、DevTools から入札単価の値にアクセスすることもできます。Chrome チームは、この FLEDGE へのフィードバックで提起された限定的な攻撃ベクトルを検討しました。しかし、Chrome のセキュリティとプライバシーモデルでは、ユーザーが自分のデバイス上で情報を使ってできることは信頼できるものと見なしているため、要求に応じて入札データを非表示にする現実的な方法はありません。
ドキュメントのリクエスト	実際のエコシステムでのテストに関するドキュメントと例。	現在公開している資料が皆様のお役に立てば幸いです。これからも数週間から数か月かけてさらに多くの資料を提供していく予定です。これにより、デベロッパーは新しいテクノロジーがどのように役立つかを理解できます。また、外部デベロッパーオフィスアワーでは、ベストプラクティスやデモを共有するほか、プロダクト/エンジニアリングリーダーとの Q&A セッションを行い、ライブディスカッションや質疑応答の時間を設けています。
Private Aggregation API	Private Aggregation API の詳細について	公開されている説明用資料には、現時点で Google が提供できる最新情報が記載されています。この API の開発とユースケースの定義に伴い、追加のドキュメントが提供される予定です。
データレイテンシ	FLEDGE の Key-Value サーバーのデータ取得はリアルタイムで行われますか？	GitHub の未解決の問題で説明されているように、クエリに対してサーバーから更新されたデータが返されるまでに、数時間ではなく、数分程度の少量の未更新データが発生する可能性があります。また、デベロッパーの皆様からのフィードバックもお待ちしております。
入札とオークションサービス	入札やオークション（B&A）のサービスを利用している場合、ユーザーには入札単価は表示されませんか？	B&A のサーバーサイドアプローチでは、入札リクエストは SSP オークションサービスから DSP オークションサービスに直接送信されるため、ブラウザでは使用できなくなるため、個別の入札単価はユーザーに表示されません。ただし、落札した入札価格は引き続きブラウザに表示されます（入札価格を難読化するリクエストについて、上記で詳しく説明します）。
入札とオークションサービス	入札サービスとオークションサービスの負荷をバランスよく行うには、どうすればよいですか。	現時点ではロードバランシングに関するガイダンスはありませんが、パフォーマンスとプライバシーの両方の観点から重要な懸念事項です。今後、詳細をお知らせいたします。
FLEDGE の上限	JoinAdInterestGroup の期間の上限を 30 日から 90 日に延長するリクエスト。	30 日間のデータ保持期間は、Attribution Reporting の 30 日間の制限や、Topics の 3 週間の振り返りなど、プライバシーサンドボックスの広告 API の他のものと同等であると考えています。この期間は、広告テクノロジーのニーズとプライバシーに関するユーザーの期待の両方に対応しています。こちらでこの問題について引き続き検討してまいりますので、さらなるフィードバックをお待ちしております。
FLEDGE の共有ストレージ	FLEDGE で Shared Storage API を使用できますか？	Google は、今後 FLEDGE で Shared Storage API をサポートする予定で、今後のオリジントライアルで利用できるようにする予定です。
クリック数によるフリークエンシー管理	FLEDGE では、落札数ではなくクリック数にフリークエンシーキャップを設定できますか？	FLEDGE では、Fenced Frame が navigator.LeaveAdInterestGroup() を（パラメータなしで）呼び出せることを指定します。この呼び出しは、フリークエンシーキャップの一形態として、今後の入札を防ぐために、最初のクリックの受信時に初めて実行することもできます。現時点では、この方法では複数回クリックした後にキャップを設定することはできません。
ネストされたフェンス付きフレーム内の FLEDGE。	ネストされたフェンス付きフレームで発生したクリックは、フェンス付きフレーム広告のレポートでレポートできません。	この問題を修正するための提案をこちらに公開しました。
測定対象	FLEDGE オークションでビッダーのレイテンシデータを収集する方法についてガイダンスが必要です。	パフォーマンス測定に関するドキュメントをまもなく公開する予定です。
レポート	FLEDGE のレポートはどのように処理されますか？	落札、オークション結果、イベント（クリックなど）に関する FLEDGE レポートは、reportResult() などの FLEDGE API を通じて利用可能になります。広告コンバージョンに関するレポートでは、Attribution Reporting API との統合は FLEDGE から独立していますが、考えられるアプローチについてエコシステムと継続的に協議されています。 Private Aggregation API を使用して、隔離された実行環境内からオークション結果をレポートすることもできます。こちらの説明をご確認ください。
インタレストグループの規模	広告テクノロジーがインタレストグループの規模（グループ内のユーザー数）を確認する方法はありますか？	インタレストグループのメンバーは、ブラウザによってユーザーのデバイスに保存され、ブラウザのベンダーなどとは共有されません。ただし、理論的には、インタレストグループのオーナーは、navigator.joininterestgroup(...) へのすべての呼び出しを追跡できます。この呼び出しを追跡しても、IG の正確なサイズが保証されるわけではありません（ユーザーはいつでもグループを退会できるため）、オーナーには上限とおおよそのサイズが表示されます。
パフォーマンス	入札の JS/WebAssembly コードはオークションごとにコンパイルされていますか？	入札 JS/WebAssembly コードは、オークションごとに 1 回コンパイルされます。
パフォーマンス	BiddingDurationMsec の範囲を教えてください。	BiddingDurationMsec にはスクリプトのコンパイル時間が含まれます。これには、ダウンロード時間、Wasm コンパイル時間、ネットワーク時間、Key-Value サーバーからの取得時間など、JS コンパイル前の時間は含まれません。
カスタマイズ	ユーザーに合わせてカスタマイズするように adComponent を更新することはできますか？	インタレストグループが更新されたときに adComponent が更新されるのは、参加者によって joinInterestGroup を呼び出したとき、または Chrome が dailyUpdateURL を呼び出したときです。これにより、呼び出し元は、現在のサイトのユーザーの知識または k-匿名性の情報に基づいて、adComponent を更新できます。商品レベルの turtledove の元の提案はこちらで確認できます。これには、レコメンデーションのユースケースの主な指標に対する RTB House の分析結果が含まれています。
インタレストグループ	インタレストグループのオーナーが、条件付きで特定のユーザーを削除することは可能ですか？	インタレストグループメンバーはユーザーのブラウザにのみ保存され、ユーザー側でのみ削除できます（サイトデータを消去するなど）。ただし、インタレストグループのオーナーが管理しているページにユーザーが戻った場合、インタレストグループのオーナーは、（条件付きロジックを指定して）navigator.LeaveAdInterestGroup() を呼び出すことができます。
パフォーマンス	generateBid のパフォーマンスを測定する方法	コンパイルと実行時間は、bidDurationMsec で測定できます。ダウンロード時間は chrome://net-export で測定できます。Chrome の最近のバージョンでは、コンパイル時間と実行時間が DevTools の [パフォーマンス] タブに表示されます。
インタレストグループの更新頻度	インタレストグループがブラウザから更新される頻度はどれくらいですか。	インタレストグループが過去 24 時間以内に更新されていない場合は、navigator.updateAdInterestGroups() が呼び出されたとき、またはオークションに参加する機会を得たときに、インタレストグループの更新を試みます。詳しくは、こちらの説明をご確認ください。
集計サービスプロバイダ	他のクラウドプロバイダはいつ集計サービスでサポートされますか？	現時点では、具体的な時期についての最新情報はありませんが、詳細が決まり次第お知らせいたします。現時点では、集計サービスのセキュリティ要件を満たしているのは AWS のみです。
FLEDGE テストのスケジュール	FLEDGE はどのくらいの期間 BYOS でテストされますか？BYOS モデルから TEE ベースのモデルに切り替えるのに十分な時間はあるか。	エコシステムで十分な時間テストを行えるよう、サードパーティ Cookie が廃止されるまでは TEE の使用は必須とされません。この移行が行われる前に、テストと導入を開始するようデベロッパーに十分に通知します。現時点では、これ以上の更新はありませんが、詳細が決まり次第お知らせいたします。最新情報については、こちらをご覧ください。
データサイズの上限	入札機能の Wasm のデータサイズの上限はどれくらいですか。	こちらで説明しているように、インタレストグループの更新によりインタレストグループが 50 KB を超えないようにする必要がありますが、Wasm のデータサイズの上限はまだ定義されていないため、このトピックについてご意見を伺いたいと考えています。
オークションシグナル	promotionSignals のデータ構造は標準化されますか？	これはまだ定義されていませんが、フィードバックを受け付けています。
広告テクノロジーサーバーのクエリ	K/V サーバーから広告テクノロジーサーバーのデータをリアルタイムでクエリすることはできますか？	いいえ。K/V サーバーは、ユーザーデータの漏洩を避けるために「ネットワーク、ディスクアクセス、タイマー、ロギングを使用しない」という信頼モデルで実行されます。詳しくは、こちらの信頼モデルに関する説明をご覧ください。
adComponents の更新頻度	現在のところ、ユーザーの閲覧履歴を基に adComponents フィールドを更新することはできません（現時点では IG 設定のみ）。	プライバシーサンドボックスは、クロスサイトトラッキングなしでウェブエコシステムのニーズに応えて、閲覧履歴へのアクセスを防ぐことを目的としています。Topics など、代替表現を使用することをおすすめします。
オークション結果	広告テクノロジーがオークションの落札率を知る方法はありますか？	オークション結果は、販売者と落札者がそれぞれ提供するオークションコードで reportResult() と reportWin() 関数を呼び出すことで報告されます。これにより、それぞれがオークション結果に関するロギングとレポートを行うことができます。
（第 2 四半期にもレポート）。除外インタレストグループターゲティングのサポート	除外インタレストグループターゲティングをサポートする API: ユーザーがインタレストグループに属していない場合にのみ広告を表示します。	第 3 四半期の更新: 新しい提案を公開し、フィードバックをお待ちしています。

デジタル広告の測定

Attribution Reporting（とその他の API）

フィードバックテーマ	概要	Chrome レスポンス
OT の要件	OT 中、または OT に対してのみ、権限ポリシー制限を削除。	テスト中に Permissions-Policy に関して発表された変更をご覧ください。この変更によって対処されるステークホルダーの根本的な懸念は、DSP がより多くのクロスオリジン iframe で API をテストできるようになることです。当初 DSP は、クロスオリジンの iframe で API をテストするために、適切な権限ポリシーが設定されていることを確認するためにパブリッシャー/SSP と連携する必要がありましたが、この変更により、DSP はデフォルトで API を呼び出せるようになり、SSP/パブリッシャーはオリジントライアル中に必要に応じて API を無効にできます。
ノイズ	ノイズレベルが高すぎてレポートの有用性に影響しているというフィードバック。	ノイズに関するフィードバックをお寄せください。ノイズに関連する特定のパラメータの設定方法を決定するために使用いたします。また、テスターがこの機能を利用できるよう、リソース、ツール、その他のドキュメントをさらに公開する予定です。
クロスドメインコンバージョン	複数のリンク先があるなど、ドメインをまたいだコンバージョンをトラッキングする方法	この質問について、現在議論しており、フィードバックを募集しています。
デバッグ要件	デベロッパーが概要レポートのデプロイ / テスト時に残りのプライバシーバジェットを確認できるようにリクエストしますか？	この機能リクエストについては、こちらから追跡できます。
API 利用ポリシー	フィンガープリントなどの制限に基づいて、特定の API を使用できるユーザーに関するポリシーを提案するフィードバック	これは非常に興味深いアイデアであり、他のブラウザプロバイダと、より広範なウェブエコシステムの双方と、さらに協力していきたいと考えています。
コンバージョンレポートの有効期限の設定	レポートのフィルタ / 有効期限が 24 時間未満になるようにサポートするようリクエストします。	時間単位の有効期限は、ユーザーが広告主のサイトにアクセスした時間を正確に把握できるため、プライバシーの懸念材料になります。有効期限を 1 日に設定すると、ユーザーがサイトを訪問した時間を特定せずに、無効なインプレッションを除外できます。
OT トークンの有効期限	運用上のオーバーヘッドを削減するために、既存の OT トークンの有効性を延長するリクエスト。	Google はトークンの更新が必要であることを認識しており、開発者にとってより簡単なものにするとともに、追加の通知を行うよう努めています。
リージョンサポート	集計サービスは現在、すべての地域に対応しているわけではありません。	これは現在のベータ版の制限です。テストの進捗に応じて他の地域をサポートする予定ですが、具体的なスケジュールはまだ決まっていません。
イベントレベルのレポートの遅延	イベント単位レポートにおける 2 ～ 30 日の遅延は、ユースケースによっては長すぎることがあります。	イベントレベルレポートが期限切れに送信されるタイミングを広告テクノロジーが制御できるようにする提案をこちらで公開しています。デフォルトは 30 日ですが、これより短くすることもできます。
（第 2 四半期にもレポート）。マルチタッチアトリビューション	クロスデバイスやクロスアプリなど、マルチタッチアトリビューションを許可します。	第 3 四半期の更新: 現在のマルチタッチアトリビューションの方法では、異なるウェブサイト間でユーザーのインプレッション（ひいてはアイデンティティ）を決定論的に関連付ける必要があります。そのため、現在の形式のこの機能は、クロスサイトトラッキングなしの主要な広告ユースケースをサポートすることを目的としたプライバシーサンドボックスの目標に沿っていません。
FLEDGE と Attribution Reporting の統合スケジュール	FLEDGE と Attribution Reporting API の統合のスケジュールについて教えてください	現時点ではお伝えできる最新情報はございませんが、具体的なスケジュールが決まり次第、詳細を公表する予定です。
複数のトリガータイプ	トリガー登録の柔軟性に関するリクエスト。	Google は、広告テクノロジーがイベントレベルレポートと集計可能レポートを柔軟に制御できるようにする集計 API の重複除去システムを提案しました。
測定対象	広告枠のパフォーマンスに関する測定データを受け取るリクエスト。	Google は、フィードバックに感謝するとともに、このリクエストのユースケースについてより明確にしたいと考えています。
コンバージョンの有効期限	ソースタグだけでなくトリガータグでコンバージョンの有効期限をサポートするようリクエストします。	フィードバックをお寄せいただきありがとうございます。今回のリクエストのユースケースについて、より明確な説明ができればと考えております。
バッチレポート	バッチレポートの追加測定のリクエスト。	フィードバックを参考に、集計サービスへの影響について検討してまいります。広告テクノロジーがレポートのバッチ処理についてどのように考えているか、その頻度を予測して、年間を通じてバッチ処理戦略がどのように変化するかに関するフィードバックをお待ちしています。
Epsilon	イプシロンの値はいつ決定されますか？	Google はエコシステムのテスターと積極的に連携し、イプシロンの価値と GA での実装方法を完成させています。その価値は、価値の決定につながる議論とともに一般公開されます。ご意見やご要望がありましたら、こちらの GH Issue に投稿してください。

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

User-Agent の情報量削減

フィードバックテーマ	概要	Chrome レスポンス
デプロイの依存関係	構造化ユーザーエージェント（SUA）のデプロイの依存関係への対応。	Google は「フェーズ 4」をリリースしました。これは、Chrome 101 以降のすべてのユーザーに対してマイナーバージョンを削減する取り組みです。更新内容はこちらです。
テスト	Meta から User-Agent Reduction Origin Trial の延長をリクエスト。	Google はオリジントライアルを延長し、大規模なサイトに対応するためにトラフィック制限を撤廃する許可を取得。緩和されたトラフィック制限は、規模の大小を問わず、あらゆるサイトに適用されます。

User Agent Client Hints API

フィードバックテーマ

概要

Chrome レスポンス

（第 2 四半期にもレポート）。

不正防止 / 不正使用対策への懸念事項

UA-CH を介して利用できなくなる可能性がある機能: クリックリダイレクトトラッカー、不正なクリック。

第 3 四半期の更新:

不正防止パイプラインに悪影響が見られなかったという報告をいただいた企業の皆様より、好意的なフィードバックをいただいています（結果はこちら、こちら）。

チームは、不正防止および測定関係者とともに、これらの潜在的な問題を継続的に調査しています。

権限ポリシー

Permission-Policy はキャッシュに保存されていますか？

こちらの GitHub の問題で説明されているように、Permission-Policy はキャッシュに保存されません。

Gnatcatcher（WIP）

フィードバックテーマ	概要	Chrome レスポンス
位置情報のユースケース	Gnatcatcher を使用すると、位置情報に基づくコンテンツのパーソナライズなど、位置情報の正当なユースケースが今後機能しなくなる可能性があります。	Google は関係者と連携して、Chrome が IP アドレスの正当なユースケースを引き続きサポートするように努めています。

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

ファーストパーティセット

フィードバックテーマ	概要	Chrome レスポンス
ポリシー	GDPR ではセット内のサイト数に上限が課されていないことから、FPS は「適用されるデータ保護法」に関する CMA のコミットメントと一致しない懸念がありますが、FPS では 3 という制限が想定されています。	Google は CMA に対し、Google 自身のビジネスを自己優先することで競争をゆがめない方法でプライバシーサンドボックスの提案を設計、実装することに取り組んでいます。また、デジタル広告、パブリッシャー、広告主における競争への影響に加え、プライバシーの成果への影響と、適用されるデータ保護法に定められたデータ保護原則の遵守も考慮しています。お客様の懸念事項では、GDPR との互換性がない旨が開示されていません。Google は引き続き CMA と緊密に連携して、Google の取り組みがこれらのコミットメントを遵守するようにしています。詳しくは、後述の「フィードバックに応じた変更」をご覧ください。
ドキュメント	追加の例をリクエストしたり、既存の説明を更新したりするようリクエストします。	YouTube の説明ファイルの例は審査中です。必要に応じて、明確にするか削除してください。
設定の共有	同じ関係者グループに対して設定を行うための提案。	こちらでフィードバックをお待ちしています。現在、このアイデアについて活発に議論しています。
適用	違反措置の透明性を確保するには、不正な行為者による不正使用のリスクがあります。	フィードバックに感謝するとともに、このリスクを評価し、潜在的な緩和策を特定するために、GitHub（この問題で提起されたポイントを考慮し、この問題で提起された提案の取り入れを検討）の関係者と積極的に協議しています。
共通の所有権	共通の所有権を機械で読み取り可能な宣言の提案。	Google の提案に関するご意見を歓迎し、推奨しています。
サブドメインの所有権	データ管理者が異なる複数のサブドメイン、異なるプライバシーポリシー、異なる事業体によって運営されている異なるサブドメインを、同じファーストパーティセットに含めるべきですか？	フィードバックに基づいて、eTLD の一般的なユースケースを削除する予定です。
不正行為の軽減	不正行為の緩和策に関する詳しい情報のリクエスト。	現在、プロセスの管理を検討しており、今後数か月以内に詳細をお知らせいたします。
潜在的な攻撃ベクトル	簡単に見つけられるページに対して偽の関連セットセットを使用して、独立したページのように見せかける他のページにトラフィックを誘導するおそれがあります。	Google では現在、この問題への対応策をできる限り公開して調査しています。
検証を設定する	同意を得た一般的なポリシーを使用して設定を検証します。	ウェブ標準コミュニティやより広範なエコシステムのメンバーは、現実的でないことを指摘しています。
ドメインの上限	関連するドメイン数の増加のリクエスト。	Google では、FPS のドメイン上限について活発に議論を行っており、ユースケースに必要な関連ドメインの数について、コミュニティからのフィードバックをお待ちしています。
サブセットサービスのインタラクション	サービスと関連するサブセットのインタラクションに関する懸念。	フィードバックをお寄せいただきありがとうございます。今後の仕様で、これをより明示するようにする予定です。
（第 2 四半期にもレポート）。プライバシーの向上	同じセットに属するサイトが多すぎると、サードパーティ Cookie と同様の結果になる可能性があります。	第 3 四半期の更新: 最新の提案では、「関連する」サブセットについては 3 ドメインという制限を推奨しています（ccTLD とサービスドメインは含まれません）。Chrome では、この上限が適切かどうかを検討するためにエコシステムと積極的に連携しています。
（第 2 四半期にもレポート）。一般的なプライバシーポリシーの要件	すべてのサービスや地域の適用法令で共通のプライバシーポリシーを維持することは不可能です。	第 3 四半期の更新: 一般的なプライバシーポリシーは、同じセットの一部である必要はなくなりました。

Fenced Frames API

フィードバックテーマ	概要	Chrome レスポンス
iframe で属性ではなく新しい要素を使用する理由	既存の iframe の提案ではなく、Frenced Frame の提案に関する質問。	こちらで説明されているように、Google は皆様からのフィードバックを歓迎し、現状を収束させるためのアイデアを積極的に取り入れています。
フェンス付きフレームの交差点オブザーバー	フェンス付きフレーム内の情報の視認性に関する質問。	これは現在も活発に議論されており、このドキュメントと GitHub のコメント期間内です。サポート方法をより深く理解するために、パートナー様にユースケースの共有を歓迎します。
動画広告枠とネイティブ広告枠をサポートする	フェンス付きフレームは動画広告枠とネイティブ広告枠に対応していますか？	動画再生機能に関しては、フェンス付きフレームは iframe と違いはありません。そのため、公開ドキュメントで明示的に説明されていません。動画広告に問題がある場合は、フィードバックをお送りいただくと、詳しく調査できます。
ウェブバンドル	Fenced Frame x FLEDGE では、今後、ウェブバンドルによる広告配信 / レンダリングが要件になりますか？	長期的な目標は、フェンス付きフレームで広告コンテンツをレンダリングするためのウェブバンドルをサポートすることです。ただし、FLEDGE の現在の実装はこれをサポートしていないため、RenderUrl から取得した HTML リソースのレンダリングが必要です。
アセットのサイズ	render_url のリクエスト。スロットの高さと幅のマクロをサポートして、適切なサイズのクリエイティブで応答できます。	この点については、こちらで積極的に議論されています。

Shared Storage API

フィードバックテーマ	概要	Chrome レスポンス
FLEDGE の統合	共有ストレージと FLEDGE はどのように統合されますか？	現在はその取り組みを進めていませんが、プライバシー保護の確実性を確保できるのであれば、この考え方を検討したいと考えています。関係者の皆様には、この提案でサポートできる潜在的なユースケースについて、共有ストレージの GitHub リポジトリまたは FLEDGE の GitHub リポジトリの提案を提出することをおすすめします。
データの保持	共有ストレージを消去するとユーティリティが少なくなります。代替の方法として、保持期間の延長や個々の Key-Value の削除を検討していますか。	Google は常に、ユーザーのプライバシーとユーティリティに関するトレードオフのバランスを取るよう努めています。調整に関するフィードバックがございましたら、ぜひお寄せください。パートナー様には、共有ストレージのテスト時に、より多くのフィードバックや詳細をご提供いただくことをおすすめします。
負のシグナル	共有ストレージの提案に関する Mozilla からの否定的なシグナル。	提案を慎重に検討してくれた Mozilla に感謝します。近日中にフィードバックに返信する予定です。

チップ

フィードバックテーマ	概要	Chrome レスポンス
パーティション分割の要件	ファーストパーティの Cookie の「分割」属性に明示的な動作要件を追加しました。	この件については PrivacyCG の通話でご説明しており、GitHub のイシューについてメモを添えてフォローアップしています。Google は、ブラウザ、デベロッパー、プライバシーコミュニティと引き続き協力して、動作のすり合わせを行い、具体的な動作を特定していきます。
認証済み埋め込み	認証済み埋め込みに影響するさまざまなパーティショニングがあるため、CHIPS が現在の SSO ログインフローに影響する可能性があります。	Google は、認証済み埋め込みのユースケースを認識しており、解決に向けて取り組んでおります。
Cookie パーティション上限	ユースケースによっては、現在の Cookie の上限 10 個では不十分かどうかが懸念されます。	Google は、Cookie の数の制限を 12 KB のメモリ制限に移行します。これにより、パフォーマンスやブラウザのメモリ使用量に悪影響を及ぼさないようにしながら、Cookie の上限に関する懸念に対処できます。
オリジントライアルのタイムライン	ホスト名の境界要件の削除に続いて、OT を拡張。	エコシステムからのフィードバックに基づき、オリジントライアルの期限を延長しました。
Chrome でのテストに関する制限事項	Chrome の現在の制限により、Firefox で CHIPS をテストする可能性があります。	Firefox の実装はほぼ異なり、Chrome の Cookie 制限は低く、CHIPS はオプトインメカニズムですが、Firefox はデフォルトでパーティション分割されています。
（第 2 四半期にもレポート）。認証済み埋め込み	ログイン状態は CHIPS で保持されますか？	第 3 四半期の更新: ログイン状態は現在保持されませんが、CHIPS の想定されたユースケースではありません。Google は、認証済み埋め込みのユースケースを認識しており、解決に向けて取り組んでおります。

FedCM

フィードバックテーマ	概要	Chrome レスポンス
（第 2 四半期にもレポート）。潜在的な攻撃ベクトル	リンクデコレーション攻撃やタイミング攻撃による潜在的な攻撃ベクトル。	第 3 四半期の更新: Google は Mozilla と協力して、タイミング攻撃の問題に対処する方法について共通の理解を得ています。詳細についてはこちらをご覧ください。現在、このアーキテクチャの変更のプロトタイピングを行っており、今後数四半期以内にテストを実施する予定です。
ID プロバイダ	Account Chooser: 単一の ID プロバイダ。複数の ID プロバイダを許可するリクエスト。	Google はブラウザベンダーや FedID CG と協力し、複数の ID プロバイダを許可する方法について検討を重ねた結果、試す価値がありそうな形式を導き出しました。提案の説明はこちらでご覧いただけます。Google では、プロトタイプを開発し、数四半期以内に実験を行う予定です。
連携に関する既知の問題	サードパーティ Cookie のサポート終了により連携で問題が発生する可能性があるケースを列挙するためのリクエストです。	FedID CG の作業項目では、連携が崩れる方法をこちらとこちらに列挙しています。また、障害をこちらでウェブプラットフォーム API にマッピングするための意思決定マトリックスも作成中です。
ノンスパラメータ	Nounce パラメータがログインフローに影響するか？
ユーザーの同意	さまざまな証明書利用者（RP）と各オリジンに対するユーザーの同意をリンクする。	この仕様では、同じドメイン内のオリジンが Cookie を共有する方法を制御できません。この仕様では、IDP オリジンから RP オリジンへの idtoken を使用できますが、ユーザーのログイン状態を、単一のオリジンにロックされた Cookie に保存するか、同じドメイン内のオリジンと共有した Cookie に保存するかは、RP が決定します。
IDP アカウントポータビリティ	2 つの IDP 間での転送時に選択する場合に、IDP を移行するユーザーオプション。	これは、FedCM API 経由ではなく、選択した新しい IDP の登録ページで直接行う必要があるようです。
アカウントの削除	IDP によるアカウント削除を考慮した IDP 取り消し。	この機能リクエストはオープンで、入力を受け付けており、調査中です。
UI クレーム	ブラウザ固有のインターフェースのアスペクトについて述べます。	この問題に対処するには、pull リクエストをご覧ください。
IDP 紹介の確認	IDP は RP のリファラーを確認します。	必須の IDP リファラーチェックを仕様に追加しました。pull リクエストをご覧ください。
ログインフロー	RP 設定に基づいてカスタマイズされるログインフローのリクエスト。	Google はこの提案を歓迎し、活発に議論しています。

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

Trust Tokens API

フィードバックテーマ	概要	Chrome レスポンス
不正行為、不正使用	bot がカード発行会社をだましトークンを提供させていないこと、実際のユーザーに発行されたトークンを bot が乗っ取っていないこと、bot が悪意のあるトークンを発行するのを防ぐツール。	bot はカード発行会社からトークンを取得できる場合がありますが、悪意のある攻撃者が bot を回避しようとすると、トークンを発行する頻度と、トークンを発行して発行ロジックを更新するための堅牢な方法を設定することが推奨されます。トークンの発行に十分に堅牢なロジックがない発行元は、ウェブサイトがより堅牢な発行元に依存して優先するため、エコシステムにおける信頼性が低下する可能性があります。
不正行為、不正使用	トラストトークン利用者が、特定のエンティティのトラストトークンのみを受け入れることを指定する方法はありますか？	はい、可能です。この仕組みについては、説明中のトラストトークンの利用セクションで説明しています。
不正行為、不正使用	トラストトークン発行者が利用者のリストを定義し、第三者がトークンを利用できないようにする方法はありますか？	現時点ではできませんが、担当チームがこのユースケースを調査中です。
タイムライン	Trust Token API はいつ一般提供されますか？	スケジュールが決まり次第、詳細を公表します。
（第 2 四半期にもレポート）。メンテナンスのオーバーヘッド	プロトコルバージョンがどれくらいの期間サポートされるかが明確でない。	第 3 四半期の更新: バージョン間でスムーズに移行できるように、複数のバージョンを同時にサポートする API のサポートが追加されます。ただし、サポートやサポート終了の日程は未定です。

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