GA4のIP除外設定｜テストから有効化までの確認手順と注意点

GA4で既知の社内アクセスを除外するには、公開IPに一致するアクセスを内部トラフィックとして定義し、その値をデータフィルタで扱います。除外を有効にすると対象データは恒久的に失われるため、まずTestingで対象・非対象の両方を検証します。これは内部アクセスを減らす方法であり、外部の実ユーザーだけになることを保証する設定ではありません。

IP除外とレポートで一時的に隠す方法の違い

データフィルタは受信データの処理に作用します。Activeの除外に一致したデータは、その後レポートで非表示を解除するように戻せません。一方、レポートや探索の表示条件は、収集済みデータの見方を一時的に絞る方法です。恒久除外が必要か、分析時に分けられればよいかを先に決めてください。

Googleのデータフィルタ説明では、フィルタは過去のデータを変更しないとしています。Activeへ変更しても、すでに集計された過去の社内アクセスが遡って消えるわけではありません。除外した後の復元と、過去データの扱いを混同しないことが重要です。

権限・対象ストリーム・公開IPを確認する

対象プロパティの編集者以上の権限、対象ウェブストリーム、除外すべきネットワークを確認します。登録するのは端末のプライベートLANアドレスではなく、サイトへの通信に使う公開IP／出口です。オフィス、VPN、在宅接続で出口が変わるか、IPv4とIPv6のどちらを使うかをネットワーク担当者と照合します。

既存の内部トラフィックルールとデータフィルタの状態も、変更前に確認してください。すでにActiveのフィルタと同じtraffic_typeを新しいルールで付けると、そのアクセスも除外対象になり得ます。ルール作成から始めて安全とは限らないため、影響範囲とテスト方法を先に確定します。内部トラフィックの公式手順が基本資料です。

内部トラフィックの定義：traffic_typeとIP条件

対象ウェブストリームのGoogleタグ設定から「内部トラフィックの定義」を開き、識別しやすいルール名、traffic_typeの値、IPのマッチ条件を設定します。一般的なinternalという値を使う場合も、対応するデータフィルタの値との一致を確認します。定義だけでは除外という処理は決まりません。

次は文書用に予約されたアドレスによる説明例です。実ネットワークの設定値ではなく、そのまま登録してはいけません。範囲を広げるほど、意図しない利用者を巻き込む可能性が増えます。

データフィルタのTesting・Active・Inactive

管理のデータフィルタで種類、オペレーション、traffic_typeの値、現在の状態を確認します。既存のInternal Trafficがあることや初期状態を、どのプロパティでも同じと想定しません。新規作成・変更前に既存設定との重複を調べます。

Testingは失敗状態ではなく、安全に判定を調べるための状態です。公式手順には適用に24〜36時間程度かかり得るとあるため、保存直後の総数だけでは判断しません。

探索でテスト対象と非対象を確認する

公式の検証方法に沿って自由形式の探索を使います。ディメンションにTest data filter nameとEvent name、指標にEvent countを取り込み、行へ配置し、対象フィルタ名で絞って一致したイベントを確認します。同じディメンションがRealtimeの比較で常に使えるとは限りません。

1. 対象ネットワークと非対象ネットワークで、別々にテスト時刻とテストイベント名を記録する。
2. 対象ケースに期待したTest data filter nameが付くか確認する。
3. フィルタ名で絞らない対照表でも非対象ケースが収集されていることを確認する。
4. 非対象ケースへ誤ってテスト名が付かないことを調べ、同意状態や他フィルタの影響も照合する。

説明用に対象側から指定テストイベント5件、非対象側から別の指定テストイベント5件を送るなら、前者5件の一致と後者5件の未一致を確認します。自動イベントを含む全数と取り違えません。前日100件、当日90件という差10件だけでは成功の証拠にならず、イベント5件も5人を意味しません。

検証後の有効化と戻せないデータの範囲

対象と非対象の検証がそろい、恒久除外が必要だと判断したうえで、権限を持つ担当者がActiveへの変更を検討します。変更日時、対象条件、承認した担当者、影響するストリームを残してください。

Activeで除外したデータはAnalyticsやBigQueryから復元できません。後からInactiveへ戻せば、その後の扱いは変更できますが、除外された期間のデータは戻りません。また、これは以後の受信データの処理であり、過去期間をきれいにする機能ではありません。検証済みの社内アクセスだけを対象にし、疑わしい流入の一括除外へ転用しないでください。

IPv4・IPv6・VPN・在宅勤務での診断

スマートフォンでも社内Wi-Fiや組織のVPN出口を使い、その公開IPが条件に一致すれば対象になり得ます。「スマホは接続ごとに変わるので不可能」とは言えません。一方、モバイル回線、動的な在宅IP、共有出口では継続性と誤除外に注意が必要です。

これらは想定例です。実際の出口を調べて判定してください。IPv4だけ登録してIPv6の経路が残る場合や、VPNの分岐で通信先によって出口が変わる場合も確認します。広い共有IPの除外で外部利用者を巻き込まないことを優先します。

設定変更日と継続点検のチェックリスト

点検頻度はネットワークの変更頻度と運用に合わせます。拠点移転、VPN変更、回線変更、在宅運用の拡大時には対象条件を見直し、対象・非対象のテストを再実施してください。IP一覧だけでなく、その範囲を内部と判断した理由も残します。

• プロパティ・ストリーム・ルール・フィルタ名とtraffic_typeを保存する。
• 公開IPと管理範囲の確認者、確認日を記録する。
• Testingの対照テストと適用後の確認結果を残す。
• Active変更日を分析の注記に入れ、前後の数値差をそのまま利用者減少と読まない。

IP除外は計測対象を変える設定です。除外後のイベント数を登録人数と見なさず、成功条件や重複の検証は別に行います。まず恒久除外の必要性を判断し、対象・非対象を確認できるテスト計画から始めてください。

関連記事

• GA4パラメータの設計・設定方法｜イベント・ユーザー・アイテムを区別
• GA4クロスドメイン設定と確認方法｜不要な参照元との違い
• GA4の(direct)/(none)が増える原因は？割合に頼らない診断手順

出典・仕様の確認日

仕様は2026年10月12日に以下の一次資料で確認しています。画面構成は権限やレポートコレクションによって異なります。

• Filter out internal traffic
• Data filters
• API dimensions and metrics
• RFC 5737: IPv4 Address Blocks Reserved for Documentation