最新 追記

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 1532   昨日: 2734

2016年03月06日

行政機関法では匿名加工情報が個人情報に当たるですって?(パーソナルデータ保護法制の行方 その20)

一昨日、4日、行政管理局の「行政機関等が保有するパーソナルデータに関する研究会」が、8か月ぶりに会合を開くというので、傍聴に行ってきた。自民党の会議情報によれば*1、前日の3日に既に党の法案審査が行われているようなので、法案はとっくに条文レベルで完成していると思われるところ、研究会で2時間も何を話すのだろう?という謎の会合だ。前回は、昨年7月、「行個法・独個法の改正に向けた考え方(検討案)」が示され、その後は音沙汰なかった。

傍聴に行ってみると、「行政機関個人情報保護法・独法等個人情報保護法の改正に向けた考え方(案)」が示され、これについて構成員の意見を聞くという趣旨だった。今から何か言って法案に影響を及ぼせるのだろうか。事務局は、条文が未だ存在しないかのような口ぶりで「考え方(案)」を説明していた。構成員はみな空気を読んでか、誰もそのことを口にしない。傍聴していた人の中には、これから骨子を作成する段階だと誤解した人もいたようだ。

照合による識別の容易性要件を巡る混迷

会合は、条文がないのに活発な議論が行われ、2時間まるまる費やされた。特に質疑が紛糾したのは、「考え方(案)」の12頁「公的部門の匿名加工情報の定義」のところであった。ここには以下の記載があった。

公的部門と民間部門の匿名加工情報が、官民の間で流通し、円滑な利活用が行われるようにするためには、新個人情報保護法における匿名加工情報と同様の情報が、行政機関個人情報保護法・独法等個人情報保護法においても匿名加工情報として取り扱われることが望ましい。このため、匿名加工情報の定義について、新個人情報保護法と同様の規定を行政機関個人情報保護法・独法等個人情報保護法にも設ける必要がある。

しかしながら、行政機関個人情報保護法・独法等個人情報保護法においては、個人情報について、その厳格な保護を通じて行政に対する国民の信頼を一層確保する観点から、「他の情報と照合することができ、それにより特定の個人を識別することができることとなるものを含む」(行政機関個人情報保護法・独法等個人情報保護法各2条2項)場合も個人情報に該当することとしている(新個人情報保護法とは異なり、照合の容易性が要件とされていない)ことから、新個人情報保護法と行政機関個人情報保護法・独法等個人情報保護法とで同一の定義とした場合、元となる個人情報の範囲の違いから、作成された匿名加工情報の範囲が異なってしまう

作成された匿名加工情報の範囲を同じとするためには、作成の対象となる個人情報の範囲をそろえることが考えられ、行政機関個人情報保護法・独法等個人情報保護法の匿名加工情報の定義を工夫する必要がある。

なお、行政機関等が作成する匿名加工情報は、加工に用いた個人情報自体などとの照合により特定の個人を識別することができることから、行政機関個人情報保護法・独法等個人情報保護法の個人情報に当たるものであると考えられる。本研究会においては、行政機関等の匿名加工情報が個人情報に該当する場合も検討対象に含めておくべきとして検討を行ってきたところであるが、基本的な考え方としては、個人情報に該当しても、個人の権利利益の保護が図られるための規律が設けられ、官民の匿名加工情報の流通に支障が生じないのであれば問題は無いものと考える。

行政機関個人情報保護法・独法等個人情報保護法の改正に向けた考え方(案), 第16回, 2016年3月4日, 12頁

エー? なんですって?

この、照合による識別の「容易に」要件の有無による違いは、この研究会が繰り返し論点とし、また、迷走してきた部分だ。一昨年11月の時点での様子は2014年11月12日の日記「行政機関法にはグレーゾーンがないですって?(パーソナルデータ保護法制の行方 その11)」に書いている。このときの事務局は、「個人特定性低減データ」について、公的部門では「容易に」がないからすべて個人情報に当たるなどといい加減なことを言っていた。それが、民間部門の改正法案が出てきた後の議論では、以下のように再整理されていた。

昨年11月の研究会の「中間的な整理」では、個人特定性低減データについて、行個法上の個人情報であることを前提として、考え方の整理を行った。

しかしながら、基本法改正案における「匿名加工情報」は、それまでの検討対象であった「個人特定性低減データ」と異なり、基本法上の「個人情報」に該当しないものとして整理されており、研究会の「中間的な整理」の検討の前提に変更が生じることとなった。今般再開する研究会では、この点を踏まえ、行政機関等匿名加工情報の考え方について再整理を行う必要がある。

なお、行政機関等匿名加工情報については、基本法の匿名加工情報を引き写した場合、概念上、行個法上の「個人情報」に該当しないと考えられる場合(下図A該当)と、行個法上の「個人情報」に該当する部分を含む場合(A+B該当)とが考えられる。このため、以下では、議論を分かりやすく整理するため、A情報該当の場合とB情報該当の場合に分け、それぞれの場合について記述することを基本とする。

A情報とB情報は、行個法上の「個人情報」に該当するかどうかで区別されるものである(注)が、視点を変えれば、どちらも同じく「匿名加工」された情報でもある。

(注)行個法・独個法では、「個人情報」の定義として、個人識別性の程度を基本法よりも厳しく規定しており、他の情報との照合の「容易」性を個人情報の要件としていない。A情報とB情報の差異はこれに対応する(すなわち、A+B情報の全体=「容易に照合することができ」ないもの、うちA情報=「照合することができ」ないもの、B情報=「容易に」ではないが「照合することができ」るもの、ということになる)。

資料の図

行政機関及び独立行政法人等の匿名加工情報の導入の論点について, 第13回, 2015年4月30日, 3頁

このように、匿名加工情報が、行政機関法(資料では「行個法」)の個人情報に該当するかは、該当しない場合もあれば、該当する場合もあるとされていた。

それが、今回の「考え方(案)」で突然、全ての場合について個人情報に該当するという解釈に変わってしまったのである。

この点について、一昨日の研究会では、松村雅生構成員が、繰り返し執拗に矛盾を指摘していた。

(松村構成員)12頁、匿名加工情報というのは、もちろん若干個人識別性が残っているかもしれないという議論はあるが、大半は個人識別性がなくなったものを言っているわけですよね。それと、今おっしゃっていることとどういうふうに整合性があるんでしょうか。

(事務局)繰り返しになるが、個人情報該当性を適切に排除するというのが元々の発想だが、行政機関の中にあるときに、個人情報なのかどうかということを整理したら、このように言わざるをえないということ。

(松村構成員)あのね、元の情報を持っている限りはいくら一部だけを取り出して渡そうとしても、渡せませんよというのが、12頁の考え方でしょ。そうしたら、10頁の、個人情報該当性を適切に排除すれば利用・提供は問題ないとするケースが起こりえますかと聞いているわけですよ。どうやったらできるんですか。

(藤原座長)そこは個人情報を加工してということで……

(松村構成員)いやいや、加工してもですよ、元の情報を持っていたらダメだって12頁は書いてあるわけですよ。

(事務局)その点は、民間事業者は元の情報を持っていないので、……

(松村構成員)そうじゃなくてー、行政機関が提供しようとする場合に、元の情報を持っていれば、個人識別情報でなくなった場合でも、出せませんよと12頁は書いてあるわけでしょ。

(事務局)そういうわけではなく……

(松村構成員)そうじゃないのなら、そうじゃないように書いた方がよろしいのではないか。

(事務局)表現を少し……

(松村構成員)いやいや(笑)、表現の問題じゃなくて、考え方として……

(中略)

(松村構成員)12頁のなお書きのところとね、10頁の個人情報該当性を排除すれば利用・提供問題ないというところ、矛盾してませんか言っているわけで、どちらが正しいと言っているわけじゃない私は。

このやりとりが何回か繰り返された後、下井康史構成員が、矛盾しているなら10頁の方を直せばいいと発言していたが、直すべきは12頁の方だろう。

なお、行政機関等が作成する匿名加工情報は、加工に用いた個人情報自体などとの照合により特定の個人を識別することができることから、行政機関個人情報保護法・独法等個人情報保護法の個人情報に当たるものであると考えられる。

行政機関個人情報保護法・独法等個人情報保護法の改正に向けた考え方(案), 第16回, 2016年3月4日, 12頁

民間部門では、匿名加工情報は個人情報に該当せずとされている*2のに、どうして公的部門ではそうならないという理屈なのだろうか。

データの内容によってそうなる場合もあるという話なら理解できるが、全ての場合に個人情報に該当するというのは、どういうことなんだろうか。もしや、匿名加工を仮名化(k=1の)として理解しているのだろうか。「k=1の仮名化」では、元の個人情報ファイルと1対1対応するので、同じ行政機関が元のデータを持っている限りは、照合により個人情報となるデータだというのは、その通りだろう。民間部門では、匿名加工情報は個人情報でないとする不本意な構成*3にしてしまったおかげで、k=1の仮名化では匿名加工情報になり得ない制度となってしまったわけだが。

仮にそういうことだとしても、民間部門では元データとの照合が問題とならないのに、公的部門では元データとの照合が問題となるとするのは、どういう理由からなのか。これが「容易に」の有無による違いだというのだろうか。

もしかして、行政管理局は、民間部門の「容易に照合することができ」を、アクセス制御説で理解しているのだろうか。アクセス制御説とは、Suica事案でJR東日本が当初主張したように、元データと加工データを別々のデータベースサーバに格納して、間にファイアウォールを入れ、同じ従業員が双方にアクセスできないようにしていれば、「容易に照合することができ」に当たらなくなるとする解釈である。

