サードパーティ Cookie は有効な用途がありますが、クロスサイト トラッキングを有効にすることもできます。Chrome では、テストを容易にするために 2024 年第 1 四半期からユーザーの 1% に対してサードパーティ Cookie を制限し、2025 年初頭からすべてのユーザーに対するサードパーティ Cookie のサポート終了に向けて、英国の競争・市場庁（CMA）が競合に関する懸念事項をすべて解消する予定です。サードパーティの Cookie に依存するログインフローがウェブサイトにある場合、この変更の影響を受ける可能性があります。サイトの準備が整っていることを確認する必要があります。
このページでは、影響を受ける可能性が高いログイン シナリオに関する情報と、考えられる解決策について説明します。
ウェブサイトで同じドメイン内とサブドメイン内のフロー（publisher.example や login.publisher.example など）のみを処理する場合、クロスサイト Cookie は使用されず、段階的廃止によるログインフローへの影響は生じません。
ただし、サイトでログインに別のドメイン（Google ログインや Facebook ログインなど）を使用している場合や、サイトが複数のドメインやサブドメイン間でユーザー認証を共有する必要がある場合は、クロスサイト Cookie からスムーズに移行できるようにサイトを変更する必要があります。
ID 関連のユーザー ジャーニーをテストする
ログインフローがサードパーティ Cookie のフェーズアウトの影響を受けるかどうかをテストする最善の方法は、サードパーティ Cookie の段階的廃止テストフラグを有効にして、登録、パスワードの再設定、ログイン、ログアウトのフローを実行することです。
次のチェックリストは、サードパーティ Cookie を制限した後のチェックリストです。
- ユーザー登録: 新規アカウントの作成は想定どおりに機能します。サードパーティの ID プロバイダを使用している場合は、すべての統合で新しいアカウントの登録が機能することを確認します。
- パスワードの再設定: ウェブ UI から CAPTCHA、パスワードの再設定メールの受信まで、パスワードの再設定が想定どおりに機能します。
- ログイン: ログイン ワークフローは、同じドメイン内でも、他のドメインに移動するときにも機能します。すべてのログイン統合をテストすることを忘れないでください。
- ログアウト: ログアウト プロセスは想定どおりに機能し、ユーザーはログアウト フロー後もログアウトしたままになります。
また、ユーザーのログインを必要とする他のサイト機能が、特にクロスサイト リソースの読み込みを伴う場合は、クロスサイト Cookie がなくても機能することを確認する必要があります。たとえば、CDN を使用してユーザーのプロフィール画像を読み込む場合でも、引き続き機能することを確認します。購入手続きなどのクリティカル ユーザー ジャーニーがログインで制限されている場合は、それらが引き続き機能することを確認してください。
以降のセクションでは、これらのフローがどのような影響を受ける可能性があるかについて、より具体的に説明します。
フェデレーション ID
[Sign in with Google]、[Facebook Login]、[Log in with Twitter] などのログインボタンは、ウェブサイトがフェデレーション ID プロバイダを使用していることを明確に示すものです。各フェデレーション ID プロバイダには独自の実装があるため、最適なソリューションは、プロバイダのドキュメントを確認するか、プロバイダに問い合わせることです。
非推奨の Google ログイン JavaScript プラットフォーム ライブラリを使用している場合は、認証と認可のために新しい Google Identity Services ライブラリに移行する方法をご覧ください。
新しい Google Identity Services ライブラリを使用しているほとんどのサイトは、サードパーティ Cookie のサポート終了に向けて準備ができています。これは、互換性を確保するために、FedCM を使用するようライブラリが通知なく移行されるためです。サードパーティ Cookie の段階的廃止テストフラグを有効にしてサイトをテストし、必要に応じて FedCM 移行チェックリストを使用して準備することをおすすめします。
個別のログイン ドメイン
一部のウェブサイトは、同一サイト Cookie の対象とならないユーザー認証にのみ異なるドメインを使用します。たとえば、メインサイトに example.com を使用し、ログインフローに login.example を使用するウェブサイトなどでは、両方のドメインでユーザーが認証されていることを確認するために、サードパーティ Cookie へのアクセスが必要になる場合があります。
このシナリオで考えられる移行パスは次のとおりです。
- ファーストパーティ（「同一サイト」）の Cookie を使用するための更新: ログインフローがメインサイトと同じドメイン（またはサブドメイン）でホストされるようにウェブサイトのインフラストラクチャを変更します。メインサイトと同じドメイン（またはサブドメイン）でログインフローがホストされ、ファーストパーティの Cookie のみが使用されます。インフラストラクチャの設定方法によっては、これよりも多くの労力が必要になる場合があります。
- 関連ウェブサイト セット（RWS）を使用する: 関連ウェブサイト セットを使用すると、少数の関連ドメイン間のクロスサイト Cookie アクセスを制限できます。RWS は、このユースケースをサポートするために構築されたプライバシー サンドボックス API です。ただし、RWS でサポートされているドメインの数は限られています。
- 5 つ以上の関連ドメインでユーザーを認証している場合は、FedCM をご覧ください。Federated Credentials Management（FedCM）を使用すると、ID プロバイダはサードパーティ Cookie を必要とせずに Chrome を利用して ID 関連のフローを処理できます。この場合、「ログイン ドメイン」は FedCM ID プロバイダとして機能し、他のドメインでユーザーを認証するために使用できます。
複数ドメイン
ある企業が、異なるドメインまたはサブドメインで複数のサービスをホストしている場合、それらのサービス間でユーザー セッションを共有したい場合があります。このようなシナリオでは、複数のドメイン間でサードパーティ Cookie にアクセスする必要があります。
このシナリオでは、すべての商品を同じドメインでホストすることは現実的ではないことがよくあります。この場合の解決策は次のとおりです。
- 関連ウェブサイト セットを使用する: 少数の関連ドメイン間でクロスサイト Cookie アクセスが必要な場合。
- フェデレーション認証情報管理（FedCM）を使用する: ドメイン数が多い場合は、別のログイン ドメインを使用して ID プロバイダとして機能し、FedCM を使用してサイト全体でユーザーを認証できます。
ログイン ソリューション
サードパーティのシングル サインオン（SSO）
SSO ソリューションの実装は複雑なため、多くの企業がサードパーティのソリューション プロバイダを使用してログイン状態を複数オリジンで共有しています。プロバイダの例としては、Okta、Ping Identity、Google Cloud IAM、Microsoft Entra ID などがあります。
サードパーティ プロバイダを利用している場合は、サードパーティ Cookie の段階的廃止がソリューションに及ぼす影響や、プロバイダが推奨するサービスについて、プロバイダにアドバイスを求めることをおすすめします。
オープンソースの SSO ソリューション
独自の SSO ソリューションを持つ多くの企業は、OpenID Connect、OAuth、SAML などの確立された業界標準や、Keycloak、WSO2、Auth.js、Hydra などの確立されたオープンソース プロジェクトを使用して、これを実現しています。
Cookie の段階的廃止がソリューションに与える影響と、特定のソリューションに最適な移行パスについては、プロバイダのドキュメントを確認することをおすすめします。
カスタムの社内ソリューション
ログイン ソリューションが前述のユースケースのいずれかに該当し、社内で構築されている場合は、コードを監査してサードパーティ Cookie の段階的廃止に備える方法について詳しくは、サードパーティ Cookie の段階的廃止を準備するをご覧ください。
今すぐご対応ください。
ウェブサイトがいずれかのユースケースに該当する場合は、認証フローをメインドメインに移行してファーストパーティの Cookie のみを使用する、関連ウェブサイト セットを使用して少数のドメイン間での Cookie の共有を許可する、フェデレーション認証情報管理の利用など、考えられる影響に対処できる複数のソリューションがあります。