結論
GA4 タグを一度埋め込んでも、ルールがなければ将来のページ追加で簡単に計測漏れが起きます。本記事では、実装そのものよりも 運用ルールの明文化と同期運用 に焦点を当て、再発防止の土台を整える方法を紹介します。
背景
BaseLayout.astro への GA4 タグ導入が完了した後も、この状態だけでは次のリスクが残ります。
- 新規ページが BaseLayout を経由しない
- gtag スニペットに
is:inlineを付け忘れる - ルールが人の記憶依存になり、セッション跨ぎで抜ける
つまり「実装がある」ことと「運用で守られる」ことは別問題です。計測ルールを明文化し、参照ポイントを統一することで、この問題を解決できます。
実施したこと
1. GA4 計測ルールの新規作成
プロジェクトのルールファイル(AI エージェントやチームメンバーが参照する共通ルール置き場)に計測ルールを追加し、次の内容を明記します。
- 全ページで GA4 を計測する
- 測定 ID は
G-201H02XFR5 - GA4 タグは
BaseLayout.astroの<head>に集約する - Astro の gtag スニペットは
is:inlineを付ける - BaseLayout を使わない場合は個別埋め込みを必須にする
このルールで「どこに書くか」「どう書くか」「例外時はどうするか」を一枚にまとめられます。
2. ルール同期対象ファイルを同時更新
AI エージェントを複数使い分けている場合、ルールの変更時に関連する設定ファイルも同時に更新する必要があります。今回は次の 4 ファイルも同時に更新し、参照先を揃えました。
AGENTS.mdCLAUDE.md.cursorrules.github/copilot-instructions.md
ルール本文だけ更新して参照先を放置すると、エージェントごとに認識差が出るため、ここは必須作業です。
なぜ効くのか
実装ルールを「人」ではなく「ファイル」に固定できる
「新規ページは BaseLayout 必須」のようなルールは、口頭運用だとすぐ崩れます。明文化して参照箇所を統一することで、レビュー時にも機械的に確認できるようになります。
変更時のトレーサビリティが上がる
ルール変更を Issue と PR を起点に管理すると、どのタイミングで何を決めたかを追えるようになり、後から計測異常が出たときの調査コストも下がります。
まとめ
計測ルールの明文化は小さなドキュメント変更に見えますが、実際には GA4 計測品質を守るための運用改善です。実装は一度で終わっても、運用は継続して壊れます。だからこそ、ルールの所在と同期手順を明示しておくことが重要です。
今後は PUBLIC_GA_MEASUREMENT_ID への段階移行も進め、環境ごとの計測切り替えを安全に扱えるようにしていきます。
関連記事
- Astro サイトに GA4 を導入する方法 — GA4 タグの導入手順と is:inline の注意点を解説
- GitHub Project の Workflows 自動化を設定した話 — Issue のライフサイクル管理を自動化した設定手順