GA4では、Universal Analyticsで使っていたanonymize_ipの設定は必要ありません。Googleの説明では、Google Analyticsの収集処理はIPアドレスを位置情報の判定などに使った後、データが記録される前に破棄します。GA4のレポートやエクスポートへ個別のIPアドレスが保存されることもありません。ただし、これはGoogle Analytics内の処理についての説明です。広告連携や自社サーバーを含めたプライバシー対応が、これだけで完了するわけではありません。

この記事は2018年に、Universal AnalyticsとAdobe AnalyticsでIPアドレスを匿名化する方法として公開しました。Universal Analyticsの終了に伴い、anonymize_ip、aip=1、ビューのIPフィルタに関する旧手順はGA4では使いません。新旧の違いが分かるように内容を更新します。

結論

製品 IPアドレスの扱い 利用者側の設定
GA4 Analyticsの収集処理では、位置情報の判定などに使用後、記録前に破棄。レポートやエクスポートへ個別IPを保存しない anonymize_ipは不要
Universal Analytics IPマスキングは任意設定だった サービス終了。旧anonymize_ip手順は使わない
Adobe Analytics IPアドレスを収集し、Data WarehouseやData Feedで扱える構成がある 収集方式と処理順に合わせて匿名化を設定する
自社サーバー・CDN・サーバーサイドGTM 製品と設定によりアクセスログへ残る ログ設定、権限、保存期間、マスキングを個別に確認する

「GA4でIPアドレスが保存されない」ことと、「WebサイトのどこにもIPアドレスが保存されない」ことは同じではありません。

さらにGoogleは2026年、Google TagまたはSDKが取得したIPアドレスを暗号化し、リンク済みのGoogle Adsへ送る変更を予告しました。IPアドレスに関する制御の提供時期は、この記事の更新時点ではまだ確定していません。したがって、GA4のレポートへIPアドレスが保存されないことと、Google Adsを含むデータフローは分けて確認する必要があります。現行の説明と今後の変更は、Googleのデータ制御に関する案内で確認できます。

GA4はIPアドレスをどう扱うか

ブラウザがGA4の収集サーバーへ接続する以上、通信時には送信元IPアドレスが必要です。Googleは、GA4でIPアドレスを次の処理に使うと説明しています。

  • 最寄りのデータ収集拠点の判定
  • 国、地域、市区町村など、おおよその位置情報の導出
  • サービスのセキュリティ保護

その後、IPアドレスはデータが記録される前に破棄されます。GA4の管理画面、探索、Data API、BigQueryエクスポートから個別のIPアドレスを取得することもできません。

Googleの地域別データ収集に関する説明では、IPアドレスは収集時に位置情報を導出した後、データセンターやサーバーへログが記録される前に破棄されるとされています。

EU、スイス、英国のユーザーについては、地域内のサーバーで位置情報の導出とIPアドレスの破棄を行ってから、処理用サーバーへ転送する仕組みも説明されています。

anonymize_ipはUniversal Analyticsの設定

以前のUniversal Analyticsでは、次の設定をタグへ追加しました。

gtag('config', 'UA-XXXXXXXX-X', {
  anonymize_ip: true
});

収集リクエストにaip=1を付け、IPv4の末尾オクテットやIPv6の一部をゼロに置き換える機能でした。

これはUAプロパティ向けの旧仕様です。GA4のMeasurement IDへ同じ設定を足して、匿名化の成否をaip=1で確認する必要はありません。Googleの旧IPマスキング解説にも、GA4ではIPアドレスをログ・保存しないためマスキングは不要と明記されています。

古いGTMコンテナに次の設定が残っている場合は、UAタグと一緒に整理対象です。

  • anonymizeIpフィールド
  • anonymize_ipパラメータ
  • aip=1を前提にした検証手順
  • UAビューのIP除外フィルタ

GA4で確認すべきプライバシー設定

IP匿名化のスイッチを探す代わりに、GA4では収集するデータと利用目的を確認します。設定は主に「管理 > データの収集と修正」に集まっています。

1. 詳細な位置情報とデバイスデータ

「管理 > データの収集と修正 > データ収集」の下部にある「詳細な位置情報とデバイス データの収集」で、国・地域ごとに収集を無効にできます。無効にすると、市区町村、おおよその緯度・経度、ブラウザのマイナーバージョン、端末モデル、画面解像度などが収集されなくなります。国レベルの位置情報は残ります。

国レベルの分析だけで十分なのに都市や端末モデルまで保持している場合は、データ最小化の観点から見直せます。ただし、地域レポートや広告のモデリングへ影響する可能性があります。

2. Google Signalsと広告連携

同じ「データ収集」画面の「Google シグナルのデータ収集」を確認します。2026年6月15日以降、Google Signalsの役割は、GA4で収集したデータをGoogleへログインしているユーザーの情報と関連付け、クロスデバイスなどの行動レポートに利用するかどうかの制御へ限定されました。この関連付けが分析目的に本当に必要かを確認し、有効にする場合はプライバシーポリシーでも利用目的を説明します。

