社内からのアクセスをGA4で除外する？職場と在宅を分けてテストする方法

まず、どの回線の訪問を社内として扱うか決める

社員が使った端末かどうかではなく、その訪問がどの接続元から来るかを確認します。職場の回線と在宅・スマホの回線を同じ対象へまとめず、管理担当が範囲を説明できる接続元から候補にしてください。

GA4の内部トラフィックは、ここでは社内の確認訪問を識別するための区分です。公開IPアドレスは、インターネット側から見た接続元の住所に当たります。PC内のアドレスや社員名そのものではありません。同じ社員でも、職場のWi-Fiと携帯回線では条件が変わり得ます。

架空の小規模EC会社で、Web担当が商品ページの見え方を確かめる場面を考えます。本人の相談を企画の入口にしていますが、以下の会社・二つの条件・記録は説明用です。実チームの人数や顧客の訪問数、社内訪問の割合は取得していません。

管理担当に確かめる具体的な範囲

• いま使う公開IPまたは範囲：職場の回線から出る接続元を管理資料と照合します。ルーター内の端末番号を、そのまま公開IPとして登録しません。
• 変わる条件：契約や接続経路が変わった場合、同じ条件で識別し続けられるかを確認します。固定IP契約がGA4の必須要件という意味ではありませんが、現在一致しただけでは将来の網羅を証明できません。
• ほかの人が使う可能性：共有回線や広い範囲を指定すると、残したい人の訪問まで対象になるおそれがあります。接続元が分かることと、そこからの訪問が全て社員だと分かることは別です。

この原票では、職場の公開IPと固定契約は未取得です。職場だから既に安全な固定IPがある、という例ではありません。在宅・スマホの接続元も未確認で、職場の条件をそのまま当てはめません。

ここまで分かると、誰の端末かという名簿ではなく、どの接続条件をテストできるかを具体的に相談できます。実IPを公開記事や共有用の例へ書き込む必要はありません。

GA4の「識別ルール」と「除外フィルタ」を分けて設定する

接続元に印を付けるルールと、その印に一致するデータをどう扱うかのフィルタは別です。内部トラフィックの定義を作っただけで、実際の除外まで完了したとは扱いません。

権限のある設定担当が、会社のGA4プロパティと対象のウェブデータストリームを確認します。プロパティは計測データを扱う単位、ウェブストリームはサイトからの受け口です。管理画面のリンクが最後に開いた別のプロパティを表示する場合もあるため、名前と対象サイトを先に照合してください。編集にはプロパティ単位の編集者ロールが必要です。

1. 既存の設定を読む：対象ストリームの内部トラフィック定義と、プロパティの既存フィルタを確認します。すでに有効な別フィルタがあるなら、その影響も含めて調べます。
2. 内部の識別条件を作る：管理のデータストリームから対象ウェブストリームを開き、タグ設定、すべて表示、内部トラフィックの定義へ進みます。管理担当と確かめたIPの一致条件と、traffic_typeの値を指定します。
3. 値の役割を区別する：traffic_typeは訪問を区分する印の値で、初期値はinternalです。ルール名、フィルタ名、IPアドレスそのものとは別です。複数のIP条件は「どれか一つに一致すれば対象」というOR条件なので、追加するほど対象が広がり得ます。
4. 別のデータフィルタで評価する：管理のデータフィルタで内部トラフィックを選び、除外条件に、識別ルールで使うtraffic_typeの値を対応させます。新たな評価はまずテスト状態で行い、実除外を有効にする判断と分けます。

たとえばルールの表示名を変更しても、フィルタが照合する値まで同じ意味で変わるとは限りません。両方の設定でどの値を使ったかを読み返します。IPの欄へフィルタ名を入れたり、traffic_typeへIP文字列を合わせたりする手順ではありません。

以上はGoogle公式の内部トラフィック設定に基づく説明です。ウェブサイトのIP条件を扱うもので、アプリ利用者の内部トラフィックを同じ方法で除外できる説明ではありません。この記事では実プロパティや回線を取得・変更していません。

テストでは「対象に印が付く」と「対象外を残す」を両方確かめる

職場の確認訪問にテスト用のラベルが付くことだけでなく、残すべき訪問が同じ対象へ混じっていないことも確認します。ラベルのある行だけへ絞った探索では、対象外の保持まで証明できません。

下の図では、職場の商品ページ確認と、在宅・スマホの別条件を見比べてください。職場側も、接続元の候補とまだ空の確認欄です。線は設定と確認先の関係で、実際に識別や除外が成功した流れではありません。

職場・在宅・スマホのどの接続が、いまの識別ルールで分かるでしょうか。

原寸画像を開く

職場も接続元とテスト結果は未確認、ルール作成と除外有効化は未実施です。在宅・スマホは別条件のまま、対象ラベルと対象外の保持を実際に確かめます。

対象の訪問を調べる

設定担当が管理できる確認訪問について、ページ、時刻、接続していた回線、対象プロパティとストリーム、フィルタの状態をそろえます。探索の自由形式で「テストデータのフィルタ名」と「イベント名」を行、「イベント数」を値にし、対象フィルタ名で絞ると、候補に対応したイベントを調べられます。

テスト状態は、該当するデータへラベルを付けて評価する状態です。その新しいテストフィルタによる実除外を意味しません。ラベルに表示されるのはフィルタ名で、接続元のIPや社員名ではありません。

残すべき訪問を別に調べる

