第７回

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

日時：平成２３年７月２８日（木）１０：００～１１：３０
場所：三田共用会議所
出席者：佐々木 良一
大山 永昭
新井

１Ｆ講堂
東京電機大学 未来科学部情報メディア学科 教授
東京工業大学 像情報工学研究所 教授

悠（代理）ラックホールディングス㈱サイバーセキュリティ研究所

主任研究員
飯島 淳一

東京工業大学大学院 社会理工学研究科 研究科長、教授

小松（独）情報処理推進機構

文子

情報セキュリティ分析ラボラトリー長
坂本 泰久

日本電信電話(株) 情報流通プラットフォーム研究所
主幹研究員

手塚

悟

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

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

松本泰

セコム(株) ＩＳ研究所基盤技術ディビジョン

理事長

認証基盤グループ グループリーダ
山口 英

奈良先端科学技術大学院大学 教授

池田（株）大和総研ビジネス・イノベーション

大造

コンサルティング事業本部 ビジネスコンサルティング部 部長
崎村 夏彦（株）野村総合研究所 ＩＴ基盤インテグレーション事業本部
ＤＩソリューション事業部 上席研究員

實川 昌幸

エヌ・ティ・ティ・コミュニケーションズ（株） 法人事業本部
システムエンジニアリング部 担当課長

鈴木 尊己

富士通（株） 官公庁ソリューション事業本部 主席部長

中上 昇一（株）日立製作所 公共システム事業部公共ビジネス推進部
主管

長島 哲也

日本アイ・ビー・エム（株） 官公庁担当ＣＴＯ 技術理事

坂東 和彦

東芝ソリューション（株） 官公ソリューション事業部官公
ソリューション第二部 ソリューション第二担当 課長

宮坂肇（代理）（株）エヌ・ティ・ティ・データ 技術開発本部
ＩＴアーキテクチャ＆セキュリティ技術センタ 部長

吉丸 邦昭

沖電気工業（株） ソリューション＆サービス事業本部情報システム事業部 マーケティング部 チームマネージャー

吉本 明平（代理）日本電気（株） 公共ソリューション事業部 マネージャー

1

峰崎 直樹

内閣官房参与中村 秀一

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

向井 治紀

内閣官房内閣審議官

奈良 俊哉

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

岡本 誠司

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

古橋 浩史

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

井上 知義

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

瓜生 和久

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

山田 英二

内閣官房情報通信技術担当室主幹

高原 剛

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

肥後 治樹

国税庁長官官房参事官（議事次第）
１．開会（瓜生企画官）
それでは、定刻になりましたので、ただいまから情報連携基盤技術ＷＧの第７回目の会
合を開催させていただきます。
お手元に配付させていただいております資料の確認につきましては、お時間の都合上、割愛させていただきます。不備等ございましたら、適宜事務局までお知らせください。
なお、前回ＷＧで委員の皆様方に御了解いただきましたとおり、本ＷＧは公開として実施させていただきます。
それでは、佐々木座長、本日の議事進行をよろしくお願いいたします。
２．議事（１）中間とりまとめ（案）について（佐々木座長）皆様、おはようございます。本日は御多忙のところ、委員の皆様にお集まりいただきまして、ありがとうございます。
それでは、本日の議題といたしまして、情報連携基盤技術ＷＧの中間とりまとめ（案）について、内閣官房の岡本参事官より御説明をお願いいたします。２つの部分に分けて議論したいということで、始めに資料の１５ページまで御説明をお願いいたします。
（岡本参事官）
それでは、事務局より御説明させていただきます。
資料１「中間とりまとめ（案）」でございます。この中間とりまとめ（案）に関しましては、これまでＷＧにおいて委員の皆様からいただいた御意見や文書でいただいた御意見等

2

を踏まえながら、座長、座長代理の御指導も仰ぎつつ作成させていただいたものでございます。既に委員の皆様には事前にメールで資料を御送付させていただいておりますので、ポイントを絞りまして御説明をさせていただきます。
２ページ目「ＷＧの位置付けと開催経緯等」でございます。（１）にございますように、
平成２３年１月３１日に政府・与党社会保障改革検討本部におきまして、いわゆる基本方
針が決定されたところでございます。この基本方針におきまして、番号の実務検討会及びＩＴ戦略本部企画委員会の下に、個人情報保護ＷＧと情報連携基盤技術ＷＧが設置されたものでございます。
下の方の段落になりますけれども、情報連携基盤の構築に向けまして検討を行ってきたものでございまして、４月２８日には皆様御存じのとおり要綱、６月３０日は社会保障・税番号大綱がとりまとめられたところでございまして、秋以降、可能な限り早期に番号法
案及び関係法律の関係法案を国会に提出することとなっております。また、一般公募されておりました「番号」の愛称は「マイナンバー」に決定したところでございます。
下でございますけれども、情報連携基盤技術ＷＧの開催状況でございます。また、両Ｗ
Ｇによります合同ＷＧも開催されましたし、両ＷＧの座長・座長代理によります意見交換も行われております。
３ページにつきましては開催経緯をまとめさせていただいたものでございます。
下でございますけれども、情報連携基盤技術ユーザーサブＷＧが設置されております。
こちらに関しましては、メンバーは地方公共団体、民間団体、関係省庁等を構成員としておりますし、また、このユーザーサブＷＧの議論の概要はその都度、本ＷＧに報告させていただいているところでございます。社会保障分野サブＷＧも設置されておるところでございまして、議論がなされているところでございます。
４ページ「本書の位置付け」でございますけれども、情報連携基盤技術ＷＧでは、さまざまな技術的な検討を行ってきたわけですが、当ＷＧで現在まで検討してきた内容は、システム設計の視点から見ると、委員から御指摘いただいていますように、概念設計、基本
設計、詳細設計という分類をした場合、概念設計のフェーズの更にその骨格を検討している段階とも考えられます。
当然ながら、より具体的なシステム設計を行っていくためには、現状の検討結果だけでは十分であるとは言えず、更に踏み込んだ検討が必要な事項や、新たに検討しなければならない事項等が存在いたします。
一方で、「大綱」を受けまして、現在でも財務省主計局に必要な説明等を行っていますが、今後関係省庁等が行っていく予算要求や予算編成過程におきまして、一定の方向性が示された材料も必要であるということ等から、現在まで検討してきた内容につきまして、できる限りの中間とりまとめを行い、論点を整備するものであるという記載になっております。
次に「情報連携基盤の役割」でございます。いわゆる諸外国では整備が進んできておる
わけでございますけれども、２段落目にありますが、番号制度は基盤を提供する中で社会保障と税に関わる番号制度ということでございまして、当面年金分野、医療分野、介護保険分野、福祉分野、労働保険分野、税務分野等において「番号」を利用することとされて3

