個人開発のGA4代替ツール：UmamiとCloudflareのコスト・機能比較

サービスを運用する立場から見ると、アクセス解析は本来「ユーザーの痛みを可視化する手段」。でも、その解析自体が新たな痛みを生んでいるなら本末転倒。軽量で、プライバシーに配慮があって、運用に時間を使わないツール。個人開発という文脈では、その三条件を満たす選択肢を本気で検証する価値がある。

本記事では、同じ「GA4からの脱却」を検討する個人開発者に向けて、UmamiとCloudflare Web Analyticsという二つの軽量解析ツールを、コスト・機能・運用の三軸で深掘りしていく。

GA4から脱却する理由：個人開発における軽量解析の重要性

2023年7月、Google アナリティクスの旧バージョン（UA）からGA4への完全移行が完了した。高機能化、機械学習の統合、プライバシー対応——どれも大規模サイトの運用を前提に据えた進化であり、方向性としては正しい。

ただ、個人開発という文脈では事情が大きく変わる。

第一に、スクリプトの重さ。GA4のタグ（gtag.js）はページのレンダリングを阻害するレベルの処理負荷を持つ。gzip圧縮後でも約35〜40KBのスクリプトを読み込み、さらに数十ミリ秒規模のメインスレッド占有時間が発生する。個人開発で扱うトラフィックはそれほど多くない分、コンバージョン1件あたりに占める「重さのコスト」が相対的に大きくなる。Core Web Vitalsの改善施策を回していても、解析タグそのものが足を引っ張る矛盾がここにある。

第二に、UIの複雑さ。GA4の管理画面は確かに高機能で、探索の自由度が高い。けれど「昨日のPVを確認する」「特定記事の流入経路を分解する」だけでも、複数のメニューを跨ぐ必要がある。デフォルトのレポートでは答えが出ず、探索モードでディメンションと指標を自分で組み合わせる必要がある場面も多い。限られた運用時間で回す立場から見ると、目的と手段が逆転している感覚が否めない。

第三に、プライバシー対応の負担。GA4はクッキーを使った計測が基本で、近年はEU圏を中心に規制強化が進んでいる。EU圏へのサービス展開がなくても、トラフィックにEU圏ユーザーが含まれるだけで対応を検討せざるを得ない。日本国内でも、同意バナーの実装が事実上の必須になりつつある。個人開発の工数で、ここまで対応し続けるのは骨が折れるのが現実。

第四に、データの所有権の問題。GA4で蓄積したデータはGoogleのサーバー上に存在し、長期的なデータ保持ポリシーはGoogle側で変更されうる。以前のUAでは無制限だったデータ保持が、GA4では最大14ヶ月に短縮されたことも記憶に新しい。個人開発者が自分のサービスの長期トレンドを追い続けるうえで、データの所在と保持ポリシーを他社に委ね続けるリスクは無視できない。

つまり、軽量・簡単・プライバシー配慮の三拍子が揃った解析ツールこそ、個人開発の現場に必要とされている。

解析は「測るための仕組み」ではなく、「プロダクトを改善するための手段」であるべき。手段が目的を食わない設計思想が、個人開発には求められる。

Umami：セルフホスト可能なプライバシー重視の解析ツール

まず注目したいのがUmamiだ。

UmamiはMITライセンスで提供されているオープンソースのアクセス解析ツールで、計測スクリプトはgzip圧縮後約2KBと非常に軽量。GA4の約35KBと比較すると、その差は一目瞭然。クッキーを一切使わずにアクセスデータを収集する——この一点で、GA4とは設計思想が根本から異なる。

セルフホストとSaaS、二つの運用スタイル

Umamiには大きく二つの使い方が用意されている。

一つ目がセルフホスト。Docker Composeで自前のサーバーに設置し、PostgreSQLまたはMySQLと組み合わせて運用する構成が一般的だ。典型的な構成は、UmamiのアプリケーションコンテナとDBコンテナの2つをDocker Composeで立ち上げ、NginxまたはCaddyでリバースプロキシを挟む形になる。最低限のVPS（1vCPU・1GBメモリ程度）でも動作し、数百円〜千円台の月額で運用できるケースが多い。

