デジタル関係制度改革検討会デジタル法制ワーキンググループ（第3回）議事録を掲載しました

2024/05/23　デジタル庁　　

ホーム
会議等
デジタル関係制度改革検討会デジタル法制ワーキンググループ
デジタル関係制度改革検討会デジタル法制ワーキンググループ（第3回）

デジタル関係制度改革検討会デジタル法制ワーキンググループ（第3回）

概要

日時：2024年4月18日（水）15時00分から17時00分まで
場所：オンライン開催
議事次第：
1. 開会
2. 議事
  1. 法制事務のデジタル化及び法令データの整備・利活用に関する調査・実証事業について
  2. 法令×デジタルワークショップの結果について
  3. 法制事務デジタル化等に関する令和6年度事業について
  4. 質疑応答・意見交換
3. 閉会

資料

議事録

中野企画官： では、お時間になりましたので、第3回「デジタル法制ワーキンググループ」を開会させていただきます。

進行を務めさせていただきます、デジタル庁の中野でございます。今年度もよろしくお願い申し上げます。

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

次に、議事に入ります前に、本ワーキンググループの主査を務めさせていただいております、デジタル庁の冨安からご挨拶させていただきます。冨安統括官、よろしくお願いいたします。

冨安統括官： デジタル庁の冨安でございます。今年度も引き続きデジタル法制ワーキンググループをよろしくお願いいたします。

本日はまず、昨年度実施いたしました法制事務のデジタル化及び法令データの整備・利活用に関する調査・実証事業についてご報告させていただきます。この調査・実証は、法制事務の業務分析、それから法制事務エディタのプロトタイピング・ユーザーテスト、法令データ公開機能の拡張、デジタル法制の現状・未来に関する調査研究等、様々な内容を盛り込んだものになります。

また、先月8日に開催させていただきました法令とデジタルのワークショップの結果につきまして、また、今年度に予定しております開発や調査・実証につきましてもご説明させていただきます。

昨年度の調査・実証を通じて明らかになりました法制事務の課題や望まれるエディタの機能、それから技術的課題等を踏まえ、いよいよ今年度は新たな法制事務システムに向けた開発等を行ってまいりたいと考えておりますので、本日もぜひ忌憚のないご意見を頂戴できたらと思います。どうぞよろしくお願いいたします。

中野企画官： 冨安統括官、ありがとうございました。

本日の議事は、ただいま画面に投影させていただいている次第のとおりでございます。

また、議事録作成のために本日の会議の模様を録画させていただきますことをあらかじめご容赦いただきますよう、よろしくお願い申し上げます。

では、早速ではございますが、議事1に移らせていただきます。「法制事務のデジタル化及び法令データの整備・利活用に関する調査・実証事業」について、第一法規株式会社様、FRAIM株式会社様から35分程度でご報告いただければと存じます。

それでは、よろしくお願いいたします。

梅牧氏： ありがとうございます。第一法規の梅牧と申します。よろしくお願いいたします。

本日はこのような場を設定いただきましてありがとうございました。まず、私からは、画面5ページ目の法制事務の業務分析ということで説明させていただきます。

6ページ目です。法制事務の業務分析の実施方法といたしましては、次の2点について実施いたしました。1つ目は、府省庁ヒアリングを踏まえました現状のワークフロー・課題の調査・分析です。府省庁の法制事務のご経験者の方から現状の事務の非効率性や負担の状況をお聞かせいただくヒアリングを実施いたしました。ヒアリングの対象といたしましては、ご覧の5つの省庁の方々にご協力いただいております。

2つ目は、ステークホルダの調査・分析です。政策立案から法律案成立までの過程に関与する機関をステークホルダと捉えまして、法制事務のデジタル化について各機関のお考えをお聞かせいただきました。ヒアリングの対象は、内閣法制局、内閣総務官室、衆議院法制局、参議院法制局の方々でございました。

7ページ目に移っていただきまして、こちらは昨年10月の第1回ワーキンググループ会合でもご報告いたしましたが、立案担当部署による一部改正法案の検討から国会提出まで、府省庁ヒアリングを通じて把握した作業方法や使われているツールを反映した業務フロー図となります。

8ページ目からは、府省庁のヒアリングなどを通じて把握してまいりました現状の法制事務における課題分析を以下に5つ挙げております。

まず、ご覧の1つ目につきましては、手作業による改正関係資料の整合性の確認というところです。作成している新旧対照表の変更によりまして改め文を修正しなければならない場合や、新旧対照表と改め文の双方を手作業で修正する必要がありまして、併せて双方の整合性を確保するために目検等による確認作業が発生するため、それらが作業者の負担増加につながっていくというご指摘をいただいておりました。

9ページ目に移ってください。2つ目は、目視によるハネ改正の確認です。ハネ改正は通常e-LAWS等の機能を用いて確認するところで、同じ条項で引用されている箇所、自法令中の「前条」や「前二項」のような箇所は出力されないといった課題があるために、ハネ改正の有無の確認に労力を要しているといったご指摘もございました。

10ページ目に移ってください。3つ目は、発射台の特定作業です。被改正法に予定されております未施行の改正を念頭に改正案を作成する場合において、溶け込み先のどのバージョンに対して改正を行うのかを特定する作業に負担を感じ、誤りの原因になり得るとの指摘がありました。

11ページ目をご覧ください。4つ目につきましては、用例の確認です。用例検索に関する話題はヒアリングにおいてもしばしば言及されまして、法制事務においての重要度も高いことが分かっております。一方で、用例検索を行うツールの操作や検索条件自体が立案者のスキルや経験への依存が見られまして、適切な用例を見つけるまでに多くの時間を要する場合があるとのご指摘もいただいています。

12ページ目になります。最後の5つ目につきましては、用字用語、引用する法律の法律番号、誤字脱字、体裁等のチェックになります。適切な用字用語の使用、体裁を用いて表現するための定型的なチェックにつきまして、デジタル技術による支援を期待するご指摘をいただいておりました。

13ページ目からは、先ほどご案内いたしましたステークホルダの調査の分析結果ということでおまとめしております。まず、内閣提出法案や政令案に対する案文の審査を行う内閣法制局からは、各資料を目視で確認する作業において膨大な資料の体裁を確認する作業が負担になっているということでございました。デジタル化の観点では、誤りを幅広に指摘できなくても目検を補うシステムへの期待や、条文化の際に生成AIを活用することで条文づくりの負担が減るのではないかといったご意見もいただいております。

あとは内閣総務官室様と衆議院法制局、参議院法制局様でございますが、参議院法制局、衆議院法制局からは、法制執務のプロセスについては閣法も議法もあまり変わりはないということでございました。また、誤り防止対策として特段デジタル技術を用いていないとのご指摘もありました。取り上げておりますのが、衆議院法制局からは、今後も改め文方式による改正を望むといった声もいただいております。

14ページ目になります。こちらでは、その他法制事務に関する業務分析の概要をおまとめしております。1つ目が、1列目のところです。過去の法律案における誤り等の問題事例の調査・分析です。法令案に関する過去の誤り事例につきましては、法令誤り防止のためのエディタ機能や業務フロー改善に向けた提案を検討しておりました。

2列目、新エディタシステムによる業務効率化について、実際の一部改正法を題材に机上シミュレーションを試行いたしました。

3列目といたしましては、デジタル法制ロードマップの実現や法令に関するデータ、情報に係るニーズへの対応のための方策等について検討いたしました。

4点目につきましては、通知・通達の立案業務の実情につきまして、実際に立案を経験された省庁職員の方にお話を伺っております。

5点目の条例立案の実情につきましては、県、市、町それぞれの団体に調査を実施して分析したところでございます。

業務分析からは以上となります。

では、続きましてよろしくお願いいたします。

宮坂氏： FRAIMの宮坂と申します。よろしくお願いいたします。私からは、法制事務エディタのプロトタイピング・ユーザーテストについてお話しさせていただきます。

次のページをお願いします。まず、本事業の中で実際に法制事務の先ほどお話しいただいた業務分析結果を踏まえつつ、エディタシステムとして備えるべき機能要件を検討して、エディタプロトタイプの作成を実施いたしました。また、そのプロトタイプを用いたユーザーテストというのを計3回実施しまして、エディタプロトタイプの機能や誤り防止機能の効果性、もしくは操作性に対する評価・フィードバックというものを得ましたというところです。下に映っているのは、参考までに実際に事業の中で作成したエディタプロトタイプになっております。

次のページをお願いします。具体的なプロトタイプの機能性について概要説明をさせていただきます。まず、ベースとしましては、被改正法令の条文を見え消し形式で直接編集をするといった編集体験を提供しております。また、ここで実際に編集した結果の見え消し結果を基に改め文や新旧対照表というものをシステム上で自動生成するということが可能です。改め文はリアルタイムに画面の右ペイン側に自動生成するといった形で実現しております。また、自動生成された改め文側を編集することで改正法令の編集内容、見え消し内容に対しても自動で反映するという双方の往復も実現しております。

また、改正法令、いわゆる案文と新旧対照表のPDF形式、RTF形式というところでのファイル出力が実現可能となっております。下に表示されているのは実際の画面の例になります。

次のページをお願いします。18ページになります。こちらでもエディタプロトタイプの中に搭載されている整合性チェック機能の概要を説明させていただきます。誤り防止を主な目的としているものになるのですけれども、まず目次の章編節みたいなところの条の範囲や法令構造の体系等のチェックを自動的に行います。また、公用文や送り仮名等の用字用語のチェックというものもリアルタイムに行うことが可能です。

また、自法令内の引用関係や他法令に対する影響、例えば条ずれが起きたときに他法令も一緒に改正しなければいけないといったハネ改正と言われるようなものの必要性みたいなところも自動でチェックをするということが可能になります。

下の画面に実際に整合性チェックの結果の画面が表示されているのと、右下にはハネ改正のチェックという形で他法令への影響というのを自動特定した結果の一覧の画面を載せさせていただいています。

次の19ページをお願いします。機能の説明としてはこれが最後になるのですけれども、未施行の改正内容の確認機能の概要というものになります。要は自分が立案した改正案によって未来の未施行が溶け込まなくなってしまうみたいな改正ミスが起きないようなことを目的としているものになるのですけれども、被改正法令を編集作業中に、実際に編集を入れている条項に対して未来に改正が浮いている状態というか、まだ施行日を迎えていない改正がある場合に、その内容を自動的に表示してあげると、それによって自分の編集結果によって未来が正しく溶け込まなくなっていないかみたいなことを確認することを補助する機能性という形で、こちらも実際にプロトタイプとして作成してユーザーテストを実施いたしました。

では、次のページをお願いいたします。このような形で様々な機能性を有したプロトタイプを用いてユーザーテストを実施したのですけれども、その結果を簡単に概要として紹介させていただきます。まず、業務改善効果や誤り防止効果が見込まれるということが実際のユーザーテストで確認できた主な機能を4つ紹介させていただきます。

