本文へ移動

デジタル臨時行政調査会作業部会(第24回)

概要

  • 日時:2023年(令和5年)9月20日(水)13時00分から15時30分まで
  • 場所:オンライン開催
  • 議事次第:
  1. 開会

  2. 議事

    1. 「テクノロジーベースの規制改革」の進捗及び当面の進め方について
    2. デジタルマーケットプレイスについて
    3. 事業者手続サービスタスクフォースについて
    4. AI時代の事故責任の在り方について
    5. ベース・レジストリと制度的課題について
    6. 意見交換
  3. 閉会

資料

議事録等

日時

令和5年9月20日(水)13時00分から15時30分まで

場所

オンライン開催

出席構成員

座長

  • 石川昭政(デジタル副大臣)

構成員

  • 安念潤司(弁護士中央大学大学院法務研究科教授)
  • 稲谷龍彦(京都大学大学院法学研究科教授)
  • 岩村有広(日本経済団体連合会 常務理事)
  • 落合孝文(弁護士渥美坂井法律事務所・外国法共同事業)
  • 上野山勝也(株式会社PKSHA Technology 代表取締役)
  • 増島雅和(弁護士 森・濱田松本法律事務所)

事務局(原田): それでは、お時間となりましたので、始めさせていただきたいと思います。第24回「デジタル臨時行政調査会作業部会」を開会いたします。

今回も、構成員の皆様にはオンラインでご参加をいただいております。

本日の構成員の皆様のご出席状況についてですが、菅原構成員におかれましては、所用によりご欠席、上野山構成員、落合構成員におかれましては、途中ご退席と伺っております。
それでは、議事に入ります前に、新たに副大臣に就任され、本作業部会の座長となる石川昭政副大臣よりご挨拶をいただきたいと思います。副大臣、お願いいたします。

石川デジタル副大臣: 皆さん、こんにちは。先般発足いたしました、第2次岸田第2次改造内閣におきましてデジタル副大臣を拝命しました、本作業部会の座長の石川昭政です。どうぞよろしくお願いいたします。

本日の作業部会では、5つの議題についてご議論いただきます。まず、『「テクノロジーベースの規制改革」の進捗及び当面の進め方』についてであります。近日中にテクノロジーマップ、技術カタログを公表予定であり、技術検証事業についても現場等での検証事業を開始いたします。本日のご議論を踏まえ、利便性、活用可能性の高い情報提供が可能となるよう取組を進めてまいりたいと考えております。

次に、「デジタルマーケットプレイス」についてであります。10月中をめどにサービスカタログサイトの実証を開始し、事業者及び行政職員による利用体験を確認することとしております。本日のご議論を踏まえ、年末までに制度的な整理を進め、来年度、本格的にIT調達に活用される環境整備を進めてまいりたいと考えております。

次に、「事業者手続サービスタスクフォース」についてであります。本日のご議論、今後の各府省の行政手続システムに関する調査等を踏まえて整備計画の策定を進め、事業者向けの行政手続システムの在り方及び体験の整理を進めてまいりたいと考えております。
次に、「AI時代の事故責任の在り方について」であります。自動運転車の実装を見据え、事故責任の在り方について、関係省庁が連携して議論を開始することが重要であり、今後、検討を加速化してまいりたいと考えております。

最後は、「ベース・レジストリと制度的課題について」であります。「新たな情報連携の仕組みの下でのデータガバナンス」、「住所、所在地、建物情報に係る番号制度やベース・レジストリの整備」についてご議論いただきまして、関係機関と密に連携し、年末までにベース・レジストリの整備に係る工程表の検討を進めてまいりたいと思います。

以上です。本日もどうぞよろしくお願いいたします。

事務局(原田): 副大臣、ありがとうございました。

それでは、これより本日の議事に入らせていただきたいと存じます。以降の議事進行につきましては、安念副座長にお願いしたいと存じます。安念副座長、お願いいたします。

安念副座長: 安念でございます。新座長にはこれからいろいろご指導いただくことになりますが、どうぞよろしくお願いいたします。

それでは、まず須賀参事官より、第1の議題「『テクノロジーベースの規制改革』の進捗及び当面の進め方について」、ご説明をお願いしたいと存じます。須賀参事官、お願いします。

事務局(須賀): 早速ですが、「『テクノロジーベースの規制改革』の進捗及び当面の進め方」の資料に従ってご説明をさせていただきたいと思います。

3ページ、本日のご報告の内容です。直近第6回のテクノロジーベースの規制改革推進委員会における議論の内容のご報告でございまして、初めに技術検証の事業を第1弾から3弾に分けて実施しますと申し上げていましたが、全て公募の実施に至りましたので、そのご報告。

そして2つ目が、テクノロジーマップの様式です。縦軸と横軸について前回もご議論いただきましたが、一旦これで進めさせていただきたいという案を決定しましたので、ご報告。

そして3つ目が、マップと併せて技術カタログの整備をしていくときに、サイバーセキュリティー関係の掲載項目を充実させることにいたしましたので、そのご報告。それから、その充実させた項目を基に、今後、順次カタログの公募を進めてまいりますので、どういった類型で進めていくかということのご報告。

そして最後に、コンソーシアムを運営開始しておりまして、そのキックオフイベントとしてのRegTechDayというものも開催したいと思っておりますので、そのご報告をさせていただきます。

6ページ、技術検証事業の類型と公募時期です。大変カラフルな資料になっておりますが、第1弾が赤、第2弾が青、そして第3弾、直近に出しましたのが黄色でございます。全て相乗りをしていただく府省庁の調整も済みまして、類型ごとに検証をまとめて実施していただく事業者の公募というものを8月までに1巡行いました。ありがたいことに大分県も検証に一緒に参加いただくということで、仕様書の細かい詰めも含めてお付き合いをいただいております。

7ページからは、第1弾、2弾、3弾と順に公募に出した類型を復習の意味も兼ねて載せております。技術検証についてはこの後、類型、条項ごとに事業者と規制所管省庁の間で、具体的にどこで何のテクノロジーをどういうふうに検査検証していくかという具体の合意を得まして、随時、検証事業に入ってまいりますので、しばらく水面下に潜ることになりますが、また検証が終わった段階でご報告をさせていただければと思います。

次に、14ページからがテクノロジーマップの話でございます。前回、規制の大きな構造に従って全体を俯瞰できるようなマップ構造にしていきたいとお話ししました。次のページに「規制の基本的な構造」を整理しています。あらゆる規制には規制目的があり、そして何らかの管理対象があります。その管理対象に関するデータを、まず「データ取得主体」が情報として取得し、伝達する。例えば構造物がひび割れていますとか、錆ついていますという情報を取得して伝達する。次に、赤色で示した「判断主体」がその情報を受け取って、この事態は深刻なのかどうかということの確認・判断をする。例えばこのひび割れや錆はこのまま放置をしておくと橋が崩れかねないといった深刻な事態なのかどうか。その判断結果を情報として次の「対応主体」に伝える。この対応主体が具体的に補修に入るとか、現場を立ち入り禁止にするといった対応をしていく。多くの規制がこういう構造になっております。さらに16ページで、条文上の記載率に関しては、今、ご説明した構造を横に置きますと、管理対象と、それに関してどういうデータを取得することを求めているのか、それを誰が深刻かどうか判断することを求めているのか、という辺りがどの規制も記載率が高くなっており、条文から文言上読み取れる、あるいは類推できるようになっているということが分かってまいりました。他方で、その判断をもって誰が何をするのかということについては現場の専門家に委ねられていたりして、条文上そのまま読み取ることが困難だという現状がございます。

以上の規制の構造や状況を踏まえまして、次のページですけれども、まずは管理対象を除きまして、データを取得し、判断し、対処する、対応するというプロセスを横に並べてテクノロジーマップの横軸にしてまいりたいということを前回ご報告しました。

さらに18ページで、縦軸は、先ほど省きました管理対象をどんどん分類し、その管理対象を管理するために必要なデータ内容で類型化していくと、非常にきれいにいろいろな規制の要素が一覧化できるのではないかという結論に達しております。

修正案の「縦軸パターン1」と書いておりますのが、管理対象と管理に必要なデータ内容を、どういった判断を求めるのかという判断内容にぶら下げて類型化をしていくという形で縦軸を整理した案です。さらに「縦軸パターン2」として、デジ臨が取り組んできた先行7項目のようなアナログ規制のキーワードから規制を探すことができるように、規制類型にひもづけた形で管理対象を分類して整理をするという案も両論併記で維持したほうがいいのではないかということを委員会でご指摘いただきまして、当面、この2つのパターンの縦軸を併存させてマップとして公表してまいりたいと考えております。

19ページですけれども、以上の縦軸と横軸が決まりまして、だいぶ技術は大くくり化していますけれども、対応可能な技術をマッピングしてみますと、大体こんな形になりそうです。現時点で我々が把握しているテクノロジー、RFIで公募して教えていただいたテクノロジーも含めてマッピングをしております。

20ページがパターン2です。縦軸が少し変わり、それによってマッピングの形も少し変わる。公表にあたってデザインやフォーマットを少し変える可能性があるかもしれませんが、テクノロジーマップの初版は今年の夏頃に公表すると申し上げて参りまして、法律に基づいて公表の義務がございますので、このパターン1、2の形でデジ庁のホームページに急ぎアップさせていただければと思っております。

21ページと22ページがより精細なテクノロジーマップになっておりまして、これは細かすぎて紙での一覧性はほぼないので、このままの形でマップとしてお示しをすることは避けたいと思っておりますが、ネット上で情報を取っていただく分にはこういった豊かな生態系がそのまま織り込まれているというのは問題ないと思いますので、ネット上にはこのぐらいの粒度のものを参照いただけるよう上げておきたいと思っております。

以上がテクノロジーマップのお話でございます。次に技術カタログです。

25ページが技術カタログ整備の全体の作業工程です。26ページで、技術カタログの掲載項目は一度確定させ、今にもいろいろな分野でカタログの公募を始めようというところまで来ていたのですが、その時点で、サイバーセキュリティーやサプライチェーンリスクへの対応というのをもう少し踏み込んで検討するべきではないかというご指摘をたくさんいただきました。もともと技術カタログに掲載される製品やサービスの情報については、デジタル庁で全てを確認する能力もリソースもございませんので、少なくとも最低限このサービスが本当に存在するのかという最低限の真偽の確認だけはした上で、速報性を重視しまして、提案いただいたテクノロジーなりサービスはどんどんカタログ掲載し、掲載されたテクノロジーの使用に伴うリスクについてはデジタル庁では責任を負えませんというディスクレーマーを規約に書かせていただくという方針でご相談をしてまいりました。他方、デジ庁のホームページに法定の義務として整備されたテクノロジーマップに関連する情報としてカタログが載りますので、それを信頼してアクセスされる方の存在をある程度は想定するべきだということで、最低限の信頼の確保、提供する情報の充実を図るために、大きく分けて以下の2つの取組を追加で実施することにしたいと思います。

1つ目が、このテクノロジーベースの規制改革推進委員会の中に、技術カタログ運用タスクフォースという場を設けまして、技術カタログの公開の前に一旦このタスクフォースに全体をかけまして、企業から応募していただいた入力情報について様々な確認を行っていただくというプロセスを挟みたいと思います。タスクフォースのメンバーに関しましては、カタログにどうしても載せてほしいという企業の働きかけが過度になったりするリスクもあるかと思いますので、当初、タスクフォースを設置した瞬間には、メンバーを非公開とさせていただきたいと思います。他方で、委員会でのご指摘もふまえ、メンバーの方々がインテグリティーを持ってしっかりとご判断いただいたのだということを後から確認できるようにするためにも、事後にメンバーの公表はさせていただくという形にしたいと思っております。