いるわけでございます。また、いわゆる国民ＩＤの検討に関しましても、ＩＴ戦略本部におきましても検討がなされてきたところでございます。
情報連携基盤の構築に当たりましては、セキュリティ対策や記載の事項、コストパフォ
ーマンス等々までを考慮しつつ、制度や業務要件等の可変性等にも十分配慮しながら取り組むことが必要でありますけれども、更に、将来的に社会保障・税分野以外の行政分野や民間機関との間における幅広い情報連携が可能となるよう考慮する必要があろうと考えております。
５ページ「情報連携基盤を活用した情報連携」でございます。番号制度における情報連
携につきまして、２行目、同一人の情報を紐付けし、紐付けられた情報を相互に活用する仕組みであるということで、定義的な規定を記載させていただいております。
また、データベースを有する機関が、他の機関が有するデータベースのうち特定の情報を必要とする際に、本人を一意に特定する何らかの識別子を介在して新たに情報を取得するということでございますが、次の段落、情報連携は番号法または番号法の授権に基づく政省令によりまして、①にございますように事務の種類、②にあります情報の種類、③にございます提供元・提供先等を規定した上で、情報保有機関が情報連携基盤を通じて、他の情報保有機関が保有する情報の提供を求めることができるというものでありますし、また制度上、情報連携基盤を利用するということも義務づける必要がございます。
この情報連携を実現するに当たりまして、情報連携基盤システムの基本ポリシーを明らかにすべきだという御指摘も賜っており、その記載もございます。
なお、「大綱」におきましては、右側にございます確定申告書、法定調書等の手続におきましては、年金や雇用保険等の資格取得等の手続につきましては、法令の規定に基づいて、申告義務者、法定調書提出義務者、または雇用主の義務として行う行為にほかならないものですので、情報を相互に活用する情報連携には当たらないものであるとされておりますが、それについて記載させていただいているところでございます。
６ページ「個人に対する付番、番号連携及び情報連携」でございます。基本的な考え方
といたしまして、番号制度の構築に当たって住民基本台帳ネットワークシステムに係る最高裁の合憲判決を十分踏まえる必要があるということで、下記のとおり記述されているところでございます。①～⑥までの要件を備える必要があるということで、それぞれに関し
まして６～７ページにそれぞれの項目に関します対応策等について書かせていただいております。
（７ページ）中段の「以上のように」から数行下でございますが、システム上の安全措置と制度上の保護措置を講じるということによりまして、国民が安心して番号のメリットを享受できるよう情報連携基盤の構築を検討していかなければならないということ。その下に、番号制度の導入に伴って発生するＩＴリスクの分析につきまして、ＷＧにおきましてフォルトツリーの報告や議論などがなされてきたところでございますけれども、今後とも可能な限り、客観的、定量的な分析を行っていく必要があるという記載をさせていただ
いております。
「２．付番と情報連携の基本的な仕組み」、「番号」の生成ということでございまして、「番

4

号」は住民票コードと１対１対応する新しい「番号」とするということ。また、「番号」の付番対象となる個人につきまして、その定義につきまして記載させていただいております。
８ページの２行目、そのために番号生成機関を設けるということが書かれております。
「（２）番号生成機関から情報保有機関への番号の提供」ということで、情報保有機関は、保有する利用者に係る基本４情報を住基ネットの基本４情報と突合した上で、「番号」の提供を求め、「番号」を自ら保有する個人情報のデータベースと紐付けるということ。
「（３）符号の情報保有機関への割り当て」でございますけれども、情報保有機関は情報連携を行う際、「番号」がいわゆる広く「見える番号」でございますので、これを直接個人を特定する共通の識別子として用いず、当該個人を特定するための識別子として符号を用いるということ。そのため、情報連携基盤が情報保有機関に符号の割り当てを行っていくという流れを記載させていただいております。
突合作業は情報保有機関の責任で対処していく必要がありますが、ＷＧでたびたび御指摘いただいておりますように、一方で情報保有機関の負担を可能な限り軽減する方策の検討が求められるとしております。
「（４）基本４情報の同期化について」でございますが、基本４情報を保有する情報保有
機関は、必要な頻度で保有する基本４情報と住基ネットの基本４情報の同期化に努める必要があるということでございますが、ここに関しましては必要な頻度のイメージがいろい
ろと幅があるということから、具体的例示を入れた方がいいのではないかという御指摘がございまして、例えば年に１回程度から頻繁に更新する必要がある機関まで大きく異なると思われるという記述を入れておる中で、いずれにしましても各情報保有機関の特性はございますので、それらに配慮しつつ関係機関で必要な調整、協力を行っていくべきであるとしております。
「３．情報連携」の「（１）「番号」と符号の関係」でございます。情報連携基盤を通じて情報保有機関相互の連携を実現する手法としては幾つかのパターンが考えられるわけですけれども、今までＷＧにおきましては、先ほどの住基ネット最高裁判決で示された判断枠組みに適合した形で、９ページになりますけれども、個人情報を取り扱うシステムとする必要があるという考え方の下で議論がなされてきたところでございます。
３月４日の第２回ＷＧにおきまして骨格案（その１）を資料として出させていただき、議論がなされたわけですけれども、その後、複数の選択肢が示されるべきという意見が出されたところでございます。これを踏まえまして、６月７日に開催されました第５回ＷＧにおきまして、下にございますように５案を出すような形で論点整理として資料を提出させていただいたところでございます。
また、符号の生成方法として可逆暗号により生成する方式、コード変換テーブル方式により生成する方法の２つの方策について比較検討する資料も出しております。
下でございますが、案５までは皆様よく御存じのとおりでございます。それらの項目、
コストパフォーマンス等からセキュリティ・プライバシー影響度の観点等まで検討した、たたき台を事務局から提出し御議論いただいたわけですが、案１につきましては当然コス
トパフォーマンスは高いのですが、これに関しましてはセキュリティ・プライバシー影響

5度が大きいことから問題であるという意見が多かったのではないかということでございま
して、また「大綱」におきましても、符号を用いる連携ということが書かれているところ
でございます。
案２～５につきましては、案２が可逆暗号方式、案３がコード変換テーブル方式、案３～５までそうなっておりますが、両方式の議論。また案３～５につきましては、情報保有
機関や分野ごとの符号の振り方の違いに関する議論がされたわけですけれども、これらについてはさまざま御議論をいただきましたが、これらの論点につきましては今後検討すべきであるという意見がだされたとしております。
「（２）法令に基づく情報連携を行う情報保有機関と情報連携対象個人情報の特定等」についてでございます。情報連携基盤を用いることができる事務の種類、提供される個人情報の種類及び提供元・提供先等は法案策定までに明らかにすると、「大綱」でなっているところでございます。
「（３）情報連携対象個人情報の提供等」でございます。下の段落でございますが、いわゆる例外措置といたしまして、著しく異常かつ激甚な非常災害への対応など特別の理由がある場合に第三者機関の許可を受けたときは、情報連携基盤を通じた情報連携ができることとするとされておりますけれども、具体的な方法について今後検討する必要があるとしております。
「（４）情報連携」。データの送受信方式についてでございます。これらにつきましてもたびたび御議論いただいたところでございまして、ゲートウェイ方式、アクセストークン方式につきまして、資料等も出していただく中で議論が重ねられたところでございます。
１１ページ、ゲートウェイ方式につきましては、情報連携基盤の役割、アクセストーク
ン方式に関しましては情報保有機関の役割というのが相対的に大きくなると思いますけれ
ども、いずれの方式を採用すべきかにつきましては、ユースケースの分析が十分になされていない現段階で決定するべきではないという意見が多かったと思いますし、また両者の複合型も選択肢として考えるべきであるという意見も出されたと考えております。
「（５）情報連携基盤における本人同意等について」でございます。本人同意に関しましては、ＷＧでも議論がなされたところでもございますし、「大綱」におきましては、番号制度の導入において原則として本人同意を前提としない仕組みとする一方、中段以降でございますが、あらかじめ本人の同意を得て「番号」の利用または情報連携を行う必要がある
個人情報については、その旨、法律または法律の授権に基づく政省令に記載することとなっております。
これらの本人同意を必要とする個人情報のやり取りについて検討を行っていく必要がご
ざいますし、情報連携基盤システムの構築に当たって、本人同意を行う具体的な方法、システムに関する方策を検討すべきであるという意見もあったと考えております。
「４．アクセス記録」についてでございます。これらに関しましては、数回にわたりＷ
Ｇで御議論いただいてきたものをまずまとめているものでございます。
「（１）アクセス記録の内容」につきましては、ＷＧでお出しさせていただいた資料でもございますし、前回のＷＧでも提出をさせていただいておるものでございます。

