Metaのコンバージョンを正確に計測するために、ピクセル（ブラウザ）とコンバージョンAPI（CAPI／サーバー）で同じイベントを両方送る——これはMeta自身が推奨する構成です。片方が同意やブラウザ制限で落ちても、もう片方が拾える冗長性が生まれます。でも、この「両方送る」が重複排除（deduplication）なしに動いていると、1件のコンバージョンが2件として計上されてしまいます。冗長性のための設計が、そのまま水増しの原因に変わるのです。
こんな症状に心当たりはありませんか？
- ピクセルとCAPIを両方入れてから、コンバージョンが実際より多い
- Events Manager上、同じ購入がブラウザ分とサーバー分で2件に見える
- 売上（
value）の合計が、実売上より膨らんでいる - 重複排除を設定したはずなのに、重複が消えていない
この記事では、Metaの重複排除がなぜ必要か、その条件（event_id とイベント名）、そしてブラウザ側とサーバー側で本当に効いているかを確認する方法を、実務目線で整理します。
確認の前に：「両方送る」と「二重計測」は紙一重
まず大前提を押さえます。MetaがピクセルとコンバージョンAPIの併用を勧めるのは、取りこぼしを減らすためです。ブラウザ側はトラッキング防止や広告ブロッカーで欠けやすく、サーバー側はそれらの影響を受けにくい。だから同じイベントを両方から送り、Metaが**重複を1件に名寄せ（重複排除）**してくれることを前提に成り立っています。
| 状態 | 起きること |
|---|---|
| 片方だけ送る | 取りこぼしが起きやすい（冗長性なし） |
| 両方送る＋重複排除あり | 1件として正しく計上される（推奨） |
| 両方送る＋重複排除なし | 同じ1件が2件に水増しされる |
つまり問題は「両方送ること」ではなく、両方送ったうえで重複排除が効いているかです。確認すべきは「送れているか」ではなく「Metaが1件にまとめられているか」になります。
重複排除の条件：同じ event_id ＋同じイベント名
Metaがブラウザ側とサーバー側のイベントを「同じ1件」と判断する条件はシンプルです。
- 同一の
event_id（イベントID） … 1つのコンバージョンに対して、ブラウザとサーバーでまったく同じ値を渡す - 同一の
event_name（イベント名） …PurchaseやLeadなど、両側で同じイベント名を使う
この2つが揃って初めて、Metaは「これはブラウザとサーバーから届いた同じ出来事だ」と判断し、1件に名寄せします。補助的に fbp（ブラウザID、_fbp クッキーの値） も照合に使われますが、軸になるのはあくまで event_id ＋イベント名の一致です。
つまずきやすい例： イベント名は合わせたのに
event_idを片側にしか付けていないケース。これだと「名前は同じだが別の出来事」と扱われ、重複排除されずに2件残ります。逆にevent_idを揃えてもイベント名がPurchaseとpurchaseでずれていると、これも別物扱いになります（Metaコンバージョン完全ガイド）。
48時間の重複排除ウィンドウ
Metaはイベントを無期限に保持して照合するわけではありません。ブラウザ側とサーバー側のイベントが同じ event_id とイベント名を持っていても、両方が48時間以内に届いた場合にのみ名寄せされます。このウィンドウを過ぎると、event_id が完全に一致していても別物として扱われ、2件としてカウントされます。
実際にはピクセルは即座に発火し、CAPIも通常は数秒〜数分以内に送信されるため、問題になることは稀です。しかしサーバー側のパイプラインに長い遅延がある場合——夜間バッチ処理、週末に滞留するキュー、失敗イベントを保持するリトライロジックなど——CAPIイベントが48時間のウィンドウ外に着地し、重複排除が静かに止まることがあります。
ポイント： コンバージョンをバッチ処理している場合は、遅延を48時間よりも十分短く保ちましょう。リアルタイムまたはほぼリアルタイムでのサーバー送信が最も安全です。
確認方法：ブラウザ側とサーバー側で event_id が一致しているか
重複排除が効いているかの確認は、両側の event_id が同じ値かを突き合わせるのが核心です。順を追って見ます。
1. ブラウザ側の event_id を見る
ブラウザの開発者ツールで「Network（ネットワーク）」タブを開き、facebook.com/tr でフィルタします。対象のコンバージョン操作を1回行い、飛んだリクエストの中の eid（＝event_id）パラメータの値を確認します。fbq('track', 'Purchase', {...}, {eventID: '...'}) の eventID がここに乗ります。
2. サーバー側の event_id を見る
CAPI側は、サーバーがMetaに送るペイロード（data[].event_id）に同じ値が入っているかを確認します。実装ログやテストイベント用のコードを使い、ブラウザで確認したのとまったく同じ値になっているかを突き合わせます。
3. Events Managerの「テストイベント」で突合する
Events Manager →対象データセット →テストイベントを開き、サイトで1回コンバージョンを発生させます。ブラウザ由来とサーバー由来の2つのイベントが届き、Metaがそれらを**「重複排除済み（deduplicated）」**として1件にまとめていれば、その旨の表示が出ます。逆に2件が別々に並んだままなら、重複排除は効いていません。
つまずきやすい例： テストイベントは「今この瞬間・自分の環境」を見ているだけです。手元では揃っていても、本番で
event_idを動的生成している箇所がズレると、実ユーザーの経路でだけ重複が発生します。手元の1パターンで安心しないことが大切です。
Events Managerで重複排除率を確認する
テストイベントは一瞬のスナップショットですが、Events Managerでは集計ベースの重複排除指標を継続的にモニタリングできます。確認方法は以下の通りです。
- Events Managerを開き、対象のデータセット（ピクセル）を選択する
- 個別のイベント名（例：Purchase）をクリックする
- 詳細画面で、受信数（Received）（全ソースからの生イベント合計）と重複排除数（Deduplicated）（重複として認識・統合されたイベント数）を比較する
この2つの数値の差が、実際に行われた重複排除です。ピクセルとCAPIの両方が安定して発火している健全な構成では、あるイベントの重複排除率はおおよそ**40〜70%**になります。数値の読み方は次の通りです。
| 重複排除率 | 意味合い |
|---|---|
| 40〜70% | 健全——両ソースが発火し、Metaが名寄せしている |
| ほぼ0% | event_id が渡っていないか、一致していない |
| ほぼ100% | 異常——片方のソースがMetaに届いていない可能性 |
注意： 概要タブの重複排除率はリアルタイムではありません。特にデプロイ直後は、少なくとも48〜72時間の実トラフィックを待ってから判断してください。
重複排除が効かない「よくある原因」
event_id を入れたのに重複が消えない——その典型パターンです。
1. 両側で event_id が異なる
最も多い原因です。ブラウザとサーバーで別々に event_id を生成していると、値が一致せず別物扱いになります。event_id は「ブラウザ側で生成した値をサーバーへ渡す」「共通のロジックで同じ値を生む」など、両側で必ず同じになる仕組みにする必要があります。
2. 片側にしか event_id が無い
ピクセルには eventID を渡しているがCAPIには event_id を入れていない（またはその逆）。片側に無ければ照合のしようがなく、重複排除は発生しません。
3. イベント名が一致していない
Purchase と purchase、あるいは標準イベントとカスタムイベントの混在など、イベント名のずれも重複排除を無効にします。両側で完全に同じ名前を使います。
4. fbp／fbc が渡っていない
補助的な照合に使われる fbp（ブラウザID）や fbc（クリックID）がサーバー側に渡っていないと、照合精度やマッチ品質に影響します。event_id の一致が主軸ですが、これらも併せて渡すのが望ましい構成です。
GTM Server-Sideで event_id を渡す方法
Google Tag Manager（GTM）Server-SideでCAPIを実装している場合、event_id を両側で一致させる流れは一般的に以下のようになります。
- クライアント側で
event_idを生成する。 ウェブサイトのJavaScript（またはクライアント側GTMタグ）で、コンバージョンごとにユニークなID（UUIDや注文IDなど）を作成する。 - ピクセルに渡す。
fbq('track', ...)のeventIDパラメータにそのIDを含める。 - サーバーコンテナに転送する。 GA4イベント（またはカスタムデータレイヤー変数）のパラメータとして同じIDを送り、サーバー側GTMコンテナに届ける。
- Meta CAPIタグでマッピングする。 サーバー側Metaタグの設定で、受信したパラメータを
event_idフィールドにマッピングする。
ここで重要なのは、クライアントとサーバーがIDの唯一の情報源（single source of truth）を共有することです。サーバーコンテナがクライアントから送られたIDを読み取る代わりに独自のIDを生成すると、値がずれて重複排除が壊れます。サーバー側GTM構成の検証について詳しくは、サーバー側GTMの確認方法を参照してください。
手元の確認だけでは分からないこと
手元で1回・手作業で確認するやり方には、構造的な限界が2つあります。
- 自分の環境＝ユーザーの環境ではない。 ログイン状態・拡張機能・同意の状態によって、手元では
event_idが揃って見えても、実際の訪問者の条件（同意拒否時にブラウザ側だけ落ちる、特定の流入でevent_idの生成タイミングがずれる等）では重複排除が崩れていることがあります。 - 広告クリックがからむコンバージョンは確認が難しい。 「広告経由で本当に1件に名寄せされるか」をきちんと再現するには、本来ライブ広告をクリックして経路をたどる必要があり、これは自己クリックとして広告ポリシー違反のリスクを伴います。
つまり、自分の操作で「event_id が揃っている」と確認できても、本番の実ユーザー経路で重複排除が効いている証明にはなりません。
確実に確認するためのチェックリスト
- ピクセルとCAPIで、同じコンバージョンに同一の
event_idを渡しているか - 両側でイベント名（
event_name）が完全一致しているか（大文字小文字も） - ブラウザ側
eidとサーバー側event_idを実際に突き合わせたか - テストイベントで**「重複排除済み（deduplicated）」**表示を確認したか
-
event_idが毎回ユニークで、かつ両側で同じ値になっているか -
fbp／fbcがサーバー側にも渡っているか - 手元の1パターンだけでなく、本番の実ユーザー条件でも重複が出ていないか
よくある質問（FAQ）
Q. そもそもピクセルとCAPIは両方入れるべき？
A. はい、Metaの推奨です。片方が同意やブラウザ制限で落ちても、もう片方が拾える冗長性が生まれます。ただし重複排除（event_id＋イベント名）が効いている前提での話です。効いていないなら、両方送ることがそのまま二重計測になります（二重計測の基礎）。
Q. event_id はどんな値にすればいい？
A. 1つのコンバージョンを一意に識別できる値（注文IDなど）であれば、ブラウザとサーバーで同じものを使えます。重要なのは「コンバージョンごとにユニーク」かつ「両側で同一」の2点です。毎回違う値が振られたり、片側だけ空だと効きません。
Q. イベント名は合わせたのに重複が消えません。
A. event_id が両側で一致していない可能性が高いです。ブラウザ側で生成した値が本当にサーバーへ渡っているか、別々に生成して値がずれていないかを確認してください（CAPIの確認）。
Q. テストイベントで重複排除済みと出れば本番も大丈夫？
A. テストイベントは自分の環境・その瞬間の確認です。本番では同意の状態や流入経路によって event_id の付与・一致が崩れることがあり、手元の1パターンでは再現しないことがあります。実ユーザー条件での確認が必要です。
Q. ピクセルの確認方法も知りたい。 A. ピクセル単体の設置・発火・受信の確認は別記事で解説しています（Metaピクセルの確認）。本記事の重複排除は、その先の「ピクセルとCAPIの両立」段階の話です。
まとめ：「両方送る」は「1件にまとまる」までがゴール
ピクセルとCAPIを両方入れるのはMetaの推奨であり、取りこぼしを減らす正しい設計です。ただしそれは、同じ event_id ＋同じイベント名でMetaが1件に名寄せ（重複排除）してくれることが前提。重複排除が効かなければ、冗長性のための設計がそのまま二重計測の原因になります。まずは両側の event_id を突き合わせ、テストイベントで「重複排除済み」を確認しましょう。
ただし、手元での1回の確認では、実ユーザーの経路でだけ崩れる重複排除は見つけきれません。ConversionOKは、外部の独立した実ブラウザであなたの本番ページにアクセスし、実際に送信されるピクセルとCAPIのイベント（および event_id の一致）を傍受して検証します。自分の広告をクリックする必要も、社内環境の影響を受けることもありません。まずは無料の静的チェックで、計測の入口を確認してみてください。