それから、2つ目に、カタログの入力項目の充実を図ります。サイバーセキュリティーやソフトウエアのサプライチェーンリスクに関しましては、まず個人データその他や営業秘密も含めた取扱いデータの保護に関しまして、データをどこに保管をしますか、暗号化などの対策をしっかりしていますか、それから、何かもめごとが発生した場合の裁判管轄はどうなっていますか、準拠法はどうなっていますかといったことを確認事項として追加させていただきます。

それから、約款上賠償の規定がどうなっていますか。何か損害が生じたときに、我々は日本に拠点がないのでと言って逃げてしまうようなことがないか、あるいは担保的な責任財産を持っている会社なのかというような、リスクが万が一発現した場合の対応についても一覧性を持って整理をするべきだということで追加をさせていただきます。

ソフトウエアのサプライチェーンリスクについても、ソフトウエアの特性、クリティカルなソフトウエアなのかどうかとかいうことも含めて確認する項目を追加したいと思います。

27ページからが、細かくなりますけれども、具体的に追加させていただく項目の考え方でございまして、基本的な方針は、何も特殊なクリエイティブなことはしない。グローバルの、あるいは日本の最先端の方々がまとめておられる最新の英知をそのまま引用し、他方で、応募者の入力のしやすさということも重要ですので、このぐらいであれば製品を提供されている方もお答えいただけるであろうという必要最低限の項目に絞りました。なるべく網羅性がある形で聞いていくということにしたいと思っておりまして、アメリカのNISTが出している重要なソフトウエアの定義に当たるのか、そこで使用に当たっての留意事項として提示されている基準を守ってくださっているのかどうかということをチェックリスト方式で確認することにしております。

28ページから31ページは、この重要なソフトウエア、クリティカルソフトウエアに当たるのかどうかということの確認の質問が続きます。

そして32ページが、ソフトウエアの検証を11の最低基準に沿ってやっていますかということの質問です。

以上を踏まえまして、33ページですけれども、全体として抜け漏れがないように念のため確認をいたしまして、この質問項目の追加をさせていただきたいと思っております。

以上がソフトウエアのサプライチェーンリスク等に関する追加の対応ということでございまして、それを踏まえて、第2回の技術カタログ公募を始めていきたいと思います。もともと次の公募のために用意をしていた往訪閲覧・縦覧の質問項目に先ほどのセキュリティー上の質問を追加しまして、9月中には公募に出したいと思っております。さらに、往訪閲覧・縦覧に続きまして、技術検証を要しない条項についてはどんどんカタログの先行整備をしていきたいと思っております。35ページの「技術検証が不要な条項」に赤枠をつけておりますけれども、大半は技術検証まで要らないと規制所管省庁もおっしゃっているので、約1万条項のうちの技術検証が要らない約8,600の条項を対象にしまして、カタログの整備を先行的に実施していくことにしています。

36ページですが、カタログの公募に当たりましては、先ほどマップで縦軸と横軸の整理をさせていただきましたが、縦軸の管理対象の分類に合わせて大くくり化をしまして、順次公募に出していくということにしております。

往訪閲覧に続いて第3回で出そうと思っておりますのが、事業場の管理や業務状況の確認を実地調査で行いなさいと言われている規制について、ウェアラブルのデバイスやリアルタイムの通話映像などの共有を使って代替していくというカテゴリ。

それから、経年劣化や安全措置対策の状況などを目視や見張りなどで確認しなさいと言っている規制について、カメラやAIやロボットを使って代替していくようなところ。

それから、広域の屋外の環境について、被害の把握なども含めて、ドローンなどを使って代替していくような部分。これらをまずは次のまとまりとして公募にかけていきたく、カタログの募集項目をつくり始めたいと思っております。

以上、ご説明したカタログ公募類型をマップに置くと大体この辺のテクノロジーをまとめて公募することになりますという整理も掲載していますので、もしご関心があれば見ていただければと思います。

42ページのコンソーシアムの運営開始のところまで参ります。テクノロジーマップとカタログはもちろんデジタル庁で整備していくのですが、それと併せて、関係ステークホルダーに当たる技術保有機関、規制所管省庁、規制対象機関がもっと距離を縮めていただいて、お互いにこういうテクノロジーが出たのだけれども、使えるようにならないか、という会話を有機的にしていただけるようになればと思っております。このRegTechを取り巻く関係者を集めたコンソーシアムというのを緩やかに開始してまいりたいと思っております。

44ページは、コンソーシアムに期待する役割で、その次の45ページで、コンソーシアムは実は、もうひっそりと運営を開始しておりまして、Slackにコミュニティーを開設するという形で8月4日に開始し、ありがたいことに既に登録が100名を超えております。今後、コンソーシアムでの勉強会やイベントを通じて参加者が増えていけばと思っており、最初のキックオフイベントとして、技術を活用したアナログ規制の見直しに関して、今までの進捗もご報告しながら理解を深めていただくということを狙いまして、「RegTechDay」というイベントを2023年10月27日、来月に開催したいと思っております。オンライン開催を予定しております。今、どういう規制をどういうふうに見直そうとしているの、技術検証は具体的にはどうやるの、規制当局の悩みは何なのというようなことを聞いていただけるようなイベントにできたらと思っておりまして、ぜひ作業部会の先生方にもこのイベントにもご協力いただければと思っております。

47ページにコンソーシアムの活動スケジュールに具体的な日程などを入れてアップデートしたものもおつけしております。

以上がコンソーシアムのご報告になりまして、最後に、全体のスケジュールでございます。テクノロジーマップが律速になります。テクノロジーマップというのはデジタル庁が法定の義務として公表していきますので、それに沿って技術カタログをどんどん公募にかけて充実させていく。それから、その裏で技術検証も3期に分けて一つ一つやっていく。その結果が出次第、規制を改革していただき、カタログに対応技術を掲載していくという形になっております。その合間合間で、RegTechの動きについてのご理解を深め、関係者に集まっていただくため、コンソーシアムのイベントをシンポジウムや報告会といった形で企画してまいりたいと思っております。
以上でございます。ありがとうございました。

安念副座長: どうもありがとうございました。

それでは、今のご説明についてご意見、ご質問等がございましたら、どうぞお願いいたします。

須賀参事官、テクノロジーマップのパターン1とパターン2ですけれども、パターン2のほうはどちらかというと法律側に寄ったというか、在来の法令の文言に寄り添った形の仕分けの仕方になりますね。

事務局(須賀): まさにそうです。

安念副座長: パターン1のほうはむしろマシンフレンドリーというか、今はもちろん両論併記しないと、規制側のほうが今までの常識と全然違うことをやられても困ってしまうからそのとおりなのだけれども、やがては法令の書き方のほうを機械に寄せていくというふうになるのではないかと思います。つまり、長期的にはパターン1のほうになっていくという見通しを何となく感じるのですが、須賀参事官はどうお考えですか。

事務局(須賀): それは非常に深いご示唆でございまして、作業部会に法制事務のデジタル化検討チームから随時ご報告しているとおり、最終的には法令自体をマシンリーダブルにしたいとか、法令のアップデートも人力で毎回直さなければいけないという形でないようにしたいという全体の大きな狙いがあるわけですが、テクノロジーマップもその一助になればと思って作っている面があります。そのときに、おっしゃっていただいたように、よりパターン1のほうがぶれないといいますか、規制の条文の文言というのはやってほしいことの一部しか書いていないというのが先ほどの分析結果で分かったことでありますので、本来何をやってほしいのかから分類をするパターン1のほうが、現行規制のキーワード抽出より未来志向で、普遍性、汎用性が高いのかなとは思っております。

安念副座長: ありがとうございました。稲谷構成員、お願いいたします。

稲谷構成員: ありがとうございます。

今、安念先生がおっしゃったこととも関係すると思うのですけれども、規制の構造というか、結局これが何をしてきたのかということについて非常に明確に、前回まとめていただきましたけれども、今回さらに精緻化されていると思います。規制の構造や機能がクリアになっていくというのは、目指すべき方向性として非常に正しい方向に行っていると思います。大変すごい成果であるという率直な感想がまず1点目でございます。

1点のお尋ねと、もう一点はコメントなのですけれども、1点目のお尋ねの点は、できるところから始めていくというのも今回の作業部会全体としても非常に重要なテーマだと思っておりまして、技術検証をやらなくても取りあえず始められるところからどんどん始めていこうというのはまさにいい方向だと思うのですけれども、逆に技術検証が要らないものとして分類されたものの特徴のようなものがもしあるのであれば、それを少し知りたいなと。つまり、あまりリスクが関係しないとか、精度が関係しないとか、どういった特徴があるのかなというのが分からなかったので、その点をお尋ねしたいです。

もう1点のコメントなのですけれども、今日のお話を伺っていても、恐らく将来的には民間のほうからいろいろこういう技術が使えるのではないかというようなことが提案されて、技術検証のやり方もある程度固まっていって、さらにそれがテクノロジーマップ全体に影響して、規制構造全体がどんどん変わっていくというダイナミックなサイクルをきっとご予定されているのだろうと理解しております。

そうすると、まさに今日もあったようなマルチステークホルダーのハブとなるようなところの整備というのが極めて重要になってきますので、ここの整備が始まっているということも大変心強く思いますし、ぜひどんどん進めていただきたいです。また、リスクの問題については、必ずどこかでリスクは生じてしまうと思います。この問題は恐らく今日の別の議題のところとも関係すると思いますけれども、このテクノロジーマップ事業はまさにアジャイルガバナンスを進めていくということにほかならないと私は理解しておりますので、リスクが発現したときに、将来的にどういった責任法の在り方であるとか、責任分配の在り方がテクノロジーマップやテクノロジーカタログの活用を促進するのかといったところについても議論を深めていただけると、責任法制をどうするべきかという論点にもうまく反映できると思います。このように、この事業の促進と責任法制の整備の両面を見ながら進めることによって、全体としてすばらしい形になっていくのかなと思いましたので、その辺りについてもぜひご議論いただければと思ったところでございます。

私からは以上です。

安念副座長: 一通り構成員の皆様にご発言いただいてから、須賀参事官にご回答いただきたいと思います。続いて上野山構成員、お願いいたします。

上野山構成員: ありがとうございます。

非常に進んでいて楽しみだなと思っていますけれども、私はソフトウエア関連で2点ございまして、1点目は、技術カタログのフォーマット定義が結構重要なのかなと思っていまして、もちろんサプライチェーンリスクの項目などは議論されていると思うのですけれども、自由記述でアップロードするのかどうか、こういう項目を入れてくださいというところをうまく設計しておくというのが極めて重要かなと思っています。

なぜかというと、自由記述にすると、過度に魅力的に書いて実際は違うことがあったりしますし、一方で、この項目を入れてくださいというのを厳密にやり過ぎると、入力項目が数百になって誰も入れなくなる。そのため、基本にはつぼをついた適度な粒度の入力項目をうまくカタログ登録時に求めるというのは、今後、非常に重要だとは思っておりまして、ここら辺をどうお考えなのかお伺いしたいです。

事務局(須賀): カタログ掲載項目自体は完全に標準化しております。そこに今回、セキュリティー部分の質問を幾つか追加させていただくというご提案です。

上野山構成員: 比較的項目を定義するということですか。

事務局(須賀): そうですね、イエス・ノーで答えられるようなものを主体としつつ、自由記述の欄も幾つかあります。

上野山構成員: 基本的には多くなり過ぎないように項目を決めるということですね。

事務局(須賀): はい。自由記述も一部残したいのですが、なるべくそこがなくても判断できるような形にしたいと思っています。類型化標準化して比較可能性を上げるとともに、任意記載の項目というのもある程度広めに取って、それによって全部埋めないと出せないとハードルを上げ過ぎない配慮もしましょうということです。