6以下、その部分の抜粋的なところになっております。「（２）アクセス記録の保存に係る役割分担」ということで、情報連携元の情報保有機関、情報連携先の情報保有機関の役割分担の例示等を書いているところでございます。
「（３）アクセス記録の生成方法と表示方法」につきましても、情報連携に係る処理に関するログから必要な情報を抽出しまして、当該情報を本人が確認できる形式に変換するということが考えられるわけですが、またアクセス記録の生成単位についても検討が必要でございます。
また自然言語に変換する必要があるわけですけれども、用語や表現ぶりの最適化を行う
ことが望ましいと記載させていただいております。
「（４）アクセス記録の編集及び保管場所」でございますけれども、マイ・ポータルで自己のアクセス記録を表示させるためには、アクセス記録を特定することができる何らかのキー情報をアクセス記録に付与しておく必要がございます。また、保管場所につきまして、
情報連携基盤またはマイ・ポータルで保管することが考えられますが、今後検討を進める
必要がございます。
「（５）アクセス記録の完全性及び機密性の確保等」でございますけれども、アクセス記
録の内容も正確であることが不可欠でございまして、生成時におきまして誤りのない内容を記録し、保管においては、不正な改ざんから保護すること等に留意する必要がございます。また、誤ったアクセス記録が生成されないような措置も当然講じることが必要になってまいります。
「（６）アクセス記録の保存期間」につきましては、過去の資料で７年間という例示を記述させていただいたこともございますけれども、保存期間につきましては引き続き検討する必要があるということで、数字等については記載しておりません。
「（７）第三者機関によるアクセス記録の閲覧・分析」でございます。これらに関しましては、個人情報保護ＷＧにおいて検討されてきたところでございますけれども、委員会の役割として以下のような業務を行うと考えられているところでございます。
また、委員会の権限といたしまして、いろいろな権限、いわゆる強力な権限を有することを想定しているわけでございますけれども、１４ページ上段でございますが、委員会による監査の対象となる情報連携に係る処理のログ等につきましては、ログの多くは個人情報が含まれているため、一元管理することは適当ではないということから、情報連携基盤
及び情報保有機関がそれぞれ分散して管理し、必要に応じて各機関からログを収集して監査する方式も考えられますが、一方でログ情報の保護、完全性の担保等を重視いたしまして、情報連携に係るすべてのログを一括して管理した上で、委員会が監査を行う方式も考えられるわけですし、また、実時間でログを確保できるようすべきであるという意見もございました。
「５．情報保有機関と情報連携基盤間の連携インターフェイス」ということでございまして、この連携インターフェイス機能につきましては、自治体等からの関心が高いところでもございます。
後段でございますが、各情報保有機関が持つ既存システムにさまざまな種類があるとい7うこと、改修のコスト等も考えながら、既存システムの差異を吸収する連携インターフェ
イスの確保方法について、早急に検討を進めるべきであるとしております。
「６．情報連携基盤・情報保有機関間等の回線」でございます。できる限り既存システ
ムの有効利用というのも必要なのですけれども、一方におきまして通信の暗号化などの積極的な活用によりましてセキュリティを確保した回線網を利用するという観点も重要であると記載させていただいております。いわゆる霞ヶ関 WAN、LGWAN の対応に加えまして、
行政機関以外の団体が情報連携を行う場合が当然想定されますので、新たなセキュリティを確保した回線網を利用することを検討すべきであるとしております。
１５ページ「７．バックアップ体制の整備」ということでございます。今後の検討課題ということになろうかと思いますが、大規模災害時等におきまして業務を継続できるような措置を講じることが必要でございまして、具体的な検討を進めるべきであるとしております。
別添の資料、資料１－１をごらんいただきたいと思います。案１～５に関しましては、
第５回ＷＧで説明させていただいた資料そのものでございますが、大変小さい文字で恐縮ですけれども、一番下のところに※印を付けさせていただいております。これに関しましては、可逆暗号と、いわゆるオーストリアで採用されている不可逆暗号につきまして、何らかの考え方の整理が必要なのではないかという御指摘もございまして、昨年１２月２７日に開催されました電子行政に関するタスクフォースの資料を記載させていただいております。
２行目の右、可逆暗号、不可逆暗号、どちらもある分野で利用番号が盗まれた場合でも、別分野での不正アクセスや分野横断的な名寄せリスクを限定的なものにすることができる
が、不可逆の場合は分野間の情報連携に当たって、その都度属性情報等により利用番号の連携を行う（例：オーストリアのセクトラル方式）などが想定され、その場合は効率性や安全性に課題があると考えられるという記述がございますので、そこの記述を記載させていただいております。
資料１－２はゲートウェイ方式、アクセストークン方式に関しまして第５回ＷＧで提出いただいた資料そのものでございます。
資料１－３に関しましては初めて提出させていただく資料でございますけれども、委員の先生方から何らかのイメージがつかめる絵が必要ではないかという御指摘がございまし
たので、事務局において作成させていただきました。
真ん中に情報連携基盤がございまして、符号同士を紐付ける仕組みをつくります。マイ・ポータルの４つの機能がございまして、右側の情報保有機関の方に符号の割り当てをいたします。また、「番号」に関しまして、Ａ、Ｂは「番号」を持っていますけれども、Ｃは番号を持っていない、そういうところとも符号と利用番号の紐付けを行うということ等々の絵を添付させていただいているところでございます。
以上で説明を終わらせていただきます。
（佐々木座長）8

どうもありがとうございました。
それでは、とりあえず今までのところについて、御意見等がありましたらお願いいたします。
坂本委員、どうぞ。
（坂本委員）
前回の論点整理及び今回のとりまとめの内容につきまして、何点かコメントさせていただきます。御参考までに資料２ということで配付いただいております。少し長いですのでポイントを絞ってコメントさせていただきたいと思います。
４点申し上げておりますが、アクセス記録について、情報連携についてということで、
まずアクセス記録の方で論点となっておりますログの集約、管理、分散管理するのかということにつきましては、ログの集約ということはやはり個人情報そのものだけではなくて、
そのアクセス履歴なども含めた、いわゆるライフサイクルを包括して管理することになりますので、集約した場合は最も大きなプライバシー保護上のリスクになる。したがいまして、おのおので分散して管理する。監査が必要になった場合には、第三者機関の公的権限に基づきまして、各機関から収集するという方が全体の設計方針と整合しているのではな
いかということで妥当と考えております。
少し飛ばしまして、３項目目ですが、データ送受信の方式について、これはもう少し前に御意見申し上げるべきだったかもしれませんが、情報連携の方式、ゲートウェイとアク
セストークンに関するリスク分析について補足をさせていただきたいと思います。最後に表があるのですが、前提としてゲートウェイ方式とアクセストークン方式のフローについて、概要はもう既に御提示いただいているんですけれども、もう少し情報の流れという面で１つ具体化した手順の一例ということでイメージ図を示させていただきました。ゲートウェイ方式、アクセストークン方式の違いということなのですけれども、この例はＡからＢへ個人情報を送るということをモデル化したものですが、ゲートウェイ方式の場合、Ｂの方から符号Ｂによって要求を出します。これは前提としまして、異なる符号を採用した
場合の分析となっております。Ｂから符号Ｂを用いて個人情報を要求する。そうすると、基盤を通じて符号Ａに変換されて、Ａの方はその要求に従って個人情報を返すことになります。基盤を経由してＢに届くというシンプルな往復の図なのですが、ここで個人情報は暗号化される。この暗号化された情報はＢにしか開けられないということを個人情報Ａ´ということでイメージさせていただいております。
一方、アクセストークンの方は、いろいろ実装のバリエーションはございますけれども、一例としてここでは情報連携基盤の方がトークンを発行する。Ｂの方から符号Ｂで要求を受けた場合に、基盤の方は符号Ａにトークンを付してＡに伝えます。このトークンを介在させることによってＡとＢで直接個人情報を受け渡すというようなイメージ図になっております。
これに対する定性的なリスク分析、改めてなのですが、一番リスクとして目的外の名寄せリスクということに絞って検討してみました結果がこの表になっているのですが、まず

9