データベースを含む完全なコントロールが手に入る。データが一切外部に出ないため、機密性の高いサービスでも安心して回せる。PostgreSQLを使う場合、データ量が膨らんでもパフォーマンスチューニングの余地が大きい。

ただし「サーバー代が必ずゼロ」とまでは言い切れない。VPSを借りる以上、月数百円〜千円程度のインフラコストは見ておきたい。加えて、OSのセキュリティアップデートやDBのバックアップ運用も自分自身で回す必要がある。DockerやLinuxの基本操作に不慣れな場合は、その学習コストも含めて考える必要がある。

二つ目が公式のSaaS版、Umami Cloud。無料Hobbyプランでは月間10万イベントまで計測可能で、3サイトまで登録できる。個人開発のスモールサービスであれば、まずこの無料枠で検証を完結できる規模感。サーバー運用を他者に任せたい場合、最もラクな選択肢になる。

有料プランもあり、イベント数・サイト数の上限をさらに引き上げられる。複数サービスを横断的に管理する個人開発者であれば、有料プランのコスパも悪くない。

機能面でカバーしている範囲

Umamiは、GA4で「あたり前」となっている機能の多くを備えている。具体的には以下の通りだ。

• カスタムイベントのトラッキング（ボタンクリック、フォーム送信、特定のCTA表示など）。JavaScript SDKまたはAPI経由でイベントを送信でき、GA4のgtag.jsに慣れている人間なら違和感なく移行できる
• UTMパラメータのトラッキング。流入元の分解が標準ででき、キャンペーン効果の測定にも対応
• ファネル分析・コンバージョン目標の設定。複数ステップにまたがるユーザーフローの可視化が可能
• リアルタイム訪問者数、直帰率、平均滞在時間の確認
• デバイス別・ブラウザ別・国別のセグメント表示

UIはシンプルで、昨日のPV・ユニーク訪問者数・平均滞在時間が一目で確認できるダッシュボードが開く。GA4のホーム画面に表示される「ユーザー数」「セッション数」「エンゲージメント率」に相当する主要指標が、トップレベルに整理されている。

「GA4を開くのが億劫」だったユーザーにとって、この軽快感は想像以上に効く。目的別に最短距離で数字にたどり着ける設計思想が、体感できるレベルで違う。

プライバシー設計と信頼性

クッキーレスであることはもちろん、IPアドレスの匿名化やEU圏のGDPRを意識した設計が標準で組み込まれている。個人開発で同意バナーの実装に頭を悩ませる必要がないのは、精神衛生上の安心感が大きい。

オープンソースのためコードの透明性が高い。GitHub上でソースコードが公開されており、実際にどのようなデータをどう収集しているかを誰もが確認できる。サービスが大きくなり「自前で全部コントロールしたい」となったときに、フォークして独自運用に踏み切る選択肢も残っている。将来の拡張性を担保しておきたい視点から見ると、これは見逃せないポイント。

Cloudflare Web Analytics：エッジで完結する完全無料の計測環境

もう一つの有力候補が、Cloudflare Web Analyticsだ。

2020年に提供が始まった、Cloudflare謹製の解析サービスで、最大の特徴はCloudflareのDNSまたはプロキシを使っている場合、JavaScriptコードを自前で埋め込まずに自動有効化される点。CDNエッジで計測処理が完結する設計になっており、従来の解析ツールのようにブラウザ側で重いスクリプトを走らせる構造とは一線を画す。

コスト構造の特殊性

利用料金は完全無料。CloudflareのFreeプランを含む全ユーザーが、追加コストなしで利用できる。月間イベント数の上限も明示されておらず、トラフィックが増えても追加料金が一切発生しない。

個人開発者にとって「サーバーの維持費を削りたい」というモチベーションは切実。Cloudflare Web Analyticsは、その文脈で最強の選択肢になる。DNSをCloudflareに向けるだけで「コストゼロ・運用ゼロ・計測スタート」という状態が成立する。Umamiのセルフホストで必要なVPS代や、Cloud版の有料プランアップグレードといった検討事項が、最初からない。

