プロダクトへの広告効果測定ツール導入時に、ITP（Intelligent Tracking Prevention）について調べる機会があり、システム構成でCDN（Content Delivery Network）を利用している場合のリスクについて学びがありました。
ITP（Intelligent Tracking Prevention）とは？
ITP は、Web サイトを横断するトラッキング（追跡）を防止するための Safari の機能です。主にサードパーティクッキーやその他のトラッキング技術を制限することで、ユーザーのプライバシーを保護します。
ITP はバージョンアップを重ねるごとにその規制を強化してきました。初期の ITP はサードパーティクッキーの保存期間を制限するものでしたが、現在ではファーストパーティクッキーに対しても影響を及ぼすケースがあるため、より複雑な対応が求められます。特に、ログイン状態の維持や、A/B テスト、パーソナライズなど、Cookieを長く利用したいサービスに大きな影響を与えます。
Safari におけるクッキー制御の条件
ITP は、Web サイトのクッキーを「ファーストパーティ」として扱うか、「サードパーティ」として扱い、有効期間を制限するかを複数の条件で判断します。以下に主な制御条件とその導入時期の概要を示します。
| 制御条件 | 導入時期（目安） | 説明 |
|---|---|---|
| サードパーティクッキーのデフォルトブロック | ITP 1.0 (2017) 以降 | Web サイトが直接訪問されていないドメインから設定されたクッキー（サードパーティクッキー）の保存期間を制限（24 時間など）または完全にブロックします。 |
| トラッカーとして認識されたドメインからのファーストパーティクッキーの制限 | ITP 2.1 (2019) 以降 | Safari が「トラッカー」と認識したドメインが設定したファーストパーティクッキー（ユーザーが直接訪問したドメインのクッキー）であっても、有効期限を7 日間に制限します。これは、CNAME（Canonical Name）レコードを利用してトラッカーがファーストパーティに見せかける手法（CNAME Cloaking）への対策です。 |
| JavaScript で設定されたファーストパーティクッキーの期限 | ITP 2.2 (2019) 以降 | 特定の条件（例えば、トラッカーと認識されたドメインへのリダイレクト後に JavaScript で設定されたクッキー）において、ファーストパーティクッキーの有効期限を24 時間に制限します。 |
| IP アドレスの第二オクテットまでの違いによるサードパーティ判定 | Safari 16.4 (2023) 以降 | Web サイトのメインドメインと、そのサイトにコンテンツを提供するサブドメイン（例：CDN や計測タグのドメイン）のIP アドレスの第二オクテットまでが異なる場合、たとえ eTLD+1（Effective Top-Level Domain + 1、例: example.com）が同じであっても、別のエンティティ（トラッカー）として認識し、クッキーの有効期限を制限する可能性が高まります。これは、IP アドレスを変えることでファーストパーティに見せかけようとする「A Record Cloaking」といった手法への対策の一環です。 |
CloudFront を利用している場合の注意点
AWS CloudFront のようなCDN（Contents Delivery Network）を利用している場合、ITP の影響を受ける可能性があります。
CloudFront は、オリジンサーバーからコンテンツをキャッシュし、ユーザーに地理的に近いエッジロケーションから配信することで、Web サイトの表示速度を向上させます。この際、ユーザーのブラウザから見て、Web サイトのドメイン（例: www.yourdomain.com）と、実際にコンテンツを提供している CloudFront のエッジサーバーの IP アドレスが、以下のような理由でITP のファーストパーティ判定に影響を与える可能性があります。
-
CloudFront は動的なルーティングによりIPアドレスが変動する
CloudFront のエッジサーバーは世界中の多数のロケーションに分散配置されており、ユーザーからのリクエストは動的ルーティングによって最も近く、最適なエッジサーバーに振り分けられます。この最適化により、同一ユーザーであってもアクセスするたびに異なるIPアドレスのエッジサーバーに接続される可能性があります。CloudFront の IP アドレスは AWS が管理する動的なプールから割り当てられるため、固定的なIPアドレスレンジに依存することはできません。
この点は下記ドキュメント内には直接的な記載がないですが、エッジサーバのIPが第1オクテッドから第4オクテッドまで全て異なる可能性があることは、AWS Supportに問い合わせのうえ確認済みです。
https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/LocationsOfEdgeServers.html -
異なるエッジサーバーへの接続により、サイトアクセス時の IP と、Cookie発行時の IP が異なり、ファーストパーティクッキーと判定されず有効期間が短くなる可能性
ITP は、IP アドレスの第二オクテットまでが異なる場合に、異なるエンティティと見なし、クッキーの有効期限を制限することがあります。CloudFront を利用している場合、あるユーザーが最初にサイトにアクセスした際に接続したエッジサーバーの IP アドレスと、その後Cookieを発行した際に接続したエッジサーバーの IP アドレスが異なり、ITP が判断する「IP の第二オクテットまでが異なる」条件に該当する可能性があります。
ブラウザは直接オリジンサーバーの IP アドレスを検知するわけではありませんが、ITP はドメインと IP アドレスの関連性、さらにはその IP アドレスのネットワーク帯域や過去のトラッキング履歴など、複数の要素を総合的に判断して「サードパーティであるか否か」を推測します。
このため、異なるエッジサーバーを経由したことで、ITP が不自然だと判断するような「IP アドレスの乖離」があると、ファーストパーティコンテキストで設定したクッキーであっても、ITP によって「トラッカーが発行したもの」と認識され、有効期間が 24 時間や 7 日間に短縮されてしまう可能性があります。
これが頻繁に発生するかどうかは、サイトの構成、CloudFront の設定、ITP のバージョン、そして Safari のヒューリスティックの具体的なアルゴリズム（公開されていないため推測の域を出ませんが）に依存します。しかし、発生する可能性は考慮しておくべきでしょう。
【重要】サーバーサイドトラッキングでも完全解決は困難
サーバーサイドGTM（Google Tag Manager）などを用いてサーバー側でCookieを発行・設定するアプローチは、JavaScriptで設定されたCookieに対するITPの7日間制限を緩和できます。しかし、ユーザーから見た送信元IPアドレスは最終的にCloudFrontのエッジサーバーのものとなるため、根本的な課題は残ります。異なるエッジサーバーへの接続により「IPアドレスの第二オクテットまでの違い」が発生すれば、ITPはこれを異なるエンティティからのリクエストと判断し、サーバーサイドで設定されたCookieであってもその有効期限を短縮するリスクが残ります。
CloudFront における ITP 対策の限界と代替策の検討
CloudFront を利用している場合、「IPアドレスの第二オクテットまでの違いによるサードパーティ判定」への根本的な対策は、CloudFrontの分散アーキテクチャの特性上、技術的に困難です。世界中に分散したエッジサーバー間でのルーティング最適化は、ユーザーが常に同じIPアドレス帯のエッジサーバーに接続されることを保証できません。
対処法としてのCDN選択肢の検討
このため、CloudFrontを利用し続ける場合、ITPによるCookie制限のリスクを完全に排除することは現実的ではありません。
代替ソリューションとして、以下のような選択肢が考えられます：
- Anycast IPによる固定IP：CloudflareのようなAnycast IPを提供するCDNサービス
- AWS CloudFrontのAnycast静的IP機能：2023年以降提供されている静的IP割り当て機能
- リバースプロキシ構成：自社サーバーを経由してCookieの送信元IPを統一する構成
これらの選択肢は、IPアドレス判定基準に対してより効果的な対応が期待できますが、コスト、パフォーマンス、既存システムとの連携を総合的に評価して判断することが重要です。
まとめ
ITPはWebサイト運営者にとって継続的な課題であり、その動向を注視し、適切な対応を取ることが重要です。特にCloudFrontのようなCDNを利用している場合は、IPアドレスの変動によるサードパーティ判定のリスクを理解し、長期的なデータ計測戦略を策定する必要があります。
Discussion