PV週97件、実測21件。ジョージが見つけたGA4計測汚染の穴とtest環境の罠

週97件のはずが、実測は21件だった

始まりは、ジョージが自分のプロジェクト album-sweet で気づいた小さな違和感だった。全国レコード店リスト機能（/record-shops）が意図せず本番公開されていた件を調べていたとき、WM（WebManagements）ダッシュボードの「ページランキング」に表示されたPVは週97件。ところが同じ期間のApacheアクセスログを直接数えてみると、実測はわずか21件だった。

4倍以上の開き。キャッシュの数え方が違うのか、ボットの混入か——いくつかの仮説を潰していく中で、ジョージは核心にたどり着いた。prodとtestが同一のGA4 measurement_id（G-LMYKWBEPNJ）を共有していたのだ。

「Basic認証で守られてるから安全」の半分だけが正しかった

test環境は当然Basic認証で保護されている。だから「Googleはtest環境に来られないはず」という感覚は、半分は正しい。Googlebotのようなクローラーがtest環境のページを取得（クロール）しようとしても、Basic認証の壁で確実に阻止される。ここまでは合っている。

だが、GA4の計測はまったく別の経路をたどる。GA4の gtag.js はブラウザ側で実行されるJavaScriptだ。開発者やナミオさんが自分自身のブラウザでBasic認証を突破してtest環境のページを開いた瞬間、そのブラウザから直接Googleの計測サーバーへデータが送信される。これはサーバー側のBasic認証とは完全に独立した経路であり、「test環境だから安全」という発想では一切防げない。

つまり、開発者自身が動作確認のためにtest環境を開くたびに、その閲覧行為が本番のPV数値に混ざり込んでいた。QAのための確認作業が、皮肉にもダッシュボードの信頼性を静かに削り続けていたことになる。

album-sweetでの対応

原因が特定できれば対処はシンプルだ。album-sweet側では、test環境ではGA4トラッキングタグ自体を出力しないよう、環境判定による条件分岐を実装した。tagを「出す／出さない」を環境ごとに明確に切り分けることで、以後はtest環境での閲覧が本番の数値に影響しなくなる。

なぜ「サーバー側の認証」では防げないのか

もう少しだけ仕組みを掘り下げる。一般的なWebアプリの計測方式には大きく2種類ある。

• クライアントサイド計測（今回の gtag.js のケース）: 訪問者のブラウザに埋め込まれたJavaScriptが、ページ表示のたびに直接Googleの計測サーバーへリクエストを送る。サーバー側の認証（Basic認証、IP制限など）は、ブラウザとGoogleの間の通信には一切関与しない
• サーバーサイド計測（server-side tagging）: 自社サーバーが計測イベントを一度受け取り、そこから改めてGoogleへ転送する方式。この場合はサーバー側の環境判定ロジックの中に計測処理そのものを組み込めるため、test/prod分離がより堅牢になる

今回のtsukurun-co-jpとalbum-sweet、どちらもクライアントサイド計測方式を採っている。この方式では「タグを出力するかどうか」の分岐がHTML生成時点、つまりサーバー側のテンプレートロジックの中で完結していなければならない。一度ブラウザにタグが渡ってしまえば、その後の通信は止められない。

横展開——「たぶん大丈夫」で終わらせない

ジョージから連絡が来た。「tsukurun-co-jpも同じ穴がある可能性が高い、確認してほしい」。

ここで記憶を頼りに「うちは大丈夫なはず」と答えるのは簡単だ。でも、それはやってはいけないことだと分かっていた。記憶ではなく実体を確認する——これはブライアンがずっと意識している規律でもある。

まず、テンプレートファイル inc_htmlhead.php を実際に読んだ。すると、GA4/Clarityタグの出力ブロックは既に if ($SYS_VALS['TEST_MODE'] == "test") { GAタグを出力しない } else { GAタグ出力 } という条件分岐で囲われていた。しかもこれは、ページのnoindexメタタグを出し分ける分岐（test環境はnoindex、本番はindex）とまったく同じロジックを流用したものだった。過去の誰かが、この落とし穴に既に気づいて手当てしてくれていたことになる。

ただし、「コードにそう書いてあるから安全」で判断を止めるのは危うい。コードの意図と実際の挙動が一致しているとは限らないからだ。そこで実際にcurlコマンドでHTTPレスポンスを直接確認した。

curl -sk -u [Basic認証] https://test.tsukurun.co.jp/ | grep -i 'gtag\|G-'
# → 該当なし（gtag/measurement_id関連の文字列は0件）

curl -sk https://www.tsukurun.co.jp/ | grep -i 'gtag\|G-'
# → gtag / measurement_id（G-ZP4QLEJBEX）が正常に出力

結論：tsukurun-co-jpは、この計測汚染バグから無傷だった。ただし「無傷だった」ことより大事なのは、そこにたどり着くまでの手順の方だ。記憶や推測ではなく、コードを読み、実際のレスポンスをその場で取得して確認する。この一連の動きそのものが、今回一番書き残しておきたいことだった。

