[!IMPORTANT] レビュー注記（2026年9月時点） この版は元記事をできる限り維持しつつ、事実誤認の訂正と欠落していた重要な出来事の補足を行ったものです。追加・修正箇所には本注記と同様の [!NOTE] / [!WARNING] ブロックまたは取り消し線＋補足で印を付けています。

本記事は 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 日間）

[!WARNING] レビュー修正：表の「サーバー発行」欄について
元記事では「長い（数ヶ月〜2年）」としていましたが、これは現在では不正確です。2022年の Chrome 104 以降、Set-Cookie の Max-Age / Expires はブラウザ側で最大400日にキャップされます（RFC 6265bis の勧告に沿った変更で、サーバー発行・JavaScript発行を問わず、Safari 以外の主要ブラウザにも順次導入されています）。つまり「ITP の制限を受けない＝無制限に長くできる」わけではなく、ITP とは独立したブラウザ共通の寿命上限が存在する点に注意してください。

サーバー発行の 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 日間に制限されます。

[!WARNING] レビュー補足：ドメイン制限は JavaScript 発行に限った話ではありません
上記1.の説明は document.cookie を主語にしていますが、Domain 属性に指定できる範囲（現在のドメインまたはその上位ドメイン、Public Suffix を除く）は サーバー発行の Set-Cookie ヘッダーでも全く同じ制約 を受けます。これは Cookie の仕様（RFC 6265）そのものによる制約であり、発行場所（サーバー/クライアント）による違いではありません。「サーバーなら任意の Domain を指定できる」と誤解しないよう注意してください。

参考:

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 や各ブラウザのプライバシー保護機能が介入するかどうかのトリガーになります。

[!WARNING] レビュー修正：Safari ITP のファースト/サードパーティ判定について（元記事の記述は誤りです）
元記事は「Safari ITP はドメインの完全一致を基準とするため一般的な定義（eTLD+1）より厳格であり、example.com 訪問中の foo.example.com へのリクエストはサードパーティと判定される」としていましたが、これは WebKit 公式ドキュメントの説明と矛盾します。

WebKit の公式説明（Tracking Prevention in WebKit）では、ストレージのパーティション判定は登録可能ドメイン（eTLD+1）単位で行われ、news.example の下で読み込まれた sub.news.example は「同一サイト」とみなされ第一者として扱われる、と明記されています。つまり ITP のファースト/サードパーティ判定も基本的には一般的な定義（eTLD+1）に基づいており、「完全一致でなければ即サードパーティ扱い」という説明は不正確です（過去にサブドメイン間の分離が意図せず発生するバグが報告されたことはありますが、これは仕様ではなくバグとして扱われています）。

なお、ファースト/サードパーティ判定と SameSite 属性の Same-Site 判定が別概念である、という元記事の指摘自体は正しく、両者ともに eTLD+1（＋SameSiteの場合はスキームも含む）を基準にしている点で、実務上はおおむね一致した挙動になります。

参考：

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
  
  [!WARNING] レビュー修正（Safari 26 の説明を正確化）：元記事は「トラッカーと分類されたスクリプト」としていましたが、正確には Safari 26 で導入された Advanced Fingerprinting Protection（AFP） という別機能で、対象は ITP の「トラッカードメイン」分類とは異なる「既知のフィンガープリンティングスクリプト」です。AFP は通常ブラウジングでもデフォルト有効になっており、対象スクリプトによる URL クエリパラメータ／document.referrer の読み取りに加え、長期間持続する Cookie や localStorage への書き込みも制限します。ITP のトラッカー分類の延長線上にある機能ではあるものの、仕組みとしては別物である点に注意してください。
サーバー発行 Cookie の識別・優遇の方向性： JavaScript で発行した Cookie を「サーバー発行と区別する」仕組みの標準化が IETF で議論されています（__Http- / __HttpOnly Cookie Name Prefix の提案）。現時点で強制はされていませんが、将来的にサーバー発行 Cookie （ HttpOnly ）が優遇される仕組みが整備される可能性があります。

[!NOTE] レビュー補足：このドラフトはあくまで議論段階の提案であり、標準化や主要ブラウザでの実装が確定しているものではありません。将来性について言及する際は「実装の見込みは不透明」という留保を付けるのが適切です。

参考：

ユーザー計測の歴史

準備ができたので 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 日制限に拡大

[!NOTE] レビュー補足：Firefox の対策もこの時期に並行して進んでいます
元記事は Safari(ITP) と Chrome(SameSite) を軸に構成されていますが、Firefox も同時期に独自のトラッキング対策を進めています。2019年に Enhanced Tracking Protection（ETP）を導入し、既知のトラッカーからのリクエストをブロック。さらに2021年には Total Cookie Protection（TCP）を導入し、サードパーティ Cookie を訪問中サイトごとに自動的にパーティション化（隔離）する仕組みをデフォルト化しました。これは後述の Chrome の CHIPS（Cookies Having Independent Partitioned State）に近い発想であり、「サードパーティ Cookie を完全ブロックするのではなくサイトごとに分離する」というアプローチの先駆けと言えます。Safari/Chrome の二軸だけでなく、Firefox の動きも歴史の一部として押さえておくべきです。

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] レビュー追記：Chrome のサードパーティ Cookie 廃止計画とその撤回（2019年〜2025年）

元記事にはこの一連の出来事が欠落していますが、2020年代のCookieトラッキング史において最大級の出来事です。

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 を発行・管理する手法へのシフトが加速しています。

[!NOTE] レビュー補足：ただし上記の通り、Chrome は2025年にサードパーティ Cookie の全面廃止計画を撤回しており、「すべてのブラウザがサードパーティ Cookie を廃止する方向に一直線に進んでいる」わけではありません。Safari / Firefox 系のブラウザではファーストパーティ Cookie への移行が引き続き有効な対策ですが、Chrome を含むエコシステム全体では、サードパーティ Cookie を分離して扱う CHIPS のような「廃止ではなく分離」というアプローチも並行して進んでいる点を踏まえて読む必要があります。また、Cookie 制限の副作用として一部のブラウザ（Safari の AFP など）はフィンガープリンティングによる代替トラッキング手法自体への対策も強化しており、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年導入・後にデフォルト化）