この解釈は誤りであるとするのが、いわゆる「Q14問題」*4である。前回の日記「防衛庁情報公開請求者リスト事件は10年先行くSuica事案だった」で書いたように、2002年の防衛庁でもそういう解釈がとられ、有識者に「別々に保存されたリストが電算機処理され体系的に検索可能なファイルとして庁内で保有されていれば、いずれも個人情報に当たる。」と新聞で反論される事態となっていたのも、これの元祖である。浅はかな素人が陥りやすいよくある誤解ということであろうか。

防衛庁リスト事件のときは、昭和63年法(行政機関電算処理個人情報保護法)だった。昭和63年法では、個人情報の定義が、今の民間部門と同様に「他の情報と容易に照合することができ」だったので、Q14問題は、昔の行政機関と今の民間部門で共通するものと言える。

今の行政機関法では「容易に」のない照合が定義となっているわけだが、これとアクセス制御説の関係をどうとらえているのだろうか。「容易に」のない照合性では、ファイアウォールで仕切った程度では照合性は否定されないということなのか。それとも、「容易に」のない照合性では、そもそもアクセス制御説は採用されないということなのか。

散在情報的照合性 vs 処理情報的照合性 説

行政管理局の謎は深まるばかりであるが*5、ちょうどよい題材となっているので、ここで私の解釈(独自の見解)を簡単に書いておくことにする。*6

「他の情報と容易に照合することができ」は、処理情報を対象とした照合識別の要件であり、散在情報に対しては適用されない概念であるという説を提唱したい。

これは、昭和63年法が処理情報を中心とした保護法であり、照合識別の要件が「容易に」となっていたことと、現行の民間部門の保護法が、旧法案を廃案とした時点で散在情報に対する規定を捨て、本来は処理情報を中心とした規律である(にもかかわらず、多くの書籍で誤ったもしくは誤解させる解説が書かれている)ところ、同様に「容易に」を照合識別の要件としていることからの類推である。

一方、散在情報を対象とする場合には、「容易に」のない照合識別要件が用いられている。これは、情報公開法(1999年)が先に採用した定義であり、行政文書という散在情報を対象としているが故に必要だった要件であったと考えられる。その後に作られた現行の行政機関個人情報保護法も、「保有個人情報」という行政文書を対象としたことから、情報公開法同様に散在情報を中心とした規律となっており、そのため、照合識別の要件も、情報公開法と同じく「容易に」のない照合としたものである。

散在情報における照合による識別は、1つ1つの文書を個別に検討*7して照合ができるかが問われる。実際、情報公開法の不開示情報の運用は、まさに個別に慎重に判断されているのであるし、行政機関個人情報保護法でも、行政文書が個人情報を含むかは個別に判断せざるを得ない。(これを「散在情報的照合性」と呼ぶことにする。)

もし、処理情報(民間部門では「個人情報データベース等」、昭和63年法では「個人情報ファイル」)に対して、散在情報と同様に「容易に」のない照合識別要件を適用したらどうなるか。数百万件からなる「個人情報ファイル」について、その一つ一つの要素が他の情報と照合することができるものとなっているか、把握せよというのは現実的でないだろう。

これに対して、処理情報に対する「容易に照合することができ」とは、もっぱら、複数のファイル間で、その要素が1対1対応するものとなっているか否かを問うものである。これは、当該ファイルを設計した時点で当事者にとっては明らかであり、一つ一つのデータごとに検討する必要がない。このことをもって「容易に」としているのである。(これを「処理情報的照合性」と呼ぶことにする。)

ここで、次の点が問題となる。現行の行政機関法は、「個人情報ファイル」(2条4項)について第3章の規定を設けているが、この「個人情報ファイル」の該当性判断には、散在情報的照合性と処理情報的照合性のどちらを適用するのか。

定義の条文からすれば、「容易に」の文言はないので、散在情報的照合性が適用されるかのようであるが、現実の運用としては、昭和63年法の「個人情報ファイル」と同じように、処理情報的照合性で判断されているのではないか。

この点、本来は、現行の行政機関法も、ファイルの「個人情報ファイル」該当性判断においては、「他のファイルと容易に照合することができ」といった定義とすることで、散在情報の規律(2章、4章)とは区別して扱うべきだったと考える。にもかかわらず、これが、ファイルの要素ごとに個人情報該当性を定義して、当該要素の「集合物であってそれを検索できるように体系的に構成したもの」と定義されていることから、本来の趣旨からずれた定義条文となってしまった。昭和63年法でこのような定義方法が用いられていて、そこでは処理情報が前提であったから、それでもなんとなく矛盾しない定義規定だったのが、現行法がその定義様式を受け継いで、かつ、散在情報的照合性を導入したものだから、綻びが顕在化したものである。

もっとも、「個人情報ファイル」該当性が処理情報的照合性によって否定されるファイルがあるときに、そのファイルの各要素を見たときに、散在情報としての保有個人情報に該当するものが存在するときは、散在情報的照合性によって判断される。すなわち、「このファイルは個人情報ファイルに該当しないが、要素の一部に保有個人情報に該当するものがある。」という扱いがあり得るということである。

以上が、「照合による識別」解釈の私の説(独自の見解)である。

この説を、今回の件に当てはめると、以下のように言える。(ここでは、煩雑さを避けるため、民間部門の「個人情報データベース等」を公的部門の「個人情報ファイル」で言い換えている。)

民間部門の匿名加工情報は、処理情報的照合性で個人識別性が排除されるので、元データの個人情報ファイルと加工データのファイルとの間で、照合ができないデータになっていれば足りることになるため、k=2のk-匿名化(というかグループ化)によって、加工ファイルは個人情報ファイルに該当しなくなる。

公的部門の匿名加工情報については、加工方法における匿名加工情報該当性判断と、当該匿名加工情報を提供してよいかの判断とで、2段階に分けられる。

加工方法については、民間部門の匿名加工情報と同じであり、元データの個人情報ファイルと、加工データである匿名加工ファイルとの間で、照合ができないデータに匿名加工すれば、匿名加工情報に該当する。ここでは、照合識別要件該当性は処理情報的照合性で判断される。

次に、そうして作成された匿名加工情報のファイルを、いざ提供しようというときには、そのファイルの各要素に、「保有個人情報」に該当するものが残存していないか確認し、存在すればそれを除去する必要がある。そうしなければ、保有個人情報の目的外提供となって行政機関法8条に違反する。ここでは、照合識別要件該当性は散在情報的照合性で判断される。

民間部門にはこの義務がなく、この作業は手間のかかるものかもしれないが、情報公開制度で個人情報ファイル丸ごとに対する開示請求があった場合には、その手間をかけているのだから、行政機関にとってはその延長といえるかもしれない。

このように整理すると、「容易に」の有無の違い、匿名加工情報の範囲、情報公開制度との関係、いずれも違和感なく整理できると思う。まとめると以下となる。

  • 行政機関の匿名加工情報は、加工方法における個人識別性排除のための照合識別要件は、民間部門と同じである。
  • 民間部門との違いは、保有個人情報の目的外提供とならないためのチェック工程が追加的に必要となることにある。
  • このチェック工程で想定すべき照合先は、「図書館等の公共施設で一般に入手可能なものなど一般人が通常入手し得る情報」であって、行政機関内の元データではない。(元データとの処理情報的照合性は匿名加工で既に排除されているから。)

追記(7日)

「考え方(案)」の「(案)」が取れた最終版が公開された。紛糾した12頁は修正されたのだろうか。確認してみると、13頁へずれて、以下の内容となっている。

  • 行政機関等が保有するパーソナルデータに関する研究会, 行政機関個人情報保護法・独法等個人情報保護法の改正に向けた考え方, 2016年3月7日, 13頁

    なお、行政機関等が作成する匿名加工情報は、特定の個人を識別することができないように個人情報を加工して得られる個人に関する情報であって、当該個人情報を復元することができないようにしたものであるが加工に用いた個人情報自体などとの照合により特定の個人を識別することができることから、行政機関個人情報保護法・独法等個人情報保護法の個人情報に当たるものであると考えられる。本研究会においては、加工基準がまだ定められていない中、行政機関等の匿名加工情報が個人情報に該当する場合も検討対象に含めておくべきとして議論をしてきたところであるが、基本的な考え方としては、個人情報に該当しても、個人の権利利益の保護が図られるための規律が設けられ、また、官民の匿名加工情報の流通に支障が生じないのであれば問題は無いものと言えよう。

矛盾することが同じ段落に集められただけで、何も説明になっていない。

行政管理局は、この研究会で、「容易に」を程度問題と捉え、いかなる趣旨で使い分けられているか、歴史的経緯を調査して明らかにするといったことをしなかった。事務局も構成員も、論理パズルを解こうとするばかりで、歴史を踏まえるとか、どうあるべきかという観点で、個人識別性を論ずることはなかった。

*1 総務部会・IT戦略特命委員会合同会議、議題「行政機関等の保有する個人情報の適正かつ効果的な活用による新たな産業の創出並びに活力ある経済社会及び豊かな国民生活の実現に資するための関係法律の整備に関する法律案」について【法案審査】」とある。

*2 とはいえ、どういう解釈でそのように整理できるかについては、未だ適切に整理されているとは言い難い状況がある。詳しくは「匿名加工情報は何でないか・後編」で書く予定。

*3 2015年12月6日の日記「匿名加工情報は何でないか・前編(保護法改正はどうなった その2)」参照。

*4 詳しくは、「パーソナルデータ保護法制の行方 その9」で書く予定。

