マイナンバー制度を「アーキテクト」目線から考える（６）
最高裁の判決とデータマッチング・リスク
住基ネットが住民票を取得するくらいしか使い道のない住民票コードとセットで開発され、運用が開始されて後、課題であった情報の紐づけをどこまでやってよいのかという問題に関する判断を示す重要な裁判がありました。住基ネットをめぐっては全国各地で多数の訴訟が提起されていますが、ここで取り上げるのは、平成19年3月6日 最高裁判所第一小法廷で出された判決です。この訴えは、要するに住民が自分のエントリを住基ネットから削除することを求めたものですが、最高裁まで争って結果敗訴しています。この裁判の意味については様々な解釈、意見がありうると思いますが、公的機関の行政権に一定の裁量を与えつつ個人情報の利用に際して歯止めをかけた内容になっていて、後のマイナンバー制度の構想に大きく影響を与えたと言ってよいと思います（※6）。行政機関として何をすべきかを明確にしたものと言えるかもしれません。判決文は、それほど長いものでもないので、まだ読んだことが無い方は一度目を通しておかれるといいかもしれません。
（※6）この判決について詳しく知りたい方は、ITや知財関係に詳しい弁護士であり弁理士の北岡弘章さんの解説「住基ネット最高裁判決 全3回」が日経XTECHで読めるのでそちらを参照してください。（ https://xtech.nikkei.com/it/article/COLUMN/20080326/297174/ ）書籍もいろいろ出ていると思います。なお、最高裁の判決文はこちらで全文読めます https://www.courts.go.jp/app/files/hanrei_jp/933/035933_hanrei.pdf
判決の骨子を思い切りかみくだいてまとめれば、
住民の四情報に住民票コードを付した統合データベースを構築、運用すること自体は適法
その判断の根拠は、データマッチング・リスク（※7）が認められないこと
ということになると思います。
この最高裁の判決においては、住基ネットが扱う情報は、いわば本人を指し示す表札のようなものに過ぎないという観点から行政手続き上必要な範囲に限定して住基ネットが活用されることについては適正であるとされたわけです。現在では、まずこれは個人情報ではないのかという指摘があるかもしれません。しかし、住基ネットの個人に振られているIDである住民票コードは他のシステムではほぼ使えませんから、四情報を使ってその都度データマッチングをせざるをえません。個人情報だとしても、四情報の範囲なら、それを使わないと必要な事務処理もできない以上、データベース化することを違法と言っても始まらないでしょう。しかも、住基ネットはその利用を厳しく制限されています。この二～三〇年でプライバシーに関する議論はだいぶ進みました。この判決で四情報を個人情報ではないかのように扱ったことと個人情報保護法の考え方の相違は世の中のプライバシーに関する進化を示すものととらえておけばよいのではないでしょうか。
そんなことよりも重要なのは、二番目のデータマッチング・リスクです。住基ネットや個人番号法に関する重要なステークホルダーである総務省（※8）としては、この判決はマイナンバー制度で乗り越えるべき基準を示したものとなったはずです。この判決の論旨に依存するならば、もし住民票コードによって税や社会保障やその他の個人情報全体が紐づけられてデータの統合が行われる状況が生じていたら、最高裁の判断は変わっていた可能性があるわけです。税のシステムも社会保障のシステムも住基ネットと直接結合していないのには、こうした背景があるのです。ユニークIDの元に個人情報が集約されて個人情報が第三者に容易に把握される危険性、特にそれが国家権力に独占される問題はしばしばジョージ・オーウェルの『1984』にちなんで "Big Brother" を生み出すリスクとして言及されます。住基ネットにはそうした危険性はないことが合憲判断の根拠になったとみなすことができます。それゆえに、新しい番号制度の導入に際してこうした紐づけリスクが明らかになれば個人番号制度はまた日の目をみないことになりかねないと制度設計を担当した当局では考えたはずです（※9）。そこから生まれてきたのが、情報を管理する各官公庁の権限は従来の制度のとおり一切変更させず、他の官公庁で管理する情報が必要な事務がある場合は、住民に書類をもってきてもらう代わりに住民の許可を得たうえで情報連携ネットワークを経由して取り寄せて使用するという、徹底した分散管理方式です。これをバックオフィス連携と呼んでいます。
（※7）データマッチングのリスクとは、わかりやすく言えば、ユニークIDをもとに各府省が管理する情報を集約することで、特定の個人についてのあらゆることがわかってしまう可能性があるということです。税、年金、雇用、保険、学歴、逮捕歴、治療履歴、等々に加え民間企業がもつたとえば銀行口座やクレジットカードの利用履歴などまで合わせるとその人に関わる情報が相当程度立体化してくるはずです。たとえば、雇用保険の履歴と学歴が入手できれば他人の履歴書を偽造するのは本人を知らない第三者であっても容易に行えてしまいます。
（※8）マイナンバー制度に関する法制度の所管は、デジタル庁（内閣府から移管）、総務省で分担されています。
（※9）ついでに言えば、自己情報コントロール権の問題については高裁判決では言及されたものの最高裁の判断からは論評抜きで排除されています。その後のマイナンバー制度の設計の中では、自己情報の請求、訂正ができることに加え、情報連携の際に住民自ら許可ができるようになっています。マイナポータルで手続きをする際、情報連携の都度マイナンバーカードで承認が必要なのはそのためです。
「符号」を用いた情報連携方式
マイナンバー制度の検討が本格的に始まる前の段階で、バックオフィス連携の必要性については、ほぼ政府内でコンセンサスができあがっていました（※10）。具体的な情報連携の方式については、先行する欧州での実現例なども参照しながら検討されていて、経産省では実証実験も行われていました。問題になったのは国家による一元管理をどのようにして回避するか、すなわち "Big Brother" 対策をどのようにアーキテクチャに取り入れるかという点です。企業内ネットワークのように、統合ディレクトリを設けて、これを各個別システムで共有する形は容易に想像できるわけですが、この方式の場合、統合ディレクトリを中心に機微な個人情報を紐づけた "Big Brother" 管理システムがそのまま成立してしまうことになりかねません。住基ネット導入時に懸念されていたプライバシー・リスクとは、まさにこのことだったわけです。
住民サービスのために紐づけが必須なのだとしても、それは常時結合が必要な事項なのか、それとも必要に応じて紐づけがなされれば十分なのかは別の問題です。制度適用の場面を詳細に分析してみれば仮に必要性が十分に認められる紐づけだったとしても、それが常時どの政府機関からも確認できる状態である必要は無いということはすぐにわかります。また、自己情報のコントロール権を拡大していくなら、その紐づけは、その個人情報の所有者たる住民の要求か許可に基づいて実施すべきではないのか、少なくともオプトアウトについては制度化されるべきではないのか、といった見方も出てきます。日本の政府は、自己情報の制御範囲をいたずらに拡大する代わりに、府省間での連携に際して住民の許可を必要とする形にアーキテクチャを作り変え、これによってデータベースの分散管理を徹底する方向に行政システムを進化させました。
（※10）オンラインに残されている資料も減ってきましたが、たとえば、「次世代電子行政サービス基盤等検討プロジェクトチームにおける検討状況 平成21年2月6日 内閣官房IT担当室」 （ https://www.mhlw.go.jp/shingi/2009/02/dl/s0206-7a.pdf 2023/8/23確認）
マイナンバー制度の検討が始まった時には、既に海外では様々な先進事例や失敗事例が出ていましたから、当然それらの事例研究もおこなわれたはずです。もちろん、単一のディレクトリ構造にした場合のリスクについては十分把握されていたと思います。しかし、数多くある官公庁のシステム間で住民のユニークIDを共有せずにどのようにしたら情報連携することができるのかについてはなかなか良い方法が見つかりませんでした。四情報を用いた突合を必要とするならこれまでと何も変わりません。しかし、もし全システム共通のIDを新しく導入してしまったら、これは住民票コードの名前を変えて統合ディレクトリに強化しただけのことで、Big Brother まっしぐらです。到底、最高裁判決の示した基準はクリアできません。
このような状況の中、「符号」による連携方式が提案されてから検討が一気に進んだとみられます。東北大震災の年、2010年にはこの発想はすでに当時政府から出されていた資料で説明されていたはずです。符号による連携方式は、コードの変換を一か所で行うゲートウェイ方式とアクセス・トークンを使う方式の二方式が検討され、ここでも集中管理リスクのあるゲートウェイ方式を避けてアクセス・トークン方式が選択されたと記憶しています。中間サーバやインターフェース・サーバの導入なども、この方式に基づいて固められていったものです（具体的な方式の内容については、項目を分けて解説します）。このように、マイナンバー制度は、最高裁の判決を受けてデータマッチング・リスクを極限までそぎ落とす分散データ管理の設計思想を中心に形作られていきました。
マイナンバー制度の技術的な基盤となっているのは情報提供ネットワークですが、その基本アーキテクチャは情報保有機関ごとに個人情報を分散管理して統合せず、連携が必要な情報はあらかじめ法的に規定した上で新しく整備する情報連携機能を用いて、官公庁の事務や当人の請求等で必要になったタイミングで取得するというものです。バックオフィス連携を支えるインフラは原則として情報提供ネットワークに一元化されます。情報連携の際に使用するのは個人に割り振られた "ID" ではなく、機関ごとに割り振られたその人を示す「符号」です。符号情報は、住民登録情報に基づいて生成する必要がありますが、各情報保有機関に固有の識別符号と組み合わせて生成され、それぞれの機関に専用の符号が割り当てられます。符号は、いわば各情報保有機関に専用の「共通」IDのようなものです。この個人を示す符号は、情報連携の際に連携先機関固有の符号に変換されて受け渡しされます。ある符号は、その保有機関でしか解読できず、他機関もこの符号をそのまま受け取るわけではなく、自らの機関向けに変換されたその個人を表す符号で受け取る形になるため、この符号の変換アルゴリズムを実装している情報提供ネットワークのコアシステムに接続しない限り、他機関との情報連携はできません（※11）。
したがって、情報提供ネットワーク以外での情報連携を禁じ、可能な情報連携を限定さえしておけばデータマッチングのリスクは最小限に抑止されると言ってよいことになります（※12）。連携してよい情報については、現在は政省令で規定できるよう緩和されましたが、当初は、個人番号法の「別表２」にまとめられていました。つまり、変更には国会での法改正手続きが必要だったわけです。ここに記載のない情報連携を勝手に行うことはできません。たとえば、マイナンバーをキーにしてデータベースを開発したら、官でも民でも刑事罰の対象です。マイナンバーカードについては後で詳しく検討しますが、この情報連携に住民が許可を与えるツールとしても設計されていることも確認しておきたいと思います。
なお、蛇足ですが、マイナンバー制度の導入は、システム・アーキテクチャ設計を制度設計と密接不可分なものとして扱った点や府省のみならず自治体や民間企業にも及ぶ国全体の情報インフラを確立することを目指して府省横断的に検討を行ったという点で画期的なもので、日本の官公庁システムの歴史の中では前代未聞のプロジェクトであったと言えると思います。
（※11）詳しくは政府から出ている資料を参照ください。たとえば、「マイナンバー制度における情報連携について 平成28年5月 総務省個人番号企画室」（ https://www.soumu.go.jp/main_content/000429540.pdf 2023/8/23確認）
（※12）実際には、情報提供ネットワークを使わずに情報保有機関間で従来どおり直接媒体でデータを受け渡ししている場合も相当数あります。データが大量であったり、既存の連携インターフェースを変更する必要性が薄かったりなどの理由から例外として認められているものと言えます。もちろん、これら例外についても法律に明記されています。
プライバシー・アーキテクチャの相違
さて、マイナンバー制度は、このようにデータマッチングを必要最小限に封じ込める強い理念の下で、個人情報の分散管理を大原則として法整備を行い、これに基づいて業務・システムの基本デザインを行って成立したものです。よく言われるように、諸外国の類似の制度と比較しても、この徹底した分散管理アーキテクチャは顕著な特長といってよいのではないでしょうか。
しかし、既に稼働開始していたコンビニ交付サービスは、前述のとおり情報提供ネットワークには参加しておらず、この新しいプライハシー・アーキテクチャのビジョンの元にもなかったことはこの交付ミスのトラブルから明らかです。コンビニ交付サービスは、このような国全体の情報インフラの考え方を変える意思のもとで開発されたはずの情報提供ネットワークやその基本アーキテクチャに適応させることなく、住基ネット時代のシステム構成概念の延長上に構築され、運営されていたわけです。
言ってみれば、プライバシー保護の観点で国の情報連携の仕組みはバージョンアップさせて新しいOSの下で動くようになった一方で、コンビニ交付サービスは古いバージョンのOSのままで残されたようなものです。つまり、マイナンバー制度の登場によって住基ネットが廃止されたわけではなく、それは従来の法律のまま単に住民記録を管理するためのシステムとして維持されるようになったということです。住民基本台帳はマイナンバーとは無関係で、住民基本台帳法に基づいて整備されており、住基ネットがそのための基盤であることには少しも変わりはありません。個人の番号として住基コードとマイナンバーとなぜ2種類運用しなければならないのか疑問に感じたことはないでしょうか。これは過渡期だからではありません。国の計画の中に、住民票コードを廃止するという日程も書かれていません。素朴に考えれば、住民票コードからマイナンバーを生成して、個人番号制度に移ったなら、住民票コードを廃止してマイナンバーのみの運用に移行すればよさそうなものです。しかし、そうはしませんでした。
考えられるとすれば、住民票コードもまた各行政機関で管理する個別の個人ID（基礎年金番号だとか、他のシステムの固有番号を思いうかべてください）とみなして制度を作ったということです。各行政機関で管理する個人IDはマイナンバー制度のもとでも維持されています。基礎年金番号を忘れても、マイナンバーがあれば変換することで探し当てることができるようになっています。しかし、だからといってマイナンバーを使って各機関がデータベースを構築しなおすと言うことは行っていません。個人と紐づけ可能な共通コードを使用する限り、それが住民票コードであれ、マイナンバーであれ同じことで、全システムで使えるようにしてしまえば、分散管理といっても容易にデータを紐づけることが可能な点では最高裁の判決に反することになります。住民票コードについても、他の行政機関と同様に、住民票コードを機関固有の個人IDとして扱うことで、住基ネットがマスター化することを避けたと理解することができます。このことによって、マイナンバーは特定のシステムで管理されない個人を示す特殊な番号となり、情報連携するすべてのシステム内ではマイナンバーの代わりに符号のみが管理されることになります。各機関の窓口でマイナンバーを見せても、それは入口で各機関の固有IDに変換され、しかも他機関との情報連携では符号しか用いられないということです。
思い起こせば、住基ネットは、少なくとも表面上は投資効果が疑われかねない住民票や印鑑証明のリモート取得ができるサービスに留まっていました。もちろんバックオフィスに目を転じれば、多様なユースケースが存在しているのですが、基礎的なデータベースをしっかり構築することの効果というのは、なかなか住民にはわかりにくいものです。その効果を説明する頼みの綱であった住民票の24時間取得サービスも、自治体の外に専用端末を設置するのは負担が重く、結局役所に出かけるのであれば大した意味もなくなってしまうといった事情から、コンビニ交付サービスの拡大が期待されていたことは既に述べた通りです。元々住民票、印鑑登録証等はそれほど頻繁に必要とするものではありませんから住民の側から見ると税金を投入する投資対効果も疑問です。もちろん、役所の側から見たらかなりの事務負担の削減になるのですが、住民側からは理解しにくい効果です（※13）。
（※13）インターネットで入手できる範囲で得られる情報として、横浜市における証明発行数の統計が残っています（「証明発行サービスのあり方の検討結果について」市民・文化観光・消防委員会 平成27年12月10日 市民局： https://www.city.yokohama.lg.jp/shikai/kiroku/katsudo/h27-h28/katsudogaiyo-h27-j-3.files/0119_20180808.pdf 2023/8/30確認）。この資料を見ると、平成8年度で、証明書の発行数は年間600万枚を超えており、職員負担の観点では決して軽くはなかったことがわかります。ただ、それも平成26年では450万枚程度になっており、デジタル化の進展にともなって更に激減していくだろうことは容易に推測できます。
コンビニ交付サービスの導入当時、住基カードが導入された2002年から7年経った時点でも、少なくとも表面的には住基ネット導入の効果はほとんど感じられないままだったといえます。そこで、政府の掲げる情報戦略のひとつの柱として、また、住基ネット導入の効果を宣伝し利用を推進する目玉のサービスとして企画されたのがコンビニ交付サービスだったと思われます。それがサービスを開始したのは、2010年、同じ年に公表された「新たな情報通信技術戦略」（平成22年５月高度情報通信ネットワーク社会推進戦略本部決定）においても「2020年までに国民が、自宅やオフィス等の行政窓口以外の場所において、国民生活に密接に関係する主要な申請手続や証明書入手を、必要に応じ、週7日24時間、ワンストップで行えるようにする。この一環として、2013年までに、コンビニエンスストア、行政機関、郵便局等に設置された行政キオスク端末を通して、国民の50％以上が、サービスを利用することを可能とする」と非常に高い目標が掲げられていたことは既に説明したとおりです。サービスがまだ開始されたばかりの時点で、3年後という期限を切って高いKPIを設定しているわけですから、このタイミングでアーキテクチャ変更などできるはずもありません。一方、キオスク端末は既存のシステムですので、これを活用して自治体サービスを載せれば、証明書取得の専用端末を自治体ごとに導入するのと比較すれば確かに効率的で、自治体の運用負担も少なくて済みます。実際、翌2014年に示されているロードマップにおいても、キオスク端末のサービスを拡大する方向性にいささかも変化はなく、長期のロードマップまでひかれています。
コンビニ交付サービスを従来のまま先行させて普及させる、という判断が行政の判断として間違っていたとは思いません。しかし、マイナンバー制度の構想そのものは、2009-2011年くらいにはほぼ固まっていました。それが、「行政手続における特定の個人を識別するための番号の利用等に関する法律」（個人番号法）として国会で成立したのは2013年ですが、これは東日本大震災の影響で法案の国会承認がいくつかの国会でスキップされたためで、コンビニ交付サービス側からみると、それが稼働し始めた時には住民に対する付番制度（国民背番号制などとも呼ばれます）はすでに新しいプライバシー・アーキテクチャに従ったものに移行する方向性が固まっていて、システムの陳腐化が始まっていたことを意味します。一方で、個人番号法の成立時ですら、コンビニ交付サービスは開始されてまだ3年、サービス拡大途上の新システムだったわけです。法制度面からみても、住基ネットを古い体系のまま残したことで、住基ネット時代の考え方、周辺事業や古いアーキテクチャのシステムも温存されることにはなりました。すなわち、コンビニ交付サービスの法的、制度的な根拠、枠組みは何ら揺らいでおらず、そのまま維持されたままだったということになります。この状況は、現在でも変わっていません。このプライバシー・アーキテクチャの相違を放置したことが、今回の個人情報の取り違えを引き起こした真の原因であると言って言えなくはないのです。
昨年、富士通の役員と思しき人物がこのシステムが開発されたのが2008年であり、当時のエンジニアには責任はないのかといわんばかりのネット投稿をしたのが話題になりましたが、稼働開始時から基本アーキテクチャを変更せずに今に至っていることはここからも推察されます。このシステムは、住基カードによって住民票をコンビニで取得できるサービスの基本骨格を変更せずに、マイナンバーカードでも使えるように改修しただけのものと考えてほぼ差支えありません。細かな技術論はさておき、コンビニ交付サービスの問題は情報提供ネットワークとは無関係であり、本質的には、個人番号法に基づくマイナンバー制度とも無関係な問題でした。一連のコンビニ交付サービスのトラブルは、すべて住民基本台帳ネットワーク時代の様々な制約がある中での設計に由来しています。これは重要なポイントで、コンビニ交付サービスの不具合を理由にマイナンバー制度の脆弱性を論じるのは、技術的側面だけに限って言えば全く不当であると言うことができます。
まとめると、コンビニ交付サービスは、マイナンバー制度以前から存在していた行政サービスの基本構造をそのまま維持して今に至っている古いシステムで、新しいプライバシー保護の考え方に厳格に従って設計された新しいプライバシー・アーキテクチャには対応していなかった、ということになります。コンビニ交付サービスがプライバシーについて無頓着だったかといえば、もちろんそんなことはなくて、通信の保護、一時データの徹底した削除、改ざん防止対策、取り忘れ防止対策など出力される帳票をめぐるプライバシー保護については様々な検討がなされて実装もされています。しかし、システム・アーキテクチャ面では、古い行政システムの主たる設計目標である職員の事務の効率化という観点から設計されたという以上のものではありませんでした。コンビニ交付サービスは、住民票の自由な閲覧さえ可能だった時代に企画・設計されたものとして、特に行政側の情報アクセスに関する取り扱いには大きな自由度が与えられていたふしがあり、それが今回の問題を引き起こした根底に潜む根本的な問題だとみなすことができるのです。果たして最高裁判決が言うように、住基ネットにプライバシー上のリスクは無いと言いえたのかどうか、今回のようなトラブルはよくあるプログラミングバグであって、偶然にすぎないと言えるのかどうか。実は、システム内のプロセスに対して無制限なアクセス許可を与えていたと推察できることは既に述べた通りです。自治体職員にも住民にも無い権限がシステムに与えられていたということになります。これは、問題ではないのでしょうか。多分、問題なのです。しかも、この問題は、マイナンバー制度の基本アーキテクチャでは乗り越えられていたわけですから。