Cookie

本記事は Cookie によるユーザー計測の是非や Cookie の詳細な仕様については触れません。 Cookie を使ったユーザー計測の歴史を振り返ることで Cookie の理解を深めることを目的としています。

Cookie に関する知識はブラウザおよびブラウザを開発している各社のポリシーによって変化しています。
またユーザー計測の文脈では JavaScript との関係の理解も必要になります。

本章は Cookie 、JavaScript について本記事で必要になる部分に絞って解説します。

発行場所（サーバー / クライアント）

Cookie は発行される場所によってブラウザ（特に Safari の ITP ）による制限の受け方が異なります。

ITP （ Intelligent Tracking Prevention ）：
Safari が導入したトラッキング防止機能です。本記事では特に Cookie の有効期限に関わる制限として登場します。

発行場所	発行方法	説明	有効期限（ ITP 制限）
サーバー	HTTP ヘッダー	`Set-Cookie` レスポンスで発行	ITP による短縮は受けないが、後述のブラウザ共通の上限（最大400日）が別途かかる
ブラウザ	JavaScript	`document.cookie` で発行	短い（最長 7 日間）

サーバー発行の Cookie は ITP の有効期限制限を受けないため長期間の計測が可能です（ただし上記の400日上限までです）。
一方、JavaScript で発行した Cookie は ITP により最長 7 日間に制限されます。7 日を超えると再訪ユーザーを新規ユーザーと誤認するため広告効果を正確に計測できない可能性が発生します。

[!NOTE] 発行場所による重要点：

ドメイン制限: JavaScript（ document.cookie ）で Domain 属性に指定できるのは、現在のページのドメインまたはその上位ドメイン（ Public Suffix を除く）に限られます。サブドメインや無関係なドメインを指定してもブラウザに無視されます。
たとえば example.com を閲覧中に Domain=example.com を指定すれば example.com および全サブドメイン（ foo.example.com など）に送信される Cookie を発行できますが、特定のサブドメイン（ foo.example.com ）のみに絞って発行することはできません（ Domain 属性は後述）。

有効期限：ブラウザで発行する Cookie の有効期限は ITP により最長 7 日間に制限されます。

参考:

MDN – Document.cookie

自動送信

ブラウザはリクエスト先のドメインと一致する Cookie を保持している場合に自動的に HTTP ヘッダー（ Cookie ヘッダー）に載せて送信します。
ブラウザの自動送信は便利な機能ですが、セキュリティ・プライバシー保護と深く関わるために送信してよい条件を理解するには 3 つの概念を整理する必要があります。

Host-only Cookie のスコープ（ Cookie の送信先）
ファーストパーティ / サードパーティの判定（ Cookie の性質・分類）
SameSite 属性（Cookie を実際に送信するかどうかの制御）

用語の整理: Public Suffix と eTLD：
Public Suffix（ eTLD とも呼ばれます）とは、独立した組織がドメインを登録できるサフィックスのことです。.com・co.uk・github.io などが該当し、Public Suffix List（PSL）で管理されています。
また eTLD+1（登録可能ドメイン）とは Public Suffix の 1 つ上のラベルまでを指します。example.com・example.co.uk・foo.github.io などが該当します。
これらの概念は後述する SameSite 属性の Same-Site 判定でも登場します。

Domain 属性は Cookie の送信可能なスコープを指定します。
Domain 属性なしで発行した Cookie は Host-only Cookie と呼ばれて送信先は発行ドメインに限定されます。

具体例で説明します。
foo.example.com が Domain 属性を指定せずに Cookie を発行します。その Cookie は foo.example.com にのみ送信されます。example.com や bar.example.com には送信されません。

Domain 属性に指定できるのは現在のドメインの上位ドメインまでです（例: foo.example.com からは example.com を指定可能）。ただし .com などの Public Suffix は指定できません。Domain=example.com を指定した場合、example.com と foo.example.com などのサブドメインすべてに送信されます。

参考：

RFC 6265 – Section 5.3 Storage Model（Host-only Cookie の定義）

2. ファーストパーティ / サードパーティ

一般的には、訪問中のページと同じサイト（ eTLD+1 ）が発行した Cookie をファーストパーティ Cookie 、異なるサイトが発行した Cookie をサードパーティ Cookie と呼びます。

