Googleアナリティクス4（GA4）で自分のアクセスを除外する具体手順

この記事は、個人サイトに Googleアナリティクス4（GA4）を入れたあと「自分の動作確認アクセスでレポートが汚れる」と困っている人向けです。特に、IPv4 共有回線や回線仕様が見えにくい環境で、GA 側の IP 除外を使うべきか迷っているケースを想定しています。読了後には、GA 側の除外を急がず、ブラウザ側で自分だけ安全に計測除外する運用を再現できるようになります。

この記事では、GA4 そのものの導入手順ではなく、導入後の自己アクセス除外に絞って解説します。技術ブログや小規模サイトで起こりやすい実例をもとに、g/collect が出ない不具合の切り分けと、自分のアクセス除外の考え方をまとめます。

TL;DR

  • 自分のアクセスを除外したいだけなら、GA4 の IP 除外よりブラウザ側の無効化が安全です
  • MAP-E や CGNAT 系などの IPv4 共有回線では、1つのグローバル IPv4 を複数利用者で共有する可能性があるため、GA 側の IP 除外は他人を巻き込むおそれがあります
  • Google 公式は window['ga-disable-MEASUREMENT_ID'] = true による Google Analytics の無効化方法を案内しています
  • Tampermonkey では userscript の文脈差で効かないことがあるため、ページコンテキストに script を注入する形にすると安定しやすいです
  • 検証時は userscript を OFF にするか、別ブラウザ・別プロファイルを使うと運用しやすいです

まず結論: 自分だけ除外したいならブラウザ側が安全です

結論として、自分のアクセスだけを除外したいなら、GA4 の internal traffic で IP を除外するより、自分のブラウザで GA を無効化するほうが安全です。

理由は単純で、IP 除外は「その IP を使う全トラフィック」に効く一方、ブラウザ側の無効化は「そのブラウザだけ」に効くからです。回線の仕様が曖昧なときでも、他人のアクセスを巻き込まずに済みます。

GA4 の internal traffic は便利ですが、回線が IPv4 共有型だと「このグローバル IPv4 を除外すると自分以外も消してしまうのでは」という不安が残ります。そのため、まずは Google 公式の ga-disable-MEASUREMENT_ID をブラウザ側で使う運用から始めるほうが安全です。

GA4 導入直後に起きたこと

最初に起きたのは、「タグは入っているのに GA4 に反映されない」問題でした。結論から言うと、gtag.js の初期化コードが Google 公式スニペットと微妙に違っていたのが原因でした。

症状は次のとおりです。

  • HTML には gtag.js が入っている
  • window.gtag も function になっている
  • window.dataLayer に config や page_view が積まれる
  • それでも Network に g/collect が出ない
  • navigator.sendBeacon(...) で直接送ると GA4 に届く

この状態は「タグの読み込みは成功しているが、通常の計測送信が正しく動いていない」ことを示していました。最終的には、Google 公式の Google tag 導入方法に合わせて dataLayer.push(arguments) を使う形に修正し、通常アクセスでも g/collect が送られるようになりました。

参考:

その次に起きるのが「自分のアクセスも計測される」問題です

通常アクセスでカウントされるようになると、次は自分の動作確認がそのまま Realtime や page_view に載る問題が出ます。

これはある意味では正常です。同じブラウザで何度見ても、Active users は 1 のままでも page_view は増えます。つまり「計測できている」ことと「自分のアクセスでレポートが汚れる」ことは同時に起こります。

個人サイトや小規模ブログでは、数回の確認アクセスでもレポートの見え方がかなり変わります。導入直後ほど、自分のアクセスをどう扱うかを早めに決めておくほうが運用しやすいです。

IPv4 共有回線では GA 側の IP 除外を急がないほうがよい理由

結論として、MAP-E や CGNAT 系などの IPv4 共有回線では、GA4 の internal traffic で IPv4 を除外する判断は慎重にしたほうがよいです。

Google Analytics ヘルプでは、internal traffic は IP アドレスや CIDR 範囲で定義すると説明されています。つまり GA4 は「この IP を internal にする」という形で判定します。ポート単位での除外はできません。

一方で Cloudflare は、CGNAT 環境では 1 つの IPv4 アドレスの背後に多数の利用者が存在しうると説明しています。MAP-E も実質的には IPv4 共有系の構成なので、GA4 でその IPv4 を除外すると、自分以外の利用者を巻き込む可能性があります。ここは厳密な同一仕様ではありませんが、「IP だけを信じて雑に除外しないほうがよい」という判断材料として十分です。

参考:

固定っぽく見える IPv4 でも安心とは限りません

「IPv4 が固定っぽいなら大丈夫では」と思いがちですが、IPv4 共有回線ではグローバル IPv4 を共有しつつ、ポート範囲などで利用者を分ける構成があります。外から見える IPv4 が安定していても、そのアドレスを本当に自分だけで使っているとは限りません。

そのため、IPv4 共有回線ではまず次の順で考えるのがおすすめです。

  1. GA 側の IP 除外は急いで有効化しない
  2. まずブラウザ側で自分だけ無効化する
  3. どうしても GA 側で除外したい場合は、Testing で十分検証してから判断する

Google 公式の無効化方法は ga-disable-MEASUREMENT_ID です

