# Google スプレッドシートで電話番号とメールアドレスをハッシュ化する方法

> Google スプレッドシートに組み込みのSHA-256関数はありません。顧客リストを正しくハッシュ化する方法と、同じ番号に2つのハッシュが必要な理由。

- Source: https://www.8apps.co/ja/blog/hash-phone-numbers-emails-google-sheets
- Markdown: https://www.8apps.co/ja/blog/hash-phone-numbers-emails-google-sheets.md
- Published: 2026-09-01
- Author: 8appsチーム
- Language: ja

---
誰もがこれを逆に考えています。SHA-256のダイジェストを作ること自体は、Apps Scriptで4行です。広告プラットフォームから**マッチ**を得ることには正規化が必要で、リストが死ぬのは正規化のところです。

Googleは自らのAPIドキュメントではっきり述べています。*"If the contact information is not correctly formatted before hashing, the API still accepts the hashed information, but it can't be matched with a customer."*

アップロードは成功します。失敗するのはマッチ率です。そして何も教えてくれません。

このガイドは両方の半分を扱います――Google スプレッドシートで実際にハッシュを作る方法と、それが何かにマッチするかどうかを決めるプラットフォーム別の正規化ルールです。前半には4つの方法があります。**最短なのは、正規化とハッシュ化を1つの関数で行うアドオン**――下記の方法1――であり、このページの残りは、正規化こそ正しくやる価値のある部分だという理由の詳細です。

---

## まず：スプレッドシートにハッシュ関数はありません

Googleが公開している関数リストは17のカテゴリに及びます――日付、エンジニアリング、財務、テキスト、数学など。**SHA256もMD5もHASHもDIGESTもありません。** エンジニアリングのカテゴリにあるのは基数変換と複素数で、暗号関連は何もありません。

つまりどの方法も回避策です。4つあり、優劣は同じではありません。

| 方法 | こんなときに | 評価 |
|---|---|---|
| シートにハッシュ関数を追加する**アドオン** | 実際の顧客リストを用意する必要があり、正規化も任せたい | **推奨** |
| **自作のApps Script**カスタム関数 | コードを自分で持ちたい、または誰のアドオンにもないアルゴリズムやルールが要る | 注意すれば可 |
| **ウェブのハッシュツール** | 1つのテスト文字列を確認するだけ | リストには使わない |
| **ハッシュ化しない** | プラットフォームが平文を受け入れ、社内規程も許している | 正当な選択 |

この節では順に見ていきます。後半の正規化ルールは、どの方法を選んでも適用されます――**マッチ率を決めるのはそちら**であり、どの方法もそこから免れさせてはくれません。

---

## 方法1：シートに関数を追加するアドオン

**まず手を伸ばすべきはこれです。** 理由はこのページ全体の主張そのものです。ダイジェストを作ることは些細です。入力を正しく正規化することが、アップロードが誰かにマッチするかどうかを決めます――そしてそれこそ、アドオンが入力の種類ごとに、すべての行で同じやり方で代行できる工程です。

[Hash Data](/ja/google-workspace/hash-data) は仕事をそのように分けています。

| 関数 | 何をするか |
|---|---|
| `=HASHEMAIL(email, [algorithm])` | 空白を除去し、小文字化してからハッシュ化 |
| `=HASHPHONE(phone, [algorithm])` | 番号をE.164に整形してからハッシュ化――`REGEXREPLACE` をダイジェストの数式に連結する代わりに1ステップで |
| `=HASH(value, [algorithm])` | 与えられた値をそのままハッシュ化――正規化なし、大文字小文字を区別 |

自作スクリプトに対して得られるものが4つあります。

- **正規化が関数の中にある**――新しいシートのたびに作り直す補助列の中ではなく。
- **カスタム関数の30秒の上限**を設計で回避する必要がない――実際のリストでなぜこれが効いてくるかは方法2で。
- **リストがスプレッドシートから出ない。** 第三者のウェブサイトに何も貼り付けません。
- **SHA3-256が使える**――Apps Script自身の `computeDigest()` は提供していません。

**使う関数を左右するので、注意点を1つはっきり書きます。** `=HASHPHONE()` はE.164に正規化します――先頭に `+` の付く数字です。これはGoogle Adsが明記するものと一致します。Metaが示す例は逆方向で、数字のみ、`+` なしです。ですからMetaへのアップロードでは、`=REGEXREPLACE(A2, "[^0-9]", "")` で自分で正規化し、その文字列を `=HASH()` でハッシュ化してください。1つの関数が両方のプラットフォームをまかなえないのは、プラットフォーム同士の規定が一致していないからです――下の比較表が示すのと同じ論点です。

