ITPの変遷・最新の仕様と挙動の違い／対策の必要性と方法

calendar Oct 7, 2019 / · 2 分で読了 · privacyITPCookie  ·
共有する: linkedin copy

概要

この記事ではSafari/WebKitのIntelligent Tracking Prevention（ITP）の仕様を、2026年3月現在の最新情報に基づいて解説する。各ブラウザのプライバシー対策の全体像やサードパーティcookie代替技術についてはtracking-privacy-by-browsers.mdを参照されたい。

われわれウェブサイト運用者は

  • cookieやローカルストレージなどを使ってブラウザにドメインのデータを保持し、
  • それらのデータを必要に応じてツール間で連携する

ことによって行動計測やコンテンツの出し分けなどのマーケティング活動を行っている。ITPはウェブサイト訪問者のプライバシー保持のためにそれを制限する仕組みである。具体的に何をやっているのかざっくりまとめると、

ITPの前提条件
ITPの前提条件
この3つのケースにおいて

  • cookieなどを使ったデータ保持が短期間しかできなくなる（期間の長さはケースごとそれぞれ異なる）
  • リファラが使い物にならなくなる

可能性があるということである。その結果

  • コンバージョントラッキングができない
  • リマーケティング広告が配信できない
  • cookieを使うツール
    • GoogleアナリティクスやAdobe Analyticsなどのウェブ解析ツール
    • Treasure DataなどのCDP
    • ABテスト
    • その他あらゆるcookieを使うツール

でデータが不正確になるリスクがある。せっかく高額なCDPなどのツールを導入しても、場合によっては使い物にならなくなるのである。

ドメインAからドメインBに遷移したとき

前提条件:

  • ドメインAがトラッカー認定されている
  • リンクにクリックIDなど、トラッキング用の文字列が入っている（リンクデコレーション）

発生する結果: ドメインBにおいて

  • JavaScriptで生成するすべてのcookieの有効期限（寿命）が24時間になる
  • リファラの文字列がeTLD+1（ドメイン名単位）に切り上げられる（ページパスやクエリ文字列を含まなくなる→流入元ページを特定できなくなる）

ドメインBとドメインAのデータ連携に制約が発生するということになる。自社ドメインがトラッカー認定されてしまい、クロスドメイントラッキングでリンクにIDを付けていると、遷移先のcookieが全滅することもある。

ITP 2.2の当初仕様ではリンクデコレーションの文字列とcookieの値が一致する場合のみ24時間制限の対象としていたが、ITP 2.3以降の実際の挙動ではリンクデコレーション付き流入時にランディングページ上のJavaScript生成cookieが広く24時間制限の対象になる。

ドメインBからドメインCのスクリプト／画像／iframe（ドメインCのリソース）を読み込むとき

発生する結果:

  • ドメインCのサードパーティcookieが使えない

Safari 13.1（iOS 13.4）以降、トラッカー認定の有無にかかわらずすべてのサードパーティcookieがデフォルトでブロックされる。例外はない。正当な用途でクロスサイトのcookieアクセスが必要な場合はStorage Access APIを通じてユーザの許可を得る必要がある。

前提条件: なし（ページ遷移や読み込むリソースやドメインの性質によらず）

発生する結果:

  • JavaScriptで生成するあらゆるストレージの有効期限が最大で7日になる
    • cookieの設定できる有効期限が最大で7日になる（ITP 2.1以降）
    • ローカルストレージ、IndexedDB、SessionStorage、Service Workerの登録とキャッシュ、Media keysが未操作7日で消去される（2020年3月アップデート以降）。ただしホームスクリーンに設置したPWAは対象外

どんなケースにおいてもJavaScriptで生成するあらゆるデータを1週間を超えて保存できないということで、強い制約である。有効期限のカウントはブラウザを実際に使用した日数で計算される（ブラウザ未使用日はカウントされない）。

「トラッカー認定される」基準は何か？

  • 当該ドメインがリソース（スクリプトなど）として他のドメインで読み込まれた数
  • 当該ドメインがiframeとして他のドメインで読み込まれた数
  • 当該ドメインが他のドメインで読み込まれたときの、そこからのリダイレクト（ドメイン）数
  • 当該ドメインにアクセスした（親フレームとして読み込まれた）ときに、そこからリダイレクトしたドメイン数

