Showing Posts From

Ga4

ノンエンジニアのClaude Code奮闘記 #7 アクセス解析に自分の足跡が混ざっていた話——「本番」と「確認用」を分けるまで

ノンエンジニアのClaude Code奮闘記 #7 アクセス解析に自分の足跡が混ざっていた話——「本番」と「確認用」を分けるまで

はじめに こんにちは、広報・制作担当のmeraです。 #6 CLAUDE.mdを育てる編の最後で、「次回は失敗した話を書く」と予告していました。 今回はその約束どおり、正直にちょっと恥ずかしい話をします。 事の発端は、ある朝アクセス解析(GA4)を眺めていたときでした。「あれ……この記事、公開したばかりで、私しか見てないはずなのに閲覧数が増えてる?」嫌な予感がしました。調べてみたら案の定、犯人は私自身でした。この記事は数字の話が少し出てきますが、専門的な計測の話というより「本番と確認用を分ける」という考え方の話です。GA4を使っていない人にも、たぶん通じる内容だと思います。この記事で学べること「自分の閲覧」がアクセス解析に混ざってしまう典型的な原因 Claude Codeに「何が起きているか」を一緒に調べてもらった流れ 実際に直した「三段構え」の仕組み(専門用語なしで) 同じことに気づいたとき、自分でもできる確認の手順事件の発端: 増えているのは「読者」じゃなかった このブログでは、記事を公開する前に必ず自分の目で確認します。パソコンで下書きを表示して(yarn dev というローカル確認)、誤字や崩れがないか見る GitHubでプルリクエストを作ると、Firebaseが自動で「確認用のURL」を作ってくれるので、それを開いてスマホ表示も確認するこのルーティン自体は、#3の頃からずっとやっていました。 ただ、そのたびに自分がページを開いていることと、本番のアクセス解析が完全に別物だと、当然のように思い込んでいたのです。 実際は違いました。 確認のために開いていたページの閲覧も、律儀に本番のGA4レポートに記録され続けていたのです。気づいたのが遅く、この間のデータにはすでに私の閲覧が混ざってしまっています。GA4のデータフィルタは「これから先」を除外する仕組みで、過去にさかのぼって数字を消すことはできません。気づいたときが直しどきです。Claude Codeと一緒に「何が起きているか」を整理した 数字がおかしいことには気づいても、原因はまったくわかりませんでした。 こういうとき、私はまず状況を丸ごとClaude Codeに話すことにしています。 「アクセス解析の数字が、自分が見ているだけなのに増えている気がする。原因を一緒に調べてほしい」 そう頼むと、Claudeはブログのソースコードの中からアクセス解析のタグを埋め込んでいる箇所(Base.astro というファイルでした)を探し出し、何が起きているかを説明してくれました。 原因は、大きく2つありました。ローカルで確認しているとき(yarn dev)も、アクセス解析のタグがそのまま動いていた プルリクエストの確認用URL(〇〇.web.app のような、Firebaseが自動発行するアドレス)での閲覧も、本番と同じ扱いでカウントされていた「確認用」のつもりで開いていたページが、システムから見れば「本番」の閲覧と区別がついていなかった、ということです。 言われてみれば当たり前なのですが、自分では思いもよらない盲点でした。直した内容: meraの足跡を除外する「三段構え」 Claudeと相談しながら直した内容は、次の3つの層に分かれています。 一つひとつは難しくないので、順番に書きます。 1段目: ローカル確認では、そもそもタグを読み込まない 自分のパソコンで下書きを見ているとき(yarn dev)は、アクセス解析のタグ自体を動かさないようにしました。 「本番用のビルドのときだけタグを読み込む」という条件を1つ足しただけです。 config.google_analytics.enable && import.meta.env.PROD && ( // ここでアクセス解析のタグを読み込む )これで、ローカルで何回下書きを開いても、そもそも記録が飛ばなくなりました。 2段目: 確認用URLからのアクセスには「これは確認用です」という目印をつける プルリクエストの確認用URL(.web.app や .firebaseapp.com で終わるアドレス)からのアクセスだけを見分けて、「これはプレビュー(確認用)です」という目印をアクセス解析側に送るようにしました。 var isPreview = location.hostname.endsWith(".web.app") || location.hostname.endsWith(".firebaseapp.com");gtag("config", GA_ID, isPreview ? { traffic_type: "preview" } : {});ホスト名を見て「.web.appだったら確認用」と判断しているだけなので、やっていることは意外とシンプルでした。 3段目: GA4側で「確認用」を除外するフィルタを設定する 最後に、GA4の管理画面側で「traffic_type が preview になっているアクセスは、レポートから除外する」というデータフィルタを設定しました。 ここはコードではなく、GA4の管理画面をポチポチ操作する作業でした。層 何をしているか どこで設定するか1段目 ローカル確認ではタグ自体を読み込まない ブログのコード(Base.astro)2段目 確認用URLのアクセスに「preview」の目印をつける ブログのコード(同上)3段目 「preview」の目印がついたアクセスをレポートから除外する GA4の管理画面3段のうちどれか1つだけでも、だいぶマシにはなります。でも「ローカルは平気だと思ってた」「確認用URLも本番と同じ扱いだった」のように、思い込みの穴は複数あることが多いです。1つ直して安心せず、抜けがないか順番に確認するのがコツでした。この経験から学んだこと 今回いちばん学びになったのは、「本番」と「確認用」を最初から分けて考える、という設計の考え方でした。 私はこれまで、「確認のために見ているだけだから、数字には影響しないはず」と無意識に思い込んでいました。 でもシステムからすれば、確認用のページを開くことも、読者がページを開くことも、区別する仕組みがなければまったく同じ「1閲覧」です。 「区別する仕組み」を自分で用意しない限り、混ざって当然だったのです。 もう一つの学びは、Claude Codeへの相談の仕方でした。 「数字がおかしい気がする」という、原因もわからないふわっとした違和感のまま相談しても、#4で身につけた「まず状況を整理してもらう」頼み方が役に立ちました。 「原因を一緒に調べてほしい」と伝えると、Claudeが該当のコードを探し出して仕組みごと説明してくれる。 大きな仕組みも、こうやって一歩ずつ理解できるんだ、という実感がありました。同じことに気づいたら、まずやること 自分のブログやサイトで「なんか数字がおかしいかも」と思ったとき、私が今やっている確認手順です。 Step 1: リアルタイムレポートを見ながら、自分でページを開いてみる GA4には「今まさに誰が見ているか」がわかるリアルタイムレポートがあります。自分がページを開いた瞬間に数字が動くかどうかで、混ざっているかがすぐわかります。 Step 2: 「確認用」と「本番」が区別されているか確認する ローカル確認・プレビューURL・本番URLの3つが、システム側でちゃんと区別されているかを見ます。区別する仕組みがなければ、混ざっているのが当たり前です。 Step 3: 仕組みがわからなければ、AIに一緒に調べてもらう 「原因を一緒に調べてほしい」という頼み方で、コードの中の該当箇所を探してもらいます。仕組みごと理解できると、次に同じ問題が起きても自分で気づけるようになります。 Step 4: 直したあとも、しばらくリアルタイムレポートで確認を続ける 直したつもりでも、思い込みの穴が残っていることがあります。しばらくは自分の閲覧が反映されていないか、様子を見るようにしています。まとめ「確認のために見ているだけ」のつもりが、本番のアクセス解析に混ざっていた 原因は、ローカル確認・プレビューURLのどちらも「本番」と区別されていなかったこと Claude Codeと一緒に、コードの該当箇所を探しながら仕組みを理解し、三段構えで除外する仕組みを作った データフィルタは過去にはさかのぼれないので、気づいたときが直しどき 「本番」と「確認用」を最初から分けて考える、という発想そのものが今回いちばんの収穫でした失敗談というより、「思い込みに気づけた話」という方が近いかもしれません。 次回は、この奮闘記シリーズを始めてから丸2ヶ月になるタイミングで、これまでの振り返りを書こうと思っています。次に読むのがおすすめの記事ノンエンジニアのClaude Code奮闘記 #6 CLAUDE.mdを育てる——AIへの「自分専用の取扱説明書」のつくり方 ノンエンジニアのClaude Code奮闘記 #1 まずはインストール編 - MacBook ProにClaude Codeを入れてみた参考文献・出典Firebase Hosting - プレビューチャンネルでの確認・共有 Google アナリティクス ヘルプ - 内部トラフィックの除外