← 記事一覧へ

ブログ

Meta コンバージョンAPI（CAPI）が正しく動いているか確認する方法

公開 2026-07-09

meta コンバージョンapi 確認capi 設定 確認facebook コンバージョンapi 動作確認meta capi テスト

コンバージョンAPI（CAPI）を入れて「これでiOSや広告ブロッカーの取りこぼしも埋まるはず」と思っている——でも、サーバーから本当にイベントが届いているか、確かめたことはありますか？CAPIは設定したつもりでも、トークンが失効していたり、サーバーが発火していなかったりで、実際には1件もMetaに届いていないことがあります。しかも、ブラウザのピクセルが動いているぶん「全体としては計測できている」ように見えてしまう——これが一番見つけにくいパターンです。

こんな症状に心当たりはありませんか？

  • イベントマネージャで、サーバーイベントが**「受信していない」**まま、または件数が極端に少ない
  • ブラウザのピクセルは出ているのに、サーバー側のイベントがどこにも見当たらない
  • **一致品質（イベントマッチ品質）**が低いと警告されるが、理由が分からない
  • CAPIを入れてから、コンバージョン数が二重に膨らんでいる気がする

この記事では、CAPIがちゃんと動いているか確認する手順、サーバーから送れているのに計測に乗らない理由、そして推測せずに検証しきる考え方を整理します。

確認の前に：CAPIは「ピクセルの代わり」ではなく「補完」

まず前提をそろえましょう。CAPIは、ブラウザのピクセル（fbevents.js が facebook.com/tr に送るもの）を置き換える仕組みではなく、サーバー側からMetaへ直接イベントを送って補完する仕組みです。ITP・広告ブロッカー・iOSのシグナル減少などでブラウザのピクセルが落ちるぶんを、サーバー送信で埋めるのが狙いです。

だからこそ、確認すべきポイントもピクセル単体とは変わってきます。次の3つを分けて考えると診断が一気に楽になります。

レベル 意味 よくある落とし穴
① サーバーが送信 サーバーがMetaのAPIへイベントを送る トークン失効・サーバーが発火していない
② Metaが受信 Metaがサーバーイベントを受理する パラメータ不足・宛先（ピクセルID）違い
③ 照合・重複排除 ブラウザ側と突き合わせ、人物に紐づけ二重を除く event_id 不一致で二重計上、EMQ低下

ポイントは、①送信と③照合は別物だということ。サーバーからリクエストが出ていても、ブラウザ側との重複排除や一致品質の問題で、最適化に使える形になっていないことがあります。多くの確認は①で止まっています。

CAPIとブラウザのピクセルを併用する場合、Metaは同じイベント名と event_id を持つ両者のイベントを重複排除します。event_id が無い・一致しないと、二重計上や欠落の原因になります。詳しくは重複排除（event_id）の確認を参照してください。

手順1：イベントマネージャで「接続方法」を見る

まず、イベントマネージャ → 対象のデータセット（ピクセル）→ 各イベントの詳細で、そのイベントがどこから届いているかを確認します。

  • イベントごとに「サーバー」「ブラウザ」「サーバーとブラウザの両方」といった接続方法が表示される
  • 狙ったイベント（Purchase・Lead 等）にサーバーの表示が付いているか
  • サーバーイベントの受信時刻が最近か（止まっていないか）

分かること： サーバーからイベントが届いている実績があるか（①②に最も近い確認）。 分からないこと： いま設定中のコードが正しく送れているか（次の手順2で見ます）。

つまずきやすい例： 「CAPIを設定した＝動いている」と思い込むこと。設定画面を保存しただけで、サーバー側のコードや連携が一度も発火していないケースは珍しくありません。必ず実際の受信実績を見てください。

手順2：テストイベント＋test_event_code

Meta公式のテストイベント（イベントマネージャ → 対象データセット → テストイベント）は、いま届いているイベントをリアルタイムに表示します。CAPIの確認では、サーバー送信に test_event_code を付けるのがコツです。

  1. テストイベント画面に表示される test_event_code（TEST12345 のような文字列）を取得する
  2. サーバー送信のペイロードにその test_event_code を含めて、テスト用のイベントを1件送る
  3. 数秒以内に、テストイベントのストリームにサーバーイベントとして表示されるはず

分かること： まさに自分のサーバーコードが、Metaに受信される形でイベントを送れていること（③に最も近い実証）。

つまずきやすい例： ブラウザ操作だけで満足してしまうこと。テストイベントにブラウザイベントが出ても、それはピクセルが動いている証拠であって、CAPI（サーバー）が動いている証拠にはなりません。サーバー由来の行が出るかを必ず確認してください。