上野山構成員: なるほど。そうすると、問題ないかもしれないですね。

2個目は、そういう対応をされているのであればあまりはまらないかもしれないですけれども、その問題を解決するアイデアを思いついたので共有しますということなのですが、自由記述欄は結構いろいろあるではないですか。いきなりAIの話になって恐縮なのですけれども、生成AIはそういう自由記述からエンティティー抽出といって、例えばその中の項目を抜き出すのが非常に得意なのですね。なので、そういうものを結構簡単につくれてしまうので、その入力時に非常に自由度を持たせながら、手間もかけないで、でも、それに対して生成AIが一回走って構造化しますという処理を入れると、入力もしやすくなるし、ユーザーにもフレンドリーだし、かつ、一回デジ臨で生成AIを使った事例をつくりたいとおっしゃられていたので、いきなり世界最先端事例にもなるなと思って、思いつきですけれども、ご共有です。

安念副座長: 四角はいっぱいあるのだけれども、チェックするかしないか、という記入の仕方をしていけばいいのですね。ありがとうございました。

それでは、落合先生、お願いいたします。

落合構成員: 毎回拝見するたびに一層すごい内容になっているので、デジタル万里の長城みたいなものに次第になってきているのではないかと思っておりました。ただ、これは見読性や構造化という点でもしっかり配慮して進められていると思いますので、アナログの積み上げとは全然違う形になっていくのだろうなと思っておりました。

非常にすばらしいものになってきていると思いますが、さらに今後どういうふうにしていくのかという意味では、いろいろな制度で最初に立ち上げるときは非常に熱があっても、アップデートされていくと、何となく良くも悪くも流れ作業になっていくことがあると思います。ぜひどういう形でうまく制度として熱を持って回していけるようにするのか、いいものをせっかくつくっていただいたと思っていますので、そこが本当に大事な点になってくると思っておりました。

もう一点、データやAIの関係も、先ほど上野山さんもおっしゃられておりましたが、ある種のベース・レジストリというべきかはともかくとして、国のベースになるような情報資産であると思います。そこがデータ戦略だったり、データの存在に対するマッピングともつながっていると、デジタル臨調でのいろいろな取組が融合していくことにもつながっていくと思います。結果的にそういうものが出来上がっていると、海外から見てもきっちり整備をしているのではないかという話になってくると思います。もしかすると、DFFTなどでIAPなどの中身の一つに、日本から持っていけるようなネタにもなってくるのではないかと思いました。そういう意味でデータとの接合をつくっておくと、国際議論でも我々の成果の中で持っていけるものが1つできるかと思います。

また、DFFTとの関係で広島AIプロセスというのも行っていて、AI側もルール整備というか、ガイドライン整備をしっかり行いましょうという話になっているかと思います。特にパターン2のプロセスの判断機能などでの配慮している内容との関係でも、国全体でガイダンスを定めてそれを使っていることも分かるようになっていくと良いように思います。全体のデジタル戦略をしっかり整備することにつながっていくと思いますし、実際、AIのガイダンス自体は強制的なものでないとしても、気をつけて使ってもらうべき内容をまとめていこうとしていると思いますので、私も総務省側のほうで検討に参加していますが、そういう性質を持っていると思いますので、その辺りも連携できると良いかと思いました。

他方で、後段のくだりはいろいろ既に走っているものがあるので、できるだけ出来上がったものを生かしながら、いろいろな議論との連携を考えていただいて、最小限でうまく利用できるようにしていただいたり、接合を考えていただければと思いました。
以上です。

安念副座長: ありがとうございました。岩村構成員、お願いいたします。

岩村構成員: ありがとうございます。

今日の資料の19ページや20ページを見て、可視化されてくると全体像が非常に分かりやすくなると感じました。企業の現場では人数が足りないという声が結構出ており、他方で労働時間もしっかり守らなくてはなりません。そこで、機械や技術で代替できる部分はきちんと全体的に実装を進めていただきたくご期待申し上げます。また、規制の趣旨を果たすために技術を活用することで生まれる新たな市場もあると思いますので、ぜひこの取組を前に進めていただきたいと思います。

スタートアップの観点から2つ質問をさせていただきたいのですけれども、まず、1回目の公募に対するスタートアップからの応募数と、協力してもらったスタートアップへのその後の対応を教えていただきたいと思います。スタートアップから、その後デジタル庁からのリアクションがないといった声を聞いたため、その点を教えていただければと思います。

2点目は、スタートアップが提出した情報の取扱いについてのお伺いです。カタログに自社製品やサービスを掲載するには、セキュリティー情報も含めてゼロベースでまた提出し直すという手続が必要なのでしょうか。既にいろいろ提供している情報もあると思うのですが、同じ情報の提出を今後再び要求するということでしょうか。この2点を教えていただければと思います。

安念副座長: どうもありがとうございました。

それでは、須賀参事官、ご質問を中心にご回答いただければありがたいです。

事務局(須賀): たくさんご関心を持っていただいてありがとうございます。
まず、稲谷先生から検証不要なものにはどういう特徴があったかということですが、35ページに戻りますと、検証が一切不要な類型というのは実はほとんどないのですね。よく見ますと、天候情報などの幾つかだけ左側の2つの欄が白くなっていまして、抽象化すると、情報としては重要かもしれませんけれども、直ちに人命に関係しないものが多そうだなと思います。

逆に言うと、このデータの類型の中で検証が要る・要らないというさじ加減のが読みにくいと言いますか、この情報については重要なので、あるいは難しいので必ず検証しなくてはいけない、という法則はなかなかこのデータの類型に沿っては見出しにくいなと思ってこの表を私も見ておりました。

アジャイルガバナンスにつなげるべきというのはおっしゃるとおりだと思います。

上野山先生から、カタログのフォーマットについて、AIでエンティティー抽出をというアイデアは本当に面白いです。我々の悩みは、先ほどのセキュリティーリスクについての質問も含め、どんどん質問項目を増やしたくなるのですけれども、それはフォーマットを埋めていただく方からすると負担であります。特にスタートアップの方などは勝手に必要事項を読み取ってカタログを作ってと思われるかなと思っていましたので、前回も上野山先生にネクストマイルストーンを教えていただいたと思いますが、そういったことを視野に進化していけたらなと思います。

それから落合先生からは、どうやって熱量を持って回していくのですかということをおっしゃっていただいて、我々も重要だと思っています。カタログやマップは何のために作っているかというと、それを見て実際に新たに規制がアンロックされた領域で技術を使っていただく、調達までつなげていただくということをぜひ実現したいので、こつこつとその実績をまずは出していく。意外とこのカタログ使えたとか、マップで知らなかった技術領域を知れたといった体験を規制所管省庁の側でも増やしていけたらなと思っております。

それから、規制を抽象化して全数整理してみて初めて、結局は全部データなのだなということが良くも悪くも分かりまして、マップの縦軸がデータのラベリングになっていると思います。何らかの安全を守ろうとしたときに、何についてどういう情報を取得することによってそれを確認できるとされているのかというファクトの一覧になっているとも言えますので、こういったマップを情報資産としてどういうふうに今後使っていくのか、例えば規制をより合理化するといった次のステップにどういうふうに進んでいくのかという点を意識して検討を深めていきたいなと思っております。

岩村構成員からスタートアップについてご質問いただきました。すみません、リアクションが足りていない部分が大いにあると思います。というのも、我々はこれまで公募をたくさん出させていただいておりまして、そもそもどういう技術領域がありますかということでRFIも出させていただきましたし、カタログを先行公募しますということで試験・講習のデジタル完結の公募もさせていただきました。結果は今、デジ庁ホームページに暫定版カタログとして載せていますが、それが必ずしも調達に繋がっていない可能性も高いと思います。今後重点的に、リアクションだと応募された方が思っていただけるようなことをしっかりやってまいりたいですし、その間を埋めるように、今、何をやっているのかということについて、RegTechコンソーシアムを通じても皆様と接点を増やしていけたらなと思っております。

岩村構成員からの、スタートアップがもう一回全部最初から手続をやり直さなくてはいけないのかというご指摘については、どの手続のことをおっしゃっていただいているかによるのですけれども、なるべくいただいたカタログの情報などは生かしていきたく、今回、セキュリティーのリスクを追加させていただいたところだけ講習・試験についてはもう一回追加でお伺いすると思いますが、総じて既にいただいたものをなるべく生かしていきたいとは思っております。

安念副座長: ありがとうございました。

続いて、議題の第2です。「デジタルマーケットプレイスについて」、吉田企画官からのご説明をいただきます。

吉田企画官: 企画官の吉田でございます。

こちらのデジタルマーケットプレイスでございますが、公共調達の仕組み、調達方法を新しく導入しようという取組でございます。従来、2ページ左側の図のように、我々公共機関がシステム調達する際には、どちらかというとテーラーメイドでのシステム調達というものが多かったというところでございます。こちらがいわゆる調達仕様書を作って、そちらに対して様々な会社から提案と価格の入札を入れていただくというこの2つを総合的に評価して調達するということを行ってまいりました。

こちらだと非常に時間がかかり、まさに行政機関もそれに提案する企業にとっても非常に手間がかかるものになっていまして、長いと半年近く調達の手続だけでかかるというケースもございます。

こういったところの中で、一方で、現在ではクラウドサービスを活用したソフトウエアサービスを中心として、利用目的がある程度決まったパッケージのSaaSというものが多くございますので、そういったものをカタログ化してウェブサイトに載せ、その中から行政機関が調達仕様に合ったものを選んで調達できるという仕組みにすれば、この調達の手間という部分で言いますと、行政機関も企業側も減りますし、さらにこのマーケットプレイスのカタログサイトに掲載されることによって透明性が高い形で選ばれることになるのではないか。そうすることによって、ある意味中小ベンダーの方々やスタートアップといった新規参入者も増えるのではないかと考えて、こういった取組を進めようとしているというところでございます。

3ページですが、何か日本で独自に新たに考えたというよりは、UKでは既に2014年から始まってございまして、UKでもともとは2009年時点では18社が調達の8割を占めるというある程度寡占的なマーケットだったところが、こちらのデジタルマーケットプレイスを導入することによって、登録ベンダーの9割以上が地方も含めた中小スタートアップになりました。調達金額ベースで見た場合も、2021年で見ますと4割近くがこういったプレイヤーになったというところでございます。この下の地図でございますが、実は左側も小さく黄色でプロットされているのですけれども、これが実際の調達に参加しているベンダーの数でして、右側の2018年の図を見ていただくと、地方から様々な地域に登録されているベンダーが分布していることが分かるかと思います。こういった形で参入されるベンダーさんを拡大していこうというところにも資するのではないかと考えております。

我々がこれを日本としてどういうふうに導入していくかということで、昨年いっぱいワークショップ等を行いまして検討を進めてまいりました。こちらのワークショップの中では、中央官庁だけではなく自治体の方であったり、ベンダーについても大手だけではなくて外資のクラウドベンダー、中小スタートアップなど、様々なステークホルダーの方々に入っていただいてワークショップを行いました。昨年度末に報告書をまとめさせていただきまして、そちらにも今後のデジタルマーケットプレイスの取組を位置づけているということでございます。

今回、このデジタルマーケットプレイスで調達の対象と考えておりますのが、先ほど来申し上げているクラウドソフトウエア、SaaSでございます。こちらのSaaSについても、直販で販売している場合だけではなくて、パートナー企業様などを通して導入支援も含めた形で販売会社が販売しているケースが多いので、こちらの両方を調達できるような仕組みを考えているところでございます。

