CAPIと拡張コンバージョンはcookie非依存？誤解を解く3点【図解】

「CAPIを入れれば、cookie制限の影響を受けなくなります」。代理店やツールの説明でこう聞いて、そのまま社内に共有した方は多いと思います。実装の見積もりまで進んでから、この一文が少しずつずれていることに気づく、という順番になりがちです。

ずれているのは結論ではなく、言葉の粒度です。CAPIは、たしかにブラウザ側のcookieブロックの影響を受けにくい仕組みです。ただし「受けにくい」と「使っていない」はまったく違います。この2つを取り違えたまま設計すると、ブラウザによって数字が合わない理由を、後から説明できなくなります。

この記事では、CAPIと拡張コンバージョンが実際に何を送っているのかをいったん分解し、そのうえでcookieの制限がどこに効くのかを、ブラウザごとに整理します。新しい打ち手を増やす記事ではなく、いま入れようとしているものの正体を言い当てるための記事です。

本記事の内容は2026-08-07に各社の公式ドキュメント本文で確認したものです（Privacy Sandbox技術の廃止発表ページのみ2026-08-09に確認）。

01CAPIと拡張コンバージョンは、cookieが使えなくてもWeb広告の成果を測れるんですか？

若葉さん

若葉さんの発言

cookieが使えなくなるから、その代わりにCAPIや拡張コンバージョンを入れる、という理解でいいんでしょうか。

鈴木さん

鈴木さんの発言

そこが最初の分かれ道です。どちらも「cookieの代わり」ではありません。cookie以外の一次情報を、測定に足す仕組みだと考えてください。

結論から言うと、CAPIと拡張コンバージョンは、どちらも「cookieが使えなくなったときの代替」ではありません。共通しているのは、cookie以外の一次情報を測定に加えるという点です。CAPIはサーバー側のイベントデータ、拡張コンバージョンはハッシュ化した顧客データが、その一次情報にあたります。

そして、この2つは並べて比べるものでもありません。CAPIはMeta広告向け、拡張コンバージョンはGoogle広告向けで、対象プラットフォームがそもそも違うからです。「どちらが優れているか」という問いは、実務ではほとんど意味を持ちません。

優先順位の目安は、次の3点に整理できます。

• Meta広告を運用しているなら、Pixelの欠測を補うCAPIを実装する
• Google広告を運用しているなら、実装工数が比較的少ない拡張コンバージョンから着手する
• どちらも「cookie非依存」ではないため、Safari・Firefoxのcookie制限を前提にした計測設計を別途用意する

02CAPIとは何ですか？Web広告の計測でcookieとどう関わるんですか？

MetaのConversions API（CAPI）は、広告主のサーバーからMetaへイベントデータを直接送信する仕組みです（出典: Meta for Developers公式）。ブラウザに置いたMeta Pixelが、ネットワーク接続の問題やページ読み込みエラーで取りこぼしたイベントを、サーバー側から送り直して補完する、という位置づけになります。

ここで広がっているのが「CAPIはcookieに依存しない」という説明です。Meta公式のベストプラクティスによれば、fbp・fbcという2つのパラメータは、訪問者のブラウザに設定されるcookie値です（出典: Meta for Developers公式）。これはMeta社のファーストパーティcookieソリューションに関連する値と説明されています。CAPIのイベント送信でも、この一次cookie値を任意パラメータとして使うことがあります。

つまりCAPIは、cookieを使わない仕組みではありません。正確には、サーバー側で送信するため、ブラウザ側のcookieブロックの影響を受けにくい、という相対的な仕組みです。「cookieに依存しない」と言い切るのは根拠が足りません。

03fbpとfbcというcookieは、広告運用の現場で何をしているんですか？

fbp・fbcは、Meta Pixelがサイト上で自動生成し、ファーストパーティcookieとして保存する値です（出典: Meta for Developers公式）。広告主自身のドメインに置かれる、いわば自社の手元にある手がかりだと考えると分かりやすくなります。

実際の送信イメージは次のとおりです（パラメータ名は公式ドキュメントの記載に基づく簡略化した例で、実際のハッシュ値・cookie値ではありません）。

{
  "event_name": "Purchase",
  "action_source": "website",
  "user_data": {
    "em": ["<SHA256でハッシュ化したメールアドレス>"],
    "fbp": "fb.1.1735689600000.123456789",
    "fbc": "fb.1.1735689600000.AbCdEfGhIj"
  }
}

Meta PixelとCAPIで同じイベントを送るとき、問題になるのが二重計上です。重複排除には、同一のevent_nameに加え、event_id、またはexternal_idとfbpの組み合わせが必要になります。ここでもfbpという一次cookie値が使われている点に注目してください。

CAPIの照合精度は、Event Match Quality（EMQ）という指標で示され、0から10のスコアで表現されます（出典: 前掲のMeta for Developers公式）。このスコアが下がったときに、まずどこを見るかを決めておくと、原因の切り分けが速くなります。

04拡張コンバージョンはCAPIと何が違うんですか？Web広告の計測での立ち位置は？

