はじめに
私たちは 「お客様の会計データを預かるときに守る 11 のルール」 という記事で、サポート対応で実データをいただくときの社内 SOP を公開しました。
その 11 ルールの中で、特に重要なのが 「受領後 24 時間以内に匿名化版を生成する」 というステップです。
ここで素朴な問いが出ます。
「匿名化しました、と言われたとき、何をもって匿名化されていると信じるべきか」
「取引先名を全部 XXX に置き換えました」では、確かに名前は消えますが、それで本当に個人情報が守られているのでしょうか。逆に「実名を仮の名前に置換しました」だけだと、その仮の名前から元の実名を逆引きできないことを、誰がどう保証するのでしょうか。
本記事では、niyase が選んだ「決定論的ハッシュによる匿名化」という考え方を、技術詳細に深く立ち入らずにご説明します。
まず「匿名化」と「仮名化」の区別
個人情報保護法の世界では、「匿名化」と「仮名化」は別の概念です。
- 匿名化: 元のデータに復元できないように加工する処理
- 仮名化: 別の符号 (仮名) に置き換える処理。マッピング表があれば復元可能
両者は法的にも、求められる管理レベルが違います。
niyase が SOP で「匿名化」と呼んでいるのは、マッピング表を一切保持しない タイプの処理です。意図的に 元のデータに戻れない 方向に振っています。
戻れたら便利なのでは? と思われるかもしれません。デバッグ作業中だけ、こっそりマッピング表を持って復元できれば作業も楽になります。
それでもあえて 戻れない ことを選んだのは、戻れる仕組みを 1 つ持っていれば、それが漏れた時点で全データが復元される、という根本リスクを排除するためです。
単純な「サンプル A」「サンプル B」では情報が失われる
匿名化の最もシンプルな実装は、「実名を 1 つずつ番号付きの仮名に置き換える」方法です。
大窪政裕 → サンプル個人 A
鈴木一郎 → サンプル個人 B
株式会社 X → サンプル株式会社 C
これは確かに復元不能で、シンプルです。
ところが、この方式には致命的な弱点があります。バッチごとに置換が変わる ことです。
例えば、ある月のデータで「大窪政裕 → サンプル個人 A」と置換され、別の月のデータでは「大窪政裕 → サンプル個人 D」と置換される。
すると、「同じ人物が複数月にわたって登場している」というパターンが消えてしまいます。バグの原因が「同一取引先からの繰り返し取引」だった場合、匿名化版では再現できなくなります。
加えて、置換の「順番」が情報を含んでいるリスクもあります。「最初に登場した人物 = A」「2 番目 = B」だと、社員の入社順や取引先との関係順を、出現順から推測されてしまう可能性があります。
決定論的ハッシュという考え方
niyase が選んだ方式は、以下のシンプルな構造です。
- 入力 (実名) を、暗号学的ハッシュ関数 (SHA-256) に通す
- ハッシュ値の最初の 4 バイトを uint32 として読み出す
- その整数を、仮名リストのサイズ (10,000) で割った余りを取る
- 結果のインデックスから「サンプル個人 NNNN」「サンプル株式会社 NNNN」を生成
"大窪政裕" → SHA256 ハッシュ → 整数 → mod 10000 → 1533 → "サンプル個人 1533"
"鈴木一郎" → SHA256 ハッシュ → 整数 → mod 10000 → 6920 → "サンプル個人 6920"
"株式会社 X" → SHA256 ハッシュ → 整数 → mod 10000 → 2720 → "サンプル株式会社 2720"
この方式の性質は以下です。
性質 1: 同じ実名は、常に同じ仮名になる
「大窪政裕」を 1 月のデータでハッシュしても、6 月のデータでハッシュしても、同じ「サンプル個人 1533」になります。
これにより 「同一人物の繰り返し取引」というパターンが匿名化後も保たれます。再現テストで有効です。
性質 2: 仮名から実名を逆算できない
SHA-256 は「プリイメージ抵抗性」を備えるよう設計された暗号学的ハッシュ関数で、現時点で破られていないと考えられています (厳密には計算量的な仮定に基づくもので、数学的に「不可能」と証明されているわけではありません)。出力ハッシュから入力を逆算するのは、現実的な時間では不可能とされています。
つまり「サンプル個人 1533」というラベルから、それが「大窪政裕」なのか「田中太郎」なのかを推測する手段が、私たちにもありません。
性質 3: マッピング表が存在しない
私たちはどこにも「実名 → 仮名」の対応表を保持していません。必要な都度ハッシュ計算で導出する設計です。
すなわち、漏えいできるマッピング表が存在しない。
性質 4: 統計的攻撃には限界がある (正直な告白)
一方で、決定論的ハッシュには弱点もあります。
「サンプル個人 1533」が一年中ずっと給与を受け取り続けている → この人は社員らしい。給与額の中央値から役職が推測できる、というような 統計的攻撃 には完全に防げません。
これを防ぐには、追加で金額の摂動や属性の汎用化が必要になります。本記事の方式は「実名そのもの」を匿名化することに限定したスコープなので、統計的攻撃まで防御するには別の層の手当てが必要です。
私たちはこの限界を正直に表明した上で、現在のスコープを「実名・固有名詞の漏えい防止」と明示しています。今後の改善で属性も含めた匿名化を進めることは検討しています。
なぜここまでやるのか
ここまでお読みいただいて、「普通の SaaS 事業者がここまで真面目に匿名化の方式を選定するか?」と疑問に思われたかもしれません。
正直に言えば、ほとんどの会社はここまで詰めません。「個人情報をマスクしています」と書いて済ませる方が、現実的にはコストが低いからです。
私たちがあえて方式を選定し、対外的に公開している理由は 2 つです。
1 つ目 は、「お客様にコードを書く時間と同じくらい、匿名化の仕組みに時間をかけている」という事実を、見える形にしておきたいからです。
2 つ目 は、ISO 27001 / SOC 2 Type II (認証取得を準備中) の取得時に、こうした個別の処理の妥当性を 書面で説明できる状態 にしておくためです。認証は最終的に書面と運用実態のセットで取得します。日々の仕組み選定がそのまま認証準備でもあります。
おわりに
「匿名化しました」という一言の背後には、選択された方式があります。
niyase では、その方式を公開できる形で運用することを 1 つの責任と捉えています。本記事の方式に問題点や改善案がありましたらお気軽にお寄せください。
匿名化を含むデータ受領 SOP の全体像 と合わせてご覧いただくと、私たちの「お客様の情報を真摯に守る」という姿勢がより伝わるかと思います。