第8回

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

日時：平成２４年３月２３日（金）１３：００～１５：００
場所：中央合同庁舎４号館
出席者：佐々木 良一

1208特別会議室

東京電機大学 未来科学部情報メディア学科 教授

大山 永昭

東京工業大学 像情報工学研究所 教授

小松 文子（独）情報処理推進機構
情報セキュリティ分析ラボラトリー長

手塚 悟

東京工科大学 コンピュータサイエンス学部 教授

戸田 夏生（財）地方自治情報センター

峰崎 直樹

内閣官房参与中村 秀一

内閣官房社会保障改革担当室長

向井 治紀

内閣官房内閣審議官

奈良 俊哉

内閣官房副長官補室参事官

阿部 知明

内閣官房社会保障改革担当室参事官

古橋 浩史

内閣官房社会保障改革担当室参事官

井上 知義

内閣官房情報通信技術担当室参事官

瓜生 和久

内閣官房社会保障改革担当室企画官

中村 裕一郎

内閣官房社会保障改革担当室企画官

神成 淳司

内閣官房番号制度推進管理補佐官

楠 正憲

内閣官房番号制度推進管理補佐官

髙原 剛

総務省自治行政局住民制度課長

西村 淳

厚生労働省情報連携基盤推進官

須田 俊孝

厚生労働省情報連携基盤推進室長

三村 和也

衆議院議員

理事長

（瓜生企画官）
それでは、定刻になりましたので、ただいまから「情報連携基盤技術 WG」の第８回会
合を開催させていただきます。
まず、お手元に配付させていただいております資料の確認につきましては、お時間の都
合上、割愛させていただきます。
1

なお、本ワーキングにつきましては、公開として実施させていただきます。
まず、開催に先立ちまして、峰崎内閣官房参与よりごあいさついただければと思います
ので、よろしくお願いします。

（峰崎内閣官房参与）
御紹介いただきました、峰崎でございます。佐々木座長ほか、久しぶりにお会いするよ
うな気がしますが、一言ごあいさつ申し上げさせていただきます。
本日、年度末ということで、お忙しい中、本当にありがとうございました。
実は、まだお見えになっておられませんが、民主党の、このシステムの調達小委員会の委員長の三村和也衆議院議員が、本来は、最初からおられる予定だったのですけれども、本会議の都合で、後ほど御参加されます。是非、よろしくお願いしたいと思います。
２月 14 日に皆さん御存じのように、マイナンバー法を法案として閣議決定して、国会に提出をさせていただきました。皆さん方に本当に御支援をいただいて、無事、法案までたどり着くことができたということでございます。
言うまでもなく番号制度というのは、国民の利便性の向上あるいは公平、公正な社会をつくっていくために不可欠なものだということで、国及び地方公共団体が力を合わせて、各機関が持っている情報について IT 化を通じて、効率的かつ安全に情報提供できるように、そういう仕組みが非常に重要だと考えているわけでございます。
このような情報提供の仕組みにつきまして、今後、内閣官房において調達手続を行い、システム開発を進めていくことになりますけれども、引き続き、委員の皆様方の御指導が不可欠と考えておりますので、活発な御議論をいただいて、よろしくお願いしたいと思います。
大変簡単ではございますけれども、私のごあいさつにさせていただきたいと思います。
なお、恐縮でございますが、この後、少しして、どうしても途中に退席しなければいけないことをお許しいただきたいと思います。
どうぞ、よろしくお願いします。

（瓜生企画官）
峰崎参与、どうもありがとうございました。今、参与のごあいさつの中にもございまし
たが、本日、民主党の社会保障・税番号検討ワーキングチームのシステム調達小委員会の委員長をされておられます、衆議院議員の三村和也先生がお越しいただく予定となっておりますが、14 時過ぎにいらっしゃるとの御連絡をいただいております。
引き続きまして、昨年 12 月に当室に御就任されました番号制度推進管理補佐官のお二人を御紹介させていただきます。
まず、神成淳司補佐官でございます。

2

（神成補佐官）
神成でございます。前回のワーキングまでは、そちら側に座っておりまして、今回から、こちら側に座るということになりました。今回のマイナンバーの主にシステム面の調達並
びに開発等の設計を担当します。頑張っていきたいと思います。
どうぞ、よろしくお願いいたします。

（瓜生企画官）ありがとうございました。楠正憲補佐官でございます。

（楠補佐官）
よろしくお願いします。楠と申します。今度、番号制度推進管理補佐官を拝命いたしました。
たまたま昨年 IT 戦略本部で規制制度改革をやっておりまして、この中でも添付書類の削減等の議論が多くございましたけれども、これらは単に制度の問題だけではなくて、これを実現するインフラが不可欠ということで、情報提供ネットワークは、今後ますます重要になってくると思っておりますので、是非、きっちり調達をしてまいりたいと考えております。よろしくお願いします。

（瓜生企画官）
楠補佐官、どうもありがとうございました。
ここで、峰崎参与は、御公務のために退席されますので、よろしくお願いします。

（峰崎内閣官房参与退室）（瓜生企画官）
この第８回の情報連携基盤技術 WG より、御議論いただく内容が情報提供ネットワーク
システム等の調達の関係になることから、ワーキンググループの構成員を変更しております。変更後のメンバーにつきましては、資料の参考資料１をごらんください。
なお、座長及び座長代理につきましては、引き続き、佐々木座長及び大山座長代理にお願いいたしたいと存じます。
それでは、佐々木座長、本日の議事進行をよろしくお願いします。

（佐々木座長）本日は、御多忙のところ、委員の皆様におきましては、お集まりいただき、どうもありがとうございました。
それでは、早速、本日の議題に入りたいと思います。本日の議題の１つが、２月 14 日
3

に閣議決定となりました、いわゆるマイナンバー法案、この概要につきまして、内閣官房の中村企画官より御説明を、また、社会保障・税番号制度の導入に向けたロードマップについて、内閣官房阿部参事官より御説明をお願いしたいと思います。
それでは、よろしくお願いします。

（中村企画官）
それでは、資料１－１と１－２に基づきまして、マイナンバー法案と、これに伴って提出しております、いわゆる整備法案の概要について、私の方から御説明をいたします。
正式名称は、議事次第の紙にも書いてございますように、行政手続における特定の個人を識別するための番号の利用等に関する法律案ということでございますが、通称といたしまして、マイナンバー法案と称していくということにいたしております。
それでは、資料の１－１の１ページをお願いします。
まず、最初に第１章ということで、総則に法律の目的などを定めております。目的といたしまして、大きく３つ掲げておりまして、この個人番号と法人番号を活用いたしまして、
効率的な情報の管理、利用及び迅速な情報の授受を行うということ。
それから、手続の簡素化を図りまして、国民の負担の軽減を実現していくということ。
それから、このマイナンバーを含めた情報というものがかなりプライバシーの面から特段の配慮が必要な個人情報であるということから、現行の個人情報保護法制の特例を定めるという形で、適正な取扱いの確保を図っていくということとしております。
ちなみに特例を定めるということですけれども、いわゆる一般法といたしまして、現行
個人情報保護法制の適用も原則としては受けるので、このマイナンバー法案に定められていないような点については、現行の個人情報保護の各法令の方に戻るというような体系になっております。
次に、より具体的に第３条におきまして、個人番号及び法人番号の利用の基本というものを定めております。
ここでは、４つに分けておりまして、個人または法人などの情報の管理を一層効率化す
るとともに、対象となるものを特定する簡易な手続を設けるということで、まず、行政運営の効率化及び国民の利便性の向上に資すると、これが１点目です。
それから、今まで大綱までの議論では、情報連携基盤という名前を使っておりましたけ
れども、この情報のやりとりをする、少なくともこの機能については、情報提供ネットワークシステムと法律上は称することにいたしておりまして、この情報提供ネットワークシ
ステムなどの仕組みを利用して、迅速かつ安全に情報の授受を行うということにいたしま
して、これを通じて、社会保障制度、税制その他の行政分野において、給付と負担の適切な関係の維持を図っていくということであります。
次に、実際の実務でのお話になってまいりますけれども、個人または法人、その他の団体から提出された情報については、今、申し上げましたとおり、情報の授受ができるわけ4

でありますので、これと同一の内容の情報の提出を改めて求めるということは避けて、国民の負担の軽減を図るということが３点目です。
最後に、個人番号を用いて収集され、または整理された個人情報が法令に定められた範囲を超えて利用され、または漏えいすることがないよう管理の適正を確保するということでございます。
次に２ページですが、第２章におきまして、個人番号に関する基本的な事項を定めることといたしております。
まず、個人番号の指定や通知ですとか、生成の方法でありますけれども、市町村が住民票コードを変換して得られる個人番号を指定しまして、これを書面で各個人の方々に通知をするということにしております。
この際、市町村は、その個人番号の生成に関わるシステム的な処理というものを、地方公共団体情報システム機構というところに要求するということになっております。
この地方公共団体情報システム機構につきましては、別途、法案が提出されておりまして、実態的に申しますと、現在の財団法人地方自治情報センターを廃止して、これを改組するということで、いわゆる地方共同法人として新たに設立するものですが、こちらの方で、個人番号の基になるものとして番号を生成して、その番号を市町村は受け取って、これを個人番号ということで指定すると。これで、法的にいうと、システム機構が生成した番号が個人番号として確定するという、こういう仕組みになっております。
この個人番号につきましては、漏えいなどがありまして、被害が生じてくるおそれがあるというような一定の要件に該当した場合に限りまして変更が可能ということといたしております。
また、住民票コードが基になっておりますけれども、住民基本台帳関係の事務が自治事務とされているのとは違いまして、このマイナンバーの指定、通知等に関わる事務は、国全体の施策の中のことということもあり、法定受託事務ということにいたしております。
次に、この取扱いの基本的なところといたしまして、第７条から第 10 条と書いてあるところですけれども、この個人番号を利用する事務等の全部または一部の委託について、もともとの責任のあったところの機関が知らない間に再委託されているということがない
ように、許諾を必要としているということのほか、個人番号の漏えい、滅失または毀損の防止など、適切な管理のために必要な措置を講じなければならないことですとか、先ほどの利用の基本というところにも出てまいりましたけれども、複数の手続において、書面等を重ねて求めることがないようにするといったような責務について定めております。
３つ目のところですけれども、提供の要求などについてです。
個人番号を利用する事務を行う者は、本人ですとか、例えば源泉徴収に関する事務を行う給与支払者などのような人たちから必要に応じて、個人番号や、いわゆる本人確認の基
本４情報というものの提供を求めることができるということにしております。
ただ、本人から個人番号の提供を受ける場合には、個人番号カード、後ほど御説明しま
5