情報連携基盤の方で何らかの不正があった場合に個人情報が集約されるのではないかということにつきましては、ゲートウェイ方式の左の方の場合は、先ほど申し上げましたように暗号化されており、基盤では解読できないということですので、基本的にはそのリスクは小さい。一方、アクセストークンの方も、たとえ不正なトークンを発行した場合でも、個人情報そのものはアクセストークンの場合は基盤を通らないということでリスクは小さいということになります。
その他脅威として考えられるのは、外部からこのような情報が盗用されて不正利用された場合あるいは保有機関のどこか１者が不正をして集約を図った場合という１者の不正と言うことについて、いずれもリスクは小さいのではないかと言う考察をしております。その理由は、１つは符号が異なっているということで、このイメージ図を見てもおわかりのように、Ａ、Ｂは情報保有機関と基盤間の間に閉じているということと、もう一つ、トークンの場合はトークンを使われてしまうのではないか、再利用されてしまうのではないかという御指摘もあったかと思いますが、これは該当処理でのみ有効であるように運用することが可能と考えておりますので、名寄せには利用できないという考察にしております。
ただ、これを２者の結託による不正を仮に想定した場合には、いずれの方式についてもある程度のリスクがある。なぜならば、Ａ、Ｂが結託した場合には、個人情報の中身、値を双方で示し合わせて置き換えるあるいは挿入するということが可能なわけです。これは両方式に共通です。更にトークン方式の場合は、このトークンを両者で管理して再利用するというパターンも考えられます。
結託のパターンとして基盤と保有機関が連携、不正をした場合も同様にリスクはある程度存在します。この場合には、いずれの方式におきましても、基盤の指示の下、片方の保有機関に情報を集約するというリスクがあり得る。この場合にはゲートウェイ方式の方は接続が基盤に一元化集約されておりますのでその回避が難しいというような考察をしております。
結論としましては、１者の場合にはある程度リスクは小さいですけれども、２者の場合にはある程度リスクが存在する。ただし、２者以上の結託についてもある程度機能実装によって一部回避または検知できることも考えられますが、どこまで事象の発生確率を見る
かということで、制度的な抑止というものが十分であればシステム的な対策は減らすといような判断もあり得るかなと。
以上のとおり細かくて申し訳ありませんが、総合的な見解としては異なる符号を使った
場合には個人情報の目的外集約防止という観点では両案に大きな相違はないと考えております。これは定性的な分析でありますが、以前に御提示のありましたフォルトツリーの分
析の考察の１つと同様の見解になったということになります。
最後に「番号」を用いない情報連携についてということで、先ほどのとりまとめの中でも御指摘があったところですが、３ページ目、将来的に幅広い行政分野で情報連携を可能とするに当たっては、「番号」を前提としない符号のみの連携の選択肢というのも提供する
べきではないかなと考えております。これは保有機関の管理対象が減って対応が簡素化されるというメリットがございます。先ほどの図のイメージ図、資料１－３の方で「番号」

10

がない保有機関というのも示されておりましたので、申し上げるまでもなかったかもしれませんが、このパターンについても残すべきだろうという意見であります。
その際、課題の１つとしては、どうやって同一人の情報であるのかということを確認す
るのかという課題は残っていると思います。これはオプトイン、ＩＣカード認証によって解決することも可能ですけれども、なかなかすべての保有機関に対応できるというわけではございません。更に非常災害時に利用できるという記載もとりまとめがございましたけ
れども、この場合でも同様の問題が生じると思われますので、どのように自己申告の情報などから臨時的に連携用の符号を生成するかということについては、運用方策を検討しておく必要があろうと考えております。
その際、仮に「番号」そのものを流通させる場合には、識別子としてではなく、個人情報の一部として取り扱っていくというのがリスク管理上は妥当だと考えております。
長くなりましたが、以上です。
（佐々木座長）どうもありがとうございました。ただいまの御指摘というのは、個人的には非常に共感して聞いているのですけれども、今回の中間とりまとめ（案）として特に修文をするという必要はございますか。それとも今後に向けてこういうことも考慮していただきたいということでよろしいでしょうか。
（坂本委員）
今後の御参考ということでよろしくお願いします。
（佐々木座長）わかりました。それでは、ほかに何かございますか。
飯島委員どうぞ。
（飯島委員）
飯島でございます。
先ほど岡本参事官から御説明いただきました中間とりまとめ（案）の４ページについてコメントさせていただきます。
「本書の位置付け」に、現在、概念設計フェーズの骨格を検討している段階という記載がございますけれども、今まで情報連携基盤技術ＷＧで専ら検討してきたものは、「番号」
に関するさまざまな技術的な観点からの課題についての考察であったかと思います。「番号」について議論する場合には、当然「番号」を使って次に情報システムがどう変わるかということを議論すべきかと思いますが、もっと重要なのは、その情報システムがサポートしている業務プロセスがどうなるかということかと思います。
その下の情報連携基盤の役割のところに、社会保障と税に関わる番号制度として当面年
金分野、医療分野等々で「番号」を利用するということが「大綱」にも記載されてござい11

ますが、こういった分野での「番号」の利用ということが考えられておりますので、こういった分野でのどういった業務プロセスが「番号」の利用によってどう変わるかということを次に議論する必要があるかと思います。
ただ、こういった分野のこういった業務を取り扱う組織においても、「番号」の導入にす
ぐなじむ分野とそうでない分野がございますので、そうすると、どの組織がいつごろまでに「番号」の導入ができるかによって、あるいは業務内容の関連性にもよりますが、どういうふうなロードマップで「番号」を導入していけばよいのかという議論が次に必要になってくるのではないかと思います。
これは中間とりまとめの記載をどうこうするということよりも、次に検討すべき課題ということで申し上げました。
以上です。
（佐々木座長）ありがとうございました。おっしゃるとおりだと思いますので、議事録に残して検討していきたいと思います。
あと何かございますか。よろしゅうございますか。もしあれだったら、先に御説明いた
だいて、もう一度この部分においても、もし必要ならば議論するということで、岡本参事官の方から次の御説明をお願いいたします。
（岡本参事官）
それでは、後半部分の御説明をさせていただきたいと思います。
１５ページを再度お開きいただきたいと思います。
「マイ・ポータル・ＩＣカード等」に関してでございます。「１．基本的な考え方」に関しまして、こちらも前回ＷＧで提出させていただいた資料に関しまして抜粋的なとりまとめをさせていただいているものでございます。基本的な考え方にございますように、マイ・ポータルは社会保障・税に関わる番号制度におきまして、国民に提供される情報にアクセスするための入り口となるウェブサイトでございます。
下にございますように、マイ・ポータルは自己情報コントロールができる社会の実現に資するものとして重要な機能であるわけですけれども、委員の先生方御存じのとおり、４つの機能を持つこととなっております。
①自己の「番号」に係る個人情報についてのアクセス記録を確認する機能。②各情報保
有機関が保有する自己の「番号」に係る個人情報を確認する機能。③電子申請を経由する機能（ワンストップサービス）。④行政機関等からのお知らせを表示する機能（プッシュ型
サービス）となっております。
（２）マイ・ポータルに関しましては、マイ・ポータルを通じてさまざまなセンシティ
ブな個人情報がやりとりされることから、厳格な運営体制とセキュリティ対策の構築が必要であるということに関しまして、委員の皆様の御指摘を踏まえてそのような記載となっております。

12

