監査で変えるべき点は「発火確認」から「送信内容の確認」へ
購入イベントが発火し、金額も正しく、アクセス解析に記録されている。それだけでは、タグの実装が安全だとは判断できません。例えば購入完了ページのURLにメールアドレスが含まれていると、ページURLを収集するタグが、その値を外部へ送ってしまう可能性があります。画面に不具合がなくても、送信データには問題が残り得ます。
TrackingplanのPII監査に関する解説は、タグの設定だけでなく、ブラウザーから出る通信、サーバーが追加する情報、項目の組み合わせを確認する方法を示しています。これは特定の制度改正や新機能の告知ではなく、解析・広告データの点検方法を整理したものです。
ブラウザー側のリクエストに問題がなくても、サーバー側の転送で個人情報が追加されていないことの証明にはなりません。監査の終点はタグの発火ではなく、送信先へ届く最終的なデータです。設定画面で項目を削除しても、別の経路で同じ情報が送られていれば対策は完了しません。
適用条件：名前のないデータも確認対象になる
PIIは、個人を識別できる情報を指す概念です。監査では氏名やメールアドレスだけでなく、個人に結び付けられる情報も対象にします。ただし、法令ごとの個人情報の定義と、解析サービスの送信禁止事項は同じとは限りません。利用先の規約、利用目的、対象地域のルールをそれぞれ確認する必要があります。
組織が本人との対応表を保有している場合、仮名化されたIDも個人に結び付く情報として扱う必要があります。文字列がランダムに見えることや、メールアドレスをハッシュ化したことだけで、安全性を判断しないでください。どのシステムで本人に戻せるのか、誰が照会できるのか、送信先にそのIDが本当に必要なのかが判断材料になります。
単独の項目に問題が見えなくても、組み合わせで識別できる場合があります。例えば郵便番号、正確な購入時刻、商品情報が残っていれば、注文履歴にアクセスできる担当者が購入者と照合できるかもしれません。これは想定例ですが、名前を消すだけでは十分でない理由を示しています。監査では、社内外の人が合理的に入手できる別の情報との照合も考えます。
一般の解析と顧客照合を分ける
広告配信の顧客照合など、本人に結び付く情報を意図的に扱う用途は、一般のアクセス解析とは分けて設計します。必要なのは「同意があるから何でも送る」という判断ではなく、目的、送信先、承認された項目、アクセス権限を定めることです。ハッシュ化や照合性能の指標だけで、プライバシー上の適切さを判断することはできません。
読者への影響：確認範囲はタグ設定の外にも広がる
実務上、監査に関わるのは解析担当者だけではありません。フォームやURLを作る開発担当者、サーバー転送の管理者、CRMやデータ出力の担当者も確認対象を持ちます。以下は一律の禁止リストではなく、自社のデータの流れを調べるための点検項目です。
- ページURL：クエリ文字列にメールアドレス、氏名、会員番号などが入っていないか。不要なパラメーターを除いても、残る値に識別情報がないか確認します。
- イベントの各項目：メールアドレスやそのハッシュ、ログイン名、顧客IDが一般の解析イベントに混ざっていないか確認します。labelのような汎用的な名前の項目も見逃せません。
- 検索・フォーム入力：自由入力には、健康状態、借入、勤務先などの情報が含まれ得ます。入力内容をそのままイベントへ複製していないか調べます。
- 購入情報：注文金額や商品分類を送るだけで目的を満たせるのに、氏名や住所を含む注文オブジェクト全体を転送していないか確認します。
- IPアドレス・端末識別子：取得設定、利用目的、保持期間を確認します。ほかの項目と組み合わせた際の追跡可能性も検討します。
- サーバー転送・CSV出力：ブラウザーの通信だけでなく、外部APIへ送る最終本文や、チーム外へ渡すファイルの列も確認します。
対策は、情報が入り込む場所で行うことが重要です。ダッシュボードから非表示にしても、送信先に保存された情報は消えません。URLが原因ならタグ側の除外設定だけでなく、フォームやリダイレクトが識別情報をURLへ載せる設計も見直します。そうしなければ、別のタグが同じURLを収集するおそれが残ります。
必要な行動：項目単位の監査記録を作る
1．実際の操作で通信を採取する
実務上の進め方として、まず対象を絞り、ログイン、購入、アカウント復旧、検索、入力エラーなどの操作を試します。個人の実データではなく、追跡しやすい目印を付けた架空のテスト情報を使い、ブラウザーの開発者ツールで通信ログを保持します。
リクエストのURLと本文を調べ、URLエンコードされた値は読み取れる形に戻し、入れ子のJSONも確認します。次に、値の供給元であるdataLayerやフォーム、Cookieへさかのぼります。サーバー経由のイベントは、その後に外部へ転送される本文まで追います。タグ管理ツールの設定一覧だけでは、実行時に変化した値を確認できません。
2．項目の意味と必要性を記録する
監査台帳には、項目名、代表的な値、取得元、送信先、目的、担当者、保持期間、同意への依存関係、適用される法的根拠を記録します。直接識別できる情報、組み合わせで識別につながる情報、健康などの機微な属性も区別します。同じ商品分類でも、扱う商品によって意味が変わるため、項目名だけで分類しないことが大切です。
「分析用」「最適化用」だけでは、必要性を判断しにくいでしょう。どの集計や業務で使うのか、その送信先がなぜ必要とするのかまで具体化します。説明できない項目は、いったん送信対象から外して確認する方法が考えられます。自動検出はメールアドレスなどの形を探すのに役立ちますが、独自IDの意味や珍しい属性の組み合わせは人による確認が必要です。
3．同意は表示ではなく通信のタイミングで検証する
バナーが正しく表示されていても、選択前に通信していれば、その送信を後から取り消すことはできません。新しいブラウザーセッションで、未選択、全拒否、解析のみ許可、マーケティング許可、途中で撤回という状態を分けて試します。各状態で、許可された送信先と項目だけが使われているかを確認します。
ここでの厳格な同意制御を前提としたテストでは、未選択時に不要なタグを待機させ、拒否時には対象の送信を止めます。ただし、同意なしの計測を認める例外や地域別の要件は別途確認が必要です。一つのバナー設定を全地域にそのまま適用せず、法務・プライバシー担当者が承認した仕様に沿って検証してください。
サーバーも独立した確認地点です。ブラウザーの広告タグが止まっていても、サーバーイベントや送信待ちキューから外部APIへ転送される可能性があります。同意状態の信号だけを見るのではなく、実際の宛先と本文を突き合わせ、撤回直後と次のページ表示時の両方で停止を確かめます。
4．修正は送信先で確認し、再発防止まで残す
改善策としては、自由入力を粗い分類に置き換える、注文オブジェクト全体ではなく必要な集計値だけを送る、送信先ごとに許可した項目だけを通す、といった方法があります。必要な識別子を扱う場合も、本人との対応情報へのアクセスを限定し、一般イベントの情報と分離します。
漏えいが見つかった場合は、影響する転送経路の停止、送信済みデータの削除依頼、必要に応じた認証情報の更新を検討します。証拠は閲覧制限された場所に保存し、広く見られるチケットへ生の個人情報を貼り付けないようにします。削除依頼の回答や、未解決の複製があるかも記録に残します。
最後に、問題が起きた操作を再現し、禁止した項目が最終送信先へ届かなくなったことを確認します。失敗したデータの条件、期待結果、担当者を回帰テストとして保存し、リリース後も再実行します。利用頻度の低い復旧画面などは、自然なアクセスを待たずにテスト操作を行う必要があります。
最初から全タグを対象にするのが難しければ、送信量の多い三つの宛先と直近の変更に関係する操作から始める方法があります。完了の基準はスキャン数ではありません。各項目を送る理由を説明でき、受信者を制御でき、修正を証拠で示せることです。項目の責任者と監査記録の承認者を決め、次のリリース後の再確認まで予定に入れましょう。