すけれども、このカードの提示に加えて、具体的には政令で定めることといたしておりま
すけれども、その他、本人確認のための措置を取って、なりすまし等が起きないようにしなければいけないということにしております。
これらを前提に、マイナンバー法上可能とされる場合を除いて、個人番号の提供を求めることは禁止するということにいたしておりまして、運営上適正な利用の権限がない人が番号の提供を求めることを認めないということにいたしております。
次に、３ページをごらんいただきますと、第６条というところで、この個人番号、マイナンバーの利用範囲を定めておりますが、第６条というのが直接の規定ですけれども、実際の事務の内容について、別表を設けまして、この中で、どういう機関がどういう事務に使えるのかということを百近い項目を列挙して定めております。
ここでは、概略を整理いたしておりますけれども、社会保障・税・防災の分野で使うといっている中で、大きく分けると、ここの３ページに書いてあるような事務ということです。
１つの大きなグループとしては、年金関係の資格取得確認ですとか、給付を受ける際の事務に利用するということ。
２つ目といたしまして、雇用保険など、雇用政策の中で、資格の取得確認、給付を受ける際ですとか、ハローワークでの事務処理などに使うということであります。
３つ目が、医療保険などの保険料の徴収等の手続ですとか、いろんな福祉分野の、主に地方公共団体で行われるような事務について利用するということであります。
この中で、最後に書いてある学資の貸与、奨学金のことですとか、公営住宅など、狭い意味では、あまり福祉というふうに言われていないような事務も入れておりますけれども、一種の広い意味での低所得者対策ということもあって、法案の具体的な検討の中で、こういったものにも使えるということといたしております。
４つ目として、国民が税務当局に提出する確定申告書、届出書、調書等に記載していただきまして、税務当局の内部事務等に利用するというものです。
防災関係につきましては、法律上、明確な防災関係の事務というのが出てくるのが、被災者生活再建支援の法律というものぐらいしかないということで、別表上は、これしか出てきません。ただ、防災のみならず、社会保障などの分野においても同様ですけれども、地方公共団体の条例で定めて使うということも可能といたしておりますので、各地方公共団体においても、いろいろお使いいただけるということで考えております。
次に、４ページをごらんください。第３章ということで、特定個人情報、マイナンバーを含む個人情報の保護に関する特別な定めを幾つか置いております。
まず、最初に、基本的なところといたしまして、この特定個人情報ファイルの作成の制限などを定めているのが、最初の黄色のところです。
まず、個人番号情報保護委員会という、これも後ほど御説明しますが、いわゆる第三者機関といっておりますもの、ここが特定個人情報を適切に管理するために講ずべき措置を6定めて指針を作成するということになっております。
この指針を踏まえまして、行政機関の長などにおきましては、社会保障・税番号大綱で情報保護評価と称しておりました、情報の漏えい、その他の事態の発生の危険性及び影響に関する評価、事前の評価を行うということを義務づけております。
また、マイナンバー法上可能となるようなケースを除いて、その特定個人情報の収集、保管をしたり、そういった必要な範囲を超えて、特定個人情報のファイルを作成するといったようなことを禁止しております。
また、次ですけれども、特定個人情報の外部への提供を原則として禁止するということにいたしておりますが、幾つか例外を設けることにいたしておりまして、その中の大きな１つの項目として、情報提供ネットワークシステムを利用して提供する場合というのを定めることにしております。
したがいまして、法律におきましては、この情報提供ネットワークシステムというのは、
特定個人情報の提供が可能な場合の１つというような位置づけのものとなります。
２つ目のところですけれども、この情報提供ネットワークシステムによる特定個人情報の提供についての基本的な事項を定めております。
この情報提供ネットワークシステムを使用して提供を求められた場合は、その情報を求められた側が提供する義務があるということを１つ定めております。
２つ目といたしまして、特に、マイナンバーの本人がマイ・ポータルなどを使って、情報提供の記録をきちんと見ることができるということを担保しなければいけないということで、この情報提供の記録を情報提供ネットワークシステムに保存するということを明記
しております。
また、このシステムの運営に関する事務に従事する者には、秘密保持義務というものを課しております。
次に、個人情報保護法等について、特例を定めております。これについては、基本的に、最初に申し上げましたとおり、特段の定めがなければ、既存の個人情報保護関係の法令が適用になるわけですけれども、それらの条文について、今回、このマイナンバーについては適用しないとか、細かいところを変えるといったようなことを幾つか定めております。
その内容としては、○とちょっと順番が違いますけれども、この○の２つ目にあります
ように、既存の法令では、法定代理人でなければ、開示請求などを行うことができないわ
けですけれども、これを任意代理人についても可能とするということですとか、本人の同意があったとしても、生命、身体、財産の保護などの特段の必要がない限り、目的外提供ができないといったようなことで、保護を強める措置を取っております。
また、そもそもこれら既存の法令におきまして、個人情報の開示請求ということができるということになっておりますけれども、これについては、そのこと自体は、そのまま適用されるわけですが、最初の○に書いてあるように、マイ・ポータルまたはその他の方法により開示するという、考え方としては、このようにいたしております。ただし、法律上7

は、マイ・ポータルという方法は定めることとはしておりませんで、いわゆる横ぐしで行政手続のオンライン化を推進する法律が別途ありますので、そちらの法律に基づく命令において定めるという考え方を取っております。
次に、４つ目の○ですけれども、地方公共団体につきましては、既存の個人情報保護の法制の中では、具体的な各種の取扱いの義務のようなものは適用されずに、個別に条例などで、地方公共団体において措置を取っていただくということになっておりますので、このマイナンバー法におきましても、その特定個人情報の適正な取扱いの確認のための必要な措置を地方公共団体等において講じなければならないということにしております。
ただ、例えば、この４ページに書いてある事項で、特定個人情報の収集、保管や作成の制限ですとか、提供禁止などの規定、こういったマイナンバー法に特有の規定については、地方公共団体においても適用がされるということになっております。
次に、５ページをお願いいたします。
個人番号情報保護委員会という、第三者機関と言われていたものを設置するための規定を設けております。
この機関の性格といたしましては、内閣府設置法第 49 条第３項の規定に基づくということで、これが、いわゆる三条委員会として設置するということを意味しておりまして、
そういった一定の独立性を持った機関として設置することを法律上明らかにしているということであります。
所掌事務といたしましては、特定個人情報の取扱いに関する監視、監督ですとか、特定個人情報保護評価に関することなどでございます。
組織、任期等については、詳細な説明は省略いたしますけれども、業務として、この特定個人情報の取扱いに関しまして、指導、助言、勧告、命令、報告などの権限を持っているということにいたしております。
次に、６ページ、第５章といたしまして、法人番号について規定を置いております。
法人番号についても、これを導入することによって、行政事務の効率化ですとか、国民というか、各法人の負担の軽減を図っていくということでありまして、国税庁長官が指定、通知をするということであります。
特に、登記がされております法人については、商業登記法による会社法人等番号を基礎とするということといたしておりまして、そのために、この登記簿に記録された事項の提供などを法務大臣から得るといったような流れとしております。
行政機関の長などは、法人の情報の授受の際、この番号を通して行うということのほか、
個人番号とは違って、プライバシーというようなことも考慮の必要性は低いということで民間でも自由に利用できるという考え方にしております。
次に第６章、個人番号カードについての規定を置いております。
市町村長が申請によりまして個人番号カードを交付しなければならないほか、氏名、住所のほかに個人番号の記載をしているものということであります。
8

この交付などに関する事務は、個人番号の事務と同様に法定受託事務としております。
また、住民基本台帳カードの方は、これに伴って、言ってみれば廃止をするということになりますが、市町村の機関におきましては、住民基本台帳カードと同じように条例で定めるところによって、その市町村において必要とされるような用途に個人番号カードを利用することができるということにいたしております。
８ページですけれども、第８章に罰則のセクションがあります。詳細の説明は省略いた
しますけれども、個人番号ないし特定個人情報の性格を考慮いたしまして、いわゆる行政
機関の命令を得ずに直接行為を処罰するケースを増やすとか、量刑を既存の個人情報保護法制における同様の行為よりも重いものとするなど、幾つか特別な罰則を設けているとこ
ろであります。
以上がマイナンバー法案の概要ですけれども、次に資料１－２で、このマイナンバー法の施行に伴う関係法律の整備等に関する法律案について、簡単に御説明いたします。この法律の施行に伴って、ほかの既存の法律の規定の整備を行う必要があるものについて、そういった措置を講じるということで、全部で 27 法律改正するということにしております。
主なものといたしましては、まず、個人番号関係というところの３つ目にあります住民
基本台帳法の一部改正ということで、住民票の記載事項や住基ネットで取扱う本人確認情報として個人番号を追加するということですとか、個人番号を利用する機関に対して、個人番号を含めた本人確認情報を住基ネットを通じて提供できるようにするといったこと。
それから、先ほど少し申し上げましたけれども、住民基本台帳カードに関する規定を削除することなどを主な内容としております。
また、右側の個人番号カード関係というところの１つ目で、電子署名に係る地方公共団
体の認証業務に関する法律の一部改正というものがありますけれども、こちらでマイ・ポータルでのログイン手段として活用することを想定した新たな認証としての利用者証明の仕組みを設けるなどの改正を行うことといたしております。
その他、租税関係の法令で、調書などにマイナンバーを記載すべきこととするなどの改正を行うこととしております。
法案の内容については、以上のとおりです。

（阿部参事官）
引き続きまして、システム担当の参事官をしております、阿部と申します。よろしくお願いします。
私の方から、システムの調達のことについてもスケジュールがあるものですから、まとめてロードマップ全体について、資料２ということで御説明を申し上げます。
まず、法律の今後ですけれども、２月 14 日に国会提出されたというのは、冒頭参与の方からも話がございました。今後御審議いただくということになります。
その下のところに、医療等の分野の機微性の高い個人情報について特段の措置を検討と
9