また、下にございますように、利用者フォルダの開設という中で、個人情報保護の観点や情報の一元管理を回避する観点から、利用者の個人情報が利用者フォルダに極力蓄積しないような仕組みとすべきであるとしております。
１６ページ「（３）マイ・ポータルにログインするための認証」についてでございます。
こちらにつきましてもＷＧにおいて数回御議論いただいておりますけれども、そのまとめ的な記載となっております。
３行目にございますように、利用者フォルダにログインする際の本人確認の方法として、認証用電子証明書を使用いたします。また、利用者フォルダへの利用に先立ちまして、マ
イ・ポータルに設定するための初回登録におきましては、公的個人認証サービスが提供する署名用電子証明書、認証用電子証明書の２つの電子証明書を使用するという中で、利用者フォルダに関する初回登録手順及びログイン手順の流れ、利用者視点から見たイメージにつきまして、資料１－４で記載させていただいておりますが、これも前回ＷＧで提出させていただいた資料と同様でございます。初回登録時の事務の流れ等につきまして記載させていただいているとおりでございます。
なお書きでございますが、「オンライン手続におけるリスク評価及び電子署名・認証ガイ
ドライン」に基づいて適切な認証方式を検討すべきとの御意見をいただいておりますので、記載させていただいております。
「（４）マイ・ポータルの利用者フォルダにおける前回ログイン日時の表示」ということでございまして、２行目右でございますが、本人以外の者が本人と偽ってログインしていないことを確認するための１つの手段といたしまして、利用者フォルダにログインした後の画面に前回ログインの日時を表示させるということが考えられるということでございま
すが、こちらも前回ＷＧで提出させていただいた資料の抜粋になっています。
「（５）利用者フォルダの継続利用」につきましても、委員の先生方から御指摘をいただ
いたところでございまして、認証用電子証明書の有効期限が切れた場合や、失効した場合には、利用者フォルダにログインということができなくなるわけですけれども、そういうことに対応するために、取得し直した認証用電子証明書のシリアル番号を従前から利用していた利用者フォルダの新たなアクセスキーとして設定することを考えるべきであるとしております。
「（６）マイ・ポータルにおける個人の情報の保持」でございます。①にございますように本人による利用者フォルダログイン後、速やかに該当の情報が画面に表示されて本人がこれを確認できるようにするため、事前に必要な情報をマイ・ポータルに収集・蓄積しておくという考え方がございますが、一方で②にございますように、マイ・ポータルでは必要な状態になるまでできる限り情報を保有しないというふうにするために、本人による利用者フォルダログイン後に情報保有機関から該当する情報をマイ・ポータルに収集して、画面に表示させるという考え方もございますが、いずれにしましても、マイ・ポータルにおける情報保持を回避するということと、本人による確認の即時性等を勘案の上、具体的な方策を決定すべきであるとしております。
また、利用者フォルダに格納された情報で本人による確認が行われた情報につきまして13

は、ログアウト後消去することが考えられますが、実際確認した情報を改めて本人が確認したいということが考えられますので、ログアウト前に一定のファイル形式でダウンロー
ドすることができる機能を提供することについて検討する必要があるとしております。
「（７）電子申請を経由する機能（ワンストップサービス）」でございます。前段はその概要について記載させていただいておりまして、なお書きでございますが、必要な手続き
はマイ・ポータルのトップページから各情報保有機関のサイトにリンクを張って認証連携することで、電子申請を行うということになろうかとも思いますが、典型的なサービスについて一度電子申請すれば、申請が必要なすべての情報保有機関に送付され処理される仕組みも検討するべきであるとしております。
「（８）行政機関等からのお知らせを表示する機能（プッシュ型サービス）」についての記載でございます。
１８ページ「（９）利用者フォルダ」の保持期間でございます。マイ・ポータルに設定されました利用者フォルダにつきましては、本人の死亡または国籍喪失に伴う海外転出など、本人が「番号」の付番要件を喪失するまで保持し続けることが考えられますが、また「番号」の付番要件を喪失した後も一定の期間利用者フォルダを保持すること等が考えられるわけです。一方で情報セキュリティの確保という観点もございますので、そちらの観点も踏まえつつ更に検討する必要があるとしております。
「（１０）代理によるマイ・ポータルの利用及び扶養関係について」でございます。代理の取扱いを検討する必要性につきましては、当ＷＧでもたびたび委員の先生方から御指摘がなされまして、また個人情報保護ＷＧにおいても検討がなされてきたところでございます。法定代理、任意代理につきまして、記載のとおりの要件に基づきまして認められるということになるわけでございますけれども、中段で、そのためにマイ・ポータルにはマイ・ポータルが提供する本人に関する情報を代理人においても確認することができるようにする機能。また、代理人が本人に代わって確認することができる情報の範囲を特定する機能等について必要になってきますけれども、一方で、代理人の正当性を的確に確認することが困難であるということ等も踏まえつつ検討していく必要があるとしております。
また、代理人による情報の確認の方法といたしまして、①にございますように、代理人の利用者フォルダに本人に関する情報を格納した上で代理人がこれを確認するという方法と、本人の利用者フォルダに代理人もログインすることができるように設定した上で、代理人が本人の情報を確認するという、大きく２つの方法があると考えられますけれども、本人と代理人との間で利益相反となるおそれのある情報をどう取り扱うべきか。
一方でＷＧでも御指摘いただきましたけれども、システムが複雑化しすぎないようにするということも重要ではないかという御指摘もいただいておりますので、その点にも留意しつつ具体的な方策を決定すべきであるとしております。
また、本ＷＧにおいて扶養関係について議論すべきという御意見を賜っております。一方で扶養関係は制度ごとに異なるということから、情報連携基盤及びマイ・ポータルにおきまして扶養関係に対応したシステムを構築することは困難ではないかという意見もいた
だいたところでございます。

14

「（１１）自宅以外でのマイ・ポータルの利用」につきましては、１９ページになります
けれども、マイ・ポータルにつきましてパソコンがない場合等マイ・ポータルへの接続が困難な者等が確認できるようなその他の仕組みを幅広く検討すべきであるとさせていただ
いているところでございます。
１９ページ「（１）ＩＣカードの交付」でございます。ＩＣカードの交付の必要性につきまして（１）に記載させていただいているところでございます。
アクセス記録の確認等を行うことができるマイ・ポータルにログインするために、また法令に基づき「番号」を取扱い得る事業者等が対面の場合には券面に記載された基本４情報及び顔写真等により、オンラインの場合には公的個人認証サービスの活用等により、利用者が本人であることを確認した上で「番号」を確認できるようにするため、ＩＣカードを交付できるようにする必要があるとしております。
なお、利用者の利便性の向上を図るため、ＩＣカードの普及を前提としつつ、将来的には多様な本人確認等の手段を利用できるように検討していくことも必要であると、カード以外に関する記述もしております。
「（２）ＩＣカードの発行」につきましては、記載のとおりでございまして、本人確認を行った上で、いわゆるＩＣカード、現行の住基カード等を活用しつつ機能を加えて改良するということで①～④までの記載をしているところでございます。
２０ページですが、技術的な観点等といたしまして、ＩＣカードに記載・記録する情報の範囲等ということで、ＩＣカードの様式、その他必要な事項は政省令で定めることになるわけですけれども、券面記載事項としては、「番号」、氏名、住所、生年月日、性別、顔写真等が考えられますが、またＩＣチップ記録事項としてもいろいろな観点がございます。
いずれにしましても記載・記録を必須とする事項や健康保険証に関連する事項を記載・記録することも含めて、更に検討していく必要があるとしております。
また、「（４）ＩＣカードの交付等」につきましては、ＩＣカードに関する各種のイベン
トについて例示がございますけれども、こちらに関して具体的な検討を進める必要があるとしております。
「（５）窓口での対応」につきましては、窓口等でリーダ及びソフトウェアで確認することができるようにする等の記載をしております。
２０ページの一番下でございますが「法人に対する付番」でございます。登記のある法人等につきましては、会社法人等番号を基礎として付番するということ、会社法人等番号を有しない登記のない法人等に関しましては、登記のある法人等に係る会社法人等番号と重ならない番号を付番するということになろうかと考えております。
２１ページ、なお、法人等の支店や事業所等に関しましては、必ずしも会社法人等番号を有していないことから、「法人番号」の付番を行わないということでございますけれども、
他方、国税の源泉徴収義務と地方税の特別徴収義務の両方を有する法人等の支店、事業所が相当数ございますので、それらに関しましては、国税当局内部で活用している番号の地方税当局との共有を図る中で、地方税当局及び徴収義務者の事務処理の効率化を図ることとすべきであるとしております。

15

