GA4の内部トラフィック除外が効かない原因と確認手順｜データフィルタが「テスト」のまま・自分のアクセスが消えない時の切り分け

この記事のポイント

• GA4の内部トラフィック除外が効かない原因は、フィルタが「テスト」のまま、IPの不一致（特にIPv6）、仕様上の見え方の3つに集約できる。
• Networkタブのcollectリクエストにtt=internalが付いているかで、IP判定側の問題かデータフィルタ側の問題かを最初の1手で切り分けられる。
• データフィルタを「有効」にしても過去データには遡及せず、除外されたデータは復元できないため、テスト状態での検証が先になる。
• 在宅勤務や代理店が多く固定IPを維持できない体制では、Cookie×GTMでtraffic_typeを付与する方式のほうが壊れにくい。

「内部トラフィックを定義して、フィルタも作ったのに、リアルタイムレポートに自分がいる」。GA4の内部トラフィック除外が効かないと感じる場面の大半は、この状態です。画面上は設定が揃っているので、どこを疑えばいいのか分からなくなります。

ただ、原因の探し方には順番があります。見るべきは「自分のアクセスにtraffic_typeが付いているか」の一点で、ここで調査の半分が片付きます。この記事では、判定されていないのか、判定されているのに落ちていないのか、それとも仕様上そう見えているだけなのかを、5分程度で切り分ける手順をまとめます。

GA4の内部トラフィック除外が効かないのはなぜ？まず疑う3つの原因

GA4の内部トラフィック除外が効かない原因は、「データフィルタがテスト状態のまま」「登録したIPと実際の接続IPが一致していない」「設定は正しいが仕様上そう見えている」の3つにほぼ集約されます。まずこの3つを順に潰すのが最短です。

多いのは「データフィルタがテストのまま」と「IPv6の未登録」

Googleアナリティクス4（GA4）の「Internal Traffic」フィルタは、作成直後は「テスト」状態になっています。テストはラベルを付けるだけで除外はしないので、定義を済ませて安心したまま放置されがちです。もうひとつがIPv6です。IPv4のグローバルIPアドレスだけを登録しても、回線がIPv6で接続していれば一致しません。

除外は「定義→traffic_type付与→フィルタ有効化」の3段階で成り立つ

内部トラフィック除外は、1つの設定ではなく3段階の連携です。Nice Looking Dataでも、多くのチームが最後の有効化まで完了していない点が指摘されています。

1. データストリームで「内部トラフィックの定義」を作り、IPの条件とtraffic_typeの値（既定はinternal）を決める
2. 条件に合うアクセスに、GA4がtraffic_typeを付与する
3. 管理画面の「データフィルタ」で、その値を持つデータを除外する状態（有効）にする

どこで止まっているかを見る。それが診断の本体です。

原因別の早見表（症状・確認場所・対処）

症状	確認場所	対処
tt=internalが付かない	Networkタブ	登録IPと接続IPのズレを確認（IPv6・CIDR・動的IP）
ttは付くが数値に残る	データフィルタの状態	「テスト」を「有効」へ切り替える（要判断）
ttは付くが残る（有効でも）	フィルタのパラメータ値	定義側のtraffic_type値と一致させる
有効化直後に残る	時間・日付範囲	有効化以降のデータのみ対象、処理待ちを見込む
一部のヒットだけ残る	タグの経路	GTMとgtagの併用、上書き設定を確認

自分のアクセスが内部トラフィックと判定されているか確認する方法は？

自分のアクセスが判定されているかは、ブラウザのChrome DevTools Networkタブでcollectリクエストを開き、tt=internalが付いているかを見れば確認できます。ここが最初の分岐点です。

Networkタブでcollectリクエストのtt=internalを確認する

手順は次のとおりです。

