ITP（Intelligent Tracking Prevention）とは何ですか？

AppleがiOS Safariに搭載しているトラッキング防止機能です。2026年現在、JavaScript（document.cookie）で発行したファーストパーティCookieは最長7日で削除され、トラッカー判定されたドメイン経由の場合は24時間に短縮されます。サードパーティCookieは原則ブロックされます。これによりLP上でJSが保存した広告クリックID（fbclid/gclid/yclid）も7日を超えると失われる可能性があります。

ITPはLINE友だち追加の計測にどう影響しますか？

広告クリック→LP→（後日）LINE友だち追加、という動線で、LP上のCookieに保存した広告クリックIDが友だち追加までに7日を超えて経過すると、ITPによってCookieが削除され、どの広告から来たかを突合できなくなります。逆に言えば、友だち追加までが7日以内であれば影響を受けにくいということです。

ITPの7日制限を完全に回避する方法はありますか？

JavaScriptで発行するファーストパーティCookieである限り、7日上限を「完全に回避」することはできません。サーバーがSet-Cookieヘッダで発行するファーストパーティCookieは制限が緩くなりますが、これも環境次第です。現実的な対策は、①LINE友だち追加までの動線を短くする、②CookieだけでなくsessionStorage等の併用、③コンバージョン送信自体をサーバーサイド（CAPI）で行いブラウザCookieに依存させない、の組み合わせです。

サーバーサイドCAPI送信ならITPの影響を受けないのですか？

送信処理そのものはサーバーで実行するため、CV送信の瞬間にブラウザCookieやITPの状態に依存しません。ただし「どの広告から来たか」を紐づけるための広告クリックIDは、最初にLP上のブラウザで取得・保持する必要があります。したがってITPの影響は『送信』ではなく『取得・保持できる期間』に出る、と理解するのが正確です。

iOSのChromeやFirefoxでもITPは効きますか？

iOS版のChrome・Firefoxは、Appleの仕様上、内部レンダリングエンジンがSafariと同じWebKitです。そのためITPの挙動はiOS Safariに準じます。一方、Android版のChromeやデスクトップのChromeはITPの対象外です（別途、サードパーティCookie廃止の動きはあります）。計測設計はOS・ブラウザごとに分けて考える必要があります。

iOS Safari ITP環境でLINE友だち追加を計測する限界と対策【Cookie 7日制限・2026年最新】

iOS Safari の ITP（Intelligent Tracking Prevention） は、JavaScriptで発行したファーストパーティCookieを 最長7日で削除します。これは、LINE友だち追加を広告のコンバージョンとして計測する際に、見落とされがちな「計測ロスの隠れた原因」です。

結論から言うと、ITPの影響は 「CVを送信できるか」ではなく「広告クリックIDをどれだけの期間ブラウザに保持できるか」 に出ます。本記事では、ITPがLINE計測に与える影響を条件別に整理し、実害を最小化する設計を解説します。

結論：ITPの影響範囲と対策

論点	実態	対策の方向性
JS発行Cookie	iOS Safariで最長7日（トラッカー判定時24h）	友だち追加までの動線を短く保つ
サードパーティCookie	原則ブロック	ファーストパーティ＋サーバー側で完結
CV送信	サーバーから送ればブラウザに非依存	CAPIサーバーサイド送信
iOS Chrome/Firefox	中身はWebKit→ITP準拠	OS/ブラウザ別に設計

ITPとは何か（2026年時点）

ITPはAppleがプライバシー保護のためSafariに搭載した仕組みです。2026年現在、広告計測に効いてくる主な制約は次の通りです。

document.cookie（JS）で発行したファーストパーティCookieは最長7日で削除
トラッカー判定されたドメインを経由した場合は 24時間 に短縮
サードパーティCookieは原則ブロック
リンク装飾（クエリパラメータ）経由の流入も監視対象

ポイントは、ITPが消すのは主に JavaScriptが書き込んだCookie だという点です。

なぜLINE友だち追加の計測でITPが問題になるのか

LINE友だち追加を広告CVとして計測する典型的な動線はこうです。

広告クリック（fbclid/gclid/yclid付き）
→ LP着地（ここでCookieにクリックIDを保存）
→ LINE友だち追加
→ Webhookで友だち追加を検知
→ クリックIDと突合してCAPI送信

