「開発者ツールのNetworkタブで見ると、コンバージョンのリクエストはちゃんと飛んでいる。なのに管理画面にはコンバージョンが出ない」——これは、タグが入っていない単純なケースよりもずっと厄介で、頭を抱える状況です。発火が確認できている分、「設定は合っているはず」という思い込みが生まれ、どこを直せばいいのか分からなくなります。
こんな状況に心当たりはありませんか？
- Networkタブで
…/pagead/conversion/…への送信は 確かに見えている - それなのに、Google広告のコンバージョンは 0、または明らかに少ない
- GA4のDebugViewにはイベントが出る のに、コンバージョンとして記録されない
- タグアシスタントで 「発火OK」 と出るのに、数字が増えない
もし問題がもっと手前——そもそもコンバージョンが発火していない——であれば、まずGoogle広告でコンバージョンが計測されない原因と診断手順から始めてください。この記事のテーマはひとつです。「発火（ブラウザからGoogleへ送信した）」と「記録（Googleが受理して保存した）」は、まったく別の段階だ ということ。Networkで送信を確認できても、Google側がそれを保存してくれる保証はどこにもありません。この一点を軸に、「送ったのに記録されない」原因を切り分けていきます。
まず大前提：発火＝送信、記録＝受理。間に「審査」がある
つまずきの最大の原因は、「リクエストが飛んだ＝コンバージョンが取れた」と考えてしまうことです。実際には、信号がGoogleに届いてから記録されるまでの間に、Google側の「受理（審査）」という段階 が挟まっています。
| 段階 | 何が起きるか | あなたが確認できる場所 |
|---|---|---|
| ① 発火（送信） | ブラウザがGoogleへ計測リクエストを送る | 開発者ツールのNetworkタブ |
| ② 受理（審査） | Googleが同意・除外・重複・正当性などを判定する | 直接は見えない（媒体内部） |
| ③ 記録（保存） | 判定を通った信号がコンバージョンとして保存される | 管理画面のコンバージョン列 |
ポイントは、あなたがNetworkタブで確認できるのは①だけ だということです。②の審査は媒体の内部で行われ、ここで弾かれると、①が完璧に見えても③には到達しません。つまり「発火しているのに記録されない」とは、ほぼすべて ②の受理段階で何かに弾かれている という意味なのです。
以下では、その②で弾かれる代表的な原因を、技術的に正確に7つ挙げていきます。
原因1：同意モードで、同意が無く保存・モデル化されている
同意モード（Consent Mode）を導入していると、リクエスト自体は送信されます（実際、同意モードv2は同意が無くてもCookieレス・ピングを送る設計です）。Networkタブには確かにヒットが見える のに、ユーザーが計測の同意をしていない場合、Google側はそのデータをそのまま保存せず、制限・モデル化された扱いにします。
- 発火（送信）は起きている → だから手元では「飛んでいる」ように見える
- しかし
gcsパラメータが「同意なし」を示していれば、受理段階で通常の記録にはならない
これは「発火しているのに記録されない」の典型中の典型です。詳しいメカニズムは同意モードでコンバージョンが減る理由で解説しています。
つまずきやすい例： 「リクエストは飛んでいるのに数が合わない」とき、まず送信されているリクエストの中身（同意状態を示すパラメータ）を見てください。「飛んでいる＝同意あり」ではありません。
原因2：内部トラフィック除外・データフィルタで受理段階で弾かれる
GA4の 内部トラフィック除外 や デベロッパートラフィックのフィルタ、Google広告のIP除外が効いていると、リクエストは送られても受理段階で破棄されます。送信は成立しているのに記録されないので、Networkだけ見ていると原因にたどり着けません。
- 自分や社内のIPアドレスがフィルタ対象になっている
- GA4の「内部トラフィック」ルール（
traffic_type=internal）がデータフィルタで除外設定になっている
厄介なのは、これは 正常な動作 だという点です。あなた自身がテストすると弾かれるよう設計されているので、「自分でテストすると発火するのに記録されない」のは壊れているわけではありません。
つまずきやすい例： 自分のPCで完了ページを踏んで「飛んでいるのに記録されない」とき、内部トラフィック除外が効いている可能性が高いです。除外対象の自分のテストで「壊れている」と即断しないでください。
原因3：キーイベント／コンバージョンとして未登録
GA4でイベントが発火し、DebugViewにも表示される。それでも、そのイベントを 「キーイベント（コンバージョン）」として登録していない と、Google広告のコンバージョン列には出てきません。送信も受信もされているのに、「コンバージョンとして数える」という設定が無いだけ、という状態です。
- GA4側ではイベントが届いている（送信・受信は正常）
- だが「キーイベント」化していない、または広告にインポート・コンバージョンとして登録していない
これは「GA4には出るのに広告に出ない」の筆頭容疑です。送信の有無を疑う前に、登録設定を確認しましょう。
つまずきやすい例： DebugViewでイベントが見えたことに安心して終わると、この登録漏れを見逃します。「イベントが届く」と「コンバージョンとして数える」は別の設定です。
原因4：測定ID／コンバージョンIDの取り違え
リクエストは飛んでいるが、送り先のID（測定ID・コンバージョンID・ラベル）が間違っている、というケースです。送信は成立しているので発火は確認できますが、信号は意図したコンバージョンアクションではなく、別のプロパティ・別のアクション（あるいは存在しない宛先）に届いています。
- GTMのタグに古い／別アカウントのコンバージョンIDが残っている
- 測定ID（
G-XXXX）とコンバージョンID（AW-XXXX）を取り違えている - リダイレクトや環境（本番・ステージング）でIDが入れ替わっている
Networkタブでリクエストの中身を開き、tid や送信先のID・ラベルが、管理画面で見ている対象アクションと一致しているかを必ず確認してください。
つまずきやすい例： 「発火はしているのに、見ている管理画面の数字が動かない」とき、発火しているリクエストの宛先IDと、あなたが眺めている管理画面のアクションが別物、という取り違えがよくあります。
原因5：重複排除・計測期間の窓から外れる
同じコンバージョンが二重に送られていると、Googleは 重複排除（dedup） で片方を記録しません。逆に、クリックから時間が経ちすぎて 計測期間（コンバージョン トラッキング期間）の窓 を外れた成果も、送信されても受理されません。どちらも「送ったのに記録されない」状態を作ります。
- トランザクションIDが同じ／タグが二重設置で、片方が重複として捨てられる（詳しくは二重計測の原因と直し方）
- クリックからコンバージョンまでの期間が設定上限を超えている
「広告とGA4で件数が合わない」現象も、この重複排除や窓のズレが原因のことがあります。媒体間の数の食い違いについては広告とGA4の件数が合わない理由も参照してください。
つまずきやすい例： 「送信は2回見えるのに記録は1件」のとき、それは故障ではなく重複排除が正しく働いている可能性があります。送信回数と記録件数は一致しないのが正常な場合があります。
原因6：ボット／スパム判定で除外される
Googleは無効なトラフィック（IVT）対策として、ボットや自動化ツール、不自然なパターンからの送信を 受理段階で除外 します。ヘッドレスブラウザや自動テストツールで発火させたリクエストは、Networkには出ても記録されないことがあります。
- 自動化ツール・ヘッドレスでの動作確認は、ボット判定で弾かれうる
- 短時間に同一環境から大量の送信があるとスパム的と見なされうる
「テスト自動化では発火するのに本番の記録が増えない」場合、テスト自体が除外対象になっている可能性を考えます。これも正常な防御動作です。
つまずきやすい例： 自動テストで「飛んでいるから大丈夫」と判断すると、その送信がボット除外されていて実ユーザーの記録は別問題、というケースを見逃します。検証は実ユーザーに近い条件で行うことが重要です。
原因7：反映の時間差（壊れと誤認しない）
最後に、意外と多いのが 壊れていないのに焦るケース です。発火（送信）はリアルタイムで確認できますが、それが管理画面のコンバージョン列に反映されるまでには 時間差 があります（通常は数時間、初回はさらにかかることも）。
- 設定直後やタグ入れ替え直後に「発火しているのに0だ、壊れた」と判断
- そのまま設定を触り始め、正常な配線を崩してしまう
発火が確認できているなら、送信の配線は生きています。まず数時間〜翌日まで待って、それでも記録されないのか を確認しましょう。
つまずきやすい例： 「Networkでは飛んでいる」を確認できた直後に0を見て壊れたと即断しないでください。発火が見えている時点で、残りは受理と反映の問題です。
原因8：プラットフォーム間のアトリビューション ウィンドウの不一致
タグは発火し、コンバージョンも実際に発生している——しかしGoogle広告の**アトリビューション ウィンドウ（計測期間）**が切れているため記録されない、あるいはウィンドウ設定が異なるプラットフォーム間で数字を比較しているケースです。
- Google広告のデフォルト： クリック後30日、ビュー後1日
- Metaのデフォルト： クリック後7日、ビュー後1日（iOS 14以降に28日から変更）
- GA4： セッションベースまたは設定可能で、ロジック自体が異なる
検討期間が30日を超えるビジネスでは、35日目に発生したコンバージョンは正しく発火しますが、Google広告には記録されません。また、プラットフォーム間でコンバージョン数を比較している場合、ウィンドウの不一致が「計測の不具合」に見える差異を生んでいることがあります。
確認方法： Google広告 → 目標 → コンバージョン → 設定で、アトリビューション ウィンドウが実際の商談サイクルと合っているか確認します。検討期間が長いビジネス（BtoB、不動産、高額商材）では、ウィンドウを延長してください。
原因9：クロスデバイスでのコンバージョン経路の断絶
ユーザーがスマホで広告をクリックし、ノートPCで調べ、自宅のデスクトップでコンバージョンする。デスクトップでタグは発火するが、スマホでの広告クリックとこのコンバージョンを結ぶCookieが存在しません。
Googleはログイン済みユーザーのデータ（デバイス間でGoogleアカウントにログインしているユーザー）でクロスデバイスの経路をつなごうとします。しかしユーザーがログインしていない場合や、異なるブラウザを使っている場合、経路が断絶し、コンバージョンは発火するがアトリビューションされないという状態になります。
緩和策：
- Enhanced Conversions — ハッシュ化されたメールアドレスでマッチングすることで、デバイスをまたいでも同一ユーザーとして識別
- サーバーサイドタグ付け — セッションをまたいで保持できるファーストパーティの識別子を送信
- 両方のアプローチはファーストパーティデータ戦略ガイドで詳しく解説しています
原因10：コンバージョンのカウント設定が重複を排除している
Google広告のコンバージョンアクションにはカウント設定として「1回」と「すべて」があります。
- 「1回」： 同一の広告クリックから最初の1件だけが記録される。同じユーザーが再度コンバージョンしても（フォームの二重送信、サンクスページのリロードなど）、2回目以降はサイレントに捨てられる
- 「すべて」： すべてのコンバージョンが計上される（ECのように各購入が別の取引であるケースに適切）
リード用アクションに「1回」を設定している場合、同一ユーザーの2回目の正当なコンバージョンが記録されなくても、設定どおりの動作です。逆にリード用に「すべて」を設定すると、ページリロードで数字が膨らむことがあります。
確認方法： Google広告 → 目標 → コンバージョン → 該当アクションをクリックし、「カウント」設定を確認します。リードには「1回」、取引には「すべて」を使いましょう。
では、どう確認するか
「発火しているのに記録されない」を確かめるには、①の送信確認だけでなく、②受理に関わる条件まで見る必要があります。
- GA4のDebugView／リアルタイム： イベントが受信されているか、
debug_modeで確認する。ただしDebugViewに出ること＝コンバージョン記録、ではない点に注意（原因3） - 媒体のテストツール： Google広告のタグアシスタント等で、宛先IDやラベルが意図どおりかを確認する（原因4）
- 送信リクエストの中身を読む： Networkで
gcs（同意状態）やtid／ラベルを開き、「飛んでいる」の中身まで見る（原因1・4） - 本番条件での検証： 内部除外・ボット除外・拡張機能の影響を受けない、実ユーザーに近い条件で確かめる（原因2・6）
切り分けの全体像はコンバージョン計測の検証チェックリスト、GA4タグそのものの確認はGA4タグが正しく動いているか確認する方法にまとめています。
確認チェックリスト
- Networkで送信されているリクエストの 中身（宛先ID・ラベル・
gcs）を開いて確認したか - 送信先のID（測定ID／コンバージョンID）が、見ている管理画面のアクションと一致しているか
- 同意モードで、同意なし状態の扱い（制限・モデル化）になっていないか
- 内部トラフィック除外・データフィルタで、自分のテストが弾かれていないか
- GA4のイベントを「キーイベント（コンバージョン）」として登録済みか
- 二重設置・重複排除や、計測期間の窓から外れていないか
- 自動化ツール／ヘッドレスで検証していて、ボット除外されていないか
- 設定直後なら、反映の時間差（数時間〜翌日）を待ったか
手元の確認だけでは分からないこと
ここまでの確認はどれも有効ですが、自分の手元で1回確認する やり方には、構造的な限界が2つあります。
- 自分の環境＝本番のユーザー環境ではない。 あなたのPCはログイン状態・拡張機能・社内IP除外などの条件が実ユーザーと違います。手元では「発火している」のに、実ユーザーの環境では受理段階で弾かれている、という食い違いは手元検証では見えません。
- 広告クリックがからむと確認が難しい。 「広告経由で本当に記録されるか」を厳密に見ようとすると、ライブ広告をクリックして経路を再現する必要があり、これは自己クリックとして広告ポリシー違反のリスクを伴います。
「自分の操作では飛んでいるからOK」と判断すると、まさに 発火は見えているのに本番の受理段階で欠けている という、この記事が扱う問題そのものを見逃しがちです。
よくある質問（FAQ）
Q. Networkタブでリクエストが飛んでいるのに、コンバージョンが記録されません。 A. 発火（送信）と記録（受理・保存）は別段階です。送信は成立しているので、原因は受理段階にあります。本記事の原因1（同意モード）・2（内部除外）・3（キーイベント未登録）・4（ID取り違え）・5（重複排除）・6（ボット除外）・7（時間差）の順に確認してください。
Q. GA4のDebugViewにはイベントが出るのに、広告にコンバージョンが出ません。 A. イベントが受信されていることと、それを「コンバージョンとして数える」ことは別設定です。GA4で「キーイベント（コンバージョン）」として登録し、広告側でコンバージョンとして取り込めているかを確認してください（原因3）。
Q. 送信は2回見えるのに、記録は1件しか増えません。壊れていますか？ A. 多くの場合は故障ではなく、重複排除が正しく働いています。トランザクションIDの重複やタグの二重設置がないかを確認してください（原因5）。
Q. 自分でテストすると発火するのに、記録されないのはなぜですか？ A. 内部トラフィック除外で自分が除外対象になっている（正常動作）か、自動化ツールでの検証がボット除外されている可能性があります（原因2・6）。実ユーザーに近い条件で検証してください。
Q. 発火が確認できているなら、あとは待てば必ず記録されますか？ A. 必ずではありません。発火は「送信できた」までを示すだけです。時間差で反映されるケース（原因7）もありますが、受理段階で弾かれていれば待っても記録されません。送信の中身（同意・宛先ID）まで確認するのが確実です。
まとめ：見えているのは「送信」だけ。記録は受理を通った先にある
「発火しているのに記録されない」の正体は、Networkタブで見えるのは①送信だけで、その先に②受理（審査）という見えない段階がある ことです。同意モード・内部除外・キーイベント未登録・ID取り違え・重複排除・ボット除外・時間差——記録されない原因のほとんどは、この受理段階に潜んでいます。
だからこそ、「発火しているからOK」では確認になりません。本番環境で、実際の訪問者の経路でも、受理を通って記録まで到達しているか を確かめることが、本当の意味での「計測できている」確認です。
ConversionOKは、外部の独立した実ブラウザであなたの本番ページにアクセスし、実際に送信されるコンバージョンの信号を傍受して、その中身（同意状態・宛先ID）まで含めて、発火から記録までのどこで途切れているかを切り分けて指摘します。自分の広告をクリックする必要も、社内環境の影響を受けることもありません。まずは無料の静的チェックで、計測の入口を確認してみてください。