1. 自社サイトを開き、F12でChrome DevToolsを開いてNetworkタブを選ぶ
2. フィルタ欄に「collect」と入力し、ページを再読み込みする
3. 一覧に出たcollectリクエスト（g/collectを含むもの）をクリックし、「Payload」または「Headers」のクエリ文字列を見る
4. 「tt=internal」（または設定したtraffic_typeの値）が含まれているか確認する

MeasureSchoolの解説でも、効かない時はペイロードのtraffic_typeを直接見る方法が紹介されています。日本語の記事では原因の列挙で終わることが多いので、リクエストを直接見る手順を持っておくと迷いません。なお、広告ブロッカー系の拡張機能でリクエスト自体が見えない場合は、シークレットウィンドウで拡張機能を無効にして試します。

リアルタイムの比較で「テストデータのフィルタ名」を使う

リアルタイムレポートで確認する場合は、比較機能で「テストデータのフィルタ名」を条件にします。フィルタが「テスト」状態なら、判定されたヒットにフィルタ名のラベルが付きます。ラベル付きのヒットが自分の端末の分だけ出るなら判定は成功です。ラベルが出ず、数値だけが残るなら、判定側を疑います。

DebugViewでtraffic_typeを見る時の注意点

DebugViewでtraffic_typeを確認する方法もありますが、注意点があります。有効な内部トラフィックフィルタはDebugViewにも効くため、フィルタが有効だと自分のイベントが見えなくなります。検証目的でDebugViewを使うなら、フィルタがテスト状態であることが前提です。DebugViewが空になる時の切り分けは、DebugViewにイベントが表示されない時の切り分けにまとめています。

結果で分かれる次の一手（付いていない→IP側／付いている→フィルタ側）

• ttが付いていない → 次のセクション（IP定義の確認）へ
• ttが付いている → フィルタ側（4番目のセクション）へ
• ttは付くのに一部のヒットだけ残る → 5番目のセクションへ

traffic_typeが付かない時：IPアドレスの定義で確認すべきことは？

traffic_typeが付かない時は、「登録しているIPアドレス」と「実際にGA4へ届く接続元IP」がずれています。IPv4/IPv6、CIDR表記、回線の種類、データストリームの4点を順に確認します。

IPv4だけ登録してIPv6で接続している（v6プラス・IPoE）

IPv6（v6プラス・IPoE）に対応した回線では、サイトによってIPv4とIPv6のどちらで接続するかが変わります。「IPアドレス確認」系のサイトでIPv4が表示されていても、GA4にはIPv6で届いている場合があります。自分の端末から、IPv4とIPv6の両方で表示されるアドレスを確認し、両方を定義します。IPv6は端末ごとに末尾が変わるため、プレフィックスを揃えた範囲（CIDR）での指定を検討します。

CIDR表記・マッチタイプの指定ミス

マッチタイプは「IPアドレスが次と等しい」「範囲（CIDR表記）」など複数あります。単一IPなのに範囲を選んでいる、203.0.113.0/24 の書き方がずれている、といったミスは地味に多い部分です。迷ったら、まず単一IPで「等しい」を使い、判定されることを確認してから範囲に広げる、という順番が安全です。

動的IP・VPN・スマホ回線でIPが変わっている

動的IPの回線や、モバイル回線は、日によって、あるいは接続のたびにIPが変わります。VPN・プロキシ経由なら、登録すべきは自宅やオフィスのIPではなくVPNの出口IPです。Nice Looking Dataでも、VPNは出口IPを登録するよう案内されています。IPが固定できないなら、後述のCookie方式のほうが筋が良くなります。

別のデータストリーム・別の測定IDに定義している

内部トラフィックの定義はデータストリーム単位です。複数のデータストリームや測定IDがある場合、別のストリームに設定していることがあります。いま閲覧しているページに実際に載っている測定ID（G-から始まるID）と、設定したストリームを突き合わせてください。

保存後のタグ反映待ちとブラウザの再読み込み