ございます。この分野につきましては、別途検討するということになってございまして、
１年間かけて検討して、来年の通常国会辺りに法律を出したいと準備されていると伺っております。
法律が出てきますと、右側のピンクのところですけれども、2015 年１月からマイナンバーの利用開始ということでございます。そこにございますような、先ほど御説明がございましたような分野からスタートしますということでございます。
並行しまして、ちょっと下がっていただいて、真ん中から少し下くらいのところですけ
れども、情報保護評価ガイドラインというのを準備しております。情報保護評価サブワー
キンググループの方で御検討をずっとしておりますけれども、そういうのを踏まえまして、
個人番号情報保護委員会が設置され、その後、保護評価を実施していくということでございます。
ネットワークシステム、先ほどの御説明でもありましたけれども、情報連携基盤と従来呼んでいたものですが、法的には情報提供ネットワークシステムという名前になってござ
いますけれども、これについてもちゃんと見ていただいた上で、実際の運用が始まるというイメージでございます。
一番右側のピンクのところですけれども、2016 年１月から国の機関間の連携を始めて、地方につきましては、それとの接続等についても、やはりちゃんと確認しながらやりたいということもございまして、現在のところ、28 年７月をめどにスタートしたいというスケ
ジュール感で準備をしたいと思ってございます。
これの調達ということで、下から２つ目の緑のところのシステム構築というところでございます。
先ほど申し上げましたように、28 年１月からということで、逆算する形で、今、スケジ
ュールを考えているということでございますが、先ほど申し上げましたように、地方公共団体を含めまして、かなりの数の情報保有機関とネットワーク化をしなければいけないということもございまして、十分なテストの期間が要るだろうと考えてございます。
ここで線表を見ていただきますと、本当にざっくりした線表で恐縮ですけれども、テス
ト期間に、単体テストなんかも含めれば、２年弱くらいかけてじっくりやりたいと思ってございます。
そこからさかのぼりますと、詳細設計、基本設計となるわけでございますけれども、結構、そういう意味でいいますと、タイトなスケジュールになっているという理解でございます。
調達の仕方については、勿論、今、仕様書の素案みたいなものを一生懸命事務的には準備しておりまして、まだまだ議論が詰まっていないところもありますし、また、ワーキン
グの委員の皆様方からも、いろいろ御指導をいただきながら準備したいと思ってございま
すけれども、一応、調達の方式としましては、一本調達といいますか、基本設計、詳細設計、それから実際のテスト、いわゆる開発を基本的には１つのベンダーなりにお願いする
10

形で調達をかけたいと思っております。
これを、基本設計と詳細設計を途中で切るというやり方もいろいろあるのかもしれませんが、なかなか連携がうまくいっていないんじゃないかというお話もあるやに聞いておりまして、そういう形で調達をしたいと、考えているところでございます。
それと、必ずしも一体というわけではないんですけれども、ここに書いていなくて大変
恐縮なんですが、適当な時期から品質検証ということで、いわゆる開発していただいたところとは別の業者なりに、要は品質のチェックをかけてもらうことにしたいと思っております。
どういう形で検証をやるのか、どういう項目についてやるのかについても、まだまだこれから検討しなければいけないんですけれども、そんな形で第三者の目で見てもらうことで品質を担保していきたいと思っております。
この結果として、第三者の方に見ていただくということになりますので、見た業者の方は、どういうふうにこの仕組みが回っているのかというのはある程度理解できる立場に立ちますので、後々の保守、運用の辺りでも参入しやすくなるのではないかということもありまして、その結果として、ベンダロックインを回避するための１つの方策になるんではないかとも考えてございます。
もう一つ、システム構築のところの左の上のところですけれども、実証事業と書いてございます。
これもまだまだ中身は検討中でございますけれども、なるべく早い段階で、どういう形で通信をやっていくのかという通信プロトコルなり、そういう技術標準を示せば、地方公共団体なり国の機関の方でもシステムの準備ができるだろうと思ってございまして、この実証事業というものになるべく早めに着手しまして、ある程度固まったものを、対外的にお示ししていきたい。その結果として、それぞれの団体でも準備ができるということにな
るかなと思っておるところでございます。
ここの紙に書いていないことの説明ばかりで恐縮ですけれども、私の方からは、以上でございます。

（佐々木座長）どうもありがとうございました。それでは、ここまでで、御質問、御意見等がございま
したら、お願いいたします。
では、最初に私の方から、マイナンバー法案の概要の３ページのところに、利用範囲ということが書かれているかと思うんですけれども、この中で、いわゆる個人番号を使う業
務として、どういう業務が多いのか、あと、昔の情報連携基盤、今、情報提供ネットワー
クですか、それを通るような情報としては、どの辺が多いのか、その辺の見積もり等がございましたら、教えていただきたいと思います。

11（中村企画官）
多いといいますか、これは、基本的には 90 から 100 近くある項目を、幾つかグルーピングをして挙げているのですけれども、最終的には、更に、省令で具体的なところを最後に決めるということになっておりまして、最終的にどういう事務が数として多くなるというところを現状でなかなか申し上げにくいところもあるのですが。

（向井内閣官房審議官）
補足します。まず、年金は既に年金番号がありますので、これは、長い時間をかけて置き換わっていくべきだろうと。
雇用保険は若干の制度のものがあって、今、雇用保険で、保険料と個人が結び付いていません。だから、雇用保険の保険料は個人管理していない。それをどうするかで変わってくるので、これはちょっと不透明要素が多いと思っています。
それから、福祉の関係というのは、基本的に実施主体が県、市町村なので、これは県、市町村の今の取組み具合にもよりますけれども、かなり具体的に番号を使われている場面が増えてくるのではないかと想定されます。
それから、税の方は、完全に開始当初から、これは調書に番号を振る、申告書に番号を振るというふうな、その番号の利用場面というのは、最初に明らかに出てくるのが、この税の場面。それから医療保険とかそういうものの保険料の徴収場面でも、最初に出てきそうな感じはしていますけれども、そこはまだはっきりはしていません。ただ、最も出てきそうな感じはしています。
それから、防災の場面というのは、それぞれ各市町村に任せられていますので、具体的に起こってしまえば、これは、確実に使えると思っています。
それから、情報連携の方ですが、情報連携でありそうなのは２種類でして、１つは給付調整の場面、ただ、給付調整というのは、現行でもバッチでやりとりしていて、それぞれの分野番号をバッチでやりとりはしているようです。これがどの程度すぐに使えるようになるかどうか、ちょっとわからないところです。
一方、所得情報、社会保障の給付とか、あるいは年金の保険料の減免で使うという、要するに低所得者情報というのは、今後の税・社会保障の一体改革の中身も関わってきて、流動性はありますけれども、まさに昔でいう情報連携基盤の使い方としては、本命ではな
いかなと思っています。
ただ、低所得者が何ぞやという、実質の議論が結構ありますので、ここもすぐ動くかどうかというのは、必ずしもはっきりしないことがありますけれども、基本的に本命はこれとうまくいけば給付調整みたいなものが本命になる可能性が高いなと思っています。あくまで、想定を交えてお話ししましたけれども。

（佐々木座長）12

どうもありがとうございます。ほかにいかがでしょうか。
どうぞ。

（手塚委員）
今 の 質 問 に 関 連 す る の で す が 、 基 本 的 に は GtoC の 構 成 だ と 思 う ん で す け れ ど も 、
GtoBtoC ですね、要するに、個人の番号と法人の番号が関わり、それで政府の方と連携していくと、そういう両方の番号が重なるといいますか、使われるようなものの想定というのは、この中でどれくらい想定されているのかとか、その辺はどういう整理をされているのか、ちょっとお聞きしたいと思います。

（向井内閣官房審議官）
法人番号が使われるのは、基本的には税と社会保険料の徴収ではないかと思っていまして、税の場合は、法人と個人がごっちゃになる世界というのは、実はあまりありません。
消費税なんかは、勿論ありますけれども、それで、税務当局そのものが、どっちかというと、法人と個人を別々に管理しているみたいなところがあって、例えば源泉所得税というのは、法人税で扱っているものですから、そういう意味で、相手によって税務当局が扱っているので、データベースそのものが必ずしも法人と個人が完全に分けられているようなデータベースになっているはずなので、そういう意味で同時には使われますけれども、法人と個人のやりとりといいますか、そういうのはあまりないのかもしれないと。ただ、いずれも、典型的な源泉所得税というのは、個人の番号を付けて、法人が提出するという場
面になりますので、そこは典型的に出てきますけれども、ただ、源泉所得税そのものの情報は個人にばらされると、法人が源泉所得を徴収したかどうかというのは、法人が管理する、そんなイメージに常になっています。また、個人の保険料の源泉で保険料は、完全にそういう問題ではなくて、個人にばらけられますので、そういう意味で、法人と個人の問題というのはそれほどないのかなという気はしていますが、これは、あくまで想定がかな
り入っています。

（佐々木座長）よろしいですか、あと、何かございますか。
どうぞ。

（戸田委員）
法案を見させていただいて、制度の骨格が随分はっきりしてきたなと思っております。
ただ、これからでしょうけれども、運用の設計というのも非常に重要だと思っています。
その中で１つお聞きしたいのは、情報提供等の記録の取扱いですけれども、この情報を一定の期間ずっとためておくというと膨大な量になるし、それをどういう形で国民一般に13見せるかということですけれども、１つお聞きしたいのは、いわゆる最新の情報といいま
すか、即時に見られるようにするお考えなのかどうか、これによって相当システムの負荷が違ってくると思いますので、もし、考えがあればお聞きしたいのですけれども。

（阿部参事官）１つの大きな論点だと思っています。そこについては、まさに、まだこれからというところが正直なところですが、おっしゃったような即時にというニーズも片方であるのかなという気もします。ただ、負荷がかかるのは、まさにおっしゃっていただいたとおりなので、大変申し訳ないですけれども、今の段階でこうだというのは、なかなか申し上げられないですけれども、そういう論点があるということをちゃんと踏まえた上でいろいろ検討
したいと思っております。

