2019年08月16日に初出の投稿

Last modified: 2019-08-16

改正された個人情報保護法は既に施行され、当社のようにプライバシーマークの利用許諾を認定されている事業者でも2017年度版の JIS Q 15001:2017 を運用しているわけだが(ちなみに2019年8月現在の話だが、『ウィキペディア』の JIS の説明は JIS Q 15001:2006 という旧版の内容で止まっているため、参考にしない方がいい)、大きな変更点の一つに「匿名加工情報」の扱いが加わっていて、実務の事例は大して公表もされていないし蓄積もされていない。しかし、実際には多くの事業者では実質的に匿名加工情報を作成して運用はしている筈である。たとえば EC サイトや B2C サイトを運用しているなら、サイトのアクセス解析やら利用者の属性にもとづく動向分析で、エンド・ユーザの登録情報に紐づけられたデータから統計情報に加工して利用しているだろう。まさしく、それが匿名加工情報である。

弊社でも求人サイトを運営しているため、そのような匿名加工情報を作成・利用している。具体的には、サイトの管理画面から登録ユーザの全データを CSV ファイルとしてダウンロードし、求職者の年齢、求職者の性別、求職者の都道府県、そして求職者の応募職種という四つの属性だけを残して、他は削除する。残ったデータを使ってグラフを描き、そのグラフを営業資料として使っている。したがって、匿名加工情報の適正な作成や利用が求められる最大の理由は「第三者提供」による情報の不当な融通や漏洩を防ぐことにあるのだから、円グラフを営業資料に描いて取引先に見せたり配布したところで、それだけなら匿名加工情報の第三者提供とは言えないだろう。(匿名加工情報なら、トレーサビリティを確保する目的から提供を受けた側の企業も提供を受けた事実を公表する義務がある。しかし、グラフを見せられたていどの企業がいちいちそんなことをするとは思えないし、グラフになってしまうと「個人に関する」データでもなくなる。)

しかし、社内だけで匿名加工情報を作成していても法律や JIS の適用範囲となる(もとより個人情報保護の目的からして、誰が利用するにしても個人の権利を侵害しないようにするためにあるからだ)。したがって、たとえ他社へ提供しないデータだとしても、適切な取り扱いをしなくてはならない。その場合に、匿名加工情報をどうにかして他の情報と照らし合わせて、特定の個人を識別するような行為は禁止されるし、そもそもそんなことができてしまうなら「匿名化」したとは言えないため、匿名化の手順を更に厳格にしなくてはならない。

弊社の場合はグラフの計算データとして使うため、匿名化の手法として、まず「一般化」と「不要な項目の削除」を使う。「一般化」とは、求職者=登録ユーザごとに記録されている生年月日を年齢に変換し、更に具体的な年齢ではなく「20代」などの年代にグルーピングするのである。「不要な項目の削除」は言うまでもなく、上記の四つの属性を除く他の全てのカラムを CSV から削除することである。このとき、Excel などで作業しているなら、Undo で元のデータに戻せないよう、操作を記録しないように設定しておかないといけない。また、一定時間ごとにバックアップ・ファイルを履歴として自動で生成するように設定されているなら、それも無効にしておくべきだろう。もちろん、往々にして MS Office のアプリケーションは少ないデータでもハングすることがあるので、これらの機能は使いたいところだし、データが破壊されると破壊されたで CIA の Integrity (an accuracy and completeness of data in its total lifecycle) が損なわれるのは避けたいところだから、もしバックアップをとるのであれば、それも保護の対象として捕捉し管理しなくてはならない(たとえば匿名加工情報のデータ・ファイルが不要となって削除したら、バックアップの削除を忘れてはいけない)。

しかし、当サイトを閲覧している方であればご承知かもしれないが、これだけでは十分な「匿名化」にはなっていない。もちろん他の(とりわけオリジナルの)データと照合して個人を特定する行為は禁止しておかなくてはいけないが、それでも内部犯行というものはどこの会社でも起きる可能性はある(ちなみに「犯行」と言うときついが、悪意とは限らない。不注意や愚かな好奇心で個人を特定しようとしてしまう人もいる)ので、あらかじめ《誰がどうやっても個人を特定できない》ようなデータに加工しておくことが望ましい。もちろん個々に独立したグラフ(つまり属性どうしの関連性がない別々のグラフ)にしてしまえば、「20代」という数値から個人を特定することが不可能であるのは、殆ど自明だろう。しかし、グラフを作成する元のデータは、「20代(一般化した年齢)、女性(性別)、鹿児島(都道府県)、医療・福祉関連(一般化した応募職種)」となっており、これら四つの属性だけでも該当する求職者=登録ユーザが一人しかいないという可能性だってある。少なくとも、サイトで運用しているマスター・データと照合さえすれば、そういう個人を特定できてしまう可能性が残るのだ。

これを防ぐには、従来からある基準として k-anonimity(k-匿名性)というアイデアを採り入れて、属性の同じ組み合わせの個人が何人以上いなくてはいけないかという基準を作って、その基準で一定以下のデータを「特異なデータ」として削除してしまうという手法が知られている。「20代(一般化した年齢)、女性(性別)、鹿児島(都道府県)、医療・福祉関連(一般化した応募職種)」という属性の組み合わせに該当する個人が登録ユーザに一人しかいなければ、k = 1 である。そして、該当者が一人しかいないという事実によって、既にその個人は特定できてしまっているのだから、k = 1 であるようなデータが「匿名化」されたとは言えないのは当然だろう。匿名化においては、そのデータのリスト全体や CSV ファイル全体がどうであれ、個々の個人の単位で、それが誰なのかが分からなくなっていることが大切だ。

しかし、この k を幾つにすればいいのかという点は明快な結論がない。k という基準をどんどん大きくすれば、たとえば k = 10 として4属性の同じパターンをもつ登録ユーザが10人以下となってしまうデータを全て捨てるとすると、たぶん使えるデータは殆ど残らないかもしれない。データの有用性と匿名性にはトレード・オフの関係があるため、これは何を有用と見做すかによって幾つかの形式的な指標が提案されている。実務では、PETs どころか個人情報保護法すら知らない一般従業員には k = 1 がダメだということは簡単に説明できても、では k が幾つならいいのかという直感的に妥当な説明はない。現実には k = 3 ていどに設定してもデータの大半が失われてしまうほど、登録ユーザが満たしている属性のパターンが分散してしまっている可能性もあるからだ。よって、こういうことは各事業者の CPO が実際のデータを見せてもらいながら判断するしかないと思う。

  1. もっと新しいノート <<
  2. >> もっと古いノート

冒頭に戻る


※ 以下の SNS 共有ボタンは JavaScript を使っておらず、ボタンを押すまでは SNS サイトと全く通信しません。

Twitter Facebook