オーディエンスアップロードにおけるソルトあり・なしのハッシュ

矛盾して見える2つのルール

セキュリティの入門書はどれもこう言います。ソルトなしのハッシュを保存してはならない、と。一方、広告プラットフォームのアップロード手順はどれもこう含意します。正規化した値の素のSHA-256をよこせ、と。オーディエンスアップロードに初めて向き合う開発者が、どちらのルールが間違っているのかと問うのは当然です。どちらも間違っていません。互いに反対の問題を解いているのです。

ソルトは何のためにあるのか

ソルトとは、同一の入力が異なるダイジェストを生むように、ハッシュ化の前に入力へ混ぜ込む追加データです。この性質こそが認証情報の保管における眼目です。同じパスワードを持つ2人のユーザーは異なるハッシュになり、事前計算された参照表は無力化されます。その文脈ではリンク不能性が目的だからこそ、ソルトが標準なのです。

マッチングが正反対を必要とする理由

オーディエンスマッチングが成立するのは、まさに同一の入力が同一のダイジェストを生むからです。あなたは自分のやり方で john@example.com をハッシュ化し、プラットフォームは自らの記録にある john@example.com を同じやり方でハッシュ化する。ダイジェストが一致する――その一致こそがマッチです。あなたしか知らないソルトを持ち込めば、あなたのダイジェストは地球上のいかなるものとも一致しません。完全に安全で、マッチしたユーザーがゼロのリストの出来上がりです。決定論的でソルトなしのハッシュ化は、プラットフォームがセキュリティに手を抜いているのではありません。仕組みが仕事をしているのです。

引き受けなければならない帰結

小さな鍵空間に対するソルトなしのダイジェストは、構造上そもそも弱いものです。とりわけ電話番号がそうです。国内の番号計画を列挙し、すべてハッシュ化すれば、「匿名化された」列はその表を持つ者にとって平文同然に読めます。これは修正できません。弱点とマッチングは同じ性質だからです。したがって扱い方のルールが導かれます。アップロードファイルは伝送のための書式であって、保護ではありません。アクセスを制限し、意図をもって共有し、キャンペーンが終わったら削除してください。（より長い議論は「ハッシュ化は匿名化ではありません」のガイドにあります。）

どのルールがどこに当てはまるか

3行目は補足に値します。あなた自身がハッシュ化する側でも照合する側でもあるとき――自社システム内でデータセットを結合するとき――照合すべきプラットフォームは存在せず、鍵付きハッシュが本物の保護をもたらします。素のSHA-256は、それを必要とするアップロードのためにとっておいてください。

Hash Dataの位置づけ

Hash Dataは、オーディエンスアップロードが期待する標準的なダイジェストをGoogle スプレッドシートの中で生成します。複数のアルゴリズムを数式として提供し、=HASHPHONE() はE.164への正規化とハッシュ化を1ステップで行います。変えられないのは上記の物理法則です。だからこのページは、そうでないふりをするのではなく、製品の隣に置かれています。

出典

• EDPBガイドライン01/2025（仮名化） – 2026年8月20日閲覧