CoreDash vs Cloudflare Web Analytics

CoreDashの開発者が書いているという前提はお含みおきください。とはいえ、Cloudflare Web Analytics自体はとても気に入っています。無料で、Cookieも設定しません。Cloudflare配下のサイトなら、誰も導入作業をしていなくてもすでに動いていることさえあります。

すでに稼働していて必要な情報が得られているなら、そのまま使い続けてください。実訪問者を計測できているだけで、何もしない多くのサイトより先を行っています。この記事は、Cloudflareでは答えられない疑問が出てきたときのためのものです。

Cloudflare Web Analyticsの優れている点

言うまでもなく、まずは価格です。Web AnalyticsはCloudflareのどのプランでも完全無料です。サイトがCloudflareのプロキシを経由していなくても使えます。プロキシ経由のゾーンであれば、Cloudflareがエッジでビーコンを自動挿入します（SRIも自動で付与されます）。Cloudflare Pagesならトグルを1つオンにするだけです。

cloudflare.com、2026年10月。

計測の仕組みもしっかりしています。ビーコンはGoogleのweb-vitalsライブラリをラップしたもので、Cloudflareが最新版に追従しています（更新履歴を確認すると、2026年9月2日にv6.2.1へアップデートされています）。SPAの処理も、ChromiumのSoft Navigations API、続いてNavigation APIに対応し、fallbackとしてHistory pushStateを用います。無料のビーコンでここまでSPAをサポートしているのは予想以上でした。

Debug Viewも便利です。各指標の下に、数値を悪化させている上位5つの要素がCSSセレクタ形式で表示され、それぞれP50、P75、P90、P99が確認できます。LCPではリソースのURLとサイズが表示され、CLSではレイアウトシフトを起こした要素と移動前後の位置がわかります。ナビゲーションタイプ（bfcache、prerender、soft navigationsを含む）による絞り込みが可能で、botの除外もトグル1つで設定できます。GraphQL APIにはダッシュボード以上のデータが揃っています。LCPの内訳（リソース読み込み遅延、読み込み時間、レンダリング遅延）、INPの各フェーズ（入力遅延、処理、表示遅延）、LCPリソースのfetchpriority、そしてP99.9までの分位数まで取得可能です。

プライバシーへの配慮も万全です。Cloudflareのドキュメントによれば、CookieやlocalStorageは使わず、フィンガープリントも行いません。そのため、通常は同意バナーの対象にする必要もありません。

LighthouseとSearch Consoleだけを見るより優れている点

監査を担当するサイトの多くは、LighthouseとSearch Consoleしか見ていません。しかし、Lighthouseはシミュレートされたモバイル端末でページを1回読み込むだけです。何もクリックしないため、INPは計測できません。CrUXは同意したChromeユーザーのみを対象とし、十分なトラフィックが集まるまでは何も表示しません（Search Consoleのデータ不足を参照）。Cloudflare Web Analyticsは、実際の訪問者を計測します。何もしないくらいなら、有効にしておきましょう。

CoreDashとCloudflare Web Analyticsの比較

価格と機能は2026年9月時点のものです。CoreDashの料金は年払いの月額換算、米ドル表記です。

ヨーロッパ向けのサイトでCloudflare Web Analyticsを運用しているなら、確認すべき点があります。無料のプロキシ経由ゾーンでCloudflareがRUMを自動有効化すると、EU、EEA、英国、スイスからの訪問者が除外されます。しかも、訪問者が実際にどの国にいるかではなく、リクエストを処理したデータセンターの所在地で判定されます。理由自体は理解できますが、ヨーロッパのショップがこれに気づかないと、大半の訪問者が欠落したダッシュボードを見ることになります。数値を信じる前に、この設定を確認してください。

Cloudflare Web Analyticsのセットアップドキュメント、2026年10月。

CoreDashがさらに役立つ場面

Cloudflare Web Analyticsは、「実訪問者に対してサイトはどれだけ速いか」という問いに答えてくれます。最初に確認すべき疑問として、これは正しい問いです。しかし数か月もすると、別の疑問が湧いてきます。どのスクリプトがINPを悪化させたのか？ 先週火曜のリリースで何か問題が起きていないか？ ログインユーザーの決済画面は遅くなっていないか？ 今年の11月は去年の11月と比べてどうなのか？ Cloudflareでは、こうした疑問のほとんどに答えられません。

アラート

Web Analyticsにある通知機能は、訪問数、ページビュー、読み込み時間の中央値が記載された週次メールだけです。Core Web Vitalsのアラートはありません。性能悪化に気づくのは、誰かがたまたまダッシュボードを開いたときか、1か月後にSearch Consoleが赤くなってからです。

CoreDashには2種類のアラートがあります。カスタムアラートは、デバイス、国、ブラウザ、ページごとに任意の指標のp75を監視します。「良好」から「要改善」「不良」へと悪化したときや、25%または50%以上の変動があったときに作動します。AI Auto Alertsはトグル1つで有効化できます。全5指標にわたる数百のセグメントを毎日チェックし、トラフィックの2%以上に影響するリグレッションのみを、対象セグメントと影響を受けたユーザー数とともに通知します。どちらもメールやSlackに送信可能です。RUMデータと同じダッシュボードにCrUXデータも表示されるため、Googleの見ている数値と実際の訪問者が体験している数値を比較できます。

どのスクリプトが原因か