実際の調達のプロセスというところでございますが、まずソフトウエア会社、販売会社様と我々デジタル庁のほうで基本契約、これはフレームワークアグリーメントと申し上げますけれども、そういったものを結びまして、実際の調達に足る資格をちゃんと持っているかというところをチェックさせていただくということでございます。その上で、各社様にサービスをカタログサイトに登録していただくという形を考えております。こちらの登録されたサービスの内容を、今度は行政機関が検索をかけます。自分たちの調達仕様に合わせてサービスの仕様を検索で絞り込んでいただくということをしまして、その中で絞り込んだものを個別契約という形で契約するというところになっております。

こちらの検索も、無作為に検索して、適当な検索結果で調達できるとなると、調達の公平性みたいなものを害しますので、この検索でどういう条件で絞り込んでどういった形でその検査結果が出てきたのかというところをエビデンスとしてつけていただくことでここの公平性を担保するということを考えてございます。

実際の検索としては、まずソフトウエアを検索していただくという形になります。こちらは我々デジタル庁の中でも防災DXやデジタル田園都市などの様々な政策軸で取組を行っていまして、それに応じて自治体などが利用するSaaSも出てきておりますので、そういった政策タグと、あとはそれをどういった目的で使うのかというソフトウエアの機能のタグというものを選んでいただくというところです。その上で、このほかにも我々がシステム調達をする際に、セキュリティーの認証であったり、どういった形のサポートを行っているかとか、SLAはどうかといった細かいチェック項目がございますので、こういったものについてもチェックボックスでチェックしていただくという形になります。

加えて、そこでソフトウエアが絞り込まれたら、直販でやっている場合もございますし、逆に販売会社が販売している場合もございますので、そういった方々が提供しているサービスなども見て、またどこから買うかということを絞り込んでいただくという、ソフトウエアと販売先の2段階の絞り込みを行うという形になります。

こういった形でデジタルマーケットプレイスを導入することによって、効果の部分は先ほど申し上げたとおりでございますが、行政側にとってもITベンダー側にとっても調達の手間というところが少なくなるということだと思っております。

加えて、透明性が高くなるというところの中で、中小スタートアップの方々も参入しやすくなるということがございますし、我々は先ほど申し上げたとおり、どちらかというとテーラーメイドで行政基幹システムをつくることが多かったのが、SaaSであればそのまますぐに導入できるというところもメリットになってくるかと思います。

今後のスケジュールでございますが、10月中旬に、まずこのデジタルマーケットプレイスのα版の実証サイトというところをオープンさせていただきます。この段階では、まず事業者の方々にサービスを登録していただくというところをやろうと考えてございます。その後、ある程度サービスが入ってきた段階で、11月頃に一般、行政機関向けのサイトをフルオープンするという形でございます。12月にこれを踏まえてユーザーテストを実施して、そこのフィードバックを来年度のカタログサイト改修に生かしていこうと考えています。

また、これを進めるに当たっては、会計制度上、先ほど言った検索して選ぶというところで調達していくということがどう整理できるかということを財務省と整理する必要がございますので、こちらについて、年末をめどにまず方向性を整理していきたいと考えてございます。

その上で、これは国だけではなくて自治体にも使っていただきたいと考えてございますので、総務省ともそこの制度解釈について今後整理していきたいと考えております。さらに、こういった制度的な整理とカタログサイトの実証を踏まえた改修というところを進めた上で、来年度後半ぐらいから、これを活用した調達というものをできるようにしていきたいと考えてございます。

取り急ぎ、以上になります。

安念副座長: どうもありがとうございました。

それでは、ただいまのご説明について、ご質問、ご意見がありましたら、どうぞお願いいたします。

岩村構成員、お願いいたします。

岩村構成員: ありがとうございます。

DMPのカタログサイトにサービス情報を載せることで、省庁としてはいろいろな情報の共有を通じて高水準なサービスの効率的な調達につながるため、期待申し上げております。

他方で、DMPにアクセスする民間の立場からは、ぜひスタートアップにも門戸を開いていただきたいと考えております。スタートアップの公共調達での活用は政府の5か年計画に盛り込まれており、ぜひそういったエンジンをかけてもらいたいと思います。

J-StartupやJ-Startup地域版に対する加点評価や、テクノロジーマップに掲載された技術の積極採用も並行して取り組んでいただきますよう、よろしくお願いいたします。

安念副座長: ありがとうございました。稲谷構成員、お願いいたします。

稲谷構成員: よろしくお願いいたします。大変分かりやすいご説明をありがとうございました。UKのほうで非常にうまくやられて、非常に活況を呈しているようですので、我が国でもうまくやると非常にいい方向に行くのだろうなと思いました。

私の方からは、もう既にお考えだとは思うのですけれども、調達のプロセスに関してコメントないしご質問をさせていただきます。ご説明を踏まえると、事業者検索の際に用いられるタグがどの粒度で引っかかるのかによって、これがうまく機能するかどうかというのは結構左右されるのかなと感じました。とりわけ、結局特定のタグをつけると特定のところしか引っかかりませんといった話になってくると、かえって調達の公平性みたいなところにも問題が生じてくる可能性があるような気がしていますので、うまく競争状態を維持するためのタグのつけ方というのがどんな感じなのかというのはぜひいろいろと試していかれながら調整されていかれるといいのかなと思ったのが一点です。

もう一点は、恐らくUKでも似たような話がどこかであったのかなと思うのです。そのときに、UKのほうで例えば競争法であるとか、あるいは収賄などにも関係しますので、刑事法もそうかもしれませんけれども、そういった法分野において、この調達に関してどういった議論がなされたのかなというのは若干関心があるところですので、もしご存じでしたら、その点についてご教示いただければと思いました。

以上でございます。

安念副座長: ありがとうございました。構成員の皆様にご発言を一通りいただいてからお返しをいただきます。

増島先生、お願いいたします。

増島構成員: ありがとうございます。
システムのほうは、全体のイテラティブな形でまずα版という形から始めて本番に行くということなので、システム側のテストというのはある程度できるのかなという感じがしています。外部のプレイヤーとの関係で生じるリスクをコントロールするときには、システムと契約で抑えるという形になっていて、フレームワークアグリーメントというのは日本でも建設などで少しやっている実績があるというのは聞いておりますけれども、IT調達などではあまりまだやったことがないかもしれません。どんな項目をどういう条件で定めていったらいいのかは、本当はシステムと同様、一定イテレーションが必要なのだろうなという感じがしています。もしかするとUKの例などを見せてもらって、UKの条文などをまねるところからスタートすると、ある程度ノウハウを吸収したところからできるので、契約にまつわるリスクをコントロールできたりするのかなという感じがしましたが、いずれにしてもイテレーションのプロセスの中にシステムの話と契約上の条文の話の両方があるというところは考えていただくのがいいと思います。

個別契約については、たとえばSaaSであれば、もうシステムが決まってしまっているので、それに応じた利用規約が存在しているということになるのだと思います。その利用規約に合意するということになるのではないかと思う反面で、要請としては政府などの公共団体に提供するということを前提に、何か上乗せをされた合意みたいなものがあって、それをもってまた個別契約という言い方をしているのだというイメージを持ったらいいのだろうかという点が質問です。政府がこれやれあれやれみたいな話だと、SaaSということと全く合わないので、この辺のイメージ感を教えていただくというのは、スタートアップなどの人たちに実際にプロダクトを出してもらいやすくするために大事かなと思いましたので、お尋ねする次第です。

以上です。

安念副座長: ありがとうございました。

落合構成員、お願いいたします。

落合構成員: ありがとうございます。こちらのほうも順調に進んできておりまして、ぜひ進めていただきたいと思っております。

何点かコメントですが、今の増島先生がおっしゃっていただいた契約の点は、事業者側がふだん使っているものを使えるようにすることが重要でないかということは、公取のほうで検討していたときもそういう話があったと思っておりました。そこはSaaSの場合に政府であるからといって特別な対応をするということですと、では売らなくてもいいやということになりかねないこともあると思います。そこはぜひ受け入れていただく一方で、最低限これは行ってほしいというものが基本契約の中に書かれていることもあるとは思っておりましたので、企業側の観点をできる限り生かしつつ、国・地方公共団体として最低限という事項はあるのだろうと思いますので、両方の視点でうまく整備をしていただければと思っておりました。

もう一点が、英国の話で、もともとはある程度英国政府もベンダーロックインではないですが、寡占市場になっていたような話は聞いておりました。スタートアップもそうだと思いますが、今では割と地域の地場の企業で入札される会社も増えている話があったと思います。どうしても意識して対策をしないと、競争法的にどうするかどうかというのもあるとは思うのですが、ベンダーロックインについては競争法での話だけしてもなかなか難しい部分もあって、どのように事業者のインセンティブを見つけながら分散できるようにしていくかをかなり意識的にやっていただくことで、実際に分散化できる可能性があるということは英国から学べる部分もあるのではないかと思いました。そういったところはぜひ参考にしていただいて、必ずしもハードローだけで解決しない分野ではあると思いますが、とはいえ競争環境といいますか、広い意味での環境整備はぜひ広く門戸を開いていく形につなげていただければと思っております。

以上です。

安念副座長: ありがとうございました。

吉田企画官、現時点でご見解がありましたら、お願いします。

吉田企画官: ありがとうございます。

最初のスタートアップに門戸をとか、落合先生からもご指摘があったように、幅広いベンダーの方に参画していただくというところに関しましては、これからスタートアップの協会やソフトウエア業界等に対してもまさにこの仕組みができてまいりますので、そちらの説明会等を行いながら、幅広く関心を持っていただくというところを進めていきたいと考えてございます。

あと、稲谷先生からタグの粒度のお話がございましたけれども、これはおっしゃるとおりで、要はどこにでも引っかかりたいみたいな形になると、タグを全部つけてしまえみたいな人なども出てきたりしてしまうと思うので、こちらについてはある程度タグの数を制限するであるとか、本当に自分たちに当てはまったものをつけてくださいというところをそもそも利用規約にしっかり書いていくというところで対応しようと考えてございます。

競争法、刑事法について何か議論があったかというところは、存じ上げないところではあるのですけれども、我々行政機関は、こういうデジタルマーケットプレイスが英国でもできる前は、アクセスできるベンダー自体の存在が分かっていなかったというところが多くあったと思っております。それで逆に要は特定のベンダーに依存しがちであるというところもあると思いますので、そういったところの情報が可視化されることによってより幅広いベンダーの方々を検討の対象にしていくことができるようになる、またはお声がけしていくことができるようになると考えているところでございます。

増島先生からございましたシステムと契約の2つをきちんと機能するように整理していくというところが必要であるというご指摘は、まさにそのとおりでございます。フレームワーク合意についてはまさにこれから詰めていくところではございますけれども、おっしゃっていただいたとおりUKのフレームワーク合意というのは一つ参考になるところだと思ってございまして、こういったところは参照しながらやっていきたいと考えてございます。

個別契約という言葉でございますが、これは基本契約と区別する上で個別契約と申し上げているところで、実際には個別契約というのは一般的な公共調達の調達行為、発注行為のことを個別契約と呼んでいまして、何かこれが特別に民間のSaaSに対して公的なものであるから付加的にこういうものを求めるという趣旨のものではないと考えています。もともと利用規約等といったものを参照していただいた上で、基本的には自分たちのサービスニーズに合うものを発注という形で契約していただくというところで考えてございますので、そこは当然企業によってはパブリックサービス向けみたいな形でそういうパッケージを用意するところも出てくると思いますけれども、何かこちらからそういうものをつくってくれということは、現状では特段考えていないというところでございます。

以上です。

安念副座長: ありがとうございました。