ファーストパーティ：訪問中ページと同じサイト（ eTLD+1 ）が発行した Cookie（例：https://example.com 訪問中に example.com が発行した Cookie）
サードパーティ：訪問中ページとは異なるサイトが発行した Cookie（例：another.com など別ドメインが発行した Cookie）

この判定は「 Cookie の性質・分類」を決めるものであり、 ITP や各ブラウザのプライバシー保護機能が介入するかどうかのトリガーになります。

参考：

3. SameSite 属性

Cookie がサイトをまたいで（ Cross-Site ）送信されるかどうかを制御する属性です。
この属性は Cookie の発行者が設定しますが、実際にその Cookie を受け入れるかどうかはブラウザ（ブラウザベンダー）側が判断します。

ここでいう Site は eTLD+1（登録可能ドメイン）＋スキーム で定義されます。そのため foo.example.com と bar.example.com のように、サブドメインが異なっても eTLD+1 が同じであれば Same-Site として扱われます。

値	挙動
`SameSite=Lax`	Safari を除く主要ブラウザ（ Chrome・Firefox・Edge 等）のデフォルト。別サイトからのトップレベルナビゲーション（リンク遷移など）では送信されますが、`<img>` タグや `<iframe>` による埋め込みリクエストではブロックされます。なお `SameSite` 属性を省略した場合、ブラウザが内部的に `Lax` として扱う場合がありますが、その挙動は明示指定の `Lax` より若干寛容です（発行から 2 分以内は POST でも送信されるなど）。
`SameSite=Strict`	同一サイト内の遷移でしか送信されません。セキュリティは最高ですが、メールのリンクなどから遷移した際にログイン状態が保持されない場合があります。
`SameSite=None`	Chrome 80 以前のデフォルト動作です。クロスサイトでも Cookie を送信します。サードパーティ Cookie として機能させる場合に必須ですが、必ず `Secure` 属性とセットで指定する必要があります。

[!NOTE] SameSite 属性の挙動はブラウザによって異なります。一貫した動作を保証するために、SameSite は常に明示的に指定することが推奨されます。

参考:

JavaScript の前提知識

現在のユーザー計測では JavaScript を使って外部ドメインに Cookie の内容を送信する手法が多く見られます。ユーザー計測に絞って JavaScript の前提知識をまとめます。

ユースケース

ブラウザで JavaScript が Cookie を発行（ JavaScript で Domain 属性に指定できるのは現在のページのドメインまたはその上位ドメイン（Public Suffix を除く）に限られます）
JavaScript が Cookie の値を読み込んでクエリパラメーターに付与して他ドメイン（外部計測サーバーなど）に送信

問題点

ブラウザで発行した Cookie をクエリパラメーターとして他ドメイン（媒体計測サーバーなど）に送信する方法の問題点は以下のとおりです。

有効期限の制限：ブラウザで発行した Cookie の有効期限は ITP により最長 7 日間に制限されるため長期的な計測ができません
Link Decoration 対策： Safari は ITP 2.2（2019年）以降、トラッキングドメインと分類されたサイトからのリンク修飾（クエリパラメーターによるユーザー識別情報の受け渡し）を経由して発行された Cookie の有効期限を 24 時間に短縮しています。さらに Safari 26 では、既知のフィンガープリンティングスクリプトとして分類されたスクリプトが URL クエリパラメーターや document.referrer を読み取ること自体を制限する方向に強化されています
- Link Decoration の例：?gclid=xxx や ?fbclid=xxx
サーバー発行 Cookie の識別・優遇の方向性： JavaScript で発行した Cookie を「サーバー発行と区別する」仕組みの標準化が IETF で議論されています（__Http- / __HttpOnly Cookie Name Prefix の提案）。現時点で強制はされていませんが、将来的にサーバー発行 Cookie （ HttpOnly ）が優遇される仕組みが整備される可能性があります。

参考：

ユーザー計測の歴史

準備ができたので Cookie とユーザー計測（トラッキング）の歴史を見ていきます。

繰り返しになりますが Cookie の原則を再度記載します。

JavaScript（ document.cookie ）で発行した Cookie を別ドメインへ自動送信する手段は仕様上、黎明期から現在に至るまで存在しません。これは ITP や SameSite 属性による制限以前の問題であり Cookie の基本仕様として最初からできません。