このとき、LP上のCookieに保存した広告クリックIDが、友だち追加までに7日を超えて残っているかが鍵になります。

友だち追加が クリック当日〜数日以内 → Cookieが生きており計測できる
友だち追加が 8日以上後（後日じっくり検討して登録）→ ITPでCookie削除済み → 突合できず計測ロス

BtoBや高額商材で検討期間が長いケースほど、この「7日の壁」に当たりやすくなります。

ITPの「7日制限」を完全には回避できない

まず正直に書きます。JavaScriptで発行するファーストパーティCookieである限り、ITPの7日上限を完全に回避する方法はありません。「ITP完全対応」「ITPの影響ゼロ」とうたうツールがあれば、その範囲を冷静に確認すべきです。

現実的な対策は、次の3つの組み合わせです。

動線を短くする — 広告→LP→友だち追加の摩擦を減らし、7日以内の登録比率を上げる
保持手段を多重化 — Cookieに加えてsessionStorage等を併用し、同一セッション内の取りこぼしを減らす
送信をサーバーサイドに寄せる — CV送信をCAPIでサーバーから行い、送信時点でブラウザCookieに依存させない

「サーバーサイドCAPI送信」が効く理由と、効かない部分

CAPI（Conversions API）でサーバーからCVを送る方式は、ITP対策として有効ですが、どこに効くかを正確に理解する必要があります。

フェーズ	ブラウザ依存	ITPの影響
① 広告クリックIDの取得・保持（LP上）	依存する	影響あり（7日制限）
② 友だち追加の検知（Webhook）	依存しない	影響なし
③ CVのCAPI送信（サーバー→各媒体）	依存しない	影響なし

つまりCAPIは②③を堅牢にしますが、①の「保持期間」はブラウザ側の制約を受けます。ITP対策の本質は、①の取りこぼしをいかに減らすかにあります。

Linetraceのアプローチ（実装ベース）

Linetraceの計測タグは、この①の取りこぼしを抑えるために、iOS Safariを判定してCookieの有効期限を切り替える設計になっています。

タグが navigator.userAgent で iOS Safari（ITP環境）を自動検出
ITP環境では Cookie の有効期限を 7日（604,800秒） に設定、それ以外の環境では 365日
広告クリックID（fbclid / gclid / yclid / ttclid / msclkid 等）とUTMを Cookieと sessionStorage の両方に保持
コンバージョン送信は LINE Webhookの友だち追加イベントと突合してサーバーから実行（Meta CAPI / Google GA4計測 / Yahoo CAPI）

この設計は「ITPを回避する」のではなく、ITPの制約に正面から合わせたうえで、送信をサーバーサイドに寄せて実害を抑えるという考え方です。7日以内の友だち追加であれば計測でき、送信処理はブラウザの状態に左右されません。

⚠️ 注意：検討期間が7日を超える友だち追加は、現状どのCookie方式でも取りこぼしが起こりえます。この点は誇張せず、動線設計とあわせて改善するのが現実的です。

iOS Chrome・Firefoxでも同じ挙動になる

意外と見落とされますが、iOS版のChrome・FirefoxはAppleの規約により内部エンジンがSafariと同じ WebKit です。そのためITPの挙動はiOS Safariに準じます。「iOSではブラウザを変えてもITPは効く」と理解しておきましょう。一方でAndroid Chromeやデスクトップは対象外で、設計上の前提が変わります。

まとめ

ITPは JS発行Cookieを最長7日で削除。LINE友だち追加の計測では「クリックから登録までの経過日数」が鍵
完全回避はできない。動線短縮・保持多重化・サーバーサイド送信の組み合わせが現実解
CAPIサーバーサイド送信は 送信フェーズを堅牢にするが、取得・保持フェーズはブラウザ制約を受ける
iOSはChrome/FirefoxもWebKit＝ITP準拠

LinetraceはiOS Safariを検出してCookie期限を調整し、CVはサーバーから各媒体へ直送する設計です。実際の挙動は2週間無料トライアル（クレジットカード不要）で確認できます。

Linetraceの無料トライアルを始める →