まず1つ目が、立案中の改正内容を反映した改め文と新旧対照表を自動生成する機能というところです。こちらについてもユーザーテストの実際の実施結果として、資料を作成する作業コストなどといったところの復元に効果的であるといったフィードバックが得られています。

2つ目、立案中の改正内容を反映した改め文と新旧対照表のワードファイル等を出力する機能という自動出力機能になります。こちらについては例えばシステム上で完結することが困難な作業があったという場合においても、そのワードファイルの出力が可能であれば、そこから迅速かつ柔軟な作業が可能になる可能性があるといったところでフィードバックを得られております。

3つ目、法令構造体系等を確認する機能やハネ改正の自動検知機能といったもの、また、立案中の条文における未施行の改正内容を表示する機能、先ほど画面も簡単に説明したところになりますけれども、こちらの機能性というものになります。これらについてはやはりミスが多いところというか、ミスをしないようにチェックをしなければいけない重要なところになりますので、このセルフチェック業務の効率化とミス防止につながるといった形でのフィードバックを得られております。

4つ目、先ほどのプロトタイプは全部ウェブブラウザ上で操作するようなUIになっているのですけれども、クラウド上で改正法令や被改正法令の立案中データを一元管理することができる機能というところです。ここに対しては複数人での共有が可能であるということ、また、立案中のデータのデグレード等を防止できるというところで評価をいただいております。やはり手元のローカルファイルで編集してしまうと、なかなかそれをマージするときにコンフリクトが起きたりデグレが起きてしまうということが課題としても言われていたので、そこに対する解決策としてのクラウド化ということは有効であろうというところになります。

これらの内容につきましては、次年度以降、実際の実装に向けた開発や引き続きの詳細な技術検証等を行うことが望ましいと考えております。

では、次をよろしくお願いします。ここも私のほうで続けてお話しさせていただきますけれども、法制事務のエディタに対して、先ほどユーザーテストの結果をフィードバックしたのですけれども、もうちょっと踏み込んだ技術検証というものも行っております。その中で今回は2つだけピックアップしてご紹介させていただきたいなと思います。

まず1つ目ですけれども、N段ロケット方式による改正に関するシステム上のサポート機能というものについて詳細を検討したというところになっておりますけれども、こちらのユーザーのヒアリングを実施したところ、N段ロケットの改正作業に特化したシステム上のサポートというところに対する強いニーズは確認されなかったといった結果になっております。そういったところからも本機能の実装を目指す優先度は低く、基本的な一部改正法の作業に対応したサポート機能の開発といったところを優先すべきではないかといった見解になっております。

次のページをお願いいたします。23ページ目について、一部改正法の一部改正というものに対するシステム上でのサポート機能についてになります。こちらもプロトタイプとしてユーザーテストには回していないような状態になっていて、技術検証として検討したものになっているのですけれども、まず機能の実装に向けては、一部改正法の一部改正に伴って作成が必要となる複数施行日順のパターンごとの最終的な溶け込み後条文を自動生成する技術や、改め文を正確に自動で溶け込ませる技術、要は一部改正の一部改正によって改正された一部改正の改め文を溶け込ませるといった技術、その改め文のデータ管理方式の詳細設計といったものが必要になるというところで技術的なハードルの高さというところが確認されているのと、開発の規模感といったところも含めて開発が容易ではないというところが判明しているといった見解になっております。こういったところから、まずは基本的な一部改正法の作業に対するサポート機能を優先的に開発すべきではないかといった見解を書かせていただいております。

ここまででエディタ部分のユーザーテストと技術検証の結果の報告というところになります。

続けて、このパートまで私からお話しさせていただきたいと思います。今度はアーキテクチャー・データ構造の設計・試作といったものになります。

こちらはアーキテクチャーとデータ構造の部分としてまず検討したところの1つ目なのですけれども、タイトルにも書いてある未確定施行日を考慮したバージョン管理の検討といったものを行っております。そのように注目している理由としましては、新旧対照表の中の条文の旧の条文の正しさが間違ってしまうと、法令誤りに直接的につながってしまうというところなので、正しい条文管理というところを目的として取り組んでいる内容となっております。そのために、未確定の施行期日といった順番が発生するようなものも考慮した法令データの持ち方やバージョン管理の仕組みといったところの検討と設計といったものを行っているような形になります。

次のページをお願いします。右側にはクラスのイメージとして載せているのですけれども、ちょっと細かくなりますのでここでは説明を割愛させていただきますが、まずデータ構造としてどういったところを調査・検討したのかという形なのですけれども、先ほどの説明とも一部重複しますが、未確定の施行期日を考慮した法令データのバージョン管理をするためのデータ構造というものを検討しているというところになります。改正規定のほか、改正法立案時に考慮した施行順序をデータとして管理することを想定しております。

また、アーキテクチャーの部分ですけれども、各省庁でデータを編集して相互に連携することが想定されるというところから、データの同期のための仕組みやワークフローというものを整理しております。また、こういった各省庁で非同期的・分散的に編集されたデータを一貫性を持って集約するといった目的から、ソフトウエアの開発においてソースコードの分散管理に広く利用されている「Git」の仕組みを応用したといった背景になっております。

次の27ページをお願いします。こちらでは、実際に未確定施行日を考慮したバージョン管理をシミュレーションしたのですけれども、そちらの結果と継続課題というところについてお話しさせていただきます。

まず、このシミュレーションによって明らかになったことですけれども、まず複数の入れ替わりの可能性があるような施行日順を踏まえたデータの管理というところは明示的に管理することができたといった結果になっております。

他方、この施行日順序を最終的には誰が管理するのかみたいな形、要はパターンとしては幾つかあるのですけれども、それが最終的にどうなっていくのかという管理の部分といったところのワークフロー面の要検討課題のポイントについても明らかになっております。

また、未施行の改正が複数ある場合についてになりますけれども、途中段階の各リビジョンの溶け込み後条文というもの、要は未確定が複数あってそれが入れ替わりの場合に各地点でどのような溶け込み後条文になっているのかといった、溶け込み後条文を即時公開するためにも作っていく必要があるのですけれども、こちらについてはまずはここの自動作成というものをこの観点から検討しているわけではなく、まず手動作成を想定して、そのデータを管理できるかといった観点からここでは設計をしているといったところになりますので、今後、この自動作成の支援の仕組みといったところについては検討することが有益ではないかと考えております。

次に、Gitの活用についてというところなのですけれども、今回、Git上でデータの管理を行ったというところになるのですけれども、Git上で管理するために各種情報というのはテキストファイルやXMLファイル等で管理していくわけなのですけれども、メタデータ的なところについてもテキストファイルとして管理しているというところがある関係で、これは当初から想定されるものではあるのですけれども、ファイル間を関連づけてデータを検索してくるとか、取ってくるみたいなときに、SQL一本で取ってこられるみたいな形にはなりませんので、そこの部分についての実装が必要になるというところがあります。そういったところで開発の効率性やメンテナンスの課題というところは、ファイル管理になりますので生じてくるというところがあります。ですので、こういったところについては実際の実装フェーズにおいてはより保守性の高いデータ管理手法の検討が求められるのではないかと思っているというところになります。

継続課題のところについても簡単にというところになりますけれども、新旧対照表の旧の条文と改正対象の溶け込み後条文の整合性が取れているのかといった自動チェックや施行期日の管理の支援といったところがまず一つです。管理の仕組みやワークフローというものは検討が必要だと考えております。

また、今回シミュレートした改正のシナリオなのですけれども、実際の全省庁で同時に進む作業規模というところを比較すると、限定的ではあるものになりますので、実際の作業規模での検証ということが必要ではないかなというところになっております。

次のページをお願いします。ここまでがアーキテクチャーやバージョン管理のところという形なのですけれども、最後に法令等データの構造の設計というものも実施しましたので、そこだけ簡単にご紹介して私のパートを終わりたいと思います。

まず、現行のe-Gov法令検索やe-LAWSで扱われている法令データに対する機械可読性の向上を目的として、諸外国の事例等も参考にしつつ、現在、画像で取り扱われている図・様式のデータの設計や条項のIDに対する設計といったものを実施しております。その他、次のページでまた詳しく説明しますけれども、現在、統一的なデータベースが存在していない告示に対する具体的なデータ設計というところについても実施をしているというところになります。その他、e-Gov法令検索に対してデータの公開度・信頼性というところについての調査も実施しているというところになります。

こちらは告示データの設計の概要というところで載せさせていただきます。詳細は時間の関係で割愛させていただきますけれども、データとしてはここに記載されているようなデータ数に対して実際にまず調査・分析・パターン化を行った上で、法令標準XMLに対するスキーマ拡張という形で今回告示に対するデータの対応というものを設計して、実際にデータの試作を行ったというところになります。また、現状の法令標準XMLがAkoma Ntosoと互換があるというところを踏まえて、スキーマ拡張後についてもAkoma Ntosoとの互換性の維持というところについては実施をしたというところになっております。今回試作したデータというところも告示の全てに対してやったというものではありませんので、引き続き告示の検討というところは調査の引き続きの実施、あとは告示XMLの編集方法やデータ連携の方法、データの管理方法というところについても設計・実証が必要ではないかなと考えております。

データの部分については以上とさせていただきます。

丹治氏： 続きまして、法令データの公開機能について丹治より説明いたします。

次のページで、法令データの公開機能に関する検討ということで、こちらは概要的な方向性的なお話なのですけれども、まずは目的としてデータの利用者を交えた設計・検討を行うというところ、もう一つは多くの人に法令データの公開機能の存在や現状の取組について知っていただくというところを目的に持ちました。また、現行のサービスは皆さんご存じなので読み上げは割愛したいと思いますけれども、これらの現行サービスと同等以上の機能提供を目指して検討を進めていくというところを目的に進めておりました。また、米印ではありますけれども、本事業では、公開するデータを2023年8月2日時点のe-LAWSのデータスナップを利用したというところになっております。

次のページをお願いいたします。続きまして、プロトタイプの説明になるのですけれども、まずは法令APIプロトタイプです。こちらは現行の法令APIバージョン1から以下のような機能拡張を行ったというところで大きく7つ挙げさせていただいているというところになっておりますが、幾つか事例紹介させていただくところで、まず1番目の時点指定による過去分の法令データの検索・取得を実現したというところがあります。また、従来にないような検索を実現するような2番目のキーワード検索APIを提供してみたり、3番目、4番目は、Open APIというものを使ったことによってユーザーの使用体験や提供について格段に向上を図ったというところがあったり、5番目、応答形式としてXMLに加えてJSONに対応したというところもやってみたというところになります。最後の米印になりますけれども、このような開発をニーズ調査に基づいてユーザーニーズに基づいて進めたという形になっております。

次のページをお願いいたします。続きまして、法令APIプロトタイプ利用サンプルというところなのですけれども、APIだけ提供されてもなかなかユーザーは理解が追いつかないだろうというところで、実際にこの法令APIプロトタイプを用いた利用サンプルと、リファレンスデザインの位置づけとしてサンプルのウェブアプリケーションのプロトタイピングも同時に実施したということになっております。もちろんこちらはユーザーテストや開発試行イベントでは法令APIプロトタイプと一緒に提供していったというところがありまして、また、ソースコードも利用者へ提供して、どのようなAPIの使い方があるのかなというのを示したというところになっております。