（戸田委員）
ログの記録が保存されていることは重要なことと考えておりますので、その辺も配慮して設計していただきたいと思います。

（阿部参事官）
まさに今回は、アクセス記録を残すことに意味があって、それが自己情報コントロールの確保につながると考えていますので、そういうのを踏まえながら、今後検討したいと思います。

（佐々木座長）どうぞ。

（大山座長代理）先ほどの説明の中で、ベンダロックインを避けるというお話があって、これはごもっともで非常に重要なことであると思います。特に政府調達で、今ある大きなシステム、この情報提供ネットワークシステムがどれくらいの規模になるか、まだわからないところがありますが、失敗事例は多々あるわけで、そちらを十分に分析していただくことが大事と思います。
その中で、ちょっとお聞きしたいのは、先ほど品質検証の説明がありましたが、諸外国をふくめてベンチマークになるようなものがありますか。そして、この方法によって、ベンダロックインが回避できる理由を説明いただきたいと思います。

（楠補佐官）
今、具体的にどういった品質検証をするかに関しましては検討中でして、公の分野でど14

れだけあるかというのはわからないですけれども、例えば金融業界であったり、ゲーム業界であれば、第三者によるテストそのものは幅広く行われていますし、そういった専業ベ
ンダーもある状況ですので、官民問わず、今後、事例を探していきたいと考えております。
後半のベンダロックインの件につきましては、かなり正直なところ、どれだけ効果があるかというのは、やってみなければわからない部分というのも多いですけれども、少なく
とも、これまでは結局、実際に構築したベンダー以外のベンダーというのは、何も中身がわからない状態では、そもそもメンテナンスにどれくらい工数がかかるかですとか、全く見積もることができないという状況でありまして、そういった情報の非対称性を少しずつであれ解消していくことが、より多くのプレーヤーが入札に参加できる機会につながっていくと考えておりまして、それが十分かと言われると、改善の余地はいっぱいあると思いますけれども、第一歩として考えているということになります。

（大山座長代理）
もし、そうであれば、最初の理屈が通っていないと思います。ベンダロックインを回避するために品質検証は有効という言い方は、まだ確認が取れていないのであれば、説明ぶりについては注意なさる方が良いのではないかと思います。
実際にベンダロックインを避けるための試みはそこら中でやっていて、私自身も実感していますが、今の話でできるのとは、次元が違うのではないかと思います。
具体的に言うと、例えば IC カードでは IC カードのソフトウエアは全てのコードを検証して安全性の確認をしています。国際標準にもあるわけですが、これはあくまでも実装方
式の中に穴がないかを見ているのであって、決して、それが移植できるという話ではありません。ベンダーは独自の努力で、よりよいものをより安くつくるという、そういうイン
センティブがうまく働くようにすることが大事です。品質検証すれば済むということについては、是非、ほかの例も含めて検証なさってからおっしゃっていただく方が良いのではないかと、ちょっと言い過ぎているかもしれませんが、そのように思います。

（楠補佐官）
今の点に関しまして、御指摘のとおり、ベンダロックインに関しては、さまざまなレベ
ルで、さまざまな取組みが行われていて、恐らく完全に排除するということはかなり難し
いと思います。恐らくソフトウエアスタック間、どういう組み合わせであれ、技術的な依存関係というのは発生してきますし、あるいは理論上依存関係がないように設計したとしても、テストのカバレッジ等の範囲によって大きく、よく使われている組み合わせと、そうではない組み合わせみたいなものもありますので、現実問題としてベンダロックインを完全に排除するということはできないと考えております。
一方で、ベンダロックインの原因というのは、今、言われたようなソフトウエアスタッ
ク、コンポーネント間の依存関係だけではなくて、例えば実際に構築したベンダーと、そ15

れ以外のベンダーとの間の情報の非対称性ですとか、さまざまな要因がある中で、それらの要因を一つひとつピックアップしていって、より条件をそろえていくということを一つひとつやっていく必要がありまして、全く依存関係をそれでなくせるわけではないから、効果がないというふうには直ちには言えないのではないかと考えております。

（大山座長代理）
これ以上、細かい話をする場ではないと思いますが、例えばワードのソフトを使った文
書は、今、アップルのマックでも、ウインドウズでも動いています。これでほとんどの人は問題ない状態にあります。この範囲であれば、選択肢が多数あり競争性が働いているので、ベンダロックインではないといえると思います。
同じような状況は、どうして情報提供ネットワークシステムではできないとお考えなのか、今のお話はわかりますが、いろいろ細かいところがあるので、ここから先の細かい議論は、今日はしない方が良いと思いますが、私が申し上げているのは、ベンダロックインの意味は、ユーザーの方がシステムを自由に入れ替えられる、あるいは競争性を保った中で取捨選択できるという仕掛けなので、あくまでも機能レベルで抑えれば良いという話ではないと思います。

（楠補佐官）
今、御指摘になられたような、いわゆる規格レベルでそろえられるものをそろえていって、入れ替えるようにしていくというような発想は、是非入れていきたいと考えております。

（佐々木座長）よろしいでしょうか。ほかにどなたかございますか。
どうぞ。

（小松委員）
今の第三者の評価の件ですが、第三者の評価自身は、第一の目的がベンダロックインというふうには理解していなくて、多分、きちんと動くシステムをつくっていくためには、一本通した設計から実装まで、きちんと一貫したプロジェクト管理をすべきだということで、その中でそれがうまく動くように第三者評価をするというふうに理解したのですけれ
ども、この後は、ちょっと大山先生との懸念と同じですが、やはり第三者の評価というのは、非常に難しくて、先ほど幾つか事例があるというふうにお聞きしたんですけれども、私の知っている限り、かなり、下手をすると、形式的な評価になってしまうことも多いということで、方法論が確立されていればいいですけれども、なかなかないのではないかと思っています。
16あとは、第三者評価の対象となるシステムの性格といいますか、多分、今回大規模なシステムになると思いますので、その点で、どのような設計の手法に対して、どういう方式が適しているとか、多分、そういうことがあると思われますので、そこは、ちょっと心配ですね。なぜかというと、今回、やってみてだめだったと言えないかなという気もするので、そこをどんなふうに確実な第三者評価というのを実現していくかというのは、いろい
ろ知恵を絞らなければいけないのではないかというふうに考えています。何か、今のお考えがあれば、お聞かせいただきたいと思います。

（楠補佐官）
おっしゃるように、これをやればばっちりですという方法が確立されているとは言い難い分野であるというふうに理解しておりまして、ちょうど幾つかの分野に関しては、国際標準等もつくられているところではありますけれども、これも開発中で検証されているという状況ではなかったですとか、一方で、幾つかの段階があると思うんですけれども、まず、第一にガバナンスの観点で、１つのベンダーの中で実装とテストが閉じているよりは、
きちんと分けた方がガバナンスは働きやすいですし、要はつくった人と同じ視点でテストをするんだと、同じ抜け漏れが発生する可能性はありますけれども、そこに多様性を入れていくことによって、すくなくともカバレッジは上がっていくだろうという点が１点。
あと、ユーザビリティー、アクセシビリティー等、幾つかの分野では、これは準拠した方がいいだろうという標準があって、それらに対しての準拠度を調べるというサービスは民間でもありますし、これまで e-Tax 等でもきちんと検証されている例もありますので、分野によっては機能するだろうと考えておりまして、それらをどうやって組み合わせて、よりカバレッジの高いテストを実現していくかということを引き続き検討していくことにろうかと思います。

（神成補佐官）私の方からも少し補足させていただきます。私自身、行政システムの開発を十年以上担当してきました。それに加え、民間企業の開発案件も大規模なものを含め複数担当しております。これらの経験を踏まえ、品質評価の仕組みを楠補佐官と一緒に検討しております。
この際、国内のものに加え、海外の事例や調達方法、品質評価の仕組みも併せて調査し、その内容を検討に加えております。現在は検討段階であり、詳細が煮詰まっておりません
ので具体的な内容についてこの場で申し上げるのは差し控えさせていただきますが、まとまり次第、改めて申し上げられればと考えております。
なお、先ほど大山先生がご指摘されたパッケージソフトに関しても検討内容に含まれております。
また、テスティングに関しては、内容が多岐にわたることを踏まえ、複数社に委託することも検討しております。
17

以上です。

（佐々木座長）よろしいでしょうか、どうぞ。

（小松委員）
一言だけ、テストするのは、多分、開発をする人と同じくらいのレベルの技術を持っている人が、やはりテストをしなければいけないのではないかと思っていますので、そういう人材も含めて、大変だなと、チャレンジャブルだなと思います。

（佐々木座長）いろいろ、これからのこともあるかと思いますが、是非、いいものにしていっていただ
ければと思います。
ほかに何かございますか。よろしいですか。
それでは、次に移らせていただきます。続きまして、RFI の結果についてと、情報提供
ネットワークの全体機能構成図（案）及び機能の概要（案）につきまして、内閣官房阿部参事官より御説明をお願いいたします。

（阿部参事官）では、私の方から資料３、資料４－１、４－２ということで、続けて御説明をさせていただきます。
まず、１つが RFI の結果についてというものでございます。RFI ということで、今回、調達の準備をするということで、各ベンダーさん等から、今回のシステム構築に当たって、使える技術を提供してくださいということで依頼をいたしました。
そのページの真ん中くらいにございますように、９月２日から 10 月 28 日と、実は大分前ですけれども、まだ、法案が形になっていないというか、まだ議論しているところだったものですから、27 年１月というのを実は頭に置きながら準備する必要があったというのもありまして、この時期に、実施してございました。
その後、法案が出ましたので、新たなスケジュール感の下で、この RFI の分析も含めて、別の仕様のほかの部分についても、準備を進めている状況です。
（３）番のところは、提案依頼において考慮すべき事項ということで、これは一般的な提供依頼において出す項目だと思いますので、省略させていただきます。
２ページの方に行っていただきますと、提案依頼事項ということで、これも一般的なことかもしれませんけれども、こういうことで、情報提供の依頼をかけたということでございます。
皆様、御案内のとおり、情報提供依頼自体は、基本的に、我々仕様書をつくる側の人間
18