に基づいてITPの機械学習分類モデルがオンデバイスで判定する。Googleなどはまさにこの条件を満たすが、自社ドメインがこれを満たしてしまうケースもないわけではない。特に大規模のポータルサイトやグループサイトになっていると陥りやすいし、CDNで自社ドメインを使っていると危険である。

トラッカー認定されたドメインのうち、30日間ファーストパーティとしてのユーザインタラクションもStorage Access APIによるアクセス許可もないものは、すべてのウェブサイトデータが削除される。

影響を受けるのは主にcookieやローカルストレージなどのストレージとリファラであり、これらがどのような影響を受けるかを整理する。

すべてのサードパーティcookieがブロックされる。例外はない（WebKitは特定のドメインへの例外も設けないと明言している）。Storage Access APIを通じてユーザが明示的に許可した場合のみアクセスできる。

サードパーティのLocalStorageとIndexedDBはファーストパーティごとにパーティション化され、かつエフェメラル（非永続）な扱いになる。Service Workerもパーティション化される。HTTPキャッシュもファーストパーティごとにパーティション化される。

JavaScriptで生成するファーストパーティcookieとストレージの有効期限が以下のように制限される。

  • 通常の流入: 最大7日
  • トラッカー認定ドメインからのリンクデコレーション付き流入: 24時間

24時間制限が適用された状態でサイト内ページ遷移をしても有効期限は延長されない。リンクデコレーションのない再流入（またはトラッカー認定されていないドメインからの流入）があって初めて7日に戻る。

  • サードパーティのリファラ: HTTPヘッダ・document.referrerともにオリジン単位（ドメイン名のみ）にデフォルトで切り詰められる
  • ケース1（トラッカー認定＋リンクデコレーション）の場合: eTLD+1に切り詰められる

Safari 14.0.1（iOS 14.2、macOS Big Sur）以降、CNAME cloakingによるITP回避が対策されている。

サードパーティのトラッキングドメインをファーストパーティのサブドメインとしてCNAMEレコードで偽装し、ファーストパーティcookieとしてサーバサイドcookieを発行することでITPのJS cookie制限を回避する手法。

ITPはDNS解決時にCNAMEチェーンを検査する。ファーストパーティのサブリソースがCNAME解決の結果、ファーストパーティドメインとは異なるregistrable domainに解決される場合、そのHTTPレスポンスで設定されるcookieの有効期限が7日に制限される。

判定基準:

  • サブドメイン（例: tracker.example.com）のCNAME先が同一のregistrable domain（例: other.example.com）→ 制限なし（正当なファーストパーティ）
  • サブドメイン（例: tracker.example.com）のCNAME先が異なるregistrable domain（例: tracking.adtech.net）→ 7日制限が適用

CNAMEだけでなく、解決先のIPアドレスもチェックされる。CNAME先のIPアドレスがファーストパーティのサーバとは異なるネットワークに属する場合、同様に7日制限が適用される。これはCDNのエッジサーバを介したクローキング（サイト全体がエッジサーバ経由でCNAMEクローキングされているケース）にも対応するための仕組みである。ただしサブドメインとトップフレームのホストが同一のCNAME先に解決される場合（例: 両方ともabc123.edge.exampleに解決する）は正当なCDN利用と判断され、制限は適用されない。

リダイレクトを利用したトラッキング（バウンストラッキング）に対しても防御がある。あるドメインから10回のユニークなナビゲーショナルリダイレクトが検出されると、そのドメインのcookieがSameSite=Strictに書き換えられ、クロスサイトのナビゲーション時にcookieが送信されなくなる。

Safari 17（iOS 17、macOS Sonoma、2023年9月）で導入されたLink Tracking Protectionは、URLに付与された既知のトラッキングパラメータを自動的に除去する機能である。ITPとは別の仕組みであり、cookieではなくURL自体に対する対策である。

  • Safariのプライベートブラウジング
  • メッセージアプリでのリンク共有時
  • メールアプリでのリンク

