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

Etsuko Mera
01 Jul, 2026
- 奮闘記

はじめに

こんにちは、広報・制作担当の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ヶ月になるタイミングで、これまでの振り返りを書こうと思っています。