2014年の米国ニューヨーク市タクシーデータの再識別（V. Pandurangan ほか）と、 「ハッシュ化は匿名化ではない」という整理（EU 第29条作業部会）を参考にした、仮想の事例（デモ）
データはすべて教材用の合成データです。
参考にした事例は 海外の事例 です。以降で触れる日本の制度（個人情報保護法・委員会規則）への言及は、 「もし同種の事象を日本の制度に当てはめて考えたら」という 仮定の説明 であり、 この事例が日本で法的に判断された、という意味ではありません。
攻撃を推奨するためではなく、安易な匿名化がいかに脆いかを具体的に理解し、正しい対策に結びつけるためのデモです。
タクシー事業者が、走行履歴を「匿名化したつもり」で公開した。
タクシー事業者が、運転者の 走行履歴（誰が・いつ・どこからどこへ運んだか）を外部公開することにしました。
運転者本人が特定されないよう 匿名化したつもり で、履歴の 運転者ID を SHA-256 でハッシュ化 した 「ハッシュ化済み履歴」を公開します。
SHA-256
ある利用者（攻撃者）が、2つの弱点を突いて 公開データの運転者IDをすべて復元 してしまいました。
運転者IDは 100-000-000 のような決まった桁形式。 しかも先頭の事業者コードは公表・固定。
100-000-000
→ 取りうるIDの候補が少ない（低エントロピー）
秘密鍵もソルトも使わない、 素の SHA-256 を 1回かけただけ。
→ 同じIDは誰が計算しても同じ値
加工方法の全体を暴く鍵になります。
ハッシュ関数は、同じ入力からは 必ず同じ値 を出します。
再識別も復元もできないよう、連結符号の削除・特異な記述の削除・一般化などの基準（施行規則第34条）で加工したものが匿名加工情報。
本件は運転者IDをハッシュ化しただけで 基準を満たさない。
照合しなければ本人を識別できないように加工し、識別行為の禁止などの義務のもとで扱うもの。 ただし 原則として公表・第三者提供はできません。
本件は外部公開が前提の時点で整合しない。
匿名加工情報でも（適切に運用される）仮名加工情報でもない、制度上の位置づけがあいまいなまま公開されたデータ。
drivers
trips
まず、公開されたデータそのものを。 「もう匿名化できていそうか？」を自分の目で確かめてください。
事業者は走行履歴の 運転者ID を SHA-256 に置き換え、走行IDを落として一般公開しました（全 17,950 行）。 氏名も、元の運転者IDも、表には出てきません。
運転者ハッシュは、規則性の無い長い文字列に見えます。氏名も運転者IDも無いので、一見すると「誰の記録か」は分かりません。
意味のなさそうなハッシュに置き換えたのだから、もう個人は分からない —— そう見えます。本当にそうでしょうか？
drivers: 運転者ID / 氏名 / 営業所
trips: 走行ID / 運転者ID / 乗車日時 / 乗車地 / 降車地 / 走行距離km / 料金
公開したハッシュ化済み履歴は、この trips の運転者IDをハッシュに置き換えて作ったものです。
「なぜ運転者ハッシュが元に戻せるのか」を、 ハッシュ化の性質と IDの作り の両面から評価します。
100
IDが「予測不能な十分に長いランダム値」（例: 128ビットの乱数）なら、 候補が 天文学的 で総当りは不可能。
桁形式が決まっていて、しかも公表されている部分があるため、 実際に試すべき候補は 約100万通り に縮む。
「形式が公知」＝「候補が少ない」＝「総当りできる」 という連鎖。
ソルト（値ごとに違うランダム値を足してハッシュ） → 同じIDでも出力がバラけ、事前計算した対応表が使えません。
秘密鍵つきハッシュ（HMAC） → 鍵を知らない攻撃者は正しいハッシュを再現できず、総当りしても一致しません。
2つの弱点を、どう組み合わせれば再識別できるか。
①で一致しなければ、別の加工方法（ソルト・鍵・別アルゴリズム）を疑うことになります。
100-NNN-NNN
ハッシュ→ID
総当り（②）はいつでもできる。いきなり総当りではダメなのか？
加工方法が分からなければ「何を」総当りすべきか決まりません （ソルト付きか、HMAC か、そもそも別アルゴリズムか）。
攻撃者は既知の1件を使って、「素の SHA-256 を全候補にかければ一致する」と 先に確かめて から、 安心して総当りに進みます。
方法は分かるが候補が無限。
→ 総当りは非現実的で 復元できない
候補は少ないが方法が不明。
→ 何を計算すればいいか 分からない
「素の SHA-256 を、約100万通りの候補に」総当りするだけ。
→ 数秒で全運転者IDが復元
手順を、具体的な処理に落とし込みます。
ハッシュ化済み履歴 （運転者ハッシュ＋乗降・料金）
運転者IDの形式 100-NNN-NNN （先頭の事業者コード 100 は固定・公表）
自分が乗ったタクシー運転手の運転者ID （乗務員証に表示）
特別な内部情報は不要。公開データ＋公知の形式＋自分が1回タクシーに乗った経験だけで成立します。
運転者ハッシュ = sha256(運転者ID)
sha256(既知の運転者ID)
運転者ハッシュ
100-{000..999}-{000..999}
ハッシュ → 運転者ID
復元運転者ID
HMAC-SHA256(秘密鍵, 運転者ID)
sha256
計算量の目安: 候補は約100万通り。短い文字列の SHA-256 を100万回計算しても、一般的な PC・Colab で 数秒。 （仮に9桁すべてが自由なら 10⁹ 通りで桁違いに重くなりますが、事業者コードの公知性がそれを 10⁶ に縮めています。）
notebooks/case03_reidentification.ipynb
攻撃を再現して終わりではなく、 7. 対策が効くことを同じコードで確かめるところまでが1セット。
「破られる」と「守れる」を並べて見ることに意味があります。
何が起きたか。そして、どう防ぐべきだったか。
100-001-001
sha256("100-001-001")
87145a71…5a542d79
→ 加工は「無ソルト SHA-256」だと 確定
運転者IDが復元されると、乗降・日時・料金は もともと平文 なので、特定の運転者の行動が丸ごと追えます。
※ ここでの「法律」は、もし同種の事象を日本の制度に当てはめて考えたらという仮定の整理です。
攻撃が成立した条件（弱点①②）を裏返すと、技術面の対策になります。
個人を識別する符号を「ハッシュ化しただけ」で公開・第三者提供するのは 安易な匿名化 であり、 技術（復元される）・法律（どちらの制度にも乗らない）の両面で危険です。
大切なのは、法令・委員会規則と、その実装例（どう加工すれば要件を満たすか）を把握し、 正しく理解したうえで運用できるようにすること。
技術的な対策（鍵つきハッシュ・連結符号の削除・一般化）と、 制度上の位置づけ（匿名加工情報／仮名加工情報の作成基準と取り扱い義務）を、目的に応じて揃える必要があります。
制度の具体的な要件は最新のガイドライン・委員会規則で確認してください。
個票を出さず「集計統計だけ」を公表すれば安全か？
出典: 2014年 NYC タクシーデータの再識別（V. Pandurangan ほか）／ ハッシュ化と匿名化の区別（EU 第29条作業部会 意見05/2014 等） サイト: https://gghatano.github.io/pets-seminar-01/ ライセンス: 教材コンテンツ CC BY 4.0 ／ コード MIT