第三回官民連携ポータル検討会
日時：平成１７年７月５日 １３：３０～
場所：総務省 合同庁舎２号館 共用会議室１
会議次第
１． 開会
２． 前回議事録確認
・第２回検討会議事録について確認。委員より表現補足の指摘部分を修正して承認。
３． 個人認証のあり方（資料３）
■質疑および主な意見
○官民連携ポータルは主体が民である場合には公的個人認証の民間利用認証が制限されている。主体が官である場合ポータルが公的個人認証をして情報を民間に送信する事は可能か。
→官民連携ポータルの主体が官の場合、あるいは民間事業者でも、、行政サイドからの委託を受けている場合はその範囲内では使える。本人であることをの電子証明書での有効確認した情報を他多目的に利用するのを制限する法律上の規定があるので、民間が他多目的に利用するのは現行法上では厳しい。公的個人認証法上の整理が必要である。
○民間が確認したは電子証明書をは使えないるのか。
→電子証明書の有効性の問い合わせは認証局の失効リストに当たらなければならない。公的個人認証の法律上は有効性の確認を失効リストにアクセスせずに電子証明書だけを見て本人かどうか確認するという使い方は想定されていない。通常の用途としては電子証明書を受け取ったら有効かどうか確認する。しかし例えば、運転免許証は、本来は運転できる資格があるという証明書だが、実質本人確認書類としていろいろな目的に使われている。公的個人認証も法律的には想定にない、いろいろな使い方があるなされるのかもしれない。整理する必要がある。
○ID、パスワードによる利用者認証は、実態としては、メールアドレスをいくらでも作れるので、厳密な本人確認は出来ない。本人確認が出来ていると見なしているのが現実では相当ある。（１）の④をやったとしても本人確認の厳格さ厳密性が上がる事にはならない。パスワード発行方式が①以外ではシステム上の負担が相当大変になると思われる。公的個人認証の普及が進み、使いやすくなれば解決できるのだが、利用が面倒くさく電子証明書をとるのは大変だという声も聞く。リーダライタについても一度取り付けてしまえば、簡単に使えると言った理解が進んでいないのではないか。
○公的個人認証は具体的にどう言った点が使いにくいのか。リーダーライターを買ってきて付けるは面倒くさいということはあるかと思うが、一回セットしてしまえば、ＩＤ、パスワードと変わらない。ＩＤ、パスワードをいろいろなところで共通にセットしているほうがよほど危ない。また逆に、それぞれ異なるパスワードを設定すると、管理の手間がかかってしまう。
○代行者による申請の場合、送信者の本人性確認はパスワードでやっている。申請名義の真証性、本人の意思であるということは電子証明書やICカードを渡すことで、委任状を渡したことと同等と見なされているのか。
→ＩＣカードが住基カードだとすると、他人に住基カードを譲渡したり貸与したりする渡すことは禁止されている。
○現行の制度をまったく無視した言い方でいうと、「実印」と書かれているのは印鑑証明が自治体から出されてるものなので、電子申請では公的個人認証を使うのとほぼ同等で、「本人が必ずしないといけない」というのは現在のテクノロジレベルでいうとID、パスワードではなくて寧ろバイオ的な指紋とか、静脈とかに行った方がテクノロジとアナロジの関連からいえばその方が親しみやすい。
○公的個人認証は印鑑登録証明をとる実印と並べて説明するとわかりやすいが、署名押印の世界で実印がいらなくても、オンライン手続きでは公的個人認証でやらなければいけない場合世界がある。本人の権利義務に関わることなどは、将来的にワンストップとなったときには公的個人認証で確認する必要がある。実印より少し広く公的個人認証でやるべき出来る範囲を考えるべき。
○③と④の違いが良く分からない。③でも本人確認はいるのだろう。本カード確認だけでは足りないだろう。④の代行者と書いてあるのは民事訴訟法２２８条４項でいうところの「本人またはその代理人」という意味の代理人と意味が違うのか。
○代理手続きなどでは、書面をまで代理人が作作成するるのであれば、委任契約などをして本人が電子署名証明書をつけて依頼し、司法書士さんが文書を作成して作って署名をつける。２つ証明書がある電子署名がつく形になる。今回、法律改正に出しているのは、司法書士なりが不動産登記を本人から委任を受けて申請するときは司法書士さん自身の電子証明書でも本人確認しているし、申請者本人の電子証明書でも本人確認している。両者あわせて申請が受理される電子証明という整理になっている。
○③、④で理解したのは下の※にあるが、④のＩＤ、パスワードによる利用者認証はシステムログイン時の話であって手続き自体の本人確認にについて厳格な本人確認が必要であれば公的個人認証でやることとなる。
○ＩＣカードを想定していない。電子署名はＩＣカードの中でしか出来ないから、それが出来る人はカードを持っていて、なおＰＩＮコードを知っている人ということになる。
○本人とカードの結びつきをどのくらい厳密にするか、アプリケーションでいろいろなのでしょうが、カードをイメージして申請を考えると③でもいるのでは。
○ID/パスワードの発行方法の類型化についてだが、この資料によると、検討結果、①を選択するということになっているが、どういう経緯で作られた資料なのか。
→東京電子自治体共同運営サービス提供委託の際の仕様書として書かれている。
○現実的に、①以外の方法でのID/パスワードの発行は実務上不可能であろう。
○手続き時に本人確認を行える場合も多いため、登録はID/パスワードとしているケースも多いのではないか。
○岡山県の場合は、公的個人認証の場合は結果的にシステムログイン時にＩＤ、パスワードが申請時に必要になる。ＩＤ、パスワードもやり、申請行為をやったあとに個人認証のところで公的個人認証を活用する形ですので③か④のどちらかでしかないという点では３パターンになっている。
○資料だけだと分かり辛いところがあるので少し具体的に調べて見る必要がある。
４． 官民連携主体における個人情報保護のあり方（資料４）
■質疑および主な意見
○関西引越しサービスでは個人情報保護法１５条でいう利用目的を書いていないのは蓄積保管しないので書いていないという理解でいいのか。
→一時的にしても保管しているので、同意を得るようなポリシーを文書で表していることで担保している。蓄積し漏洩した時の責任がとれないので蓄積しない方法を取っている。
○個人情報保護法第15条では、個人情報の利用目的をできる限り特定しなくてはならない、としている。どの程度特定しなくてはならないかについては、様々な議論の余地がある。一時的な保管の場合にも利用に該当するのか、整理が必要だろう。
○ポータルの後ろにある個々の事業者毎には、それぞれに認証の目的が異なっている。これらのポリシーをポータルとしてはそれぞれ見せている。個別のものとして取り扱うということで、ポータルには一時的に情報が流れることを理解頂いている。個々に相手方の責任が見えることが大事なのかと思う。経営の責任もあるが個人情報を取り扱う際の責任がとれるかも大きな課題になる。
○東京ガスの事例は個人情報保護法23条４項の３号の共同利用の要件を満たしている。後から関連会社が増える場合などの取り扱いについては、明示が必要。
○官民連携ポータルの参加事業者が途中で増えた場合に、個人情報の利用が行えるように事前承諾をすることができるのか。後から加わった事業者はそれ以前に収集されている情報を使わない仕組みが必要か。
→共同利用にすれば第三者に当たらないというのが共同利用の考え方だ。共同利用する範囲などを定めて、どことどこが共同利用するかを明確にする。同意はいらなくなるが、他の所まで共同利用するのは問題ではないかという議論が生じてくる可能性はある。
○官民連携の場合になると、対象が官と民で個人情報保護法の内容が少しずつ違うので、どのように個人情報の取り扱い面で調整していくのか議論が必要。民間同士の場合は共同利用を行えるが、公的機関間の共同利用というのは、この法律では想定していない。民間で作った場合には、自治体が自治体に対して提供するのは第三者提供になる。同意を得るようにする手続きが必要になる。
○公的機関同士で個人情報のやりとりができるかについても課題となっている。例えば、警察と教育委員会で情報連携ができるか、といった議論がされている。最初に集める時の利用目的が何だったかによりかなり制約を受ける。社会的に明示していかなければならない。
○官民連携ポータルで新しいサービスを追加したときも最初に登録したサービス内容以外に使ってはいけないということになるのか。
→最初に明示した利用目的の範囲を超えては使えない。合理的な相手の変更は可能になるが、解釈上の問題はある。
○官民連携ポータルで、ポータル側に溜まった情報を共同利用するパターンは想定できない。利用者の側からトリガーを掛けて各方面に送るというのはあるが、溜まった情報を事業者の方から取りにくるケースはなく、共同利用に該当しないのではないか。
○送られた各事業者の方で個人情報保護のポリシーに従って進め、虚偽の書き換えがあった場合とか捜査の手が及んだ時とか、特殊なケースの場合について規制すれば良い。
○個人情報のオーナが個人だから、その個人が選択したサービスの範囲で提供するという考え方で、新しくまたできたものが便利なら利用しようと選択する。選んでいない場合には、個人情報を利用しないことが民間の利用の基本的な原則。公の場合は必ずしもそうではないので、混在しているときの整理は必要。
○ポータルの提供事業者としては、その人が住んでいるか問い直すことは想定せずに、最初のワンプッシュでそこの情報が得られればポータルとしては情報が満たされているということか。
→ポータルとしては、最初のワンプッシュだけで良い。本当に住んでいるかといったことは、日々の業務で確認できることも多い。
○ポータルにいろんな民間事業者が入ることを想定したとき、各事業者に最初に一回入ってくるところで確認すればいいのか。そこは割り切りで再確認しない整理で良いのか。
○利用者がポータルに持つ興味を考えると事前事後の情報提供がこのビジネスモデルの基本にあるのでは。
○同意が明示でいいのか黙示で良いのかはあるが本人がクリックすれば明示の同意と解釈をしてできるだけポータルが広まる仕組みを検討しないといけない。
○同意の確認方法だが、クリックによる明示的な選択ではなく、予め「同意」が標準で選択済みでとなっていて、全体一括で１クリック押せすれば良い仕組みでも良いのか。
→包括的に同意を得る方法では、問題と指摘される可能性もある。具体的に名称を表示する方法が望ましい。明示か黙示かという点についても、明示が望ましい。
○ポータルに個人情報が蓄積される場合、消去についてはどのように規定すれば良いか。
→○自分の情報がどうなっているか、開示を求めることはできる。取得で問題があれば消去を求められる。23条の2項にオプトアウト制度があるが、自分の情報は他に提供しないで欲しいという本人の要望に応じて第三者への提供を停止することを前提としている。
○例えば、最初ある事業者への情報提供を承諾したが、情報提供を停止したいとなった場合に、本人が個々の事業者に連絡するしなければならないのか。ポータルに連絡すると、ポータルのほうサイトでそれぞれ個々の事業者に止めてくれ、というようなオブリゲーションを負うのか。どういう整理になるのか。
→日本通販協会などでの、Mail Preference Serviceでは通販協会に申し出るとそこの会員については全部ストップするようにするやりかたの慣行がある。利用停止もポータルの主催者に一回そういう通知をすれば個々のところも止まる仕組みにしたほうが良い。あまり複雑にすると大変だがいろいろな方法が考えられる。
５． 官民連携ポータルにおけるデータセットについて（資料５）
・資料５に基づき事務局から説明後に質疑を行う。
■質疑および主な意見
○「GPPデータセット」は「申請データ設計ガイドライン」や「様式の設計ガイドライン」に基づいて作られたので、官民連携データセットは「GPPデータセット仕様書」を参照すれば良いという扱いになるのか。また、国ともデータの共通化ができるのか。
→GPPデータセット仕様書は、申請データの中身そのものの定義はされておらず、あくまで管理情報の共通部分だけが定義されている。そのため、「GPPデータセット仕様書」のみを参照して官民連携データセットを策定することはできない。国においても一つの標準にまとめようとする動きはあるので、今後は連携が容易になる。
○「共通化データ項目」と「官民連携データセット」という用語は違う概念で用いられているのか。
→「官民連携データセット」の方が標準的なベースとなって、そこに共通的な項目が含まれるのであれば、それを大元として各データセットと対応関係を作っていくというのが一番理想的な考え方だと思う。共通的なデータ項目があって官民連携データセットもひとつの対象となるデータセットになるのかは議論の余地がある。共通化データ項目候補として、引越れんらく帳や関西引越し手続きサービスで用いられているデータ項目を挙げている。
○９ページの「データセット対応表の利用イメージ」だが、ポータル事業者は、システム設計の際に、データセット対応表を参照するのか。
→現状は、システム設計の段階のものとなる。対応表みたいなものを公開することでシステム設計の支援になる。
○実際に地方公共団体協議会でデータ標準を決めたとしても、バリデータとかのソフトツールでチェックしないと作れないとか、間違って作るなどになる。同じものを参照していても作りが微妙に違うなどから互換がないなどが起こりかねない。ソフトウェアツールなりチュートリアルのようなことをやらないと実際にものを作ると点からは不十分。
○データセット対応表を整備する作業が官側のデータ標準化で行なわれることを前提にこういう作業があれば良いのでは、という理解でいいのか。
→官が行うという理解で良い。
○９ページのデータセット対応表管理者とは誰が行うのか。
→１ページ目にあるスキームのところで関わっているデータ標準化ＷＧとフォーラムや協議会などの標準化組織の両者が関係しなければいけないと思う。
○１ページの標準化組織とは、どういう形態が想定されるのか。
→官民連携データセットの標準を作成したい事業者が集まるイメージ。UN/CEFACTなどとの調整を行う必要は生じるかもしれないが、そのような組織が直接参加することは考えにくい。
○一般論としてデータ項目を細分化で数を増やすということがデータ交換の対象を増やすことに結びつくと考えていいのか。入力側の立場から考えると分ければ分けるほど、それごとに入力していくことになる。
→どこまでが細分化レベルなのか範囲をきめる必要はある。ユーザーインタフェースも細分化される必要がある。
○細かいレベルで標準化が進んでいれば進んでいるほど、後ろで受けたシステムのハンドリングレベルは融通性が高まるが、いろいろなシステムがあるので簡単ではない。同じデータの標準化といっても具体的なアプリケーションに近い部分とそうでない全体的な部分がり、方向性としてはそれを見据えて収斂させるようにすることが必要。極めて時間のかかる大変な作業になる。官民連携の間で具体的なアプリケーションで議論の範囲を絞り込んで検討をすることが必要。
６． その他
・資料３、東京電子自治体共同運営サイトの認証方法及びID/パスワード発行方法の例については、記述内容詳細について、事務局で確認を行う。
・第四回検討会は、2005年8月5日（金）13:30～16:00に行う。場所は別途連絡する。
７． 閉会
配布資料
【資料１】会議次第
【資料２】第二回検討会議事録 (42K)
【資料３】認証方法及び官民連携の連携パターンの例 (236K)
【資料４】個人情報の取り扱いに関する記載例 (86K)
【資料５】官民連携データセット検討課題の整理 (242K)
以上