2025年最新版：SameSiteとPartitioned Cookies（CHIPS）を徹底解説 ― ログインが切れる理由と正しい設定方法

技術

はじめに

「突然ログインが切れた」「外部サービスが動かなくなった」「iframe内でログインできない」
もしそんな経験があるなら、それは Cookie仕様の変化 が原因かもしれません。

特に、2025年現在のWebブラウザは SameSite属性 と Partitioned Cookies（CHIPS） という新しいルールを採用しています。
これを知らないと、何気ない挙動変更が本番トラブルに直結します。

この記事では、初心者にも分かりやすく、「なぜ変わったのか」「どうすればいいのか」 を実例つきで説明します。

Cookieとは？

Cookieはブラウザが保存する「小さなデータファイル」です。
Webアプリがユーザーを“覚えておく”ために使われます。

  • ログイン状態を保持する
  • カートの中身を保存する
  • ダークモード設定を記憶する
  • 言語設定を保存する

こうした機能の多くが、Cookieの上に成り立っています。

SameSite属性とは？

SameSite属性は、「このCookieをどんなリクエストに添付して送るか」を指定する設定です。

値意味主な用途
Strict完全に自サイト内のみ銀行、マイページなど高セキュリティ系
Lax同サイト＋リンク遷移時のみ（デフォルト）通常のログインセッション
Noneクロスサイトでも送信OK外部連携や埋め込みウィジェット

Noneを使うならSecureが必須

Set-Cookie: session_id=abc123; SameSite=None; Secure

SameSite=None は「どこからでも送信OK」ですが、代わりに Secure（HTTPS限定）が義務化されています。
HTTPサイトでは動作しません。

“未指定”はもう危険

昔は SameSite を書かなくても、どんなリクエストにもクッキーが送られました。
今は違います。未指定＝Lax扱い になりました。

つまり、他ドメインからのアクセスではCookieが送られず、
「ログインが切れる」「外部サービスが動かない」などのトラブルが発生します。

よくあるユースケースと挙動の違い

ログインが勝手に切れるケース

例:
ECサイトで、商品ページは別ドメインの shop.example.com。
ログイン処理は auth.example.com に実装されている。

問題:
SameSite が Lax のままだと、クロスドメインのPOST時にCookieが送られない。
結果、セッションが引き継がれず「ログインしていません」と表示される。

解決:
SameSite=None; Secure に設定し、HTTPS通信に統一する。

外部ウィジェット・SNS埋め込み

例:
ブログにTwitterのタイムラインやYouTube動画を埋め込む。

問題:
これらのiframeは「サードパーティ扱い」。
ブラウザはセキュリティ上、クッキー送信を制限する。
その結果、YouTubeのログイン情報が共有されず、「おすすめ」や「視聴履歴」が反映されない。

解決:
YouTubeなどは SameSite=None; Secure に対応済み。
埋め込み先はHTTPS化を徹底する。

シングルサインオン（SSO）

例:
企業が portal.company.jp から app.company.jp にSSOでログインする。

問題:
SSOリダイレクトの途中でCookieが送られないと認証が途切れる。
「ログインループ」に陥ることもある。

解決:
SSOドメインで SameSite=None; Secure を設定する。
社内環境でもHTTPSを使う。

Partitioned Cookies（CHIPS）とは？

正式には CHIPS（Cookies Having Independent Partitioned State）。
2024年以降、ChromeやEdgeが順次対応している新仕様です。

意味は「分割されたCookie」。
これまで1つだったクッキーを、トップレベルサイトごとに分離して保存します。

どういうことか？

従来のサードパーティCookieでは、同じ広告サーバーやCDNを使うと、
「どのサイトを見たか」が一意に紐づいてしまいました。

例:

  • ads.example.com が複数サイトに埋め込まれている
  • 全てのサイトで同じCookieが共有される
    → 広告会社が「あなたの閲覧履歴」を簡単に追える

これを防ぐために導入されたのが Partitioned。
今では「サイトごとに独立したCookie」として扱われます。

設定例

