CAPIと拡張コンバージョン、cookie制限下の計測代替を整理

「CAPIを入れれば、cookie制限の影響を受けなくなる」——この理解のまま実装を進めていませんか。MetaのConversions API（CAPI）は、実際にはfbp・fbcという一次cookieの値を送信に使う設計です。cookieに依存しない仕組みではなく、サーバー側送信のためブラウザのcookieブロックの影響を受けにくい、というのが正確な理解です。

この記事で分かること

• CAPIが「cookie非依存」ではなく「cookieブロックの影響を受けにくい」仕組みである正確な理由
• CAPIと拡張コンバージョンの仕組み・実装方法・cookieとの関係の違い
• Chrome・Safari・Firefoxでcookieの扱いがどう異なり、CAPI・拡張コンバージョンにどう影響するか

検証環境：Meta for Developers公式ドキュメント・Google広告ヘルプ・WebKit公式ブログの本文直接確認／2026-08-07確認。

01結論：CAPIと拡張コンバージョン、cookie制限下でどう使い分けるか

CAPIと拡張コンバージョンは、どちらも「cookieが使えなくなったときの代替」ではありません。cookie以外の一次情報（サーバー側のイベントデータ、ハッシュ化した顧客データ）を測定に加える仕組みという点が共通します。CAPIはMeta広告向け、拡張コンバージョンはGoogle広告向けで、対象プラットフォームが異なります。

優先順位の目安は次の3点です。

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

02CAPIとは何か｜「cookie非依存」ではなく「影響を受けにくい」が正確

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

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

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

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

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

fbp・fbcはMeta Pixelがサイト上で自動生成し、ファーストパーティcookieとして保存する値です（出典: Meta for Developers公式）。Meta PixelとCAPIで同じイベントを送るとき、重複排除には同一のevent_nameに加え、event_id、またはexternal_idとfbpの組み合わせが必要です。CAPIの照合精度はEvent Match Quality（EMQ）という指標で示され、0から10のスコアで表現されます（出典: 前掲のMeta for Developers公式）。

03拡張コンバージョンとは何か｜CAPIとの仕組みの違い

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

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

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

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

04CAPIと拡張コンバージョンを比較する｜データソース・実装方法・cookieとの関係

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

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

05cookieの制限はブラウザで違う｜CAPI・拡張コンバージョンへの影響

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

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を廃止しない方針が確定しています。

動きはここで止まっていません。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への移行を進めていた場合は、移行先そのものが縮小したことになります。4段階に及ぶ詳しい経緯は『Chromeのサードパーティcookieは廃止されなかった経緯を整理』で解説しています。

一方でSafari・Firefoxは、既にサードパーティcookieを既定でブロックしています。SafariのITP（Intelligent Tracking Prevention）は、サードパーティcookieを例外なくブロックします（出典: WebKit公式）。Firefoxも2019年9月3日、既定でサードパーティのトラッキングcookieをブロックすると発表しました（出典: Mozilla公式ブログ・2019-09-03公開）。

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

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

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

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

06CAPI・拡張コンバージョンの導入手順｜最初の一歩

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

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

計測タグの実装自体は一度きりの設定作業になりやすく、どの工程を人が担い、どの工程をAIに任せるかの切り分けが必要です。実務全体の任せ方は『AI時代の広告運用、任せる工程と人が持つ工程の地図』が参考になります。

07CAPIと拡張コンバージョンでつまずきやすい点

08CAPI・拡張コンバージョン導入チェックリスト

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

09FAQ