RUM方式でパフォーマンスも同時に測れる

Cloudflare Web AnalyticsはRUM（Real User Monitoring）方式を採用しており、ページビューや訪問者数に加えて、Core Web VitalsなどのWebパフォーマンス指標を自動で計測してくれる。具体的にはLCP（Largest Contentful Paint）、FID（First Input Delay）に代わるINP（Interaction to Next Paint）、CLS（Cumulative Layout Shift）といった指標を継続的に定点観測できる。

個人開発者が表示速度の改善施策を回す際、PageSpeed InsightsやLighthouseで一度だけ計測するだけでなく、実ユーザーの実際のパフォーマンスを継続的に把握できるのは心強い。施策前後の比較データが自然と蓄積される仕組みは、GA4のCore Web Vitalsレポートを代替するうえでも十分に機能する。

プライバシー設計

クッキーもlocalStorageも、フィンガープリント技術も使わない。訪問者を個人単位で追跡するのではなく、集計値としてPV・訪問者数・滞在時間を返す。GDPRや各国のプライバシー規制への配慮が、ツールの前提に組み込まれている。

同意バナーの表示不要という点ではUmamiと同じだが、Cloudflareは追跡の仕組み自体を排除している設計思想がより徹底している。個人開発のフロントエンドをシンプルに保ちたい場合、この思想の一貫性は大きなメリットになる。

導入の実際

CloudflareをDNSとして使っている場合、計測は自動で有効化される。ダッシュボードの「Analytics」タブから「Web Analytics」を選択し、対象のドメインを追加するだけだ。Cloudflareのプロキシ（オレンジの雲アイコン）が有効であれば、追加のスクリプト埋め込みは不要。

もしCloudflareをDNSだけ使っている場合（グレーの雲アイコン）でも、計測用のスニペットをHTMLのhead内に一行追加するだけで対応できる。この場合のスクリプトサイズは約1KB前後と、Umamiよりもさらに軽い。

限界と注意点

一方で、いくつか割り切らなければならないポイントもある。

• カスタムイベントのトラッキングは非対応。ボタンクリックやフォーム送信といったイベント単位の計測は基本的にできない
• UTMパラメータの分解、ファネル分析、コンバージョン設定はサポート外
• データ保持期間に制約があり、30日〜6ヶ月程度、利用規模によってはデータのサンプリングが発生する可能性

「全体傾向の定点観測」と「Core Web Vitalsの継続監視」に強みを持つツールと理解しておく必要がある。あくまでイベント単位の深い分析は、別途ツールを組み合わせる前提になる。

機能と運用の比較：カスタムイベント計測とインフラコストの境界線

両者を横並びで整理する。

この表を見れば一目瞭然で、機能重視ならUmami、コスト・パフォーマンス重視ならCloudflare Web Analyticsという構図になる。

コストと運用の境界線

Umamiのセルフホストは、VPSのランニングコストが発生する。月数百円〜千円程度が現実的なラインで、PostgreSQL/MySQLの運用保守も自分で回す覚悟が必要。一方、Umami Cloudの無料Hobby枠で収まるなら、運用負荷・コストともに最小化できる。10万イベントという上限は、個人開発の初期フェーズであれば十分な規模だ。

Cloudflare Web Analyticsは、コストが本当にゼロ。サーバー運用もデータベース管理も不要で、DNSをCloudflareに向けるだけで計測が始まる。ただし、データ保持期間に制約があり、長期トレンド分析より「最近の動きをクイックに確認する」用途に向きやすい。サンプリングが発生する正確なアクセス規模のしきい値は公開されていないため、大量トラフィックを扱う場合は要注意。

機能の境界線

Umamiはカスタムイベント・UTM・ファネル分析を通じて、ユーザーの行動ログを積み上げられる。仮説 → 検証のループを回すための土台が揃う。「この流入経路からのユーザーはどのボタンを押しているのか」「コンバージョンに至ったユーザーはどこで最初につまずいているのか」といった問いに、データで答えられる段階に初めてたどり着ける。