また、この開発はOpen APIというものを使っている中で、APIを使うのにとても便利なSDKと呼ばれるソフトウエア開発キットを自動で生成して開発を行ったというところで、こちらの法令APIプロトタイプ利用サンプルのほうも効率よく開発することができたというところや、実際にAPIと結合していくという中で課題抽出や改善につながったというとても効率のよい開発ができたと思っております。

次のページをお願いいたします。こちらは参考までに先ほどから言っているOpen APIというものの説明を書かせていただいて、全て紹介するのはちょっと厳しいので割愛はいたしますが、画面の下部のほうに画面のUIなどがありますけれども、今回、このウェブの画面上から実際にAPIをすぐに試して実行できるというTry it outという機能がありまして、こちらがユーザーのアンケート結果や声を聞いた限りではとても取っつきやすかったというところで、使ってみようという方が多かったのかなという印象がありました。

次のページをお願いいたします。続きまして、ここからは活動の説明のようなものになってきて、3つ紹介になりますけれども、1つ目として、法令等データの公開機能に関するユーザーテストというところで、実際に先ほどご紹介した2つのプロトタイプ、APIと利用サンプルを利用者に触れていただくユーザーテストというものを実施しております。ユーザーテストは段階的に2段階、まずクローズドテストというものと一般に公開する公開テストということを行っております。特にクローズドテストのほうは、記載にあるとおりリーガルテック関連企業や法律事務所、研究者等の協力者とありますけれども、いわゆる法令データの主たる利用者であろうというところを選定してご協力を要請したという形になっております。このようなユーザーテストを経て、特にクローズドテストの段階でAPI仕様書の説明文の不備やプロトタイプのバグの報告をいただけたというところで、公開テストに向けてプロトタイプの品質の底上げになったというところが非常に有益であったと思っております。

また、今回のPOCで本当にいろいろご意見をいただきまして、課題に網羅的に対応できているわけではございませんので、ぜひ引き続き2024年度に目指している法令APIの機能拡張に向けて開発を進めていただければ幸いでございます。

次のページをお願いいたします。2点目としましては、法令APIハッカソンという開発試行イベントを行ったというところになっております。詳細は割愛させていただきたいと思いますけれども、本ワーキンググループの構成員の方にも審査員のご協力をいただきましたこと、改めましてこの場でもお礼申し上げます。ありがとうございました。

では、次のページをお願いいたします。APIハッカソンレポートというところですけれども、簡単にご紹介いたしますと、こちらもデータの利用者を交えた進め方をしようというところと、広報目的で皆さんに知っていただくという両方を両立したイベントだったと思っております。実際に作ったプロトタイプを提供して、それを使って参加者の方にサービスを作っていただくというイベントになっております。真ん中の段に書いてあるのは受賞作品の紹介を日本語に書き起こしたというところで、読み上げは割愛させていただきますけれども、本当に全チームから作品がちゃんと出来上がりまして、このPOCの法令APIプロトタイプでも様々なユースケースの抽出が垣間見られたということで、満足度が大きいのかなという所感も受けております。

また、APIプロトタイプの仕様が先ほどご紹介したようなOpen APIのSwagger UIで提供されたことであるとか、法令APIプロトタイプ利用サンプルとそのソースコードが提供されたことというのがSNSや本イベントのアンケートから参加者の評判が非常によかったというところがありましたということを加えて報告したいと思います。また、ハッカソンをまたぜひ次回も開催してほしいという声も上がっているようなので、ぜひまた今後も継続してご検討いただければと思います。

いずれにしても、ハッカソンイベントの開催は非常に有益であることが裏づけられたかなと考えております。

では、次をお願いします。3つ目、最後になるのですけれども、もう一つのイベント、法令×デジタルワークショップというワークショップ及びセミナースタイルのイベントを開催いたしましたが、こちらは本日の議事2でデジタル庁からもご説明があると思いますので、この場では割愛させていただきたいと思います。

公開機能としては以上になります。

村木氏： 続きまして、デジタル法制の現状・未来に関する調査研究につきまして、第一法規の村木より報告をさせていただきます。

こちらの調査につきましては、デジタル法制ワーキンググループの前身であるデジタル臨時行政調査会作業部会の頃から検討されてきました、デジタル法制ロードマップの精緻化ということを試みることを実行して進めてまいりました。資料42ページでお示ししてあるデジタル法制ロードマップというものは、フェーズ0から始まって、各フェーズにおいて提供される技術や知見といったものが示されていて、それらが集積されることによってさらに次のフェーズへと進めていけるといった方針が示されたものになります。こうしたロードマップが果たして実現可能性があるのかとか、仮に実現された場合には社会に対してどういった影響が生じるのかといったところを、まず国内外におけるデジタル法制やデータの利活用に関する事例を調査することから始めまして、その上で専門家の方々の協力を得ながら技術的な面や法学的観点から分析した結果を報告書としてまとめさせていただいています。

次のページをお願いします。まず、技術的な面から見たところとしては、現時点ではフェーズ1、2の実現可能性というものは見えつつも、それと比較するとフェーズ3、4、5というものの難しさというのが見てとれています。そういった内容をこちらの資料にも簡単に抜粋して要約させていただいているのですが、この資料の下のほうに記載しましたとおり、フェーズが進んでいくと自然言語処理分野といった専門分野での知見を活用したデータ分析や技術発展の可能性が広がっていくとも考えています。また、そのためにも先のフェーズに推進できるための分野の見極めというものが重要だといった見解に至っています。

次のページをお願いします。次に、法学的な視点からということで、憲法や行政法に詳しい協力者の方に参画いただいて、分析を進めました。法令データが集積されて利活用が推進される状況が進展していきますと、情報提供にとどまらなくて法解釈まで行えるといった状況に社会が進んでいく可能性もあり得ます。この場合に法令解釈の動態性を前提として、システムを利用できるユーザーとの相互関係の下で実運用と技術進展の中でロードマップの推進を図っていくことが重要だろうといった見解に至っています。

以上のようなロードマップについての調査に加えまして、そうした技術進展が実際に行われた場合に対して各リーガルテックの企業の皆さんがどういったニーズを有し、期待を持ちかを調査すべく、次のページで示したような5社のリーガルテック企業の方たちにヒアリングを行いました。ヒアリング結果の詳細は割愛いたしますが、資料上で示してあるような取組・サービスについて既に実施されているといったところを聞き取りまして、この後、法令等データ、それに関連するようなデータが利活用しやすい状況となったら、民間企業としてこんな取組ができるのではないかといった期待感を込めたコメントをいただきました。46ページには、そういった取り組んでいきたいことについてピックアップさせていただいていますが、時間の関係でここでは割愛いたします。

次のページをお願いします。資料47ページ、48ページでは、本資料の最後として諸外国におけるデジタル法制、データ利活用に関する取組の例を示させてもらっています。最初にお話ししたとおり、本調査の最初のきっかけとして、国内外におけるデジタル法制やデータ利活用に関して幅広く探索・調査ということを行いました。その後、幾つかの代表的な取組をしている国について追加調査を行ったのがこちらの47ページに取り上げた諸外国となっています。

これらのほか、重点的にというところでは、学生参画として、大学院生の方で以前デンマークのコペンハーゲン大学での客員研究員としての経験のある方に協力いただき、デンマークでの取り組みや北欧における大学でのデジタル法制に関する研究などについても報告書本体では紹介をさせていただいています。

報告させていただく点は以上となります。ありがとうございました。

中野企画官： ありがとうございました。

それでは、議事1につきまして、質疑応答、意見交換の時間を45分程度、16時25分前後まで設けたいと思います。ご質問、ご意見のある方は挙手をお願いできればと思います。

では、安野先生、まずお願いいたします。

安野構成員： プレゼンテーションありがとうございました。非常によくまとまっており、よく分かりました。

その上で何点か質問ができればと思いました。1個目が、エディタのユーザーテストを実際に行ってフィードバックを得たというところに関連して、資料上で載っていなかった部分の感触みたいなところをお伺いできると、より解像度が上がるのでいいなと思っているのですけれども、実際使っていただいた方は、こういったエディタがあったらぜひあしたにでも使いたいという感じだったのか、そうでないとすると、こういうところまでいくと使いたいと思うのだけどなみたいな会話や感触があったかどうかみたいなところをお伺いしたいなと思ったというのが1個目。

2つ目はコメントですけれども、海外でデンマークやEU、ドイツで立法の支援をするデータシステムが既にあるということでしたので、そこはデータ構造レベルでかなり参考になる部分があると思ったのですね。なので、今後、もし機会があれば、実際にデータ構造やその中身のところのヒアリングをして、運用されているシステムですので、既にこれから我々がぶち当たるような課題に先にぶち当たっている可能性が高いと思うので、特にデータ構造は後戻りしにくいという意味で、そこのヒアリングなどもするといいのではないかなと思いました。

一旦その2つです。

中野企画官： ありがとうございます。

でしたら、ひとまず第一法規様、FRAIM様、今の安野構成員のご質問、ご意見についてコメントをいただけますでしょうか。

宮坂氏： では、エディタの部分でFRAIMの宮坂から回答させていただきます。

実際のユーザーテストの感触としてどうだったかというところのお話だと思うのですけれども、人によって意見が分かれるというところがやはりありました。結構若手の方などが中心だと、仮にこれがシステム化されたらすぐにでも使いたいという意見が多かったです。そこまで既存のやり方にとらわれが強くなくて、むしろ現状だと一太郎での編集を覚えるのが大変だというところの苦労があるので、そこがなくなってシステムで完結できるというのは物すごくいいし、改め文が自動生成されるというのももちろん目検チェックが完全に不要になるというものではないにしても非常にいいという形で、非常に肯定的な意見だというところがあります。

一方で、業務経験が豊かな方になってくると、よりこのシステムを通して業務全体を完結できるかどうかというところが結構ポイントになって意見をいただいた方があります。例えば一つの大きなステップとしては内閣法制局様の審査というフェーズがあって、そこで求められている提出物というものがあるのですけれども、そこを例えばこのシステムから自動出力したもので提出していいのですかというところが質問として出てくるのですね。そういったところのある意味業務フロー上のルールというところが変わらないと、結局幾らシステムで作っても、その後やはり一太郎に打ち直して、そこで完璧な体裁のものを作り直して印刷して渡すみたいな通常の業務フローを挟まなければいけないと、結局途中まで効率化できても、途中のポイントで引っかかってしまうと全体を通してシステムを使えなくなってしまうというところの話などが出てきて、その辺をどのように突破するかというところは、ルール決めも含めて、関係するステークホルダとのあれも含めて改善をしていかないと、システムを作ったから全部オーケーということにはなかなかならないなというところで、課題感として感じたところになります。