だけが基本的に見ますということになっているものですから、３ページにございますように、実は 19 社から出していただいたのですが、社名は全部伏せてございます。ただ、中身としては、こういう情報提供をしていただきましたということをまとめてございます。
これは３ページでございます。
４ページ以降で、我々なりにとりまとめました論点ごとに、どんな提案があったか、実は、繰り返しになりますが、中身そのものを出すわけにもいかないものですから、こういう項目について御提案がございましたということが中心になるんですけれども、出てきたものがどういうものだったかということを御紹介することが、これからの議論にも役に立
つのではないかと思いまして、順番に御説明をさせていただきたいと存じます。
まず、４ページの①、ログインのための認証ということでございます。マイ・ポータル
へログインするための認証手段としては、IC カードに格納した公的個人認証の電子証明書を利用する方式というのが出てきました。
将来に向けた認証手段としては、IC カード以外にもあるのではないか、そういう御提案もいただいたところでございます。
とりわけ IC カードの接続に必要な環境がない場合があることに配慮しないといけないといった提案もございました。
②番のところでございますけれども、アクセス記録の確認の実現の方法につきまして、
大きく情報連携基盤から取るのか、それとも情報保有機関から取るのかと、そういうのがございました。どこにアクセス記録をためるかという問題とも絡むのですが、両方やり方があるよということで提案がございました。
それから、③のところも同じような中身になるのですけれども、自己情報の確認の実現の方法につきましても、いわゆるマイ・ポータル側に情報をためておくのか、それとも各
情報保有機関で持つのかという、大きく言えば、その２つのパターンがあると思うのです
けれども、実は両方とも提案がありました。
それから、利用者フォルダへ情報を保存するのか、しないのかということ、この辺りについても両方出てきてございます。
ただ、私どもも当然分析をしていまして、まだ確定的ではないのですけれども、例えば各情報機関で持ってしまうとすると、それぞれの保有機関でしっかり全部データ整備をしなければいけない、共通で同じように見てもらう必要があるので、なかなか保有機関にやってもらう負担が大きいのかなというのは、ちょっと思っているところではございますが、いずれにしても今後検討したいと思ってございます。
それから、お知らせ通知の実現方法、この辺りも同じような話ですけれども、マイ・ポータルの利用者フォルダに送って保存するというのと、いわゆるリンクを張ってしまって、保有機関の方で見せるようにすると、後者の方は、結局、保有機関、マイ・ポータルの情報をためないという意味において有意性があるという意味だと思いますけれども、逆に言うと、保有機関の方で準備することが多いということで、これも痛し痒しの部分はあると19

いうことでございます。
それから、ワンストップにつきましても、マイ・ポータル側に機能を持つのか、それとも保有機関側でまとめておいて、それに取りに行くのかというようなことも出てございました。とりわけ、ワンストップにつきましては、私ども事務局では、ユースケースによる部分があるので、なかなか判断しにくい部分があると思ってございます。
⑥番ですが、ダウンロードの方法については、PDF なり、もし、加工がいるなら XML
みたいな形でやるということもあるのではないかというのもありました。
代理のところでございます。これも、実は、先ほど法律の御説明でもございましたが、例えば任意代理でも見られるようにするというのも１つ論点として、技術の提案をしていただいているわけですけれども、その中でも、例えば代理人の権限がどこの範囲にあるのかということをチェックして入れて確認するとか、そもそもこの人が代理ですよということを設定するようなシステムが要るのではないかとか、かなりシステム的にもいろいろはねてくるところはかなりあると思っていますが、法案の方の準備ができましたので、うちの内部で、システムと法律的な観点両方から今、検討を進めている状況でございます。
５ページの方でございます。符号の付番・管理及び番号連携の方法ということで書いてございます。
中間とりまとめで５案ほど提案されまして、御記憶かと思いますけれども、その中で、
案２というのが、いわゆる可逆暗号方式で符号を生成・管理するという方式です。案３というのがテーブル方式でやると。
案４、案５というのは、そこに書いてございますように、両方とも、例えばテーブル変換とかをするんですけれども、一部の特定分野では共通 ID コードなり、共通のリンクコードを使うと、これは４番、５番ということになります。
RFI を客観的に分析すれば、ここに書いてございますように、案２がいいんじゃないかという案か、案２もしくは案３どちらでもいいのではないかという案が大半でございました。
案４、案５につきましては、同じ ID を共有する情報保有機関間で結託、不正マッチングが可能となるということで、基本理念と整合しないのではないかという指摘がかなりご
ざいました。
それから、案２につきましては、案３に比べて巨大なテーブルを持つ必要がないので、民間に拡大することも考えれば、かなり運用コストが軽減されるとの指摘も多くございました。
⑨番の情報連携の方法のところでございますけれども、いわゆるゲートウェイ方式、アクセストークン方式について、各社さんとも各方式のメリット・デメリットということで整理をしていただいた上で、結論的に言うと、両方式、それぞれ特性があるし、流れる情
報もいろいろタイプがあるだろうから、両方対応できるようにしておくべきなのではないかというのが、大半の提案だったと理解をしてございます。
20

⑩番でございます。アクセス記録の生成・保存の方法というところでございまして、これにつきましては、情報連携基盤と保有機関で分散管理するべきではないかという提案が大半でございました。
これにつきましては、ここでは情報連携基盤と古い言葉になっていますけれども、いわゆるネットワークシステムと保有機関で、保有機関というのは、新しい言葉では情報提供
照会機関となっていますけれども、いずれにしても分散でそれぞれ持っておく方がいいん
ではないかというか、持つことに法律上なってございますので、基本的には、これは決まった話になったんですけれども、システム的にも、こういう提案が多かったということでございます。
それから、細かいですけれども、アクセス記録の個人識別キーに用いる情報として、要はアクセス記録をためておいて、それをあるときに引き出してくるということになります
ので、そのひも付けをどういうふうにやるのかということにつきまして、直接 ID コードを使えばいいという方法を提案しているところもあれば、さすがに直接 ID コードを使うと、そのままアクセス記録の一部として出てしまうということが考えられるので、これを変換した方がいいんじゃないかという提案もございました。
⑪番でございます。連携基盤といいますか、ネットワークシステムと保有機関での職員のアクセス制御の方法についてでございます。
これは、後ほど御説明をさせていただきたいんですが、提案の中でも保有機関とどうい
うふうにつなぐかということにつきましては、連携インターフェースとここでは書いてご
ざいますけれども、それぞれの団体でそういうのを置いてもらって、そこでコミュニケー
ションできるようにするべきではないかという話でございます。
そのときに、連携インターフェースそのものに職員認証を置くのか、それとも既存の保有機関ごとに、それぞれ皆さん、自分たちで職員認証のシステムを持っていらっしゃるので、例えば自動で回答しようとすると、当然、いちいちインターフェースのところまでいって職員認証をしなければならないのかみたいな話になるので、団体内部の職員認証と連携させるべきではないかというのが、提案としてあったと。その辺り、後ほど御説明しま
すが、１つの大きな論点かなと思ってございます。
⑫でございますけれども、第三者機関の役割とシステム機能による実現方法ということでございます。
これは、先ほども法案の説明の中で、第三者委員会というのができますということなんですけれども、要は第三者委員会が、どこまでシステム的に対応すべきなのかというのは、これは１つの大きな論点としてあると思っていまして、これは RFI でもいろいろな意見というか、アイデアはいただいておりますので、今後は、第三者機関がどこまで権限を持つのかという法律的な議論等と併せて、システム的にどうするのか検討していかなければい
けないと思ってございます。
６ページでございます。連携インターフェース、先取りしてお話しした感じになるんで21

すけれども、その１つ目のポツに書いてございますように、情報提供ネットワークシステ
ムへ情報保有機関が接続するためのシステムとして、標準アプリケーションとして連携イ
ンターフェースを開発して情報保有機関へ配布すべきとの提案が多かったと書いてございます。
私ども、これはかなり現実的な案かなと思っているところでございます。
あと、細かい責任分界点の話が、その下に書いてございますけれども、情報保有機関ごとに、文字コードや外字とか、異なってきますので、その辺の差異をどこで吸収するかというのは、また論点になってきます。既存システム側で対応するのか、それとも、私どもが仮に配布するようなところまでやるのかという話はあるのですけれども、なかなか私どもの方ですべて対応するのは困難だろうと思っています。RFI でも既存システムで実装してやった方が、後々の開発とか改修なんかも含めて柔軟にできるんではないか、ということで、ここに１つ責任分界点を設けた方がいいんではないかというような御提案がございました。
もう一つの下のポツですけれども、個人情報を照会されてきて、提供を求められたら、それを返さなければいけないわけですけれども、いちいち既存のシステムに聞きにいくのか、それとも、それは大変なので、中間サーバーみたいなものに問い合わせに答えるためのデータ集みたいなものを持っておくということが必要ではないかということが、かなり出てきておりました
ただ、そうすると、当然、既存システムとのタイムラグが生じますので、その辺どうす
るのか、これも１つの論点になるのかなと、今後のシステムをつくるという意味では整理をしなければいけないところかなと思ってございます。
⑭番でございますけれども、災害・障害時の措置（バックアップ体制）ということでございます。
データセンターの構成につきまして、主センターとバックアップセンターを１拠点ずつで２センター体制にするのか、それとも主センターと併せて、近距離、遠距離１つずつ、トータルで３つということについても提案がありました。
それから、バックアップシステムの実現方法につきましては、いわゆる２馬力でずっと走った状態にするのか、何か起こったときにすぐ稼働できるように、ホットスタンバイにするのか、この辺りはいろいろな御提案がございました。この辺りは、ちゃんと整理して今後どうするのかというのは決めていかなければいけないと思ってございます。
あと、運用管理の方法でございます。システムの稼働時間につきましては、本体、いわゆる連携基盤本体の部分と、あと、マイ・ポータルともに、基本的には 24 時間、365 日
稼働させなければいけないんではないかというのが、非常に多数ございました。
それから、当たり前のことですけれども、ネットワークの冗長化等々についても御提案がございました。
それから、これは、直接システム的ではないかもしれませんが、いわゆるユーザー支援
22

