Cloudflare Web AnalyticsとGA4の違い｜数字がズレる理由

初級InfraDB編集部

TL;DR

「Cloudflare のアクセス解析と GA4、どっちを使えばいい？」の答えは用途で決まります。ただしその前に、Cloudflare にはアクセス数らしき数字が出る機能が少なくとも2つあり、数え方がまったく違う、という点を押さえておく必要があります。

  • Cookie を使わない解析で、ページ別・参照元別の傾向がわかれば足りる → Cloudflare Web Analytics（ページで動く JavaScript のビーコンで数える。Cloudflare の DNS やプロキシを使っていなくても使える）
  • UTM で広告・キャンペーン別に流入を分けたい、問い合わせまで繋がったかを追いたい → GA4（無料。Web Analytics には UTM の記録もイベントの計測もない）
  • サイトに届いた通信の量や脅威を見たい → Cloudflare の Analytics & Logs → HTTP Traffic（Cloudflare でプロキシしているドメインが対象）
  • 数字が合わない → 故障とは限りません。HTTP Traffic はクローラーも含めて届いたリクエストを数え、Web Analytics と GA4 はブラウザで動く JavaScript で数えます。同じ値にならないのが前提です

上司に「先月のアクセス数は？」と聞かれて Cloudflare と GA4 の画面を見比べたら、まるで違う数字が並んでいた。どちらを報告すればいいのか、どちらかが壊れているのか、判断に困っていませんか。

壊れていると決める前に確認したいのは、「どの画面の、どの数字か」です。

まず確認：Cloudflare のどの画面を見ているか

Cloudflare でアクセス数らしき数字が出る画面は、少なくとも2つあります。名前は似ていますが、別の機能です。

  • Cloudflare Web Analytics … ページに JavaScript のスニペット（ビーコン）を入れ、訪れた人のブラウザから計測する機能です。公式ドキュメントでは RUM（Real User Monitoring：実ユーザー計測）と説明されています。ダッシュボードの Web Analytics のページで、Visits・Page views や参照元の一覧が出ていれば、こちらの画面です
  • Analytics & Logs → HTTP Traffic … Cloudflare でプロキシしている（訪問者からの通信を Cloudflare のネットワーク経由でサイトに届けている）ドメインについて、エッジ（Cloudflare 側のサーバー網）のログを集計する画面です。Traffic / Security / Performance などのタブが並んでいれば、こちらです

GA4 と比べて Cloudflare の数字だけが極端に大きいなら、HTTP Traffic を見ている可能性が高いと考えられます。

Cloudflare Web AnalyticsHTTP Traffic（Analytics & Logs）GA4
数える仕組みページで動く JavaScript（ビーコン）Cloudflare のエッジのログページで動く JavaScript（計測タグ）
使える条件Cloudflare の DNS 変更やプロキシがなくても使えるプロキシ（オレンジクラウド）しているドメインのみサイトに計測タグを設置する
クローラー・脅威—含まれる既知のボット・スパイダーは自動で除外
広告ブロッカービーコンがブロックされるブロックされない—
見られる項目参照元（referer host）・国・デバイス・ブラウザ・OS。UTM は記録しない—UTM でキャンペーン別に見られる
Cookie使わないスクリプト不要（エッジのログで集計）ファーストパーティ Cookie を使う
データの保持過去6ヶ月プランによって異なる2ヶ月か14ヶ月（Analytics 360 ではイベントデータを50ヶ月まで）
データが出るまで設定後、数分かかることがある—多くのレポートで24〜48時間かかることがある
料金無料全プランに含まれる無料（360 契約者向けの Analytics 360 もある）

「—」は、公式ドキュメントで記載を確認できていない項目です（影響がない、機能がない、という意味ではありません）。

数字がズレる理由

HTTP Traffic が大きく出やすいのは、クローラーも含めて数えるから

HTTP Traffic はエッジのログにもとづく数字で、正規のユーザーによるリクエストに加えて、クローラーや脅威によるリクエストも含みます。ページのスクリプトを必要とせずに集計するので、訪問者の広告ブロッカーにも止められません。ただし数えるのは Cloudflare のプロキシを通った通信だけで、プロキシしていない DNS レコードへの通信は含みません。なお、Cloudflare の分析は Adaptive Bit Rate（ABR）という方式で、条件に応じた解像度のデータを選んで集計（サンプリング）します。

自動化トラフィックの規模の目安として、Imperva の 2025年版レポート（2025 Bad Bot Report）は、自動化トラフィックが Web トラフィック全体の51%、悪性ボットだけで37%を占めると報告しています。インターネット全体の数字なので、自分のサイトでの割合はサイトによって違います。

