GA4で社内アクセスを除外する方法｜内部トラフィックと開発者トラフィックのフィルタ運用
GA4で社内アクセスを除外するには、Webデータストリームで社員や制作会社の公開IPを「内部トラフィック」として定義し、イベントへ付いたtraffic_typeをデータフィルタで除外します。開発者がDebugViewを使う検証アクセスは、IPではなくdebug_modeを対象にする「開発者トラフィック」フィルタで分けます。
重要なのは、最初からフィルタをActiveにしないことです。Google Analyticsのデータフィルタは受信時点でイベントを処理対象から外し、Active化後に除外されたデータはAnalyticsにもBigQueryにも戻せません。まずTestingで対象イベントを観測し、外部顧客が巻き込まれていないことと、KPIの減少幅を説明できることを確認してから有効化します。
本記事のポイント
- GA4の社内アクセス除外は、IPルールでtraffic_typeを付ける設定と、その値を除外するデータフィルタの二段階で行います。
- データフィルタをActiveにすると除外データは後から復元できないため、Testingで対象と外部顧客の混入がないことを確認してから切り替えます。
- リモートワークや制作会社は接続元IPが変わりやすいため、対象者・利用期間・接続経路・確認日を台帳化し、四半期ごとに見直します。
GA4の社内アクセス除外は「識別」と「除外」の二段階
社内アクセス除外は、IPアドレスを登録するだけでは完了しません。第1段階で、指定したIPから入るイベントにtraffic_typeを付けます。第2段階で、その値に一致するイベントを内部トラフィックのデータフィルタで除外します。どちらか一方だけでは、レポートから社内アクセスは消えません。
| 対象 | 識別方法 | 使うフィルタ | 向く場面 |
|---|---|---|---|
| オフィス・固定拠点 | 公開IPv4・IPv6、CIDR範囲、正規表現に一致するイベントへtraffic_typeを付与 | 内部トラフィック | 固定IPの本社、支社、コールセンター、管理されたVPN |
| 開発・タグ検証 | Tag AssistantやGoogleタグのdebug_mode | 開発者トラフィック | GTMプレビュー、イベント実装、DebugViewでの確認 |
| 一時的な分析上の除外 | 地域、端末、ページなどのレポート条件 | レポートフィルタ・探索のセグメント | 元データを残したまま特定の見方だけ変えたい場合 |
| アプリ利用者 | 内部トラフィックのIPルールでは対象外 | 要件に応じて別の計測設計 | モバイルアプリの社内利用を区別したい場合 |
Google Analytics公式ヘルプでは、内部トラフィックの定義時にtraffic_typeへ任意の値を設定できます。標準値はinternalですが、tokyo_officeやagency_reviewのように拠点・用途を分けると、Testing中の確認と変更履歴を追いやすくなります。1つのルールに複数のIP条件を追加した場合はOR条件として評価されるため、「本社か制作会社のどちらかに一致すれば内部」という判定になります。
一方、データフィルタは過去データを遡って変更しません。作成後に入ってくるイベントだけを評価します。過去期間の社内アクセスを分析から外したい場合は、元データを消そうとせず、探索やレポート側で期間・地域・端末・既知の特徴を使って区分します。GA4で成果地点までの離脱を見る場合は、GA4のファネル分析と設定方法を先に整え、どの指標が社内操作で膨らんでいるかを確認してください。
設定前に対象者・接続経路・守るKPIを棚卸しする
設定画面を開く前に、誰のどのアクセスを、なぜ除外するのかを決めます。「社員は全部除外」とすると、在宅勤務者の可変IPを追い切れず、商談先の共有回線を巻き込む可能性があります。「社内のコンバージョンだけ除外」とすると、同じユーザーのページ閲覧だけ残り、セッションとキーイベントの関係が不自然になります。対象者、接続元、操作、期間、確認責任者を一つの台帳にします。
| 棚卸し項目 | 確認する内容 | 危険な決め方 | 記録例 |
|---|---|---|---|
| 利用者 | 社員、業務委託、制作会社、広告代理店、開発者、コールセンター | 会社名だけで全員を恒久除外 | 部署・会社・用途・責任者・終了日 |
| 接続経路 | 固定IP、拠点回線、管理VPN、家庭回線、モバイル回線 | 家庭回線や広い通信事業者範囲を一括除外 | 公開IP、CIDR、回線所有者、確認日 |
| 操作 | 日常閲覧、入稿確認、フォーム送信、タグ検証、障害対応 | DebugView用の開発操作と一般閲覧を同じIPだけで処理 | 操作目的、対象ページ、利用ツール |
| 守るKPI | ユーザー、セッション、キーイベント、フォーム送信、商談化、広告連携 | PVだけ見てActive化 | 変更前の7日・28日基準値と想定減少幅 |
| 例外期限 | 制作期間、リリース確認期間、委託契約、拠点移転 | 終了日なしで制作会社IPを残す | 開始日、終了日、更新責任者、削除確認 |
自社のフォーム送信や資料ダウンロードを日常的に試している場合、除外前後でキーイベントが大きく減る可能性があります。その減少は設定成功かもしれませんが、本物の顧客まで除外した結果かもしれません。CRMや問い合わせ台帳で実件数を照合し、GA4だけを見て判断しないことが重要です。
また、設定変更中にイベント名や発火条件まで同時に変えると、減少原因を切り分けられません。内部トラフィック除外とイベント改修は別の変更として進めます。名称・タグ・キーイベント・広告・BigQueryを安全に切り替える順序は、GA4イベント名の変更管理を参照してください。
TestingからActiveまでを7段階で進める
データフィルタにはTesting、Active、Inactiveの状態があります。Testingは一致するイベントを捨てず、「Test data filter name」ディメンションで識別できる状態です。Activeは一致する新規イベントを恒久的に処理対象から外します。Inactiveはフィルタを評価しません。安全な切り替えには、識別、観測、比較、承認を分けます。
- 基準値を保存する：変更前の7日・28日について、ユーザー、セッション、主要イベント、キーイベント、ランディングページ、地域、端末を保存します。問い合わせやCRMの実件数も同じ期間で用意します。
- 内部トラフィックの値を分ける：Webデータストリームのタグ設定から「内部トラフィックの定義」を開き、拠点や用途ごとにルール名、
traffic_type、IP条件を登録します。広いIP範囲を使う場合は所有者と範囲を確認します。 - フィルタをTestingで作る：データフィルタで「内部トラフィック」「除外」を選び、定義時の
traffic_type値と一致させます。最初からActiveを選びません。 - 既知の操作を実行する：対象拠点やVPNから、閲覧、フォーム到達、テスト送信など、識別しやすい操作を時刻付きで行います。外部回線からも同じ操作を行い、比較対象を作ります。
- 探索で一致を確認する：自由形式の探索に「Test data filter name」「イベント名」を置き、社内操作が対象フィルタ名で識別されることを確認します。Googleは適用に24〜36時間かかる場合があると案内しているため、直後に見えないだけで設定を重ねません。
- 外部顧客の巻き込みを確認する：対象イベントのページ、地域、端末、時間帯、キャンペーンを確認し、商談先、店舗Wi-Fi、共有オフィス、制作会社の別案件などが混ざっていないかを調べます。想定減少幅をCRM・フォーム実件数と照合します。
- 承認後にActiveへ切り替える：設定者とは別の担当者が対象、証拠、想定影響を確認し、Active化日時を記録します。切り替え後は当日・翌日・7日後にKPIを確認し、異常時はフィルタをInactiveにして追加除外を止めます。
内部トラフィック除外は設定完了ではなく、外部顧客の行動だけが残っていると継続確認できて初めて運用になります。
Active化は過去の除外データを戻す操作ではありません。異常を見つけたときにできるのは、その後のイベントに対する評価を止めることです。だからこそ、Active化前に十分なTesting期間と承認を置き、Active化後もフォーム・CRM・広告側との突合を続けます。週次レポートで異常を同じ型で残す方法は、マーケティングレポートの運用設計も参考になります。
リモートワーク・制作会社・開発者は接続経路で分ける
内部トラフィックの標準設定は、Webサイトへのアクセス元IPを条件にします。そのため、家庭回線やモバイル回線のように公開IPが変わる環境では、登録した値と実際の接続元がずれます。広いIP範囲を推測で追加すると、同じ通信事業者を使う外部顧客まで巻き込む危険があります。対象者ではなく、管理できる接続経路を基準にします。
| ケース | 推奨する扱い | 避ける扱い | 見直し契機 |
|---|---|---|---|
| 固定IPのオフィス | 拠点別のtraffic_typeでTestingし、Active化 | 移転・回線変更後も旧IPを残す | 移転、ISP変更、ルーター更改 |
| 管理VPNを使う在宅勤務 | VPN出口の固定IPと利用対象を台帳化 | 全社員の家庭回線を個別登録 | VPN構成変更、対象部署変更 |
| 固定IPを持たない在宅勤務 | 通常閲覧は残し、開発検証だけdebug modeで識別 | 通信事業者の広い範囲を除外 | 検証手順、端末、タグ設定の変更 |
| 制作会社・広告代理店 | 案件用VPN・固定IP・期間・責任者を限定 | 会社全体のIPを期限なしで恒久登録 | 契約終了、公開完了、担当変更 |
| GTMプレビュー・DebugView | 開発者トラフィックフィルタをTestingから検証 | 開発者の全アクセスをIPだけで除外 | Googleタグ、GTM、テスト端末の変更 |
| 共有オフィス・来客Wi-Fi | 外部顧客が混ざる前提で原則除外しない | Wi-Fi全体を社内扱い | ネットワーク分離が実現した時 |
開発者トラフィックフィルタをActiveにすると、debug modeが有効なイベントは通常レポートから除外されますが、DebugViewでの検証は続けられます。Tag Assistantのプレビューモードは公開前のコンテナ構成をブラウザで試し、どのタグがどの順番で発火したかを確認するためのものです。内部トラフィックのIP除外と、タグ検証のdebug modeを同じルールにまとめない方が、原因を追いやすくなります。
制作会社や広告代理店が新しい計測タグを追加するときは、アクセス除外だけでなく、誰がどのタグを公開し、いつ外すかも管理します。UTMやキャンペーン名まで含めた配信前レビューは、UTM設計の命名ゆれとレビュー運用と同じ台帳に結び付けると、計測変更の責任範囲が明確になります。
除外しすぎ・除外漏れを防ぐ監視と変更台帳
運用開始後は、社内アクセスがゼロになったかだけでなく、本物の顧客行動が不自然に減っていないかを監視します。特にBtoBサイトでは、商談中の顧客が自社オフィスへ来訪し、同じWi-Fiからフォームやデモページを操作することがあります。回線だけを根拠にすべてを除外すると、重要な顧客行動を消す可能性があります。
| 症状 | 考えられる原因 | 確認方法 | 対応 |
|---|---|---|---|
| Testingに何も出ない | IP値の誤り、別の出口IP、反映待ち、対象ストリーム違い | 実際の公開IP、ルール、ストリーム、24〜36時間後の探索 | 既存ルールへ無計画に条件を追加せず、接続経路から再確認 |
| Active化後にCVが急減 | 顧客・来客・共有回線を巻き込んだ、社内テストが想定以上 | CRM実件、フォーム受信、広告CV、地域・端末・時間帯 | フィルタをInactiveにし、新規除外を止めて条件を再設計 |
| 在宅社員のアクセスが残る | 家庭回線のIP変動、VPN未利用、モバイル回線 | 対象者の接続経路と公開IP、debug modeの有無 | 管理VPNか開発者フィルタへ分離し、広いIP範囲は追加しない |
| 制作会社のアクセスだけ残る | 別拠点・別VPN・契約変更 | 案件責任者、利用期間、作業時刻、接続元 | 期限付き例外を更新し、終了済みルールを削除 |
| DebugViewには出るが通常レポートにも出る | 開発者フィルタがTesting・Inactive、debug_modeの範囲が不適切 | フィルタ状態、イベントのdebug_mode、探索のTest data filter name | Testingで対象を確認してからActive化 |
変更台帳には、ルール名、traffic_type、IP条件、対象者、接続経路、目的、Testing開始日、確認したイベント、想定減少幅、承認者、Active化日時、次回レビュー日、削除日を残します。IPアドレスそのものを不要に広く共有せず、アクセスできる担当者と保管期間も決めます。
レビューは最低でも四半期ごとに行い、拠点移転、ISP変更、VPN更改、制作会社の契約終了、サイト改修、GTMコンテナ公開のたびに臨時確認します。ページ別のユーザーやイベントが急に減った場合は、サイト障害、タグ不発、同意設定、フィルタ変更を同じ時系列で並べます。計測タグやチャット、埋め込みの所有者まで含めて確認する場合は、企業サイトの外部スクリプト棚卸しも併用してください。
よくある質問
GA4で社内アクセスを除外するには何を設定しますか？
Webデータストリームで社内の公開IPまたはIP範囲を内部トラフィックとして定義し、イベントへtraffic_typeを付けます。次に、同じ値を除外する内部トラフィックのデータフィルタを作成します。IPルールとデータフィルタの両方が必要です。
内部トラフィックフィルタはテストと有効をどう切り替えますか？
最初はTestingにし、探索で「Test data filter name」とイベント名を確認します。想定した社内操作が識別され、外部顧客が混ざらず、主要KPIの減少幅をCRMやフォーム実件で説明できた段階で承認を取り、Activeへ切り替えます。
リモートワークや制作会社のアクセスをどう扱いますか？
固定IPのVPNや管理拠点を使える場合は、対象者と期間を限定して登録します。接続元IPが変わる環境を広いIP範囲で除外せず、開発検証はdebug_modeと開発者トラフィックフィルタへ分け、所有者・期限・確認日を台帳に残します。
除外設定で必要なデータまで失わないために何を確認しますか？
Testing中に対象イベントのページ、イベント名、地域、端末、時間帯を確認し、商談先、来客、共有オフィス、同じ回線の外部利用者が混ざっていないかを調べます。Active化後は除外データを復元できないため、変更前の基準値と承認証跡も保存します。
内部トラフィックフィルタは過去データにも適用されますか？
適用されません。データフィルタは作成後に入ってくるイベントを評価し、過去データを書き換えません。過去期間を分析上分けたい場合は、探索やレポートの条件を使い、元データを残したまま扱います。
設定と検証に使えるGoogle公式資料
- Google Analytics：内部トラフィックを除外するでは、
traffic_type、IPv4・IPv6、CIDR、Testing・Active・Inactive、探索での確認方法を確認できます。 - Google Analytics：開発者トラフィックを除外するでは、debug modeを使う開発者のイベントを通常レポートから外す条件を確認できます。
- Google Analytics：データフィルタでは、フィルタが作成後の受信イベントだけを評価し、除外が不可逆であることを確認できます。
- Google Analytics：DebugViewでイベントをモニタリングするでは、Tag Assistantや
debug_modeで検証イベントを確認する方法を確認できます。 - Google Tag Manager：コンテナのプレビューとデバッグでは、公開前のコンテナをTag Assistantへ接続し、タグの発火順と送信データを確認する方法を確認できます。