のためのコールセンターが要るのではないかということも出てございました。
それから、既存資産の活用というところでございますけれども、LGWAN なり、霞が関
WAN の活用についての提案。
あと、活用するに当たっては、一定の改修なり増強が要るのではないかということについても、いろいろ提案をいただいたところです。
それから、地域情報プラットホーム標準仕様というのが総務省の方で、メインはもともと地方団体内のデータのやりとり、例えば課を超えてのデータのやりとりをしやすくする
ための標準仕様ですけれども、これを今回の連携なんかにも活用できるのではないかというような提案もいただいております。
７ページでございますけれども、構築条件につきましては、オープンソースを採用するべきだという提案と、あと、先ほどもちょっと議論になっていましたけれども、パッケー
ジソフトウエアを有効に活用して、コスト低減を図るべきだというお話と、それに対して
は、ベンダー固有の技術を避けて拡張において自由度を確保するべきという提案もあった
りと、いろいろ提案をいただいたということでございます。
その下のポツですけれども、先ほど、私はスケジュールの話もしましたけれども、全国の地方団体が対象になるので、接続に関する試験は段階的に時間をかけてやってくれというような話についても、かなりございました。
それから、リスクということでございますけれども、法整備についてのスケジュールが遅れるリスクがあるという話であったり、情報連携対象の決定が遅れた場合には、当然ながら規模がわからないので、過大になったり過小になったりする可能性があると、それもごもっともだと思いますが、そういう御指摘もありました。
セキュリティーについては、例えば先ほどもありましたけれども、従来のインフラと連携するということになれば、それぞれの持っているポリシーがございますので、その辺りの整理が要るというようなこともございました。
概要を御説明しましたけれども、多岐にわたりまして、いろいろ情報提供をいただきましたので、こういうものも踏まえながら、今、内々に作業を進めているという状況でございます。
続きまして、資料４－１の方に行かせていただきますと、こういうのも踏まえつつ、私どもの方で、全体機能構成図（案）というのを、つくりました。今後は、こういうものを基にして、仕様書にブレークダウンしていく段階だと思ってございます。
今日は、この機能構成図を御説明させていただきたいと思います。
この図を見ていただきますと、大きく真ん中の左寄りですけれども、情報提供ネットワークシステムコアシステムと名前を付けてございますけれども、これが、例えば符号変換であるとか、そういうのをやっていく中心部分に当たるシステムだと御理解いただきたいと思います。
右側に、情報照会者・提供者と、私、情報保有機関とずっと言っていたものが、今はこ23

の名称になっているものですから、情報照会者・提供者と書いておりますが、例として市
町村ということで挙げさせていただいております。
先ほど来、お話をさせていただいておりますけれども、情報提供ネットワークシステム、
インターフェースシステムと書いてございますけれども、こういうものをそれぞれの情報照会者・提供者、従来で言えば、情報保有機関にお配りをするということを考えてございます。
一番左に行っていただきますと、個人番号情報保護委員会システム、いわゆる第三者委
員会のシステムというのもあるだろうということでございます。上に目を転じていただきますと、マイ・ポータルがあります。
あとは、符号なり番号との関係もあって、地方公共団体情報システム機構というのが右上に書いてあると、こういう感じになってございます。
順にざっとですけれども、御説明をさせていただきたいと思います。
まず、コアシステムからですけれども、符号管理機能というのが、右の列の上から２番目にありますけれども、マイ・ポータル及び情報提供者からの求めに対して符号を変換したり、振りだしたりする機能ということでございます。
併せて資料４－２というものがございますので、それも併せて見ていただければと思います。失礼しました。
この符号管理機能では、２つ目のポツでございますけれども、システム機構から受信した住民票コードを基に ID コードを生成し、それを基にリンクコードを生成する機能と書いてございます。
こういった符号管理の機能というのがありますということです。
それから、その下の、資料４－２でいいますと、２番目ですけれども、情報提供管理機
能ということでございます。これは、今、御説明したような、ネットワーク先といいます
か、連携先との連携をする機能そのものということでございます。情報提供照会機関及びマイ・ポータルとの関係で情報をやりとりするということでございます。
３番目としまして、情報提供記録管理機能、これも先ほども出てきましたけれども、いわゆるアクセス記録をためておくということが必要だということでございます。これを保存し、管理する。更に、マイ・ポータルからの求めがあれば、それに対して閲覧を認めるということがこの機能でございます。
４番目ですけれども、個人番号情報保護委員会向け機能ということで、どこまで個人番
号情報保護委員会にもってもらうかということは、これからの大きな論点なんですが、基本的には、ここに書いてある辺りの機能というのは持ってもらう必要があるんだろうということで、とりあえず、書いております。
コアシステムに保存されている各種の監査証跡を保護委員会に提供、出してくれと言われたら、それを出すということでございます。
それから、目的外の個人情報閲覧または取得するような懸念があるような情報提供処理
24

の監視を行って、リスクが懸念される処理を検知した場合に、その場で委員会の方に通知すると、こういった機能もとりあえず、要るのではないかと置いてございます。
セキュリティー管理機能という５番目でございますけれども、これは、他のシステムとの送受信のデータの暗号化であったり、その暗号化に使ったかぎの管理なんかも、この中に入ると思いますけれども、そのような形で考えてございます。
それから、機関間の認証だったり、運用要員等の管理、運用要員の認証等々につきましても、ここの機能でやっていくということかと思っております。
６番目は、システム管理機能ということで、いわゆるシステムのリソース管理みたいな話をここでやっていく、データ送受信機能については、それぞれの相手方とのネットワー
クをしていくということで置いてございます。
２ページの方に行っていただきまして、個人情報保護委員会システムということでございます。とりわけ、この委員会の中では、監視検査支援機能というのが、１つの大きな、当然中心になる機能だということで、監査証跡の収集、分析、監視、検査ということの業務を支援する機能ということが必要だと考えてございます。
あと、セキュリティー管理機能ということで、絵の方を見ていただきますと、委員と書いてございますけれども、個人番号情報保護委員というのは、実はすごい権限を持っておりまして、ここの利用者の認証なんかも非常に大きな、気を付けなければいけない部分かと思っておりますが、そういうものを含めて、セキュリティー管理の機能が要るということでございます。
システム管理とデータは、コアシステムと同様の機能でございます。
それから、インターフェースシステムの方を見ていただきますと、情報提供管理機能というのは、まさに、コアシステムの方でもありましたけれども、情報をやりとりするための機能ということになります。
それから、２番目に書いてある既存システム接続機能というのは、ここでは市町村の例
が、一応、つくってございますけれども、当然、内部システムへの引き継ぎを行ったり、接続して送られてきた情報のデータの確認をして、それを送り出すということも必要になってくるということでございます。
３番目は、情報提供記録管理機能、これは、先ほども説明の中でもいいましたし、先ほどのコアシステムの中にも、この機能はあるわけですが、これをインターフェースの方にも置いておくと、つまり、情報照会者・提供者側でも同じような形で、こういうやりとりをしたという記録を置いておくということでございます。
ただ、これは、ここではインターフェースシステムの中に入ってしまっているのですが、あくまで保有機関が持つべき機能なので、この情報は、一番よければ、中間サーバーといいますか、組織の中の方に持っていくべきではないかという議論も、もしかしたらあるのかもしれません。しかし、一応、現段階では、インターフェースの中で、例えば中身を切って、その一部が保有機関しか扱えないようにしてしまうところに、情報提供記録管理機
25

能というのを置けば、あくまで、保有機関でしかいじれないような形にして残しておくということができるのではないかということも、今、考えてございます。ただ、いずれにしても、コアシステムと保有機関側の両方で持たなければいけないので、それぞれ同じようなものを持っているということになります。
それから、セキュリティー管理機能ということで、先ほどちょっとフライング的にもお話ししましたけれども、職員認証みたいな話もここにも出てくるということでございます。
それから、システム管理機能、データ送受信機能ということになってございます。
参考ということで、中間サーバーということで、これは、市町村側のシステムになるということですけれども、先ほども申し上げましたけれども、データを送り出すために、一定程度の情報をためておいて、場合によっては、自動応答みたいな形で返すみたいなことになると、こういうところにためておいて、照会が来たら、すぐ返すということになるのと思いますけれども、そういうサーバーが要るのではないかということで、一応、ここに仮称として仮置きをしてございます。
符号管理機能と書いてございますけれども、既存のシステム側で利用者番号とかを持っている場合が多いので、それと、いわゆるリンクコードと言われる、それぞれに振り出した符号等をここで管理しておくということが要るのではないかということで、置いてございます。
それで、職員認証につきましては、先ほど言いかけた話は、結局、ここの部分のインターフェースのところにも職員認証が要るのではないかと思っておりますけれども、団体内部で認証したものが、自動的に中間サーバーを経由して、ずっとコアシステムまで流れるような形にしてほしいというニーズも恐らく高いので、その辺りは、どういう形で認証を連結させていくのかというのは、１つの大きな論点かと思ってございます。
３ページでございます。マイ・ポータルシステムでございます。一番上に書いてございますのが、いわゆる利用者認証・管理機能ということで、個人番号カードの認証用電子証
明書の有効性を公的個人認証サービスで確認するということで、利用者がログインする際の本人認証を行う機能を考えてございます。
それから、利用者の申請に基づいて、いわゆるリンク P と言われた、マイ・ポータル用のリンクコードを発行するという要求をするという機能がここに必要だろうと考えてございます。
２番目につきましては、先ほど RFI でも出てきましたけれども、いわゆる情報提供の記録を確認する機能、それから自己情報の表示、プッシュ型、ワンストップと言われている
各種の機能がここに要るであろうということでございます。
これも繰り返し出ていますが、いわゆる代理機能というのが、マイ・ポータルに要るということで、これから十分詰めなければいけないのですけれども、代理する機能が要ると。
それから、利用者サポート機能というのは、４番目に出てきますけれども、マイ・ポータルに対する問い合わせ、苦情等というのも当然あると思いますので、この辺りにつきま26

