【2026年】コンバージョンAPIとは？Cookie規制後の計測精度を高める導入方法

広告管理画面に表示されているコンバージョン数は、実際の成果を正確に反映しているとは限りません。サードパーティCookieの規制強化とブラウザ側のトラッキング制限により、2026年現在、ピクセル計測だけでは全コンバージョンの30〜50%が計測できていないと推計されています。

この計測の空白を埋める技術が、サーバーサイドからデータを直接送信する「コンバージョンAPI（CAPI）」です。本記事では、コンバージョンAPIの仕組みから、Meta・Google・Yahoo!それぞれの対応状況と導入手順、複数媒体への一括連携による運用効率化まで、実務に直結する形で解説します。

コンバージョンAPIとは何か

コンバージョンAPI（Conversions API、通称CAPI）は、広告主が管理するサーバーから広告媒体のサーバーへ直接コンバージョンデータを送信する技術です。従来のブラウザ上のJavaScript（ピクセル）に依存しないため、ブラウザの制限やアドブロッカーの影響を受けにくいという特徴があります。

ブラウザ計測（ピクセル）との根本的な違い

従来のピクセル計測は、ユーザーのブラウザ上でJavaScriptを実行し、広告媒体へCookieを送信する仕組みです。この方式は、ブラウザのセキュリティ設定やアドブロッカーによって遮断されるリスクが常に伴います。

コンバージョンAPIはこの送信経路をサーバー間（Server-to-Server）の通信に置き換えます。広告主のバックエンドサーバーから媒体のAPIエンドポイントへ直接データを送るため、ブラウザの介在が最小化され、計測の安定性が大幅に向上します。

サーバーサイドでイベントを送信する仕組み

CAPIのデータフローは、大きく5つのステップで構成されます。まずユーザーがウェブサイト上でアクション（フォーム送信や購入など）を実行すると、ブラウザ上にファーストパーティCookie（_fbcや_gcl_auなど）が生成されます。

次に、このイベントデータと個人情報が広告主のサーバーへ送信され、サーバー側でSHA-256によるハッシュ化が行われます。ハッシュ化されたデータはHTTP POSTリクエストとして媒体のAPIエンドポイントへ送信され、媒体側でユーザーの広告クリックと紐付けられてアトリビューションが成立します。

個人情報（メールアドレスや電話番号）は不可逆なハッシュ値に変換されてから送信されるため、プライバシー保護と計測精度の両立が可能です。

ピクセルとコンバージョンAPIの比較

ピクセル計測とコンバージョンAPIの主な違い

比較項目	ピクセル計測	コンバージョンAPI
送信経路	ブラウザ → 媒体サーバー	広告主サーバー → 媒体サーバー
Cookie依存度	高い（ブラウザ制限に直撃）	低い（ファーストパーティデータを活用）
アドブロッカーの影響	通信がブロックされる可能性が高い	サーバー間通信のため影響を受けない
送信できるイベント	ページ閲覧・クリック等のブラウザ内行動	来店・成約等のオフラインイベントも送信可能
プライバシー保護	サードパーティCookieに依存	ハッシュ化済みデータのみ送信

Cookie規制が広告計測精度に与える影響

計測環境の悪化は段階的に進んできました。SafariやFirefoxが2020年以前にサードパーティCookieのデフォルトブロックを完了し、2025年にはGoogleもChromeでユーザーの選択プロンプトを導入しました。

その結果、現在のサードパーティCookie取得環境は、広告主にとって実用性が大きく低下しています。

サードパーティCookieの段階的な取得率低下

ODB概要資料に記載されているデータによれば、サードパーティCookieが取得できるブラウザの割合は2020年以降の約2年間で約20%減少し、2022年時点で40%程度まで落ち込みました。

その後も規制強化は続いており、2026年現在では取得可能なユーザーは10〜30%程度にとどまると推計されています。Chromeの選択プロンプト導入以降、多くのユーザーが追跡を拒否する傾向があるためです。

ITPによるファーストパーティCookieの有効期限短縮