Google広告の拡張コンバージョンは、コンバージョン時に取得したファーストパーティの顧客データを、SHA256でハッシュ化する仕組みです。ハッシュ化したデータをGoogleへ送信します（出典: Google広告ヘルプ）。対象データはメールアドレス・氏名・電話番号・住所などです。送信したハッシュ値を、広告操作時にログインしていたGoogleアカウントと照合し、コンバージョンを補完します。

拡張コンバージョンには2種類あります。ウェブサイト上のコンバージョンを対象にした「ウェブ向け」と、フォーム経由の見込み客のその後の商談・購入を対象にした「リード向け」です（出典: 前掲のGoogle広告ヘルプ）。

高梨課長

高梨課長の発言

実装はどれくらいの手間になりますか。うちはタグまわりを触れる人が限られていて。

鈴木さん

鈴木さんの発言

方法は選べます。Googleタグを直接編集する、Googleタグマネージャーを使う、Google Ads APIを使う、の3通りが案内されています。

高梨課長

高梨課長の発言

入れたら、すぐに数字で分かるものですか。

鈴木さん

鈴木さんの発言

そこは待ちが入ります。効果が指標に反映されるまで最長1か月程度（30日）かかるとされています。設定した週に判断しないでください。

実装方法は、Googleタグを直接編集する方法・Googleタグマネージャーを使う方法・Google Ads APIを使う方法の3通りがあります（出典: Google広告ヘルプ）。設定手順は共通して、拡張コンバージョンの有効化、ユーザー提供データの収集方法の選択、実装の検証、効果測定という4段階です（出典: 前掲のGoogle広告ヘルプ）。

05CAPIと拡張コンバージョンは、cookieとの関係でWeb広告上どう違うんですか？

両者の違いを一覧にすると、次のようになります。

06cookie制限下の広告運用では、CAPIと拡張コンバージョンをどう使い分けますか？

決定的な違いは、送るデータの性質です。CAPIは購入・登録といったイベントそのものをサーバー間で送ります。拡張コンバージョンはハッシュ化した顧客データを送り、Google側のログイン情報と照合させます。拡張コンバージョンの公式ヘルプページにcookieに関する記述はなく、cookie値そのものを送信パラメータに含める設計ではありません。

したがって、cookie制限の影響を強く受けやすいのはCAPI側のfbp・fbcパラメータです。拡張コンバージョンはハッシュ化データでの照合が前提のため、cookie制限そのものからは距離があります。ただしどちらも、Pixelタグ・コンバージョンタグ自体が正しく発火することが大前提です。ここが崩れていると、上に何を積んでも数字は戻りません。

07Chromeのcookieはどうなったんですか？Web広告の前提は変わりましたか？

「cookie制限下」とひとくくりにする前に、ブラウザごとの違いを正確に把握する必要があります。Chromeは2026年8月時点で、サードパーティcookieを既定ではブロックしていません。ここに至るまでに3回の方針転換があり、さらに代替候補だった技術群の廃止も発表されています。

2024年4月23日、Googleはサードパーティcookie廃止の完了時期を延期すると発表しました（出典: Privacy Sandbox公式・2024-04-23公開）。この時点は撤回ではなく延期です。2024年7月22日には、廃止そのものをやめて、ユーザー選択式のプロンプト方式へ転換すると発表しました（出典: Privacy Sandbox公式・2024-07-22公開）。

2025年4月22日、そのプロンプト方式の導入自体も断念しました。既存のChromeプライバシー設定での運用維持を発表しています（出典: Privacy Sandbox公式・2025-04-22公開）。これによりサードパーティcookieを廃止しない方針が確定しています。

08SafariのITPはcookieをどう扱うんですか？広告運用への影響はどこですか？

一方でSafari・Firefoxは、既にサードパーティcookieを既定でブロックしています。SafariのITP（Intelligent Tracking Prevention）は、サードパーティcookieを例外なくブロックします（出典: WebKit公式）。

ここで見落とされがちな点があります。fbp・fbcはMeta Pixelが広告主自身のドメインに設定するファーストパーティcookieであり、サードパーティcookieのブロック対象そのものではありません。

若葉さん

若葉さんの発言

では、Safariでもfbp・fbcは残るということですか。

鈴木さん

鈴木さんの発言

残る、とは言い切れません。ブロックはされませんが、別の制限がかかります。

若葉さん

若葉さんの発言

つまり、消える理由が「ブロック」ではなく「寿命」だということですね。

SafariのITPは、JavaScriptで書き込まれたcookie（fbp・fbcを含む）に制限を設けています。ユーザーの無操作が7日間続くと削除される仕組みです（出典: 前掲のWebKit公式）。Safariでは、fbp・fbcが「ブロックはされないが、7日間で消える」設計になっている点が、実務上の影響になります。

09Firefoxも含めると、ブラウザ別のcookieの扱いは広告運用でどう整理できますか？

Firefoxも2019年9月3日、既定でサードパーティのトラッキングcookieをブロックすると発表しました（出典: Mozilla公式ブログ・2019-09-03公開）。