Set-Cookie: __Host_user_id=xyz;
             Path=/;
             Secure;
             HttpOnly;
             SameSite=None;
             Partitioned

ポイント：

  • Secure は必須（HTTPでは使えない）
  • SameSite=None でクロスサイト送信を許可
  • __Host- 接頭辞でDomain指定禁止・Path=/固定（セキュリティ強化）

広告や分析タグでのユースケース

例:
アクセス解析ツールが analytics.vendor.com にCookieを保存している。

問題:
3rd-party Cookie廃止で解析ができなくなる。
これまでのCookieが他サイトでも共有されていたため、同一ユーザーを識別できた。

解決:
Partitioned 属性を付与すれば、
各トップレベルサイト（例：example.com・news.jp）ごとに別々に保持できる。
つまり トラッキングは禁止でも、計測は続けられる。

CDNを使うサービス

例:
画像配信CDN（cdn.example.net）がセッションや設定をCookieで管理している。

問題:
別サイトに埋め込まれるとサードパーティ扱いになり、Cookieが送られない。
キャッシュ認証が失敗してエラーになることも。

解決:
Partitioned を指定しておけば、埋め込み先ごとに独立したCookieとして安全に運用可能。

よくあるトラブルと対策まとめ

症状原因対策
ログインが切れるSameSite未指定（Lax扱い）明示的に SameSite=None; Secure
iframeで動かないサードパーティ扱いSameSite=None; Secure
分析ツールが動かない3rd-party Cookie 廃止SameSite=None; Secure; Partitioned
CDN認証が外れるクロスサイト扱いでCookie不送信Partitionedを追加

実務で覚えておきたい設定早見表

用途設定例備考
通常のログインセッションSameSite=Laxデフォルトで安全
SSO・外部連携SameSite=None; SecureHTTPS必須
分析・CDN・埋め込みウィジェットSameSite=None; Secure; Partitioned新仕様（CHIPS）対応

まとめ

Cookieの新仕様は、Webのセキュリティとプライバシーを両立させるための変化です。
これまで自由だったCookieの挙動を見直し、ユーザーの情報を守りながら必要な機能を維持する方向に進化しています。
開発者にとっては少し面倒な変更かもしれませんが、正しく理解しておけば大きな武器になります。

設計段階では、まずCookieの役割と目的を整理することが重要です。
ログインやセッション維持のようなファーストパーティ用途なら Lax で十分。
一方、OAuth・埋め込みウィジェット・SSO など他ドメインをまたぐケースでは SameSite=None; Secure が必須です。
さらに、広告・解析・CDN など第三者ドメインを使う場合は、Partitioned（CHIPS）を使うことで安全に動作させられます。

実装時は、HTTPではなくHTTPSを前提に設計しましょう。
Set-Cookie ヘッダーを自分で設定する場合は、常に SameSite と Secure を明示すること。
フレームワークが Partitioned に未対応の場合は、レスポンスヘッダーを直接操作すれば対応可能です。
テストではChrome DevToolsの「Network」や「Application」タブを使い、実際にCookieが送受信されているかを確認してください。

運用の現場では、チーム全体でCookieポリシーを統一しておくと混乱が防げます。
マーケティングや分析チームがサードパーティCookieを利用している場合、早めにCHIPS対応を検討しましょう。
SafariのITPやChromeのPrivacy Sandboxなど、ブラウザごとの差異も今後さらに広がるため、
APIベースの認証やサーバーサイド計測への移行も視野に入れておくと安全です。

結局のところ、Cookie設定の正解は一つではありません。
しかし、次の三つを押さえておけば迷うことはありません。

  • クロスサイト通信には SameSite=None; Secure
  • サードパーティ用途には Partitioned（CHIPS）
  • そして HTTPはもう使わない。HTTPSが前提

この三点を理解しておけば、「Cookieが送られない」「ログインが切れる」といった典型的なトラブルを確実に防げます。
仕様変更を恐れず、正しく味方につけることで、より安全で快適なWebアプリを作っていきましょう。

コメント

タイトルとURLをコピーしました