結論として、Google 公式が案内している「このブラウザでは GA を送らない」方法は、window['ga-disable-MEASUREMENT_ID'] = true を使う方式です。

Google の Tag Platform ドキュメントでは、この window プロパティを true にすると Google tag がデータ送信を行わないと説明されています。重要なのは、gtag() が呼ばれる前に設定することと、無効化したい各ページで設定することです。

参考:

最小例は次のとおりです。

<script>
  window['ga-disable-G-XXXXXXXXXX'] = true;
</script>

ただし、これを毎回手で Console に打つ運用は現実的ではありません。そこで、自分のブラウザだけで自動的に入るように userscript を使います。

Tampermonkey で自分のブラウザだけ無効化する

結論として、Tampermonkey で userscript を使う方法は手軽ですが、そのまま window['ga-disable-...'] = true を書くだけでは期待通り効かないことがあります。

理由は、userscript の実行文脈とページ本体の文脈が分かれると、ga-disable-* がページ側に届かないことがあるためです。環境によっては、Console から見ると window['ga-disable-G-XXXXXXXXXX'] が undefined のままなのに、一見すると送信が止まっているように見える、逆にタイムラグで後からカウントされる、といった混乱が起きます。

最終的に安定したのは、ページコンテキストに script を注入する次の形です。

// ==UserScript==
// @name         Disable GA4 on example.com
// @namespace    https://example.com/
// @version      1.0.2
// @description  example.com で GA4 送信を無効化する
// @match        https://example.com/*
// @match        https://www.example.com/*
// @run-at       document-start
// @grant        none
// ==/UserScript==

(function () {
  'use strict';

  const script = document.createElement('script');
  script.textContent = `
    window['ga-disable-G-XXXXXXXXXX'] = true;
  `;
  (document.documentElement || document.head).appendChild(script);
  script.remove();
})();

使うときは、次の 2 か所を自分の環境に置き換えてください。

  • G-XXXXXXXXXX → 自分の GA4 Measurement ID
  • example.com / www.example.com → 自分のサイトのドメイン

この形にすると、ページ側の window に ga-disable-* が入りやすくなります。実際に次の 3 点を満たせば成功です。

  • Console で window['ga-disable-G-XXXXXXXXXX'] が true
  • Network で collect が出ない
  • GA4 Realtime が増えない

Chrome 138 以降は userscript の許可設定にも注意が必要です

結論として、Tampermonkey を入れただけでは userscript が実行されないことがあります。Chrome 138 以降では、拡張機能ごとの Allow User Scripts が必要です。

Chrome for Developers のブログによると、Chrome 138 からは従来の Developer Mode 依存から移行し、拡張機能ごとに userscript を許可する方式に変わりました。バージョンによっては Developer Mode を求められることもあるため、メッセージに従って拡張設定を確認するのが確実です。

参考:

チェックポイント

  1. chrome://extensions/ で Tampermonkey が有効か確認する
  2. Chrome 138 以降なら拡張詳細で Allow User Scripts を ON にする
  3. 保存後にページをハードリロードする
  4. window['ga-disable-G-XXXXXXXXXX'] が true か確認する

確認は collect と Realtime をセットで見ると迷いにくいです

結論として、userscript が効いているかの確認は、Console の値だけに頼らず、Network と GA4 Realtime をセットで見るほうが確実です。

確認手順は次のとおりです。

1. 通常の計測が有効な状態を確認する

まず userscript を OFF にして、通常アクセスで計測されることを確認します。

  • Network を All にする
  • collect で絞り込む
  • g/collect もしくは類似の送信先が出るか確認する
  • GA4 Realtime で page_view が増えるか確認する

2. userscript を ON にして再確認する

次に userscript を ON にして同じ確認を行います。

  • window['ga-disable-G-XXXXXXXXXX'] が true
  • collect が出ない
  • Realtime が増えない

3. タイムラグに注意する

Realtime でも反映に少しタイムラグがあります。そのため、「増えていないように見えたが、数分後に増えた」ということが起こります。切り分け時は、その場の印象だけで判断せず、数分待ってもう一度見るのが安全です。

普段用ブラウザと検証用ブラウザを分けると運用が楽です

結論として、日常運用では「普段用は無効化」「検証用は有効」の 2 系統に分けると迷いにくいです。

おすすめは次の運用です。

用途設定
普段の閲覧Tampermonkey の userscript を ON
GA4 の確認userscript を OFF、または別ブラウザ / 別プロファイル

この分離をしておくと、「今のアクセスは計測される前提か」を毎回考えずに済みます。個人サイトではこの運用だけでもかなり快適になります。

まとめ

  • 自分のアクセスを除外したいだけなら、GA4 の IP 除外よりブラウザ側無効化のほうが安全です
  • MAP-E や CGNAT 系などの IPv4 共有回線では、IP ベース除外が他人を巻き込む可能性があります
  • Google 公式の window['ga-disable-MEASUREMENT_ID'] = true は、自分だけ無効化したい用途に使いやすいです
  • Tampermonkey ではページコンテキストへ script 注入する形にすると安定しやすいです
  • 確認時は collect、Realtime、タイムラグの 3 点をセットで見ると混乱しにくいです

次にやることとしては、まず普段使いブラウザで userscript を有効化し、その後に検証用ブラウザを 1 つ分けておくのがおすすめです。これで日常運用と計測確認を無理なく分けられます。

参考リンク