SafariのITP（Intelligent Tracking Prevention）は、サードパーティCookieの遮断にとどまりません。JavaScriptで生成したファーストパーティCookieに対しても、最終訪問から7日間という有効期限を設けています。

さらに、GCLIDやFBCLIDなどの広告クリックIDがURLに含まれる場合、参照元が追跡ドメインと判定されると有効期限は24時間まで短縮されます。

日本市場では特にこの影響が深刻です。iPhoneのブラウザシェアが60%を超えるとされるなか、検討期間が1週間を超える商材（不動産・保険・BtoB商材など）では、コンバージョンが「直接流入」として誤認される可能性が極めて高くなります。

計測データ減少が広告最適化に与える具体的な影響

計測漏れは、レポートの精度問題にとどまりません。広告媒体の自動入札（スマート入札）は、機械学習のために正確なコンバージョンデータを必要とします。

不完全なデータを教師データとして与え続けると、入札アルゴリズムの最適化精度が下がり、最終的なCPAの悪化につながります。

• アドブロッカーの影響：国内利用率は約18%とされており、これらのユーザーのピクセル計測は100%遮断される
• Cookie規制による全体欠損率：30〜50%のコンバージョンが計測できていないと推計
• CAPIによる回復率：導入により欠損データの約20〜30%が回復可能という実測値がある
• 同意バナーによる損失：Cookie同意バナーでの拒否率は約40%というデータもあり、欠損をさらに拡大させている

主要媒体のコンバージョンAPI対応状況

Meta・Google・Yahoo!の主要3媒体は、それぞれ独自の仕様でCAPIを提供しています。媒体ごとに必要なパラメータや導入前提が異なるため、複数媒体を運用している場合は全体像を把握した上で実装を進めることが重要です。

Meta広告のコンバージョンAPI

MetaはCAPIの普及に最も積極的に取り組んでいる媒体です。2025年にはオフラインコンバージョンAPIを統合し、単一のエンドポイントで全てのイベント種別を処理する仕様に統一されました。

購入（Purchase）、リード取得（Lead）、カート追加（AddToCart）、予約（Schedule）など、標準イベント名に従ってデータを送信します。

送信に必要な必須パラメータはevent_name（イベント種別）、event_time（発生時刻のUNIXタイムスタンプ）、action_source（「website」や「physical_store」等の発生元）、そしてハッシュ化された個人情報を含むuser_dataオブジェクトです。

MetaはピクセルとCAPIを同時運用し、event_idによる重複排除を行う構成を公式に推奨しています。この構成によりEvent Match Quality（EMQ）スコアが向上し、Advantage+等の配信最適化の学習効率が高まります。

Google広告の拡張コンバージョン

Googleの「拡張コンバージョン（Enhanced Conversions）」は、フォーム送信時などに取得したメールアドレス等のファーストパーティデータをハッシュ化してGoogleへ送信し、広告クリックと照合する技術です。

ウェブでのリード獲得後にCRM上で成約したオフライン成果を送信する「リード向け拡張コンバージョン」は、GCLIDをキーとして過去のクリックと紐付けるという点で、実質的なサーバーサイドAPI連携です。

2025年10月には「Data Manager API」が一般公開され、CRMやバックエンドサーバーからGoogle広告へ直接コンバージョンデータを送信するための新しい統合プラットフォームとして機能しています。GoogleスプレッドシートやBigQueryをデータソースとして接続し、自動的にデータを同期できます。

Yahoo!広告のコンバージョンAPI

LINEヤフーも2025年にCAPIの提供を本格化させました。検索広告（YSS）向けCAPIは2025年9月10日より提供開始、ディスプレイ広告（YDA）向けの新しいコンバージョンAPIは2025年6月30日より提供を開始しています。

主要3媒体のコンバージョンAPI対応状況（2026年時点）

