「なぜかiPhoneのユーザーだけ、コンバージョンの数字が合わない」——広告運用やサイト改善の現場で、じわじわと相談が増えているテーマです。Chromeで見れば正しく計測できているのに、Safari（iPhone・iPad・Mac）経由だけ数字が薄い。設定を変えた覚えもないのに、なぜか合わない。原因の多くは、Safariに標準搭載された**ITP（Intelligent Tracking Prevention）**によるCookieの制限にあります。
こんな症状に心当たりはありませんか？
- iPhone・Macからの流入は多いのに、Safari経由のコンバージョンだけ少ない
- GA4で、Safariユーザーの新規率が異常に高い（同じ人が何度も新規にカウントされている疑い）
- 数日前にクリックした広告の成果が、アトリビューション期間内なのに紐づいていない
- リピーターとして扱われるはずのユーザーが、毎回はじめて訪れた人のように見える
- 広告のクリックID（
gclid・fbclid）が、数日後には効かなくなっている
この記事では、SafariのITPでコンバージョンが減る・計測されない仕組みと、なぜリピーター識別やアトリビューションが切れるのか、緩和策、そして本番環境で「いま実際にどうCookieが扱われているか」を確認する方法を、実務目線で整理します。
まず前提：ITPは「故障」ではなく「プライバシー仕様」
つまずく最大の原因は、Safariで数字が減るのを「タグの不具合」や「設定ミス」だと決めつけてしまうことです。実際には、これはSafari（正確にはブラウザエンジンのWebKit）が意図的に組み込んでいるプライバシー保護機能の結果です。直そうとしても「直る」ものではなく、前提として織り込むべき仕様だと理解するところから始まります。
ITPが何をするのかを、先に整理しておきます。
| ITPがやること | 具体的な挙動 |
|---|---|
| 一次Cookieの寿命制限 | JavaScriptで発行した一次Cookie（document.cookie）を、原則最大7日で削除。クロスサイト遷移（リンク装飾＝クエリ付き遷移）を経た場合は24時間になることも |
| サードパーティCookieのブロック | 他ドメインが発行するCookieは原則ブロック。クロスサイトのトラッキングを遮断 |
| クロスサイト計測の抑制 | サイトをまたいだユーザー識別を段階的に制限 |
ポイントは、**「JavaScriptで書いたCookieほど、寿命が短く扱われる」**という点です。多くの計測タグは、まさにこのJavaScript経由でCookieを発行します。だからこそ、計測の土台がSafariのITPと真正面からぶつかるのです。
「7日で消える」が、なぜコンバージョンを減らすのか
ITPの中でも実務に最も効いてくるのが、一次Cookieの寿命が最大7日に制限されるというルールです。これがなぜ数字を減らすのか、影響を4つに分けて整理します。
1. リピーター識別が切れる
計測タグは、ユーザーを見分けるためにCookieへ識別子（GA4なら _ga など）を保存します。この識別子が7日で消えると、8日後に再訪した同じ人が「別の新規ユーザー」として数え直されます。結果として、リピーターが減り、新規ユーザーが実態より水増しされます。
つまずきやすい例： 「Safariユーザーの新規率が妙に高い」——これは獲得がうまくいっているのではなく、
_gaが入れ替わって同じ人を新規として何度も数えているサインであることが少なくありません。
2. アトリビューション期間が実質的に短くなる
「広告をクリックしてから14日以内のコンバージョンを成果として数える」といった設定をしていても、その判定に使うCookieが7日（場合により24時間）で消えれば、期間の後半はそもそも紐づけられません。設定上のアトリビューション期間が長くても、Safariでは実質的にそれより短い窓でしか成果を拾えなくなります。
3. gclid・fbclid の保存が失効する
広告から来たユーザーには、どの広告経由かを示すクリックID（Googleの gclid、Metaの fbclid）が付いています。多くの実装では、これをJavaScriptで一次Cookieに保存し、後日コンバージョンした時に読み出します。ところがそのCookieが7日で消えると、後日のコンバージョンを広告のクリックへ結び付けられなくなります。「クリックはあったのに、成果が計上されない」状態です。
4. 新規ユーザーが水増しされる
1〜3が積み重なった結果、Safari環境では同じ人が何度も新規として数えられ、ユーザー数・新規率が実態より膨らみます。分母がふくらむため、コンバージョン率（CVR）が実際より低く見えるという二次的な歪みも生じます。
Safariだけではない：iOSのすべてのブラウザが影響を受ける
見落とされがちなポイントがあります。iOS（iPhoneとiPad）では、Chrome・Firefox・Edgeなどすべてのブラウザが、内部的にAppleのWebKitエンジンを使っています。 これはAppleのApp Storeポリシーによる要件です。つまりITPのCookie制限は、Safariアプリだけでなく、iOS上のすべてのブラウザに適用されます。
実務上の意味：
- 「iPhoneのChrome」でサイトを開いたユーザーにも、Safariと同じ7日間のCookie寿命制限・サードパーティCookieのブロックが適用される
- Safari単独のトラフィックレポートでは、ITPの影響範囲を過小評価してしまう——実際にはiOSブラウザ全体のトラフィックに損失が及んでいる
- 影響を受けるユーザーの割合は、Safariの単体シェアが示すよりもはるかに大きい
影響を見積もるときは、SafariセッションだけでなくiOS全体のトラフィックを見る必要があります。
サードパーティCookieのブロックも効いている
寿命制限に加えて、ITPは他ドメインが発行するサードパーティCookieを原則ブロックします。従来、広告のリターゲティングやクロスドメインの計測は、このサードパーティCookieに支えられてきました。
Safariではこれが使えないため：
- サイトをまたいだユーザー識別ができず、リターゲティングの母集団が小さくなる
- 複数ドメイン（例：本体サイトと決済ドメイン）をまたいだ購入完了の紐づけが切れやすい
- 外部ドメインのタグに依存した計測ほど、Safariでの取りこぼしが大きくなる
つまりSafariでは、「一次Cookieが短命」＋「サードパーティCookieは原則不可」という二重の制限がかかっており、Chromeと同じ実装のままでは数字が合わなくて当然、という状態になっています。
「発火しているのに減る」のはなぜか
タグは動いている（発火している）のに、レポートの数字は減る。ITPで最も混乱するのがこのパターンです。理由は、発火＝リクエストの送信、計測＝Cookieを使った継続的な識別、が切り離されるからです。
Safariでは、タグが正しく発火してリクエストが飛んでいても：
- Cookieが7日で消えるため、同じ人を継続して識別できない（リピートが新規に化ける）
- クリックIDの保存が失効すると、どの広告の成果か分からなくなる
- サードパーティCookieが使えず、クロスサイト・クロスドメインの紐づけが切れる
つまり、「Networkでリクエストが飛んでいるからOK」と判断しても、その裏でCookieが短命化・失効していれば、広告に効く継続的なコンバージョンとしては記録されていないのです。発火の有無だけを見ても、ITPの問題は見抜けません。
見えにくいコスト：シグナル欠損で広告アルゴリズムが劣化する
ITPの影響はレポートの不正確さにとどまりません。広告キャンペーンのパフォーマンスそのものを劣化させます。 Google広告やMeta広告などのプラットフォームは、コンバージョンシグナルを使って機械学習モデルを訓練しています。Safari（およびiOS）のコンバージョンが報告されないと：
- スマート入札やキャンペーン最適化に渡るデータが不完全になる。 実際よりコンバージョンが少なく見えるため、Apple端末に偏るオーディエンスや配置の価値を過小評価してしまう
- 「学習データ不足」ステータスに陥りやすくなる。 レポート上のコンバージョンがプラットフォームの閾値（多くの場合、週50件前後）を下回ると、アルゴリズムが学習フェーズを抜けられず、配信が不安定になりCPAが上昇する
- 類似オーディエンスの精度が落ちる。 iOSユーザーが過小評価されたコンバージョンプールをもとにオーディエンスモデルが構築されるため、Apple以外のデモグラフィックに偏り、最も価値の高い顧客を取り逃す可能性がある
これは悪循環を生みます。コンバージョン報告が減ると最適化が悪化し、実際のコンバージョンが減り、さらにシグナルが減る。この循環を断ち切るには、ブラウザ側のCookie制限を迂回するルートでコンバージョンデータをプラットフォームに戻す必要があります。それがサーバーサイドタグやコンバージョンAPIの役割です。
何ができるか：ITPへの緩和策
ITPは「消す」ことはできませんが、Cookieの発行方法を変えることで影響をやわらげられます。方向性は「JavaScriptで発行するCookieを、より寿命の長い方式に置き換える」ことです。
1. サーバーサイドで一次Cookieを発行する（HTTP Cookie）
JavaScript（document.cookie）ではなく、サーバーがHTTPレスポンスヘッダー（Set-Cookie）で発行した一次Cookieは、ITPの7日制限の対象になりにくくなります。識別子の保存をサーバー側に寄せることが、最も基本的な緩和策です。
2. サーバーサイドタグ（サーバーサイドGTM）を使う
計測タグの処理をブラウザ内ではなく、自社が管理するサーバー経由に移す方式です。Cookieをサーバー側（自ドメイン）で扱えるため、寿命制限やブロックの影響を受けにくくなります。実装は重くなりますが、Safariの取りこぼしに対しては効果の大きい対策です。
3. CAPI（コンバージョンAPI）でサーバーから直接送る
ブラウザ経由ではなく、サーバーから広告プラットフォームへ直接コンバージョンを送る方式（MetaのCAPIなど）です。ブラウザのCookie事情に左右されにくくなるため、Safariでの取りこぼしを補えます。CAPIと拡張コンバージョンを組み合わせることで、ハッシュ化されたファーストパーティデータをコンバージョンイベントと一緒に送信し、マッチ率を高めることができます。
つまずきやすい例： サーバーサイド化したつもりでも、実際のCookieがまだJavaScript発行のまま（
Set-Cookieヘッダーになっていない）というケースは珍しくありません。「対策した」ことと「実際にHTTP Cookieで発行されている」ことは別です。本番のレスポンスヘッダーで、Cookieが本当にサーバー発行になっているかを確認する必要があります。
注意：IPマッチングルールでサーバーサイド対策が無効化されることがある
Safari 16.4以降、WebKitは追加のチェックを行うようになりました。Set-Cookieヘッダーを発行するサーバーのIPアドレスプレフィックスが、ウェブサイトのオリジンサーバーのIPアドレスプレフィックスと一致しない場合、サーバーサイドで発行したCookieであっても7日間に制限されます。
よくあるケースに当てはまります。サイトはあるホスティングサービスで運用し、サーバーサイドGTMコンテナは別のクラウド（Google Cloudやマネージドsgtmサービスなど）で動かしているパターンです。IPレンジが異なるため、Safariが静かにCookieの有効期限を7日に上書きし、緩和策が気づかないうちに無効化されます。
確認すべきポイント：
- sGTMのエンドポイントとウェブサイトが、同じIPプレフィックス範囲のアドレスに解決されるか確認する
- CNAMEサブドメイン（例：
data.yoursite.com）をサードパーティのトラッキングサーバーに向けている場合、WebKitのCNAMEクローキング検知によってもCookieが制限される可能性がある - デプロイ後、本番のSafariブラウザで実際のCookie有効期限を確認する——
Set-Cookieヘッダーだけでは、ブラウザが設定した有効期限を尊重しているとは限らない
手元の確認だけでは分からないこと
ITPの対策をしたら、当然「効いているか」を確かめたくなります。ですが、自分の手元で1回テストするやり方には、ITP特有の死角が2つあります。
- 自分の環境は、本番のSafariユーザーと同じではない。 開発用のブラウザは拡張機能やキャッシュ、ログイン状態などが本番の一般ユーザーと異なります。とくにITPは「クロスサイト遷移を経たか」「過去にそのドメインと接触したか」で挙動が変わるため、開発者のクリーンでない環境では、本番ユーザーに起きている7日失効や24時間短縮が再現されないことがあります。「自分のSafariでは紐づいた」が、初回訪問の一般ユーザーでは切れている、というズレが起きます。
- 広告クリックがからむと再現が難しい。 「広告をクリックして
gclidが付いた状態で来て、数日後にコンバージョンした人が、Safariでどう扱われるか」を正しく見ようとすると、本来はライブ広告をクリックして経路と時間経過を再現する必要があり、これは自己クリックとして広告ポリシー違反のリスクを伴います。
ITPの問題は、「対策済みの自分の環境」ではなく「初回訪問の本番Safariユーザー」の経路で起きます。手元で紐づいて見えることが、かえって油断を生むのです。
本番で「いまCookieがどう扱われているか」を確認する手順
手順1：開発者ツールでCookieの発行方式と有効期限を見る
最も基本的な確認です。SafariでもChromeでも、開発者ツールの「Application（またはストレージ）」→「Cookies」で、各Cookieの**有効期限（Expires / Max-Age）**を確認できます。
- 計測用のCookie（
_gaなど）の有効期限が、7日以内に切り詰められていないか - そのCookieがJavaScript発行か、サーバー発行（HttpOnly）か
分かること： いま本番で、識別子のCookieがITPの短命化を受けているか、そしてサーバー発行に置き換えられているか。
手順2：レスポンスヘッダーで Set-Cookie を確認する
Networkタブでページのレスポンスヘッダーを開き、Set-Cookie ヘッダーでCookieが発行されているかを見ます。ここに識別子のCookieが出ていれば、サーバー側での発行（HTTP Cookie）ができている証拠です。JavaScriptだけで発行している場合、ここには現れません。
分かること： ITP緩和策（サーバーサイド発行）が、口先だけでなく実際に効いているか。
手順3：Safariで「時間経過」を含めて確認する
ITPの本質は「時間が経つとCookieが消える」ことです。だからこそ、発行直後だけでなく、数日後に同じユーザー識別が保たれているかまで見る必要があります。とくにSafariで、リンク装飾（クエリ付き）を経たクロスサイト遷移の後に、Cookieの有効期限が24時間に縮んでいないかを確認します。
分かること： 初回訪問・クロスサイト遷移という本番に近い条件で、識別子が7日・24時間の壁に当たっていないか。
確実に確認するためのチェックリスト
- 計測用Cookie（
_gaなど）の有効期限を、Safari本番で確認したか - そのCookieは**サーバー発行（
Set-Cookie）**か、JavaScript発行か - クロスサイト遷移（リンク装飾）を経た後、有効期限が24時間に縮んでいないか
-
gclid・fbclidの保存が、数日後にも失効していないか - Safari経由の新規率が不自然に高くなっていないか（リピーターの新規化を疑う）
- サーバーサイドタグ／CAPIを「入れたつもり」でなく、実際に発行・送信されているか
- Chromeだけでなく、Safariの実条件で確認したか（自分のクリーンでない環境で判断しない）
よくある質問（FAQ）
Q. SafariのITPで、コンバージョンはどのくらい減りますか？ A. 一概には言えません。減り方は、Safariユーザーの比率、アトリビューション期間の長さ、リピート購入が多いビジネスかどうかで大きく変わります。共通して言えるのは、「7日を超えて再訪・再コンバージョンする経路」ほど影響が大きいということです。
Q. これはSafariの不具合ですか？直せますか？ A. 不具合ではなく、Safari（WebKit）のプライバシー保護機能（ITP）による仕様です。「直す」対象ではなく、サーバーサイドでのCookie発行やCAPIなどで影響を緩和するのが現実的な対応です。
Q. Chromeなら問題ないのですか？ A. Chromeは長らくサードパーティCookieを許容してきましたが、プライバシー強化の流れは全ブラウザ共通です。ITPはSafari固有の名称ですが、「一次Cookieの短命化」「サードパーティCookieの制限」への備えは、Safari以外でも将来にわたって有効です。
Q. gclid を保存しているのに、成果が紐づきません。なぜ？
A. gclid をJavaScriptで一次Cookieに保存している場合、ITPで最大7日（クロスサイト遷移後は24時間）で消えることがあります。コンバージョンがその窓を過ぎると紐づけられません。サーバー側での保存に切り替えるのが対策です。ブラウザ管理の識別子への依存を減らす包括的な戦略については、ファーストパーティデータによるコンバージョン計測も参考にしてください。
Q. サーバーサイドタグを入れれば完全に解決しますか？ A. 取りこぼしは大きく減りますが、「完全」ではありません。実装ミスでCookieがまだJavaScript発行のままだったり、クロスドメインの配線が抜けていたりすると効果は限定的です。入れた後に、本番で実際にHTTP Cookieが発行されているかを確認することが欠かせません。
Q. GA4と広告で、ITPの影響は同じですか？ A. 根っこは同じ（Cookieの短命化・ブロック）ですが、現れ方が違います。GA4では新規率の水増しやセッション分断として、広告ではクリックIDの失効やアトリビューションの取りこぼしとして現れます。両方を分けて確認するのが安全です。
まとめ：「クリーンな自分の環境」ではなく「初回訪問の本番Safariユーザー」で確かめる
SafariのITPでコンバージョンが減る問題は、タグの発火を見るだけでは見抜けません。大事なのは、Cookieが実際にどの方式で発行され、どれだけの寿命を持ち、時間が経っても識別が保たれるかを、本番のSafari条件で確認することです。これは故障ではなくプライバシー仕様なので、前提として織り込み、サーバーサイド発行などで緩和したうえで、「本当に効いているか」を実測する必要があります。
ConversionOKは、外部の独立した実ブラウザであなたの本番ページにアクセスし、実際に送信されるリクエストと発行されるCookie（発行方式・有効期限）を傍受して検証します。自分の広告をクリックする必要も、社内環境の影響を受けることもありません。まずは無料の静的チェックで、計測の入口が本番のブラウザ条件でどう扱われているかを確認してみてください。