第５回

情報連携基盤技術ワーキンググループ
議事要旨

日時：平成２３年６月７日（火）１４：００～１６：００
場所：三田共用会議所

３Ｆ大会議室

出席者：佐々木良一委員（座長）、大山永昭委員（座長代理）、新井悠委員（代理）、小松文子委員、坂本泰久委員、神成淳司委員、手塚悟委員、戸田夏生委員、松本泰委員、山口英委員、池田大造委員、崎村夏彦委員、實川昌幸委員、鈴木尊己委員、中上昇一委員（代理）、長島哲也委員、坂東和彦委員、宮坂肇委員（代理）、吉丸邦昭委員、吉本明平委員（議事次第）
１．開会
２．議事（１）個人情報保護ＷＧの検討状況について（２）社会保障分野サブＷＧの検討状況について（３）情報連携基盤の構築に当たっての論点整理について（４）社会保障・税番号要綱について（５）委員提出資料について（配付資料）
資料１：社会保障・税番号制度における個人情報保護方策について大綱に盛り込むべき事項（案）

資料２：社会保障分野における検討状況

資料３－１：情報連携基盤の構築に当たっての論点整理
資料３－２：番号連携方式検討表
資料３－３：データ送受信方式検討表
資料４－１：社会保障・税番号要綱（概要）
資料４－２：社会保障・税番号要綱
資料５－１：「番号」制度導入に伴って発生するＩＴリスクに関するフォルトツリー分析（佐々木座長提出資料）
資料５－２：情報連携の概念整理について（大山座長代理提出資料）
資料５－３：番号連携方式検討表・データ送受信方式検討表へのコメント（小松委員提出資料）
資料５－４：情報連携基盤の論点に関する意見書（手塚委員提出資料）

1

資料５－５：情報連携基盤の検討において議論されるべき事項について（松本委員提出資料）
資料５－６：共通番号制度・国民ＩＤ制度：今後に望む検討事項（意見書）（崎村委員提出資料）
資料５－７：リンクコード変換処理性能について（鈴木委員提出資料）
資料５－８：番号連携に関するご参考資料（中上委員提出資料）
資料５－９：「番号」導入による引越し手続きのリデザイン（飯島委員提出資料）

2

（会議概要）議事事務局より、配付資料１、配付資料２を説明。
○

今後の社会保障分野サブＷＧの検討スケジュールはどのように考えているか。

○

今月にも大綱が纏められるので、大綱に向けて必要なユースケースの作業を進めて事務的に調整をしていきたい。それに向けて、作業班が検討している。

○

資料に「番号」がまだ出てきていないが。

○

見える「番号」を用いて直接やり取りしてよい情報と、情報連携すべきことのふるい分けをしている段階である。

○

機微性の判断は様々な考え方があると思う。単独での交換であれば単なる数値でも、情報を組み合わせた場合の機微性の評価はどうしているのか。もう一つ、安全サイドに倒して考えて、何でも機微だと言ってしまうと、すべての情報を隠してしまえ、となってしまう。情報連携を行わない、閉じたシステムにしよう、という結論になると思うが、現在の議論はどうなっているのか。

○

明確な答えがサブＷＧで出ているわけではないが、ある情報とある情報が組み合わさった場合に格段に機微性が上がる等の議論は出ている。法制度として機微性を評価することの限界から、個人情報保護法がそのような体系になっていないという前提で、どのような仕組み、制度を作っていくか、議論をしているところである。

○

検討の軸を定めて、それをまず議論してから個別ケースを見ていかないと、政府に整合性がないということで国民が不安に思う。検討の仕方を構造化しないと、時間と説得力の浪費になるのではないか。

○

ユースケースを見ていく中で、ＢＰＲ的な視点から、番号制度を導入することでステップが変わるのか、それとも単に「番号」が付いてやりやすくなっているのか、どのように感じているか。

○

時間的な制約もあるので、どこまで手続きの内容面あるいは根本的に見直していくのかは、個別に対応するものと考えている。ただし、省令や法律で決まっているものは、規定を変えていく前提で作業している。
事務局より、配付資料３－１、配付資料３－２、配付資料３－３、配布資料４－２を3説明。
佐々木座長より提出意見を説明。
○

番号制度導入に伴って発生するＩＴリスクに対して、現在検討されている対策が安全なものになっているか、バランスのよいものになっているかを明確にするため、可能な限り定量的分析が不可欠である。政府職員による不正情報マッチング、外部の不正者による複合個人情報の盗み出し、「番号」を利用した民間にある個人情報のデータベースの３点についてフォルトツリー分析を行った。分析結果から、次のように言えるのではないか。
政府職員に関する情報マッチングで情報連携基盤における不正情報マッチングの確率は十分小さく、安全上は問題ないであろう。ＩＤコードとリンクコードの変換においてテーブル方式をとるか、暗号方式をとるか、いずれも安全上はそれほど差がない。また、ゲートウェイ方式、アクセストークン方式はいずれも安全上あまり問題がないので、使い勝手やコストを考えて決めていけばよいのではないか。
情報保有機関における不正情報マッチングは、情報連携基盤におけるものよりも大きく、単独犯が自分の組織の情報と、他の組織の情報の両方を入手して不正マッチングする場合の確率が大きい。
マイ・ポータルや番号付番機関、ＩＤコード付番機関における不正情報マッチングの確率は低い。また、外部不正者による複合の個人情報の入手も運用により発生確率を十分小さくできると考えている。
民間企業が「番号」をＤＢ化する可能性は残る。刑事罰や番号変更による抑止効果のほかに、教育を行うことが重要である。
今後、フォルトツリー分析の結果の見直しを行うとともに、新たな対策が必要な部分については、対策の提案と詳細化を行っていきたい。
大山座長代理より提出意見を説明。