GA4 は、既知のボットやスパイダーを自動で除外します。Cloudflare 自身も、脅威・ボット・クローラーのリクエストは通常 JavaScript を実行しないため Google アナリティクスには記録されない、と説明しています。HTTP Traffic と GA4 に差が出る理由の1つが、この数え方の違いです。

なお、ボットの内訳を画面で切り分ける Bot Analytics は、Business / Enterprise 向けの機能です。

Web Analytics と GA4 は、どちらもブラウザ側で数える

どちらもページで JavaScript が動いたときに数える仕組みですが、次の理由で一致しません。

  • 指標の定義: Web Analytics の「Visits」は、別のサイトから、または直接リンクで始まったページビューです（「Page views」は HTML を返した成功レスポンス）。GA4 の「セッション」はページ表示などで始まり、既定では操作のない状態が30分続くと終わります。たとえば、30分以上放置したあとサイト内のリンクで次のページに進むと、GA4 では新しいセッションが始まりえますが、Web Analytics の Visits は増えません
  • 反映の時間差: GA4 のレポートは、データの処理に24〜48時間かかることがあります。直近の期間を比べると、GA4 側だけ少なく見えることがあります
  • サンプリング: Web Analytics は直近7日間のデータをサンプリングせずに保持し、それより前は約10%に集約します。画面で集計するときも、絞り込み条件やデータ量に応じてサンプリングの割合が自動で選ばれるので、期間や条件によっては推定を含む値になります

なお、Cloudflare は公式 FAQ で、Web Analytics のビーコンが広告ブロッカーにブロックされることを認めています。広告ブロッカーを使う訪問者の分は、Web Analytics の数字から欠けます。GA4 がどの程度影響を受けるかについて、Google の公式な記載は確認できていません。

Cloudflare Web Analytics とは何か

Cloudflare が無料で提供しているアクセス解析です。Cloudflare の DNS に切り替えたり、プロキシを通したりしなくても使えます。公式 FAQ では、むしろ Cloudflare のプロキシを使っていない利用者を主に想定した機能 だと説明されています。ドメインをプロキシしていても、Web Analytics の数字はビーコンで数えたもので、HTTP Traffic の数字とは別物です。

見られるもの: ページごとの Visits・Page views ／ 参照元（referer host） ／ 国・デバイス・ブラウザ・OS

見られないもの

  • UTM パラメータ: 現時点では、機微なデータを集めないようクエリ文字列を記録していません。UTM でキャンペーンを分けた流入は追えません
  • イベント・コンバージョン: フォーム送信や購入完了などの計測機能はありません（公式 FAQ では、UTM・イベントとも将来対応する可能性があるとしています）

Cookie や localStorage を使わず、フィンガープリント（端末の特徴から利用者を識別する手法）もしない、と Cloudflare は公表しています。

有効化の手順

まず、すでに有効になっていないか確認する

Cloudflare は、2025年10月15日から無料プランのすべてのドメインで Web Analytics を既定で有効にする、と発表しています（EU・英国から発生する通信は対象外）。同じ発表では、Pro / Business / Enterprise はダッシュボードで有効にするとしています。無料プランで Cloudflare を使っているなら、ダッシュボードの Web Analytics に、すでにデータが出ていないかを先に見てください。

Cloudflare でプロキシしているドメインの場合

  1. ダッシュボードの Web Analytics を開く
  2. Add a site を選ぶ
  3. 一覧からホスト名を選ぶ

これで自動セットアップ（既定で有効）が使われ、Cloudflare がビーコンをページに自動で挿入します。HTML にスニペットを貼る必要はありません。自動で入るのも手動と同じビーコンなので、広告ブロッカーに止められる点は変わりません。

プロキシしていないサイトの場合

Web Analytics の JavaScript スニペットを、自分でページに貼ります。サイト共通のレイアウト（テンプレート）に入れておけば、全ページで読み込まれます。

Cloudflare Pages でホスティングしている場合

対象の Pages プロジェクトで Metrics を開き、Web Analytics の項目で Enable を選びます。

データが表示されないときの確認

  1. 数分待つ: 公式ドキュメントでも、設定後にデータが出るまで数分かかることがあるとされています
  2. CSP を確認する: CSP（Content Security Policy：ブラウザが読み込み・通信してよい取得元を指定する仕組み）を設定しているサイトでは、次の2つの許可が必要になる場合があります
    • ビーコンの読み込み元: https://static.cloudflareinsights.com/beacon.min.js
    • データの送信先: プロキシしているサイトは https://<あなたのドメイン>/cdn-cgi/rum、プロキシしていないサイトは https://cloudflareinsights.com/cdn-cgi/rum
  3. Cache-Control ヘッダーを確認する: プロキシして自動挿入を使っている場合、Cache-Control: public, no-transform を設定していると、Cloudflare がページを書き換えられないため、ビーコンが自動で挿入されず、Web Analytics は動きません
  4. 自分のブラウザの広告ブロッカーを確認する: 表示を確かめるために自分でアクセスする場合、広告ブロッカーが有効だとビーコンがブロックされ、そのアクセスは計測されません

