昨日、TwitterのTLに流れてきた「イノベーションはいつも危なっかしい」という危なっかしいインタビュー記事を読んだことがきっかけで、パーソナルデータの匿名化周りで良く出てくるトピックを整理しようと思い立ったので、せっかくなのでブログに書いてみました。

---

1.「匿名化=氏名到達性の削除」じゃない
経済産業省のガイドライン【個人情報に該当する事例】に
生年月日、連絡先(住所・居所・電話番号・メールアドレス)、会社における職位又は所属に関する情報について、それらと本人の氏名を組み合わせた情報

特定の個人を識別できるメールアドレス情報(kizai_ichiro@meti.go.jp等のようにメールアドレスだけの情報の場合であっても、日本の政府機関である経済産業省に所属するケイザイイチローのメールアドレスであることがわかるような場合等)

という例が挙げられていることもあってか、かつて個人識別性の要素として氏名到達性の有無が非常に重視されていたこともありましたが、少なくともここ最近は、氏名到達性がなくても個人識別性は生じうると考えるのが一般的だと思います。

2.匿名化には濃淡がある
一口に「匿名化」と言っても、その内容は一義的ではありません。
1でNG例として挙げた「氏名の削除」から、k-匿名化、データの抽象化・一般化など、その手法は様々であり、また匿名化のレベルも異なります。
「どこまで匿名化すれば『匿名化できている』といえるのか」をきっちり設定していないもかかわらず、いきなり「このデータは匿名化できているか?」の検証を始めてしまうと議論が華々しく宙を舞うことになります。

3.連結可能性は、匿名化ができた後の話でしかない
連結可能性、つまり、個人をバッチリ特定できる生データと、匿名化したデータを照合することができるかは、「匿名化したデータ」が、適切に匿名化できた後に初めて出てくる話でしかありません。
Suicaの案件では連結可能性が無いことが強調されたこともあり、「ちゃんと匿名化できているのか」と連結可能性の切断がごっちゃに議論されてしまっているのを見かけることがあります。

4.連結可能性は、照合キーの削除だけの問題じゃない
連結可能性を考える際には、主に「生データ」と「匿名化データ」を照合するキー(例えばユーザーIDなど)が存在するか、という観点で語られることが多いですが、電子化されたDBであれば、k-匿名化がなされていない限り、実データ(例えば乗降時間と乗降駅と性別)の照合によっても容易に連結可能なのがむしろ通常だと思います。
連結可能性の判断には、アクセス権設定やファイヤーウォールも重要になる、ということでしょうか。

5.生データのまま匿名化を担保することは、基本的にすんごく困難
基本的に、生データを生データのまま「完全に匿名化できた」という状態にすることはとても困難です。
たとえば、k-匿名化をしても、そのk個のIDが実は裏では同一人に紐付いていた、なんてことはあり得る話ですし、一般化・抽象化をしても、その一般化・抽象化の枠内に当てはまった人は一人だけ、なんてこともあるでしょう。

---
時間のある限り気づいたことをつらつら書きつらねましたが、まだまだ自分自身も鋭意勉強中の分野ですので、お気づきの点がございましたら、本エントリーのコメントか、twitter(@katax)からご指摘いただければ幸いです。