サーバー側でAPIレスポンスを確認する

見落としがちなポイントがあります。サーバーがMetaのコンバージョンAPIを呼び出すたびに、HTTPレスポンスが返ってきます。このレスポンスをログに残して確認することが、問題を最速で見つける方法です。

HTTPステータス 意味 対処
200 Metaがイベントを受理した レスポンスボディの events_received の件数が送信数と一致するか確認
400 リクエスト不正——ペイロードの形式エラーや必須フィールドの欠落 エラーメッセージを読む。event_time・action_source の欠落や user_data のハッシュ化ミスが多い
401 / 403 認証またはパーミッションの失敗 アクセストークンが期限切れ・無効化・スコープ不足——イベントマネージャで再発行する

APIレスポンスをログに残していなければ、障害が起きても気づけません。エラー率が数%を超えていたら、イベントが静かに欠落しています。

ヒント： 変更を本番に反映する前に、MetaのイベントマネージャのコンバージョンAPI内にあるペイロードヘルパーにJSONペイロードを貼り付けて検証できます。必須フィールド・正しいハッシュ化・よくあるミスを、実際にピクセルへ送信することなくチェックできます。

手順3：ブラウザとサーバーの両方が出ているか・重複排除

CAPIをピクセルと併用している場合、両方が出たうえで重複排除されているのが正常な状態です。テストイベント上で次を確認します。

  • 同じコンバージョンについて、ブラウザとサーバーの両方のイベントが見えるか
  • 両者が同じイベント名と同じ event_id を共有しているか
  • Metaが「重複排除されました」と認識し、二重に計上していないか

分かること： 届いているだけでなく、正しく突き合わされ、二重計上が防げているか。

つまずきやすい例： ブラウザとサーバーで event_id の作り方が違う（片方だけ付けている・別の値になっている）こと。これだとMetaは別イベントと見なし、コンバージョンが二重に膨らみます。送信側の event_id の生成ロジックをそろえてください。

手順4：一致品質（EMQ）と顧客情報パラメータ

CAPIの価値は「届く」だけでなく「人物に紐づく」ことにあります。これを示すのが**一致品質（イベントマッチ品質、EMQ）**です。

  • イベントマネージャの各イベント詳細で、一致品質のスコアと、どの顧客情報パラメータが送られているかを確認する
  • メール（em）・電話（ph）・氏名（fn/ln）・外部ID（external_id）などを、ハッシュ化したうえで送れているか
  • より多く・より正確なパラメータを送るほど、一般に一致品質は上がる

分かること： 届いたイベントが、最適化やアトリビューションに使える形でMetaの人物に紐づいているか。

つまずきやすい例： 個人情報をそのまま（平文で）送ろうとすること。em や ph などはハッシュ化（SHA-256）が前提です。生値を送るとMetaは正しく扱えず、一致もしません。サーバー側でハッシュ化されているかを必ず確認してください。

fbp・fbc・デバイスシグナルも忘れずに

メールや電話番号といったPII以外にも、一致品質を大きく左右するパラメータがあります。

  • fbp（Facebookブラウザ ID）： Metaピクセルがセットする _fbp Cookie の値です。ブラウザからサーバー送信に転送すると、Metaはサーバーイベントを同じブラウザセッションに紐づけられます。
  • fbc（Facebookクリック ID）： 広告クリック経由で訪問したときに生成される _fbc Cookie の値です。サーバーイベントを広告に正しくアトリビュートするために不可欠です。
  • client_ip_address と client_user_agent： Metaがサーバーイベントをブラウザイベントと照合するために使います。ハッシュ化したPIIがあっても、これらが無いと一致品質は目に見えて下がります。

この4つのフィールドはピクセルが求める同意の範囲で送信でき、特別な追加同意は不要です。にもかかわらず、これらの欠落はEMQスコアが低い原因のなかで最も多い部類に入ります。ブラウザ起因のシグナル減少についてはSafari ITPとコンバージョン欠落も参照してください。

「サーバーから送れているのに計測に乗らない」のはなぜか

送信（①）は確認できたのに、コンバージョンとして期待どおりに使われない。よくある理由：

  • アクセストークン失効：CAPI用のアクセストークンが期限切れ・無効化されていて、送信が拒否されている
  • 重複排除の不備：ブラウザとサーバーで event_id を共有しておらず、二重計上または欠落
  • ハッシュ化パラメータ不足：顧客情報が少なく一致品質が低いため、最適化で十分に使われない
  • サーバーが発火していない：そもそもコンバージョンの瞬間にサーバー側のイベント送信が走っていない
  • 宛先（ピクセルID）違い：別のデータセットや無効な宛先に送っている