1. 黎明期

初期の Google Analytics（ Urchin ベース、2005 年頃）はファーストパーティ Cookie（ JavaScript で発行）を使ってユーザーを識別していました。
一方で広告配信の文脈では DoubleClick などがサードパーティ Cookie を使ってクロスサイトトラッキングを行っており、当時はまだ SameSite 属性が存在せず、すべての Cookie がクロスサイトで送信されることをブラウザが許容していました（ただし Safari は初期の頃からサードパーティ Cookie に独自の制限を設けており、他ブラウザより厳しい姿勢を取っていました）。

黎明期のサードパーティ Cookie によるクロスサイトトラッキングについて簡単に触れます。

仕組みは Cookie の自動送信を利用したものです。example.com に広告配信サーバー（another.com）の <img> タグや <script> タグを埋め込むことで、ブラウザは another.com に対してリクエストを送ります。このリクエストに対して another.com のサーバーが Cookie を発行・受信することでユーザーを追跡していました。

当時は訪問中でないドメインのサーバーが発行した Cookie であっても、ブラウザがそれを受け入れ・送信する動作がデフォルトでした（後述する Chrome 80 の SameSite 変更はこのデフォルト動作を改めたものです）。

2. ITP による制限（ Safari 2017年〜）

Safari は ITP（ Intelligent Tracking Prevention ）を通じて段階的にトラッキング制限を強化しました。

重要な点は ITP はサードパーティ Cookie をブロックするだけにとどまらずファーストパーティ Cookie を使った迂回策を制限する方向に進化したことです。

ITP 1.0（ 2017 年 9 月）：機械学習でトラッカードメインを分類して分類されたドメインのサードパーティ Cookie を制限（ 24時間のインタラクション猶予あり）
ITP 2.0（ 2018 年 6 月）： 24時間猶予を廃止。分類されたドメインのサードパーティコンテキストでの Cookie アクセスを即時ブロック。Storage Access API を導入（ユーザーの明示的な許可があればアクセス可能）
Safari 13.1（ 2020 年 3 月）：サードパーティ Cookie を全面ブロック
- Safari に関しては上述した黎明期のクロスサイトトラッキングができなくなりました。ビジネス面でもモバイルの重要性が増している時期に、大きなシェアを持つ Safari の制限強化はユーザー計測に大きな影響を与えました

ユーザー計測を提供するサービスはサードパーティ Cookie の制限に Link Decoration という手法で対応しました（この手法は現在も広く使用されています）。

Link Decoration は JavaScript でファーストパーティ Cookie を発行してクエリパラメーターで他ドメインに送信する手法です。ITP はこの方法も制限する方向に進みました。

ITP 2.1（ 2019 年 2 月）： document.cookie で発行したすべての永続的な Cookie（セッション Cookie を除く）の有効期限を最大 7 日に制限。なお ITP 1.x はトラッカーと分類されたドメインのみが対象でしたが、ITP 2.1 からはすべてのサイトの document.cookie が対象となった点が重要な変化です
- ITP 2.1 時点ではサーバー発行（ Set-Cookie ）の Cookie は制限を受けない（後述の Safari 16.4 で波及）
ITP 2.2（ 2019 年 4 月）：トラッカードメインからのリンク修飾（Link Decoration）経由でページに到達した場合、そのページのファーストパーティ Cookie の有効期限を 24 時間に制限
ITP 2.3（ 2019 年 9 月）：localStorage 等 Cookie 以外のストレージも 7 日制限に拡大

3. Chrome の SameSite デフォルト値変更（ 2020 年 2 月）

Safari ITP とは実装アプローチが異なりますが、同じくプライバシー強化という潮流の中での変更です。

Chrome 80（ 2020 年 2 月）： SameSite 属性未指定の Cookie を Lax に変更
- サードパーティ Cookie として機能させるには SameSite=None; Secure の明示指定が必須化
- Firefox も同時期に同様の対応を実施

4. ITP のさらなる強化（迂回策を制限 2020 年〜）

ユーザートラッキングのサーバーサイドへの移行が進む中 ITP はさらなる迂回策も制限します。

