Safari、Chrome、Firefox、Edgeはそれぞれ、Cookieがどのくらい保持されるか、third-party cookieを許可するかどうか、そしてJavaScriptで書き込む値（localStorage、IndexedDB）がユーザーの操作なしに保持されるかどうかについて、独自のルールを適用しています。Appleはこの仕組みをIntelligent Tracking Prevention (ITP) と呼び、FirefoxはEnhanced Tracking Protection (ETP) およびTotal Cookie Protection (TCP) と呼びます。2026年現在、ChromeとEdgeには、こうしたユーザーの操作有無に基づく既定の制限はありません。ただし、いずれも要求された値に関わらずCookieの最大保持期間を400日にキャップしています（詳細は後述）。これらのルールは、Treasure Data JavaScript SDKが再訪問者を識別するために使用するtd_client_id、td_global_id、td_ssc_idという識別子が特定のブラウザ上でどのくらい保持されるか、またドメイン間で共有できるかどうかを直接左右します。client-side trackingやserver-side cookie、cross-domain trackingの設定を決める前に、このページを確認してください。
Cookieは、Treasure AIが再訪問者を認識し、あなたのウェブサイトでパーソナライゼーションを提供するための中心的な手段であり続けています。そのため、ブラウザがCookieの制限を強化することは、単なる技術的な詳細ではなく、パーソナライゼーション施策にとってのビジネス課題です。Treasure AIは各ブラウザの制限がどのように変化していくかを継続的に監視し、お客様の組織のプライバシー上の義務とパーソナライゼーションの目標の両方をサポートするオプションを一緒に検討します。
ブラウザ間のCookieの挙動の違いは、ほぼ5つの仕組みで説明できます。
- Third-party cookieのブロック。 アドレスバーに表示されているサイトとは異なるドメインのCookieがthird-party cookieです。Safariは、Safari 13.1（2020年3月）以降、例外なくthird-party cookieを完全にブロックしています。Firefoxはthird-party cookieを完全にブロックはしませんが、分離（isolate）します（後述のTotal Cookie Protectionを参照）。ChromeとEdgeは既定でthird-party cookieを許可します。
- Client-side（JavaScript）Cookieの有効期限キャップ。
document.cookieで書き込まれたCookieは、HTTPのSet-Cookieレスポンスヘッダーで設定されたCookieとは異なる扱いを受けます。ブラウザはスクリプトで書き込み可能なストレージとサーバー制御のストレージを区別できるためです。Safariは、スクリプトで設定されたCookie、localStorage、IndexedDBを、サイトへのユーザーの操作がない場合は7日間に制限します。 - Server-side cookieのキャップとcloaking検出。 正規のfirst-partyサーバーが設定したCookieは、スクリプトで設定されたCookieよりもはるかに長く保持され、ほぼ設定された有効期限どおりに保持されます。Safariは、Safari 14（2020年11月）以降CNAME cloakingを検出しており、Safari 16.4（2023年4月）でIPアドレスcloakingの検出も追加しました。サブドメインのDNSレコードやそれを提供するIPアドレスがサイト自身のインフラと一致しない場合、Safariはそのcookieを偽装されたthird partyが設定したものとみなし、スクリプトで設定されたcookieと同じ7日間にキャップします。これが、サブドメインのDNSをトラッキングベンダーに委任する仕組み — まさにserver-side first-party cookieが依拠しているパターン — が、免除されるのではなくキャップされる理由です。
- ChromeとEdgeにおける絶対的なCookie保持期間キャップ。 ITPのような操作要件とは無関係に、ChromeとEdgeは更新されたCookie仕様（RFC 6265bis）を適用しています。Chrome 104（2022年8月）以降、
document.cookieとHTTPのSet-Cookieヘッダーのどちらで設定されたか、first-partyかthird-partyかに関わらず、すべてのCookieのExpires/Max-Ageは最大400日に自動的にクランプされます。たとえば2年という長い有効期限を設定していても、訪問者が400日以内に再訪してCookieが更新されない限り、400日で失効します。2026年時点でFirefoxは通常のwebサイトCookieにこのキャップを適用しておらず、Safari自身のキャップ（上記）は適用される場面において常に400日より厳しい制限になります。 - Link decorationのキャップ。 訪問者が既知のトラッカーのクリックIDパラメーター（
gclid、fbclidなど）を含むURLからページに到達した場合、Safariはそのランディングページでのスクリプト設定Cookieのキャップを7日間から24時間に短縮します。
| ブラウザ | 既定でThird-Party Cookieをブロックするか | JavaScript設定のCookie／ストレージのキャップ | Server設定のFirst-Party Cookieのキャップ | 補足 |
|---|---|---|---|---|
| Safari（WebKit ITP） | はい — 例外なく常にブロック | サイトへのユーザーの操作がない場合は7日間。ランディングURLに既知のトラッカーのクリックIDパラメーターが含まれる場合は24時間。document.cookie、localStorage、IndexedDBすべてに同様に適用されます。 | 正規のfirst-partyドメインではほぼ設定された有効期限どおりに保持され、WebKitのCNAMEまたはIP cloaking検出が応答しているサーバーを偽装されたthird partyとフラグ付けした場合は7日間にキャップされます（CNAME cloaking検出はSafari 14、2020年11月以降。IPアドレスcloaking検出はSafari 16.4、2023年4月に追加） | WebKit Tracking Prevention |
| Chrome | いいえ | 下記の400日の絶対キャップ以外に制限なし — それ以外は自身のExpires/Max-Ageの値に従って保持されます | 下記の400日の絶対キャップ以外に制限なし | Googleは2025年10月17日にPrivacy Sandboxを終了し、2025年4月にはthird-party cookieを廃止しない方針を確認しました。Related Website Sets（旧称First-Party Sets）自体も段階的に廃止され、Chrome 152での削除が予定されています。また、Chrome 104（2022年8月）以降、すべてのCookieのExpires/Max-Ageを最大400日にクランプしています（上記の「絶対的なCookie保持期間キャップ」を参照）。 |
| Edge（Chromium） | いいえ | 下記の400日の絶対キャップ以外に制限なし | 下記の400日の絶対キャップ以外に制限なし | Chromeと同じChromiumのCookie処理コードを共有しており、同じ400日の絶対キャップが適用されます |
| Firefox | 実質的にはい — Total Cookie Protection（Firefox 103以降、2022年から既定）による | 正規のfirst-party cookieには制限なし | なし | Total Cookie Protectionは削除ではなく分離を行います。third partyのCookieはトップレベルサイトごとに二重キー化されるため、同じスクリプトでもサイトごとに共有されない別々の値になります |
td_client_idは、JavaScript SDKが既定でdocument.cookieによって書き込むfirst-party cookieです。Firefoxは正規のfirst-party cookieに対して一切キャップを適用しないため、設定された有効期限（既定は2年 — config.storage.expiresを参照）が切れるか、訪問者がCookieを削除するまで保持されます。ChromeとEdgeもITPのようなキャップは適用しませんが、更新されたCookie仕様（RFC 6265bis）により、同じ設定値であっても実際の保持期間は最大400日に自動的にクランプされます。Safariでは再訪問がない場合、7日間にキャップされます — これがserver-side cookieという代替手段が存在する理由です。
td_global_idは、顧客が所有するすべてのドメインで同じIDになるという本来の目的を果たすには、ブラウザがthird-party cookieの共有を許可している必要があります。ChromeとEdgeは、いずれも既定でthird-party cookieを許可しているため、この目的を達成できます。Safariでは決して共有されません。Safari 13.1以降、third-party cookieは完全にブロックされており、これを復元する設定はありません。Firefoxではcookie自体は設定されますが、Total Cookie Protectionによってトップレベルサイトごとに分離されるため、実際には顧客の複数ドメイン間で値が共有されません。この機能への影響については、Enabling Cross-Domain Trackingを参照してください。
td_ssc_idは、JavaScriptではなくサーバーがHTTPレスポンスヘッダーでCookieを設定することにより、Safariのdocument.cookieにおける7日間のキャップを超えて保持されるように設計されています。しかし、Treasure Dataのserver-side cookieサービスは、DNSで委任されたサブドメイン上で応答するため、Safari 14（2020年11月）以降はCNAME cloakingとして分類され、同様に7日間にキャップされます。より長い保持期間を前提に計画を立てる前に、該当ページの既知の制限を確認してください。ChromeとEdgeではtd_ssc_idはcloaking検出の対象にはなりませんが、設定された有効期限に関わらずRFC 6265bisにより最大400日にクランプされます。
Third-party cookieを通じてactivateされるsegmentは、配信先がそのcookieをどう分類するかによって影響を受ける可能性があります。各配信先への影響は、activationパートナーと協力して評価してください。
Safariでは、広告インプレッションと後の購買を結びつける識別子がより断片化されるため、attributionはより困難になります。たとえば広告パートナーのドメインで設定されたtd_global_idは、自社サイトで読み取ることができません。
Consentは通常、client-side cookieとして保存されるため、上記と同じキャップが適用されます。JavaScript SDKはconsentをlocalStorageに保存することもサポートしています。詳細はConsentレコードの保存場所の指定を参照してください。
td_client_idは、これらの制限に関わらず同一のトップレベルドメインのサブドメイン間で保持されます。この持続性はcookieのドメインスコープに依存するものであり、ITP、ETP、TCPには依存しないためです。