２が「法人番号の変更」、３が「法人番号の通知」でございます。
いずれにしましても４にございますように、「法人番号」は広く一般に公開されるものでございまして、自由に流通させることができ、官民を問わずさまざまな用途で利活用が想定されております。このため、法人等に対する付番機関におきましては、法人等基本３情報の検索、閲覧ができるサービスをホームページ等で提供すべきとしております。
「５．企業コードについて」でございます。電子行政に関するタスクフォースにおきま
して、いわゆる企業コードの整備及びその活用のための施策について検討をしております。
今後の検討の方向性といたしましては、記載のとおりの項目について検討を進めていく
わけでありますけれども、委員の先生からも御指摘をいただいた項目といたしまして、例
えば８行目の右の方になりますけれども、企業認証の整備、９行目になりますが、企業コードに関連した企業ポータルの整備ということの検討も考えられるかなと思っております。
また、なお企業認証につきましては、電子署名及び認証業務に関する法律に基づく認定
認証業務の活用を含めて検討することが考えられると考えております。
これらに関しまして、いずれにしましても、次の段落、タスクフォースにおいて国、地方公共団体における行政手続に関し、連携のメリット等を整理するとともに、必要となる業務改革についての重点的な検討が必要であるとしております。
「その上で」から２行でございますが、誠に恐縮でございますけれども、こちらは差し替え前のものでございまして、その上で求められる性質を満たすための仕組みや、法人番号に関連する企業ポータルにつきましての２行は、削除ということで（案）として御了解いただきたいと思います。申し訳ございません。その内容が上の方に記載されているということでございます。
企業コードに関しましては、網羅性、一意性、一貫性等の性質が備わっていることが望
ましく、番号制度により付番される「法人番号」を利用するに当たってさらなる検討が必要になると考えられます。
「６．その他」は、ＷＧの委員の先生から御指摘がございまして、企業におきましては、雇用する従業員の「番号」に係る情報の取扱い等いろいろな業務に番号制度の導入に伴って対応していく必要があるわけですけれども、当然「法人番号」の活用ということでメリット等もあるということでありますが、「番号」に係る情報の連携等につきまして、企業の負担軽減の観点から検討も必要ではないかというような御意見をいただきまして、その項目も記載させていただいております。
次に「社会保障分野の取扱いについて」でございます。２２ページ一番下の右でございますが、医療・介護分野での情報連携につきましては、特にまず情報保有機関が相当数に上ります。平成２１年厚生労働省調査によりますと、医療施設は約１８万、介護施設・事業者数は約２６万でございます。非常に多くの情報がやりとりされるということ、また民間の医療機関も当然含まれてまいります。
ということになることから、法制上の特段の措置と併せて、負荷や費用の面で、勿論、これは効率的なシステムとなるよう努めなければならないわけですけれども、当然そうい
うことを前提としつつ、特段の技術設計を行う方向で検討するとしております。

16

また、医療分野等において番号制度の利便性を高め、国民に安心して活用してもらうた
め、医療分野等の特に機微性の高い医療情報の取扱いに関しまして、個人情報保護法または番号法の特別法として、機微性や情報の特性に配意した特段の措置を定める法制を番号法と併せて整備する。法案の作成は、社会保障サブＷＧでの議論を踏まえて、内閣官房と連携しつつ、厚生労働省において行うとされているところでございます。
「今後の開発に向けての留意点」でございます。ＷＧの委員の先生方からもたびたびスケジュールに関する御意見をいただいておりますので、それをまとめております。全体のスケジュール、特に実施に向けた期間の制約も非常に大きいわけですけれども、多岐にわたる情報保有機関が接続する新たなシステムであるということを考えると、時間をかけた
慎重な対応が必要になるという御意見、番号制度に基づく情報連携については、できるところからスタートする、スモールスタートも考える必要があるという御意見、大規模なシステムであることから、プロトタイプ開発を実施し、実証実験を行いながら進めるべきであるという御意見等々いただいておりますので、記載させていただいております。
また、システム等の技術設計や開発に当たりましては、費用対効果も十分踏まえた検討を行う必要もございます。
２４ページ「おわりに」ということでございます。情報連携基盤技術ＷＧでは、構成員の先生方の経験や知見を活かしまして、またＷＧとも連携しながら情報連携基盤の構築に向けた検討を重ねてきたものでございますけれども、土台となる部分について一定の方向性を示すことができた一方で、情報連携の範囲とされた、いわゆる社会保障・税分野で示された利用場面のうち、情報連携基盤を用いることができる事務の種類、提供される個人情報の種類、提供元・提供先等が未確定でございます。当ＷＧにおきましても、委員の先生方から提出されたユースケースに関する資料等に基づき議論がなされましたけれども、その社会保障・税分野のユースケースの分析がすべて十分にできているというわけではないことから、現時点では情報連携基盤に必要となる機能や性能等の要件を洗い出すというところまでには至っていないというところかなと考えます。
また検討の視点といたしまして委員の先生方から御指摘いただきましたが、情報連携基盤との連携において、情報保有機関がどのようなものとイメージするかによっても着目の仕方が異なる。国レベルでは、いわゆる国税庁、日本年金機構等がございます。地方レベ
ルでは約１，８００の地方公共団体、一方で接続方式の詳細は今後検討が必要ですけれど
も、医療機関・介護事業者等も存在しております。
そういう意味で、情報保有機関にさまざまな種類が存在いたしておりますので、取り扱う情報の種別、情報量等を踏まえて情報連携基盤の構築を検討することが必要でございます。また、情報連携の処理性能を実用に耐え得るものとするため、費用対効果を踏まえ、情報連携基盤の性能目標等の検討も必要となってまいります。
主要なシステム構成要素（コンポーネント）を抽出しまして、機能要件を満たすための
ＩＴシステムの構造（アーキテクチャ）の定義をいたしまして、これらを実現する仕様等を検討する中で、当然ですが非機能要件としてのセキュリティ対策や災害等事業継続を困難にする事象に対応するためのデータや装置のバックアップなど、事業継続に関する方策

17

等についても検討する必要がございます。
このように検討すべき事項は数多くあるわけですけれども、今後まずはユースケースの分析を早急に進めるとともに、それを充足するための機能の確認やトランザクション数、データ量など、たびたび御指摘もいただいております、いわゆる性能面の妥当性の検証等を行う必要がございまして、政府において最適なシステム構築に向けた検討を精力的に進めることを強く求めるものであるという結語となっております。
説明は以上でございます。
（佐々木座長）どうもありがとうございました。ただいまの御説明に対しまして、御意見等ございますか。小松委員、どうぞ。
（小松委員）
お願いがあるのですが、１６ページの一番下、利用者フォルダについて、「認証用電子証
明書のシリアル番号を利用者フォルダへのアクセスキーとして使用する場合、認証用電子証明書の有効期限が切れた場合や失効した際には、利用者フォルダにログインできなくなる。このため、取得し直した認証用電子証明書のシリアル番号を従前から利用していた利用者フォルダの新たなアクセスキーとして設定することを考えるべきである」という記述があるのですが、文章の位置づけとしては、認証用電子証明書の内容についてここで記載するのはやや詳細すぎると考えます。
ですので、利用者フォルダを継続使用する場合、もしくは前段にあるように利用者フォルダの認証時の電子証明書の使い方等につきましては、勿論、技術的には今後検討していかなければいけないと思うのですが、詳細過ぎますので、この辺はもう少し認証用電子証
明書を利用するとか、認証用電子証明書の情報を利用して利用者フォルダを継続させるであるとか、文言の修文をお願いしたいと考えます。
技術的にはいろいろバックグラウンドがあって申し上げていますけれども、ここまで詳細に書くというのは少し書き過ぎなのではないかと考えます。
（佐々木座長）今、小松委員から、実質のやり方がいろいろあってまだ詰め切れていないだろうから、もう少し書き方として今後の検討課題であるというような書き方にした方がいいのではないかという御指摘と考えてよろしいですか。
（小松委員）
はい。
（佐々木座長）今の御指摘に関連しまして、何か委員の方から御意見ございますか。よろしゅうござい

18