*5 もう一つの可能性を思いついたが、これは「匿名加工情報は何でないか・後編」を書いた後でないと説明が簡単でないので、またの機会にする。

*6 詳しくは、「散在情報と処理情報(パーソナルデータ保護法制の行方 その3)」を書いて、「Q14問題とは(パーソナルデータ保護法制の行方 その9)」を書いた後で、また書く予定。

*7 「特別の調査をすれば入手し得るかもしれないような情報」(行政管理局「解説 行政機関個人情報保護法」より)まで実際に調査してみることが求められるわけではないが、「図書館等の公共施設で一般に入手可能なものなど一般人が通常入手し得る情報」(同)であるか否かは、個別に文書ごとに判断する必要がある。

本日のリンク元 TrackBack(0)

2016年03月14日

治外法権のeLTAX、マルウェア幇助を繰り返す無能業者は責任追及されて廃業に追い込まれよ

ここ数年、不正送金の被害がインターネットバンキングの法人口座で急増しているという*1。その原因は今更言うまでもなく、Java実行環境(JRE)やAdobe製品の古いバージョンの脆弱性を突いてくるマルウェアである。しかしそれにしても、法人口座を扱うパソコンがなぜ、Java実行環境やAdobe製品をインストールしているのだろうか。インストールしなければ被害も起きないのに……。

その謎を解く鍵が、eLTAX(地方税ポータルシステム)にあるようだ。eLTAXでは、インターネットバンキングの口座を用いた納税ができることから、インターネットバンキング用のパソコンでeLTAXの利用環境も整えるということが普通になっていると思われる。そのeLTAXが、昨日までは、Java実行環境のインストールを強要していた。eLTAXはこの危険性を認識していたのか、3月11日の時点では、トップ画面に赤字で以下の注意書きを掲示していた。

画面キャプチャ
図1: eLTAXが利用後はJavaを最新版にせよと指示していた様子

これに関してTwitter界隈の様子を調べてみると、案の定、阿鼻叫喚が渦巻いていた。

これはけしてJavaが悪いわけではなく、アップデートしたくらいで動かなくなる(メジャーバージョンが変わったわけでもないのに)ようなeLTAXのアプレットの実装なり設計なりが悪い。おそらくは、起動時に「u73」のところのバージョン文字列をチェックして、所定の番号でない限り動かないように業者がわざと作り込んでいたのだろう。こういう話は2007年までに散々書いており、もうお腹いっぱいだった。

こうした類の問題は、国の政府機関についてはとっくに解決済みである。この2007年の報道で、厚労省の脆弱性放置が大々的に報じられ、当時の内閣官房情報セキュリティセンターが対応をとったことによる。現在の「政府機関の情報セキュリティ対策のための統一基準」では、以下の事項が規定されており、これに違反すれば政府機関は対応を迫られることになる。

遵守事項

6.3.1 (2) アプリケーション・コンテンツのセキュリティ要件の策定

(a) 情報システムセキュリティ責任者は、府省庁外の情報システム利用者の情報セキュリティ水準の低下を招かぬよう、アプリケーション・コンテンツについて以下の内容を仕様に含めること。

(オ) 提供するアプリケーション・コンテンツの利用時に、脆弱性が存在するバージョンのOSやソフトウェア等の利用を強制するなどの情報セキュリティ水準を低下させる設定変更を、OSやソフトウェア等の利用者に要求することがないよう、アプリケーション・コンテンツの提供方式を定めて開発すること。

解説

遵守事項6.3.1(2)(a)(オ)「脆弱性が存在するバージョンのOSやソフトウェア等の利用を強制する」について

行政サービスを提供する情報システムの提供において、当該情報システムを利用するために、府省庁外の事業者等が作成した汎用のソフトウェアやミドルウェアのインストールが利用者の端末で必要となる場合がある。この場合、利用者は府省庁から指示されたソフトウェアを自身の端末にインストールせざるを得ないが、指定されるソフトウェアのバージョンが古く、脆弱性が存在するものであると、利用者の情報セキュリティ水準を府省庁が低下させることになる。したがって、脆弱性が存在するバジョンのOSの利用やソフトウェアのインストールを府省庁が暗黙又は明示的に要求することにならないよう、アプリケーション・コンテンツの提供方式を定めて開発しなければならない。

(略)例えば、当該行政サービスを利用するために、第三者が提供している汎用のソフトウェアのインストールを必要としていたとする。このとき、当該ソフトウェアに脆弱性が発見され、それを修正した新バージョンのソフトウェアが公開された場合に、当該新バージョンのソフトウェアをインストールすることで当該行政サービスに不具合等が生じて利用が不可能になるような事態が発生すると、利用者は、当該ソフトウェアを新バージョンに更新することができなくなる。結果として、府省庁の行政サービスが利用者の脆弱性回避を妨げることになってしまう。こうしたことが起きないよう、行政サービスを提供するシステムは、第三者の汎用ソフトウェアの併用を前提とする場合は、当該汎用ソフトウェアが新バージョンに置き換わっても、正常に動作するように設計する必要がある。予期せず不具合が発生する事態が発生した場合にも、行政サービスを提供するシステムを修正することができるよう、迅速に新バージョンのソフトウェアに対応することを保守契約に盛り込んでおくことが望ましい。

(略)

なお、開発時に公開されているバージョンだけでなく、例えば、利用を想定しているブラウザの次期バージョンについて、ソフトウェアの配布前に情報が公開された状態又は試用版ソフトウェアが配布され動作検証可能な状態にあれば、前もって利用可能かどうかを検証するなど、その後に公開が想定されるバージョンにも対応できるよう、構築時に配慮することが望ましい。

遵守事項6.3.1(2)(a)(オ)「情報セキュリティ水準を低下させる設定変更を、OSやソフトウェア等の利用者に要求する」について

行政サービスを提供する情報システムを利用するために、利用者の端末にインストールされているソフトウェア(府省庁が直接提供していないソフトウェア(例えば、端末のOSやウェブブラウザ等))の設定変更を必要とするとき、その設定変更が情報セキュリティ水準の低下を招くものである場合、そのような設定変更を要求してはならない。必要があって利用者に設定変更を求めるときは、そのOSやブラウザの標準設定(初期設定)に変更することのみを求めるものとすること(略)

政府機関の情報セキュリティ対策のための統一基準, 内閣サイバーセキュリティセンター

しかし、この基準は地方公共団体には適用されない。日本国憲法92条がいう「地方自治の本旨」により、「地域のことは地方公共団体が自主性・自立性をもって、国の干渉を受けることなく自らの判断と責任の下に地域の実情に沿った行政を行っていくこと」とされているからである。eLTAXは地方公共団体が寄り集まって運営(組織概要参照)しているので、誰も彼らに指図することはできず、10年経ってもこのザマだった、というわけである。

Twitterにはこんな悲痛の叫びもあった。

これは、eLTAXが、JRE(Java実行環境)の開発者向けテスト用バージョンのインストールを一般人に強制していたからのようだ。eLTAXは去年の時点では以下の説明をしていた痕跡がある。

「Archive」とあるように、これは過去分の保管用のものであり、一般人向けのインストーラではない。URL中に「technetwork」とあるように、このページ自体がそもそも開発者向けのコンテンツである。そのため、「ダウンロードするには「Oracleプロファイル」が必要です。」という事態になっている。つまり、eLTAXは、一般人の利用者たちに、Java開発者の登録をさせていたのである。このばかげた手順は、以下の手順書にガッつり書かれている。

この手順書の指示通りに、http://www.oracle.com/technetwork/java/javase/downloads/java-archive-javase8-2177648.html#jre-8u66-oth-JPR のURLにジャンプすると、ページの途中へジャンプしてしまい目にすることはないが、このページの冒頭には、ちゃんとこういう注意書きがある。

画面キャプチャ
図2: eLTAXの指示通りにジャンプすると目に入ってこないページ冒頭部分の警告と注意書き

赤字のあたりに、「「警告:この旧バージョンのJREとJDKは、開発者が古いシステムのデバッグするのを補助するために提供されるものです。これらは、最新のセキュリティパッチが適用されておらず、実際の製品での使用は推奨されません。」とあり、下のところに、「Only developers and Enterprise administrators should download these releases.」つまり、「開発者及び企業の管理者以外の者は、これらのリリースをダウンロードしてはならない。」とある。eLTAXは、これを無視して一般人にインストールさせたばかりか、事もあろうに、この警告が目に入らないようにページの途中にリンクさせて一般人を騙し、Oracle開発者登録させ、インストールさせていたのである。これはもはや犯罪行為に等しい。

この話も10年前にもう書いていたので、正直お腹いっぱいだ。2005年には最高裁がこれをやらかしていた。(この当時は開発者登録は不要だったが。)

そのeLTAXが、今日からJavaのインストールが不要になったというので、冒頭の警告メッセージを以下のものに差し替えている。

画面キャプチャ
図3: eLTAXの本日からの画面

「Java実行環境をアンインストールしてください」としているが、Oracleプロファイルの会員登録削除も促して然るべきだろう。無論そのためには、開発者向けのことを一般人にさせていた己の不明を詫びなければ、理由の説明にならない。

それにしても、10年間怠惰に徹してきたeLTAXが、ここにきてJava実行環境を必要としない方法に改めた背景には何があるのか。脆弱性のあるJREをインストールさせていたことが、銀行の不正送金被害を許す原因となっていたことが判明して、シャレで済まなくなったのではないか。*2

この仕様変更のお知らせが、2月2日から出ていた。

「ActiveXコントロールのインストールが必要」とのことで、Twitter界隈はまたまた阿鼻叫喚で溢れていた。