媒体	提供名称	主な照合キー	提供開始時期
Meta（Facebook/Instagram）	コンバージョンAPI（CAPI）	FBCLID、ハッシュ化メール・電話番号	2020年〜（継続強化）
Google広告	拡張コンバージョン / Data Manager API	GCLID、ハッシュ化メール	2021年〜（2025年10月にData Manager API一般公開）
Yahoo!広告（検索）	コンバージョンAPI（YSS）	YCLID、ハッシュ化メール・電話番号	2025年9月
Yahoo!広告（ディスプレイ）	コンバージョンAPI（YDA）	YCLID、LINE UID	2025年6月

コンバージョンAPIの導入手順

各媒体のCAPI導入は、現在はサーバーサイドGoogleタグマネージャー（sGTM）をハブとして使う方法が最も汎用的です。sGTMを介することで複数媒体への送信を一元管理でき、個別のサーバー実装を媒体ごとに構築する手間を省けます。

Meta CAPI導入の基本ステップ

1. Meta イベントマネージャーでピクセルの設定を開き、コンバージョンAPIセクションからアクセストークンを生成・保存する
2. GCP等でsGTMサーバーコンテナをセットアップし、独自サブドメインを割り当てる
3. ウェブ側GTMコンテナでGA4イベントタグをsGTMサーバーへ送信する設定に変更する
4. sGTM内に「Meta Conversions API」タグを設置し、アクセストークンとピクセルIDを入力してGA4イベントをMeta形式にマッピングする
5. ウェブ側ピクセルとCAPIタグの両方に共通のevent_id変数を設定し、重複排除を有効化する

Google 拡張コンバージョン導入の基本ステップ

1. Google広告管理画面の「コンバージョン」設定から拡張コンバージョンをオンにし、利用規約に同意する
2. GTMウェブコンテナで「ユーザー提供データ」変数を作成し、フォーム送信時のメールアドレス等を取得するフィールドを設定する
3. Google広告コンバージョンタグの設定で「拡張コンバージョン」にチェックを入れ、手順2の変数を紐付ける
4. オフライン成果（リード向け）の場合はData Managerを通じてCRMデータソースを接続し、GCLIDと成約データを定期的に同期する

Yahoo! CAPI導入の基本ステップ

1. Yahoo!デベロッパーネットワークでアプリケーションを登録しClient IDを取得する
2. Yahoo!広告管理ツールの「ツール」から「コンバージョン測定」の新規設定を作成し、yahoo_conversion_idをコピーする
3. sGTMのCommunity Template GalleryからLINEヤフー公式のsGTMテンプレートを追加する
4. sGTMタグ内でClient ID・アクセストークン・YCLIDのマッピングを設定し、管理ツールのイベント受信履歴で動作を確認する

ピクセルとコンバージョンAPIの併用時の重複計測対策

MetaをはじめとするCAPIを推奨する媒体の多くは、ピクセルとCAPIを同時に稼働させる「冗長化」構成を推奨しています。これは、どちらか一方が何らかの理由で計測に失敗した場合のバックアップとして機能させるためです。

ただし、単純に両方を動かすと同一のコンバージョンが二重計上されてしまいます。

重複計測が発生する仕組みとevent_idの役割

重複が発生するのは、同一ユーザーのアクションに対してブラウザ側のピクセルとサーバー側のCAPIが、それぞれ独立したシグナルを媒体へ送信するためです。媒体サーバーには同じコンバージョンの情報が2つ届くことになります。

これを解決するのが「event_id」を使った重複排除（Deduplication）の仕組みです。同一のアクションから発生するピクセルとCAPIの両シグナルに、共通のevent_idを付与します。

媒体サーバーは一定時間内（通常48時間）に受信したevent_nameとevent_idが両方一致するシグナルを「同一アクション」として集約し、1件のコンバージョンとしてカウントします。

媒体別の重複排除設定

媒体別の重複排除キーと実装のポイント

媒体	重複排除のキー	実装上の注意点
Meta	event_id	ブラウザ側fbq(‘track’, …, {}, {eventID: ‘ID’})とCAPIペイロードのevent_idを文字列として完全一致させる。大文字小文字のずれで重複排除が無効になる
Google	transaction_id	gtagイベント内のtransaction_idをユニークな注文IDとして設定し、タグとAPI送信の両方で同じ値を使用する
Yahoo!	コンバージョンID等	sGTMテンプレートを使用する場合、重複排除の設定が組み込まれているかを確認するか、トリガー管理でタグの重複発火を制御する