○

情報連携について、概念を整理した。情報連携とは、データベースを有する情報保有機関が他の情報保有機関が有するデータベースのうち、特定の情報を必要とする際に、本人を一意に特定して新たに情報を取得することである。情報収集は、情報保有機関が自らのデータベースを構築するために、情報保有機関固有の権限を行使して、個人または法人から新たに情報を取得することである。
このような情報連携をする場合は法定手続きであり、何らかのイベントが発生していないにも関わらず、情報連携をする例があるのかがはっきりすれば、ワンストップサービスの一環だという整理になると思われる。イベント発生に基づく認められた手続きだ
けが情報連携基盤にアクセスできるようにし、その他の連携は一切行われないことを担保することではないかと思う。
マイ・ポータルについては、本人による情報の入出力が行われるので情報保有機関の一つと考えるべきではないかと思う。
4小松委員より提出意見を説明。
○

資料３－２と３－３についてのコメントである。一つ目は、比較の評価軸を追加してはいかがか。技術と制度との関連を期待するとバランスがわかるのではないか。
資料３－２は故障や災害等の障害時の対応においても追加するのが良いのではないか。
資料３－３では監査証跡の対応を追記した方が良い、案１と案２それぞれの解析のしやすさという考え方が重要である。
社会保障分野において、情報連携基盤と類似の二重の連携基盤が構築されるということは無駄ではないか。社会保障分野での「番号」の取り扱いを明らかにした方がいい。
手塚委員より提出意見を説明。
○

情報保有機関についてしっかりと議論をしていく必要がある。代表的なものとして、国レベルでは社会保障に関わる日本年金機構、税に関わる国税庁があり、地方自治体関係では、１，８００もの市町村があり、これらをいかに調和の取れた形で連携させていくかというのが一番難しいと思う。そういった視点から情報の種別や情報量を具体的に挙げてみていく必要がある。ＩＤコードとリンクコードの変換については、セキュア管理的な視点と変換処理性能の視点から意見を述べる。テーブル方式も暗号変換方式もど
ちらもセキュリティ設計をしっかり考える必要がある。暗号変換処理はＨＳＭを使うことによって十分性能が期待される。テーブル方式でも必要なところは暗号化する必要あり暗号化方式とあまり変わらない部分があるのではないか。
情報保有機関間の情報連携については、「番号」を将来どういうふうに活用していくかという視点で更に検討していく必要がある。本人同意については、オプトアウトでまずはしっかりやっていく。将来、官民連携も視野に入れると、オプトインの考え方もどこかの時点で検討する必要がある。
松本委員より提出意見を説明。

○

情報連携基盤に関する基本的な要件が非常にわかりづらい。これを解消するためには、ユースケースを早く提示すること、ユースケース等に基づき情報連携の原則がもう一度根本から議論されることが必要である。これまでの情報連携基盤技術ＷＧでの骨格案に基づく議論は、情報保有機関でリンクコードと「番号」の紐付きが完全になされることを前提にした議論がなされているが、情報保有機関側の紐付けのコスト負担等も考慮した上で、リンクコードと「番号」の紐付けがきちんとできるかといった議論が必要である。情報連携基盤の基本的な機能として、代理や扶養関係等が識別子間の関係として曖昧性なく証明でき、自動処理できることが最終的な目標であるべきではないか。これは基本設計時にも十分考慮される必要がある。オプトインによる利用者同意も近い将来、基盤として考慮しなければいけない。プライバシー保護の観点から言えばオプトインは情報連携基盤に実装されるべきだが、現状の骨格案は、プライバシー保護のことを考えているがゆえに、オプトインの実装が難しいと言うような矛盾があるように見えてしま5

うところがある。
崎村委員より提出意見を説明。
○

コンセンサスが取れるような基本哲学、グランドデザインを書く上でのポリシーレベ
ルの要件の検討をやらなければならない。国民や民間企業等のステークホルダーが理解しやすいメリット提供が必要である。情報連携の範囲はどこかというセクターの考え方の検討、ＯＥＣＤやＩＣＡＯ、ＩＳＯを参照した制度的・技術的相互運用性等の検討、ＩＣカードのロジスティックの検討、ガバナンスのあり方の検討、認定のやり方の検討が必要である。
鈴木委員より提出意見を説明。

