アドプライバシーQ&A

CHIPSおよびFirst-Party Setsの技術仕様解説：サードパーティCookie代替としての実装とプライバシー考慮事項

Tags: CHIPS, First-Party Sets, Privacy Sandbox, Cookie, ウェブ標準, プライバシー技術

はじめに

ウェブにおけるプライバシー保護強化の一環として、主要ブラウザによるサードパーティCookieのサポート廃止が進められています。これに伴い、クロスサイトコンテキストでの状態管理や連携が必要なユースケースに対して、プライバシーを尊重した代替技術が提案され、開発が進められています。本記事では、これらの代替技術群であるPrivacy Sandboxの一部として検討されている「CHIPS (Cookies Having Independent Partitioned State)」および「First-Party Sets」に焦点を当て、その技術仕様、目的、ユースケース、そして実装上の考慮事項について詳細に解説します。これらの技術を正確に理解し、適切に導入することは、変化するウェブ環境における持続可能なビジネス運営とユーザープライバシー保護の両立のために不可欠です。

CHIPS (Cookies Having Independent Partitioned State) の技術仕様と目的

CHIPSは、サードパーティコンテキストで設定されるCookieに対して、新しい属性 Partitioned を導入する提案です。この属性が付与されたCookieは、サードパーティコンテキストであっても、トップレベルサイトごとに分離（パーティショニング）されて保存されます。

Partitioned 属性

Cookie設定時に Set-Cookie ヘッダーに Partitioned 属性を追加します。

Set-Cookie: __Host-session=abc; Secure; Path=/; SameSite=None; Partitioned;

この属性により、同じオリジンから設定されたCookieであっても、埋め込まれているトップレベルサイトのオリジンが異なれば、それぞれ独立したCookie Jarに保存されます。

パーティショニングの仕組み

CHIPSにおけるCookieの保存領域は、以下の3つのキーによってパーティショニングされます。

  1. Cookieのオリジン: https://cdn.example.com
  2. トップレベルサイトのオリジン: https://example.com
  3. ブラウザのプライベートブラウジングモード: (利用している場合)

したがって、https://cdn.example.com から設定された __Host-session という名前のCookieは、https://example.com に埋め込まれている場合は (https://cdn.example.com, https://example.com) というパーティションに保存され、https://anothersite.com に埋め込まれている場合は (https://cdn.example.com, https://anothersite.com) という別のパーティションに保存されます。これにより、cdn.example.com が異なるトップレベルサイトを横断してユーザーをトラッキングするために同じCookieを利用することはできなくなります。

CHIPSのユースケース

CHIPSは、サードパーティコンテキストで状態を維持する必要がある、クロスサイトトラッキングを伴わないユースケースに適しています。代表的な例として以下が挙げられます。

これらのユースケースでは、Cookieがトップレベルサイト間で共有される必要はなく、むしろ分離されていることがプライバシー保護の観点から好ましいと言えます。

プライバシーへの影響

CHIPSは、サードパーティCookieによるサイト横断トラッキングのリスクを大幅に低減します。Cookieがトップレベルサイトごとに分離されるため、埋め込みコンテンツ提供者が異なるサイト上でのユーザーの行動を単一の識別子で紐づけることが原理的に困難になります。これは、サードパーティCookieの主要なプライバシー懸念点であったクロスサイトトラッキングへの直接的な対策となります。ただし、CHIPSはあくまでCookieのパーティショニングに関する仕様であり、フィンガープリンティングなどの他のトラッキング手法に対する直接的な対策ではありません。

First-Party Sets の技術仕様と目的

First-Party Sets (FPS) は、同じ組織によって運用される複数のドメインを「同一の第一者（First-Party）」としてブラウザに認識させるためのメカニズムです。これにより、セット内のドメイン間では制限付きでCookieを共有できるようになります。

セット構成と宣言

FPSを構成するドメインは、セットオーナーとなるドメインが管理する .well-known/first-party-set ファイル内で宣言されます。

