③ 結果とチェック・対策 — 7/7¶
② 実装（Colab） の Notebook をコミット済みデータに対して実行した結果です（決定的なので Colab 実行と一致します）。復元後スキーマは 復元後テーブル定義 を参照。
データ規模¶
| データ | 件数 |
|---|---|
| drivers（運転者マスタ） | 2,000 |
| trips（走行履歴） | 17,950 |
| 公開された運転者ハッシュ（種類） | 2,000 |
攻撃① 加工方法の特定¶
自分が乗ったタクシー運転手の運転者ID（既知）を SHA-256 にかけ、公開データに一致があるかを見ます。
- 既知の運転者ID:
100-001-001 sha256("100-001-001")=87145a713eecd1e3b9e383ca754cbc1c11d48322c9469eb29f86d1135a542d79- この値は公開データの運転者ハッシュに存在した → 加工は「無ソルト
SHA-256」だと確定。
たった1件、元IDとハッシュの対応が分かるだけで、加工方法の全体が割れてしまいます（弱点②）。
攻撃② 総当りで全復元¶
公知フォーマット 100-NNN-NNN の全候補（約100万通り）を計算し、ハッシュ → 運転者ID の対応表を作って、公開履歴を復元します。
| 指標 | 値 |
|---|---|
| 総当りした候補数 | 1,000,000（10^6） |
| 復元できた運転者ハッシュ | 2,000 / 2,000（100%） |
| 運転者IDを復元した走行履歴 | 17,950 行すべて |
| 復元結果と元データの一致 | 全件一致 |
| 総当りの所要時間の目安 | 数秒 |
確認テスト結果（すべて合格）¶
- [x] 既知IDのハッシュが公開データに一致する（加工方法を特定できる）
- [x] 公知フォーマットの全列挙（10^6）で 2,000 種の運転者ハッシュをすべて復元できる
- [x] 復元した運転者IDが、元の走行履歴の運転者IDと全 17,950 行で一致する
- [x] 秘密鍵つきハッシュ（HMAC）で加工した場合、同じ総当りでは 0 件しか復元できない
再識別で何が分かってしまうか¶
運転者IDが復元されると、乗降・日時・料金はもともと平文なので、特定の運転者の行動が丸ごと追えます。たとえば復元後に営業所ごとの傾向を見ると（本来は非公開の営業所も、既知の運転者などから紐づく）:
| 営業所 | 最も多い乗車地 |
|---|---|
| 新宿営業所 | 新宿 |
| 渋谷営業所 | 渋谷 |
| 羽田営業所 | 品川 |
個々の運転者では、いつ・どのエリアを流し、どこへ客を運んだかという生活・勤務のパターンまで見えてしまいます。「ハッシュ化したから匿名」という思い込みが、こうした再識別を招きます。
安易な匿名化が危険な2つの理由（技術・法律）¶
「とりあえずハッシュ化して匿名化した」というデータは、技術と法律の2つの意味で危険です。
ここでの「法律」は、もし同種の事象を日本の制度に当てはめて考えたらという仮定の整理です（この事例が参考にしたのは海外の事例。全体概要 冒頭の注意も参照）。
| 面 | 何が問題か | このデモでの現れ方 |
|---|---|---|
| 技術 | 元の値の候補が少なく（低エントロピー）ハッシュが単純（無ソルト・鍵なし）なら、総当りで復元できる | 100万通りの総当りで 2,000種を全復元・17,950行が全一致（数秒） |
| 法律 | 匿名加工情報の作成基準（施行規則第34条）を満たさず匿名加工情報ではない。公表・第三者提供を前提にする点で仮名加工情報の取り扱いにも当てはまらない（原則、公表・第三者提供不可） | 「匿名化したつもり」で公開したデータが、どちらの制度にも乗らない中途半端な状態 |
技術だけ・法律だけを見ても足りません。「復元できないか（技術）」と「制度の要件を満たすか（法律）」の両方を確かめる必要があります。
どう防ぐべきだったか（対策）¶
攻撃が成立した条件（弱点①②）を裏返すと、技術面の対策になります。
- 秘密鍵つきハッシュ（HMAC）にする:
HMAC-SHA256(秘密鍵, 運転者ID)なら、鍵を知らない攻撃者は同じ値を再現できず、総当りしても一致しません（本デモで復元 0 件を確認）。鍵は公開データと分離して厳重に管理します。 - ソルトを付ける: 値ごとに異なるランダム値を足してからハッシュすると、事前計算した対応表（レインボーテーブル）が使えなくなります。
- そもそも個人単位の識別子を残さない: 十分に長いランダムな仮IDへ置換し、元IDとの対応表を残さない（＝匿名加工の考え方 / case02）。連結符号を断てば、行動履歴を特定の個人へ結び付けられません。
- 粒度を落とす・集計する: 個票のまま公開せず、エリア・時間帯などに一般化して、そもそも個人を追えなくします。
この事例の要点 — 正しく理解して運用する
ハッシュ化＝匿名化ではありません。 個人を識別する符号を「ハッシュ化しただけ」で公開・第三者提供するのは、安易な匿名化であり、技術（復元される）・法律（どちらの制度にも乗らない）の両面で危険です。
大切なのは、法令・委員会規則と、その実装例（どう加工すれば要件を満たすか）を把握し、正しく理解したうえで運用できるようにすることです。技術的な対策（鍵つきハッシュ・連結符号の削除・一般化）と、制度上の位置づけ（匿名加工情報／仮名加工情報の作成基準と取り扱い義務）を、目的に応じて揃える必要があります。制度の具体的な要件は最新のガイドライン・委員会規則で確認してください。
↩ もう一度確かめる: ② Colab で自分で実行 ／ ④ 攻撃の設計 に戻る。
出典: 本デモは実在の再識別事例を参考にした教材です。2014年 NYC タクシーデータの再識別（V. Pandurangan ほか）、ハッシュ化と匿名化の区別（EU 第29条作業部会 意見05/2014 等）については 参照資料 を参照。