通常ブラウジングモードでは適用されない（Safari 26時点）。ただしATFP（後述）を有効にすると通常ブラウジングでも適用される。

gclid（Google Ads）、fbclid（Facebook）、mkt_tok（Marketo）など、既知のトラッキングパラメータが除去される。除去リストはPrivacyTests.orgが管理するトラッキングパラメータリストに基づく。

utm_source、utm_medium、utm_campaignなどのUTMパラメータは除去対象外である。

Safari 17で導入されたオプション設定。有効にすると以下の保護が追加される。

  • Link Tracking Protectionが通常ブラウジングでも有効になる
  • 既知のトラッカードメインへのネットワークリクエストを完全にブロック

Safari 26（iOS 26、macOS 26、2025年9月）で導入されたAFP（Advanced Fingerprinting Protection）は、フィンガープリンティングによるトラッキングを防止するデフォルト有効の機能である。ATFPとは異なりユーザ設定によらず常に動作する。

フィンガープリンティングとは、画面サイズ、GPU、オーディオスタック、インストールされたフォントなど数十のブラウザ・デバイス特性を組み合わせて個人を一意に識別する手法である。

AFPの対策:

  • 2D Canvas、WebGL、WebAudioのAPI出力にノイズを注入し、スクリプトが一意のフィンガープリントを生成できないようにする
  • 既知のフィンガープリンティングスクリプトに対して高エントロピーAPIへのアクセスを制限
  • フィンガープリンティングスクリプトからの長期ストレージへのアクセスを制限
  • フィンガープリンティングスクリプトからのURLクエリパラメータおよびdocument.referrerへのアクセスを制限
  • iOS 12, Safari 12以降
  • https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/
  • 主なアップデート
    • 多重リダイレクトのトラッカー認定
    • トラッカー認定されたドメインのサードパーティcookieの即排除
    • トラッカー認定されたドメインでユーザインタラクションのない場合のリファラを制限
  • iOS 13.4, Safari 13.1以降
  • https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/
  • 主なアップデート
    • サードパーティcookieを完全にブロック（トラッカー認定の有無を問わず）
    • cookie以外のストレージ（IndexedDB, LocalStorage, Media keys, SessionStorage, Service Worker registrations and cache）も寿命7日に制限。ホームスクリーンに設置したPWAは対象外
    • すべてのドメインに対してdocument.referrerがドメイン単位に制限
  • iOS 17, macOS Sonoma以降
  • 主なアップデート
    • Link Tracking Protection（プライベートブラウジング、メッセージ、メールで既知のトラッキングパラメータを除去）
    • ATFP（Advanced Tracking and Fingerprinting Protection）オプション設定の追加
  • iOS 18, macOS Sequoia以降
  • 主なアップデート
    • プライバシーマニフェスト要件の全App Storeアプリへの適用
  • iOS 26, macOS 26以降
  • 主なアップデート
    • AFP（Advanced Fingerprinting Protection）のデフォルト有効化
    • Canvas/WebGL/WebAudioへのノイズ注入によるフィンガープリンティング防止
    • Link Tracking Protectionの範囲拡大

iOSではすべてのブラウザがWebKitの使用を義務付けられており、iOS版ChromeやFirefoxにもITPが適用される。ただし2024年3月のiOS 17.4以降、EU域内ではDigital Markets Act（DMA）に基づき代替ブラウザエンジンの使用が許可されている。EU域内のiOSユーザがBlink（Chrome）やGecko（Firefox）エンジンを使用している場合、ITPは適用されない。

https://support.apple.com/ja-jp/HT201222

  • Googleの検索広告からの流入（URLにgclidパラメータ付き）の場合にGoogle広告やGoogleアナリティクスのcookieの有効期限が24時間になる
    • 広告のコンバージョントラッキングのみならず通常のウェブ行動計測やCDPとしての用途にも影響がある（リマーケティングはすでに不可）
  • Safari 17以降のプライベートブラウジングではgclidやfbclidがURLから除去されるため、パラメータ自体がサイトに到達しない
  • あらゆるJavaScript生成のファーストパーティcookieの有効期限が最大7日に制限されるため、7日以上間隔を空けた再訪問で新規ユーザとしてカウントされる
  • 自社ドメインがトラッカー認定された状態でクロスドメイントラッキングを実装していると、遷移先のcookieが全滅することがある
  • CNAME cloakingによる回避策も対策済みのため、単純なCNAME設定では有効期限7日制限を回避できない
  • Safari 26以降ではフィンガープリンティングによる代替トラッキングも無効化される

