心地よい思い込み
メールアドレスをハッシュ化し、電話番号もハッシュ化すれば、そのリストは「匿名化済み」――気軽にメールで送れて、代理店に渡せて、プライバシー規制の対象外。この思い込みは多くのマーケティングチームで重い役割を担っています。そして法規制の面でも数学の面でも、間違っています。
規制当局が実際に述べていること
GDPRは前文第26項でこの点を決着させています。「仮名化を受けた個人データであって、追加的な情報を用いることにより自然人に帰属させうるものは、識別可能な自然人に関する情報とみなされるべきである」。2025年1月に採択された欧州データ保護会議（EDPB）の仮名化に関するガイドライン01/2025も、まさにこの出発点の上に組み立てられています。
ハッシュ化は仮名化です――適切な追加情報を持つ者であれば元に戻せる変換です。この枠組みにおいて、ハッシュ化された顧客データは依然として個人データです。グレーゾーンではありません。引用した一文そのものが枠組みなのです。
算術が示していること
暗号学的ハッシュは代数的に逆算できません――心地よい思い込みのうち、そこまでは正しいのです。しかし電話番号は逆算する必要がありません。推測すれば足ります。国内の番号計画は現代の計算能力からすれば小さな空間です。ありうる番号をすべてハッシュ化し、リストと突き合わせれば終わりです。これは理論上の攻撃ではなく、単なる参照表です。
メールアドレスはもう少し抵抗します――空間がより広く、偏りもあるためです――が、既知のアドレスなら即座に確認できます。jane@example.com を持っている人なら誰でも、それをハッシュ化してあなたの「匿名」ファイルに彼女がいるかどうかを試せます。静かな失敗はメンバーシップの露見です。そのリストは、当人たちをすでに知っている相手に対して誰が入っているかを漏らします。
ソルトを足せば済む話ではない理由
標準的な強化策であるソルト――ハッシュ化の前に秘密の値を混ぜること――は、広告プラットフォームのマッチングが最も許容できないものです。マッチングが成立するのは、双方が同じ入力を同じ方法でハッシュ化するからです。あなたしか知らないソルトは、あなたにしか作れないダイジェストを生み、何とも一致しません。アップロード用のハッシュ化は設計上ソルトなしであり、つまり上記の弱点を恒久的に抱え込みます。（ソルトあり・なしの全体像は別のガイドで扱っています。）
だからハッシュ化されたリストは、その実態どおりに扱う
- 生のリストと同じアクセス制御を――同じフォルダ権限、同じ共有ルール。
- ハッシュ化したら作業の痕跡を消す――ハッシュ列をコピーし、値として貼り付け、外に出るファイルからは生の列を削除する。
- ハッシュ化ファイルは意図をもって共有する――生ファイルに必要だったのと同じ取り決めのもとで。「ハッシュ化してあるから」と気軽に渡さない。
- 生ファイルとハッシュ化ファイルは離しておく――両方の列が並んだスプレッドシートは、あらかじめ作られた参照表そのものです。
Hash Dataの位置づけ
以上のいずれもハッシュ化に反対する議論ではありません。プラットフォームがそれを求めており、生のPIIをアップロードファイルから排除することは明確に望ましいからです。これは、目を開けたままそれを行うべきだという議論です。Hash DataはGoogle スプレッドシートの中でハッシュ化を行います。つまり変換は、顧客データを貼り付けるウェブツールではなく、すでにあなたが管理しているシートの中で起こります。
出典
- GDPR前文第26項 – 匿名データには適用されない – 2026年9月2日閲覧
- EDPBガイドライン01/2025（仮名化） – 2026年9月2日閲覧