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

> セキュリティの解説は必ずソルトを使えと言い、広告プラットフォームはソルト付きデータを照合できません。どちらも正しい――その違いと、実務上の意味。

- Source: https://www.8apps.co/ja/blog/salted-vs-unsalted-hashes-audience-uploads
- Markdown: https://www.8apps.co/ja/blog/salted-vs-unsalted-hashes-audience-uploads.md
- Published: 2026-09-02
- Author: 8appsチーム
- Language: ja

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

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

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

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

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

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

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

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

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

| 文脈 | ソルト？ | 理由 |
|---|---|---|
| パスワード、認証情報 | 常に使う | リンク不能性。参照表を無力化する |
| 広告プラットフォームのオーディエンスアップロード | 使わない | マッチングには決定論的なダイジェストが必要 |
| 社内の仮名化された分析 | 鍵付き／ソルトあり | 両側を自分で管理しているので秘密鍵を使う |

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

## Hash Dataの位置づけ

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

## 出典

- [EDPBガイドライン01/2025（仮名化）](https://www.edpb.europa.eu/system/files/2025-01/edpb_guidelines_202501_pseudonymisation_en.pdf) – 2026年8月20日閲覧