計測データに氏名を送ってはいけない｜規約違反を避ける設計

「誰が見たか分かれば便利だ」という発想から、計測にメールアドレスを渡す設定が作られることがあります。しかし、これは利用規約で明確に禁じられている行為です。便利さの問題ではなく、アカウントの停止やデータの削除につながる領域の話になります。

何が禁じられているのか

まず、規約の内容を正確に押さえます。曖昧な理解のまま設計すると、判断を誤ります。

Google アナリティクスの利用規約では、個人を特定できる情報の送信が禁止されています。

具体的には、氏名、社会保障番号、メールアドレス、および類似のデータが挙げられています。

さらに、個人の携帯電話番号や、その他の個人識別情報も対象に含まれます。

加えて、1平方マイル未満の地域を特定できる正確な場所の情報も禁止の対象とされています。

この最後の項目は見落とされがちです。詳細な位置の情報を送る設計は避ける必要があります。

禁止の理由は、利用者の保護にあります。解析の目的は個人の特定ではありません。

一方で、個人情報を含まない識別子であれば使用できるとされています。ここが対策の鍵になります。

社外で保管している識別子と同じものを、解析の側でも使うことができます。

つまり、結び付けること自体が禁じられているのではなく、そのままの形で送ることが禁じられています。

この区別が分かれば、必要な分析を諦めずに規約を守る設計が組めます。

経路1：URLとクエリのパラメータ

意図せず混入する経路を順に見ます。最も多いのがURLです。

ページのURLやクエリのパラメータに、個人情報が誤って含まれる場合があると指摘されています。

典型が、会員の設定の画面です。URLにメールアドレスが含まれる作りになっていることがあります。

この画面が閲覧されるたびに、メールアドレスが解析の側へ送られます。

フォームの送信の後に表示される完了の画面でも、同様のことが起きます。

入力した内容がクエリのパラメータとして引き継がれ、URLに表示される作りがあります。

この場合、氏名、メールアドレス、電話番号がまとめて送られる状態になります。

キャンペーンのパラメータに個人の情報を入れてしまう例もあります。配信の識別のためです。

メールの配信で受信者を識別する値をURLに付ける場合、その値が個人を特定できるなら問題になります。

対処として、URLに含まれる個人情報を独自の識別子に置き換える方法が示されています。

たとえば、設定の画面のURLでメールアドレスの部分を番号に置き換える形です。

経路2：ページのタイトル

2つ目の経路が、ページのタイトルです。URLより見落とされやすい部分になります。

ページのタイトルにも、個人情報が誤って含まれる場合があると指摘されています。

よくあるのが、会員の画面で「山田様のマイページ」といった形式のタイトルを使う場合です。

この形式だと、氏名が解析の側へ送られます。URLは対策していても、タイトルが残ります。

同様に、受注の確認の画面で購入者の名前をタイトルに入れる作りもあります。

対処は、タイトルから個人の情報を外すことです。「マイページ」だけで機能は足ります。

画面上の表示としては名前があってよいのですが、タイトルの要素には入れません。

すでに運用している場合は、送信の前にタイトルを変更する方法があります。

計測の実装を調整し、送信の前にURLとタイトルを変更するという対処が示されています。

この方法なら、サイト側の作りを変えずに対応できます。改修の範囲が小さくなります。

ただし、恒久的にはサイト側の作りを直すほうが確実です。実装の変更は見落としが起きます。

見落としが起きる理由は単純です。画面が増えるたびに、対処の対象も増えていくからです。

サイト側の作りを直せば、新しい画面にも同じ規則が引き継がれます。対処の対象が増えません。

経路3：入力欄と検索の語句

3つ目の経路が、利用者が入力した内容です。ここは制御が難しい領域になります。

検索の欄やフォームの入力欄に、利用者が個人情報を入力する場合があります。

サイト内の検索の語句を計測している場合、入力された内容がそのまま送られます。

利用者が自分のメールアドレスや注文の番号を検索の欄に入れることは、実際に起こります。

こちらが求めていなくても、入力される以上は混入します。防ぐ設計が要ります。

対処として、送信の前に利用者が入力した情報から個人情報を削除する方法が示されています。

具体的には、送信する値を検査し、メールアドレスの形式や数字の並びを検出して置き換えます。

完全な検出は困難ですが、代表的な形式を弾くだけでも混入は大きく減ります。

あわせて、入力欄の案内文で個人情報を入力しないよう促す方法もあります。

ただし、案内文だけでは防げません。技術的な対処と併用します。