一方、Google Adsで使うCookieや識別子の収集・利用は、Google Ads側のConsent Modeで制御します。広告パーソナライズの要否をGoogle Signalsだけで判断しないようにします。

3. データ保持期間

「管理 > データの収集と修正 > データの保持」で、イベントデータの保持期間を選びます。標準プロパティでは2か月または14か月です。この期間を過ぎたデータは探索レポートで使えなくなりますが、標準レポートの集計値には影響しません。長期分析はBigQueryエクスポート側で保持し、GA4本体は目的に必要な最短へ寄せるのがデータ最小化の基本です。

4. Consent Mode

IPアドレスを保存しないことは、Cookieや広告目的の同意を不要にするものではありません。GA4はClient IDなどのオンライン識別子、端末情報、閲覧イベントを扱います。

Consent Mode自体は、同意を求めたり取得したりする仕組みではありません。対象地域と利用目的に応じてCMPまたは同意UIを用意し、そこで得た選択をGoogleタグへ伝えるために、analytics_storage、ad_storage、ad_user_data、ad_personalizationの4状態を含むConsent Mode v2を実装します。

analytics_storageは分析、残る三つは主に広告で使う同意タイプです。広告連携を使っているからといって、一律にgrantedへ設定するものではありません。利用している機能とユーザーの選択に応じて状態を更新します。実装後は「管理 > データの収集と修正 > 同意の設定」で、同意シグナルがGA4へ届いているかを確認できます。実装と検証の手順はCookie同意バナーの実装方法にまとめました。

5. 不要な個人データの送信防止

IPアドレス以外の個人データが、URL、ページタイトル、検索語、イベントパラメータへ入ることがあります。多いのは、フォーム送信後のURLに付いたメールアドレスや会員番号、サイト内検索語に入力された氏名、エラーメッセージに含まれた入力値です。

GTMのプレビューとGA4のDebugViewでpage_locationや主要イベントのパラメータを確認し、BigQueryエクスポートがあるなら@を含む値をURLとパラメータから検索すると網羅的に点検できます。混入が見つかったら、発生源のフォームやリンクを直したうえで、送信済みのデータは「管理 > データ削除リクエスト」で削除を申請します。

Google Analyticsの規約では、個人を特定できる情報を送信できません。この点検の方が、GA4へanonymize_ipを追加するより重要です。

GA4には、メールアドレスらしい文字列と指定したURLクエリパラメータを、イベント送信前に編集するデータ編集機能もあります。ただし、これはクライアント側で行うベストエフォートの保険です。想定外の形式や別のフィールドまで完全に検出するものではないため、個人データを生成・送信しない実装を先に行い、その補助として使います。

社内アクセスのIP除外はどうするか

GA4のIP除外は、「内部トラフィックの定義」と「データフィルタ」の2段階で設定します。IPアドレスを保存しない仕様と矛盾しないのは、保存済みデータを後から除外するのではなく、収集時に送信元IPを条件と照合してtraffic_typeパラメータを付け、それをフィルタする仕組みだからです。

手順は次のとおりです。

  1. 「管理 > データの収集と修正 > データストリーム」で対象ストリームを開き、「タグ設定を行う > すべて表示 > 内部トラフィックの定義」でルールを作る。社内拠点のIPアドレスを「等しい」「範囲内（CIDR）」などの条件で登録すると、一致したイベントにtraffic_type=internalが付く
  2. 「管理 > データの収集と修正 > データフィルタ」で「内部トラフィック」フィルタを作り、まず状態をテストにする
  3. テスト中は、レポートをディメンション「テストデータのフィルタ名」で絞ると、除外予定のデータだけを確認できる。社内アクセスが正しく判定され、一般の訪問が巻き込まれていないことを数日確認する
  4. 問題なければ状態を有効にする

運用上の注意が3つあります。有効化したフィルタは過去データへ遡って適用されず、有効化後に除外されたデータは後から復元できません。在宅勤務、VPN、動的IPでは条件が安定しないため、IPだけに頼らず、GTMからtraffic_typeを直接送る社内用Cookie方式の併用も検討します。開発・ステージング環境は、IPではなく別プロパティやデベロッパートラフィックフィルタ（debug_mode）で分ける方が確実です。

サーバーサイドGTMを使っている場合

ブラウザからサーバーサイドGTMへ送ると、GA4の前に自社管理のサーバーがリクエストを受けます。Cloud Run、ロードバランサー、CDN、WAFなどのアクセスログへIPアドレスが残る可能性があります。

確認事項は次の通りです。

  • どのレイヤーでIPアドレスがログに記録されるか
  • 誰がログを閲覧できるか
  • 保存期間は何日か
  • デバッグログを本番で常時有効にしていないか
  • 他のデータと結合できる識別子が含まれていないか
  • マスキングまたはログ除外が可能か