表でまとめると次のとおりです。

拡張コンバージョンはcookie値そのものを使わずハッシュ化データで照合するため、この一覧の「一次cookieの制限」による直接の影響を受けにくい設計です。影響を受けやすいのは、CAPIのfbp・fbcパラメータの側だと整理できます。

10Privacy Sandboxの縮小は、cookieに頼らないWeb広告の計測をどう変えましたか？

動きはここで止まっていません。2025年10月17日、GoogleはPrivacy Sandbox関連の技術10件を廃止すると発表しました（出典: Privacy Sandbox公式・2025-10-17公開）。この中には、cookieに依存しない計測手段として案内されていたAttribution Reporting APIが含まれます（出典: 同上）。これに対しCHIPS・FedCM・プライベートステートトークンは、引き続きサポートすると明記されています（出典: 同上）。

CAPIと拡張コンバージョンはPrivacy Sandboxの技術ではないため、この廃止の対象には含まれません。ここは安心してよい部分です。

高梨課長

高梨課長の発言

受け皿として案内されていたものが、なくなることもあるんですね。

鈴木さん

鈴木さんの発言

はい。だから「これを入れれば終わり」という設計にしないほうが安全です。cookie制限への備えとしてAttribution Reporting APIへの移行を進めていた場合は、移行先そのものが縮小したことになります。

言い換えると、計測の設計で持っておきたいのは特定の技術への忠誠ではなく、前提が変わったときに気づける仕組みです。参照している公式ドキュメントの更新を追う担当を決めておくだけでも、気づく速さが変わります。

11CAPIと拡張コンバージョンの導入は、広告運用のどの順番で進めますか？

実装は次の順で進めます。

1. 対応プラットフォームを確認する（Meta広告を運用していればCAPI、Google広告を運用していれば拡張コンバージョンが対象）
2. 実装方法を選ぶ（CAPIは統合方法が複数あり工数は方式により異なる、拡張コンバージョンはGoogleタグ・タグマネージャー・APIの3通り）
3. 重複排除・照合の条件を確認する（CAPIはevent_id等、拡張コンバージョンはハッシュ化データとアカウントの照合）
4. 実装を検証し、効果測定に進む（拡張コンバージョンは最長30日程度で指標に反映される）

順番を守る理由は単純です。土台が抜けたまま上を足しても、数字は戻らないからです。タグ自体が発火していない状態でCAPIを足しても、補完される元のイベントがありません。手がかりの値が短命化している状態で照合精度だけを追いかけても、原因にたどり着けません。

12AI活用で広告運用が自動化されても、CAPIとcookieの設計はなぜ人に残るんですか？

計測タグの実装そのものは、一度きりの設定作業になりやすい仕事です。だからこそ、どの工程を人が担い、どの工程をAIに任せるかの切り分けが必要になります。

切り分けの手がかりは、この記事でここまで見てきた内容の中にあります。ブラウザ側の仕様は、外の都合で変わります。Chromeの方針は動いてきましたし、Privacy Sandboxの技術も整理されました。変わるものを読み続ける仕事は、設定作業とは性質が違います。

もうひとつは、何を送るかの決定です。拡張コンバージョンで扱うのはメールアドレス・氏名・電話番号・住所といった顧客データで、ハッシュ化するとはいえ、送ることそのものは自社の意思決定です。ここは自動化の対象ではありません。

13CAPIと拡張コンバージョンでつまずくのは、cookieと広告運用の理解のどこですか？

つまずきは、どれも言葉の粒度から生まれます。よくある誤解と、正しい理解を並べます。

いちばん実害が大きいのは、最後の行です。CAPIはPixelの取りこぼしを補うために存在します。Pixelを外してしまうと、補完すべき元のイベントが減り、狙いと逆の結果になりかねません。

14広告運用の現場で、CAPIと拡張コンバージョンのcookie対応をどう点検しますか？

ここまでの内容を、点検できる形に落とします。自社の状況に当てはめて、順に確認してください。

• Meta広告を運用しているか確認し、CAPIの実装要否を判断した
• Google広告を運用しているか確認し、拡張コンバージョンの実装要否を判断した
• CAPIを「cookie非依存」ではなく「cookieブロックの影響を受けにくい」と正確に説明できる
• fbp・fbcがSafariのITPで無操作7日後に削除される可能性を理解している
• CAPIの重複排除条件（event_id、またはexternal_id・fbpの組み合わせ）を確認した
• 拡張コンバージョンの実装方法（Googleタグ・タグマネージャー・API）のうち自社に合う方法を選んだ
• 拡張コンバージョンの効果反映まで最長30日程度かかることを踏まえてスケジュールを組んだ
• Safari・Firefox向けの計測手段を用意した
• PixelとCAPIを併用し、片方だけに依存していないか確認した

この点検表は、一度通したら終わりというものではありません。ブラウザ側の仕様も、媒体側のドキュメントも更新されます。見直す間隔を先に決めておくほうが、思い出したときに見るより確実です。

15よくある質問

16まとめ｜今日やる3つのこと