ますか。では、これについてはそういう形で文章を見直させていただくということで、後でまた御相談するかと思いますけれども、よろしくお願いします。
（小松委員）
よろしくお願いします。
（佐々木座長）あと何かございますか。どうぞ。
（山口委員）
２点。まず、２３ページの「今後の開発に向けての留意点」というところでスモールス
タートなどの意見を言わせてもらった経緯がありますが、大規模なシステムであることも重要なのですけれども、もう一つは、システムを作っていく上で手戻りとか開発途中での仕様の再度の検討とかあるので開発コストがいきなりでかいのをつくると上がってしまう
ので、だからスモールスタートをやって確かめながらやったらどうかというのが意見の趣旨だったわけです。ということで、全体の開発のトータルコストの圧縮に勘案しつつというような、全体のコストを増大させないという意味の文言をここに加えていただきたいというお願いが１つあります。
前のセクションに戻ってしまうのですけれども、いいですか。
（佐々木座長）
どうぞ。
（山口委員）
８ページのところですが、ずっと読んでいて、私は頭が悪いのでよくわからないのです
けれども、８ページの（２）の番号生成機関から情報保有機関への番号で、「番号」の提供というのは、これをやってしまうとセクトラルモデルではなくなってしまうのではないかというのがすごく気になるのですけれども、これは読み方を間違えていますか。
もともと各情報保有機関はそれぞれの中で自分の個別番号を使っていたと。個別番号とほかの機関との間の紐付けをするところでいきなり「番号」を使うとおかしいから、リンクコード、ここでは符号という言葉を使っていると思いますけれども、リンクコードを使って突合の目的に使っていた。そうすると、「番号」というのは、行政事務の中で結果として提示される可能性はあるけれども、それを付けてしまうと「番号」でデータベースは全部フラット型のモデルになってしまうので、突合ができてしまいますね。だから、これは記述としていいのですかというところなのです。
（佐々木座長）まず第１点目については、書きぶりの話ですのでこれも議論させていただくということ

19

で少し書き方を考えたいということです。
第２点目の話について何か委員の方から御意見ございますか。
どうぞ。
（大山座長代理）
今、山口委員が言われた話で理解を深めるために確認したいのですが、スモールスター
トと言っているのは、いわゆるウォーターフォールではなくてアジャイルでやれということですか。
（山口委員）違います。私がもともと意味していたのはそちらではなくて、もう少しスモールスケー
ルで始めてくださいということです。だから、いきなり国民全体に適用するシステムではなくて、プロトタイピングの意味を持っています。
（佐々木座長）そちらの方はよろしいですか。後者の問題について何かございますか。よろしいですか。
では、小松委員、どうぞ。
（小松委員）
私は別に弁護するわけではないのですが、先生のおっしゃったとおりだと思うんですが、坂本委員の先ほど資料で、「４．番号を用いない情報連携について」ということで、将来は符号のみで紐付けすることを可能にすればいいのではないかというような資料が出ていると思うのですが、まさにこの話なのではないかと思います。
ここでどこまで「番号」を、坂本さんは今後検討すべきだという話だったのですが、中間とりまとめにどういうふうに書くかというような、どこまで詰めるかということだと思いますので、私の意見ではないですけれどもね。
（佐々木座長）私も意見はあるのですが、事務局の方からこの点について何か御意見ございますか。
（岡本参事官）フラットモデルかセクトラルモデルかということに関しましては、委員の先生方でまた御議論いただきたいと思うのですけれども、いずれにしても情報保有機関に何らかの形で「番号」を渡す必要もありますし、「番号」を確認するという機能は必要になってくると考
えております。そこのところで初期突合をどの程度どういうやり方でやるか、情報の基本
４情報の同期化についてまたいろいろ御意見があろうと思いますけれども、当然情報保有機関に何らかの形で「番号」を提供するという機能は必要なのではないかと考えています。

20

（佐々木座長）
よろしいですか。あと何か御意見ございますか。
セクトラルモデルかフラットモデルかという議論は勿論あるのですけれども、要するにこれをやることによってセキュリティ上何か具体的な問題が出てくるのか、あるいはプラ
イバシー上付帯的な問題が出てくるのか、そういう仕組みになっているのかどうかの議論が必要だと思うのですが、山口委員はその辺どのように考えられていますか。
（山口委員）
もともとオーストリア方式と言われていたセクトラルモデルのひな形みたいなものでは、各情報保有機関が使っている個別番号の適用範囲を法律で厳格に定めて、そこの拡大を阻止しつつ、相互に情報保有機関が突合するための、ここで言っている符号というものの提供を個別に行うからセクトラルという言葉が出てきているわけですね。
ところが、「番号」というところが共通的なキーとして使えるのであれば、情報連携基盤
を利用しない突合の可能性というのは出てくるわけですから、当然そこの部分はどういうふうに考えるか。私は特に今まで結託の問題を言ってきましたけれども、その可能性は起きるのではないですかというところが問題なので、プライバシー保護とか、そういったビックブラザーの問題とかに１つ問題になるのではないかと思います。運用上の問題もありますので、制度との関係で必ずしもこの１点で言い切るのはなかなか難しいところだとは思いますが、もともとのひな形で考えられていたオーストリア方式で言われていたものとは違うのかなというところだけは指摘したい。
（佐々木座長）オーストリア等について具体的にその辺りのセクター間の情報のやりとりの問題をどう扱っているかについて井上さんの方から何かございますか。
（井上参事官）
岡本参事官からも御説明ありましたけれども、資料１－１の下のところに違いについて細かい字で恐縮ですが若干注書きで書いてあります。違いは２点あるかと思っています。
１つは可逆か不可逆かということで、案の２においては可逆方式を提示しているわけです
けれども、オーストリアの場合は不可逆であるがために情報連携に当たって番号間の直接の連携ができない、したがって、属性情報をその都度送る、照合するというようなことをやっている。そういう意味で効率性とかセキュリティ、プライバシーの面で課題があるのではないか。したがって、そこを解消した案ということで可逆方式を案２で提示しているということです。
もう一点、山口先生が御指摘になった利用番号もオーストリアの場合とは異なっている。
日本の場合、共通番号を使うところについては共通であり、そこが違うということです。
共通化されていることによってセキュリティ上あるいはプライバシー上の問題が生じるので、その点については「番号」に係る個人情報について法制面で措置し、罰則も含めて対21

応しているというところです。
（佐々木座長）どうぞ。
（大山座長代理）
これも多分この文書全体の構成に関わることだとは思うのですが、今の８ページの（２）に関する内容は、７ページの２．のところに戻って全体を見る必要があると思います。付
番と情報連携の基本的な仕組みということで「番号」が出てきますが、先ほど井上参事官が言われたところにもかかるように、８ページ（２）の情報保有機関を、もし明確にするのであれば、例えば「「番号」を用いる情報保有機関は」と限定すれば、そこの考え方が整理されるのではないかと思います。もちろん、それ以外のことも情報連携基盤としては考えることが必要であり、将来の発展性も他方で言っているので、今のような表現になっているのはないかと思います。このような整理だったらいかがですか。
（佐々木座長）
山口委員、何かございますか。
（山口委員）
私はその次の（３）のところで「番号」は直接個人を特定する共通の識別子として用いずという記述があったので気になっているんです。全体に整合性と適用範囲の書き方をこ
こは丁寧に書いた方がいいと思うのですけれども、今、先生が言われたように、例えば「「番号」を用いる情報保有機関は」と（２）のところで限定するとしたら、（３）のところで個人を特定するための識別子として符号、要は「番号」を使わないと書いてあることとの整合性はどう考えるのかというところは気にはなるんです。
私はどちらかというと（２）と（３）をセットで読んでいたので、「番号」で特定する組織もあるんだと。「番号」とは別の個別のサービスに付帯する番号、ＩＤというのが世の中にあって、それとここで言っている符号でマッチングをかける組織があるという、その２種類の組織があるんだということがアーキテクチャの前提になるのであればそれはどこかに書かないといけないし、そこの部分が私の中で気になっている源なんです。
（佐々木座長）いかがですか。
（大山座長代理）
私と山口先生だけで話していては良く無いかもしれませんが、今の指摘はそのとおりと思います。最初の方から読んでいただいた時に、よりわかりやすい文章を書くという観点から明記しようという言い方はわかります。ただ、ここで言っている「番号」は、利用す22