管理できる対象外の確認条件を設定担当と決め、同じページ・期間などを対応させて、対象フィルタ名へ誤って分類されていないかを調べます。顧客へ無断で操作を依頼したり、実顧客の識別情報を集めたりする必要はありません。対象フィルタ名だけの絞り込みを外した確認など、対象外も読める条件が必要です。

ラベルなしや(not set)の行を、全て「本物の顧客」と読み替えません。在宅の社員がまだ識別されていない可能性もあり、行が見えない理由も未確定だからです。訪問条件、設定の値、見た画面と時刻が対応して初めて、その確認範囲の判断材料になります。

図の職場も在宅・スマホも、テストラベルと対象外の保持は未確認です。次に必要なのは両方の結果を作り話で埋めることではなく、確認する回線と画面を定めることです。

在宅やスマホが識別できないなら、有効化を保留する

職場のテスト結果が得られても、在宅・スマホまで識別できたとは広げません。回線や範囲が分からない訪問は未確認として残し、対象を広げる変更や恒久除外を急がないでください。

二例目は一例目の修正後や成功例ではありません。スマホという機器名だけで、職場のWi-Fiにいるのか携帯回線なのかは決まりません。在宅の公開IPが今一致した場合も、接続条件が変わった後の訪問まで識別する保証にはできません。

ラベルが見えないときに戻る確認

対象のストリーム、IP条件、traffic_typeの対応、フィルタの状態、探索の期間と絞り込みを読み返します。Googleは適用に24〜36時間かかる場合があると案内していますが、必ずその時間で解決する保証ではありません。確認時刻を残し、設定担当と見直す時点を決めます。

リアルタイムの人数が見えないだけで、除外成功や原因は決まりません。既存フィルタや送信・受信、同意状態など、別の条件もあります。設定を削除したり同意の選択を変えたりする前に、GA4の確認訪問と0表示を切り分ける方法へ戻れます。

職場の対象外確認に問題がある場合は、在宅を足す前に対象範囲を見直します。在宅だけ識別方法が分からない場合は、その限界を共有し、会社として必要な対象が足りるかを判断します。一部を確かめた結果を「全社員除外済み」と報告しません。

恒久的な除外か、レポートだけの非表示かを選ぶ

確認後も、データを処理対象から外す必要があるのか、特定の報告で分けて見たいだけかを選びます。対象が確かでないまま、有効へ切り替えて数値を整えようとしないでください。

テスト

フィルタ条件への一致を評価し、確認用のラベルで調べる状態です。実除外の完了ではありません。

有効

以後の受信データへフィルタを適用します。除外されたデータは処理されず、後で必要になってもGA4やBigQueryで取り戻せません。

無効

そのフィルタを評価しない状態です。無効へ戻しても、有効だった間に処理対象から外れた過去分を復元する操作にはなりません。

恒久除外を検討できるのは、対象プロパティ、識別条件、対象・対象外の確認結果、残る未識別範囲と変更の影響を担当者が説明できる段階です。これは実務上の判断の整理で、この記事の架空例が条件を満たしたという結果ではありません。誰が有効化を判断し、いつ変更して、どの訪問を再確認するかも先に決めます。

報告で分けて見るだけなら、元データを除かない方法もある

特定のレポートでだけ非表示にしたい場合は、Google公式が説明するレポートフィルタという別の選択肢を検討します。データの処理から除外することとは異なります。ただし表示上で分ける場合も、条件が何を識別できるかは確かめる必要があります。未識別の在宅訪問まで分離できたことにはなりません。

GA4のデータフィルタは作成後のデータに反映され、過去の計測値を後から社内・社外へ分類し直す仕組みではありません。原票の「過去データの回復」は未取得のままです。

有効化などを行った場合は、設定担当が保存された状態と条件を読み返し、変更時点以後の対象と対象外を、決めた条件で再確認します。失われたデータが戻る保証と、これからの適用を止める判断を混ぜないことが大切です。

まとめ：職場と在宅の条件を分け、対象外も確かめてから判断する

社内アクセスをGA4で分ける最初の作業は、社員の端末を一括で除外することではありません。接続元を確かめ、内部の印を付けるルールと、その印を処理するフィルタを対応させて、テストで対象と対象外を確認します。

• 職場の回線も、公開IP・安定性・共有範囲が未確認なら候補です。範囲を広く入れて解決しません。
• 在宅・スマホは別条件です。職場のラベルが確認できても、その結果を全社員の識別へ広げません。
• テストラベルあり・ラベルなし・リアルタイム非表示は、それぞれ確認した画面の結果として読みます。成功や原因を一つの表示で確定しません。
• 有効な除外は恒久的に影響します。報告だけで分ける目的なら、レポート上の非表示も検討します。

最初の一歩：商品ページを確認する職場と在宅・スマホについて、使う回線、分かっている接続元、対象GA4、まだ分からない範囲を管理担当と照合してください。原票の空欄を埋めるために、実顧客の値を集める必要はありません。まず一つの管理できる接続条件をテストの候補にします。

タグの設置経路そのものが不明なら、Site KitとGTMの送信先を見分ける方法を先に確認できます。同意後の動作を調べる場合は、Cookieバナーの表示・状態・通信を分ける確認が別の課題です。内部トラフィックの除外を、この二つの解決へ置き換えません。

社内のWeb運用と計測管理の担当が分かれている場合は、対象ページと現在分かっている設定、未確認の接続条件を添えてWebサイトの支援相談へ相談できます。相談の受付や支援範囲・費用は個別に確認してください。