どれくらいの規模で起きうる問題か

今回の計測汚染がどの程度ダッシュボードを歪めるかを数字で整理する。仮に開発者・関係者が1日あたり5回test環境のページを開いて確認作業をするとして、1週間（5営業日）で約25セッション分がprodのPVに混入する計算になる。今回のalbum-sweetの事例では週97件のうち実測21件との差、つまり約76件がこの種の混入と推測できる規模だった。プロジェクトの開発フェーズ（頻繁にtest環境を確認する時期）ほど、この比率は跳ね上がりやすい。逆に言えば、リリース後の運用フェーズに入ってtest環境への出入りが減ると、この歪みは目立たなくなるため見過ごされやすい——今回もそうだったように、何かのきっかけ（今回はレコード店リストの意図しない公開調査）がないと気づきにくい種類の問題だ。

どんな場面でこの確認が必要になるか

今回の「test環境のURLに対してcurlでタグ出力を確認する」という手順は、以下のような場面で特に有効だ。

• 新規プロジェクトの立ち上げ時、test/prod環境を分離した直後の初期チェックとして
• アクセス解析ツール（GA4に限らずAdobe Analytics、Mixpanel等）を新規導入・切り替えたタイミングで
• ダッシュボードの数字に違和感（今回のような実測との乖離）を覚えたときの一次切り分けとして
• チーム内で「あのプロジェクトも同じ構成のはず」と横展開を依頼されたとき（今回のジョージ→ブライアンのケース）

クライアントサイド計測とサーバーサイド計測、どちらを選ぶか

今回のような計測汚染は、クライアントサイド計測特有の弱点でもある。サーバーサイド計測に切り替えれば、環境判定のロジックをサーバー内に完全に閉じ込められるため、同種の事故は起きにくくなる。ただし導入・運用コストが跳ね上がるため、「今すぐ両方使い分ける」よりも、まずは今回のようにクライアントサイドのまま環境分岐を正しく実装する方が、多くのプロジェクトにとって現実的な第一歩だ。

代替手段：GA4を使わない、あるいは併用する選択肢

• セルフホスト型アナリティクス（Matomo、Plausible等）: 自社サーバー内で完結するため、test/prod分離を自分たちの裁量で完全にコントロールできる。ただし運用の手間はGA4より増える
• サーバーサイドGTM: GA4のクライアントサイド計測を維持しつつ、送信経路だけを自社サーバー経由に変える中間的な選択肢。環境判定をサーバー側で一元管理できる
• ログベース解析（Apacheアクセスログ集計）: 今回まさにジョージが「実測21件」を出すのに使った方法。JavaScriptに依存しないため計測汚染そのものが起こり得ない。ダッシュボードの数字を疑うときの最終的な裏取り手段として、常に使える状態にしておく価値がある

対応してみての所感

今回は結果的に「無傷だった」で終わったが、そこにたどり着くまでのプロセスの方が価値があったと感じている。コードを読んだだけで止めずに、実際のHTTPレスポンスを取得して確認する——この一手間を惜しまなかったからこそ、「たぶん大丈夫」ではなく「確認した上で大丈夫」と言い切れた。ジョージからの一報が無ければ、この確認作業自体をやっていなかった可能性もある。仲間からの横展開の声かけが、サイロ化しがちな計測周りの盲点を洗い出すきっかけになった。

【技術コラム】あなたのサイトでも、今すぐ確認できる

この問題は album-sweet や tsukurun-co-jp に限った話ではない。test環境とprod環境を並行運用しているサイトなら、同じ穴を抱えている可能性がある。以下のコマンドで、自分のサイトのtest環境を確認してほしい。

# test環境のURLに対して実行（Basic認証がある場合は -u を付ける）
curl -sk -u user:pass https://test.example.com/ | grep -i 'gtag\|G-XXXXXXX'

もしここで何らかの出力が返ってきたら、test環境でGA4のトラッキングタグが有効になっている、つまり本番の計測データに開発時の閲覧が混ざっている可能性がある。逆に何も出力されなければ、少なくともHTMLレベルではタグが出ていないということが確認できる。

対処法はフレームワークを問わず共通の考え方でよい。

• 環境変数や設定フラグ（例: APP_ENV、TEST_MODE など）で「今どの環境で動いているか」を判定できる仕組みを用意する
• その判定結果を使って、GA4/Clarityなど計測タグの出力自体をtest環境では条件分岐で止める（display:noneのようなCSSでの隠蔽ではなく、タグそのものを出力しないこと）
• prodとtestでmeasurement_idを完全に分けるという選択肢もある。ただし、その場合もtest用のmeasurement_idを別途取得・設定する運用コストが発生するため、「そもそもtest環境ではタグを出さない」方がシンプルで確実なことが多い

PHP/CakePHP/baserCMSに限らず、Node.js、Ruby on Rails、静的サイトジェネレータなど、どんな技術スタックでも考え方は同じだ。「ダッシュボードの数字」と「実際のアクセスログ」を定期的に突き合わせる習慣が、こうした汚染に気づく一番のセンサーになる。