つまり、サーバーから「送れている」ことの確認は、本番でMetaが受信・照合・重複排除した証明にはなりません。

手元の確認だけでは分からないこと

手元で1回・手作業で確認するやり方には、構造的な限界が2つあります。

  1. 自分の環境＝本番のユーザー環境ではない。 test_event_code を付けた自分のテスト送信は通っても、実際の訪問者の購入・問い合わせの瞬間に、本番のサーバー経路で同じように送れているとは限りません。テスト送信の成功は、本番フローの成功とイコールではありません。
  2. 広告クリックがからむコンバージョンは確認が難しい。 「広告経由で本当に計測・最適化されるか」をきちんと見ようとすると、本来はライブ広告をクリックして経路を再現する必要があり、これは自己クリックとして広告ポリシー違反のリスクを伴います。

「テスト送信は成功したからOK」と判断すると、本番の実ユーザーの経路でサーバーイベントが欠けている問題を見逃しがちです。

確実に確認するためのチェックリスト

  • イベントマネージャで、対象イベントにサーバーの接続方法が表示されているか
  • サーバーイベントの受信時刻が最近で、止まっていないか
  • test_event_code を付けたサーバー送信が、テストイベントにサーバーとして現れるか
  • 同じコンバージョンでブラウザとサーバーの両方が見え、同じ event_id で重複排除されているか
  • CAPI用のアクセストークンが有効か（失効していないか）
  • 顧客情報（em・ph 等）がハッシュ化されて送られ、一致品質が許容範囲か
  • 手元のテスト送信だけでなく、本番の実ユーザー経路でもサーバーイベントが欠けていないか

よくある質問（FAQ）

Q. ブラウザのピクセルが動いていれば、CAPIは無くても同じでは？ A. 同じではありません。CAPIは、ITP・広告ブロッカー・iOSのシグナル減少などでブラウザのピクセルが落ちるぶんをサーバー側で補完します。ピクセル単体だと、その取りこぼしぶんがそのまま欠落します。確認方法は別記事のMetaピクセルの発火確認もあわせてどうぞ。

Q. テストイベントにイベントは出るのに「サーバー」と表示されません。 A. それはブラウザのピクセルだけが動いている可能性が高いです。サーバー送信に test_event_code を付けて1件送り、ストリームにサーバー由来の行が出るかを確認してください。出なければ、サーバー側のコードが発火していない・トークンが無効、などを疑います。

Q. CAPIを入れたらコンバージョンが二重に増えた気がします。 A. ブラウザとサーバーのイベントが event_id を共有しておらず、重複排除されていない可能性が高いです。両者のイベント名と event_id をそろえてください。詳しくは重複排除（event_id）の確認を参照してください。

Q. 一致品質（EMQ）はどうすれば上がりますか？ A. ハッシュ化した顧客情報パラメータを、より多く・より正確に送ることです。メール・電話・氏名・外部IDなどを、サーバー側で正しくハッシュ化（SHA-256）して送ると、一般にスコアは上がります。

Q. Metaのワンクリック CAPI（CAPIゲートウェイ）を使っています。確認は不要ですか？ A. いいえ、確認は必要です。ワンクリック CAPI（2026年4月リリース）は設定の手間を大幅に省きますが、イベントがサーバーの接続方法で届いているか、重複排除が機能しているか、一致品質が許容範囲かは引き続き確認が必要です。Metaがインフラをホストするため、サーバーログに直接アクセスできない分、上記の手順1～4の確認がむしろ重要になります。なお、ワンクリック CAPIは標準ウェブイベントのみが対象で、カスタムイベントやオフラインコンバージョンには手動実装と個別の検証が必要です。

Q. アクセストークンはどれくらいで切れますか？ A. トークンの種類や発行方法によって有効期限が変わります。期限切れに気づかないとサーバー送信が静かに止まるため、定期的に受信実績を確認し、長期運用ではトークンの更新方針を決めておくのが安全です。

まとめ：送信の確認で止めず、「Metaが受信・照合したか」まで見る

CAPIの確認は、手順1（接続方法）→2（test_event_code）→3（重複排除）→4（一致品質）の順に進めれば、送信から照合まで切り分けられます。大事なのは全体像です。サーバーイベントが受信され、ブラウザ側と照合・重複排除され、本番の実ユーザー経路でも記録されているか。Metaのコンバージョン計測の全体像はMetaコンバージョン計測の完全ガイドでも整理しています。

ConversionOKは、外部の独立した実ブラウザであなたの本番ページにアクセスし、実際に送信されるイベントを傍受して検証します。自分の広告をクリックする必要も、社内環境の影響を受けることもありません。まずは無料の静的チェックで、計測の入口を確認してみてください。