大きくはそういった実際のところなのですけれども、ただ、期待感としては結構大きくて、いろいろなチェック機能系などは整合性チェックなどを自動的にチェックしてくれたり、ハネ改正の検出というところでふだん苦労しているのだよみたいな話を聞かせていただきながら、そこがここまで自動化できるとなると今後に期待したいみたいなところのお話とか、内閣法制局様からも審査処理周りの自動チェックみたいなところについては非常に期待しているというところで、実際にユーザーテストの内容を踏まえた上で期待感をフィードバックとしてもいただいたというところがございます。

もし回答として不十分であればあれなのですけれども、いかがでしょうか。

安野構成員： ありがとうございます。非常に手触り感のある回答で、非常に参考になりました。

今いただいた、例えば内閣法制局に出すためのセットを全部出力できるのかみたいなところを気にしておられた方がいたというところなどはすごい面白いなと思っていて、そういう意味で言うと、導入を実際にこれからしていくに当たってこれはクリティカルに大変そうなポイントだなというのはどういうことを指摘されましたか。

宮坂氏： その一番のクリティカルなところがまさに内閣法制局審査のところかなと。なので、例えばその手前までの業務を効率化するシステムで、それ以降は従来どおりにしますみたいな考え方もなくはないのですね。ただ、結局そこをシステムで最後に突破しないと、最終的にデータベースとしてシステムで作られたマスターデータが要は一太郎ファイルではなくて法令表示XMLであるということになったときには、システム上で最後まで編集が完結していく。あくまでマスターがシステムにあるということが重要なのですけれども、そことどうしても今の業務が合わないというところで、一番課題が大きかったのはやはり内閣法制局審査のフェーズというところだというフィードバックが多かったかなと思います。

安野構成員： ありがとうございます。

これはコメントではあるのですけれども、そのように段階的に導入していくという界面が切り分けられ得るというのもすごく大きな示唆だと思いますので、それが分かったのはすごくいいなと思いました。

1点目の質問のところで私がさら問いをしてしまいましたが、2点目のほうに行っていただければなと思います。

宮坂氏 ありがとうございます。

2点目はどうしましょうか。

村木氏： ありがとうございます。

コメントとしていただいた2点目の件につきまして、今回の調査でつかんだ感度のようなものをお伝えさせていただきます。諸外国の事例を調べていく中でデンマークやEUやドイツというのは我々の調査のさらに前の年度でも詳しく調査をされていたかと思いますが、コメントをいただいたとおり、各国で先行するシステムについては分析すればするほど参考になる点があり、我々の報告書本体でもその辺りは触れさせていただいています。

ただ、データ構造についてというところでいえば、データ構想上ここの国のこういうものがそのまま参考になるか、というところまでは、我々の調査の中ではそこまで深く突っ込めておりません。コメントしていただいたように、各国の背景も含めて日本の参考になるだろうかというところを考えてからヒアリングなどを進めていくとよいのではないかと、感想レベルで恐縮なのですが、そのように感じております。

以上でございます。

安野構成員： ありがとうございます。

スタートアップでシステム開発をするときなども、似たようなサービスのデータ構造を先に知っておくと、将来的に実はこういうところでこういうデータが必要だったみたいなことが分かるので、先になるべく調べるということをやることが多くて、そういう意味でぜひ参考にできる部分はしていただくのがいいと思います。

以上です。

中野企画官： 安野先生、FRAIM、宮坂さん、第一法規の方々、ご対応いただきましてありがとうございます。

補足させていただきますと、エディタ関係は宮坂さんがおっしゃったとおりでして、プログラムを書くことに似ているのかなと思うのですけれども、要は慣れた方だといわゆるローコードツールがむしろ自分でコードを書くより効率が悪い場面があるように、条文も自分で書いたほうが早いといったところが慣れた職員だとあるというところと、少しこの法令の世界も似ているところがあるのかなと思います。他方で、内閣法制局の名前も出ましたけれども、特に法制事務の経験がそれほどない職員の間で、法制事務に関するあるルールがどこかの機関によって決められていると誤解されていることもありますが、各省庁で独自ルールでやっているということもあろうかと思いますし、もう一つ、私も実は今日の会議資料は紙で印刷しているものもあるのですけれども、文章を読むときにどうしても紙で見たいという方が一定数いらっしゃるということもあろうかと思います。これは慣れの問題なのか、そもそも画面と紙で脳が認知するものがちょっと違うという研究なども見たことがありますけれども、そういった問題もあるのか、ちょっとそこは全部デジタル完結でできるというところはすぐにはなかなか難しいのではないかという感触を持っていますが、ただ、これは引き続き検討を進めたいと思うところでございます。データ構造についても後ほどご説明させていただきますけれども、今年度の取組でも引き続き調べたいと思います。示唆に富むご指摘をありがとうございます。

続きまして、渡部先生、お願いいたします。

渡部構成員： ありがとうございます。改めて今年度もどうぞよろしくお願いいたします。Airbnbの弁護士の渡部と申します。

私からは大きく3つの塊がありまして、1、2でコメントをした上で、3でデジタル庁様ともし可能であれば、今日参加されている内閣法制局様にもしご意見をいただけたらうれしく存じます。

初めに、第一法規さんとFRAIMさんのこの資料は非常にすばらしいと思っています。私自身も業務の関係上、内閣法制局資料というものを行政文書の開示請求等を通じて個人的に非常によく勉強させていただいているのですけれども、まさにFRAIMさんと第一法規さんの調査にあるとおり、恐らく我が国の法律が隅から隅までしっかり一貫しているというのは、立案担当者だけではなくて今日いらっしゃる内閣法制局さんの見えない血と汗の結晶なのかなと思っており、非常にリスペクトしております。

その上で2番目のところなのですけれども、中野さん、もし可能であればなのですけれども、7ページをお映しいただけますでしょうか。

ありがとうございます。現在、スライドの7ページが映っているかと思うのですけれども、一つ、私も先ほどの議論に出た問題の所在として、例えば仮にエディタがうまくいった場合でも、恐らくできた資料を紙で印刷して、内閣法制局さんのほうにダンボールに詰めてガラガラと持っていって、それからコメントをまたヒアリングして、それをメモして、また自分の省に戻って、手作業をしてということをしていると、恐らくエディットをするという自分側の仕事は大分このツールで楽になるかなと思います。一方で、より大きな負担である実際に直したものをレビューする内閣法制局との間のシステムの連携ができていないと、結局それを紙に写して持っていって、またそれを聞いて戻ってというところでそこが一つの大きなペインポイントになるのではないかなと思っています。

これを感じた理由としては、例えば今、私が所属している外資系のAirbnbなどでは、ジェネラルカウンセルに上げる一つの文書について、同時に世界各国から10から20人の弁護士がクラウド上で一緒に作業して、そのクラウド上でコメントを確認することによって迅速な作業を完結しているというところがございます。もしこのツールも内閣法制局さんのレビュー、レビューに対するコメント、コメントに対する応答についても一つのクラウド上でできるというところが非常に大きな鍵になっていくと考えています。

そこで、3点目のところはまさにデジタル庁さんに質問なのですけれども、今回のツールを開発して、今年度、2024年度ですけれども、実際にこれをどのように官僚の方の働き方（way of working）に生かしていくのかというところについてぜひご知見をいただけたらと思います。

また、内閣法制局様、私の勉強不足で恐縮なのですけれども、現在はクラウド上で例えば同じドキュメントにオンラインでコメントをしていくというものではなくて、恐らく紙の資料を持っていってご精査いただいて、それを面談という形で、ウェブ面談もあるかもしれないですけれども伝えて、それをまた反映するという若干アナログなプロセスになっているのかなと思うのですけれども、もし誤り等があれば、ぜひご教示いただければ大変勉強になります。よろしくお願いいたします。

中野企画官： 渡部先生、非常に貴重なご意見をありがとうございます。

よろしければ、まず第一法規、FRAIM様から何かコメントがあればいただきまして、私からご回答させていただきまして、最後に内閣法制局の方からどなたかご発言できるのであればやっていただければと思いますけれども、第一法規、FRAIM様、まずいかがでしょうか。

宮坂氏： FRAIMの宮坂です。ありがとうございます。

まさに我々の会社も実はクラウド上でドキュメントの作成からレビューまでを完結するシステムを開発しているのですけれども、そういう観点と、今回の事業の中でこの法制事務に対してより深掘りする中で見えてきたところみたいな形で簡単にだけ、感想レベルかもしれないのですけれども、お話しさせていただきますと、やはり理想的なところは渡部先生がおっしゃるようにクラウド上での完結というところというのは間違いなく重要なポイントになってくるかなと思います。ですので、同じシステム上に対してコメント・フィードバックをするというところです。

一方で、この審査業務はものすごい大変な業務であって、読み合わせ一つ取っても様々な苦労を聞いていまして、内閣法制局様がどこまで苦労されているのかというのは私自身は詳しくは存じていないのですけれども、立案者でもあれだけチェックに苦労されているというところでさらに正確なチェックを行っているというところを踏まえると、恐らくすごい大変なのだろうなというところは感じるのですけれども、やはり紙のよさは紙のよさで実はあるというところで、チェックするときに紙を机に置いてチェックするからこそ精度高くできるという人間の能力的なところなのかもしれないのですけれども、そういった観点もないがしろにはできないなというところだと思います。ただ、全体最適化という観点でやはりクラウド完結を目指すべきだというところもあり難しいポイントだなと思っているところです。そこに対してはまだ正確にどうすればいいのだというところの解は私自身も明確な答えを今ここでご提案できるほどのものは持っていないのですけれども、そういった感想を持っているというところだけお話しさせていただきます。

中野企画官： ありがとうございます。

続きまして、私からコメントさせていただきますが、これはどちらかというとデジタル庁で法案の立案等をしている立場からの経験からのお話になってしまいますけれども、まず、我々デジタル庁が推進していますけれども、GSS（ガバメントソリューションサービス）という国家公務員が日々業務をする上での基盤になるサービスがございまして、その中でいわゆるシェアポイントという形でワードファイルをクラウド上で共有して作業するというのは、実はもうやっていることではあります。法令立案においてもそういう作業というのは少なくとも職員の間では、法制局に持っていく資料について作成するプロセスにおいてはできるという状況になります。

ただ、ここで一つ問題になりますのは、例えばオンラインのエディタでワードと同等の表現ができるかということでありまして、それがまさに今年度の開発でどういったエディタを作っていくかというところにも深く関係してくるところではありますけれども、他方で私の理解が間違っていたら後で法制局の方に訂正いただければと思いますけれども、段階的にこのGSSに各省庁も移行しておりまして、まだ法制局は移行する前ということかなと理解しておりますので、恐らくクラウド上でワードファイルなどを共有するということはまだできないのではないかと理解しております。

その上で、これは私が入省した頃から随分変わったなと思うのですけれども、現在は内閣法制局に毎回紙を持ち込んで審査を受けているということではなくて、オンラインでメールでお送りしたものをご覧いただきながら審査を受けるということもかなり一般的になっているかと思います。何らか統計を持っているわけではありませんが、自分の経験上もよくそういう形でやっていただいているなというところがございます。

