技術ブログの計測にGA4ではなくCloudflare Web Analyticsを選んだ理由

結論から

tech.rebounder.jp はこのブログ自身のアクセス解析に Google Analytics 4（GA4）を入れていない。 代わりに Cloudflare Web Analytics だけで PV を測っている。理由は最初から明文化されていて、AdSense と二重に Core Web Vitals を削らないこと、Cookie 同意まわりの記載を増やさないことの2点だった。

ただし「設計書に書いてある」と「実装されている」は別で、この方針を決めてから実際にタグが入るまで2日かかり、その間のアクセスは記録されずに消えた。

なぜ GA4 を入れないのか

設計時点でこのブログの技術スタックは決め打ちされていて、ホスティングは Cloudflare Pages（無料枠で商用利用可）、計測は Cloudflare Web Analytics（Cookie 不要）と最初から書かれている。同じ設計書には「使わないもの」として Vercel（Hobby プランは商用利用不可）と Google Analytics が並んで挙げられている。

GA4 を入れない理由は3つ書かれている。

1. AdSense の広告スクリプトと GA4 のタグを両方読み込むと、Core Web Vitals（表示速度や体感の軽さを表す指標）を二重に削ることになる
2. GA4 は Cookie を使うため、Cookie 同意バナーの記載を増やす必要が出る
3. この規模のブログでは、細かい行動分析が意味を持つほどのトラフィックがない。副業ブログでの実体験として、計測タグを6本に分けて細かく分析しようとしても、Amazon 側が少量データを伏せてしまい結局読めなかったことがある

Cloudflare Web Analytics は Cookie を使わずに計測できる分、この3点と正面から噛み合う。

ホスティングも同じ理由で決まっていた

計測だけでなくホスティング先も、同じ「商用可・無料枠」という基準で決まっている。Vercel の無料枠（Hobby）は商用利用を許可していない。広告とアフィリエイトで収益化する前提のブログを Vercel で運用するなら、有料プランに上げる必要がある。Cloudflare Pages の無料枠は商用利用を制限していないため、この制約を踏まずに済む。

もう一つ気づいたのは、このブログのように完全に静的出力（JS ゼロ）なプロジェクトなら、Cloudflare Pages 用のアダプタパッケージすら要らないということだった。Astro の設定ファイルには @astrojs/cloudflare のようなアダプタの import が無く、defineConfig にも adapter の指定が無い。package.json の依存関係にも Cloudflare 専用のパッケージは入っていない。ビルドが吐く dist フォルダをそのまま Cloudflare Pages の Git 連携がデプロイするだけで完結する。

決めたのに、2日分のアクセスが消えた

設計書には計測方針が2026-08-15の時点で書かれていた。だが実際に本番の HTML に Cloudflare Web Analytics のビーコンタグが入ったのは2026-08-17で、2日のラグがあった。 その間、公開されていたページへのアクセスはどこにも記録されずに消えている。あとから取り戻す方法はない。

原因は単純で、「設計書に書いた」ことと「本番の HTML にタグが出力されている」ことは別の事実だという点を、確認する手段を用意していなかったことだった。目視で「書いてあるから入っているはず」と思い込んでいた。

この経験のあと、ビルド後の dist を機械的に検査してタグの有無を確認するチェックをビルド工程に足した。以後は人が見なくても、タグが抜けていればチェックが落ちる。

トークンをコードに直書きしている理由

計測タグの data-cf-beacon に入る識別用トークンは、環境変数ではなくソースコードに直接書かれている。これは意図的な判断で、理由が2つある。

1. このトークンは HTML に出力される時点で誰でも見える公開情報であり、秘匿する意味がない
2. 環境変数にしてしまうと、ビルドやスケジュールタスク側でその変数の受け渡しが欠けたときに、エラーも出さずに計測が無言で止まる。直書きにしておけば、その失敗の経路自体が存在しない

環境変数を経由させる設計は「値を外から差し替えられる」という利点と引き換えに、「渡し忘れると静かに壊れる」という経路を必ず持ち込む。公開情報を渡すためだけにその経路を作るのは割に合わない、という判断だった。

広告ローダーとの整合性

このブログには AdSense の広告枠もあるが、広告ユニットの ID を1つも設定していない状態では AdSense のスクリプト自体を読み込まないようにしている。理由として書かれているコメントは明快で、広告を出さないのに Google のスクリプトだけ動かすと、1円にもならない Cookie を読者に置くことになり、Cloudflare Web Analytics を選んだ理由と矛盾する、というものだった。

実際、AdSense は2026-08-16 に申請し、8月下旬までに「有用性の低いコンテンツ」という理由で却下されている。承認されるまでは広告ユニットの ID が空のままなので、このロジックにより広告スクリプトは今のところ一切読み込まれていない。「使う理由」だけでなく「使わない理由」も同じ基準で判断している、という一貫性がここに表れている。

まとめ

計測やホスティングの選定は、機能の比較表だけで決まるものではなかった。「収益化前提の個人・小規模事業のブログで、無料枠のまま商用利用でき、余計な Cookie を増やさない」という基準を先に固定したことで、GA4 ではなく Cloudflare Web Analytics、Vercel ではなく Cloudflare Pages という組み合わせが素直に決まった。

一方で、**方針を決めることと、それが実装に反映されていることの間には必ずラグがある。**このブログでは2日分の実測データを失って初めてそれに気づいた。同じ構成を検討している場合、決めた方針が本番の HTML に実際に出力されているかを、目視ではなく機械的に確認する手段を先に用意しておくことを勧める。