特定のタグが生成するcookieに限定されず、JavaScriptが生成するあらゆるcookieが対象になる。そのため各タグの発行プラットフォームの対応を待つ、タグごとの対応では不十分で、自前であらゆるcookieを対象にした対策が必要になる。

JavaScriptで生成されたクライアントサイドcookieではなく、Webサーバ側からHTTPレスポンスヘッダ（Set-Cookie）でcookieを生成すればITPの7日制限を回避できる。ただし以下の条件を満たす必要がある。

  • cookieを発行するサーバのドメインがファーストパーティである（サイトと同じregistrable domain配下）
  • CNAMEレコードで割り当てる場合、CNAME先のregistrable domainがサイトと同一でなければならない（異なる場合はCNAME cloaking対策により7日制限が適用される）
  • サーバのIPアドレスがサイト本体のサーバと同一ネットワーク帯に属する必要がある（異なる場合はIPアドレスクローキング対策により7日制限が適用される）

現在もっとも普及している対策はGTM Server-Side Tagging（サーバサイドGTM）である。

  1. Google Cloud Run等にGTMサーバサイドコンテナをデプロイする
  2. ファーストパーティドメイン配下のパスまたはサブドメイン（例: example.com/gtmまたはsgtm.example.com）をサーバに割り当てる
  3. クライアント側のGTMがサーバサイドコンテナにリクエストを送信する
  4. サーバサイドコンテナがHTTP Set-Cookieヘッダでファーストパーティcookieを発行する
  5. サーバサイドcookieはJavaScript生成ではないため、ITPの7日/24時間制限を受けない
  • AレコードまたはAAAAレコードでサーバのIPアドレスを直接指定するのが最も確実
  • CNAMEを使う場合は参照先のregistrable domainがサイトと同一でなければならない
  • Googleは現在、サブドメイン方式ではなくパスベース方式（例: example.com/gtm）を推奨している。パスベースならDNSのCNAME cloaking判定の問題を完全に回避できる

サーバサイドコンテナのIPアドレスとサイト本体のIPアドレスが同一ネットワーク帯に属さない場合、WebKitはサードパーティIPと判定しcookieの有効期限を7日に制限する可能性がある。クラウドプロバイダやCDNの選定時にはIPアドレスの近接性を考慮する必要がある。

GTM Server-Side Taggingを使わない場合も、同様の原理で自前のサーバサイドcookie処理サーバを構築できる。

  1. ページ読み込み時、JavaScriptからファーストパーティのcookie処理サーバにリクエストを送信
  2. サーバがHTTPレスポンスヘッダでサーバサイドcookieの値をJavaScript読み書き可能なcookieとして発行
  3. メインのタグ処理（JavaScriptがcookieを読み書き）
  4. タグ処理完了後、JavaScriptからサーバにリクエストを送信
  5. サーバがJavaScript生成cookieの値をサーバサイドcookieとして保存

ITP対策処理フロー
ITP対策処理フロー

  • 複数のタグ、複数のcookieキーに対して個別に設定する必要がない設計にする
  • ネットワークやサーバ負荷を最小限にする。同一セッション中はcookieが切れることはないため、1セッションに1回のサーバコールにする
  • サーバのドメインはAレコードで割り当てるか、CNAMEの場合は同一のregistrable domainを参照先にする
  • サーバのIPアドレスがサイト本体と同一ネットワーク帯に属するようにする
  • トラフィックが増え、サーバ負荷が増大してきたらサーバをそのまま複製して使える（DNSラウンドロビンを使用可能）
  • 複数のサブドメインで運用するサイトでも、サーバはサイトごとに分ける必要がない（全サブドメインで共通動作する）