その上で、一つ考慮が必要かなと思いますのは、このワークフローの中で「国会提出まで」と書いていますけれども、最終的に国会に法案を出すということは、これも私の理解が間違っていれば法制局の方から訂正いただければと思いますけれども、紙で行っているというところはありますので、そうしますと、最終的にはどこかで紙にならざるを得ないというのは現行のワークフロー上に必ずあるということは一つ我々が開発する上で念頭に置く必要があるのかなと思っているところでもあります。

以上、直接のご回答にはなっておりませんが、その上で、このシステム上で内閣法制局で持っていただいているシステムとの連携等をどうしていくかというのはまさに我々も課題として掲げているものでして、引き続きこれは本当に取り組んでいきたいと思っているところでございます。

その上でもし法制局の方から何かコメント等がございましたら、よろしくお願いいたします。

北村氏： 内閣法制局の北村と申します。

今、デジタル庁の中野さんが言われたことが全てのような気がしてはおるのですが、重複しますけれども、全てにおいて紙の持ち込みで審査をしているというわけではなくて、特に近年はオンライン審査等も大分増えていると聞いております。

また、最終的なアウトプットは紙になりますので、国会提出、閣議決定もありますけれども、紙で提出するということになりますので、最終チェックは紙で打ち出したものをチェックするという形にならざるを得ないと認識しております。

以上です。

中野企画官： ありがとうございました。

渡部先生、今のそれぞれのコメント、回答につきまして何かあられますでしょうか。

渡部構成員： 皆様、ありがとうございます。非常によく理解できました。

1点だけフォローアップクエスチョンなのですけれども、先ほど中野様がおっしゃっていたいわゆるシステムの統合みたいなところについては、例えば2025年度中とか、何かもし今、目安になるマイルストーンがもし差し支えない範囲でお話しできるものがあれば、教えていただけますでしょうか。まだ検討中ということであれば、それで差し支えございません。ご教示ください。

中野企画官： 貴重なご意見を誠にありがとうございます。

結論を申しますと、正直年限が区切られるという検討状況にはないという認識でございまして、まず官報の入稿システムを印刷局様でやっていますけれども、こちらとの連携というのは今もやっておりまして、引き続き法令XMLのフォーマットを活用してやってくという検討が進んでいるところではありますけれども、法制局の法令審査支援システムとどう連携していくのかというのは、実際のところ、お恥ずかしながら我々のシステムがそれほど法案を編集するという場面においては使われていないというのが実態としてありますので、使われていないものを連携するというところはなかなか難しいところがございます。我々も今年度から実際の開発と実装というのに取り組もうと思っているところでありまして、基本的には国家公務員が中心になると思いますけれども、まずはユーザーが便利だと思う、使いたいと思えるようなシステムをなるべく早く進めていくというのに注力しつつ、他方で法令審査支援システムとの連携・統合というのは課題として掲げられていることですので、これも同時並行で検討していくといったフェーズにあるのかなというところで、結論的には年限というのは今のところ区切れていないというのが現状になります。

渡部構成員： 分かりました。全てのプライオリティーはトレードオフなのでまさにおっしゃるとおりですし、私もその方針には違和感はございませんので、引き続き強力にご支援できればと思います。よろしくお願いいたします。

中野企画官： 貴重なご指摘、誠にありがとうございます。引き続きご支援のほど、何とぞよろしくお願いいたします。

それでは、藤原先生、お待たせして恐縮ですけれども、よろしくお願いいたします。

藤原構成員： どうも、藤原でございます。よろしくお願いします。

プレゼンテーションをどうもありがとうございました。お伺いしていてすごい大変だっただろうなと思いながら、本当にいい方向に進んでいるなと思いながら聞いておりました。

私のほうでは2つ、比較的細かい質問があります。1つ目は、22から23ページ辺りで技術検証の結果外した機能の話があったと思うのですけれども、このように技術的にハードルが高かったりニーズが強くないものを外すというのは当然やるべきで、大変すばらしいと思っているのですが、その程度がどのぐらいの話なのかなというのをちょっと確認したくて、恐らく私のほうがN段ロケットなどの一部改正法の一部改正にどういう作業が必要なのかを理解していないがゆえによく分からないところがあるのですけれども、このサポート機能を外すと何が起こるのか、つまりサポート機能がないから若干不便ではあるけれども、結局エディタ上で作業が終わるのか、それともここは突然ワードや一太郎の世界に行ってしまうのかという辺りのことを一つお伺いしたかったということがあります。

もう一点は28ページのデータ構造の話で、これも今までもよく出てきたと思うのですけれども、例の画像で取り扱われているからよく分からないものがあるという話があって、これについて機械可読データの設計をされていると書いてあるのですけれども、結局基本的にはこの画像問題というのは全て解決されそうなのか、それとも引き続き何か残ってしまうのかという辺りの感覚も教えていただければと思います。

以上2点です。よろしくお願いいたします。

中野企画官： ありがとうございました。

第一法規、FRAIM様、いかがでございますでしょうか。

宮坂氏： FRAIMの宮坂からご回答させていただきます。何かあれば、お願いします。

まず、N段ロケット、一部一部改正の程度という話になります。これがない場合についてどのようになるかというところになるのですけれども、まだ今のプロトタイプの時点だと何がどのようになるかというと、スコープとしては改正法令を直接編集することができるので、そちらにそういう内容を書けば実現はできる。ただ、それをサポートするための見え消しから改め文を自動生成して作れますとか、一部改正法の一部改正であれば、一部改正法をエディタに表示してそこを編集することで勝手に一部改正法の一部改正の改め文を作れるみたいなショートカット機能のサポート機能がまずは提供できていないというところになりますので、そこはアナログで作る必要がある。

ただ、このアナログというのを必ずしもいきなり一太郎に戻るのかというと、そこはシステムの設計次第でエディタ上でもシステム上でも作れますよというところは可能かなと思います。ただ、その際に一部改正の一部改正をすると、最終的にもともと溶け込み後条文だったものがその一部改正が直ることによってまた状態が変わるわけなのですね。そこをどうするのかというと、またそこも手動で編集をして登録するという、システム上ではできるかもしれないのですが、ショートカットする自動化機能まではなかなか支援がないみたいな状態に落としどころとして持っていくことができるのではないかなというのが私の所感というところになります。これがまず1つ目のご回答というところになります。

次に、画像の機械可読化というところについてなのですけれども、今回できている範囲としては、まず画像に対してテキスト化ということをメインにしております。ですので、例えば画像として貼られてしまっている様式データのテキスト情報というものをデータとしてひもづけて管理しておくことによって、例えばテキストでの全文検索ができるようになるとか、もしかしたらそのテキスト情報があれば、類似の検索みたいなところも自然言語処理などの昨今の技術でできますので、そういったところでの活用、もしくはテキストの解析ができるといったところでのものができたりします。

もう一個は、数式というのも画像で貼られているのですけれども、こちらについてもラテフと呼ばれるようなもの、いわゆるテキストで数式を表すような形式を裏に持っておくことによって再利用ができるよねといったところまでは、今回、設計として入れているというところになります。

ですので、主に解決できているところは、テキストを持つことによる検索性の改善というものと、そういった画像になる前のベースのテキストデータというものがあることによって再利用性が上がるというところについては一定程度解決できる設計になっているのではないかなと思います。

ただ、機械可読性というとなかなかどこまでというところがあって、例えば今回のとこでまだできていないところのスコープで言うと、様式を一部改正したいですというときに、今回、別に様式データというのは何か法令表示XMLみたいな構造化されたものを設計したわけではないのですね。なので、様式の中の一部を改正するようなものをエディタで編集させることによって自動的に要式に対する改め文を生成できますみたいなことも、要は発展系の先としてはあるのですけれども、そこまでは踏み込んでいなくて、あくまで検索性の向上とデータの再利用性を高めるというところまでが今回の事業の中で実現できた範囲といった位置づけになっているかなと思います。

ご回答になっておりますでしょうか。

藤原構成員： どうもありがとうございました。よく分かりました。

最後の点も取りあえずテキストにしてから考えるということだと思うので、いいかなと思います。ありがとうございます。

宮坂氏： ありがとうございます。

中野企画官： ありがとうございました。

これも補足的にコメントさせていただければと思いますけれども、最初のご指摘のN段ロケットや一部改正法の一部改正で一つ難しいなというのは、要は基本的に我々は公布された法令の改正案を起案するのですけれども、2段ロケットというのは今起案している改正が溶け込んだ後のバージョンをまた改正するということになり、また、一部改正法も溶け込む前の一部改正法を取り扱うという点です。よく発射台と言われる改正の対象の法令のバージョンが間違っていると、改め文そのものが間違ってしまうことになりかねなですけれども、要すれば、一部改正法は公布されているという意味では確定しているものではありますけれども、いわゆる溶け込みデータとして我々がふだん取り扱っていないものを改正しにいくというときに、これは人がやる分には実はあまり業務内容に差異はないのですけれども、システム上で編集する場合は編集対象の法令データの管理をどうするかという別の論点が出てきます。技術的には人がやる分にはそこまで普通の改正と難しさに差がないのですけれども、システム上の難易度が格段に上がってくるという可能性がございます。その上で、宮坂さんがおっしゃったとおりですけれども、例えば差分を新旧にするとか、溶け込みベースの差分を新旧にするとか、改め文を吐き出すといった機能であれば、これは一部改正法の一部改正であっても2段ロケットであってもできることだと思いますので、全てアナログになるということは必然的ではないのかなと考えているところでございます。貴重なご指摘を誠にありがとうございます。

続きまして、八木田先生、お願いいたします。

八木田構成員： ありがとうございます。

今回のスライド資料は非常に網羅的かつ分かりやすい内容で、まとめていただいて本当にありがとうございました。

私からは2つだけご質問させていただければと思っておりまして、一つは技術的なところで、資料1の26ページのGitのところについてご質問をさせていただくのと、あと全体像についてのご質問をその後にさせていただければと思っております。

まず、最初に資料1の26ページについての確認のようなご質問になるのですが、ここのところは以前、1個か2個ぐらい前の会合のタイミングで、未確定の施行期日を考慮した形でバージョンを管理するのは非常に難しいという話があったかと思いまして、その中で議論としてGitを採用するかしないかみたいなところが結構大きな論点としてあるのではないかということを当方から発言させていただいたところがあったかなと思います。今回、26ページで書いていただいた内容を拝見するに、「（参考）」のところになるかと思うのですけれども、このようなデータ構造を採用することによって、うまくGitを使って管理ができそうかなということを記載いただいているのかなと理解しておりまして、なので、全体としては今後、Gitを使っていくことを念頭に置きつつ進めておくので大体よろしいのではないかということがご提案いただいている内容なのかなと受け取ったのですが、それは合っていますでしょうかという確認のご質問になります。