そして、この変更に伴い、「初めてのeLTAXをご利用の方はこちら」のボタンから進むと出てくる「必要な設定」のページの「STEP3」が次のものに差し替えられていた。

嗚呼、これはシャレにならない。「署名済みActiveXコントロールのダウンロード」を「有効」に設定しろだと? 2016年にもなって新たにこれを書かなくてはならなくなるとは思いもよらなかった。以下の表を示したのはもう10年も前のことだ。どうしてこんな簡単なことがわからないの?

そもそも、実際にやってみればわかることだが、2006年にIE 7が出たときに、こうした危険な設定をしようとすると、設定画面がオレンジ色になって、警告が出るようになっている。*3

画面キャプチャ
図5: eLTAXが指示する設定をしようとするとIEが警告を発する様子

これまで脆弱性のあるソフトを入れろと指示し、利用者は皆それに従ってきたのだから、このような理不尽な設定でも従順に従う人が続出するだろう。そして、次にやってくるのは、ActiveXコントロールを用いたマルウェアだ。日本の銀行の法人口座を狙う犯罪者らは、eLTAX利用者がこの設定をしていることに目をつけ、ActiveXによるマルウェアを頒布してくることになるだろう。

いったいいつまでこういう阿呆なことを繰り返すつもりか。法人口座から不正送金マルウェアでお金を盗まれたら、eLTAXを疑うとよい。eLTAXの指示に従ったせいで被害が出たことを示して、損害賠償を求め地方税電子化協議会を訴えよう。それ以外、誰にもこの無能どもを反省させる術はない。

追記(19日)東洋経済オンラインの的外れ記事

上記の日記を書く過程でTwitterを「eLTAX」で検索したとき、ITジャーナリストの本田雅一氏がeLTAXのActiveX化に不満のツイートをされているのを見ていた。東洋経済オンラインに記事を書いたとのことだったので、楽しみにしていたところ、18日にその記事が出た。これがよくある的外れな内容になっていたので、以下に批判しておきたい。

私の上記の日記を見た後で原稿を仕上げた様子だが、出てきた記事は以下だった。

eLTAXの事務局に今回のシステム移行について問い合わせたところ「これまで利用されていたJava実行環境に代わるものとして、ActiveXコントロール以外の代替技術とのセキュリティ面を含めた比較検討を行い採用を図っております」との返答を受けた。

(略)

前出のように、国税庁は、eLTAXにおいて「代替技術とのセキュリティ面を含めた比較検討」のためにActiveXコントロール使ったと説明している。この文言だけを取り上げると時代錯誤甚だしいのだが、その背景には、2001年から2006年まで政府が推進していたe-Japan戦略がある。

本田雅一, 日本の電子納税は「時代錯誤」になっている エルタックスの寒すぎる実態, 東洋経済オンライン, 2016年3月18日

eLTAXに電話取材したのはプロフェッショナルで結構だが、取材先の一般社団法人地方税電子化協議会を国税庁と取り違えており、記事の内容も全体を通してeLTAXとe-Taxを混同しているようで、これは噴飯ものだ。

技術的にも、聞きかじった生半可な知識で書いているため、誤った結論が導かれている。以下の部分はほとんど間違いしか書かれていない。

このICカードを取り扱うためのWebブラウザ向けの仕組みは、JavaかActiveXコントロールしかない。このため、eLTAXではJavaを採用していたのだろう。ただし、Java時代のeLTAXの新規申し込みページも、Intenet Explorer以外のWebブラウザではエラーが発生して動作しないお粗末なものだった。

こうしたお粗末なシステム納品を受け入れてしまう側にも問題はあるが、これを変更せざるを得なくなった理由は、eLTAXのJavaアプレットが最新のJRE(Javaを動かすためのソフトウェア環境)に対応できなくなったからだ

JREはセキュリティ問題への対応へのアップデートを繰り返しているが、最新JREでeLTAXの新規申し込み用アプレットが動作しなくなった。このため、eLTAXの新規申し込みを行うために、わざわざセキュリティの脆弱性が明らかになっている古いバージョンに差し替えてから申し込みを行い、さらに古いJREを削除した上で新しいものをインストールするという、驚くほど稚拙な対応を利用者に求めていた。

こうした状況を打破するために、新しいJava環境で動作するよう作り直すことも含めて検討した上で、いっそのことActiveXコントロールへの切り替えが適切と判断したのだろう。Javaには頻繁に脆弱性が見つかっており、最新環境に追従していくためのコストが高いとみられる。Java環境での再開発に継続投資するよりも、現時点で実績のあるActiveXコントロールを使ったということなのだろう。

本田雅一, 日本の電子納税は「時代錯誤」になっている エルタックスの寒すぎる実態, 東洋経済オンライン, 2016年3月18日

第1に、Webブラウザでの利用を前提とした場合に、「JavaかActiveXコントロールしかない」は誤りで、Webブラウザのプラグインを用いる方法もある。実際、2003年ごろ政府の電子申請システムが始まった初期の頃には、プラグイン方式のものもあったと記憶している*4し、日経コンピュータ誌の浅川記者が、エストニアではプラグイン方式だと指摘している。

第2に、ActiveXへの変更が、「最新のJREに対応できなくなった」ためだというが、eLTAXの「地方税電子化協議会からのお知らせ」を見ればわかるように、eLTAXが最新のJREに即応できないのは以前からで、JREのリリースから遅れての対応を何度も繰り返している。その意味ではずっと前から同じ状況だったのであり、突然「対応できなくなった」わけではない。

eLTAXのサイトをInternet Archiveで過去にさかのぼってみるとわかるように、2015年7月10日の時点までは、冒頭の赤字の注意喚起がなかったのが、2015年7月30日の時点で初めて赤字の警告*5が出た様子がうかがえる。それまでは危険性を放置していたわけだ。7月からこの警告を出さざるを得なくなってお尻に火がついたのだろう。

上で既に書いているように、これは10年前に国の政府機関も通った道であり、今ではこんな馬鹿げた注意喚起はもうやっていない。なぜなら、特定のアップデートバージョンでしか動かないようなJavaアプレット実装にはしていないからだ。これは2007年ごろに解決した話であり、やればできることなのに、一般社団法人地方税電子化協議会と業者がそれをしなかっただけのことだ。

第3に、「Javaには頻繁に脆弱性」「実績のあるActiveXコントロール」などと言っているが、これらを対比させるのは間違い。Java(というかJRE)は実行環境であり、環境であるがゆえに脆弱性が見つかると他に影響が出るので放置できないが、利用者が他の様々な用途でJREを使っているなら(今日では電子申請くらいでしか使われなくなりつつあるが)ば、元々JREは日々アップデートすべきものであり、そうしている限りは問題がない。ActiveXも、安全にActiveXコントロールを動かすために日々Windows Updateをしているわけで、JREと対比すべきはWindowsであり、両者に違いはない。繰り返すが、アップデートで動かなくなるようなJavaアプレットの作り方を続けていた業者と協議会が無能なだけの話。

局所的な事実だけを追えば、理に適っているように見えるが、2016年の今にあって、それは時代錯誤ともいうべきものだ。e-Japan構想で「世界最先端のIT国家実現に向けて」と取り組まれた結果が、むしろグローバルで見ると時代遅れの仕組みを生み出した

(略)

こうした現状に対してICカードによる認証システムを残したまま、問題解決する方法を模索する道はあると指摘する声もある。従来の公的個人認証サービスで使われているICカードに加え、NFC(近距離無線通信)での標準化、そしてWeb標準を決めている標準団体W3Cへのロビー活動を通じて、ブラウザ自身がICカードを用いた公的個人認証サービスい対応すれば、将来にわたってのサポートや、カードの互換性、利便性といった面での問題解決につなげることはできるからだ。

あとは、政府自身がどのように将来を見すえているかだが、その見通しが晴れているようには思えない。まだ、混乱は続きそうである。

本田雅一, 日本の電子納税は「時代錯誤」になっている エルタックスの寒すぎる実態, 東洋経済オンライン, 2016年3月18日

第4に、「それは時代錯誤ともいうべきものだ」と言うが、それが単に「ActiveXを使うことが時代錯誤だ」という意味ならば、まあある面でそうではあるけれども、「e-Japan構想」のせいだと言っているので、ICカードや電子署名を用いること自体が時代錯誤だと言いたいのだろう。前記の通りプラグイン方式を選択する道もあるのだから、そのような論理展開は誤りだ。

単に「ActiveXダサい」と言いたいのだとすれば、私の上記の日記に釣られた面もあるかもしれないが、私が書いたことは、「署名済みActiveXコントロールのダウンロード」を「有効」に設定しろという不適切な指示をしていることについてであり、ActiveX方式を採用すること自体を否定したわけではない。

もっとも、ActiveXコントロールを用いるのが「時代錯誤」だというのは別の意味で正しい。本田氏は理解していないだろうが、ActiveXコントロールが時代遅れとされ、廃止に向かっている理由は、Web画面でいきなり実行モジュールをボタン一つで自動インストールできるという仕組み(以下「オンデマンドインストール」)自体が危険なものであるからで、Microsoftはその対策のために、Windows XP SP2の時点で、Web画面の上部に現れる黄色の「情報バー」で許可の操作をしないとインストールのポップアップが出ないようにした。このときActiveXは死んだのであり、もはや互換性のために生かされてきただけだった。こんなわかりにくい操作方法を利用者にさせるくらいなら、別途ダウンロードして使う外部インストーラでプラグインをインストールする方がエレガントだという共通認識ができあがっていたわけである。その点で、署名Javaアプレットも同様の仕掛けであり、同様の意味で時代遅れだと言える。