定義を保存した直後は、タグ側に反映されるまで少し間が空きます。保存ボタンの押し忘れも含め、MeasureSchoolは待ち時間と保存漏れを原因として挙げています。定義の保存後は、時間をおいてからシークレットウィンドウで再読み込みし、Networkタブで再確認します。

traffic_typeは付くのに消えない時：データフィルタの「テスト」と「有効」の違いは？

traffic_typeが付いているのに消えない時は、データフィルタの状態が「テスト」のままか、フィルタ側のパラメータ値が定義側と一致していません。テストは除外せずラベルを付けるだけの状態です。

「テスト」「有効」「無効」で何が変わるか

GA4の「データフィルタ」の状態は、次の3つです。

状態	動作	レポートへの影響
テスト	一致したデータに「テストデータのフィルタ名」を付ける	除外されない
有効	一致したデータを除外する	以降のデータから消える
無効	フィルタを適用しない	影響なし

テスト状態で比較して、想定どおりのデータだけにラベルが付いていることを確認してから有効にするのが基本の流れです。

フィルタのパラメータ値と定義側のtraffic_type値が一致しているか

定義側で「traffic_type値」を独自の文字列（例：office）に変えているのに、フィルタ側が既定のinternalのままだと、一致せずに除外されません。両画面の値を並べて見てください。大文字小文字や余分なスペースも原因になります。

有効化しても過去データは消えない・除外したデータは戻せない

データフィルタには、過去データへの遡及適用がありません。有効化したあとに計測されたデータだけが対象です。逆に、有効化後に除外されたデータは復元できません。Nice Looking Dataが、テスト状態で検証してから切り替える運用を勧めているのはこのためです。

有効化を切り替える前の判断基準は、次の3点です。

• テストのラベルが付くのは、自分と社内のアクセスだけか（外部ユーザーに付いていないか）
• 付与される範囲（CIDR）が広すぎないか
• 除外してはいけないアクセスが含まれていないか

過去分の数値を見る時は、探索のセグメントや比較で自分のアクセスを絞って見ることになります。標準レポートと探索の数値がずれる件は、GA4の標準レポートと探索で数値が合わない原因で整理しています。

有効化後に反映を待つ時間の目安

有効化の直後は、データの処理に時間がかかります。標準レポートに反映されるまで24〜48時間ほど見ておくのが無難とされています。ただし、公式ヘルプの記載は更新される可能性があるため、2026年時点の最新の数値は、Googleアナリティクス ヘルプでご確認ください。リアルタイムは標準レポートより早く確認できますが、処理の仕組みが異なるため、見え方が一致するとは限りません。

設定は正しいのに自分のアクセスが見えるのはどんな時？

設定が正しくても自分のアクセスが見える時は、タグの実装や別の経路のヒットが原因で、GA4の故障ではないことがほとんどです。

GTMやgtagの設定でtraffic_typeを上書き・未送信にしている

Googleタグマネージャー（GTM）のGA4設定タグやイベントタグで、traffic_typeというパラメータを独自に設定していると、GA4側の判定を上書きしてしまうことがあります。逆に、特定のイベントだけがGoogleタグ（gtag.js）の設定を引き継がず、traffic_typeが付かないケースもあります。ttが付くヒットと付かないヒットが混在するなら、イベントごとにNetworkタブで見比べてください。

GTMとGoogleタグの併用で別経路のヒットが飛んでいる

GTMと直接埋め込みのgtag.jsが両方載っていると、別経路でヒットが飛びます。片方だけ設定が効いている状態です。併用の整理は、GoogleタグとGTMの違いと併用時の整理手順を参考にしてください。

デベロッパートラフィック（プレビュー・debug_mode）は別フィルタ

デベロッパートラフィックは、プレビューモードやdebug_modeのヒットを対象とする別のフィルタです。内部トラフィックのフィルタとは独立していて、これを有効にしても自社のIPからのアクセスは除外されません。Search Engine Journalでも、デベロッパーフィルタは_dbg付きのヒットが対象で、DebugViewには残る点が整理されています。GTMのプレビューで検証する手順は、GTMプレビューが接続できない時のチェックリストが参考になります。