それでは、続いて、第3の議題に移りたいと思います。「事業者手続サービスタスクフォースについて」です。これについては、関係省庁として法務省にもご参加いただいております。この議事についても吉田企画官からご説明をお願いいたします。

吉田企画官: こちらの事業者タスクフォースの趣旨でございますが、これまでデジタル庁の取組としましては、どちらかというと個人向け、住民向けの行政手続の部分をどう便利にするかというところが中心だったと考えていますが、実際には、ビジネスをやられている皆様にもかなり行政手続の負担というのは大きくなっていると考えています。こういったところの中で、事業者の皆様にとっても利用しやすいサービス体験というのをどういうふうに実現していくかということや、あとは実際に行政の事業者向け手続システムの共通機能みたいなものをきちんと特定して重複開発みたいなものを抑えていくことで、効率的に行政手続ができる環境というのを整備していくというのは不可欠だと考えております。

こういったところを踏まえて、3つの柱と書いておりますが、まず1つ目は、各府省庁の手続システムを今後どういうふうに整理していくべきかというお話と、先ほど申し上げたように共通機能としてどういうものを整備していくべきかというところで、ここでは認証/署名、通知、決済、ベース・レジストリと挙げさせていただいていますけれども、こういったものの整備の方向性、さらには行政手続の利用体験の在り方というところで、マイナポータルのような住民向けはございますが、事業者向けのところではなかったりするので、そういった利用者体験をより向上させるためにどういった施策が必要かというところを整理しているところです。

どんな行政手続でも認証、ログインの機能というのが必要になるところですけれども、現状、例えばGビズIDというのが事業者向けの認証サービスとしては共通的にかなり使われているところでございます。一方で、こちらを見ていただくと、まだまだ全部のサービスで使っているというところにはなっていない。複数ID、パスワードを管理しなければいけないみたいなところの負担を考えると、このGビズIDでシングルサインオンできるような世界というのを今後、追求していくべきでございますし、ほかにも共通機能的なものを使っていけるようにしていくというところが重要だと考えています。

4ページは先ほどご説明したものを絵にまとめたものではございますけれども、手続の処理のシステムがありまして、それで共通的に使っていく共通の機能群というのがあり、これらをポータルのところから活用して手続しやすくしていくという利用体験の部分の整理、この3つをこの後、簡単にご説明させていただきます。

まず、手続処理システムの部分の整理でございますが、事業者によっても実際の手続はどういうものを行っているかであったり、その中で抱えているペインというものは異なると考えています。こういったところに対してどういうふうに対応していくかというところは非常に重要だと考えております。

2点目として、行政手続の中でもそれが事業者にとってどういった効果をもたらすのかというところである程度類型化できるのではないかと考えています。行政手続の類型に合わせたシステム化のような考え方も今後重要ではないかというところでございます。

また、トランザクションで見ますと、1割程度の手続の種類で9割近くのトランザクションを占めているというところになっています。これは税や社会保険などが中心になってまいりますが、そういったところが中心的になっていて、ただ、ここはかなり前から電子化されていて、レガシー化も進んでいるところをどういうふうにモダナイズしていくかというところが課題になってくるのかなと。

一方で、1割しかトランザクションがないけれども9割を占める行政手続というところについてどうやって効率的にデジタル化を進めていくかというところが非常に重要かと考えております。こちらは農水省でもeMAFFという取組であったり、デジタル庁ではe-Govというシステムがございますが、そういったプラットフォームのサービスを使って簡易に電子化を進めていくというところができるようにしていくべきではないかと考えております。

そういった意味で申し上げますと、先ほど申し上げた1割のトランザクションを占めている9割の部分については、各省庁で既にプラットフォームサービスを使って電子化している部分はそれで進めていただければと思うのですけれども、そうではないところで、やはりまだデジタル化を進めていく能力がないというところについてはe-Govの申請支援サービスのようなものを活用していただくというところが一つの方向性としてあるのではないかというところです。

また、共通機能についてはこの後、またご説明しますけれども、様々な行政手続処理システムが共通的に使っていくというところです。

実際にこういった共通機能であったり、プラットフォームサービスみたいなものを各省がどういうふうに整備しているのかというところを今後、調査をかけていきたいと考えています。それを調査することによって、どういった共通機能をどの省のどのシステムに入れていくことが可能なのかというところを検証していくという作業を進めていきたいと考えています。

では、具体的にその共通機能というものがどういうものかというところでございますけれども、先ほど申し上げたとおり、今回スコープとしているのは認証/署名、通知、決済、法人情報、これはベース・レジストリのことですが、これを基本的な共通機能として考えているというところです。特に認証と署名というところがかなり似たような機能というか、まだきちんと使い分けがよくされていない部分ではあるのですけれども、この認証というのはあくまで何か手続をしている人がその事業者当人であるということをリアルタイムに確認するものです。一方で、電子署名というものは、電子的な記録のデータをその人が作成したということを第三者にも証明できるというところが特徴になっていまして、この2つは実は違う機能であるということを、まだシステムを利用されている方も認識されていない部分がございますので、改めて13ページでご説明しているところです。

一方で、これは規制改革推進会議等でもご意見がございましたが、この認証と署名の機能自体が一体的に使えるようにしてほしいというご要望をいただいております。認証の部分はGビズIDになりますが、署名の部分は、まさに今日もご出席いただいていますが、法務省の商業登記電子証明書が法人については証明機能を果たしている。ここの部分について、一緒に連携した形で使えるようにしていくというところが一つあるのではないかというところです。

15ページがGビズIDと商業登記電子証明書の現状の状況をまとめたものでございますが、この2つを連携して使えるようにしていくというところが一つ重要になってくるのかなというところで、今後、検討を進めていきたいと考えているところです。

その際に、法務省と連携しながらこれを進めていきたいと考えていますが、実際にデジタル庁側の強みとしては、デジタルサービスをどういうふうに開発していくか、運用していくかというところにあり、一方で、署名や認証の機能を提供する際には代表者の本人確認というところが必要になりますので、こういったところを法務省様に担っていただくという役割分担が今後できると望ましいのではないかというところを16ページでは書かせていただいているところでございます。こちらが認証/署名の機能の共通機能の進め方というところで一つ考えているところです。

一方で、通知の機能に関しましては、こちらは実はe-Govの中では事業者向けの通知の機能というところが整備されてございますが、これがほかの行政手続の処理システムでも活用できるように整備していくというところが、こちらについては重要かなと考えています。

さらに、決済につきましても、今、住民向けのサービスなどでは決済機能が共通的なものとして開発されつつあったり、財務省に実際にどういった納付がなされたかというところのデータを連携するREPS連携という機能については、e-Govで整備されていたりします。こういった機能をきちんとつなげた形で共通の決済機能というところをつくっていく必要があるのではないかというところです。

最後に、法人情報のベース・レジストリの部分ですが、こちらはまたこの後に改めてプレゼンがあると思いますので割愛させていただきますが、この基本情報を使って様々な行政手続におけるプレフィルであったり、情報取得の手間を減らすというところで活用されていくというところが望ましいと考えております。

最後に、「事業者の行政手続の体験整理」というところですが、冒頭申し上げたとおり、事業者の方々がどういった手続をどこからやったらいいのかというところが電子的には分かりづらいというところがございます。そういった事業者のポータルのようなものを整備するですとか、あとは認証/署名につきましても、本人確認の作業として二要素認証みたいなものを設けると、必ずアプリというものが必要になってまいりますので、そういったものも整備しながら、例えば認証の機能については、行政手続だけではなく、将来的には民間手続でも事業者の本人確認をモバイルアプリと連携してできるような形といったところも考えられるのではないかというところです。

また、体験として考えるべきスコープとしても、これまで何か行政手続システムを整備するといったときには、探すところと手続をするという部分をどう電子化するかというところだけ考えておりましたが、我々はAISASというモデルに基づいてアクノーレッジメントでインタレストを持っていただいて、サーチしていただいて、アクションを取っていただくという一連の体験をきちんと意識した形でシステム化なり動線というものをつくっていくというところが必要になると考えています。

こちらについても、我々はそういった事業者の利用者体験というものがどうあるべきかというところで今後調査を進めてまいりまして、先ほど申し上げた事業者ポータルのモックのようなものもつくりながら検証していきたいと考えています。

【「事業者手続サービスタスクフォース」の一部については、非公開】

取り急ぎ、私からの説明は以上になります。

安念副座長: どうもありがとうございました。

それでは、ただいまの吉田企画官のご説明について、ご意見、ご質問がありましたら、どうぞお願いいたします。

増島構成員、お願いいたします。

増島構成員: ありがとうございました。とても分かりやすいご説明をいただいたかなと思います。

9ページでもう少し教えていただけるとありがたいと思いましたのは、今、課題全体を3つに分けていて、9割行われている1割のサービスというものはレガシーからの脱却をやりますと言っています。モダナイズとさっきおっしゃいましたが、ここは何らか新しいものをつくりますという話をされていて、真ん中にある部分についてはデジタル庁で開発し、下の部分については今の取組みを続けていただくという感じで聞こえたのですけれども、政府のシステム全体のアーキテクチャがどうなっているのかというのがよく見えないなという感じがしました。つまり、上の2つからは、基本的にマイクロサービスをつなげていくようなアーキテクチャを想定しているように見えたのです。真ん中のところはまさにAPIでつないでいくということなので、細かいマイクロサービスをいろいろつくって、それをつなげればフォローできる、残りの部分はローコードでやろう、という話をされているのかなと見えました。レガシーからの脱却というところもきっとそういうアーキテクチャを取っていくと、スケーリングとか、新しいものを切り換えていくというときはやりやすいということをおっしゃっているのかなと思ったわけです。他方で一番下の既存のものを使いましょうというときに、既存のものは結構モノリシックにやっているものが多いのではないかと思います。そうすると、出来上がりでの電子行政処理システムはどんなアーキテクチャになりますかというと、いろいろなものが引き続き混ざっているようなものが取りあえず短期的な出来上がり図になって、既存のものを使いましょうというところが古くなっていくと、だんだんモダンなアーキテクチャに切り替わっていくといったような、段階的なイメージを持たれているのかなとこの図を見て思っていました。この辺のアーキテクチャ全体をどうつくっていくつもりでこれをご説明いただいたのか、もしよろしければ教えていただきたいなと思いました。
以上です。

安念副座長: ありがとうございます。

続いて、落合構成員、お願いします。

落合構成員: どうもありがとうございます。こちらの件も非常に進めていただいておりまして、すばらしいと思います。

その上で、こういうアーキテクチャ自体が、増島構成員もおっしゃっていただいた全体として何をやっていくべきなのかをさらに整理していくことが必要な部分があるとは思いますが、まずはできるところを進めていっていただいていることもまた一面であるようには思っております。その中で今後は、今見えている範囲でいえば、やはりGビズIDの法制化はしっかり進めていくとことが大変大事なのではないかと思っております。

加えて、今回ご説明していただいた中で、署名等の機能もお話をいただいております。個人側についてはマイナンバーカードもありますが、法人の場合ですと、商業登記電子証明書がしっかり使える形になっていくということで、商業登記電子証明書の整備をしっかりデジタル庁でもうまく法務省をサポートしていただきながら、リモート署名などもしっかり進めていただくことが大事だと思っております。

この2つは特に整備が必要な点として間違いがないのではと思っておりますが、そのほかに、本日お話しいただいている中でもいろいろな意味で課題が残っている部分はたくさんあるように思っています。決済についても、例えば納付についても国庫納付だけではなくて自治体側の納付のほうもeLTAXなどの仕組みでということで規制改革会議でも議論されてはおりますが、なかなかこの辺りも整備するのが大変な、結構重い領域ではあると思います。それぞれ非常に重い内容が入っている部分もあるとは思いますが、そういう意味ではどうしても順次できるところから、他省庁で権限を持たれているところもあると思うので、デジタル庁側で全部決めてやり切れないことも理解できる部分がありつつも、ただ、やはりデジタル庁のほうでしっかりアイデアを出していただくことがないと、持たれている省庁のほうがどうすればいいか分からないということになると思います。少なくともユーザー体験としてはどうしてもよくないものをつくってしまう傾向があるように思いますので、ぜひそういった点も配意しながら進めていただければと思います。

