[🛠] GitHub Pagesブログに訪問者カウンターを付ける

✨ GPT-5.5の要約 　

静的なGitHub Pagesブログに無料枠のCloudflare WorkerとD1をつなぎ、既存のGA累積値を活かしながら、今日の訪問数と記事別の閲覧数を表示できるようにした記録。

ブログに訪問者カウンターを付けたくなった。

機能そのものがすごいからではない。むしろ逆だ。あまりにも当然の機能のように感じるのに、GitHub Pagesで作った静的ブログには自然には付いていなかった。

Google Analyticsはすでに入れてあった。運営者である自分はGAに入れば訪問者数や閲覧数を見られた。けれどそれは、ブログの中に見える数字ではなかった。訪問者は、このブログが今日も読まれているのか、最近の記事がどれくらい読まれているのかを知ることができない。

Naver Blogのように、今日、累計、記事別閲覧数が小さく見える感じが欲しかった。見栄のための数字というより、ブログが死んだ静的ページではなく、今も読まれ続けているという信号に近かった。

だから問題は単純だった。

無料の静的ブログという利点は保ったまま、訪問統計だけを本当に小さく動的に付けられないだろうか？

まず条件を決めた

訪問者カウンターをひとつ付けるためだけに、構造が大きくなるのは嫌だった。

最初からいくつか条件を決めた。

• GitHub PagesとJekyllで書く流れは維持する。
• 有料サーバーは使わない。
• CloudflareでもFirebaseでも、無料枠の中で解決する。
• プロフィール付近に小さく付ける。
• モバイルでも変に長くならないようにする。
• ブログ全体の統計だけでなく、記事別の閲覧数も見せる。
• 既存のGA累積値を捨てない。

最後の条件が特に重要だった。

新しいカウンターを付けたからといって、閲覧数が0から始まるとおかしい。ブログはすでに運営中で、GAには以前から積み上がった閲覧数があった。とはいえGAだけを読み続けるのは、自分が欲しかったカウンターの感覚とは距離があった。

GAを読むだけで終わると思っていた

最初はGoogle Analytics APIを読めばいいと思っていた。

GAはすでにデータを持っているので、Cloudflare WorkerひとつがGA APIを呼び出して数字を返せばよさそうだった。実際にサービスアカウントを作り、GAプロパティに権限を付け、API呼び出しまではできた。

ところが実際に付けてみると、自分が欲しかったものとは違っていた。

GAは分析ツールだ。運営者があとから流れを見るにはよいが、ブログ画面ですぐ反応する訪問者カウンターとして使うには微妙だった。特に今日の数字が問題だった。自分が今入ったばかりなのに今日の値が0に見えると、訪問者からすればただ壊れているように見える。

また、指標名も紛らわしかった。active usersとpage viewsは別の値だ。訪問者数を厳密に取ろうとすると数字がかなり控えめに見え、page viewを使うと体感としては自然だが、名前には注意が必要になる。

結局、判断は単純だった。

GAは過去の基準値として使い、これから増えるカウントは自分で直接取ろう。

baselineと増分を分けた

最終的な構造はこうした。

公開閲覧数 = GA baseline + Cloudflare D1増分

GA baselineは、すでに積み上がっている数字だ。基準日を決め、その時点までの全体閲覧数と記事別閲覧数を保存する。

そのあとからはCloudflare Workerが直接カウントする。訪問者がブログに入るとJavaScriptがWorkerを呼び出し、WorkerはD1に今日/月/全体/page path別の増分を記録する。

整理するとこうなる。

既存の累積値: Google Analytics baseline
新しい増分: Cloudflare Worker + D1
公開API: Cloudflare Worker
ブログ表示: Jekyll include + JavaScript

この方式が気に入った理由は、どちらも捨てないからだ。

GAの既存データは活かす。同時に、これからのカウントはブログ画面ですぐ反応するようにする。

なぜCloudflare WorkerとD1だったのか

Firebaseも候補だった。けれどこの程度の機能には、Cloudflareのほうが単純だった。

GitHub Pagesは静的サイトなので、サーバーコードを置く場所がない。Workerはその空白を小さく埋めてくれる。D1はSQLiteベースなので、訪問者カウンターのような単純な数字の保存には十分だった。

費用条件にも合っていた。個人ブログの訪問者カウンター程度なら無料枠の中で処理できる。急にたくさんの人が来ればカウントが多少ぶれる可能性はあるが、記事そのものが壊れるわけではない。そもそもこれは決済システムでも金融台帳でもない。

自分が欲しかったのは正確な会計ではなく、ブログが読まれているという流れを見せることだった。

botと重複訪問はほどほどに防いだ

公開ページにカウンターを付けると、botも数字を増やせる。

完璧に防ぐのは難しい。そして厳しくしすぎると、かえって自分が欲しかったカウンターの感じから遠ざかる。自分はNaver Blogのように、ある程度ゆるめに数えられるほうを望んでいた。

そこでWorkerではいくつかだけ処理した。

• 明らかなbot user-agentは除外する。
• 同じ訪問者と同じページの組み合わせは、一定時間内には再び数えない。
• 記事別閲覧数も同じ方式で、path基準の増分を積み上げる。

つまり、厳密な分析ツールではなく、公開用の訪問カウンターに合わせた。

画面には小さく付けた

最初は統計を複数の枠で見せようとした。けれどプロフィール横に入るUIは小さくなければならなかった。数字が多くなると、むしろブログの最初の画面が散らかった。

だから最終的に残したのは三つだ。

今日 / 月 / 合計

今日は今ブログが読まれている感じを出す。月は最近の規模感を見せる。合計はブログが積み上げてきた時間を見せる。

記事一覧には、各記事ごとに閲覧数を付けた。

閲覧数 10回

この値も全体統計と同じ構造だ。

記事別閲覧数 = GA記事別baseline + Cloudflare D1記事別増分

たとえば、ある記事がGA基準で9回閲覧されている状態で、新しいカウンターに切り替えたあとにもう1回読まれたなら、画面には10回と表示される。

これがいちばん自然だった。過去の閲覧数は捨てず、これからの閲覧数はすぐ積み上がる。

結果

結果として、ブログのプロフィール付近にはこういう数字が付いた。

今日 1 / 月 66 / 合計 4,944

そして記事一覧には、こういう形で閲覧数が付く。

閲覧数 10回

機能ひとつだけを見ると小さい。けれどこの作業はかなり気に入っている。

問題は明確だった。GitHub Pagesブログには訪問者カウンターがなかった。GAはあったが、公開画面のカウンターとしては足りなかった。とはいえ、ブログひとつのためにサーバーを大きく作りたくもなかった。

だから既存のGAデータはbaselineとして活かし、Cloudflare WorkerとD1でそれ以降の増分だけを直接数える構造を付けた。

静的ブログの利点はそのまま残した。Markdownで記事を書き、GitHub Pagesで配信し、維持費はほぼ0円に近い。その代わり、本当に足りない部分にだけ小さなサーバーレスの部品を載せた。

あとでこのブログをポートフォリオのように見せる機会があれば、こういう作業のほうがむしろ説明しやすい気がする。大げさな機能ではないが、実際の不便から出発し、費用と複雑さを制限し、運用できる形まで最後に付け切ったからだ。