中野企画官： こちらは1つ目でお答えさせていただいたほうがよろしいでしょうか。

八木田構成員： それでお願いします。

中野企画官： かしこまりました。

まず、FRAIM様、第一法規様、いかがでしょうか。

宮坂氏： ありがとうございます。FRAIMの宮坂からご回答させていただければと思います。

先に結論から申し上げると、Gitが最終的にシステム化で実装していくに当たってベストなものであるとは考えていないというところが、様々な検証の結果、今のところたどり着いている所感というところになっております。

今回、Gitをどのように活用したのかを簡単に言うと、認証付のETLとして、かつ、省庁ごとにデータを分散して管理したものを統合できるという観点において、そこの点についてはもう既にGitで実装されているところであるというところで、そこを再開発する必要もないよねという観点からGitの採用をして構築をしているというところになります。

また、今回のデータ構造であれば、Git上でそれを表現するということもできるということまでも、今回のシミュレーションしている範囲においては逆にそれでできているということを検証しているということになりますので、そういう意味ではGitを使って実現性があるかないかという観点においては、実現性はあるのではないかというところは今のスコープの範囲においては言えるのではないかなとは思うのですね。

一方で、今、Gitがベストだと思っていないと言い切るかどうかというのは難しいのですけれども、ベストだと言い切れないとは少なくとも言えるかなと思う点については、本来の例えばRDBやNoSQLといったデータベースを採用することによって得られる恩恵は、システム設計の効率化やデータの取得の効率化など、データというのも単体のファイルを取ってくるだけで処理が完結するものでも必ずしもないので、そういったことを考えると、少なくともGit上でファイル管理されているものに対して直接システム上の各処理がダイレクトに呼びに行って処理を完結するということについてはなかなか開発工数の観点からも処理速度の観点からも現実的ではないのかなと思っているところになります。

ですので、その場合はどういうことを考えるかというと、メインのデータはこのようなGitベースのデータを管理しつつ、その1個上のレイヤーに例えばRDBなどといった処理に最適なデータを一個持って、ある意味各種処理を高速に行うためのデータとして一個レイヤーを分けたところとして管理して処理を実現するということも考えられますし、いっそのことデータの管理自体も、今回の設計は結構抽象度高く概念的なところからブレークダウンしたところもありますので、この設計はそのままGitではなくて例えばRDBなどに対しても概念レベルの設計としては適用可能なものになっておりますので、最初からデータの管理としてもRDBを使おうとか、NoSQLのデータベースを使おうみたいなことも十分考え得るのではないかなと思っております。

現状の見解として回答させていただきました。

八木田構成員： ありがとうございます。よく理解させていただきました。

すみません、私が毎回この点をお伺いさせていただいているのは、恐らく作ろうとしているもので何が実現できるかというか、表現可能性の限界をこれが一定程度規定すると考えているのですね。ですので、この辺りをどのように技術選定していくのか、どのように設計していくのかというところはものすごく重要かなと思っておりまして、お伺いさせていただきました。ありがとうございます。

若干時間が押していると思いますので、簡潔に2点目をお伺いできればと思っていますが、2点目は資料1の20ページのところになります。これはもしかすると先ほど藤原先生からいただいた、この機能を外すと結局何が起きるのだろうみたいな点に若干近い話かなと思っているのですが、20ページで例えば業務改善効果や誤りの防止効果が確認されたとおっしゃっていただいているところで、これがそれぞれについて全体のうちどれぐらいの重要性の部分についてどの程度改善効果が見られたのかという温度感というか、重みづけみたいなところがぜひお伺いできるとうれしいなと思いました。

つまり、例えば資料1の7ページで全体の作業オペレーションを非常に分かりやすい図によって示していただいていると思うのですけれども、それぞれ各工程においてものすごく大変な要素がある、つまりここはすごく工数がかかるとか、ここはこういう間違いが起こりやすいみたいなことがいろいろあるかと思うのですけれども、今回、POC的に作っていただいたプロトタイプによって、この工程はすごく重要で、ここはすごい工数がかかっているところのここの工数が90％削減されたのかとか、あるいはこの部分というのは誤り発生率が非常に高かったところがほぼゼロになりましたといった部分のビフォーアフターというのがもし見えるような形になっていると、非常に分かりやすいかなと思った次第でした。もしかするとこれは昨年度というよりは今年度の調査事項になるかもしれないので、そういったことでも特に問題ないかなと思うのですけれども、ぜひその辺りについても現段階で何かございましたら、お伺いできればなと思った次第でございます。

中野企画官： こちらはもしよろしければ、大変恐縮ですが、まず私からお話しさせていただければと思います。

先ほどの藤原先生のご質問に戻ってしまうところもあるのですけれども、優先順位が低いとご提案いただいている先ほどのN段ロケットや一部改正法の一部改正は、正直何％かというのはなかなか試算がしにくいところがあるのですけれども、ざっと我々で法令データを見ておりますと、厳密なところはなかなか言えないのですけれども、恐らく発生件数が数パーセントぐらいではないかと推測をしているところでございまして、他方で、20ページに書かせていただいた機能は、例えば1つ目の改め文と新旧対照表を自動生成する機能というところで申しますと、まさに八木田先生からご指摘いただきました7ページでいうところの新旧対照表の作成や本則起案など、場合によっては附則起案というところをこの枠の中だとカバーするというところになりますし、ワードファイル等を出力する機能というのはなぜ書いているかといいますと、エディタ上で完結しないような改正形式があったときに、これは対応できないから最初からエディタを使わないでおこうとなってしまうと、先ほど申し上げたとおりなかなか発展しないシステムになってくるだろうというところがありまして、例えば複雑な表を組み込むなどの前の段階までは使えるようにして、楽になるパターンというのを増やしていくためには現状は必要不可欠なものかなと思って入れさせていただいているというところと、ハネ改正の自動検知機能というのも先ほどのワークフローの上段の右から2段目の附則起案の経過措置、ハネ改正等ができるものになりますし、このワークフロー全体に関わりますけれども、先ほど渡部先生からもありましたけれども、今はクラウド上でそれぞれが作業してからファイルをがっちゃんこするみたいなことをやっておりますから、これは全部のワークフローに対して効果がある機能になってくるというところで、実はここで誤り防止効果や業務改善効果が見込まれる機能というのを全て網羅できているわけではないのですけれども、効果があるだろうというところで、これは実は定量化も試みたのですが、なかなか取り方が難しいというか、我々は究極的にはこういう機能を実装したプロトタイプを作って実験してみて、今の我々が使っているようなワークフローでやった場合と新たなシステムで実験してみて例えばどれだけ減ったみたいことができればいいのですが、なかなかそれもできなくて、どうしてもアンケートみたいなものになってしまうというところがありまして、これは今年度の調査・実証等でも引き続きそういう定量化のような分析に取り組むことができればと思っているところではあります。できるだけそれぞれのワークフローで汎用的に使える機能というのを選んでいただいているとは思っているところですが、その上で第一法規様、FRAIM様から何かコメントがありましたら、よろしくお願いいたします。

宮坂氏： 中野さん、ありがとうございます。

簡単にだけ、FRAIMの宮坂からお話しさせていただきますと、ユーザーテストを実施した感触としてなのですけれども、結構これはユーザーさんや省庁さんごとに違うというところが見えてきました。ユーザー全体を平均して見てしまうとどうかというのはあるかもしれないのですけれども、全然違っていて、例えばやたら複雑な表の改正が多いから新旧対照表を作るのが物すごく大変だというふうに苦労されている省庁さんや、一方でハネ改正の自動検出ですごく喜ぶところもあれば、実は我々の改正においては大体パターンが毎年決まっていて、ハネの対象というのは分かっているので、そこまでそれは課題に思っていないのですという省庁さんもいたりといったところから言うと、改正する法令の特徴に依存するのかもしれないのですけれども、そういったところによってどこの業務が特に負荷が高いのかというところは傾向が出てきそうだなというところになります。

なので、一概に全般を通した定量化というのは難しいかもしれないのですけれども、こういう傾向の場合はみたいな形でうまく分類していくことがまず第一歩なのかなと、ユーザーテストを実施した観点からは感じたところになります。

何か補足がある方がいれば。

吉田氏： 先ほどのGitの議論とも共通しますが、技術的に100％改め文を溶け込ませることができないので、Gitで被改正法をバージョン管理するということになるのですが、そもそも自動改正できない特殊な改正法をやめてしまえば、技術的に100％に近い形で改正法ができるとか、改め文方式自体が省令以下のようになくなれば、100％にできない話ではないと思います。

ですので、技術側でいくのか、そもそもそういう法律化の弊害になることと今までの業務のトレードオフみたいな話というのはここではあまり踏み込めていません。そういった意味ではGitの件であるとか、ヒアリング対象からそもそもなくしてしまえばいいのにみたいな話も出てきたりするのです。

ただ、現状の改正手法は維持するということが前提で、ここのテストが網羅的であると言っているのは今の既存業務ですので、そことのトレードオフというのはかなりある話かなという認識でした。

若干の補足でした。

八木田構成員： ありがとうございます。

中野企画官： ありがとうございました。

でしたら、次に角田先生、お願いいたします。

角田構成員： こんにちは。よろしくお願いいたします。

まず、この報告書は私も皆さんがお話ししていらっしゃいましたように非常に感心いたしましたし、とてもよい報告書として読ませていただきました。特に誠実で正直な印象を受けておりまして、例えば今回議論されていた多段ロケットなどの記述箇所で、できること・できないことを正直に書いてくださっているという点などです。強いて申しますと、八木田先生のおっしゃるように定量的に報告できる部分が増えれば、さらに嬉しいですが、そもそもこの報告対象には定性的な面もありますので、そういう部分に関しては現時点では定量化しにくかったかもしれないと思っております。

そこで、まず、このご報告がよろしかったという大前提で述べさせていただきますと、これからのシステムを考えていくときにも、あまり完全性ばかりを目指していただきたくないというか、未来の理想として目指して頂くのはよろしいのですけれども、毎年毎年とか、2から3年先にすごいものができるという感じになると、結局使われないものになってしまったり、現状分析が雑になってしまったりする懸念がありますので、今回のように現状分析を丁寧に引き続き実施いただけたらよろしいかなと思いました。

その上でいくつか今後のことについて、今回のご報告の中で、思いついた順になってしまって申し訳ないのですけれども、述べさせていただきます。まず、内閣法制局さんのお仕事のお話が何回か出てきました。法制執務のやり方というのは省庁ごとや部署ごとに結構異なったりしますので、内閣法制局さんでもそこを考慮された組織になっていると思いますし、そこをシステムで画一化するというよりも、例えばスタイルシートのような形で外づけすることによって省庁さんごとに対応していただくとか、あるいは機能としてもオプションとして着脱できるような形で、統一的にするというよりも一番共通のところを土台として構築しておくような方向性でしたらよろしいかと思います。ただ、あまりに完全性を目指し過ぎて、しかも現在行われている仕事のやり方を大きく変える部署が出てきてしまうということがないようにしていただけたらと強く感じています。