問い合わせのフォームでは、そもそも入力の内容を計測に送らない設計にします。

経路4：独自の項目と識別子

4つ目の経路が、独自に定義した項目です。ここは意図的に設定されるため、判断が問われます。

混入の経路として、利用者IDの上書き、キャンペーンのパラメータ、サイト内検索の語句、イベントのラベルが挙げられています。

利用者IDに、社内で使っている顧客の番号を入れる設計は広く行われています。

この番号が個人情報を含まないなら問題ありません。社外のデータと同じ識別子を使えるとされています。

問題になるのは、識別子としてメールアドレスや会員の名前を使う場合です。

「一意だから」という理由でメールアドレスを識別子に選ぶ設計は、規約に反します。

イベントのラベルも同様です。行動の記録に、入力された内容をそのまま入れる設計は避けます。

たとえば、資料の請求のイベントに請求者の会社名や氏名を入れる形です。

この設計は分析には便利ですが、便利さと規約の遵守は別の問題です。

必要な分析は、識別子を介して社内のデータと突き合わせることで実現できます。

解析の側には識別子だけを送り、氏名は社内のデータベースで対応させる。この形が基本になります。

4つの経路を並べる

混入の経路を、確認しやすい形に並べます。点検の際の観点として使えます。

経路	起きやすい場面	対処の方向
URLとクエリ	会員の設定の画面、フォームの完了の画面	識別子に置き換える、パラメータを削除する
ページのタイトル	氏名を含むタイトルの形式	タイトルから個人の情報を外す
入力欄と検索の語句	サイト内検索、フォームの計測	送信の前に検査して置き換える
独自の項目と識別子	利用者IDにメールアドレスを使う設計	個人情報を含まない識別子を使う
取り込むデータ	社外のデータを解析へ取り込む場面	取り込む前に内容を確認する

表の5行目は、経路というより手作業の場面です。取り込むデータの事前の確認が推奨されています。

顧客の一覧を解析へ取り込む場合、氏名やメールアドレスの列が含まれていないかを確認します。

• 対処は1つでは足りません。4つの経路すべてを点検する必要があります
• サイトの改修のたびに、新しい経路が生まれていないかを確認します

なぜ問題になるのか

規約に反した場合、実際に何が起きるのかを整理します。ここを軽く見ないためです。

最も直接的なのが、アカウントに対する措置です。規約への違反は解除の理由になり得ます。

解析のアカウントが使えなくなると、過去のデータも含めて参照できなくなります。

次に、送信されたデータの削除が必要になります。削除の申請の仕組みが用意されています。

削除の対象となる期間のデータは、分析に使えなくなります。過去の比較ができなくなります。

さらに、社内の情報の管理の観点でも問題になります。個人情報が外部の仕組みへ渡っています。

この状態は、自社の個人情報の取り扱いの方針と矛盾する可能性があります。

顧客に説明している内容と、実際の運用が異なる状態は、説明の責任の問題につながります。

加えて、権限を持つ人が個人情報を閲覧できる状態になります。解析の権限は、通常この前提で設計されていません。

委託先や他部署に閲覧の権限を渡している場合、意図しない範囲に個人情報が届きます。

これらを踏まえると、便利さのために許容できる範囲ではないことが分かります。

判断の軸は1つです。その設定が止まったときに失うものと、続けたときに失う可能性のあるものを比べる。

前者は分析の利便性、後者は蓄積したデータそのものです。比べるまでもなく、後者のほうが大きくなります。

対策1：送る前に取り除く

ここから対策を扱います。最も基本となるのが、送信の前に取り除く設計です。

計測の仕組みでは、データを送る前に内容を加工できます。この段階で処理します。

URLとタイトルを、送信の前に書き換えるという方法が示されています。

具体的には、メールアドレスの形式に合致する部分を検出し、別の文字列に置き換えます。

同様に、電話番号の形式や、長い数字の並びも検出の対象にします。

完全な検出は困難ですが、代表的な形式を押さえるだけで大部分は防げます。

処理は、タグの管理の仕組みで実装できます。サイトの改修が不要な場合が多くあります。

実装した後は、実際に該当する画面を開いて、送られる値を確認します。

確認せずに実装を終えると、想定と違う形で送られていることがあります。

確認の方法は、計測の仕組みが提供する検証の機能を使います。実際の送信の内容を目で見て確かめます。

この検証を、サイトの改修のたびに行います。新しい画面で混入が起きていないかを確かめます。

対策2：管理画面の設定を使う