して、しっかりと対応していくものが必要だろうと。併せて、２つ目のポツに書いていますけれども、ものによっては、それぞれの情報提供者なり、委員会に転送しなければいけないということもありますので、これもどういう形でやるのかというのを考えなければい
けないと思ってございます。
それから、セキュリティーの管理機能ということで、送受信の暗号化とか、運用要員の管理等々でございます。
それから、システム管理機能、データ送受信機能は、ほかのものと同じということでございます。
説明が大変長くなって恐縮でしたが、今の段階で、私どもとして、こういう形の機能を考えているということでございます。
以上でございます。

（佐々木座長）よろしゅうございますか。どうぞ。

（瓜生企画官）済みません、事務局でございますが、先ほど民主党の三村和也先生が御到着になられました。
三村先生、恐縮でございますが、一言ごあいさつをいただければと思います。よろしくお願いいたします。

（三村議員）
本会議のため遅参いたしました、衆議院議員の三村でございます。民主党のシステム調達の関係の小委員会で委員長を務めさせていただいている関係で、オブザーブさせていただきます。どうぞ、よろしくお願いします。

（佐々木座長）それでは、ただいまの御説明に対しまして、御意見、御質問等がございましたら、お願
いいたします。
では、また、私が最初に、ちょっと心配しているのが、半年ほど前のときに、いわゆるユースケースが不十分だという話があって、その辺、確かに心配していたのですが、そのユースケースというのは、かなり積み上がってきたのか、その辺がちょっと心配であって、実を言うと、先ほどのような例は、私が質問したようなことについては、ユースケースをかなり積み上げていれば、どこが一番多いとかというのはわかるのではないかという思いで聞いたのですが、その辺、どうでしょう。

27

（阿部参事官）
先ほど法律の説明の中で、別表１として番号を付す事務について説明がありましたが情報連携については別表２というのがございまして、その中で、別表１のある意味では内数ですけれども、情報連携ができる業務として実は 116 事務が整理されています。
正直申し上げまして法律をつくるのを非常に優先して、といいますか、そちらの作業をやっていまして、その 116 上げるということが、とりあえず、作業として先だったものですから、とりあえず、それを今、各省から上げていただいた状態になっています。
ですから、私どもとしては、それをまさにブレークダウンして、実際にどういう情報が要るのか、だれから具体的にこの情報が要るということを整理しなければいけないと思っていまして、今、それを各省にもお願いをしてございます。
私どもとしても、なるべく早くやらなければいけないと思っていますので、別表２が出ましたので、大分具体的な議論を各省ともさせていただけるのではないかと思ってございます。

（佐々木座長）よろしくお願いいたします。ほかに、いかがでしょうか。
どうぞ。

（大山座長代理）
今日見させていただいている資料４－１、４－２は、ある意味、常套手段的なやり方で、これはこれで良いのですが、その前に、情報システムの、さっきの話ではありませんが、政府調達でうまくやっていくための基本的なポイントがあると思います。すなわち、これよりも前に企画と概念設計ができていなければなりません。これらに関する紙が出た後に、機能をブレークダウンして基本設計というように入っていかないと、手戻りが起こることは、ほかの例でもさんざん見ていると思います。是非、これよりも上位の概念をもう一つ出していただく必要があるのではないかと思います。
そのためには、佐々木座長が言われたとおり、ユースケースの分析を実施していないと、概念設計が間違っているかもしれないということになりかねません。
それから、調達の中で、上下の分離をしないというお話もありましたが、ここも是非間違えないでいただきたいのは、今まで失敗しているのは、上下の分離をしたからではなく、上を取ったら下に入れないという制限をかけたことだと思います。要するに、上下の分離というのは、基本設計がしっかりできているかというのを見る話であり、ちゃんとできていなければ、基本設計あるいは詳細設計まで戻ってもう一回手戻りになる話です。その意
味では、分離をするというよりも、途中の完成度を確認することが大事です。それを１つの業者に任せると逆に作業が遅れてくると、線を引かないで進めてしまうので、それぞれがやっているプロジェクトごとに、進展の状況が変わってしまいます。このような状況を28

見えない形で進めてしまうことに、失敗の主要因があるということを是非お考えいただきたいと思います。

（佐々木座長）どうぞ。

（阿部参事官）
２つ御指摘をいただいて、企画と概念設計ということで、おっしゃっているところは、
恐らく基本的な調達と言いますか、開発のポリシーというような辺りかと思います。
私ども、ちょっと頭の整理をさせていただきたいと思います。どういう形でお示しできるかというのは、また検討させていただきたいのですけれども、重要な視点かと思います
ので、私の方でも検討させていただきたいと思います。
それから、一本調達のことについて、済みません、私の方の説明が不十分なところがあるかもしれませんけれども、決して、一本調達すれば、それでよくなるということでもないと思っていますので、ただ、例えば特許庁の方の話もあったり、いろいろございまして、
要は不必要に、少なくとも上下がスムーズに連結できないのはよろしくないということはあるのかなと、中ではかなり議論した結果としてございまして、こういう形で調達したいと思っているということでございますけれども、先生の御指摘も、いずれにしても、ちゃんとした調達にならなければいけないというのはおっしゃるとおりですので、その辺り、また、中でもよく議論しながら進めていきたいと思っております。

（佐々木座長）どうぞ。

（大山座長代理）
ありがとうございます。特許庁の件について、ここでまた説明することではないと思いますが、御存じのとおり、私は、第三者委員会の委員長をやっていましたし、それから、
年金システムもずっと見てきました。先ほどから申し上げていることは、実経験ですので、お聞きいただくチャンスがあれば、幾らでも協力をさせていただきます。大事なところは、ドキュメントのチェックだということなので、上下分離したからという理由ではないとお考えいただきたいと思います。

（佐々木座長）よろしゅうございますか。ほかに、どなたか、どうぞ。

（手塚委員）
29

確認ですが、資料４－１の構成図（案）で、マイ・ポータルのところで赤点線が入っている、この部分は、何か特別な理由があって、この範囲を何かしているのでしょうか。

（瓜生企画官）
マイ・ポータルの中で、インターネットにつながって機能する部分をあえて強調して認識をしてもらうため、このような形になっています。

（手塚委員）
そういうことですか、わかりました。では、右側の方の赤点線の箱とは、また意味は違うわけですね。右下にも赤点線があるので確認させていただきました。

（瓜生企画官）申し訳ありません、色が混在してございますが、右下の中間サーバーの赤点線部分の意
味とは全く違う、マイ・ポータルだけの中の話でございます。

（佐々木座長）あと、私から１件。セキュリティーの絡みでいうと、最近 APT 攻撃みたいな形で、非常に厳しい攻撃があるので、攻撃の形はいろいろ変わってきていますが、やはり被害の広がりを見ていると、結局、セキュリティーホールがあるサーバーを放置しているみたいな
ところがあって、そういうのは結構きいているんですね。
そういう意味で、要するにパッチを当てていくということは、やはり大事かと思っていて、設計段階からそこをやっておかないといけないのではないかと思います。
それで、オンラインのシステムというのは、パッチを当てると、システムが止まるから嫌だという方がいて、パッチを当てないでやっていて、ファイア・ウォールみたいのがあるから大丈夫だということでやってきたのですが、そこは、もうやれなくなっていると思います。
ですから、そういう意味で、設計の段階から、要するにパッチを当てながら、かつオンラインでやっていくみたいなことを考えていく必要があるのかなと思いました。
どうぞ。

（手塚委員）
今の質問と関連するのですが、今の資料４－１を見て、黄色のところは、これから新規につくるところということで、結構、セキュリティーレベルのポリシーは共通にできると思うのですが、問題は、情報照会者、情報提供者の既存システム、こちらの方と連携する部分、ここのところがセキュリティーレベルにおいて、既存システムの方が、問題はないと思いますが、やはりポリシー上、いろいろなレベルを考えないといけないというところ
30

で、ここの接点は一番重要になってくるかなと、今回思いますので、是非、ここのところは、注意されればいいのかなという気がしております。
あと、もう一点は、名寄せ突合をするのは、ここでは、この符号管理機能というところと思えばいいのでしょうか。名寄せというのは、要するに、リンクコードなり何にしろ、最初の時点でつなぐわけですね。それは、どこのところで、その機能は、今回、どういうふうな提供というか、考え方にしているのか、その辺は、いかがでしょうか。

（阿部参事官）
おっしゃっているのは、初期の突合でしょうか。

（手塚委員）
そうです。初期突合です。

（阿部参事官）
それにつきましては、地方公共団体情報システム機構、右上にあるところから、住民票コードを振り出してもらって、それに基づいて ID コードに変換し、それから、それぞれの機関ごとのリンクコードを出していくということで考えてございます。流れとしては、
そういう流れでございまして、符号管理機能の中に入っております（手塚委員）
是非それも、やはりレベルがかなり、1,700 近くございますので、是非そこをうまく管理していくというのが大事だと思います。提供型にするのか、基本的なところは地方公共団体側がするとか、いろいろ考えていただきたいと思います。

（佐々木座長）ほかに、どなたか御質問はございますか。
どうぞ。

（大山座長代理）
もう一つ聞かせてください。情報提供ネットワークのコアシステム、資料４－１にあるところの中で、個人番号情報保護委員会システムという方に、データ送受信機能というのを持っていて、お互いにやりとりできるようになっています。ないとは思いますが、こちらがセキュリティの穴になることもちょっと心配というのが１点です。また、オンライン
でそんなにずっと監視するというのは、ネットワークの動きを見ているのでしょうか。何が言いたいかというと、情報提供ネットワークシステムのコアシステムを通過するデータに例えば、いろんな色があって、例えば青でも赤でも白でもいいのですが、その中で黄色
31

だけを見つけるというのをここでやろうとしているのでしょうか。それとも白なら白しか通らないが、たまに違う色の怪しいデータが通るかもしれないので、それを捕まえようというのとでは全く違うと思います。通常のネットワーク監視では、流れている情報を見ているわけではなく、ネットワークが順調に動いているかどうかを見ているわけです。このようなレベルで考えると、個人番号情報保護委員会の人は、何を見るのかについてその考え方を教えていただきたいと思います。

