ObservePointで実現する次世代Web監査とROI最大化 - 第7回 会員ページのPII漏洩リスクを監視する
プライバシーコンプライアンス対応として、同意バナーの設置やプライバシーポリシーの整備を進めている企業は多いでしょう。しかしもう一つ、意識的に取り組むべき領域があります。会員ページ・マイページ・注文完了ページなど、ログインしなければ見えないページでのPII（個人情報）送信の監査です。
目次[非表示]
会員ページこそ、PII送信を確認すべき理由
公開ページでは会員ページに比べPIIが存在する可能性は低いものの、会員ページには氏名・メールアドレス・購入履歴・住所といった本物のPIIが存在します。そこにタグが動いている以上、そのPIIが外部に送信されていないかを確認することはプライバシーコンプライアンスの基本要件です。
GA4やAdobe Analyticsなどの主要な計測プラットフォームでは、メールアドレスなど個人を直接識別できる情報の送信を禁止または制限しています。意図しない送信であっても、状況によっては規制当局から説明や是正を求められる可能性があります。
どのようにPIIが漏洩するのか
実装ミスによる混入： これは実際の監査で発見されているケースです。例えばフォーム送信後のURLに ?email=xxx@example.com が含まれていて、GA4がページURLを自動収集してしまうケース。あるいはdataLayerにユーザー属性を格納していて、タグがその変数を誤って外部に送信しているケース。実装した本人に悪意はなく、テスト時には気づかないまま本番環境で継続して発生していることがほとんどです。
デイジーチェーン経由： 別スクリプトがページ上のデータへアクセスし、意図しない形で外部送信してしまうリスクがあります。こちらは実装担当者も把握していないまま発生しているケースが多く、より発見が困難です。
なぜ意図的に監査しなければならないか
会員ページのPII監査にAuditではなくJourneyを使う理由はここにあります。会員ページへの到達には「ログイン→マイページ遷移→注文履歴表示」といったユーザーのアクションを再現する必要があり、URLをクロールするAuditでは対応できません。Journeyはそのユーザーアクションをステップとして定義し、各アクションに対してRuleを設定できるため、会員ページのPII監査に適しています。
意図的にシナリオを設定してテストしなければ、問題は永続的に見えないまま続きます。
ObservePointのJourneyによるアプローチ
Tag & Variable RulesでPIIパターンを監視： Journeyの各Action（ページ遷移・フォーム送信・クリックなど）に対して、Tag & Variable Ruleを個別に設定できます。正規表現（Regex）を使い「このタグの変数値にPIIパターンが含まれていたら失敗」というRuleを作成し、該当するActionに割り当てます。Journeyを定期実行することで、継続的な自動監視が実現します。
PIIの識別について： RegexによるPII検出はすべての個人情報に対応できるわけではありません。フォーマットが一定なメールアドレスや電話番号は比較的確実に検出できますが、氏名（特に日本語）や住所はパターンが複雑で通常テキストとの区別が難しく、Regexでの自動検出は困難です。検出可能なPIIの種類を理解した上でRuleを設計し、誤検知（False Positive）の検証も並行して行う必要があります。
PII種別 | Regex検出 | 備考 |
メールアドレス |
| フォーマットが一定 |
電話番号 | △ パターン次第 | 形式のバリエーションが多い |
氏名（日本語） |
| 通常テキストと区別できない |
住所 |
| 構造が複雑・可変 |
比較的確実
困難できること・できないことを正確に理解する
シナリオ | 検知 | 手段 |
既知タグがPIIを送信している |
| Journey × Tag & Variable Rules |
承認リスト外のタグの存在 |
| Consent Categories × Alert |
未知タグがPIIを送信している内容 |
| Network Requests Reportで手動確認 |
未知タグへの間接的な対応： デイジーチェーン経由の未知スクリプトがPIIを送信している内容を自動検知することは現時点ではできません。ただし間接的な対策として、Consent Categoriesで承認リストにないタグが動いている事実をAlertで検知することができます。
Network Requests Reportでは、送信先URLやクエリパラメータなどのリクエスト情報を確認できます。ObservePointのAPIを活用すれば取得したデータをスクリプトで処理して自動化することも技術的には可能ですが、Journey × Tag & Variable Rulesで対応できる範囲を先に整理した上で、追加の自動化が必要かを判断するのが現実的です。
多層防御としての設計
会員ページのPII監査は単一の機能で完結しません。Journey Rules・Consent Categories・手動確認を組み合わせた多層防御として設計することが現実的なアプローチです。「どこまで自動化し、どこを人が確認するか」を整理した上で仕組みを構築することが、プライバシーコンプライアンスにおける組織的なガバナンスの第一歩です。
【ObservePoint無料トライアルのご案内】
貴社サイト（50ページ程度）を対象に、ObservePointのAuditを実施し、実際に生成されたレポートをご覧いただきながら、ObservePointのご説明をいたします。ご希望の方は以下の内容を添えて sc-observepoint@ex-ture.jp までご連絡ください。
件名：ObservePointトライアル
本文：
・貴社名
・お名前
・メールアドレス
・URL
・ 気になっている課題（例：タグが管理できていない、アクセシビリティ対応ができていない など）