一方、Cloudflare Web Analyticsはページ単位の集計値を返すのみで、ボタンクリックやフォーム送信といったイベント単位の計測は基本的に非対応。「どのページが見られているか」「サイト全体のパフォーマンスはどうか」という俯瞰的な情報が主軸になる。

コンバージョン改善を回し続ける段階ではUmami一択。逆に、表示速度の定点観測と大まかな流入把握だけで十分なら、Cloudflare Web Analyticsが圧倒的にラク。

軽量ツールは「GA4の劣化コピー」ではなく、個人開発という文脈での最適解。重さと複雑さを手放す代わりに、本当に必要な数字に集中できる設計が手に入る。

プロジェクトの規模と目的で選ぶ解析ツールの最適解

ここまでの比較を踏まえて、自分の運用で得た選定基準をまとめておく。

スモールスタートで「数字に慣れる」段階

個人開発を始めたばかりで、まだアクセスがほとんどない段階。Cloudflare Web Analyticsで十分。DNSをCloudflareに移すだけで計測が始まるので、初期設定の手間がほぼゼロ。「自分のサービスに人が来ている」という事実を、まず数字で確認するフェーズ。ここではイベントの細分化より、「今日何人来たのか」「どのページが見られているのか」がわかれば十分。

加えて、Core Web Vitalsの自動計測は、開発初期のパフォーマンスチューニングにそのまま活用できる。サービスの土台を固める段階でパフォーマンスの定点観測ができるのは、GA4では得られなかった副次的なメリットになる。

ユーザーフローやCV改善を回したい段階

サービスが軌道に乗り始め、コンバージョン率を改善したくなってきた段階。Umamiの出番だ。UTMで流入経路を分解し、コンバージョンに至ったユーザーの行動パターンを観察する。仮説 → 検証のループを回すための土台ができる。

具体的に言うと、「申し込みボタンのクリック率を測りたい」「特定の流入経路からの離脱率を可視化したい」といった要望が出てきたタイミング。Cloudflare Web Analyticsだけでは、ここまでの解像度は得られない。

この段階で、Umami Cloudの無料Hobby枠が上限に近づくかどうかが判断の分かれ目になる。月10万イベントを超える見通しがあれば、有料プランへの移行かセルフホストへの切り替えを検討する時期だ。

長期トレンドと短期KPIを分けて運用する

理想は、両方を併用する構成。Cloudflare Web Analyticsでサイト全体のパフォーマンスと大まかな流入を定点観測しつつ、Umamiで施策単位の行動分析を回す。Cloudflareは無料だから「常時ON」、Umamiは「分析フェーズだけ深掘り」と役割を分けることで、コストと機能のバランスを取れる。

データ保持期間の長さはUmami側に集約し、Core Web Vitalsの定点監視はCloudflare側に任せる——この棲み分けが、個人開発の限られたリソースを最大限に活かす構成になる。

選ぶ基準を一文でまとめると

「コストゼロで全体傾向を測りたいならCloudflare Web Analytics、行動ログを積み上げて改善を回したいならUmami」。この軸で迷うことは、まずなくなる。

次に試したいこと

最後に、自分自身が今後回していく検証をまとめておく。

• Umami CloudのHobbyプランで複数サイトを横断的に分析し、無料枠のリアルな限界値を測る
• Cloudflare Web AnalyticsのCore Web Vitalsを起点に、表示速度改善の優先順位を整理する
• 両ツールの数値を1ヶ月並走させ、「見えている数字」「見えていない数字」を比較検証する
• セルフホスト版Umamiを軽量VPSで運用し、実質的な月額コストと運用工数を確定させる
• GA4から完全移行した状態で、コンバージョン率とユーザー満足度にどんな変化が出るかを観察する

GA4から離れることは、数字を手放すことではない。むしろ個人開発にとって、本当に必要な数字にだけ集中できる環境を整えることだ。スクリプトの重さ、UIの複雑さ、プライバシー対応——その三つを同時に解決できる軽量ツールは、これからの個人開発の定番になっていくはずだ。