INPについて、Cloudflareはどの要素が遅かったかを教えてくれます。またAPI経由なら、入力遅延、処理、表示遅延への内訳も得られます。しかし、どのスクリプトが原因だったかはわかりません。スキーマにLong Animation Frames関連のフィールドが存在しないためです。ですが、本当に知りたいのはその点です。クリックの反応が遅い場合、ボタン自体のハンドラーには問題がなく、タグマネージャーやチャットウィジェットがmain threadを占有しているのが大半の原因だからです。

ユーザーの操作によってlong animation frameが発生すると、CoreDashはLong Animation Frames APIからスクリプトURLを紐付けて記録します。そのため、INPをスクリプトごとに絞り込んで調査できます。さらに、入力タイプ、INP読み込み状態（ページの読み込み中にクリックが発生したかどうか）、LCP優先度（preload済み、fetchpriority high、またはlazy loading）も取得可能です。フェーズごとの内訳はAPIだけでなくダッシュボードでも確認でき、Diagnosis画面では14種類のLCPアンチパターンを検出して、利用中のスタックに合わせた修正方法を提示します。

セグメントとデータ保持期間

Cloudflareはクエリ文字列、カスタムイベント、カスタムディメンションを記録しません。そのため、UTM、A/Bテストのバリアント、ページテンプレート、ログイン状態などでデータを細分化することはできません。CoreDashなら、スニペットの実行前にwindow変数を設定するだけで、クエリ文字列に加え、ページラベル、A/Bバリアント、ログイン状態がディメンションになります。たとえば5万件の商品ページに「product」というラベルを付ければ、テンプレート全体の数値を1つのデータとして集約できます。

Cloudflareは、生のビーコンデータをサンプリングなしで7日間保持します。その後は約10%に集約され、ダッシュボードでの表示は6か月前までです。「今週の調子はどうか」を確認する程度なら十分でしょう。しかし、今年のブラックフライデーを前年と比較することはできません。CoreDashなら、保持期間はStarterで6か月、Standardで1年、Studioで3年、Enterpriseなら8年です。

MCPとAIエージェント

Cloudflareは以前、専用のGraphQL MCPサーバーを用意していました。しかし現在は非推奨となり、汎用のAPI MCPに一本化されています。そこではエージェントが汎用的な検索・実行ツールを通じてアナリティクスにアクセスし、自力でGraphQLを書く必要があります。動くことは動きますが、エージェントは問い合わせを行う前にRUMのスキーマを自力で理解しなければなりません。

CoreDashのMCPサーバーはAPIと同じエンドポイントであり、用意されているツールはget_metrics、get_timeseries、get_histogramの3つだけです。自作スクリプトでも同じ3つを使うため、作成したレポートにはエージェントが見ているものと寸分違わぬ数値が表示されます。読み取り専用で（書き込み経路は一切ありません）、Starterを含む全プランに付属しています。Claude、Claude Code、Cursor、Windsurf、VS Code、Gemini CLIに接続し、「今週モバイルで遅くなったページはどれか」と尋ねてみてください。

さらに、MITライセンスの無料エージェントであるCWV Superpowersもあります。field dataを取得し、最も時間を食っているボトルネックを特定します。そしてモバイルエミュレーションとCPUの4倍減速を適用したChromeトレースを記録し、最終的にコードの修正案（ファイル、行番号、diff）またはHTMLレポートを出力します。そこにLighthouseのスコアなど一切登場しません。AIエージェントによるINPの修正では、実際のサイトにおける実例を紹介しています。

クライアントサイトを管理しているなら、Agency APIを使って同じ3つのツールで任意のクライアントプロジェクトを読み取れます。Agencyプランでは、クライアント間でページビューを集約できます。支払いはページビュー数に応じたもので、どのプランでもすべてのダッシュボードが使えます。上位プランの違いは、主にトラフィック枠、登録サイト数、保持期間の長さです。

Cloudflare Web Analyticsを選ぶべきケース

• 予算がゼロの場合。Cloudflareの無料版は十分に優秀です。
• すでにCloudflareを利用しており、稼働している場合。CoreDashを含め、何らかのツールに課金する前に、まずは表示される数値を確認してください。
• 主な目的がプライバシーに配慮した訪問数とページビューの把握で、Core Web Vitalsの確認はついででよい場合。そもそもその用途に向けて作られています。
• 小規模なサイトで、毎週パフォーマンスをデバッグする専任者がいない場合。Debug Viewの上位5要素を見れば、遅いヒーロー画像などをそのまま特定できることがよくあります。
• すでにCloudflare Pro以上を契約しており、field dataの隣でLighthouseテストも実行したい場合。Observatoryがそれを行います。

両方を並べて試す

単純に両方動かしてみればよいのです。Cloudflareは無料ですし、CoreDashにはクレジットカード不要の14日間無料トライアルがあります。同じサイトで2週間併用しても費用は一切かかりません。その上で最も遅いページを両方で開き、なぜ遅いのかをどちらが教えてくれるか確かめてみてください。事前にダッシュボードを確認したい場合は、CoreDashのデモを開き、トラフィックに応じた料金プランを確認してください。他のツールとの比較は比較ページに掲載しています。

出典: Web Analyticsの概要、Web AnalyticsにおけるCore Web Vitals、Web Analytics FAQ、制限事項、更新履歴、通知、RUMビーコン、Observatoryテスト、GraphQL APIの制限事項、Cloudflare MCPサーバー。