このように、「時代錯誤」なのはオンデマンドインストールを用いることであって、ICカードや電子署名を用いること自体では必ずしもない。そもそもなぜ、電子申請システムを設計している人たちはこんなにもオンデマンドインストールを使いたがるのか。「信頼済みサイト」に登録しろという指示も散見される*6が、そんなことをさせるくらいなら、普通の外部インストーラでインストールする方が混乱がないだろう。結局のところ、ボタンを1回押すだけで自動実行などというのは、大昔に見た儚い夢だったということだ。

第5に、ICカードを残すなら「Web標準を決めている標準団体W3Cへのロビー活動」が必要だなどと、どこで聞き齧ってきたのか*7知ったかこいているが、標準化など必要としない。標準化が真に必要となるのは相互運用性が必要な場合であり、ここの用途ではそれがない。日本独自の電子署名方式を用いているのであっても、直接その独自方式を使用するプラグインを作ればいいだけ*8の話。(うまくいくのならば、JavaアプレットやActiveXコントロールでも同様。)

こういう生半可な知識の記事が横行すると、誤った理由で電子署名をやめよという話にされかねないので、危うい。

そして最後に以下の点。

「政府に言わないと」と言うが、2007年ごろに政府に直接言った*9から、国の政府機関ではここの問題は解決済みとなっているのであるし、ここ数年は政府の中の人であるから、いろいろやっている。

それに対してeLTAXは、国の権限が及ばないから、問題が解決してこなかったし、解決する手段もない。だから「治外法権のeLTAX」というタイトルにしたのだし、その理由も「日本国憲法92条がいう地方自治の本旨により」云々のくだりでちゃんと書いている。

そのような意味で、このブログにとってeLTAXの件は新しいテーマだから書いたものだ。このテーマは、ちょうど今ホットになっている個人情報保護法制において地方公共団体が個人情報保護委員会の監督下に置かれない問題(いわゆる「2000個問題」)とも共通する。もはや政治レベルの課題である。

追記(22日)

まだ書き足りてないことがあったので念のため追記。上の追記では、Webブラウザで使うことを前提とした場合についてどうなのかを書いたが、それ以前に、Webブラウザを使わず独自の専用プログラム(ネイティブアプリ)で構築する方法がある。このことは2007年のときに既に書いた。実際、他の電子申請システムはそうなっているものが多いし、このeLTAXでも、電子申請の本体はそうなっていて、「利用届出(新規)の手続き」でのみActiveXコントロール(かつては署名Javaアプレット)が使われている。住所氏名等を書いてアカウント作成を申し込むだけのことに電子署名が要るのかというそもそも論がある*10が、仮に必要だとしても、たったこれだけのためにWebブラウザからできるようにすることにいかほどの意味があるのか。とっつきやすいようにとのつもりかもしれないが、どのみちネイティブアプリをインストールしなければ何もできないのだから、そこに「利用届出(新規)の手続き」の機能を設ければいいだけだという話もある。もっとも、Webでやるのかネイティブアプリでやるのかの選択に、開発コストの面があることも本当は書かないといけないところで、HTMLで書いた方が各OSで共通にできることや、HTMLで書いた方が開発が容易な面(本当にそうなのかは大いに疑問でもある)もあるだろう。しかしそこには、ミドルウェアとの整合性を維持するためのメンテナンスコストも踏まえなければならない。昨今のスマホアプリの開発モデルを見習えば、ネイティブアプリとして開発する方が早いと言えるのかもしれないし、また、別の案として、HTMLを使ってネイティブアプリを開発する手法もあり得るだろう。

*1 参考検索例:「法人口座 不正 送金 被害

*2 昨年6月に、日本税理士会連合会が「電子申告に関する要望事項(eLTAX編)」を地方税電子化協議会に提出しており、そこに「Javaを利用しなくても利用可能なシステムとすること。」が要望として出ていた。

*3 2006年5月13日の日記参照。

*4 証拠を探してみたが、すぐには見つからなかった。

*5 「eLTAXの利用届出等を提出する際に使用したJava実行環境は、セキュリティ対策の観点から、直ちにJavaの最新のバージョン(Java8u51)に切り替えるか、又は無効化をしていただきますよう、ご注意願います。」とある。

*6 eLTAXは、eltax.jpという.jpのドメイン名のURLを「信頼済みサイト」ゾーンに登録しろと指示しているので、未来永劫eltax.jpのドメイン名を維持し続けるか、放棄する前に、全ての利用者が確実にその信頼済みサイト設定を削除するのを確認する責務が生じている。

*7 どうやらここで聞きかじったらしい。このツイートで教えていただいた。「Oracleがやめるぞといっててランタイムの配布ページが英語版しかない」というのもどこの話だ?現時点で https://java.com/ja/download/は日本語だが? もしかして「Arcive Downloads」のことを言っているのか? あれが一般向けの配布でないことに気づけないなら、地方税電子化協議会と同レベルで無能だろう。大丈夫か?

*8 むろん、標準化されればベターではあるが、それは、独自実装の範囲を最小限にできる(ライブラリやAPIに投げられる)ということにすぎない。

*9 それゆえ2007年で「電子政府」関係のブログエントリは終わっている。

*10 この部分において電子署名は不要だと思う。e-Taxではこれが必要とされておらず、即座にアカウントが作成できるようになっている。もっとも初回に電子証明書を登録する作業があって、これも要らないと思うが、いろいろあれでこちらはまだまだ簡単な話ではない。

本日のリンク元 TrackBack(1)

2016年03月27日

行政機関匿名加工情報取扱事業者に再識別禁止の義務はかかるのか(パーソナルデータ保護法制の行方 その21)

前々回の「行政機関法では匿名加工情報が個人情報に当たるですって?」で書いていた、行政機関等が保有するパーソナルデータに関する研究会の最終報告書「行政機関個人情報保護法・独法等個人情報保護法の改正に向けた考え方」が公表された翌日、行政機関法の改正法案*1が閣議決定され、国会に提出された。

有意義な制度が誕生する予感

これは画期的な法案だと思う。去年成立した個人情報保護法の改正法では、民間部門に匿名加工情報の制度を設けたものの、その必要性が疑われるものとなってしまった*2のに対し、行政機関の匿名加工情報の制度は、非個人情報の提供にすぎない点では民間部門と共通であるものの、行政機関が自ら提案の募集をしなければならない点で、全く異なる性質のものだ。(独立行政法人もこれに同じ。)

正直ここまでやる気があったとは予想外だった*3一昨年12月の情報ネットワーク法学会のパネル「プライバシー・パーソナルデータアップデート」(動画)の席で、私は次のように述べていた。

板倉 (略)高木さんはほとんど傍聴に行かれていたと思いますが、何かこの研究会についてご感想があればお願いします。

高木 今、最後に石井先生からご指摘のあった、「提供しなければならない」ということがなぜ入っているかという部分は、研究会を傍聴していたところ、松村先生……。

板倉 松村雅生先生でしょうか。

高木 情報公開法の先生がおっしゃるには、結局、これはオープンデータとして活用していくことを推進するためだけども、行政に対して「利用できる」という形で個人情報保護法に穴開けをして、「やっていいですよ」としたところで、行政はやりはしないだろうと。オープンデータを推進するのであれば、「しなければならない」としないと、誰もやらないという指摘がありました。

それから、情報公開法の延長で、オープンデータ的なものができるかという話がありました。つまり、事業者が「こんなデータが欲しい」ということを行政機関に求めたときに、今の情報公開法の考え方では、情報をいじってはいけない。消すことについては一部隠すことはできるが、それ以外はそのまま出さなければいけないという制度ですから、統計化してほしいとか、k-匿名化して半生データが欲しいというような要求に対して、法の趣旨からして加工してはならないので、そういうのは成り立たないのだということで、そういう本当にやりたいことが、どちらの制度でも実はできないのではないか、という議論がありました。そのことがそのまま書かれているのだと思います。

私の意見としては、本当にオープンデータをやりたいのであれば、むしろオープンデータ推進基本法なりを作ってやらないと、この議論の延長ではできないというふうに思いました。

情報ネットワーク・ロレービュー講演録編, 第14回研究大会講演録, 190頁

これが本当に実現されることになった。オープンデータ法ではなく、保護法に盛り込まれたところには違和感があるにしてもだ。行政機関も独立行政法人も、情報公開と個人情報保護を担当してきた部署が、提案の募集と、提案の審査、匿名加工の発注と、受領者との契約など、これまになかった業務をこなさなくてはならなくなるわけで、その覚悟ができたことに驚いた。

また、昨年10月20日の日記「行政機関等パーソナルデータ制度改正に対するパブコメ提出意見」で示していた「意見2」の願いは叶った。この「意見2」は、匿名加工のソースとする元データは、散在情報の保有個人情報を対象とせず、個人情報ファイルを構成する保有個人情報に限るべきとしたものであったが、改正法案では、「行政機関匿名加工情報」*4の定義(2条9項)で、「次の各号のいずれにも該当する個人情報ファイルを構成する保有個人情報(略)の全部又は一部を加工して得られる匿名加工情報をいう。」とされたので、期待した通りとなった。

名称変更の謎

しかし解せないのは、「匿名加工情報」だったはずの用語が、どういうわけか、「非識別加工情報」などという別の名前になっており、名前を変える理由が謎になっていることだ。国会提出後に新旧対照表と同時に公表された「概要」の資料では、図1のように「匿名加工情報」のままとなっており、何か不測の事態が起きたように見える。

PDFの資料の1ページ
図1: 法案の「概要」の資料では「非識別加工情報」ではなく「匿名加工情報」と書かれている様子