無料枠は1日100回のハッシュ呼び出しまで、有料枠は上限がなくなります。

→ [Google Workspace MarketplaceからHash Dataをインストール](https://workspace.google.com/marketplace/app/hash_data_by_8apps/476613022290)

---

## 方法2：カスタム関数を自分で書く

コードを自分で持ちたいなら、必要なのはこれだけです。**拡張機能 → Apps Script** を開き、以下を貼り付けて保存し、シートで `=SHA256(A2)` を使います。

```javascript
/**
 * 入力の SHA-256 ダイジェストを小文字の16進文字列で返します。
 * 単一セルまたは範囲を受け取ります。
 * @customfunction
 */
function SHA256(input) {
  if (Array.isArray(input)) {
    return input.map(function (row) {
      return row.map(function (cell) { return SHA256(cell); });
    });
  }

  if (input === '' || input === null || input === undefined) return '';

  var bytes = Utilities.computeDigest(
    Utilities.DigestAlgorithm.SHA_256,
    String(input),
    Utilities.Charset.UTF_8
  );

  return bytes
    .map(function (b) { return ((b < 0 ? b + 256 : b)).toString(16).padStart(2, '0'); })
    .join('');
}
```

ここで多くの人がつまずく点が2つあります。自分でスクリプトを書かない場合でも、どちらも理解しておく価値があります。

**`computeDigest()` は16進文字列ではなく符号付きバイト配列を返します。** Apps ScriptはJava形式の符号付きバイトを返すため、`0x7F` を超える値は負の数として届きます。`b < 0 ? b + 256 : b` が直しているのはそれです。省くと `-` だらけのダイジェストになり、どのプラットフォームも受け付けません。`padStart(2, '0')` を省くと、各バイトの先頭のゼロが無音で落ち、64文字未満の、非常に気づきにくい形で誤ったダイジェストができあがります。

**カスタム関数は30秒以内に返さなければなりません。** さもないとセルに `#ERROR!` が出ます。1セルずつの方式――各行に数式を1つ――は、実際の顧客リストでは破綻します。上の関数が最初に配列かどうかを判定しているのはそのためです。こう書いておけば、`=SHA256(A2:A5000)` を1つのセルに入れて、列全体を1つの配列として返させることができます。

---

## 方法3：ウェブのハッシュツール

最も慎重に考えるべき方法です。最も手を伸ばしやすく、そして唯一、開示上の問題を抱えているからです。

顧客リストをウェブサイトに貼り付けることは、そのサイトの運営者への個人データの提供です。ハッシュ化がブラウザ内で行われているのか相手のサーバーで行われているのかは、たいていページからは判別できません。そしてその答えは決定的に重要です。テスト用の文字列1つを確認するだけなら問題ありません――このページの後半に、そのために使うべきものがあります。実在する顧客のリストには、使わないでください。

---

## 方法4：ハッシュ化しない

忘れられがちな選択肢です。Google Adsは平文の顧客データを受け入れてアップロード前にハッシュ化しますし、TikTokは *"accepts both hashed and original values."* と明記しています。

ですからハッシュ化する理由が社内規程や契約上のものであるなら、ハッシュ化が答えです。必須だと思い込んでいたのなら、そうでない場合が多いのです――そして事前にハッシュ化するということは、正規化とそこで起こるあらゆる間違いを、プラットフォームではなく自分が引き受けるということです。それを前提にパイプラインを組む前に、知っておく価値があります。

---

## 次に：正規化する、それもプラットフォームごとに

ほとんどのガイドが飛ばす部分であり、マッチ率が崩壊する理由でもあります。

### Google Ads

**カスタマーマッチ**はハッシュ化する列について、すべて小文字化し、空白を除去し、*"Format phone numbers using the E.164 format"*、そして明示的に *"Include the country code and '+' sign."* と明記しています。

GoogleはGmail限定のルールを2か所に記載していますが、それらは同一ではありません――どちらかをパイプラインに写す前に知っておくべきことです。

**カスタマーマッチのデータファイル**のページはこう述べるだけです。*"Remove all periods (.) that precede the domain name in gmail.com and googlemail.com email addresses."* ピリオドのみで、それ以外はありません。

カスタマーマッチのAPIページはさらに踏み込みますが、**拡張コンバージョン**に限定された見出しの下でのことです。ユーザー名部分のピリオド*と*、プラス記号以降のすべてを除去する、と。示されている例は `Jane.Doe+Shopping@googlemail.com` → `jane.doe+shopping@googlemail.com`（小文字化）→ `janedoe@googlemail.com` です。

つまりプラス以降の除去は拡張コンバージョンについて明記されたものであって、顧客リストのアップロードについてではありません。オーディエンスリストを作っているなら、その仕事についてGoogleが実際に明記しているのはピリオドのルールのほうです。**両者が一致している点：これは `gmail.com` と `googlemail.com` にのみ適用されます。** すべてのドメインに適用するのはそれ自体がバグです――多くのメールシステムは `jane.doe@` と `janedoe@` を別人として扱います。

### Meta

Metaは別のことを明記しています。メールアドレスについては *"Trim any leading and trailing spaces. Convert all characters to lowercase."* Gmailのドットのルールはいっさいありません。

電話番号については *"Remove symbols, letters, and any leading zeros,"* に加えて *"Always include the country code as part of your customers' phone numbers."* Meta自身の例は `(650)555-1212` → `16505551212` ――国番号、数字のみ、プラス記号なしです。

### つまり同じ電話番号が2つの異なるハッシュを生む

|  | Google Ads | Meta |
|---|---|---|
| 電話番号、明記の内容 | E.164、*"include the country code and '+' sign"* | *"Remove symbols… and any leading zeros"*；例 → `16505551212` |
| Gmailのドットと `+` 以降 | `gmail.com` / `googlemail.com` はドット除去。`+` 以降のルールは拡張コンバージョンについて明記 | 明記なし |
| エンコード | *"Use hex SHA256"* | *"HEX representations… using lowercase for A through F"* |

ハッシュ化した1つの列で両方のプラットフォームをまかなうことはできません。使い回していたのなら、それがあなたのマッチ率です。

### TikTokは例外

TikTokの明記ははるかに少なめです。*"MD5 and SHA256 encryption is supported. The content of the file before encryption needs to be in all uppercase or lowercase."* E.164の要件は公開されておらず、ハッシュ化された値と元の値のどちらも受け入れます。Googleのルールがそこでも通用すると思い込まないでください。

---

## 数式を、適用する順に

補助列で正規化し、補助列をハッシュ化し、ダイジェストだけを残します。

| 工程 | 数式 |
|---|---|
| メールアドレス、両プラットフォーム共通 | `=LOWER(TRIM(A2))` |
| `TRIM()` が見逃すノーブレークスペースの除去 | `=TRIM(SUBSTITUTE(A2, CHAR(160), " "))` |
| Gmailのドットと `+` 以降、Google Adsのみ――上記の適用範囲の注意を参照（小文字化済みメールである `B2` に適用） | `=IF(REGEXMATCH(B2, "@(gmail\|googlemail)\.com$"), SUBSTITUTE(REGEXREPLACE(REGEXEXTRACT(B2, "^[^@]+"), "\+.*$", ""), ".", "") & REGEXEXTRACT(B2, "@.*$"), B2)` |
| 電話番号、数字のみ（Meta） | `=REGEXREPLACE(A2, "[^0-9]", "")` |
| 電話番号、E.164（Google Ads） | `="+" & REGEXREPLACE(A2, "[^0-9]", "")`（国番号があると確信できてから） |

最後の行には、声に出して言っておくべき注意があります。国内番号に `+` を前置してもE.164として有効な番号にはなりません。`07700 900461` は `+7700900461` になり、これは誤りでマッチしません。国番号が実際にそこにある必要があります。

---

## 失敗の形を、起こる順に

1. **ハッシュ化する前にスプレッドシートがデータを壊す。** 16桁の数字が指数表記になり、`07700 900461` は先頭のゼロを失い、`+44…` は数式として読まれます。何かが入る**前に**列をプレーンテキストにしてください――後から直すのはデータ損失であって書式設定ではありません。
2. **大文字小文字と空白。** `John@` と `john@` は別のダイジェストです。CSVエクスポート由来の末尾の空白が付いた `john@x.com ` と `john@x.com` も同様です。そして `TRIM()` はノーブレークスペースを除去しません――ウェブページからのコピー＆ペーストが残すのは、まさにそれです。
3. **表示上の値をハッシュ化する。** `(650) 555-1212` は `16505551212` ではありません。セルが電話番号として書式設定されていれば、見えているものとハッシュ化しているものは別の文字列です。
4. **二重ハッシュ化。** すでにハッシュが入っている列の上で数式を走らせること。簡単な確認方法：SHA-256の16進ダイジェストは常にちょうど64文字の `0-9a-f` なので、`=LEN(B2)=64` が捕まえます――切り詰めも同時に。
5. **エンコードの誤り。** Base64のダイジェストは、正しい入力に対する有効なハッシュでありながらマッチしません。よく出回るコピー＆ペースト用の断片には、MD5*かつ*Base64が既定になっているものが少なくありません。

---

## アップロード前に検証する

Metaは `john_smith@gmail.com` の期待ダイジェストを公開しています。

```
62a14e44f765419d10fea99367361a727c12365e2520f32218d505ed9aa0f62f
```

この文字列をそのまま、あなたの数式でハッシュ化してください。まったく同じ値が返らないなら、直すのは数式であってリストではありません。30秒で済み、外から見ると区別のつかない「ハッシュ化が壊れている」と「リストが悪い」を切り分けられる唯一のテストです。

---

## プライバシーについて正直に一言

ハッシュ化は仮名化であって匿名化ではありません。GDPRは前文第26項でこの点を決着させています。「仮名化を受けた個人データであって、追加的な情報を用いることにより自然人に帰属させうるものは、識別可能な自然人に関する情報とみなされるべきである」。2025年1月のEDPBによる仮名化のガイドラインも、まさにこの出発点の上に組み立てられています。

ソルトなしの電話番号ハッシュは総当たりが可能です――数の空間は、すべて試し尽くせる程度に小さいのです。そしてソルトを付けることはできません。ソルトこそがプラットフォームのマッチングを止めるものだからです。ハッシュ化された顧客データは、依然として顧客データです。そのように扱ってください。

終わったら、ハッシュ化した列をコピーし、値のみを特殊貼り付けし、生の列を削除してください。

---

## 全体を、順番に

どの方法を取ったとしても、手順は同じです。

1. データが入る前に**列をプレーンテキストに設定**する。
2. アップロード先のプラットフォームのルールで――もう一方のではなく――**補助列で正規化**する。
3. プラットフォームが別途指定しない限り、16進SHA-256で**補助列をハッシュ化**する。
4. その列を信頼する前に、Metaが公開するダイジェストに対して**既知の文字列を1つテスト**する。
5. 範囲全体で **`=LEN(B2)=64` を確認**し、切り詰めと二重ハッシュ化を捕まえる。
6. **値のみを特殊貼り付け**し、生の列を削除して、アップロードする。

工程2と3を単一の関数にまとめるのが [Hash Data](/ja/google-workspace/hash-data) です――メールアドレスには `=HASHEMAIL()`、E.164の電話番号には `=HASHPHONE()`、自分で正規化済みのものには `=HASH()`。SHA256、MD5、SHA1、SHA512、SHA3-256に対応し、すべてがあなたのスプレッドシートの中で動きます。無料枠は1日100回のハッシュ呼び出しまで、有料枠は上限がなくなります。

---

## 出典

- [Google スプレッドシートの関数リスト](https://support.google.com/docs/table/25273)
- [Apps Script – Utilities.computeDigest](https://developers.google.com/apps-script/reference/utilities/utilities) および [DigestAlgorithm](https://developers.google.com/apps-script/reference/utilities/digest-algorithm)
- [Apps Script – Google スプレッドシートのカスタム関数](https://developers.google.com/apps-script/guides/sheets/functions)
- [Google Adsヘルプ – 顧客データファイルの形式を設定する](https://support.google.com/google-ads/answer/7659867)
- [Google Ads API – Get started with Customer Match](https://developers.google.com/google-ads/api/docs/remarketing/audience-segments/customer-match/get-started)
- [Meta – Conversions API customer information parameters](https://developers.facebook.com/docs/marketing-api/conversions-api/parameters/customer-information-parameters/)
- [Meta – Custom Audiences guide](https://developers.facebook.com/docs/marketing-api/audiences/guides/custom-audiences/)
- [TikTok – Guidelines for customer files](https://ads.tiktok.com/help/article/customer-file-faq)
- [GDPR前文第26項 – 匿名データには適用されない](https://gdpr-info.eu/recitals/no-26/)
- [EDPBガイドライン01/2025（仮名化）](https://www.edpb.europa.eu/system/files/2025-01/edpb_guidelines_202501_pseudonymisation_en.pdf)

*プラットフォームの仕様は2026年8月20日に確認しました。広告プラットフォームはこれらのページを改訂します。大規模なアップロードの前に出典を確認してください。*

---

## 関連記事

- [Hash Dataのドキュメント – `=HASHPHONE()`](/docs/hash-data/using-hash-data/hash-phone)
- [Google スプレッドシートでのハッシュ化のベストプラクティス](/docs/hash-data/power-user-tip/best-practices)
- [Google Driveのアクセス権を監査する方法](/ja/blog/drive-guard-audit-google-drive-access)