（阿部参事官）繰り返しで恐縮ですけれども、まさに、そこを今、議論しているところです。ただ、資料４－２のところで書いているのが、一応、今の段階でこの程度の機能なのかなというのが、実は置いてあるということです。
ですから、４－２の１ページの４番のところに書いてございますけれども、コアシステ
ムに保存されている各種証跡を個人番号情報保護委員会に提供する仕組みなので、あるものを基本的に見せろと言われたときに見せるということをやるという機能と、あとは、コ
アシステムの側で、一応不自然なものを見ておいて、それはある程度機械的に、例えば大量に同じ人ばっかりいっているみたいな話があれば、当然、ウォーニングが出て、それについて、こういうウォーニングが出ましたということだけは、とりあえず、お知らせすると、この辺りまでかなということなんですが、それは、これから役割分担で、どこまで委
員会にもってもらうかというのを決めなければいけないと思っています。

（佐々木座長）
どうぞ。

（戸田委員）
システム全体機能構成図が示されて、それぞれにやっていくというのはいいんですけれ
ども、システム全体の運用監視とか、どういうふうに説明したらいいのかわからないんですけれども、例えば使っている OS もどんどんバージョンが変わっていきますね、そうい
ったものを個々のセクターでやっていくというのは、不都合でして、どこかでレベルの高い専門家を置いて、パッチの問題も含めてですけれども、整合を図って進めていく必要があると思うのですが、それがどこで機能を発揮することになるのでしょうか。

（阿部参事官）
現在は、調達をするということなので、運用フェーズに入れば、当然なってくると思いますが、基本的にはコアシステムというか、システムの一応中心になっているのは、このネットワークシステムそのものですので、そこを所管する主体なりが、ちゃんと見ていくということにしないと、インターフェースに入っているソフトにパッチを当てなければい32

けないといったようなことが当然出てきますから、そこは、所管するところが見ていくということになると理解しております。

（戸田委員）
重要な機能だと思いますので、是非、何か書き込まれるようにしていただくとありがた
いと思っております。

（佐々木座長）ほかに、よろしいですか。それで、個人番号情報保護委員会のシステムというのが、ここに書かれていますが、ここと各個人との関係というのは、今、何らかの形で調査依頼みたいなことがあったときに、調査をしますといったような運用を考えられていますか、それとももっと何か別の運用を考えていますか。

（阿部参事官）システム的なことでいいますと、先ほど御紹介したんですが、マイ・ポータルに利用者サポート機能みたいなものをつくって、マイ・ポータルが一番行きやすいところなので、何か変なことがやられているみたいだということを言っていただければ、それを委員会の方にも連絡するとかというのは、機能として要るだろうなと思っております。
当然、それとは別に、委員会の方に直接何か申し立てるみたいなこともあると思います
けれども、システム的には、そういう形での受け口はつくっておかなければいけないと思ってございます。

（佐々木座長）その辺、運用の容易性という話と、第三者チェックの話が、多分両方あって、あまりコ
アシステムを運用している人が、何かをやり過ぎるというのは、ある意味で矛盾なわけですね。ですから、その辺は、少しよく検討いただければと思います。

（中村企画官）
おっしゃる点につきましては、確かにそもそもこの個人番号情報保護委員会というのが、全体としてどういうふうに業務をやっていくのかというところも、まだ、法案で整理がついたばかりの段階で、十分詰め切れていないところもございますので、そこは、並行で検討を進めてまいりたいと考えております。

（佐々木座長）あとは、いかがでしょうか。小松委員、いいですか。

33

（小松委員）こういう絵を見ると、もっといろんなことを、これは、そこにあるのかと、いろいろ考
えたくなってしまうのですけれども、多分、私たちの役割というか、どこまでやればいいのかというのを一度お話しいただきたいと思います。
例えば、これを見ていると、データはどうなっていくのだろうと、先ほど大山先生がおっしゃったように、全体のアーキテクチャーはどうかとか、その辺から、いろいろ疑問は
ふつふつと湧くのですが、どこまで私たちは、これに対して役割を持つのかなというとこ
ろで、どこまで期待されているのでしょうかというのが、ちょっと気になりますので、教えてください。

（阿部参事官）
冒頭申し上げたように、だんだん実は仕様書の中身に入っていくので、たしか、前回から公開ということになるのですけれども、本当に仕様書の中身まで議論していただくとな
れば、開催のやり方も含めて考えなければいけませんし、逆にいうと、そこまで委員の方で御議論いただくべきなのかということも含めて、整理が必要と考えています。また、今日も三村先生がいらっしゃっていますが、党の方でも御議論いただいているものですから、その辺の議論の進捗を全体的に見ながら、御相談させていただきながら、どこまで御議論いただくかというのは、決めさせてもらえればなと思っております。いずれにしても、仕様書の中身まで入っていくと、当然なかなか議論しにくくなってきますので、私としては、どちらかといえば、大きな論点として、例えば今日お話がございましたけれども、職員認証のところとか、あと、いわゆるバックアップのところとか、幾つか残っていて、大きな論点もありますので、その辺りを中心に御議論いただくのかなと、思っております。

（佐々木座長）よろしいですか。

（小松委員）
わかりました。では、職員認証の話ですけれども、特に今、インターフェースシステム
を通したコアシステムに対しての認証システムというのは、特別なものを考えているわけではないということでよろしいのでしょうか。

（阿部参事官）
まだ、検討は十分詰まってはいないのですけれども、既存のシステムでやっている認証をそのまま受け入れるというのは、多分難しいというか、当然何かの基準をクリアーしているとか、本来的にいえば、そういう前提が当然あって、そのセキュリティーを超えているので、それを信用してつないでいいですよという話になるべきだと考えております。
34しかし、その判定ができるかと言われると、なかなか難しいのかなというのもありまして、何とか簡易な形で、そこを連結できるようなことはできないかなというふうに考えています。
具体的に、まだ、全然十分煮詰まっていませんが、１つの方法としては、例えば公的個
人認証を使うことを考えています。もし、番号カードをみんなが持つということになれば、職員の方々も持つことになるわけですから、団体内部の認証を公的個人認証でちゃんとやっているならつないでいいですよと、既存システム側で、例えば個人認証でちゃんと認証している団体については、そのままスルーしていいですよということはあり得るのかなと、
１つの方策です。まだ、全然具体的なことではないのですけれども、１つの方法としてはあるのではないかと思っております。

（小松委員）
御存じのとおり、個人認証サービスというのは、個人の認証なので、職員を認証しているわけではないので、何かちょっと気持ち悪いなという気はするんですけれども、多分、その辺もこちらの情報照会者、提供者側の負荷等を見ながら、認証システムというのはつくっていかなければいけないのだろうなと思います。
もしかしたら、記憶違いかもしれませんが、LGPKI が、その辺で個人の利用者認証、何か証明書を出していると思いますので、もしかしたら、それも使えるかもしれないというふうには思います。
それから、認証の件でいうと、個人番号情報保護委員会の委員の先生というのは、やはり高いレベルの認証が必要なので、ここだけはバイオメトリクスが必要であるとか、デュアルで複数人認証にしなければいけないとか、いろいろあるとは思いますが、ここがという論点であれば、どんどん深く検討はできると思います。

（佐々木座長）よろしいですか、あともう一件、これはセキュリティーに関連する評価を少しやらせていただいたのですが、コアシステムのところというのは、割と安全性が高いなという認識を持っています。
それで、少し問題になりうるかということでいうと、従来の情報保有機関、ここでの照会者、提供者、機関ですか、ここのところでのなりすまし問題というのは、結構可能性としてはある。
それから、もう一つ、マイ・ポータル、この運用がきちんとやれるということであれば問題ないはずなんだけれども、やはりこの１、２年攻撃のレベルというか、激しさが大分
変わってきているので、やはりある程度そこがブレークするという可能性も考えなければいけないのではないかと思ったときに、マイ・ポータルに情報をどのくらいの期間、どういったものをどのくらいの期間置いておくのかということについても、やはりいろいろ検35

討しなければならないかなと思っています。
この辺について、是非、御検討をお願いしたいということです。
それから、先ほど出たように、今回、個人情報保護委員会システムが、こういう形で明確になってくると、やはりここにおける認証、例えば委員の先生方で、コンピュータがあまり使い慣れていない人が、代理のカードを使って、だれかにやらせるみたいなことをやってしまうとまずいので、どこまでそういうものを使える人を広げるかとか、そういうのは検討しておく必要があると思います。
よろしいでしょうか。どうぞ。

（大山座長代理）
もう一つだけお願いします。先ほど、様々な色のデータが通るという話をしましたが、情報提供ネットワークシステムのインターフェースに関してです。
法案上、許可された情報提供業務が別表に書いてあって、そこには情報照会者も規定されています。ということは、情報照会者と業務をセットにして、インターフェイスを通過できる情報照会の要求に制限をかけるセキュリティー機能を、是非お考えいただくと良いのではないかと思います。
そうすれば、トラヒックも減ることになる上に、さっき言ったような変な色のデータが通ることはなくなると期待されます。
更に、システムのフル稼働に向けた過渡期を考えると、個人のリンクコードを張るのにも相当の時間がかかると予想されるとともに、接続される情報保有機関についてもその電子化の度合いに時間差があると思われます。そのため、実は情報を照会に行こうとしても、相手の情報保有機関は準備ができていないこともありえます。このようなことを想定してうまくコントロールしないと、回答が全部エラーになってしまいます。このようなエラーがたまると、多分、個人番号情報保護委員会の先生方に、何かおかしくなっていますよという連絡が行ってしまうようなことになりかねません。是非、その辺は、うまい整理の仕方をするのと同時にセキュリティーとのバランスを取ることをお考えいただく必要があると思います。
これは、意見です。

（佐々木座長）よろしゅうございますか。では、時間もまいりました。
それでは、これで、本日の議事を終了したいと思います。
最後に、事務局から連絡事項をお願いいたします。

（瓜生企画官）事務局でございます。次回のワーキンググループの日程等に関しましては、別途事務局
36

より御連絡させていただきますので、よろしくお願いいたします。
以上でございます。

（佐々木座長）
本日は、長時間にわたり御審議ありがとうございました。また、活発な御議論をいただ
き、どうもありがとうございます。
以上をもちまして、第８回「情報連携基盤技術 WG」を閉会いたします。
どうもありがとうございました。

37