○

リンクコードの変換処理性能のシミュレーションを行い、性能についてはそれほど問題にはならないという試算結果となった。
中上委員（代理）より提出意見を説明。

○

主に情報交換の際の番号変換に着目して、リンクコードの生成・変換と、そのリンクコード自体のリスクと影響の範囲、その変更処理の例をまとめ、参考として、リンクコード変換の性能についての検討結果を整理した。暗号方式とテーブル方式ではともに暗号化、復号化を片道2回行っており、テーブル方式の方が若干性能的には不利ではないかと思うが、その他はあまり大きな差はないのではないか。
事務局より飯島委員の提出意見を説明。

○

引越し手続きについて、将来的に望ましいと考えられる姿をイメージして検討を行った。３人家族で子どもがおり、全員引越しするという場合の流れを示しており、業務改革対象として手続に必要な情報を自治体間、また組織で共有できて、総合窓口で一括して申請ができる、転入先で転出元の台帳を引き継げるということを目指すというものである。

各委員から、以下のような発言がなされた。
○

資料３－２の５つの番号連携方式案のリスクについて考えた。前提として、目的外のマッチングを未然に防ぐことが情報連携基盤の役割と考えている。案１、４、５の共通の符号を使った連携は、二者の結託ではなく、一者の不正によるリスクや、外部への漏洩に加え内部の結託リスクも高くなるであろう。もうひとつ、情報保有機関の立場からの評価が不足している。共通の符号を与えられたということは、「番号」並の保護対策が情報保有機関に求められる側面もある。原則としては、異なるコードを設計し、業務ケースや情報保有機関の状況に応じて運用していくことが合理的ではないか。
案５については、ＩＤコードは出てこないが、紐付けのための内部コードが情報連携
6

基盤に必要である。ＩＤコード相当のコードを使うことになり、共通符号を使うこと以外は、事実上、案３と同等の構造になるのではないか。
○

大山座長代理の概念整理が、大変見通しがよい。設計をしていくときの原則をいくつか立てて合意していくことが良いのではないか。資料５－２

６）の情報連携基盤の利用を義務付けることについて、同時に枠外移送の原則禁止を入れることが必要である。
ログに関しては、生のログを実時間で提供することを原則とし、サマリはポータルのひとつのオプションとしていただきたい。欧州の電子政府システムでは、実時間による利用者に対するログの提供は非常に重要な要件として考えられている。番号の桁数については、構造化による全体の整合性の取り方を考えるべきである。松本委員のオプトイン、オプトアウトの設計については、情報連携基盤はなるべく連携部分に集約し、コンパクトにつくり、監査するための第三者機関側の道具としての位置づけを明確にすることが必要である。
○

リアルタイムログは、情報保有機関も情報連携基盤も持つべきである。

○

情報連携基盤を含めるとすると、情報を提供する側、情報を受ける側の３者でログを持つことになるのか。

○

そのとおりである。ただし、情報連携基盤は、情報保有機関という位置づけではなく、情報を監査する第三者機関側の手段提供をする機関と整理してはどうかと一貫して主張している。

○

いろいろなところでログを持つと、その分のリスクが高まるため、リスク面からの検討も必要である。

○

扶養関係の情報をどこかが持つこととすると、一番怖いのは、今の制度の明確な解釈がないことである。例えば、年金の扶養の話では、年収が１３０万円を越える場合、いつから被扶養を外れるのか。もしリアルタイムに情報が集まるとなると、月次か、年次か。年次でない場合、翌年の１月１日は被扶養に戻ることになり、たぶん実装できないだろう。

○

年金も医療保険も、確定申告で被扶養関係を国税庁に申告しても、健康保険組合に反映されるとは限らない。しっかりとシステムを動かそうとすると、整理しておくことが制度上、非常に重要である。どこがいつの時点でどう判断するのか、が必要である。個人の関係で言えば、個人の属性情報のアップデートを誰が行い、どの属性情報を判断する場合にどのアプリケーションを使うのか、明確にする必要がある。

7

○

世帯や扶養について補足すると、それぞれの制度で年収の基準額等条件が異なり、一義的に被扶養の関係をつくることは不可能である。それぞれの制度毎に考えざるをえない。

○

技術的な事項については、論点が多くあり、なかなか決めきれないが、開発あるいは設計開発の段階で決めていくべきものも多く、あまり心配する必要はないのではないか。
しかし、利用者側あるいは情報保有機関側から考えると、１，８００の市町村側にこのシステムは非常に開発や運用の負担がかかるので、運用の制度について基本的なところを押さえておく必要がある。特に、市町村では大量の個人情報を持っており、情報連携基盤を介した情報のやりとりは、国と地方あるいは市町村間が圧倒的に多いであろう。
したがって、システムをつくっていく上で、市町村の理解、協力が必要である。地方団体との連携を重視して欲しい。きめ細かく市町村と調整し、スムーズにシステムが動くようにして欲しい。

○

次回ＷＧの日程は今月下旬を予定している。決定次第連絡する。
以上

8