{
  "primary": "https://primary.example.com",
  "associatedVendors": [
    {
      "owner": "https://associated.example.com",
      "associatedSites": [
        "https://site1.associated.example.com",
        "https://site2.associated.example.com"
      ]
    }
  ],
  "associatedSites": [
    "https://blog.example.com",
    "https://shop.example.com"
  ]
}

このファイルは、セットの「primary」メンバーと、それに「associated」するメンバーをリストします。ブラウザは、この宣言を読み取り、特定のドメインがどのセットに属するかを認識します。宣言には、セットの目的（ユースケース）を示すアノテーションを含めることも検討されています。

アクセス許可の仕組み

FPSは、単にセット内のドメイン間で無条件にCookieを共有することを許可するわけではありません。セット内のサイトが別のセットメンバーのCookieにアクセスしようとする場合、Storage Access API (document.requestStorageAccess()) を通じてブラウザに許可を求める必要があります。

document.requestStorageAccess()
  .then(() => {
    // Cookieへのアクセスが許可された場合の処理
  })
  .catch(() => {
    // Cookieへのアクセスが拒否された場合の処理
  });

ブラウザは、ユーザーの同意状況、サイトとのインタラクション履歴、セットの信頼性などを考慮して、このリクエストを許可するかどうかを決定します。これにより、無制限なCookie共有を防ぎつつ、正当なファーストパーティ間の連携ユースケースを可能にします。

First-Party Setsのユースケース

FPSは、単一の組織が複数のドメインを使用してサービスを提供している場合に適しています。代表的な例として以下が挙げられます。

これらのユースケースでは、技術的にはクロスサイトアクセスとなりますが、組織単位で見れば第一者の連携であり、サードパーティトラッキングとは性質が異なります。

プライバシーへの影響

FPSは、関連性の高いドメイン群を「第一者」として扱うことで、ユーザーにとってより直感的なプライバシー境界を提供しようとします。ユーザーは、単一の組織が提供する複数のサービス間での連携はある程度許容する可能性があるためです。しかし、セット内のドメイン間であっても無制限なCookie共有は許可せず、Storage Access APIによる明示的な許可メカニズムを設けることで、プライバシーへの影響を緩和しています。セット定義の妥当性や悪用リスクについては継続的に議論されており、標準化プロセスやブラウザの実装を通じて改善が続けられています。特に、セットのメンバーシップをどのように検証し、承認するかの仕組み（例：Brand Verification）が重要となります。

CHIPSとFirst-Party Setsの比較と使い分け

CHIPSとFirst-Party Setsは、どちらもサードパーティCookie廃止後の代替技術ですが、その目的、スコープ、技術メカニズム、そして適用されるユースケースが異なります。

| 特徴 | CHIPS (Cookies Having Independent Partitioned State) | First-Party Sets (FPS) | | :------------- | :------------------------------------------------- | :-------------------------------------------------------- | | 目的 | クロスサイトコンテキストでのCookieをトップレベルサイトごとに分離し、クロスサイトトラッキングを防止する。 | 関連性の高いドメイン群を一つの第一者として扱い、セット内での制限付きCookieアクセスを可能にする。 | | スコープ | サードパーティコンテキストで設定される個々のCookie。 | 組織が所有する複数の関連ドメイン群。 | | 技術 | Partitioned Cookie属性。 | .well-known ファイルによるセット宣言、Storage Access API。 | | プライバシーモデル | クロスサイトトラッキングを技術的に困難にする。 | 組織単位での第一者境界を定義し、明示的なアクセス制御を設ける。 | | ユースケース | 埋め込みウィジェットの状態管理、CDNキャッシュなど。 | クロスサイトSSO、関連サービス間連携、組織内コンテンツ埋め込み。 | | 実装 | Cookie設定時に属性を追加。 | .well-known ファイルの配置、Storage Access API呼び出し。 |

これらの違いから、どちらの技術が適切かは実現したいユースケースによって判断する必要があります。

多くのシナリオでは、CHIPSは埋め込まれる側（iframeなど）が自身のCookieを独立させるために利用し、FPSはトップレベルのドメインと埋め込まれるドメイン（またはリダイレクト先ドメイン）が同じ組織に属している場合に、ユーザーのインタラクションを伴ってCookieアクセスを許可するために利用される、という補完的な関係になります。