特にMetaの場合、event_idはサーバー側で生成してクライアント側へ受け渡す手法が最も確実です。フロントエンドとバックエンドで独立してIDを生成すると値が一致しないリスクがあります。

オフラインイベントデータのコンバージョンAPI送信

CAPIはブラウザ上のアクションだけでなく、店舗での来店や対面での商談成約といったオフラインの成果もAPIで送信できます。なお、電話コンバージョンの計測は別の専用ツールが担う領域であるため、本記事では来店・商談・予約に絞って解説します。

オフラインイベントをCAPIで送信できるケース

• 来店・店舗での購入（Store Visit / In-store Purchase）：POSシステムに記録されたメールアドレスをキーとして広告との寄与を特定する
• 対面商談・成約（Qualified Lead / Sale）：CRM上で「商談成立」にステータスが変更された時点でAPIへ送信し、ウェブでの最初のリード獲得情報と紐付ける
• 予約確定（Booked Appointment）：ウェブでの予約リクエストを受け付けた後、管理者が承認して確定した段階でイベントを送信する
• 継続課金・返品（Subscription Renewal / Refund）：ブラウザ外で自動発生するサブスクリプション更新や返品処理もAPI経由で送信できる

来店・対面商談データの送信フロー

オフラインデータの送信はリアルタイムではなく、バッチ処理（定期的な一括送信）で行われるのが一般的です。ウェブでリードが発生した時点で、ブラウザ上の広告識別子（fbclid・gclid・yclidなど）とメールアドレスをフォームの隠しフィールド等で取得し、CRMへ保存します。

その後、CRM上で「成約」などのオフライン成果が記録された際に、そのレコードに紐付けられた広告識別子と個人情報をハッシュ化して媒体のAPIへ送信します。

照合キーとデータ正規化の仕様

照合キーの精度がアトリビューションの成功率を左右します。主なキーとその正規化ルールは以下の通りです。

• メールアドレス（em）：小文字化・前後のスペース削除後にSHA-256でハッシュ化する。最もマッチ率が高いキー
• 電話番号（ph）：国番号を含むE.164形式（+8190XXXXXXXX）に整形し、ハイフンや括弧を除去した上でSHA-256でハッシュ化する
• 広告クリックID：Meta＝fbc/fbp、Google＝gclid、Yahoo!＝yclidをそれぞれ取得してCRMに保存しておく
• 外部ID（external_id）：CRM上の顧客IDなど広告主独自のユニークIDを補助キーとして活用できる

正規化を怠るとハッシュ値が一致せずマッチングに失敗します。特に電話番号の国番号有無やメールアドレスの大文字混在は見落としやすいため、送信前の正規化処理をサーバー側で自動化することが重要です。

複数媒体のコンバージョンAPI連携を効率化する方法

Meta・Google・Yahoo!それぞれに独立したCAPI実装を構築する場合、媒体の数だけ設定・保守コストが発生します。広告予算の分散が進むほど、この個別実装の負担は比例して増加します。

媒体ごとに個別実装する場合の課題

各媒体のAPI仕様は独立しており、パラメータ名・認証方式・イベント名のマッピングルールがそれぞれ異なります。媒体が追加された際や仕様変更があった際には、その都度対応が必要です。

また、各媒体のAPIが正常に稼働しているかを個別にモニタリングする体制も求められます。

ODBによる複数媒体CAPI一括連携の仕組み

Omni Data Bank（ODB）は、オンライン・オフラインの顧客データを統合し、複数の広告媒体へのデータ連携を一元管理するマーケティング特化型データクリーンルームです。GCLIDやYCLID、FBCLID、MSCLKIDといった各媒体のクリックIDをベースとしたCV反映に対応しており、Google広告・Yahoo!広告・Meta広告・Microsoft Advertisingへの一括連携が可能です。