GA4 とは何か

GA4（Google Analytics 4）は、Google が無料で提供しているアクセス解析ツールです。Google アカウントで登録し、サイトに計測タグ（JavaScript）を設置して使います。

強み

  • キャンペーン別の流入分析: リンクの URL に UTM パラメータ（utm_source / utm_medium / utm_campaign）を付けておくと、どのキャンペーンから流入したかを見られる
  • 成果の計測: 収集した任意のイベントを「キーイベント」（旧称：コンバージョン）に指定して、問い合わせや購入などを計測できる
  • Search Console との連携: 連携すると、自然検索からの流入を GA4 の中で分析できる
  • データ保持期間の設定: 2ヶ月か14ヶ月から選べる（Analytics 360 では、イベントデータに26ヶ月・38ヶ月・50ヶ月も選べる）

弱み

  • Cookie を使う: GA4 の JavaScript タグはファーストパーティ Cookie を使い、_ga（有効期間2年）で利用者を区別します。EU 域内からのアクセスがある場合など、同意取得（クッキーバナー）が論点になるケースがあります
  • ボットを除外する: 既知のボット・スパイダーは数えないため、サイトに届いた通信の全体像は見えません。Cloudflare でプロキシしているなら、全体像は HTTP Traffic 側で見ることになります
  • 反映に時間がかかる: 設置した当日に数字が少なくても、すぐに設定ミスと決めつけないほうが安全です
  • 設定の手間: 機能が多く、キーイベントなどを設定しておかないと、判断に使えるデータになりにくい面があります

Cookieとは？ ウェブサイトがブラウザに保存する小さなデータファイルのことです。「前に来た人かどうか」などを記録するために使われます。

結論：用途別に使い分ける

3つは競合ではなく、数えている場所がエッジとブラウザの2つに分かれます。

【エッジ】Cloudflare HTTP Traffic
  Cloudflare に届いたリクエスト（クローラー・脅威を含む）
  対象：プロキシしているドメイン／広告ブロッカーでは止まらない
────────────────────────────────────────────
【ブラウザ】Cloudflare Web Analytics ／ GA4
  ページの JavaScript が動いた訪問
  Web Analytics：ページ・参照元・国・デバイス（UTM・イベントはなし）
  GA4：UTM 別の流入・キーイベントの計測まで（既知のボットは除外）

上司や社内に報告するときは、「Web Analytics の Visits」「GA4 のセッション」のように どの画面の、どの指標か を添えておくと、数字が合わない理由を後から説明しやすくなります。

「どれか1つだけ使うなら？」

  • ブログ・コンテンツ運営で、キャンペーンの効果や問い合わせまで追いたい → GA4
  • Cookie を使わずに、ページと参照元の傾向がわかれば足りる → Cloudflare Web Analytics
  • 通信量や脅威（Security タブ）、帯域の節約量（Performance タブ）を見たい → すでにプロキシしているなら HTTP Traffic（全プランに含まれます。選べる期間や表示項目はプランで異なります）
  • 行動分析は GA4、Cookie なしの傾向把握は Web Analytics と、役割を分けて併用する選択肢もあります

クッキーバナーはどちらが必要？

Cookie などの利用
Cloudflare Web AnalyticsCookie や localStorage を使わず、フィンガープリントもしない（Cloudflare の公表）
HTTP Trafficサードパーティのスクリプトやトラッカーを必要とせず、エッジのログを集計する
GA4ファーストパーティ Cookie（_ga など）を使って計測する

Cookie を使わないことは、同意取得を検討するうえで押さえておきたい違いです。ただし、クッキーバナーやプライバシーポリシーへの記載が必要かどうかは、Cookie の有無だけでは決まりません。対象となる規制（EU の GDPR、日本の個人情報保護法など）、訪問者がどの地域にいるか、ほかに入れているツールによって判断が変わります。

Web Analytics だけにすればバナーが要らなくなる、とは言い切れません。自分のサイトで何が必要かは、法律専門家への確認をおすすめします。

GA4CloudflareAnalyticsGDPRPrivacy

関連記事

Cloudflare・CDN活用CDNとは何か、Cloudflareを挟む理由【入門】無料で何ができる？Cloudflare・CDN活用WordPress高速化：Cloudflareキャッシュ設定Cloudflare・CDN活用サイトを無料でHTTPS（鍵マーク）にする方法【Let's Encrypt + certbot 実務ガイド】
記事一覧に戻る