最後に、4つ目になってしまいますが、これまで議論されてきた中で、行政手続のデジタル化で最後に残っている論点としては、本人確認の部分があります。本日もIDの部分をお示ししていただいていたと思うのですが、それと物の郵送が若干まだ整理できていない部分があって、デジタル化ができていない部分もあるようですので、そこは論点としては比較的小さいのではないかと思いますが、どこかのステージの中で整理していただければと思います。

以上です。

事務局(小坂): 事務局でございます。石川副大臣におかれましては、この後、ご予定がございますので、ここで中座されます。副大臣、ありがとうございました。

安念副座長: ありがとうございました。今後ともどうぞよろしくご指導ください。

石川デジタル副大臣: 構成員の皆さん、それぞれご指摘ありがとうございます。こちらで失礼します。

安念副座長: 副大臣、ありがとうございました。

それでは、吉田企画官から何かコメントがありましたら、お願いいたします。

吉田企画官: 最初の増島構成員のシステムのアーキテクチャというところで申し上げると、まず共通機能の部分をちゃんとマイクロサービス化して、様々な行政手続のシステムで活用できるようにしていくというところが非常に重要なのではないかと考えています。これはシンガポールであったり、インドでもそうなのですけれども、認証/署名であったり、決済といった様々な手続で共通的に使われる部分は同じインフラとして整備していくというところが非常に重要だと考えていますので、ここは先ほど落合先生からもご指摘があったとおり、一つ一つ結構重い話ではあるのですけれども、まずはこういった共通機能というものを整備しなければいけないのではないかということの問題提起がここでなされているとご理解いただけるとありがたいというところでございます。

一方で、手続処理システムの部分に関しましては、先ほどおっしゃっていただいたように、9ページの下の灰色の部分でございますけれども、この中で先ほども少し言及しましたが、eMAFFのシステムであったり、金融庁などでも行政手続を汎用的に行えるシステムをつくったり、各省庁でもそういった汎用的にトランザクションの少ない行政手続を電子化できるような仕組みというのをつくり始めておりますので、そこについて、e-Govにまた載せ換えてくださいというのはなかなか現状では大変なことだと思いますので、まずそこはちゃんとそれで進めていっていただこうと。そういったものでカバーできないところについてはe-Govのシステムなどでしっかり支えていくというところが役割分担としては重要なのではないかと考えています。

その先の将来としては、もしかしたらここの手続の処理のステップというところも、より要素分解していくとマイクロサービス化できるみたいなところも実際はあったりしますので、そこはもう一歩先のところでそういった議論もあり得るのかなというところではございますが、現状ではまずはそういったところの整理から進めていく必要があるかなと考えています。

あと、落合先生からおっしゃっていただいたことも、応援していただいているというところで受け止めてございまして、ここの共通機能の部分を充実させていくというところは非常に我々としても重要だと考えていますので、今後、進めていきたいと考えています。
以上です。

安念副座長: ありがとうございました。

今日は法務省の皆様にもご参加いただいてどうもありがとうございました。これでご退席をお願いしたいと存じます。

続いて第4の議題「AI時代の事故責任の在り方について」です。この議題については、関係省庁として警察庁、消費者庁、法務省、経済産業省、国土交通省の各省庁にもご参加をいただいております。

それでは、須賀参事官からご説明をお願いいたします。

事務局(須賀): ありがとうございます。AI時代の事故責任の在り方についての検討を開始したく、今回、新しいアジェンダとしてご報告をさせていただきます。

2ページですが、5月の第7回デジタル臨時行政調査会において今後の検討課題をご説明したときに、経済界から約1,900件要望をいただいているうち150件程度が、AIの活用の観点で規制を点検する必要があると思われるものだったということを踏まえまして、AI活用のためのルールの見直し点検のをデジタル臨調としても進めたいということを申し上げておりました。その一環として、今回、自動運転車の普及に備えて責任制度を再整理するということをご提案したいと思います。

そもそもデジタル臨調を立ち上げてすぐに合意していただきました「構造改革のためのデジタル原則」の中でも、原則2がアジャイルガバナンス原則となっておりまして、その中で点検のチェック項目③と④ですけれども、③には、AI時代の管理手法を見直して、モニタリングや制御ソフトウエアの導入やログ保存、事故原因究明協力等の制度を整備することと書かれております。それから④には、AI時代の事故責任分担について一体的な仕組みを整備することと書かれております。このデジタル原則と点検項目に沿って検討を進めるための準備がやっと整ったということだと思っております。

グローバルに見ても、右上ですけれども、アジャイルガバナンスの重要性ということはこのたびの日本が議長国を務めましたG7デジタル・技術大臣会合においても認識され、アジャイルガバナンス5原則のようなものが合意されております。直近、経済産業省が唱えて各省と連携して整備を進めているデジタルライフライン全国総合整備計画におきましても、ハード・ソフトの投資と併せて、ルール面において自動運転の車やドローンがこれから社会に普及してくるということを見据えまして、その安全性を担保するために、制御の自動化、最適化、それからリスクマネジメントを促すインセンティブ設計、事故時の原因究明や対策を即時に講じるためのアジャイルガバナンスの実践ということを書かれております。そろそろこのアジャイルガバナンス原則の今まで手をつけていなかった部分について取り組み始める段階かなと思っております。

3ページですけれども、自動運転の車はドライバーという人が観念されず、車が自動で走るという現象がこれから社会に入ってくることを想定いたしまして、被害者の迅速な救済と、特定の人に過度な責任が寄ってしまう事態は回避するということを通じて、イノベーションがしっかりと社会に実装されて、今までよりも高い安全性の担保が可能となるというのが自動運転システムの目指したいところだと思います。そのために関係者に対して望ましいインセンティブがしっかり働くように、今の環境をそのまま変える必要がないのだったらそれでいいのですけれども、しっかりと点検をして、整備が必要であれば行っていくという対応ができればと思っております。

具体的には、自動運転の車の製造や運行にこれから関わろうとする主体が幾つか抱えているリスクがございまして、まず、そもそも社会的に事故を1つ起こしてしまうと大変なブランド凋落のリスクがあり、すぐに事業を全部停止しなければいけないということも含め大きな社会的な制裁を受ける可能性があります。

それから、法律上も、まずは民事におきまして、事故の発生を予見し切れなかった場合でも、事故防止のための方策があったではないかと後から言われてしまって損害賠償の請求を受けるおそれがあります。訴訟に巻き込まれるリスクです。

それから2つ目が、刑事の分野におきましても、犯罪の構成要件に該当する行為がなされたのだとして個人や法人がいきなり刑事責任を問われるというおそれもあるように考えております。

自動運転車というのはいろいろな複雑なシステムが絡み合って運行が実現するものでございますので、複合的な要因による限界事例というものが必ず生じます。そういったときに、リスクを恐れて開発を萎縮する、あるいはヒヤリハットも含めて何らかの事故に近いものが起きたときに何も言わず全ての情報を秘匿するというインセンティブが働いてしまう。それによって情報開示も学習も進まないという状態はぜひ避けたく、自動運転車の普及に備えまして、取り組むべき主要課題の一つとして、自動運転車の運行によって損害が生じた場合の責任制度の在り方に係る議論を深めるべきだというお声をたくさん頂戴しております。

4ページでございますけれども、目指すべき方向性として、大きく分けて自動運転車を走らせるためにシステムとルールが関わってまいります。まず、システム面でできることといたしましては、自動運転の車やその周りの走行環境がどうだったのかということについてデータを集める。これは事故が起きたときだけではなくて、デジタル化のメリットは、ヒヤリハット、ニアミスをしたときの情報というのもビッグデータとしてシステム経由で収集することができる。それをしっかり解析して、どうしてこういった事案が起きたのかという原因の検証を常に常にし続けることによって、社会全体で事故やヒヤリハットの情報を学習して、社会にフィードバックする。それによって各プレイヤーがシステムの改善を継続的に行っていく、まさにアジャイルな改善を行っていくための仕組みというのを実装できないかと考えております。

それから、ルールの面におきましては、適切なリスクマネジメントや調査への協力です。事故が起きたときに原因究明調査にしっかり協力したほうがいいというインセンティブが社会から提供されるような仕組みというのをぜひ実装していきたいと思っております。

そのためにご検討いただく具体的な論点といたしましては、ヒヤリハットの情報なども含めて、誰が収集して解析をし、どうフィードバックしていけばいいのかというように、必要となる組織やシステムの要件というものの定義が必要になります。そして、その組織にどのような権限があれば有用な情報を迅速に社会にフィードバックすることができるのかということについてもご検討いただきたいと思います。

それから、ルール面におきましては、まずは企業で製品を開発される、あるいは運用される場合に、企業しか知り得ない情報というのは必ずありますので、自律的、あるいは協調的にリスクマネジメントを促すような責任制度というものがあってほしい。さらに、必要に応じて予見困難な事故が起きた場合には、ここまでやってくれたならそこから先は免責ですという制度というのも実装する可能性がないかどうか。その場合に、誰かが独りよがりで決めるのではなくて、免責要件というのをマルチステークホルダーの参画を得て具体化していくといったことについてもご検討いただきたいと思っています。
それにあわせまして、免責されるから救済されないというのではなく、責任と救済は切り離すことが可能でありますので、被害者の救済、あるいは企業のリスク軽減のための保険や公的な救済の制度というものもしっかりと実装していき、どういう車にはねられたのかで泣き寝入りをする被害者が出るといった差が生まれないような制度にしていけたらと思います。

【「AI時代の事故責任の在り方」の一部については、非公開】

以上、私からのお願いとご報告でございました。以上です。

安念副座長: ありがとうございました。

稲谷先生、ご発言をお願いいたします。

稲谷構成員: 稲谷でございます。

本当におっしゃるとおりでございまして、極めて重たい論点ではあると同時に、ここを何とかしてクリアしないと、全体が前に進まないということもまたある程度明らかな論点かと思っております。現行の制度は、過失責任もそうですし、あるいは製造物責任のような欠陥といった概念を前提とする責任もそうなのですけれども、ある程度事故のリスクが明確に規定できて、しかもそれを除去することで、結果が回避できるということが念頭に置かれてつくられている仕組みだと思います。

そうすると、確率的に挙動するAIの問題でありますとか、あるいはまさにご指摘になったような複合的な要素によって生じる事故といったものについては、もともとあまり適合的なモデルとしては出来上がっていないというところがどうしてもございます。そういった点に特に留意しながら改善を進めていくということで、特にその際に、ご説明にもございましたように、その責任制度を回すことによって情報がきちんと必要な限りで共有されて、システム全体が、問題となった自動運転システムもそうですけれども、法制度のほうもセットでどんどん進化していくようなインセンティブを上手につくっていってやっていくということが恐らく今後、まさにアジャイルガバナンスというお話がありましたけれども、それを実装していく上で必要だと思います。どこまで細かい論点に踏み込むべきかというのはありますので、このぐらいにしておきますけれども、私といたしましても、この論点につきましては、かなりきちんとコミットをして、責任を持って取り組みたいと考えているところですので、必要があれば、いつでもお声がけいただければ、可能な限り尽力したいと考えているところです。

どうもありがとうございました。

安念副座長: ありがとうございました。

それでは、落合構成員、お願いいたします。