そういう無理やりなところを少しでも減らそうという観点で述べますと、この一連の活動はDXなのだから無理やりのところはあってもよいという見解があるのかもしれないですが、私は例えば内閣法制局さんが昔から使っている、法令審査のシステムがありますけれども、それとの連携も、実はそんなにきつい連携にしなくても、審査する側とされる側が同じシステムというのはいかがなものか、という考え方もあります。もし、統一化するのでしたら、データ形式などを合わせるような客観的なものはよろしいのですけれども、判断や解釈に関わるような部分まで、あまり無理にシステムを統一してしまう必要はないのかな、とも思います。

次に、紙の話も出ていましたけれども、韓国などですとたしか10年以上前には、国会に電子化された法案が提出されていたようですので、そういうデジタル化も「あり」かとは思います。ただ、逆に審査の過程や作成の過程で見直すときにやはり紙を使いたがる人はいらっしゃると思うのです。デジタルで全部できるよ、と言うかもしれないですけれども、それでも多くの年配の人ではなくて若い20代の人たちでも、例えば、結局は紙に印刷してチェックしたほうが作業しやすいという方もいます。現時点では紙であることの作業の利点というのはそれなりにあり、これからメタバースなどで仮想現実がすごく発展して紙面を扱うかのようにデジタルデータを使えるようになればよろしいのですけれども、現在の多くの貧相なデジタル環境のモニター上で作業するときには、マウスも1個だけですから、紙だったら両手で使えるわけですので、そういったことを考えてもまだまだ紙の利便性というのも一応は念頭に置いておいてよろしいのかなと思いました。以上が本日のお話を聞いていて、コメントしておきたいと思った点です。

それから、私は以前、告示のデータを作成されている職員の方々から、いろいろなお話を聞く機会があったのですけれども、先ほど数式という話が出ていましたが、化学式などを使う省庁さんというか、そういう告示を出す国の機関もありまして、そういう部署では告示データの標準化のようなものがあると、デジタル庁で最初からデータベースとしてご用意していただかなくても、データ形式の標準が示されていれば、各部署でもそういうものに興味を持ってデータベース化を進めている方というのはある程度いらっしゃいますので、そういう方々にその標準に沿っていただければ、将来的にはどんどん統一に向かうのかなと思っておりました。そこで、さきほどのLaTeX形式の提案というのも結構よろしいように思いました。多分告示を起案しているご本人たちも告示の文章内で式を書くときには内部的にはLaTeX形式を使っていることもあると思います。

最後に1点、行政法の先生方からのヒアリングにおかれまして、法解釈の方向性の話も報告されていましたが、まだ未来のことですのでここであまり細かく議論する必要はないと思うのですけれども、述べさせていただきます。まず、法解釈といったときに、立法府と行政府と司法機関の三者があって、この順番で、法解釈は複雑になる傾向にあります。一旦法律が施行されてしまったら司法の側では多様なケースに適用していきますので、解釈の多様性も大きくなり、法解釈も複雑になります。それに対して立法府というのは、最初に法制度で着目しようとしている対象者をこういうふうに誘導したい、という立法者側の意図が最初からある程度想定された上でつくられているので比較的ですが解釈しやすいです。また、行政府の方は、行政関連の法規がほとんどですが、訴えられることも想定しますし、運用で対応することなど、いろいろ詳細まで可能な解釈を現場では考えますので、複雑さは三者の中間ぐらいなのですが、このような側面のある三者の法解釈に関して混ぜて議論することにはやや抵抗を感じます。学術的にはより一般的で普遍的な説を考えたくなりますし、法学分野では立法的な対処はいわば奥の手であって、極力解釈論を駆使できることが目指される傾向にあります。そこで法学的な解釈論をベースにしますと、将来法解釈にITやAIを導入する際にも、司法の問題設定のほうに寄って行ってしまう可能性もありますので、そうなるといきなり司法における解釈の難しさに立ち向かうことにもなりかねません。そこで、解釈問題に手を付けるにしても、最初は立法のほうから行ってほしいと思いました。

少々長くなってしまいましたけれども、私からのコメントは以上です。

中野企画官： 角田先生、いつも大変多岐にわたり非常に重要なご指摘を誠にありがとうございます。いずれも深く受け止めさせていただきます。

FRAIM、第一法規の皆様、何かコメント等がありましたら、手短にお願いいたします。

宮坂氏： ありがとうございます。

まさにおっしゃっていただいたポイントは非常に重要な点が多くて、かつ、間違いやすいポイントとしてシステム化をするときについ完璧を求めてしまって統一化を求め過ぎてしまうことによって使えなくなってしまうみたいなところに対して逆に重要な気づきをおっしゃっていただいたなと思っております。ありがとうございます。

吉田氏： 角田先生から今、ご助言いただいた画一的なという部分においては、システムチェックが一つの手法でいいのだろうかというのは今回のプロジェクトでも何度か話題になりました。作る側とチェックする側が同じロジックで同じことをチェックしてしまうと、システムが間違うと全部抜けていってしまいますので、チェックする側が例えばハネ改正のチェックをするというロジックと、ハネ改正を作成するシステムのロジックというのが同一だと、結局ミスが出やすくなるのではないか、システムバグがそのまま結果になるのではないかという議論はあったのですが、一つのロジックで追いかけるのがいっぱいいっぱいだったというのが実際のところです。

一応、画一的なところに関しては議論があったことなのですが、ただ、できていないということも、正直ベースなのですがお伝えいたします。

角田構成員： とても誠実なご対応で、とても安心しています。ありがとうございます。

中野企画官： ありがとうございました。

米田先生、いかがでございますでしょうか。

米田構成員： ありがとうございます。

大分言い尽くされてしまったので、非常に充実した議論が展開されてよかったと思います。報告いただいた内容は、角田先生のおっしゃったとおり、できること・できないことを明示するという志向がはっきり現れているので、この次のステップに進むに当たっても参考というか、重要な情報を提供していただけたのではないかと思っているところです。

今、課題になってきているのは、ひとつひとつの成果が、どこまでできているかを示すことだと思います。その点で、もう少し解像度が上がるといいなと思ったのは、実際に使う人たちにとってどこがデジタル上でできてどこは手作業でやらなくてはいけないのかという新しい線引きが生まれるということがはっきりしたと思うのですね。それをはっきりさせることが次の課題になるというところだと思うのですけれども、こういった認識でよいのかを確認しておきたいと思います。

中野企画官： ありがとうございます。

第一法規、FRAIMの方で何かございますでしょうか。

宮坂氏： ありがとうございます。

エディタの部分をメインで進めていたFRAIMの宮坂から回答させていただきますと、おっしゃるとおりかなと感じております。結論から言うとまさにそういうところになるのですけれども、やはり全て最初からデジタルでというところにはならないところ、全部システム上で完璧にならないところをどのように移行フェーズを経ながら従来業務をやっていくかというところが非常にポイントかなと思っておりますので、おっしゃっていただいたとおりかなと思っております。ありがとうございます。

米田構成員： そこをどれだけ具体的に示せるかというのが、システム自体の普及やマニュアルを作るときに最も重要なところになってくると思うので、ある段階や実装する段階ではそこに力点を置いて情報提供等もいただく必要があるかなと思ったりしています。

以上です。

中野企画官： ありがとうございます。

まさに米田先生のおっしゃるとおりで、今回、プロトタイプを作っていただきましたけれども、いろいろな機能を盛り込もうとすればするほど、いろいろなユースケースに対応しようとすればするほど非常に複雑になっていくというのは痛感するところでして、最終的なシステムの在り方というのは理想論・理想像があると思いますけれども、ひとまずどういうところから手をつけるのか、人の手を残すところをどこにするかというのはまさに今後の開発の肝になってくると思います。皆様、貴重なご指摘を誠にありがとうございます。

では、時間も押してしまって私の仕切りが悪くて大変恐縮ですが、残り2つの議題についてそれぞれ事務局から合計5分程度でご説明させてだきまして、その後、10分少しでご質問、ご意見等をいただければと思います。

では、よろしくお願いいたします。

山内参事官補佐： よろしくお願いいたします。事務局の山内でございます。

先月開催しました法令×デジタルワークショップの結果についてご報告させていただきます。資料や模様についてはデジタル庁ホームページでも公開しております。また、一部これから公表準備するものもございます。詳細についてはぜひそちらもご覧いただければと思います。

概要でございます。法令の仕組みや法令APIについて学べるイベントとして開催しております。経緯ですけれども、法令APIハッカソンの参加者から、法令文書や法令データに関する基本的な技術者向け情報が公表されていないといった声をいただきました。こちらの情報は法令データや法令APIを使った開発には必要だと思いますので、そういった基本的な法令の仕組みに関する情報、それから法制事務の実態に関する情報を提供する機会として開催したものでございます。対面会場、オンライン会場のハイブリッド形式で、合計200名を超える方々、技術者、法曹・リーガルテック関係者、研究者等の参加者の皆様にご参加いただきました。

プログラムの個別の内容について、次ページ以降にございます。1つ目のパートで法令×デジタルの取組紹介をさせていただきました。こちらは資料を公開しております。パート2は法制事務の実態の紹介ということで、パネルディスカッションを行いました。右側にございますような実物の法制事務の書類を使って、こういうところが困っているのだということをご説明させていただきました。パート3以降は法令データ、法令APIの使い方といったものを法令の仕組みの解説とともに行いました。サンプルコードを用いた開発の実演を行い、最後は参加者の皆様に、法令APIプロトタイプや現状提供している法令APIを使って実際に開発を行っていただくというワークショップも行いました。

こちらは参加者の皆様からの反応でございます。法改正における課題が分かっただとか、法制事務デジタル化が負担軽減につながることが分かったといったご反応をいただきました。それから、これは法令APIを使えばできるのではないかという気づきを持っていただくこともできました。法令になじみがある参加者からもポジティブなご意見をいただきました。

このように必要な情報を発信し、体験いただくことで今後の開発のきっかけになる。それから、あまり知られていない法制事務の情報やニーズの存在を知っていただき、関心を持っていただくといった、オープンな議論の効果が示唆されました。今後もこういった情報についてサービス開発、技術開発につなげるためにオープンに公開していくとともに、法令APIの機能向上を今年度目指しておりますので、こちらを進めてまいりたいと思います。

ワークショップの説明については以上でございます。

野口参事官補佐： 引き続きまして、私、デジタル庁の野口と申します。法制事務デジタル化等に関しまして、令和6年度、今年度の事業について簡単にご説明さしあげます。

こちらは2事業を準備しておりますけれども、現在、調達手続の最終局面にございまして、来週目途にプロジェクトを開始するべく、調達手続を進めているところでございます。プロジェクトが開始いたしましたら、速やかに受託事業者と共に実施計画を調整することになっておりますので、こういった調整の中で事業内容について詳細化した上で、また次回のWGにでもご説明をさせていただきますので、ご意見、ご助言をいただければと思います。それでは、簡単にご説明さしあげます。