る範囲を限定しています。一方で情報連携基盤としては、将来の発展性についても委員の皆様に納得いただいていると思います。これらのことから、「番号」を使う情報保有機関と使わない情報保有機関があるという前提があるので、このような書き方になっていると思いますが、もしこの１文だけ抜かれて誤解されるのを避けるために明記すべきというのであれば、皆さんの御意見も踏まえて、最終的には事務局、座長と相談させていただきたいと思います。考え方はそれでいいですか。
（山口委員）
一応気になっているところはそこでして、先生が言われる、大体そこです。要はいろい
ろ符号というものはなぜ生まれたかとか、「番号」はなぜ直接個人を特定しないとかと書いてあるのかというところがすべてプライバシーとかいろいろなところに関わってくるので、非常に簡素に書くのはいいのですけれども、誤解されるぐらいならばしっかり書いた方がいいのではないかというように思っているわけです。
（佐々木座長）これはどうするか検討させてください。基本的には情報連携基盤を通じてやるやりとりについては、「番号」だけのものも「番号」以外のものも通すけれども、それは法律に定まったものがそこを通ることができるといったようなことでありますし、情報連携基盤のところにおいて情報のマッチング等の不正はできないような仕組みに今なっていると思っておりますので、その部分についての心配はないだろうと思っております。
あと、「番号」を利用してその「番号」間で不正なマッチングが起こるかどうかという点については、また別途いろいろな防ぐ手段というのを考えているわけでありまして、そこの部分についても情報連携基盤での不正に比べると、先ほど坂本委員からもありましたけ
れども、マッチングの可能性は高いわけですが、全体としてはかなり低いところにおさえられるだろうと思っているので大きな問題点はないのではないかと私は思っているということでございます。よろしゅうございますか。では、この点について書きぶりを少し検討させてください。
ほかの委員の方は、山口委員がおっしゃったような形での修文をしていくということについてよろしゅうございますか。特に問題はございませんか。よろしいですか。では、そういうことで検討します。
あとは何かございますか。
（崎村委員）
１６ページの「（３）マイ・ポータルにログインするための認証」というところで、公的
個人認証サービスが提供する認証用証明書を使用するとなっているのですが、後段でユーザビリティの話でその他も検討するような話があるので、これは「当初は」とかというよ
うに限定句を入れた方がよろしいのではないかと思います。

23

（佐々木座長）
少し聞こえにくかったのですが。
（崎村委員）
ごめんなさい。（３）のマイ・ポータルに対するログインで、公的個人認証サービスが提供する認証用電子証明書を使用するとかなり具体的に書いてあるですが、後段でユーザビ
リティを考えるとその他の仕組みもとかいろいろあるので、これだけに限定するのではな
くて、多少遊びを持たせてやる。例えば当初はこうするとか、「等」と入れるとか、そういう形にされた方が全体的な整合性という点でもよろしいのではないかと思います。
（佐々木座長）今の御意見についていかがでしょうか。修文、「等」を入れるという。
（大山座長代理）済みません。「当初」と入れると、後ではやめるという解釈になり得るので、それは避けるべきと考えます。ですから、そこの修文の仕方については、ここに書いてある趣旨を残す必要があるので、私の意見としては「当初」ではなく別の言葉の方が良いのではないかと思いますが、それはどうですか。
（崎村委員）
私が今「当初は」と言ったのは、後でやめるという意味ではなくて、後から追加できる
ようにという意味でございますので。
（大山座長代理）
その趣旨であれば座長と相談させていただきたいと思います。
（佐々木座長）では少し言葉を。何々からとか、あるいはそういう言葉。いかがでしょう。よろしいですか。それについてはそういうことで少し検討させていただきます。
あと何かございますか。どうぞ。
（小松委員）
これは意見なんですが、例えば１１ページの「４．アクセス記録について」に、自己情報のコントロールという言葉が。
（佐々木座長）何ページですか。

24

（小松委員）１１ページの「４．アクセス記録について」の一番頭に自己情報のコントロールという言葉があり、１５ページのマイ・ポータルの基本的な考え方に、国民が自己情報をコントロールできる社会の実現に資するものであるというような表現があるのですが、今回の情報連携基盤とマイ・ポータルを使って、今後国民が自己情報をコントロールできる社会のための最初のステップだとは思うのですが、まだまだ例えば情報に対して国民からの積極的な制御ができるようなシステムではまだないということですので、これは書き過ぎではないかなと実は思っています。
自己情報をコントロールできる社会の実現がファーストステップであるというのが私の意見でありまして、本来の自己情報のコントロールというのは、更にいろんな制御ができるようなもので、そういう国民へのサービス提供も必要なのではないかと意見が委員の中からもありましたので、少しここはわかるのですが、飛び過ぎているなと思います。これは意見ですので、修文を要請しているわけではありません。
以上です。
（佐々木座長）よろしいですか。あと何かございますか。
それでは、もし無いようでしたら、今、お話があった点について少し検討させていただ
きたいと思います。その上で基本的に御意見のあった委員の方とやりとりさせていただいた上で最終的に私に一任させていただければと思いますけれども、いかがでしょうか。具体的に委員の皆様にはどういう形で開示していくかということについては別途連絡させていただきますけれども、文章については今の趣旨を反映するような形で御一任させていた
だきたいと思いますが、よろしゅうございますか。
（「異議なし」と声あり）（佐々木座長）どうもありがとうございました。それでは、今後のＷＧにおいていろいろまだ議論することはあるかと思いますが、今回はＷＧの中間とりまとめとしてこういう形でまとめさせていただきたいと思っております。よろしくお願いいたします。
それでは、少し時間が早いですけれども、終わりに峰崎参与の方から御挨拶をお願いしたいと思います。
（峰崎参与）
本日も大変お忙しいところ、ありがとうございました。先ほど来ずっとお聞きしており
まして、最初の中間とりまとめ（案）を提起するときにも今後検討しなければいけない課
題がたくさんあるということを我々も提示しているわけでありますが、改めて今日も議論の中で論点もまた多岐にわたって出てきているなと思っています。

25

概念設計から基本設計から詳細設計と、ここから先、最終的にどういう形で展開するかに当たって、この情報連携基盤技術ＷＧの皆さん方にはまだまだお願いしなければいけないことがたくさん出てくるだろうと思います。そのときにまた体制その他もいろいろと座長の方から相談させていただきたいと思いますけれども、本当にこれからとりあえず中間とりまとめ、今、座長一任をいただきましたので、中間とりまとめをいただいて、更にまたこれからの課題を我々としても整理していきたいと思っております。
いずれにせよ「大綱」が一応でき上がっておりまして、今、パブリック・コメントにかかっておりますので、法案に向けての作業もこの夏過ぎて以降、秋に向けて展開をしていきたいと思っておりますが、余り拙速に走って失敗することの無いようにというのを我々は頭の中に入れておりますので、是非これからもＷＧの皆さん方の御指導をいただいて、きちんとした番号制度を入れられるよう頑張っていきたいと思います。
本日はどうもありがとうございました。
（佐々木座長）どうもありがとうございました。それでは、最後に事務局から連絡事項をお願いいたします。
（瓜生企画官）事務局でございます。次回のＷＧにつきましては、別途事務局より御連絡させていただ
きますので、よろしくお願いいたします。以上でございます。
（佐々木座長）どうもありがとうございました。本日は長時間にわたり御審議いただき、また活発な御意見をいただきましてありがとうございました。
以上をもちまして、第７回情報連携基盤技術ＷＧを閉会いたします。どうもありがとうございました。

以上

26