落合構成員: ありがとうございます。

非常に壮大な論点になっていますが、とはいえ、ここまで取り組めることが最終的な到達点の一つにもなりそうな部分ですので、非常に重要かと思っています。

1点目として、とはいえ時限性もあってといいますか、急ぎ実施しないといけないというか、デジタルライフライン全国総合整備計画の関係で早めに実施できるようにしなければならないこともあると理解しております。実際には非常に難しいというか、社会のまさしく根幹になる制度をつくり変えてしまうところなので、完全に民法自体をいきなり大きく変えるとか、刑事法をいきなり大きく変えるという話になると、それこそ数年ぐらいはかかることは想定される部分かと思っております。

その一方で、デジタルライフライン全国総合整備計画などで想定されている中では、道路側の定義だったり、システム要件の整備だったりをされていて、そういった中で行為義務などを整理していく中で、条件など限定できる部分をつくって、実装を先行してできるようにして、中間的にまず一部の成果を出せるようにする方法もあると思います。そういう意味では最終的な法の構造自体の変化もあると思うのですが、短期的な条件設定と、落としどころをつくっていくことをぜひしっかり議論できればと思っております。私もモビリティーの関係で、国土交通省などでよく検討会に出ていたりしますので、ぜひこの辺りも稲谷先生に続いてできる限りご協力させていただければと思っております。

安念副座長: ありがとうございました。

増島構成員、お願いします。

増島構成員: ありがとうございます。

この検討は非常に大事であるのですが、レベル感としてどのレベル感の議論をやるのかという話なのかなと聞いて少し思っていました。最終的な制度に落とすところは多分やらないだろう。それは国土交通省だとか、いろいろな人たちがやられるのかなという感じがしておりまして、そうすると、それを整備するに当たっての考え方は、まさに先ほど在り方という形で書いていたかもしれないのですけれども、もう一段抽象的なレベルでの考え方の整理をされるということかなとお伺いをしたところであります。

例のアジャイルガバナンスのほうでは、自動車に限らず全体の責任の議論をやりましたけれども、あれよりは一段具体で自動車という場面に絞った形になると思います。そこでやられるということだけれども、あくまで具体的な制度としてこういうものでやると多分収拾がつかなくなるので、そこまではいかないというレベル感の議論かなということを話を伺って思いました。

そのレベル感の議論だと、多分今、狙っているところは、同じ議論がAIの規制のところでも出てくるみたいなところにきっとなるでしょうということなのだと思いますから、同じように確率的であってかつ複雑な中でということであれば、きっと同じだということだと思うので、そういうものを検討するときにもひな形になりそうなレベルでの考え方を整理するという頭になっているのかなと、お伺いをしながらちょっと感じたというところでございます。イメージが合っているのかどうか、変に具体の話に突っ込むと利害関係が入り混じってごちゃごちゃになって分解してしまうということがきっとあると思いましたので、どのレベル感でやられるのかというのを教えていただくといいかなと思いました。
以上です。

安念副座長: ありがとうございます。

須賀参事官、いかがですか。分解しないレベル感というのは今、お持ちですか。

事務局(須賀): ありがとうございます。

今までの法規制の在り方をもしかすると根幹の部分で変えることになる、抜本的な検討を求めるような議論になってしまうかもしれないということも含めまして、規制所管省庁、制度所管省庁の皆様がまずは集まってみて、今の制度を今後もずっと運用していくに当たって何か決定的に不都合な点がないのかどうかということを虚心坦懐に論点検討するということにまずは同意していただいたという段階だと思っております。いきなりこの制度のここをこういうふうに変えるという具体論に入るというよりは、まずは自動運転の車で必ずしも運転者、運転手のような人が想定されない車が社会に入ってきたらどうなるのかというシミュレーションに近いような議論をしながら、今、おっしゃっていただいたように、今後、車に限らず様々なAIが社会に入ってきますと、人間が今まで担っていた機能を機械が代替するというのはより汎用性一般性のある議論だと思いますので、そういったところに通用し得るような、広がりを持ったときに局所最適ではない議論になるような形で少し俯瞰してご議論いただければと思っております。

その議論の先に具体的に何かを変えたり、何か新しい制度を創設するという結論に至れればもちろんありがたいわけですけれども、まずは集まって、まさに考え方の整理からしてみようではないかということでお声がけをさせていただいた次第でございます。

増島構成員: そういうことですね。どこを見据えているのかというのを理解した人をちゃんと集めてやっていくのが大事かなと感じた次第でございます。

ありがとうございました。

安念副座長: ありがとうございました。

しかし、既に有力な先生からもご協力のお申し出があったから、これはとても頼もしいことですね。ありがとうございました。

関係省庁の皆様、お忙しいところご参加いただいてどうもありがとうございました。これでご退席をお願いしたいと存じます。

5つ目の議題になります。「ベース・レジストリと制度的課題」ですが、これは2つのパートに分けて議論していただきたいと存じます。第1のパート「新たな情報連携の仕組みの下でのデータガバナンス」、第2のパート「住所・所在地・建物情報に関わる番号制度やベース・レジストリの整備について」です。

最初のパート「新たな情報連携の仕組みの下でのデータガバナンス」については、杦浦参事官からご説明をお願いいたします。

杦浦参事官: 杦浦でございます。ありがとうございます。

では、最初にデータガバナンスに関してご説明いたします。2ページの行政手続における番号法での現行の規定についてですけれども、まず法人での行政機関間の情報連携については、番号法の中で法人番号を用いてやりましょうということが書いてあり、各行政機関においては正確な情報を担保せよということが定められております。

しかしながら、各行政機関は各々自分のところに来た届出において法人の実在確認等をしているわけですけれども、これまでは必ずしも法人番号を用いた事務ということはしておらず、法人番号を強く意識して把握・管理する必要性というのはあまりなかったというところです。

今後、法人番号を共通の識別子として情報連携を行い、それによって添付省略や、さらに届出事項の省略といったサービスを実現していくに当たっては、この番号法第42条に基づく管理する必要性というところをより強く意識していく必要があるのだろうと考えております。

また、データ連携におきましては、文字に係る規格等の標準をしっかりと定めていかないと、例えば特殊な文字をある行政機関において扱っていても、ほかの行政機関で扱えないといったことがあるとデータ連携がスムーズに進みませんので、こういったところもケアをしていく必要がございます。

3ページでございますけれども、先ほど申し上げた42条というのは、特に情報連携をして今まで業界ごとにその都度届けていただいていたようなことを無くしていく。例えば、登記情報において住所変更がなされた場合、その法人番号にひもづいているほかの行政機関で届出されている住所も併せて変更するといった場合、確実にその法人番号を保有した上で、きちんと正しい情報にひもづいているということが大事になります。仮にそのひもづけ等が間違っておりますと、異なる法人の情報が書き換わってしまうという可能性があるということでございます。この法人番号をきちんと管理するためには、そもそも法人に対して法人番号届出の際に出してくださいということを義務づけるなり、またはGビズIDアカウントといったものから法人番号をきちんと取得するといったことが前提になろうかと考えております。

こういったことも含めまして、デジタル時代の中で情報連携におけるデータガバナンスをきちんと果たしていくためには、手続の全体の枠組みがどうなっているのかを明確にしておく必要があろうかと思います。全体の枠組みとして4ページに記載しておりますけれども、全体をデジタル庁が調整していく。それは番号法第4条であったり、デジタル手続法であったりということですけれども、情報連携の仕組みをつくっていく、データ標準と要件を策定していく、また、先ほど申し上げたような届出事項の省略といった規定をつくっていくといったところがデジタル庁の担当であると考えてございます。

また、情報元である法務省や国税庁におきましては、正確な登記の推進や法人番号の付番等々を行っていただく。さらにそれをデータ連携ということでデジタル庁が情報連携機能を提供する。そして、それを利用する行政機関においては、届出事項等をきちんと整理していただいて、法人番号のひもづけを正確にしていただくといった役割分担を明確にしていき、我々としても仕組み全体がこうなっていますということを明確にご説明していく必要があると考えています。

1つ目のパートにつきまして、説明は以上になります。

安念副座長: ありがとうございました。

引き続いてパート2のご説明をいただいて、その後、全体を通じてご質問やご意見をいただくことにいたします。

続いてのパートです。パート2番目、「住所・所在地・建物情報に係る番号制度やベース・レジストリの整備について」です。関係省庁として、総務省、法務省、国土交通省にもご参加いただいております。杦浦参事官からご説明をお願いいたします。

杦浦参事官: 杦浦から続いてご説明いたします。

ベース・レジストリのうち、不動産の部分でございます。こちらの2ページ目、住所、所在地、建物情報の現状と目指す姿についてまとめてございます。まず現状におきまして、住所や所在地、建物情報といったものを行政として一元的に管理しているところは今のところございません。これにより、行政機関や民間事業者においてもそういった情報を独自に個別に整備をするため、社会全体で見ると整備の重複といったコストが生じているところでございます。

また、それぞれに整備していることもあり、住所、文字情報というのは表記の揺れがどうしても出てしまいますので、データを事業者間で連携しよう、突合しようとすると、どうしても難しい状況が生じます。

また、住所制度そのものも課題がございまして、同一住所の中に物件が複数存在するといったこと場合、例えば宅配業者におきましては、それらを実地で調査するといった作業も必要となっております。

こういった背景の下、既存の制度はしっかりと動かしつつも、今後、行政機関等が参照可能な何らかの統一的な番号の下で管理した情報の整備、これをアドレス・ベース・レジストリと我々は呼ぶわけですけれども、それを整備しまして、行政機関等がそれを参照していただいて、業務の効率化や連携した事業、新しい事業といったところを生み出していただくということが我々の目的でございます。

3ページに、具体的にこれまで民間からのヒアリング等を基にどういったニーズがあるのか、あるいはどういった困難があるのかということを例示してございますけれども、例えば右上の配送時の建物特定ということになりますと、先ほど申し上げましたように複数の物件で同じ住所で記載がされているものがあったり、あるいは左側におきましては、例えばインフラ系の会社や不動産の取引をされている会社等が独自にデータベースを持っているものの、それを突合しようとすると、表記の揺れ等により、どうしても手作業になってしまったりといった形でなかなかデータ連携を円滑に進めるのが難しいといったニーズがございます。

4ページで、今、どういった状況にあるのかというのを理念的に整理しています。特に登記の体系で管理をされておりますのが③、④のところですけれども、不動産登記におきましては、土地、建物等は基本的に地番といった形で管理されてございます。その上で、②で建物は自治体のほうで住居番号というものを振られているわけですけれども、これは必ずしも④の地番とひもづいた情報ではございません。さらに、①の一般的に利用されている住所においては、例えば建物の名称、マンションの名称、アパートの名称といったものが書かれている場合もございます。こういった情報を特に②、③、④の行政が持っている情報と連携し、ひもづけた状態でデータを整備するということで、①の利用住所というものもこれらの情報にひもづいた形で使いやすいデータベースにしていくということを目指しています。

そうなりますと、どこまで細かいところまで行政としてやるべきなのかという議論になろうかと思います。5ページで、当然のことながら、行政が協調領域として一定程度共通的なところを整備した上で、民間の方に競争領域として付加価値を生み出す部分といったことがあろうかと思いますので、どこで切り分けるのかについて、今後の議論、調整をする必要があろうと思っております。

これについて1点参考になりますのが、6ページ、法人番号の例かと思っております。もともと法人の情報につきましては、かつては信用調査の会社様などが独自に情報を収集して、IDなどを振って情報として、例えば販売されていたというところです。こちらは今、国税庁が法人番号というのを指定して、名称や事務所の所在地などをオープンにすることが定められております。これはある意味、行政による協調領域として設定をしており、その上で民間の方が独自のサービスを展開されているというのが法人番号の世界でございますので、これと似たようなことを不動産の領域でも議論していく必要があろうかと思っております。