BigQueryエクスポートやサーバーサイドGTM経由の場合の確認点

サーバーサイドGTM経由で計測している場合、GA4に届くIPが変わる可能性があります。6th Man Digitalでも、サーバーコンテナ環境ではGTMとdataLayerによる方式が推奨されています。ただ、日本ではサーバーサイドGTMの導入は少数なので、該当する場合のみ確認すれば十分です。実際に届くIPの扱いは、2026年時点の公式ドキュメントで確認してください。

在宅・代理店などIPが固定できない場合はどう除外する？

在宅勤務や外部の代理店が多く、IPを固定できない体制では、IPで除外する方式ではなく、Cookieでtraffic_typeを付ける方式のほうが壊れにくくなります。

IP方式が向く体制・向かない体制

体制	向く方式
固定IPのオフィスで全員が働く	IP方式
在宅・モバイル・外出が多い	Cookie方式
外部の代理店・制作会社が頻繁にサイトを触る	Cookie方式（または個別にIP登録）
VPNを使う	VPNの出口IPを登録、または Cookie方式

Search Engine Journalでは、リモート主体の組織ではIP方式はほぼ機能しないと指摘されています。日本でも、v6プラスやモバイル回線の普及でIPが安定しない環境は多く、この指摘は当てはまると言えます。

専用URLでCookieを付与しGTMでtraffic_typeを送る方式

流れはシンプルです。

1. 社内メンバー向けに、?exclude_user=1 のようなパラメータ付きの専用URLを用意する
2. そのURLを開いた時に、GTMでCookieを保存する
3. Cookieがあるブラウザのヒットにだけ、GTMの設定でtraffic_typeをinternalとして送る
4. GA4側のデータフィルタで、そのtraffic_typeを除外する

TrackFunnelsでも、IPに依存せずURLパラメータやdataLayerを起点にtraffic_typeを付与する設計が紹介されています。ブラウザ単位なので、端末やブラウザを変えるたびに再度専用URLを開く必要がある点は、運用に織り込んでおきます。

オプトアウトアドオンなど個人単位の手段との使い分け

Google Analytics オプトアウト アドオンは、自分のブラウザからの計測自体を止める手段です。個人が自分のブラウザで使うには手軽ですが、計測が止まるので、サイトの動作確認や検証には向きません。全社での管理には、Cookie方式やIP方式のほうが向きます。

代理店・制作会社のアクセスを誰が管理するか決めておく

代理店や制作会社のアクセスは、発注側と受注側のどちらが除外を管理するのかが曖昧になりがちです。専用URLの発行は誰が行うか、IPを登録するなら誰が更新するか、を最初に決めておきます。月次のレポート運用の中で除外の定義を揃える考え方は、代理店と計測除外の定義を揃える月次合意フレームでも触れています。

GA4の内部トラフィック除外とGoogle広告のIP除外は何が違う？

GA4の内部トラフィック除外は計測データの除外で、Google広告のIP除外は広告配信の除外です。別の設定なので、片方だけでは不十分になります。

GA4・Google広告・Clarityで除外されるものの違い

ツール	除外されるもの	設定場所
GA4	レポートに入るアクセスの計測	データストリーム＋データフィルタ
Google広告	指定IPへの広告の表示	キャンペーンのIPアドレス除外
Microsoft Clarity	記録されるセッション	Clarity側の設定

GA4で自分を除外しても、Google広告で自分に広告が表示され、クリックされれば広告の費用は発生します。逆も同様です。Google広告側の設定については、Google広告のIPアドレス除外が効かない原因と確認手順をご覧ください。Clarityのほうは、Clarityが記録されない原因と確認手順で、記録されない側の原因を扱っています。

内部アクセスがCV数とスマート入札の学習に与える影響の考え方