CNAME クローキング対策（ Safari 14 / 2020 年 11 月）：計測サーバーを自社サブドメインの CNAME で隠蔽する手法を検知し、該当レスポンスで発行された Cookie の有効期限を 7 日に制限（詳細：WebKit – CNAME Cloaking and Bounce Tracking Defense）
IP アドレスクローキング対策（ Safari 16.4 / 2023 年 4 月）：CNAME を使わず A / AAAA レコードで直接サードパーティ IP に向ける迂回手法にも対応。サーバー発行 Cookie であっても対象となる。判定基準の詳細は WebKit の公式ドキュメントを参照：WebKit – Tracking Prevention in WebKit
Cookie の寿命上限の一般化（ Chrome 104 / 2022 年 8 月）：RFC 6265bis の勧告に沿い、Set-Cookie の Max-Age / Expires を発行元（サーバー / JavaScript）を問わず最大400日にキャップ。ITP のようなトラッキング対策としてではなく Cookie 仕様そのものの変更として導入された点が異なります。

[!IMPORTANT]

2019年：Google が Privacy Sandbox 構想を発表。サードパーティ Cookie に代わるプライバシー保護技術（Topics API、Protected Audience API など）の開発を開始。

2020年：Chrome でもサードパーティ Cookie を段階的に廃止すると発表（当初目標は2022年）。

2021年〜2024年：英国競争市場庁（CMA）・情報コミッショナー事務局（ICO）との調整や業界からのフィードバックを理由に、廃止時期が複数回延期（2023年末→2024年後半など）。

2024年1月：Chrome の Stable チャンネル利用者の1%を対象にサードパーティ Cookie 制限のテストを開始（実際に展開されたのはこの段階のみ）。

2024年7月：Google が「独立した新しい同意プロンプトによる強制的な廃止は行わない」方針を表明。

2025年4月：既存のプライバシー設定内でユーザーがサードパーティ Cookie を管理する現状の仕組みを維持する方針を正式に確認。事実上、Chrome における全面廃止計画は撤回されました。

2025年10月：業界での採用が進まなかった複数の Privacy Sandbox API を終了。一方で CHIPS（Cookies Having Independent Partitioned State）、FedCM、Private State Tokens は継続してサポート。

結果として、2026年時点で Safari・Firefox（・Brave 等）はデフォルトでサードパーティ Cookie をブロックしている一方、Chrome は依然としてサードパーティ Cookie をデフォルトで許可し続けるという状態になっています。「主要ブラウザが足並みを揃えてサードパーティ Cookie を廃止する」という数年来語られてきた前提そのものが崩れており、記事の「現在・今後」を語るうえで欠かせない情報です。

現在・今後

Cookie を使ったユーザー計測への制限は段階的にしかし着実に強化されてきました。
これらの制限を踏まえ、Google の サーバーサイド GTM や Account Engagement ファーストパーティトラッキング のように自社ドメインのサーバーが直接 Cookie を発行・管理する手法へのシフトが加速しています。

参考資料まとめ

ドキュメント	内容
RFC 6265	Cookie の基本仕様（Host-only Cookie、Domain 属性など）
RFC 6265bis（最新ドラフト）	RFC 6265 の後継。SameSite 属性、Cookie 寿命上限（400日）を含む現行仕様
MDN – Using HTTP cookies	Cookie の総合ガイド
MDN – Third-party cookies	ファースト/サードパーティの定義・ブラウザの対応状況
MDN – Set-Cookie	Set-Cookie ヘッダーのリファレンス
MDN – Document.cookie	JavaScript からの Cookie 操作
WebKit – ITP 2.2	Link Decoration 対策の導入
WebKit – ITP 2.3	localStorage 等への 7 日制限拡大
WebKit – Tracking Prevention in WebKit	ITP の現行仕様まとめ（eTLD+1単位のパーティション判定、CNAME・IP アドレスクローキング対策を含む）
IETF Draft – HttpOnly Cookie Prefix	サーバー発行 Cookie の識別プレフィックス提案（議論段階）
IETF Draft – Layered Cookies	`__Http-` プレフィックスによる Cookie の層構造提案（議論段階）
Google – Chrome の Cookie 廃止方針に関する更新（2025年4月）	サードパーティ Cookie 全面廃止計画の撤回に関する公式発表
Mozilla – Total Cookie Protection	Firefox のサードパーティ Cookie パーティション化機能（2021年導入・後にデフォルト化）

Cookie の前提知識