サーバーサイドGTMを導入するとデータの制御点は増えますが、自社が管理すべきログも増えます。

Adobe AnalyticsのIPアドレス設定

Adobe AnalyticsはGA4と仕様が異なります。

Analytics本体の扱いは、実装方式に関係なく同じ

Adobe Analyticsは受信したリクエストからIPアドレスを取得し、IP AddressディメンションをData Warehouseで利用できます。Data FeedにもIP関連列があります。これはAppMeasurementでも、Web SDK（alloy.js）でEdge Networkを経由しても変わりません。

Report Suiteには、処理順の異なる二つの設定があります。

設定 処理順と影響
Replace the last octet of IP addresses with 0 IPアドレスの末尾オクテットを0へ置換する。位置情報の判定前に行われるため、地域データの精度へ影響する可能性がある
IP Obfuscation IPアドレスを難読化または削除する。通常は位置情報、IPフィルタ、Botルールの処理後に行われ、Data Warehouseを含むAnalytics全体に適用される。元のIPは復元できない

Web SDKには、データストリームの難読化もある

Web SDKの場合は、Edge Networkのデータストリームにも詳細オプション「IPアドレスの難読化」（なし・部分・完全）があります。Edgeから各ソリューションへ転送する前にIPを難読化する設定です。

Adobeのデータストリーム設定ドキュメントでは、次のように説明されています。

  • Edge Network自身の位置情報判定は難読化前に行われる。都市などのジオ情報を制限したい場合は、Geo Lookupを別に設定する
  • 「完全」を選ぶと、Adobe Analyticsには空のIPアドレスが渡る。Analyticsの位置情報、IPフィルタ、Botルールなど、IPに依存する処理へ影響する
  • 「部分」または「なし」なら、Analytics側のReport Suite設定でさらに難読化できる
  • Adobe Target（Web SDK 23.4以降）では、データストリーム側の設定がTarget側の難読化設定より優先される

AppMeasurementならReport Suite内の処理順を確認すれば足ります。Web SDKでは、Edge NetworkとReport Suiteの二段階があるため、どこで難読化するかを先に決めます。ソリューションごとに挙動が違ううえ、仕様は更新されるため、実施前に現行ドキュメントと管理画面で確認します。

実施前に確認すること

この違いを無視して「IPを匿名化する」とだけ決めると、必要な地域データを失ったり、IPに依存する社内アクセス除外が動かなくなったりします。まず、AppMeasurementとWeb SDKのどちらで収集しているか、匿名化をEdgeとAnalyticsのどちらで行うかを確認します。その上で、次を整理します。

  • 地域ディメンション、IP除外、Botルールに必要な処理順
  • Data WarehouseとData FeedでIPアドレスを必要としている利用者
  • 過去データへ遡及しないことと、元のIPアドレスを復元できないこと
  • Report Suiteごとの設定差
  • EMEA向けReport Suiteを含む地域別設定

現行仕様と処理順は、Adobe Experience LeagueのIP AddressディメンションとGeneral Account Settingsで確認してください。

「IPアドレスを保存しない」だけでは足りない

プライバシー対応では、特定の一項目だけでなく、データフロー全体を見ます。

  1. どの目的で計測するか
  2. どのイベントと識別子を収集するか
  3. どのサービスと地域へ送るか
  4. Cookieや広告利用についてどう同意を得るか
  5. 誰がデータへアクセスできるか
  6. 何日保存するか
  7. 削除や開示の依頼へどう対応するか

IPアドレスが保存されなくても、Client ID、User-ID、広告識別子、詳細な行動履歴を組み合わせれば、個人または端末に結び付く可能性があります。

よくある質問

GA4でanonymize_ipを設定する必要はありますか？

不要です。anonymize_ipはUniversal Analytics向けの旧設定で、GA4はIPアドレスを位置情報の導出などに使った後、データが記録される前に破棄します。GTMに残っているanonymizeIpフィールドやaip=1前提の検証手順は、UAタグと一緒に整理してください。

GA4はIPアドレスを保存していますか？

保存しません。管理画面、探索、Data API、BigQueryエクスポートのどこからも個別のIPアドレスは取得できません。ただし、サーバーサイドGTMやCDNなど、GA4の手前にある自社管理のレイヤーのアクセスログには残る可能性があります。なお、Googleは2026年に、タグが取得したIPアドレスを暗号化してリンク済みのGoogle Adsへ送る変更を予告しています。GA4のレポートに保存されないことと、Google Adsを含むデータフローは分けて確認してください。

IPアドレスが保存されないなら、同意バナーも不要ですか？

別の話です。GA4はClient IDなどのオンライン識別子、端末情報、閲覧イベントを扱うため、対象地域と利用目的によってはCookieや広告目的の同意が必要です。IPアドレスは、確認すべき項目の一つにすぎません。

まとめ

「GA4にIPアドレスが保存されるか」だけで判断せず、ブラウザから各サービス、ログ、レポートへ至るデータフロー全体を棚卸しすることが重要です。