7ページに、どういったところが今申し上げたような行政が提供する協調領域で、どこが競争領域なのかということを、まだ大まかではございますが、端的に書いたものでございます。左側から都道府県、市区町村、町字といった粒度がだんだん右に行くほど細かくなると見ていただければ、地番や住居番号、建物番号といったところは行政が既に付番等をして持っている情報ですので、ここは引き続き行政が整備をして提供していく協調領域として見るのが適当ではないかと考えております。

一方、一番右側のほうの事例で書いておりますような極めて粒度の細かい情報につきましては、競争領域とすることが妥当であろうと考えております。他方、その中間にあります建物名等は、住居の行政が管理しているところに出てくることもございますし、必ずしも出てこないものもございますので、この辺りは例えば官民が連携して整備等を行う協調領域の準公共版というところで何かしら工夫して整備をするということも考えられるのではないかというのが、我々が現在考えていることでございます。

こういったことも含め、8ページに、今後、アドレス・ベース・レジストリとして何をどう整備していくかということでございますが、今、情報元として先ほど来申し上げているような市区町村で管理をされている、いわゆる住居に与えられている住居番号等の住居の表示、法務省で管理されている地番等の登記情報をアドレス・ベース・レジストリとして整備していき、一番重要なことは、右側に書いておりますように、これらの情報を何か1つ持っていたら、ほかの情報を検索することができるというところを目指すというのが、我々が今、考えているところになります。
この地番と住居番号がどうして別々になっているのかということを少しフローで復習いたしますと、9ページに、何か建物を建てるといったときに、建築の確認申請のときにはまだ土地の情報があり、地番で管理されているところに建物が建っていく。建物が建ちますと、自治体のほうで住居番号を振って、それが後々住所といったところで流通していくことになります。

片や、不動産の登記のほうでは、建物が建っている地番が複数あれば、その中から代表地番というものを一定のルールに基づいて選び出して、以後、登記情報としてはそれが代表地番として管理されるということで、この段階でいわゆる住所と地番といったものは独立して管理されることになります。

10ページ、これを今後どうしていくのかというと、何らかの形でベース・レジストリのところに入れる際には集約をするというところが必要になりますが、基本的には今あるものをどうするかというのと、今後、どうしていくかの2つに分かれます。

今あるものにつきましては、11ページで初期データの整備ということで書いておりますけれども、今ある情報の住所を書き換えていくということはできませんので、今ある様々な情報を活用して、地番なり住所なりといったところをひもづけなり集約ということを行って、初期データとして構築することが必要だと考えてございます。

片や、12ページ、今後新しく建物が建っていく場合に、これは何かしら上流の過程と申し上げますか、住居表示の台帳の作成及び不動産登記もしていくといったところで、何かしらひもづけがされるような工程を追加する、つくるといったことが必要になろうと思っており、これは今後の課題となります。

それらも含めまして、アドレス・ベース・レジストリの実現に向けた課題といったところを一旦整理させていただきますと、13ページ、初期データの整備につきましては、情報の収集とデータの統合、ひもづけといったところを確定していく必要がございます。また、入っているデータを最新とするため日々アップデートする必要がございますけれども、町字のレベルについても管理がどうなされているのかということは、我々もいろいろヒアリング等を含め実態把握をしようとしておりますけれども、やはり自治体によって様々あるというところが実感としてございます。

また、地番等の更新の頻度につきましても、現在のところ、年次の更新データであれば利用可能ですけれども、それをどこまで細かく刻んでいけるかといった課題もございます。また、先ほど住所の問題として申し上げたような複数の物件が同一の住居番号に存在するといったところをどう解決していくかといったところを、今後、各関係省庁とも調整をしながら決めていく必要があろうかと思います。

最後に、14ページに、スケジュール感といいますか、今、申し上げたような課題を踏まえつつ、どういったところから実現がされていくのかということをイメージいたしますと、まずは粒度感で言うと比較的上のほうにある町字レベルでの提供といったものは、ある程度システム等を整備してやればいけるものかなと思っておりますので、ここ2~3年といったところを一つのメルクマールとして考えています。

片や、それよりも粒度の高い住居表示、地番といったところにおきましては、システム面の整備と制度化といいますか、どういったルールで情報を整備していくのか、ひもづけ等を行っていくのか。ここについてはある程度時間をかけて丁寧に議論をしていく必要があろうかと思っておりますので、町字レベルの提供に少し時間を置いて、その後、粒度の細かい情報の提供を目指していくということでスケジュールをイメージしております。

説明は以上になりますので、ご議論、ご質問をよろしくお願いいたします。

安念副座長: ありがとうございました。

それでは、ただいまの杦浦参事官のご説明に対してご質問、ご意見がありましたら、どうぞお願いいたします。

増島構成員、お願いいたします。

増島構成員: ありがとうございます。

この更新の話というのはすごく大事だなと思ってお話をお伺いしていたのですが、システムを提供する側の自治体側としてどのぐらいでできますかという話もさることながら、恐らく利用する側から更新の話を見ておく必要があると思います。利用者側から見て、更新と更新の間の期間がこれだけ空いてしまって、この期間中は結局ずれている可能性がありますという話になると、そのシステムを果たして人は使うのだろうかという話がもしそこにあるとします。そうすると、いつものようにできたけれども使われない現象といったような、システムで出てきた結果が本当かどうかが分からないので目的を達成するためには何か別のこれをしなくてはいけないという話になると、いつもの悲劇が起こるかもしれないというところにちょっと懸念を感じるところがあります。ここはもちろんすごく難しい話なのですけれども、使われる、使われないのところに直結する話かもしれないなと思いまして、今のような目線から見たときにどんな解決方法があるかについてお考えがありましたら、教えていただけますでしょうか。

安念副座長: ありがとうございます。

それでは、他の構成員の皆様にもご発言をいただいてからお答えいただきましょう。
岩村構成員、お願いいたします。

岩村構成員: ありがとうございます。

今の増島先生のご指摘は非常に重要な点だと思います。利用する側からすると、配送DXのように、実装されることで利便性が大きく向上すると思う一方、使われなくなり情報の正確性が不確実となってしまうのは困るということで、懸念については私も同じ意見でございます。

また、第22回作業部会でご説明いただいた不動産テック協会のIDのように、民間の取組やデータも活用していただき、実現に向けて進めていただくことを期待しております。
以上です。

安念副座長: ありがとうございました。

落合構成員、お願いいたします。

落合構成員: どうもありがとうございます。

今、ご議論があったように、優先度が必要な程度がどこかということを考えていくことは大事だと思いますので、配送が一つあるかと思います。また、例えば不動産取引などになってきますと、いろいろなひもづけ先もたくさんあってまた難しくなってくるところがあると思います。着実にユースケースを積み上げながらとなると思っておりますし、そういう進め方をしていただいていると思います。

また、特に住所の点について重要だと思っておりますのは、徹底的にやり切れないところがあると思いますので、どこかで捨てる勇気を持っていただくことが大事ではないかと思います。そのため、一定の精度を保って、業務上耐え得る程度の精度にする必要はあろうかとは思いますが、多少のミスや制度不足はどうしても避けられないというか、更新が遅れたりということもあるでしょうから、さらにもともとのデータ自体が必ずしもどこまで正確性があるのか論点があるものも混ざっているかと思います。そういう点を一部捨てて、期待値コントロールが大変大事だと思います。

社会的にいろいろな意見が出てきたりすることもあると思いますが、枠組みに対する打ち出し方だったり、期待値コントロールも気にしながら進めていただくと、無用な批判も避けながら進められるのではないかと思いました。

私からは以上です。

安念副座長: ありがとうございました。

それでは、杦浦参事官からご発言をお願いいたします。

杦浦参事官: ありがとうございます。様々なご意見とともに応援のメッセージをいただき感謝申し上げます。

まず、データの粒度とその更新の頻度、最新性の担保につきましては、町字レベルに関しましては、幸い町字が変更されるというケースは年間でそれほど多くはございませんので、それについては一定程度最新性の担保はできるのではないかと思っております。この町字レベルでの粒度でどれぐらいのニーズがあるかということに関しましても、既に町字レベルでも表記の揺れがあるといったところ、現在、突合等の作業が難しくなっている場合もあると聞いておりますので、町字レベルの情報であってもこういうデータベースが整備されるのはありがたいといったニーズは、声として聞いています。

今度、より粒度の細かいところに持っていったときに様々な課題がございまして、最後の期待値コントロールとか、ある意味完璧性を捨てる勇気も必要ではないかといったところで大変ありがたいご助言をいただきました。完璧を求め過ぎるあまり、例えば一定程度の精度でも十分なサービスというのを遅らせる理由にはならないと思っておりますので、その点は重々留意して進めたいと思います。

粒度と頻度に関しましては、例えば粒度が細かい情報について、必ずしも最新性が担保されていなくても、ある程度といいますか、大いに役に立つといったご要望なりニーズは関係省庁から聞いておりますので、例えば一定程度初期データが整備できた際に、その後の更新の頻度が必ずしも高くない状態でも、それはそれでかなり使えるものになるということは感触としては持っております。もしかしたら事例は幾つかの省庁に限られるかもしれませんが、それでも例えば調査の際の手間がある程度削減されるとか、あるいはそもそも一定程度の見当をつけるといった作業においては十分に役に立つであろうというところは聞いています。

そして、ある意味、地番等の細かい情報が日次で更新できるようになるというのは、少しシステム面でも制度的な担保等においても時間がかかるものかもしれませんが、最終的にはそこまでにたどり着くのが究極的な目標かと思っております。ただ、それまでの各フェーズにおいても一定程度の有用性はあり、そのようなデータベースでも使いたいといったニーズの声はいただいておりますので、そういったところは段階的に提供できるところからやっていくという考え方でいきたいと思います。

あと、民間データの活用についてのコメントもございました。まさに配送業者様や地図業者様が民間データとしていろいろ整備されておりますので、そういったところと、先ほどの言葉で言えば、どう協調領域と競争領域を切り分けていくかというのは、今後、調整をしたいと思っています。まずは初期データを整備する段階においては、地番と住所のひもづけといったところには民間のデータを大いに活用していく必要があるのだろうと思っておりますので、その辺りは今後、詳細を詰めていきたいと思います。

ありがとうございます。

安念副座長: ありがとうございました。

それでは、第5の議事についてもこれくらいにさせていただきたいと存じます。総務省、法務省、国土交通省におかれましては、こちらでご退席をお願いいたします。今日はお忙しい中、ありがとうございました。

それでは、最後に事務局より次回の作業部会の開催についてご説明をお願いいたします。

事務局(栗栖): ありがとうございました。

次回の作業部会の詳細につきましては、事務局より追ってご連絡させていただきますので、よろしくお願いいたします。

なお、本日の議題につきまして、議事3「事業者手続サービスタスクフォース」の一部及び議事4「AI時代の事故責任の在り方」の一部については、ご異議がないようでございましたら、非公開とさせていただき、後ほど議事録を作成し、皆様にご確認をいただいた上で公開させていただきたいと存じます。

また、本日の資料の取扱いにつきましては、議事3「事業者手続サービスタスクフォース」に関する資料の一部及び議事4「AI時代の事故責任の在り方」に関する資料の一部を除きまして、デジタル臨時行政調査会のホームページに公開させていただきたいと存じます。
本日は皆様方、ご参加いただき誠にありがとうございました。

安念副座長: ありがとうございました。
それでは、以上で第24回の作業部会を閉会いたします。皆さん、ありがとうございました。