実装を変えずに対応できる部分もあります。管理画面の設定を使う方法です。

管理画面には、メールアドレスの自動削除の設定が用意されているとされています。

この設定を有効にすると、送られてきたデータからメールアドレスが取り除かれます。

あわせて、URLのクエリのパラメータを削除する設定も利用できます。

不要なパラメータを指定して削除すれば、そこに含まれる情報は記録されません。

これらの設定は、管理画面から数分で有効にできます。最初に行うべき対処になります。

ただし、設定だけでは万全ではありません。氏名や電話番号は自動では検出されません。

また、独自の項目に入れた情報も、設定では取り除かれません。

したがって、設定と実装の両方で対処します。どちらか一方では不十分です。

設定の有効化は、既存のアカウントでも今すぐ行えます。過去のデータには適用されません。

過去のデータについては、次の節で扱う削除の申請が必要になります。

設定を有効にした日付は記録しておきます。以降のデータは対処済みという判断ができます。

対策3：識別子に置き換える

分析の必要性を満たしつつ規約を守る方法が、識別子への置き換えです。

個人情報を含まないIDであれば、社外のデータと同じ識別子を使えるとされています。

つまり、社内の顧客の管理の番号を解析の側でも使うことができます。

この番号があれば、解析で見た行動と社内のデータを後から突き合わせられます。

突き合わせは社内の環境で行うため、解析の側に個人情報を送る必要がありません。

URLに含まれる個人情報も、同じ考え方で置き換えられます。

設定の画面のURLでメールアドレスの部分を番号に置き換える例が示されています。

番号は、その番号自体から個人が特定できないものにします。連番や無作為な文字列が向きます。

メールアドレスを変換した値でも、変換の方法が推測できる形式は避けます。

この設計にすると、分析の自由度を保ったまま規約を守れます。

実装には開発の側の協力が要ります。設計の段階で相談しておくと、後の改修が減ります。

相談の際に伝えるのは1点です。解析の側には、個人を特定できない番号だけを渡したいという要件です。

この一文があれば、開発の側は実現の方法を選べます。細かい実装まで指定する必要はありません。

すでに送ってしまった場合

過去に個人情報を送っていたことが判明した場合の対処を整理します。

まず、送信を止めます。原因となっている設定や実装を特定し、修正します。

止める前に削除の申請をしても、送信が続いていれば意味がありません。順序が重要です。

次に、いつからいつまで、どの範囲のデータに含まれていたかを確認します。

範囲が分からないと、削除の申請の対象を決められません。

すでに送信されたデータについては、削除の申請を行うことができるとされています。

申請の手続きと対象の範囲は、提供元の案内に従います。

削除により、その期間のデータが使えなくなる可能性があります。影響を事前に把握します。

並行して、社内への報告を行います。個人情報の取り扱いに関わる事案として扱います。

報告の要否や範囲は、社内の規程に従います。判断に迷う場合は法務に確認します。

対処の記録を残します。何が起き、いつ止め、どう対処したかを書きます。

この記録は、再発の防止と、後の説明の両方に使えます。記録がないと、対処したこと自体を示せません。

点検の手順

定期的に点検する手順を示します。半年に一度を目安とします。

1つ目から3つ目は、記録されたデータを目で見る作業です。一覧を並べ替えると異常が見つかります。

メールアドレスの形式は目立つため、一覧を眺めるだけで気づけます。

4つ目は、設定の一覧を見る作業です。過去に誰かが設定した項目が残っていることがあります。

設定した本人が異動している場合、目的が分からない項目が残ります。この機会に整理します。

点検は、サイトの大きな改修の後にも行います。改修で新しい経路が生まれることがあります。

点検の項目

点検の際に確認する項目を、一覧として整理します。

• URLに個人情報が含まれる画面がないか（会員の設定、完了の画面など）
• ページのタイトルに氏名を含む形式がないか
• サイト内検索の記録にメールアドレスや番号が入っていないか
• 利用者の識別子に個人情報を使っていないか
• イベントの項目に入力された内容をそのまま入れていないか
• メールアドレスの自動削除の設定が有効か
• 不要なクエリのパラメータの削除が設定されているか
• 解析へ取り込んでいるデータに個人情報の列がないか

6つ目と7つ目は、管理画面で今すぐ確認できます。まずここから手を付けます。

残りの項目は、データの一覧を見る作業になります。半日程度で一通り確認できます。

確認の結果は記録します。次回の点検で、前回からの変化が分かります。