この資料に、「個人の権利利益を侵害することにならないよう、民間事業者と行政機関等の双方に必要な規律を課す」とあるように、双方に義務を課すのだから、同じ名前でないと辻褄が合わないように思える。

民間事業者に規律を課すとあるが、今回の改正案に、民間事業者に再識別禁止の義務を課す新たな規定は含まれていない。行政機関個人情報保護法に民間事業者の義務を規定することを避けたのであろうか、どうやら、昨年の改正法で改正される個人情報保護法の38条(識別行為の禁止)でそれを拾う趣旨のようである。

今回の改正法は、個人情報保護法38条も改正するものとなっており、その改正部分は以下の下線部の挿入である。

(識別行為の禁止)
第38条 匿名加工情報取扱事業者は、匿名加工情報を取り扱うに当たっては、当該匿名加工情報の作成に用いられた個人情報に係る本人を識別するために、当該個人情報から削除された記述等若しくは個人識別符号若しくは第36条第1項、行政機関の保有する個人情報の保護に関する法律(略)第44条の10第1項(同条第2項において準用する場合を含む。)若しくは独立行政法人等の保有する個人情報の保護に関する法律第44条の10第1項(同条第2項において準用する場合を含む。)の規定により行われた加工の方法に関する情報を取得し、又は当該匿名加工情報を他の情報と照合してはならない。

この挿入部分は、取得を禁じようとする「36条1項の規定により行われた加工の方法に関する情報」に、行政機関法と独法法の規定で行われた加工の方法に関する情報も加えるという趣旨であり、それを超える意味はなさそうである。(ここに、「行政機関法2条8項の非識別加工情報を取り扱う場合もこの規定の◯◯を◯◯と読み替えて準用する。」といった規定があるわけではない。)

ここで疑問となるのが、行政機関法でいう「匿名加工情報」と、個人情報保護法でいう「匿名加工情報」は同一の概念なんだろうかという点である。

行政機関で作成した匿名加工情報(非識別加工情報)が提供されるとき、受領者には「匿名加工情報」の取扱いについて、再識別禁止の義務がかからなくてはならない。再識別禁止義務を前提として提供するのが匿名加工情報制度の元よりの趣旨であるからだ。

法案では名前が「非識別加工情報」となっていて、別の概念ではないかという疑義が生じるところ、別の概念であるとすれば、「非識別加工情報」の受領者に再識別禁止の義務がかからない場合が存在することになりかねない。

定義の内容が同じものを指しているか

名前の問題は置いておくとしても、それぞれの法律で定義された語が指す概念が同一のものであれば、再識別禁止義務は課されるということもできるだろう。

では、両者の定義は同一の概念を指しているのか。以下は、今回の改正法で規定される行政機関法の「匿名加工情報」(非識別加工情報)の定義と、昨年の改正法で規定される民間部門の「匿名加工情報」の定義を並べたものである。両者の違いは、下線部の括弧書き2つが挿入されている点のみである。

行政機関個人情報保護法
第2条
8 この法律において「非識別加工情報」とは、次の各号に掲げる個人情報(他の情報と照合することができ、それにより特定の個人を識別することができることとなるもの(他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを除く。)を除く。以下この項において同じ。)の区分に応じて当該各号に定める措置を講じて特定の個人を識別することができない(個人に関する情報について、当該個人に関する情報に含まれる記述等により、又は当該個人に関する情報が他の情報と照合することができる個人に関する情報である場合にあっては他の情報(当該個人に関する情報の全部又は一部を含む個人情報その他の個人情報保護委員会規則で定める情報を除く。)と照合することにより、特定の個人を識別することができないことをいう。第44条の10第1項において同じ。)ように個人情報を加工して得られる個人に関する情報であって、当該個人情報を復元することができないようにしたものをいう。

個人情報保護法
第2条
9 この法律において「匿名加工情報」とは、次の各号に掲げる個人情報の区分に応じて当該各号に定める措置を講じて特定の個人を識別することができないように個人情報を加工して得られる個人に関する情報であって、当該個人情報を復元することができないようにしたものをいう。

1つ目の「(……もの(……ものを除く。)を除く。)」という二重の除外の括弧書きは、この法案で他のところでも何度も出てくるフレーズで、カオス感を醸し出しているが、これは、行政機関法の中でありながら、「個人情報」の語義を一時的に(「この項において」)民間部門の「個人情報」と同じにするという趣旨であろう。研究会がこだわっていた点である。民間部門と行政機関とで「個人情報」の定義が「容易に」の有無という点で異なるため、行政機関法の「個人情報」から照合による識別部分を除いた上で、容易照合による識別部分を戻すという規定となっている。

しかし2つ目の括弧書きが解せない。「委員会規則で定める情報を除く。」とあるので、委員会規則で範囲を調整できるようになっている。これはいったいどういう意図があるのだろうか。

2つ目の括弧書きは、「特定の個人を識別することができない」の後ろに「(……により、特定の個人を識別することができないことをいう)」と付いているので、「特定の個人を識別することができない」ことの明確化の括弧書きである。この括弧書きで何かを足したり引いたりしているわけではなさそうである。

そういえば、去年の改正法で、民間部門の「匿名加工情報」の定義においても、「特定の個人を識別することができないように」というのが、照合による識別を含むのか否かが解釈上の論点となっていた*5。もしここが、「特定の個人を識別することができないように加工して(他の情報と容易に照合することができ、それにより特定の個人を識別することができることとならないように加工することを含む。)」と規定されていれば、元データとの照合もできないようにしたものという意味になる。

今改正案のこの括弧書きも、そういうことを言っているようにも見えるが、それならばそのように規定すればよいことであり、委員会規則に委任しているのが解せない。

この定義の趣旨について、日経コンピュータの大豆生田記者による、行政管理局への取材記事が先日出た。

  • 国立病院の医療データを活用できる?行政機関個人情報保護法改正案, 大豆生田崇志, 日経ITPro, 2016年3月22日

    ただし、行政機関個人情報保護法の改正案には、改正個人情報保護法にある「匿名加工情報」ではなく、「非識別加工情報」という新たな言葉が登場する。これについて改正案を提出した総務省は、「匿名加工情報と同じもの」(行政管理局)と説明する。

    あえて異なる名称にしたのは、行政機関個人情報保護法と個人情報保護法の間で「個人情報」の定義が異なるため、「匿名加工情報と差がないように、内閣法制局との議論で法制的に整理したもの」(同)という。総務省行政管理局は、今後の国会での議論に向けて分かりやすく説明したいとしている。

これによると、名前は違うが「匿名加工情報と同じもの」だといい、「匿名加工情報と差がないように」した趣旨であるが、「内閣法制局との議論で法制的に整理した」ことが原因でこうなったらしい。

委員会規則へ委任の謎

同じにするという趣旨はわかったが、条文がそうはなっていない。そもそも、このような丸投げの委任規定は合憲なのかという疑問もわく。

一般に、下位法令への委任規定は、何かしらの例示と共にその趣旨を一定程度規定した上で委任するのが通常だという*6。それなのにこの括弧書きは、照合の対象となる「他の情報」から「除く」とする情報の範囲について、「当該個人に関する情報の全部又は一部を含む個人情報その他の」という範囲で委員会規則で定めるとしているだけであり、範囲は「個人に関する情報」「個人情報その他」と広範なうえ、そこからどのように委員会規則で限定するのかという趣旨が何ら規定されていない。

そのため、例えば、委員会規則で定める「情報」の範囲を最大限にとるならば、照合の対象となる「他の情報」から「個人に関する情報」の全てが除外されることになるので、「措置を講じて特定の個人を識別することができないように個人情報を加工」するときに、元データとの照合による特定個人識別を一切考慮しなくてよいことになり、「k=1の仮名化」*7をしただけの詳細な記述の残るデータであっても、匿名加工情報(非識別加工情報)に該当することとなってしまう。

もしそのようになれば、氏名を黒塗りしただけの詳細な個人に関する情報が、行政機関から民間事業者に事業用途で提供されることになり、かなり深刻なプライバシー侵害が大量に発生する危険性が高まる。これは、情報公開法6条2項の規定により氏名を黒塗りして部分開示することに相当するが、情報公開法6条2項は、ただ単に黒塗りすればOKで開示せよとしているのではなく、「公にしても、個人の権利利益が害されるおそれがないと認められるときは」との個別の判断を求めている。これに対し、匿名加工情報(非識別加工情報)の制度には、提供するファイルの要素1個1個についての個別の判断をせよとする規定が存在しないのであるから、その歯止めがかからず、重大な事態を招きかねない。

また、この場合、「k=1の仮名化」では、元データとのデータセットによる照合*8により、特定の個人を識別できることとなるデータであるから、その行政機関においては依然として個人情報のままであって、目的外で提供すれば行政機関法8条(利用及び提供の制限)に違反することになってしまう。*9

そして、この場合、行政機関の匿名加工情報(非識別加工情報)は、民間部門の匿名加工情報とは、名称が異なるだけでなく、その指している情報の範囲も異なるものということになって、これらは別の概念だということになるから、受領者に再識別禁止の義務がかからない事態となってしまう。

他方、委員会規則で定める「情報」の範囲を最小限にとるならば、照合の対象となる「他の情報」に元データは含まれるままとなって、「k=1の仮名化」では匿名加工情報(非識別加工情報)に該当しないということにできる*10ので、民間部門の匿名加工情報と同じく「匿名加工情報は個人情報でない」という性質を確保でき(常にではないが、その点は後述)、匿名加工情報であれば提供できることになる。