内部アクセスがコンバージョンとして計測されると、CV数が実態より多く見えます。そのCVをGoogle広告にインポートして自動入札に使っている場合、学習データに内部のアクセスが混ざることになります。影響の大きさはCV数全体に占める内部アクセスの割合次第で、母数が少ないアカウントほど無視できなくなる傾向があります。まず内部のアクセスがCVに何件入っているかを確認し、割合が高ければ優先的に対処する、という順番が現実的です。

再発を防ぐために決めておきたい運用ルール

内部トラフィックの除外は、設定して終わりではなく、IPや体制が変わるたびに壊れるものとして運用を決めておくのが再発防止の基本です。除外のルールは計測設計の一部として扱います。考え方は計測設計を最初に固める考え方にも通じます。

回線変更・オフィス移転・代理店切り替え時の点検項目

• 回線を変更した（プロバイダ・v6プラスの切り替え含む）ら、IPv4/IPv6を再確認して定義を更新する
• オフィスを移転したら、新しいグローバルIPアドレスを登録し、旧IPを整理する
• 代理店や制作会社が替わったら、旧担当のIPや専用URLの扱いを見直す
• 変更後は、Networkタブでtt=internalを必ず確認する

四半期ごとの確認チェックリスト

• 内部トラフィックの定義のIPが、現在の接続IPと一致しているか
• データフィルタの状態が意図どおり（テスト／有効）か
• フィルタのパラメータ値と、定義側のtraffic_type値が一致しているか
• 複数のデータストリームがある場合、それぞれに定義があるか
• GTMとgtagの併用で別経路のヒットが飛んでいないか
• Google広告・Clarityなど他媒体の除外設定も更新したか

よくある質問

Q：GA4のデータフィルタを「有効」にしてから反映されるまでどのくらいかかりますか？

有効化したあとのデータから適用されます。標準レポートでは処理に24〜48時間ほど見ておくのが無難です。具体的な時間は更新されることがあるため、Googleアナリティクス ヘルプで最新の記載をご確認ください。

Q：GA4のデータフィルタは「テスト」のままだとどうなりますか？

「テストデータのフィルタ名」というラベルが付くだけで、レポートからは除外されません。除外を効かせるには、検証したうえで「有効」にする必要があります。

Q：IPv4とIPv6は両方とも登録する必要がありますか？

回線がIPv4とIPv6を使い分けるため、両方登録しておくのが無難です。IPv6は端末ごとに末尾が変わりやすいので、範囲（CIDR表記）での指定を検討してください。

Q：スマホや自宅からの自分のアクセスはどう除外すればいいですか？

モバイル回線はIPが変わるので、IP方式には向きません。専用URLでCookieを付与するCookie方式や、社内Wi-Fiを使って確認する運用を検討してください。

Q：内部トラフィック除外を有効にする前の過去データからも自分のアクセスを消せますか？

遡及適用はされません。過去のデータは、探索のセグメントや比較で自分のアクセスを絞り込んで見ることになります。

Q：データフィルタを有効にしたあと、テストに戻したり除外したデータを復元したりできますか？

除外されたデータは復元できません。状態の変更ができるかどうかは、現行の管理画面と公式ヘルプで、切り替える前に確認してください。

Q：内部トラフィックを除外するとDebugViewで自分のイベントが見えなくなるのはなぜですか？

有効な内部トラフィックのフィルタはDebugViewにも適用されるためです。検証時の対処は、DebugViewにイベントが表示されない時の切り分けをご覧ください。

Q：GA4で内部トラフィックを除外すればGoogle広告の自社クリックも除外されますか？

されません。GA4は計測の除外、Google広告は配信の除外で、設定が別です。広告側のIPアドレス除外も別途設定する必要があります。

真策堂では、計測設計や広告アカウントの設定について、こうした観点でご相談を受けています。内部トラフィックの除外が整理できない、代理店とのルールが曖昧になっている、といった場合は、お気軽にご相談ください。