問題が見つかった場合は、修正の期限を決めます。期限のない課題は放置されます。

修正の優先順位は、混入している情報の種類で決めます。氏名やメールアドレスが最優先です。

点検の担当も決めます。解析の管理の責任者が兼ねるのが自然です。設定を触れる人が確認します。

担当が決まっていないと、点検は誰の作業でもなくなります。周期より先に、担当を決めます。

やりがちな失敗

この領域で起きやすい失敗を挙げます。いずれも悪意なく行われます。

• メールアドレスを一意の識別子として使う（規約に反する。番号に置き換える）
• 会員の画面のタイトルに氏名を入れる（URLだけ対策しても残る）
• フォームの完了の画面のURLに入力の内容を引き継ぐ
• イベントの項目に、問い合わせの内容や会社名をそのまま入れる
• 解析へ顧客の一覧を取り込む際、氏名の列を残したままにする
• 設定だけ行い、実装の側は確認しない（独自の項目は設定では防げない）

1つ目が最も多く見られます。一意であることと、使ってよいことは別です。

4つ目は、分析の要望から生まれます。営業が知りたい情報を入れてしまう構造です。

この場合、識別子を介して社内で突き合わせる方法を提案します。要望自体は満たせます。

6つ目は、対処したつもりで残っている状態です。両方の確認が必要になります。

社内で共有しておくこと

この問題は、担当者1人が知っていても防げません。関わる人に共有します。

• 計測の設定を行う担当と、サイトを改修する開発の側の双方に共有する
• 新しい計測を追加する際は、個人情報を含まないかを確認する工程を入れる
• サイトの改修の要件に、URLとタイトルに個人情報を含めない旨を記載する
• 解析へデータを取り込む作業は、確認する人を決めて実施する
• 問題を見つけた場合の連絡先と、対処の手順を決めておく

3つ目が実務では効きます。改修の要件に書いておけば、作る段階で防げます。

後から見つけて直すより、作る前に伝えるほうが費用も時間もかかりません。

開発の側にとっては、伝えられていない要件は存在しないのと同じです。

要件の書き方は1行で足ります。禁止の理由まで書くと、判断の質が上がります。

また、外部に制作を委託する場合も、同じ要件を仕様に含めます。

委託先は自社の規約の事情を知りません。明示しなければ考慮されません。

分析の要望とどう折り合うか

最後に、現場の要望との折り合いについて触れます。禁止するだけでは進みません。

営業や経営から「誰が見たか知りたい」という要望が出るのは自然なことです。

この要望を否定するのではなく、別の手段で満たす道を示します。

解析の側には識別子だけを送り、社内のデータベースで氏名と対応させる。これが基本の形です。

突き合わせの作業は、社内の環境で行います。個人情報は外へ出ません。

この方法なら、知りたい情報は得られます。手間は増えますが、規約の問題は生じません。

あるいは、顧客に接触する仕組みの側で行動の記録を持つという設計もあります。

解析ツールは全体の傾向を見るために使い、個人の追跡は別の仕組みで行う。役割を分けます。

役割を分けると、それぞれの仕組みの制約に沿った運用ができます。

1つの仕組みですべてを賄おうとすると、どこかで無理が生じます。

説明する際は、規約の話だけでなく、代替の手段を同時に示します。そうすれば理解が得られます。

代替の手段を示さずに禁止だけを伝えると、現場は別の経路で同じことをやろうとします。

たとえば、計測の担当が止めても、広告の担当が別の仕組みで個人情報を送るといった形です。

したがって、要望の背景にある「何を知りたいのか」をまず聞きます。手段の話は後です。

知りたいのが「どの会社が見に来たか」であれば、個人の特定は必要ありません。

要望を分解すると、個人情報を送らずに満たせる場合がほとんどです。

分解の作業に30分かければ、規約の問題も要望の不満も同時に解消できます。

この会話は、計測の設計を始める段階で行います。実装の後では、作り直しになります。

まとめ

計測データへの個人情報の混入についての要点は、氏名やメールアドレスをそのまま送ることは禁じられている一方、識別子への置き換えなら使えることです。混入の経路はURLとクエリ、ページのタイトル、入力欄と検索の語句、独自の項目の4つ。管理画面の設定と、送信の前に取り除く実装の両方で対処し、半年に一度は記録された一覧を目で確認する。すでに送っていた場合は、まず送信を止めてから削除の申請を検討する。まずはサイト内検索の記録を並べて、メールアドレスが混じっていないか確かめてみてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。