委員会規則の定め方によってこんなにも結果が大きく違ってくるのだから、この丸投げ委任の不適切さは看過できないものだろう。どういう趣旨での限定なのか、民間部門の匿名加工情報と差がないようにというのが趣旨であるなら、それを条文に書き込んで然るべきだ。

というか、それ以前に、そもそも、これは明確化の括弧書きであるのに、委員会規則で変更できるということ自体がおかしい。

研究会報告書と提出法案の関係

このように条文を検討したうえで、前々回の「行政機関法では匿名加工情報が個人情報に当たるですって?」の件を再検討してみると、見えてくることがある。

なお、行政機関等が作成する匿名加工情報は、特定の個人を識別することができないように個人情報を加工して得られる個人に関する情報であって、当該個人情報を復元することができないようにしたものであるが加工に用いた個人情報自体などとの照合により特定の個人を識別することができることから、行政機関個人情報保護法・独法等個人情報保護法の個人情報に当たるものであると考えられる。本研究会においては、加工基準がまだ定められていない中、行政機関等の匿名加工情報が個人情報に該当する場合も検討対象に含めておくべきとして議論をしてきたところであるが、基本的な考え方としては、個人情報に該当しても、個人の権利利益の保護が図られるための規律が設けられ、また、官民の匿名加工情報の流通に支障が生じないのであれば問題は無いものと言えよう。

行政機関等が保有するパーソナルデータに関する研究会, 行政機関個人情報保護法・独法等個人情報保護法の改正に向けた考え方, 2016年3月7日, 13頁

松村構成員にあれだけしつこく論理的矛盾を追求されたにもかかわらず、頑として譲らず、この通り、「識別できないようにしたものだが識別することができるから」などと、直球で矛盾する文章を堂々載せたわけだが、これは、まさに前記の2つ目の括弧書きと関係しているように見える。

これは、「識別できないようにしたもの」と「識別することができる」とで、異なる意味で「識別」の語を用いているのだろう。後者は、この文に「照合により」とあるように、照合による識別を含む意味で言っていて、前者は、照合による識別を含むのか含まないのか曖昧なままとなっている。

この前者の曖昧性については、前記の通り、去年の改正法のときから論点になっていたところで、脚注5の通り、照合による識別を含む(省略されているだけである)と解するべきだというのが私の意見である。ここの政府解釈が定まっていないというのであれば、今改正を通じて明確にするのがよい。

さらに、ここで「照合による識別」と平易な文で述べたが、これも、「容易に照合することができそれにより識別」の意味なのか、それとも、「容易に」なしに「照合することができそれにより識別」という意味なのかという曖昧性がある。つまり、民間部門の「個人情報」定義に沿って「識別できないように」とするのか、行政機関法の「個人情報」定義に沿って「識別できないように」とするのかの違いである。

行政管理局は、定義を民間部門のものと「同じもの」「差がないように」したというのであるから、「容易に照合することができそれにより識別」の意味で「識別できないように」の「識別」を解釈することにするのが自然であるように思える*11。――(A)

そうすると、前者の「識別できないようにしたもの」と後者の「識別することができる」とで、「識別」の意味は、「容易に」の有無の分だけ異なるのであるから、研究会の報告書は、この理屈によって「個人情報に当たるものである」という結論を導き出している(この帰結もおかしいが、一旦置いておくとして)のだと、このように読解することができる。

ところが、国会に提出された法案の条文はそうはなっていない。前記2つ目の括弧書きは、「識別できない」の「識別」の意味を、「容易に照合することができそれにより識別」の意味として明確化してはおらず、どのような照合とするかを委員会規則に委任しているのである。どうしてこうなったのだろうか。

もしここを、「容易に」なしに「照合することができそれにより識別」という意味で「識別できないようにしたもの」としていれば、行政機関法の「個人情報」定義に沿って「識別できないように」の意味となるから、行政機関法における匿名加工情報は、行政機関において個人情報に当たらないこととなる。なぜその道を選択しなかったのだろうか。――(B)

どちらの道も選択せず、委員会規則に委任したというのが全く解せない。もしかして、直前まで人によって言うことが違っていて、決めきれなかったということではないのか。もしこれが図星なら、あんまりだ。

(B)の道を選択した場合どうなるか。行政機関において匿名加工情報は個人情報でないことになって都合がよいが、匿名加工の方法の基準(最低限の基準)が、民間部門のものとは異なることになるので、民間部門に向けて作られる匿名加工基準を行政機関でそのまま使えないことになってしまう。行政管理局はこれを避けたかったのではないか。

また、(B)を選択した場合は、「匿名加工情報」の概念が、行政機関法と民間部門とで異なることになるため、行政機関で作成した匿名加工情報について、受領者に民間部門の再識別禁止義務(改正個人情報保護法38条)が課されるのか、法解釈上怪しくなるという問題もある。

どうすればよいのか

結局、(A)を選択するしかないように思える。その場合に問題となるのは、行政機関では「匿名加工情報」に加工しても「個人情報」である場合があるという点である。

重要なのは、常に個人情報となるのではなく、あくまでも個人情報となる場合の存在が否定できないというだけである。その意味で、研究会報告書の「加工に用いた個人情報自体などとの照合により特定の個人を識別することができることから」という、あたかも常にそうなるかのような書きぶりは不適切である。

どうすればよいかの結論は、実は前々回も書いている。その部分を再掲すると以下である。

民間部門の匿名加工情報は、処理情報的照合性で個人識別性が排除されるので、元データの個人情報ファイルと加工データのファイルとの間で、照合ができないデータになっていれば足りることになるため、k=2のk-匿名化(というかグループ化)によって、加工ファイルは個人情報ファイルに該当しなくなる。

公的部門の匿名加工情報については、加工方法における匿名加工情報該当性判断と、当該匿名加工情報を提供してよいかの判断とで、2段階に分けられる。

加工方法については、民間部門の匿名加工情報と同じであり、元データの個人情報ファイルと、加工データである匿名加工ファイルとの間で、照合ができないデータに匿名加工すれば、匿名加工情報に該当する。ここでは、照合識別要件該当性は処理情報的照合性で判断される。

次に、そうして作成された匿名加工情報のファイルを、いざ提供しようというときには、そのファイルの各要素に、「保有個人情報」に該当するものが残存していないか確認し、存在すればそれを除去する必要がある。そうしなければ、保有個人情報の目的外提供となって行政機関法8条に違反する。ここでは、照合識別要件該当性は散在情報的照合性で判断される。

民間部門にはこの義務がなく、この作業は手間のかかるものかもしれないが、情報公開制度で個人情報ファイル丸ごとに対する開示請求があった場合には、その手間をかけているのだから、行政機関にとってはその延長といえるかもしれない。

このように整理すると、「容易に」の有無の違い、匿名加工情報の範囲、情報公開制度との関係、いずれも違和感なく整理できると思う。まとめると以下となる。

  • 行政機関の匿名加工情報は、加工方法における個人識別性排除のための照合識別要件は、民間部門と同じである。
  • 民間部門との違いは、保有個人情報の目的外提供とならないためのチェック工程が追加的に必要となることにある。
  • このチェック工程で想定すべき照合先は、「図書館等の公共施設で一般に入手可能なものなど一般人が通常入手し得る情報」であって、行政機関内の元データではない。(元データとの処理情報的照合性は匿名加工で既に排除されているから。)
行政機関法では匿名加工情報が個人情報に当たるですって?, 2016年3月6日の日記

この考え方を採用するには、「散在情報的照合性 vs 処理情報的照合性 説」を採用するのが前提である。現時点では、まだ私の独自の見解にすぎないので、これを前提にするわけにはいかないのは理解できる。

そこで、次善の策として次のように考えることもできる。

まず、前々回の「まとめると以下」の、最初の2つの事項はそのまま採用できる。

  • 行政機関の匿名加工情報は、加工方法における個人識別性排除のための照合識別要件は、民間部門と同じである。
  • 民間部門との違いは、保有個人情報の目的外提供とならないためのチェック工程が追加的に必要となることにある。

1つ目の事項は、要するに前掲の(A)を選ぶということである。法案の条文について言えば、委員会規則に委任するのをやめて、はっきりと「容易に照合することができそれにより識別」の意味で「識別できないようにしたもの」の意味である旨の括弧書きに修正すればよい。それが今からでは困難であるならば、いっそのことこの2つ目の括弧書きを削除してしまい、政府解釈で示すことにするという方法もあるだろう。

2つ目の事項は、作成された「行政機関匿名加工情報ファイル」(法案では「行政機関非識別加工ファイル」だが)を提供する前の段階で、ファイルの各要素について、保有個人情報に該当するものとなっていないか、人力で検査することである。

このようなチェック工程は、行政機関に対してならば無理な注文でもなかろう。情報公開制度を運用するのと似た作業である。

実は、これに類する作業を要求する規定が、今回の改正法案には規定されている。それは、2条9項の「行政機関匿名加工情報」(法案では「行政機関非識別加工情報」だが)の定義中にある、以下の強調部分である。

9 この法律において「行政機関非識別加工情報」とは、次の各号のいずれにも該当する個人情報ファイルを構成する保有個人情報(他の情報と照合することができ、それにより特定の個人を識別することができることとなるもの(他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを除く。)を除く。以下この項において同じ。)の全部又は一部(これらの一部に行政機関情報公開法第5条に規定する不開示情報(同条第1号に掲げる情報を除く。以下この項において同じ。)が含まれているときは、当該不開示情報に該当する部分を除く。)を加工して得られる非識別加工情報をいう。