1つ目でございますが、e-LAWSに実際に機能を実装していくための開発になります。今日のWGの中でも、界面で切り分けられるのではないかであったり、働き方改革にどう資するのかみたいなお話もありましたけれども、このe-LAWSの機能実装に当たっては、実際の法制事務の現場の方の役に立つようなシステムを早期に提供できるように、着実に進めていきたいと考えております。

具体的には、資料の左側にございますけれども、関連資料を編集できる最低限の機能であったり、今日の説明でもございましたけれども、Wordファイルの出入力を可能とする実装の機能、あるいは官報入稿といった中長期的なフローも見据えた必要な機能の開発といったことを行っていきたいと考えております。

また、資料の下の方になりますけれども、③ではアラート機能であったり、様々な整合性のチェックの機能の実装であったり、あるいは④でございますけれども、昨年度の実証事業の中で開発した法令APIについて、こちらを本機能として実装することを進めてまいりたいと思います。

次のページになります。こちらですが、引き続き実証事業を行っていく項目になります。今日の説明の中でも必要な機能を見据えて優先順位をつけて研究を行っていく必要があるといったお話もございましたし、また、例えば③になりますけれども、告示についてもどういったデータ構造としていくかについては、しっかりと利用実態やニーズを含めてどういったデータ形式がよいのかということを研究した上で機能実装を見据えたプロトタイピングを行っていくことが重要と考えております。今後も引き続き、WGの先生方にもいろいろご助言やご意見をいただければと考えております。

簡単ではございますけれども以上とさせていただきます。何かご不明な点がございましたら、質疑応答いただければと思います。

中野企画官： ありがとうございました。

今、投影しています今年度の開発と調査実証というものは仕様書の項目から拾っておりまして、今、具体的な取組というのをまさに受託していただける事業者の方々と詰めていくというところにありますので、詳細の具体化はこれからというところでありますけれども、ご質問、ご意見等がございましたら、10分ほどしか時間が残らなくて大変恐縮でございますけれども、挙手をいただければ大変ありがたく存じます。

米田先生、お願いいたします。

米田構成員： ほかに発言者がないようなので少し広めの発言をさせていただきたいと思います。これまでの作業の中で結局最初に議論していたいわゆる法令のデジタル正本というものが今の段階でどのような絵になったのかということについて、来年度の課題として示していただけたらと思っているところです。これは実際にこの機能を組み込んだ後、我々国民から見て法律の正本としてみなすべきものというのは、これまでは売られている六法であったり、どうにかe-Govの法令検索であったりみたいな形だったのですけれども、それがどんな形になるのかということについてもっと明確になるようにしたほうがいいだろうと思っているところです。

もう一つは、ここまで様々なものを手作業でやってきて、それぞれに持ってきたスキルやノウハウや知識などのルール化してきた前提のような知識というのが、システム化されるとそれを知っている人が減っていくというのが社会的な現象として当然あり、時間がたつとなぜこうしたのか分からなくなってしまう問題というのが必ずつきまとってくるということになると思います。同時にシステムそのものへの作り込みのノウハウも同様です。そのこれまでやってきた作業というのが何かをある程度残せるような形というのも重要かと思うので、システムをつくる中でそのバックオフィス的な作業になってしまってあまり前向きになりにくいのですけれども、そういった記録もしっかり残せるような形を取っていただく必要があるかなと思っているところです。

感想めいたもので申し訳ありませんが、何かあれば、よろしくお願いします。

中野企画官： 米田先生、ありがとうございます。

まさにデジタル正本は、そもそも法令が公布されているのは官報ですけれども、今日も出席いただいております内閣府が中心になりまして、官報そのものもデジタルが正本になるという法律も成立しまして、まだ施行はされておりませんけれども、こういう大きな事情変更もありましたので、現時点でどういった整理ができるかというのは大きな宿題だと思いましたけれども、こちらは明確化してご意見をいただければと思いますので、非常に重要なご指摘をありがとうございます。

あと、ノウハウの点は、実は今年の開発でも、パワーポイントでは省略されていますけれども、そもそも我々がやっているこの法制事務はどういう仕事をやっているかというところを今回まとめていただきましたけれども、これを公表に向けて精査しております。膨大な量がありまして、今、最終的な精査をしておりますが、なかなかこの粒度で、しかも内閣法制局様や衆参の法制局様というところにヒアリングして作ったものというのは私も見たことはありませんでして、これは詳細に公表させていただきたいと思っておりますし、我々の法制事務はどうやって行われているかといったノウハウみたいなところも何らかデジタルで整理をして、先ほどの法令×デジタルワークショップでも世の中にお示しした部分はありますけれども、公開できるものは公開したいと思っていますので、そういったノウハウが完全に失われてしまって最終的に我々の立案者としての能力が下がってしまうようなことがないようにこれは考えているところですので、対応させていただければと思います。貴重なご指摘を誠にありがとうございます。

続きまして、安野先生、お願いいたします。

安野構成員： ありがとうございます。

私からも1点コメントでして、来年度、実際の機能開発というところに入っていくということだと理解していますが、ある意味機能が開発されたけれども誰にも使われてはいないよというのが最悪のシナリオだと思っていまして、目標として実際に使われて成果が出始めるというところを目指していただきたい。そのときにある種KPIを設定して、これだけ使われたよとか、この作業では何％くらい効果が出たよというのも併せて来年度終わったときに示せるようになっておられるといいのかなと思います。

さらに言うと、ターゲットとする業務やターゲットとするユーザーは最初はかなり絞ったほうがそういった実際のオペレーションにつながりやすいと思うので、そこは結構大胆に絞ってしまってもいいとは思います。最初は例えばデジタル庁の中の法律を編集する業務の浸透度が100％であるとか、そういう手の届きやすいところから目に見える結果を出すというのが進め方としてはいいのではないかと思ったので、コメントでございました。

中野企画官： 誠にありがとうございます。

KPIの定量的な指標というのはおっしゃるとおりでして、実は仕様書の細かいところにこういうログなどがちゃんと取れるようにすることを、盛り込んでいるところでございますし、ターゲットや業務を絞ったほうがよいというご指摘についても我々も昨年度のPOCを通じて本当に痛感したところになりまして、実は今、我々デジタル庁でこれから事業者の方々と契約が相成りましたら議論してまいりますけれども、まずは本当にこれが便利なものだと認知をしてもらうべく、使ってもらえるものにしたいと考えております。また、完璧なものが10年後にできますというものを目指すのではなく、例えばすぐに何か効果を発揮できて、実装も比較的容易なもの、それは業務やターゲットを絞るということと考えておりますが、そのためにどうすれば良いかという議論を行っておりまして、まさに今日、構成員からいただいたご指摘も踏まえて具体化を進めたいと思います。貴重なご指摘を誠にありがとうございます。

安野構成員： ありがとうございます。

実際に使われ始めると、ソフトウエアというのはどんどん磨かれていくのですけれども、使われないと本当に意味のないものができて終わりになってしまうので、使われ始めるというところは結構重要だろうなという趣旨のコメントでした。ありがとうございました。

中野企画官： 貴重なご指摘を誠にありがとうございます。

実は今日、増島先生もご出席いただいておりまして、もしご対応いただけないようであればミュートのままにしていただければと思いますけれども、もし何かございましたら、お願いします。

増島氏： 大丈夫です。ありがとうございます。非常に活発なご議論をいただきましてありがとうございました。

進められていただいているものも非常に今までのいろいろな活動を生かした形でやられていらっしゃいますし、今、ご意見をいただいた各委員の先生方も非常に高いレベルでのコメントをいただいておりまして、間違いなくこれが進んでいくなというのを拝見していて大変うれしく思いました。

僕自身も、この辺になってくると何か僕が言える領域でもなくなってきているなという感じもちょっとあったのであれなのですけれども、聞かせていただいて非常に心強かったという感想だけでございます。どうもありがとうございます。

中野企画官： 貴重なご意見をいただきまして誠にありがとうございます。大所高所の観点から引き続きご支援いただければ大変ありがたく存じます。引き続き何とぞよろしくお願いいたします。

でしたら、少しお時間は早いですけれども、あと3分ということですので、本日は貴重なご指摘、ご意見をいただきまして誠にありがとうございます。本年度の開発実証、そして取組を、本日いただいたご指摘を踏まえまして具体化していきまして、またご相談させていただき、ご指摘いただければと思います。

では、最後に審議官の蓮井からご挨拶させていただければと存じます。蓮井審議官、よろしくお願いいたします。

蓮井審議官： 先生方、本当にお忙しいところ、今日もご参加いただきましてありがとうございました。審議官の蓮井でございます。

本日、本当に闊達にご議論いただきました。誠にありがとうございます。特に昨年度の調査・実証につきましては、本日オブザーバーでご参加をいただいております内閣法制局、総務省、そして関係省庁の皆様方にもユーザーテストなどでご協力いただきました。その結果もあるかと思いますが、今日は先生方にいろいろと高いご評価もいただいたと思っております。ありがとうございます。皆様方のご協力もあってのことでございまして、改めてこの場を借りてお礼を申し上げます。

法令のワークショップでございますけれども、多くの参加者の方々に法制事務について知っていただいて、また、今後の開発で参考となる示唆に富むご指摘もいただいております。今後もできるだけ情報をオープンにして、行政機関の中に閉じない産学の多くの方によるツール・サービス開発や技術開発を進めたいと考えております。

あとは、今年度の開発と調査・実証も開始されます。昨年度の調査・実証について、先ほど大変ありがたいご指摘、ご意見をいただいたところでございます。昨年度の調査・実証でも利用者のニーズ、技術的課題も踏まえて優先順位を持って開発を進めるべきだというご提案などもいただいているところでございます。

本日いただいたご意見で、誠実であるとか、無理に詰め込み過ぎないなど、非常にありがたいご指摘をいただいております。私も法令事務に関わるようになってから30年近くたつのですけれども、彼我の違いはものすごいと痛感するところでございますが、こういった法制事務へ活用できること、できないことを明確に見える化していくというのは非常に重要だということも今日ご指摘いただいたと思っておりまして、その上で、最後もご指摘がありましたが、しっかりと現場の実務で使われるようなものを開発していくというのが重要と思っておりますので、KPIの設定なども含めまして、まずは小さく産んで大きく育てるという思想かと思っております。こういったところも本当に有益なご示唆をいただき、ありがとうございます。引き続き構成員の皆様方にもご支援いただければと思っております。

以上、簡単ではございますけれども、私からの挨拶とさせていただきます。今後ともどうぞよろしくお願いいたします。

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

中野企画官： ありがとうございました。

では、本日の議事は以上とさせていただきまして、ご異議がなければ議事録を作成し、皆様にもご確認いただいた上で公開、資料につきましても全て公開させていただきます。

それでは、以上をもちまして、第3回ワーキンググループを閉会いたします。本日はご参加いただきまして誠にありがとうございました。引き続き何とぞよろしくお願いいたします。

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

以上