実装上の注意点と課題

これらの新しい技術を実装する際には、いくつかの注意点があります。

  1. ブラウザサポート: Privacy Sandboxの各APIや機能は開発途上にあり、ブラウザによってサポート状況が異なります。特にChromeが積極的に実装を進めていますが、他のブラウザ（Firefox, Safariなど）は異なるアプローチや独自のプライバシー機能を実装している場合があります。常に最新の互換性情報を確認することが重要です。
  2. セットアップと検証: CHIPSでは Partitioned 属性を正しく設定する必要があります。FPSでは .well-known/first-party-set ファイルを正確に配置し、その内容がセットのルール（例：メンバーシップの検証、セットサイズの制限）に適合している必要があります。不備があると、ブラウザにセットとして認識されない可能性があります。
  3. Storage Access API: FPSでは、セット内のクロスサイトCookieアクセスにStorage Access APIが必要です。このAPIはユーザーインタラクションやブラウザの設定に依存するため、アクセスが常に許可されるとは限りません。アクセスが拒否された場合のフォールバック戦略を考慮する必要があります。また、APIの呼び出しタイミングや、ユーザー体験への影響も考慮する必要があります。
  4. デバッグ: パーティショニングされたCookieやFPSのセットアップ状況をデバッグするためのブラウザ開発者ツールの機能を利用する必要があります。Chromeの場合、chrome://flags で特定の機能を有効にしたり、開発者ツールの「Application」タブでCookieのパーティション状態を確認したりできます。
  5. 法的・コンプライアンス上の考慮事項: これらの技術はプライバシー保護を強化する目的で導入されますが、それ自体がGDPRやCCPA/CPRAなどのデータプライバシー規制への完全な準拠を保証するものではありません。特に、ユーザーからの同意取得（Consent Management Platform: CMPの導入）や、収集するデータの種類、利用目的、データ保持期間など、総合的なプライバシー戦略の一部としてこれらの技術を位置づける必要があります。CHIPSやFPSを利用して収集・利用するデータが、規制で求められる透明性や制御の要件を満たすかどうかの検討が必要です。Storage Access APIによるアクセス許可も、法規制上の「同意」と同義ではない場合があるため、法的専門家への相談が推奨されます。

将来的な展望

CHIPSとFirst-Party Setsは、Privacy Sandboxの進化と共に、今後も仕様変更や改善が行われる可能性があります。W3Cなどの標準化団体での議論や、ブラウザベンダーからのフィードバックに基づき、より堅牢で実用的な形へと発展していくことが期待されます。

他のPrivacy Sandbox API（例: Topics API, Protected Audience API）との連携も重要な検討事項です。これらのAPIはそれぞれ異なるユースケース（興味ベース広告、リターゲティング広告など）に対応しますが、例えばFirst-Party Sets内のサイト間でユーザー属性を共有し、それをProtected Audience APIでの入札シグナルとして利用する、といった複合的なシナリオも考えられます。これらの技術が組み合わさることで、サードパーティCookieに依存しない広告エコシステムやウェブサービスの提供がより現実的になるでしょう。

まとめ

CHIPSとFirst-Party Setsは、サードパーティCookie廃止後のウェブ環境における重要な基盤技術です。CHIPSはサードパーティコンテキストでのCookieをトップレベルサイトごとに分離しクロスサイトトラッキングを防ぎますが、First-Party Setsは関連ドメイン群を第一者として扱い、セット内での制限付きCookie共有を可能にします。これらの技術は、それぞれ異なる目的とユースケースに対応しており、その技術仕様とプライバシーへの影響を正確に理解することが、今後のウェブ開発やプライバシーコンサルティングにおいて不可欠となります。実装にあたっては、ブラウザサポート状況、セットアップ要件、Storage Access APIの挙動、そしてデータプライバシー規制との整合性を慎重に検討する必要があります。これらの新しい技術を活用し、ユーザープライバシーを保護しつつ、変化するウェブエコシステムに適応していくことが求められています。