匿名加工情報を作成する前に、ソースとする個人情報ファイルについて、その各要素について検討して、情報公開法の不開示情報(個人に関する情報以外の、法人情報や、国家安全、公共安全に係る情報等)に該当する部分を除去しなければならないとしている。

この作業が運用可能であるのなら、匿名加工された後の「行政機関非識別加工情報ファイル」に対して、個人情報に該当するものが残っていたら除去するという作業も、運用可能と考えられる。

次に、前掲3つ目の事項は、「チェック工程で想定すべき照合先は、行政機関内の元データではない。」としているが、これは「散在情報的照合性 vs 処理情報的照合性 説」を前提としているので、そのまま採用するわけにはいかないが、いっそのこと、チェック工程で元データとの照合できるかを確認してもよい。

ただ、実際にやってみると判明するのではないかと考えているのは、チェック工程で元データと照合できるかを確認してみると、いずれも照合できないという結果になるはずだ。なぜなら、民間部門の匿名加工情報の加工基準は、元データとの照合ができないように加工するものとなるはずだからである。ここで、前者の「照合できるか」は「容易に」なし基準であり、後者の「照合できないように」は「容易に」あり基準であるという違いがあるものの、元データとの照合という場面に限ると、両者による違いはなく、元データと照合できないということを実感できるはずだと考えている。

以上のことから、まとめると次のように言える。

  1. 民間部門の匿名加工基準で匿名加工して作成する「匿名加工情報ファイル」は、その一部の要素に行政機関法における「保有個人情報」に該当するものが残存する可能性は否定できないが、当該ファイルを提供する前に、該当する要素を取り除けばよいのであり、問題はない。
  2. 「保有個人情報」が残存する可能性があるものを「匿名加工情報」と呼ぶことに難があるのかもしれないが、名称を変えてしまうと、行政機関法と民間部門とで概念同一性が怪しくなり、受領者の再識別禁止規定の適用が怪しくなるから、名称は「匿名加工情報」という同じ名前とするのがよい。
    • もしくは、名前が同一であればよいので、改正個人情報保護法を未施行のうちに再改正して、民間部門の方の「匿名加工情報」を「非識別加工情報」に名称変更して統一するという案も考えられる。*12
  3. 「匿名加工情報」の定義は、民間部門のそれとの概念同一性を明確にするために、2番目の括弧書きを削除するか、又は、前記(A)に沿うよう修正して委員会規則への委任を削除するのがよい。
    • 後者を選択するなら、改正個人情報保護法を未施行のうちに再改正して、民間部門の方の定義でも「特定の個人を識別することができない」の部分を明確化する括弧書きを(A)の形で加えて、定義条文の一致を図る*13ことも考えられる。

残る瑣末な論点

このような匿名加工情報の定義の論点について、書き足りていないことが2つある。

  • 行政機関が保有する個人情報ファイルには、その各要素に、属性情報として他の個人についての個人情報が記載されているもの(これを「処理情報中のローカル散在情報」と私は呼んでいる。*14)が存在し、民間部門の匿名加工基準での匿名加工では、それが匿名化されない可能性がある。これが行政機関法では、散在情報としての保有個人情報に該当することになり、行政機関匿名加工情報ファイルに残存する可能性がある。しかし、前記の通り、提供前のチェック工程で保有個人情報の除去をすることで対処できる。
  • 研究会報告書が「行政機関が作成する匿名加工情報は、行政機関法の個人情報に当たる」とした理由に、「加工に用いた個人情報自体などとの照合により特定の個人を識別することができることから」とした背景には、民間部門では、36条5項で、自ら元データと照合することを禁じる規定を置いていることから、「照合が法的に禁止されることによって元データとの容易照合性が消滅する」とする理屈によって、「k=1の匿名化」であっても「匿名加工情報」に該当するものとすることができるとの考え方が一部にあるようであり、同じ理屈を行政機関法に適用できるかというときに、36条5項相当の禁止規定が行政機関法には改正案で導入されないから、その理屈は適用できず、その結果として、元データと照合が常にできてしまう(常にではないが)とする考え方が潜んでいるのかもしれない。これは、そもそも「照合が法的に禁止されることによって元データとの容易照合性が消滅する」とする考え方が法解釈として誤りと言うべき*15なので、採用する必要のない考え方である。

これらについては、いずれ時間のあるときに書こうと思う。

*1 行政機関等の保有する個人情報の適正かつ効果的な活用による新たな産業の創出並びに活力ある経済社会及び豊かな国民生活の実現に資するための関係法律の整備に関する法律案

*2 その理由は、「匿名加工情報は何でないか」の前編中編前編の2で途中まで書いた。後編ではっきり書く予定であるが、民間部門において匿名加工情報は、個人情報に当たらないもののみが匿名加工情報たり得るのであるから、元から提供が規制されていない情報の提供ができるにすぎないものであるし、規制強化というわけでもないので、匿名加工情報の制度を使う意思がなければ義務に従わなくてよいというものである。民間部門で唯一の意義として考えられるのは、グレーゾーンが怖くて非個人情報に加工しても提供できないという事業者にとって、大手を振って匿名加工情報に加工して提供できるという点である。

*3 昨年10月20日の日記「行政機関等パーソナルデータ制度改正に対するパブコメ提出意見」では、ここまでやる気はないだろうと思っていたので、「意見1 行政機関及び独立行政法人等の保有するパーソナルデータについては、民間部門と同等の「匿名加工情報」の制度を設けずとも同等の利活用は可能であり、「匿名加工情報」の制度を設ける必要性がない。」としていた。

*4 国会提出法案では、なぜか「匿名加工情報」が「非識別加工情報」という名称になっているが、そこはスルーして、ここでは「匿名加工情報」で通している。

*5 1月31日の日記「匿名加工情報は何でないか・中編」では、「定義は「特定の個人を識別することができないように個人情報を加工して得られる」を要件とするが、ここで言う「特定の個人を識別」が、照合による識別を含むのかがはっきりしない。改正前2条1項括弧書きに相当する文がないが、当然に含むとして省略されているだけなのか、意図して照合による識別を除いたものなのかが不明である。」としつつ、後に「(すなわち、改正前2条1項括弧書き相当の記述が改正後2条9項にないのは、省略であって、照合による識別を除く趣旨ではない。)ということになるように思える。」と書いていた。

*6 参考:「法制執務コラム 委任立法―国民の目に見える立法を―」, 参議院法制局

*7 3月6日の日記の「照合による識別の容易性要件を巡る混迷」参照。

*8 1月31日の日記の「法律ではどう規定されたのか」参照。

*9 民間部門の匿名加工情報で「23条1項の規定にかかわらず、当該匿名加工情報を第三者に提供することができる。」との規定を置かなかった(12月6日の日記の「匿名加工情報は「個人データであっても第三者提供を許す」の形ではなかった」参照。)のと同様に、今改正案でも、「8条1項の規定にかかわらず、当該匿名加工情報を提供することができる。」との規定は置かれていないので、匿名加工情報(非識別加工情報)が個人情報である限りは、本人同意なく提供することはできないこととなってしまう。

*10 この道を選択する場合、この委員会規則には何を規定するつもりなのだろうか。元データを除外に含めないようにするとなると、残るは、当該行政機関の外にある情報(例えば図書館にある情報)であり、これを「他の情報」から除くということが考えられるが、しかし、この委員会規則への委任規定では、対象範囲を「当該個人に関する情報の全部又は一部を含む個人情報その他の」としているので、当該個人に関する情報とは関係のない図書館にある情報を含めることはできないはずであり、いったい何を規定するつもりなのか解せない。委員会規則で定めるとしながら、規則では空集合を規定するというのもアリなんだろうか。

*11 もっとも、民間部門においても、「識別できないようにした」の「識別」を、「容易に」なしに「照合することができそれにより識別」という意味で解釈するものとする道も残ってはいる。なぜなら、「個人情報」が「容易に」入りの照合性で定義されているからといって、「匿名加工情報」の定義で「容易に」なしの照合性で識別性を排除することを妨げるものではないからだ。ただ、こちらの道を選択した場合は、私の独自説では、匿名加工情報の作成基準が「散在情報的照合性」(3月6日の日記の「散在情報的照合性 vs 処理情報的照合性 説」参照。)によって「照合による識別」を排除する必要が出てくることになるから、データの1個1個について個別に「他の情報と照合」できるかを見極めなくてはならなくなり、民間部門にとっては酷なルールとなるので、私はこの方向性には賛成しない。

*12 これが可能なら、むしろ「非識別加工情報」の方が適切なネーミングであるように思えてきた。民間部門においても「匿名加工情報」という用語はあまり適切ではなかった。昨年の改正法案の国会提出から1年が経ち、すっかり「匿名加工情報」の語に馴染んでしまったが、最初に目にしたときの違和感を思い出す。「匿名加工情報」という呼び名だと、仮名化をしただけのものを指すように聞こえかねない。医療分野で用いられてきた「連結可能匿名化」や「連結不可能匿名化」と同様にだ。元データと照合できないように加工することが匿名加工情報の要件であるなら、k≧2のグルーピングをすることとなり、それは、技術検討WGが一昨年整理した「識別/非識別, 特定/非特定」情報の概念からすれば、「非識別情報」に加工することを意味するのであるから、初めから「非識別加工情報」とするのが正しかったとも言える。

*13 「(……もの(……ものを除く。)を除く。)」の部分だけは異なることになるが。

*14 これについては、「散在情報と処理情報(パーソナルデータ保護法制の行方 その3)」で書く予定。

*15 これについては、「匿名加工情報は何でないか・後編」で書く予定。(前々回の脚註5の件)

本日のリンク元 TrackBack(0)

最新 追記

最近のタイトル

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|
最新 追記