ODBでは、CRM・基幹システム・ウェブフォームから収集したデータを突合し、広告媒体への送信に必要な形式へ自動的に変換します。媒体ごとに個別のサーバー実装を用意する必要がなく、ODBを単一のデータ送信ハブとして機能させることで実装・運用工数を削減できます。

ファーストパーティデータ活用でCAPI精度を高める方法

CAPIの照合精度を上げるには、メールアドレス・電話番号・広告クリックIDを顧客レコードに紐付けて蓄積するファーストパーティデータ基盤が不可欠です。ODBではウェブ解析データ・フォーム入力情報・CRMの契約データを突合キーによって統合し、照合に必要なデータを一元的に保持する基盤として機能します。

これにより、CAPIで送信するデータの品質が向上し、媒体側の機械学習がより精度の高いインサイトを得られる環境が整います。

個別実装とODB一括連携の比較

比較項目	媒体ごとの個別実装	ODBによる一括連携
対応媒体の追加	媒体ごとに新規実装が必要	ODB管理画面から設定を追加するだけ
データ統合	媒体ごとに独自処理が必要	オンライン・オフラインデータを一元突合
仕様変更への対応	各媒体の変更を個別に追跡して対応	ODB側でのアップデートで自動対応
モニタリング	媒体ごとに個別確認が必要	ODB管理画面で一元確認

コンバージョンAPIに関するよくある質問

Q. コンバージョンAPIとオフラインコンバージョンインポートの違いは何ですか？

A. オフラインコンバージョンインポートは、CSVファイルなどを手動または定期バッチでアップロードする方式です。コンバージョンAPIはAPIエンドポイントへリアルタイムまたは自動で送信する方式であり、タイムラグが少なくデータ連携の自動化が容易です。Googleは現在、手動インポートよりもData Manager APIやリード向け拡張コンバージョンを推奨しています。

Q. CAPI導入にはエンジニアのリソースが必須ですか？

A. sGTMを利用する方法であればエンジニアなしでの実装も可能なケースがありますが、サーバーのセットアップやデータレイヤーの設計には技術的な知識が必要です。ODBのような連携プラットフォームを利用する場合は、複雑なサーバー実装を自前で構築する必要がなく、実装ハードルを大きく下げられます。

Q. Meta・Google・Yahoo!のCAPIはそれぞれ別途実装が必要ですか？

A. 個別実装では媒体ごとに異なる仕様への対応が必要です。sGTMをハブとして使う方法では一定の集約が可能ですが、各媒体のタグ設定は個別に行う必要があります。ODBのようなデータクリーンルームを利用することで、複数媒体への送信を単一の管理基盤から行うことができます。

Q. ピクセルは廃止してCAPIのみにすべきですか？

A. MetaをはじめとするCAPI対応媒体は、ピクセルとCAPIの並行運用（冗長化）を推奨しています。ピクセルはリアルタイムのブラウザ内行動の把握に優れており、CAPIはその計測漏れを補完する役割を担います。event_idによる重複排除を正しく実装した上で、両方を継続して使用することが現時点での最適な構成です。

Q. コンバージョンAPIの送信データに個人情報保護上の注意点はありますか？

A. 送信するメールアドレスや電話番号はSHA-256でハッシュ化されるため、不可逆な文字列として送信されます。ただし、送信データの取り扱いについては各媒体の利用規約および日本の個人情報保護法に準拠した同意取得が必要です。ユーザーからの同意フローを整備した上でデータを収集・利用することが前提となります。

コンバージョンAPIで計測精度を取り戻す

Cookie規制による計測の欠損は、広告レポートの精度問題にとどまらず、自動入札アルゴリズムへの悪影響を通じて広告パフォーマンス全体を引き下げます。ピクセル計測だけに依存した環境では、媒体側の機械学習が不完全なデータを教師データとして使い続けることになり、入札最適化の精度低下とCPAの悪化につながります。

コンバージョンAPIはこの問題に対処するための現時点で最も有効な技術的手段です。単一媒体の導入から始めることもできますが、複数媒体を運用している場合は一括連携の仕組みを整えることで、実装コストと計測精度の両面で大きな差が生まれます。