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

概要

• 日時：2023年10月27日（金）14時から16時まで
• 場所：オンライン開催
• 議事次第：
  1. 開会
  2. 議事
     1. 法制事務のデジタル化及び法令データの整備・利活用に関する調査・実証事業の進捗状況について
     2. AI×法令に関する研究や展望について
     3. AI等を利用した法制事務補助の実験結果について
     4. 質疑応答・意見交換
  3. 閉会

資料

• 議事次第（PDF／48KB）
• 資料1 デジタル法制ワーキンググループの開催について（PDF／36KB）
• 資料2 デジタル法制ワーキンググループ運営要領（PDF／41KB）
• 資料3 デジタル法制ワーキンググループ構成員（PDF／38KB）
• 資料4 法制事務のデジタル化及び法令データの整備・利活用に関する調査・実証（中間報告）（第一法規株式会社及びFRAIM株式会社提出）（PDF／2,859KB）
• 資料5 法律分野におけるAI利用の技術的課題と展望 （角田構成員提出）（PDF／987KB）
• 資料6 生成系AIと自然言語処理研究（狩野准教授提出）（PDF／1,823KB）
• 資料7 AI等を利用した法制事務補助の実験結果について（PDF／864KB）
• 議事録（PDF／618KB）

議事録

事務局（中野）： デジタル庁企画官の中野でございます。デジタル法制ワーキンググループ第1回会合を開会したいと思います。
本ワーキンググループは、10月6日付でデジタル臨時行政調査会が発展的に改組されまして、これを受けて法制事務のデジタル化検討チームの議論を引き継ぎまして、新規法令等のデジタル原則への適合性の確認プロセス・体制構築、法制事務のデジタル化、法令データのベース・レジストリ整備、法令データの利活用促進等の検討を行うため、開催させていただくものとなっております。
本ワーキンググループの開催要領、運営要領、構成員に関しましては、資料1から3として配付させていただいているとおりでございますので、本日はご説明を省略させていただきます。
本日も構成員の皆様にはオンラインでご参加いただいております。なお、堀口構成員は所用によりご欠席となっております。
次に、議事に入ります前に、新たに本ワーキンググループの主査を務めさせていただきますデジタル庁統括官の冨安から挨拶をさせていただきたいと思います。
冨安統括官、お願いいたします。

冨安統括官： デジタル庁で戦略・組織グループの統括官をしております冨安でございます。本ワーキンググループの主査を務めさせていただきますので、どうぞよろしくお願いいたします。
ただいま事務局からもご説明がございましたが、10月6日付でデジタル臨調が発展的に改組されて、デジタル行財政改革会議が発足いたしました。そのデジタル行財政改革会議からも、引き続きデジタル庁においてこの法制事務のデジタル化等に関する検討はするようにということで指示をいただいておりますので、これまで同様のご検討をいただきたいと思っております。
そういうことで、これまでの法制事務のデジタル化検討チームからデジタル法制ワーキンググループということで模様替えはさせていただきますけれども、どうぞ引き続きよろしくお願いいたします。
また、検討チームにおきまして、これまで合計8回の会合をしていただきました。構成員の皆様には大変にご支援いただきまして、誠にありがとうございました。これからもどうぞよろしくお願いいたします。
本日の会合におきましては、第一法規株式会社様及びFRAIM株式会社様から、本年4月からデジタル庁事業として受託いただいております調査・実証事業に関して状況をご報告いただきます。また、角田構成員、狩野准教授から、AIと法令に関する研究や展望につきましてお話を伺わせていただきます。また、デジタル庁で職員が自ら実施しておりますAI等を利用した法制事務補助実験につきましてもご説明させていただきます。
盛りだくさんの内容となっておりますけれども、本日も活発なご議論をいただければと思いますので、どうぞよろしくお願いいたします。

事務局（中野）： ありがとうございました。
本日の議事は、事前にお送りさせていただいたとおりでございます。
早速ではございますけれども、議事1に移らせていただきます。「法制事務のデジタル化及び法令データの整備・利活用に関する調査・実証」の進捗状況について、第一法規株式会社様及びFRAIM株式会社様より20分程度でご説明いただければと存じます。
第一法規株式会社の梅牧様とFRAIM株式会社の宮坂様、よろしくお願いいたします。

第一法規株式会社（梅牧氏）： このたびはこのような機会をいただきまして、ありがとうございました。
私、第一法規株式会社の梅牧と申します。よろしくお願いいたします。
お時間も限られておりますので、早速ですが、お手元にございます資料4をご説明申し上げます。
まず、3ページ目をご覧いただけますでしょうか。今回のご報告の全容をご説明申し上げます。項目1から6まで太字にしておりますその辺りを中心に、この後私からご説明を申し上げます。
それでは、4ページ目に移っていただけますでしょうか。法制事務の業務分析の概要からご説明申し上げます。まず、法制事務のデジタル化に当たりまして、現状の法令の立案作業における事務の非効率性や負担の状況を把握・分析し、法制事務に存在する課題を解決するための方策や法制事務のデジタル化のために有益と思われる方法を提示するため、デジタル庁様、また、各府省庁様の担当者のご協力を得まして、法制事務業務フローの実態調査のヒアリングをこれまで実施してまいりました。また、今後の予定といたしましては、ヒアリングの結果を基に洗い出した業務内容に要する時間等を把握して、定量的測定や定量的な推定について分析を進める予定でございます。
その下、ヒアリング実施概要、目的は、以下のとおりでございます。そのうち、実際にヒアリングを実施した法律は（3）に列挙いたしました5つの法律でございます。選択に当たりましては、※に挙げましたように、法形式によって業務フローに違いが生じるのではないかといった想定に基づいて選定しております。上の（2）に戻りますけれども、実施に当たりましては、1つの法案当たり法案作成を統括する担当者、具体の作業内容や負担感などを深掘りしてお聞かせいただきたいと思っておりました立案担当者の方、また、官房総務課などのチェックの観点からお話をお聞きしたいと審査担当者の方を対象に、基本全3回のヒアリングを実施しております。
続きまして、5ページ目をご覧ください。こちらでは、ヒアリングにおいてご担当者の実体験に基づくご指摘でこれまで明らかになりました法制事務の課題として6つ挙げさせていただいております。
1ポツ目といたしましては、法制事務において作成する条文案等の関係資料は、縦書きでの厳密な体裁が求められていることから、内閣法制局の審査を受ける各文書や閣議請議に用いる5点セットの編集ツールを使いこなすことがなかなか難しい、そこで少し時間がかかっているとのご指摘をいただいております。
2ポツ目につきましては、新旧対照表の旧に当たる改正前条文に関する課題です。旧の状態は施行日によって変化し、その施行日は検討過程で変わり得るため、変更のたびに修正が発生することが分かりました。
3ポツ目は、条文修正のたびに用例の確認作業がありまして、適切な用例を探すのに時間を費やしておられるということでお聞かせいただいております。
4ポツ目といたしましては、資料の点検に関する労力になります。改正前の条文や新旧対照表の内容が一致しているかどうか、ここを特に重点的に複層的に点検が行われております。従来行われている点検方法の一つである読み合わせ作業には、法案のボリュームにもよりますけれども、多くの人員と時間がかけられておりました。
5ポツ目といたしましては、内閣法制局の予備審査におきまして、審査用に提出する資料のページ数が多くなることなどもありまして、その作成・印刷等に時間を要するといったことです。
6ポツ目は、法案の参考資料として国会に提出する資料の作成にも時間がかけられているため、その辺りの負担の大きさも感じ取れた次第です。
続きまして、6ページ目になります。ヒアリングに先立ちまして、法案の検討から国会提出までの法制事務業務フローの全体像を把握するために、業務フローを作成いたしました。こちらは抜粋になりますけれども、このような資料を使いつつ、担当者の方の印象に残っているこれまでの仕事を思い出していただくような作業をして、ヒアリングを行ってまいりました。ありがとうございます。
以上、業務分析の概要の説明をさせていただきました。
この後はFRAIM株式会社の宮坂さんからお願いできますでしょうか。

FRAIM株式会社（宮坂氏）： FRAIMの宮坂と申します。よろしくお願いします。
ここからシステム的なところも含みますので、私からご説明させていただきます。
最初にご説明させていただく7ページ目になりますけれども、法制事務のエディターのプロトタイピング・ユーザーテストの概要というところをご説明させていただきます。こちら、上の四角にも記載されているのですけれども、概要としましては、改正後の溶け込み条文データを直接編集できるエディターシステムといったコンセプトで進めておりますので、そちらにおいて編集機能や新旧対照表や改め文等の自動生成機能、整合性チェック機能ですね。こういったところの機能案や画面イメージについてユーザーテストを実際に実施しまして、今後検討が必要な観点等について確認や意見聴取を行ったといった状況になっております。下のところに実際に実施したユーザーテストの概要を記載しているのですけれども、9月末に実施したユーザーテストですね。説明は割愛させていただければと思います。
次の8ページ目に移っていただきまして、ここから17ページぐらいまで、実際にユーザーテストの中で用いた画面構成やどのような機能をテストしたのかということが記載されているページになります。ただ、これを全部説明すると時間の関係上難しくなってしまいますので、飛ばさせていただいて、ユーザーテストの総評というところに移りたいと思います。
18ページ目をお願いいたします。ありがとうございます。第1回ユーザーテストの実施結果のサマリーというところなのですけれども、総評としまして、まず、このユーザーテストは既存システム、第一法規とFRAIMの保有システムと、今回このPoCの中でやっているプロトタイプ、こういったところを用いたテストを実施しているのですけれども、既存システムについて特に評価されたポイントは、チェック機能です。中でも他法令や自法令の引用チェックと用字用語チェックです。あと、改め文の自動生成、自動出力機能、新旧対照表の出力機能、こういったところが評価の高かったポイントになります。他法令の引用チェックがどのようなものかというと、例えば条の繰上げ下げが発生したときに、他法令から引用されている場合に影響が出ますよと。いわゆるハネ改正などと言われるものですけれども、そういったものを自動的に検出してくれるとか、そういった機能性になります。
また、総評の2つ目として、テストシナリオに入っていない改正パターン、具体的には一部改正法の一部改正ですね。こちらについても今後確認していきたいといったところのフィードバックをいただいたところになります。
この後、この実施結果のサマリーとしては2ページにわたって下にチェック機能やその次のページにも代表的な機能が記載されていて、その機能に対する実施サマリーの記載があるのですけれども、こちらも時間の関係上、説明は割愛させていただきますので、必要に応じてご参照いただけますと幸いです。
そうしましたら、20ページ目に移っていただいて、ここからこのPoCの中で主にエディターという観点において検討内容になっている論点の一部、3つを代表してピックアップしておりますので、こちらについて、こちらも詳細まで説明するとすごく長くなってしまうので、どのような論点があるのかというポイントだけ説明していけたらと思っております。
1つ目なのですけれども、編集対象の条文、いわゆる新旧対照表の旧に当たる部分の条文が途中で変更になるケースへの対応というところを書かせていただいております。どのようなケースかというと、立案作業をしている中で想定している改正法の施行日が変わりました、半年後になってしまいましたみたいなときに、結果として旧の条文が変わる、そのバージョンが変わってしまうことがあるというところ、もしくは他法令の改正や施行日の変更、確定に伴って編集対象の条文の内容に変更が生じるケース、こういったものがございます。こういったことが発生したときに、エディターシステムとして改正作業を進めているのですけれども、途中段階で旧の条文が変わってしまったときにどのように考慮して対応していくのか、こういったものが論点の1つ目になります。
次、21ページ目に行っていただけたらと思います。論点の2つ目なのですけれども、こちらは起案中の改正よりも未来の改正、つまり未施行状態で浮いている改正法が溶け込まなくなってしまうということが発生し得るところに対する考慮になります。ここについては、具体的にどのようにして溶け込まなくなる可能性を検知するのかという仕組みのところですとか、溶け込んだからといって必ずしも正しいとは限らない、条文の形として正しいとは限らない、そういったものをどのようなUIでユーザーに見せてあげるとよいのかといったところの検討項目の論点になっております。
次の22ページ目をお願いいたします。エディターの部分としては最後のページになりますけれども、こちらは公布前の改正法令による溶け込み後条文を編集対象の条文とする必要がある場合ということについてです。何のことかぱっと頭に入らないかもしれないのですけれども、前提を少し説明させていただきますと、現在、これはご存じの方も多いと思うのですが、e-LAWSやe-Govに掲載される溶け込み後条文というものは、公布された改正法令、法律についていえば法案を前提にそれを法務省司法法制部により改正法を溶け込ませて、かつ各府省による確認を経て作成されているものであります。これが正確な法令データを担保するための工程として行われているものであるという前提がございます。ですけれども、この工程を経る前の条文、例えば国会提出前の条文を新旧の旧として設定して、そこに対して修正、改正作業を行う、エディター上で行わせる業務が想定されるところから、その工程を経ていない条文の正確性はどのように管理すればよいのだろうかというところについて、業務フローを含めて実際に今後ヒアリングを通して調査を進めていきたいと考えています。こちらが3つ目の検討項目になっております。
分量が多かったのですけれども、こちらがエディターとしての説明になります。
そうしましたら、次の23ページ目です。こちらから観点を変えて、次は法令等データの公開APIの機能拡張に向けた取組概要に入っていきます。ですから、ユーザーが中央省庁さんではなくて民間企業などになるイメージです。この23ページから説明していきたいと思うのですけれども、冒頭、四角に記載されている1ポツ目のとおり、法令データの時系列対応の検討を中心に、公開法令APIの機能拡張を進めている状況になっております。また、ターゲットをリーガルテック関連企業や法律事務所といった民間ユーザー層に据えて、ユーザー調査を行いながらプロトタイピングを行っているところになります。また、四角の中の2ポツ目ですけれども、プロトタイプを用いた公開テストをまさに現在実施中というところで、そこに続くハッカソンといったイベントも11月中旬に向けて準備を進めている状況になります。また、最後のポツになりますけれども、今回公開法令APIはOpenAPIを採用しておりまして、ユーザーからもおおむね好意的な意見をいただいているところになります。
OpenAPIについて次ページで解説しているのですけれども、詳細は割愛させていただいて、2つのポイントだけ説明させていただきますが、この上にポツが3つあるのですけれども、その2つ目と3つ目を簡単に触れさせていただきますと、1つ目のユーザーにとっての利点については、API仕様を見るだけではなくて実際に試運転ができる、このページ上で試しにAPIを実行してみることができるところがございます。また、3つ目のポツになりますけれども、利用者が公開法令APIを用いたサービス開発などを行う場合について、その開発効率を高めるSDKですね。こちらを簡単に準備することができるというのも利点になっております。このような提供方法によってAPIに触れていただく利用者の敷居を下げて、これからの法令データの利活用の活性化につながることを期待しております。
そうしたら、次のページに移っていただきまして、ここもデータの公開というところにはなるのですけれども、先ほどまではAPIで、25ページからは公開のUIに対する検討の取組概要について簡単に説明させていただきます。こちらも冒頭の四角の中に概要を記載しているのですけれども、この公開UIの位置づけですけれども、先ほど説明した公開法令APIのプロトタイプを利用して作成したウェブサービスのプロトタイプになっております。先ほどのAPIのプロトタイプの利用方法を開発者に向けて示して、言わばサンプル的な位置づけで、この公開法令APIのプロトタイプと同時にUIのウェブシステムのプロトタイプについて提供を行っているところになっておりますという形です。詳細な説明は割愛するのですけれども、本ページに記載していますので、必要に応じてご参照いただければと思います。
26ページ目、お願いいたします。こちらが公開UIの画面イメージとなっております。こちらも早速既に実施したプロトタイプを用いたユーザーテストにおいて利用者から多数のご意見が寄せられているところと、現在も実施中の公開テストがあるのと、11月にもハッカソンがあるというところで、たくさんのご意見をいただけることが見込まれます。ですから、この取組のポイントとしては、優先的に取り組むべきニーズの選定が最重要の課題なのかと捉えているところになっております。
これで法令等データの公開機能の現状報告についても以上となります。
私からは次が最後になるのですけれども、27ページ目になりますが、アーキテクチャー、データ構造の現状報告に移らせていただきます。上に概要を記載しているのですけれども、主に取り組んでいる内容については、法制事務のデジタル化検討チーム第6回会合資料1において議論された、施行期日の不確定性を考慮した法令の溶け込み条文のバージョン管理の仕組みを踏まえたデータ構造の設計や必要なアーキテクチャーの検証を実施したところになっておりますという形です。
幾つか取組内容はあるのですけれども、時間の関係上、28ページ目、29ページ目はスキップさせていただきまして、30ページ目に移っていただければと思います。ここは主に取り組んでいる内容になるのですけれども、先ほどの会合でデジタル庁様から提案があった施行期日の不確定性を考慮したデータ構造の方式に基づいて、どの程度課題が解決できるのかを検証するということを取り組んでおります。特徴としては、下に1、2、3と記載しているのですけれども、改正にまつわる依存関係ですね。改正と被改正の関係などをデータとして管理するというもの、修正後の条文をあらかじめファイルとして用意して管理することで施行期日の不確定性を見込んだ溶け込み後条文管理を行うということ、3つ目として、施行期日の順番前後のパターンをあらかじめ見込んで各バージョンの溶け込み後条文をファイルとして管理しておくといったところになります。こういったものをGitを用いた管理でのチャレンジをしているところになっております。各種想定したシナリオを通してみて、実際にこのデータが成り立つのかどうかの検証を進めている状況になっております。
31ページ目です。こちらのページで私からの説明は最後になりますが、先ほど言った各種データをGitで管理するというところにおいて、現状で見えてきそうな課題としては、性能面の問題がありそうですというところです。性能、パフォーマンス面です。大量の法令データをリポジトリ上で管理するところにおけるパフォーマンス面の課題やデータの同期に関する懸念ですね。こういったところが見えてきている。また、通常の今、RDBなどを用いた設計ではないというところからすると、メタデータをファイルとして保存していく必要が出てきておりますので、こういったところについても検索性能などに影響を及ぼす可能性があるかというところになっております。
長くなりましたけれども、こちらでアーキテクチャーに関する説明についても以上とさせていただきます。
そうしましたら、この後は最後に梅牧さん、よろしくお願いいたします。

第一法規株式会社（梅牧氏）： ありがとうございます。
では、32ページをご覧いただけますでしょうか。ここまでお話ししてまいりました具体的な調査・実証と並行いたしまして、デジタル法制の現状・未来に関する調査として、現在の取組例や今後の検討を進めていくに当たって必要とされる技術、今後の社会に対してどういった影響が生じ得るかといった観点で調査・分析を行っております。
まずは、デジタル法制の現状・未来に関する情報収集・分析といった観点から、32ページに記載しているような基礎的な情報探索を行っております。昨年度の報告資料での諸外国調査結果や国際ワークショップなどをきっかけとした情報探索を行いまして、専門家の方や学生の方の協力を得ながら調査を進めております。今後は法令等データの利活用・先端技術活用の未来像に関するニーズ調査をリーガルテック企業に対して実施する予定でございます。
もう一つとして、デジタル臨時行政調査会作業部会のこれまでの法制事務のデジタル化検討チームで検討されてまいりました「デジタル法制ロードマップ」の精緻化に関する調査も進めております。資料でお示ししているようなロードマップの各フェーズで求められている技術について、自然言語処理分野からの視点で調査を行っています。その他、諸外国における先行実施分野についての調査、さらにロードマップのフェーズが進んでいくことによって実現できるサービスや、今後の社会への影響、規制の必要性等について、公法の分野からの視点でも調査を実施しております。
また、33ページでお示ししておりますのは、法制事務のデジタル化の取組や先端技術活用の関係事例の情報を収集した一覧の抜粋となります。調査・分析の基礎資料としても利用していく予定でございます。
最後ですが、34ページに本調査・実証の今後のスケジュールを10月以降来年3月までの一覧でまとめております。主な予定として項目等を挙げさせていただきました。
私ども第一法規株式会社とFRAIM株式会社からのご報告は以上となります。ありがとうございました。

事務局（中野）： ありがとうございました。
来月開催予定の法令APIハッカソンにつきましては、チャットでも書かせていただいておりますので、ご参照いただければと存じます。
それでは、議事1につきまして、質疑応答、意見交換の時間を20分程度設けたいと思います。ご質問、ご意見のある方は挙手をお願いいたします。
安野構成員、お願いいたします。

安野構成員： 安野です。
第一法規の皆様、FRAIMの皆様、発表いただき、ありがとうございました。データアーキテクチャーの検討のところで3点ほどご質問ができればと思っております。1点目の質問としては、そもそもの話なのですけれども、このデータアーキテクチャーはどこでどう使うことを目的に検討しているのかをもう一度確認したいと思っていまして、データ構造を考える上で、どういう目的で考えるかによって結構正解が変わってくると思っていまして、アプリの検索性能を上げたいのか、データが正しいことを保証しやすくしたいのか、開発のしやすさとか、外部の参加のしやすさを上げたいのかとかいろいろあると思うのですけれども、今回のものはご紹介いただいたエディターや法令データの公開APIなどに実際に採用しようとするものという認識で合っているのかどうかがまず1点目です。
Gitをベースにいろいろ考えていただいていて、Gitをアーキテクチャーに沿うようなものを考えることは、いろいろメリットはあると思ってはいます。既存のGitの機能やエコシステムの資産をすごく使いやすくなる。ただ、一方で、無理やりGitに一般的でないようなやり方で載せようとしてくると、実はそういったGitベースのベネフィットは受けづらくなってしまうことも想定されているかと思っていて、そういう意味で、もし標準的なGitから運用方法が外れる場合においては、目的に応じてどういうアーキテクチャーを採用するかは、結構オープンに考えてもいいのではないかという感想を持ちました。それが1点目です。
2点目なのですけれども、Gitでアーキテクチャーでやる場合であっても、全てのバージョンの溶け込み条文をファイルとして保持するという記載があったので、そこが私が分かっていない部分なのですが、それらのファイルをリポジトリの中で管理する想定なのかどうかをお聞きしたいと思っています。というのは、Gitの運用方法として、中間生成物みたいなものは、ある意味そのリポジトリの中で管理するのではなくて外で管理するのが一般的なベストプラクティスだという認識をしていまして、例えばコンパイルされたものであるとか、計算結果として生成されるものは、アプリケーション上やエッジの上で生成すればよくて、そうでないものをリポジトリに含めるといろいろ管理の煩雑さが増えていくだろうと思っていて、そこはどういうご想定なのか私が理解できていないかもしれないので、お聞きしたいと思っています。
3点目がパフォーマンス面のところでして、将来的な懸念というところでパフォーマンス面を挙げていただいていたのでお聞きしたいのですけれども、そのパフォーマンスがどういう操作をしたときのご懸念なのかをお聞きしたくて、リポジトリのファイルサイズなのか、例えばコミットをするときやコンフリクトを解消するときにかかる時間なのか、処理時間なのか、そこら辺もお聞きしたいと思っています。私の認識だと、一つ一つのファイルのデータのサイズには結構Gitは敏感で、大きなファイルを突っ込むとすごくパフォーマンスは下がるのですけれども、ファイルの数自体は結構スケールするものだという認識がありまして、その辺、何かご想定があればお聞きしたいというところです。この3つです。

事務局（中野）： 宮坂さん、お願いいたします。

FRAIM株式会社（宮坂氏）： 安野さん、ありがとうございます。回答させていただきます。
1つ目、どこで使うことを想定しているかというところになります。ここについてなのですけれども、あと、何を目的としているかに対しては、まずはデータの正確性ですね。
ここを一番に据えていると認識して進めています。正確な法令のマスターデータをどのように管理するのかという観点ですね。ここが非常に重要だと思っています。スコープとしては、ある程度立案時の業務フローから実際に確定した公布が行われた時点での溶け込み後条文、ただ、公布時点ではまだ施行日は確定していないので、複数パターン施行日の並び順が考えられることがあるので、それぞれのパターンに対する溶け込み後条文の管理がスコープに入ってくるところになっております。
さっきのGitのアーキテクチャーのところについても1つ目の質問の内側かと思っているのですけれども、Gitのアーキテクチャーはおっしゃるとおりで使うことによってメリットはあると思いますし、既存のいろいろ使えるものはあるのですけれども、現状どうかというと、標準的なやり方からは乖離しているところになってきているかと思っております。ちょうど今、画面に映っているページの（3）の①と②があるのですけれども、①の部分で、いわゆる標準的な形に近づけた方法ですね。ソフトウエア開発で用いるようなGitの管理に近い方法をまずチャレンジしてみたところなのですけれども、そこに対する課題点が29ページ目の（3）の部分です。ソフトウエア開発とは異なる部分が多数あるというところです。法令同士の依存関係を機械的に解決できないとか、時系列の修正とか、将来の溶け込み条文の修正が行われたりとか、施行日の順番が公布段階でも確定していないとか、そういったところにおいてなかなか表現し切れないところがあって、今はどちらかというとGitで管理が可能であるという観点から、概念的な観点においては別に必ずしもGitであることにとらわれたものではなくて、それをファイルやフォルダ管理、そういうツリー構造で表現できないかがまず一つの設計のベースになっております。
その上で、パフォーマンス面などを考慮したときに、ファイル形式であれば一応Gitを使えるところにはなるわけですが、それが適切なのか、それとも先ほど話したようなパフォーマンス面でもう少しRDBみたいなものを活用していくとか、もしくはその合わせ技なのかとかについても検討の可能性は出てきているところかと思っておりまして、ご指摘の標準的に外れる場合に必ずしもとらわれる必要はないのではないかというところについては、本分科会の中でも議論として上がってきているところになっております。
1つ目の質問について回答させていただきましたが、この点は大丈夫でしょうか。回答になっていましたでしょうか。

安野構成員： ありがとうございます。
その上で、1個だけまだ分かっていない部分があったのでお伺いしたいのが、ファイルシステムの上でやりたいというところだと思うのですけれども、ファイルシステムでやりたい理由はどういったものがあるのですか。

FRAIM株式会社（宮坂氏）： まずはそういったファイルシステムであれば、Gitの既存の機能性の活用可能性があるというところが要素としてはあります。逆にファイルであるからこそそのように扱えると。ただ、それに無理が出ていないかについては、精査が必要かとは思います。

安野構成員： なるほど。そういう意味でいうと、Gitを使うベネフィットがどこまで受けられるか分からない場合には、別にファイルシステムにこだわる必要もあまりなくなってくるという認識で合っていますか。

FRAIM株式会社（宮坂氏）： そうですね。私の認識としてはそうです。

安野構成員： ありがとうございます。1点目、理解できました。

FRAIM株式会社（宮坂氏）： ありがとうございます。
2点目について、溶け込み後条文の管理をリポジトリ内で管理する想定か外かというところなのですけれども、こちらは具体的に設計を進めています山本から説明、回答させていただけたらと思うのですけれども、山本さん、お願いできますか。

Oxygen（山本氏）： 承知しました。
よろしくお願いします。第一法規株式会社から本事業について再委託を受けているOxygenの山本と申します。
ご質問いただきまして、どうもありがとうございます。中間生成物ですね。溶け込み後条文をファイルのGitの外で管理するといったところも検討したところではあるのですけれども、一旦まずGitのリポジトリの内部で管理する方式を取っております。外で管理する方式も考えられるのですけれども、ここは使っている理由としましては、一応確認で、外で管理すると言ったのは、例えばGitのアーティファクトのような形で溶け込み後の条文を管理したほうがいいといった感覚を想定されているという認識で合っていますでしょうか。

安野構成員： 外というのは、リポジトリの管理対象外にすることを想定していまして、溶け込ませる改め文的なデータともともとのデータがあれば、その溶け込ませ後のデータは生成できるのかというところで、その後のデータも前のデータも両方ともリポジトリの中に入れる必要はないのではないかと思ったという趣旨です。

Oxygen（山本氏）： ありがとうございます。
そうしますと、恐らくこのPoCの全体の前提条件が大きく関わってくるのかと思っていまして、このリポジトリの中で管理している理由としましては、今回溶け込み後の条文をそもそもデータとして管理するといったところが、最初のもともとのコンセプトになっているところがあります。そういった意味で溶け込み後の条文をあらかじめ見える形で管理しておいて、そこ（編集したファイル）の中身を確認した段階で次の（審査）ステージに進めるといったことを想定しているところから、当然アプローチの取り方としては2つあると思うのです。溶け込み後の条文を後から生成する形と、溶け込み後の条文をつくっておいて改め文を後から生成するという形、どちらもあると思うのですけれども、今回は後者のコンセプトを採用していることから、リポジトリ内で溶け込み後の条文を管理する方式を取っているところになります。
こちらでご回答になっておりますでしょうか。

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

Oxygen（山本氏）： ありがとうございます。

FRAIM株式会社（宮坂氏）： 3つ目の観点ですね。パフォーマンス面の話などは具体的にどういうところで出てくるのかというところになります。まず、想定されるかと思うものについては、このデータを例えばGitで管理されているものに対して、各種エディターのほうで検討している整合性チェックですとか、いわゆるシステムの処理系ですね。そういったものを走らせるときに、本当にファイル内のメタ情報を見ながらたどっていかなければいけないものですとか、そういったものがありますので、通常、RDBによってインデクシングされて効率化されているものだとか、そういったものとかにおけるパフォーマンスは課題としては出得る。それはダイレクトにその処理がここのデータを見る場合においてという話になるのですけれども、そういったところは考え得るところかと思っております。
あとはリポジトリ、1ポツ目のところにも大量のファイルが配置されることになるのでというところについて書いているのですけれども、それでリポジトリ同士の連携やデータの同期などに時間がかかるのではないかということの懸念なのですが、今回1つのリポジトリの中に管理する対象は、例えば法律だったら法律用のリポジトリという中に全ての被改正法かつリビジョンと呼ばれるようなそれぞれ時点の溶け込み後条文やそれぞれに発生する未確定であるパターンですとか、そういったもののファイルを管理していく。加えて、そこに対して改め文などの改正規定とか、そういった情報とか、各種管理していくものになりますので、かなり1リポジトリのサイズ感が大きなものになるというところが現状の設計上の状況になっておりますので、そこに伴うリポジトリ間の同期や連携、そういったところの性能面に問題が出ないかというところが懸念事項として挙がっている、その2点かと思っています。
山本さん、もし補足があればご指摘をお願いします。

Oxygen（山本氏）： ありがとうございます。
補足としまして、組織ごとに編集したデータを中央のリポジトリにマージするときがパフォーマンスとして懸念される箇所かと思っております。組織間で異なるリポジトリ、各種異なるリポジトリを管理していて、審査向けに新しくデータを連携するというときに、そのマージの操作が果たして時間内に終わるのかといったところが懸念点としてあるところです。
今、状況として伝わっておりますでしょうか。

FRAIM株式会社（宮坂氏）： これは図示なしだとなかなか難しいですね。

Oxygen（山本氏）： そうですね。組織の内部で編集をしたファイルを自分たちの内部で審査した段階で中央向けにデータを連携するとき、そこのときにパフォーマンスが懸念されるところでございます。その背景になっているのが、今、宮坂からご説明させていただいたとおり、1つのリポジトリにものすごく大量のファイルがあることと、当然大量のファイルがあるということで、コミットもかなり増えてくるのかと思うのですけれども、そのコミットの数に応じてだんだんパフォーマンスが落ちていくといったところがありますので、その2つがパフォーマンス面で懸念されるところかと考えております。
こちらでご回答になっておりますでしょうか。

安野構成員： 多分理解できたと思います。ただ、今の話を伺う限りだと、法令の数分くらい掛ける何個かくらいのファイル数しかないのではないかという気もしており、それくらいであれば大丈夫かという所感もありますが、ここはいろいろテストしてみてというところだと思っています。

Oxygen（山本氏）： ありがとうございます。

事務局（中野）： ありがとうございます。
次に、八木田構成員、お願いいたします。

八木田構成員： ありがとうございます。Legalscapeの八木田でございます。
まず、全体として非常に有意義かつこの国の法制事務をまさに具体的にDXするようなお取組で、一国民としても大変ありがたいと思っております。その中で、一技術者としてお伺いしたいと思っていたポイントは、安野構成員におっしゃっていただいたポイントと近いところがあるかと思うのですが、27ページから31ページのGitみたいなもののところかと思っていまして、これは先ほどのお話ですと、今後もしかすると日本の法制事務全体を支えるようなデータベースになっていく可能性があるようなものだと理解しているのですが、そこにおいてGitを採用するのか、あるいはそもそも何かまるっと開発するのか、仮にGitを採用するのであればどう採用するのかみたいなところが、今後何十年もかかってくるような極めて大きな意思決定かつ論点かと思っていまして、その辺りにイシューレイズをしつつ、抽象的にお伺いしたいのが、これは仮にGit以外のものを新しくつくることになるとすると、何割ぐらいが車輪の再発明になって、何割ぐらいが法制事務固有のGitではそもそも困難なものになりそうなのでしょうか。
例えばGitを直接使う、Gitのコマンドを法制執務をされる方にたたいてくださいというのは、結構難しい話だと思いますので、例えばGitを内部的に利用しつつラップするようなツールを開発するみたいな、そういったことがあり得るのではないかと思っていまして、そうすると、バージョン管理をするという意味での車輪再発明部分は結構小さくなり、かつGitはご案内のとおり数億人が世界で使っているような最も使われているバージョン管理システムであり、世界中のいろいろな人々によってメンテナンスされていっていますので、これを再利用するというのは案としてあり得るのかと思っておりました。
先ほどおっしゃっていたパフォーマンス懸念みたいなところも、これは安野構成員のおっしゃっていたところと重複するかもしれないのですが、今現状でも、Linuxカーネルみたいなコードの行数が1000万とか5000万とかそういう規模感のコードがGitによって管理されているものであるので、パフォーマンス的にはそこまで問題ないかとも思っており、ご質問に戻ると、イメージとして、どれぐらい法制事務固有で、Gitで幾らラップするツールをつくっても全然対応ができない、というものがありそうなのかみたいな感覚をお伺いできますと幸いです。

事務局（中野）： 宮坂さん、お願いしてよろしいでしょうか。

FRAIM株式会社（宮坂氏）： ありがとうございます。
八木田さん、ありがとうございます。なかなか難しいところではありまして、まず、前提としたところで、先ほど安野さんからもあったところでして、今回は溶け込み後条文をベースとしたところにチャレンジをしているところではあるのですけれども、そっちを正としていくのか、それとも改正法側の改め文とかそちら側を正とするかによっても、今後の長期にわたる法令のデータベースを組み立てていく意味においても設計や考え方は大きく変わるところかとは前提としては思っているところになります。
ただ、本PoCにおいてのご質問でいうと、被改正法という溶け込み後条文のほう、つまりe-Govなどに公開されるほうをある意味で正としてと考えたときに、どれぐらいが新規か既存かという話ではあるのですけれども、割合で答えるのが難しいと思うのが、どこのスコープなのかということなのですね。データとして保持しておけます、データとしては確かにここに一式そろっていますというものをつくるということを今、取り組んでいて、それをフォルダで表すならばこうだし、クラス図みたいに表すならばこういう関係だねみたいなことを実は組み立てていたりするのです。そこにおいてはあまりGitかどうかという概念は、それよりもっと抽象度が高いところでやっていて、それをGitで表すならばこうかとか、RDBで表すならばこうかという検討になるので、それが前提としてございます。
その上で、Gitの仕組みだけでいけるかというところでいうと、まず、そうは思えていないです。いろいろとマージを一つ取ったとしても、溶け込み後条文を正としたときに、この条文とこの条文を溶け込ませますみたいなときに、例えばコンフリクトが発生して手動修正をしなければいけないケースが発生したときに、誰がその業務をそもそもやるのかとか、そのマージを誰が確認するのかみたいな業務フローにはねてくるみたいなところがありますし、それはシステムの考慮外だねと外すか外さないかでもその割合が変わってくる。
もしくはそれをシステム化で完全に自動化することができるのかを、Gitのラップをするような便利なマージツールの開発みたいなことを検討してみるのかとか、そういった範囲を含めるかどうかでも変わってくるとは思うところです。
一方で、法令全体はどういうものを管理しなければいけないのか、その法令とか、その改正法とか、様々なものがどういうデータとして全体としてはあるのかという全体感については、本PoCの中でもかなり解像度が上がっているところになりますので、直接的な質問への回答ができなくて大変恐縮ではあるのですけれども、なかなかGitで何割かが一概に言えないかもというのが1つ目になっています。
まずはそこが最初の質問に対する回答なのですけれども、いかがでしょうか。

八木田構成員： ありがとうございます。
抽象的な質問をしてしまったのですが、これは今後結構大きめの意思決定になるかと思いますので、ですから、一旦イシューレイズ的なところも含めてお伺いさせていただきました。ありがとうございました。

FRAIM株式会社（宮坂氏）： ありがとうございます。

安野構成員（チャット発言）： 八木田構成員の大きめの意思決定だという感触について同意します。データ構造の部分は後戻りもしにくく、インパクトが大きい部分だと思います。

事務局（中野）： 藤原構成員、その後、角田構成員、お願いいたします。

藤原構成員： 藤原でございます。
今日は発表をありがとうございました。大変興味深いというか、大変な取組だと思ってお伺いしていたのですけれども、私からは一番最初の法制事務の業務分析のところについてご質問したいと思います。これは基本的には業務フローについて実態調査をするとともに、こうしたほうがいいですよという改善の提案みたいなものをすることを想定されていると思うのですが、一方で、エディターのプロトタイプなどをつくっているときには今のフローを前提にした実験しかできない面があると思っていて、現状この業務フローの改善についてどのぐらい抜本的に変える提案がされる可能性があるかというか、それによってエディターをどこの部分まで深掘りするかが結構変わるのかと思っています。恐らくこのワーキンググループの検討事項というかPoCの対象にも入ってくるのだろうと思っている官報のデジタル化などもあると思うのですけれども、その辺りも含めてどのぐらい業務フロー的に変えることを前提とした検討をされているのか、その感覚みたいな、これも抽象的な質問なのですけれども、どのような感じなのかお伺いしたくてご質問しました。
以上です。

事務局（中野）： 梅牧さん、お願いできますでしょうか。

第一法規株式会社（梅牧氏）： ありがとうございます。
ご質問ありがとうございました。まさに今日ご説明申し上げましたように、各中央省庁様の法制事務のワークフロー、ヒアリングを通じて様々な課題を洗い出してきて、そこから業務フローの改善、どういったことが可能なのかを探索していくところではあると同時に、システムも今、プロトタイプを検討して並行して進めている段階ですので、今のお答えに満額回答はなかなか難しいところではあるのですけれども、まずはどのような業務フローの改善が可能かを、ヒアリングで聞かせていただいたお話をよく分析して、形づくっていけたらというところかと今の段階では考えております。

藤原構成員： 了解しました。
例によって縦書きのインデントが云々かんぬんというのは、昔からこの会議が始まってからずっと話されているところで、あそこを変えることで結構変わるのかと思っており、個人的にはそういうところを変えることに意味があるかと思っているので、ぜひご検討をお願いします。
以上です。

第一法規株式会社（梅牧氏）： おっしゃるとおりかと思います。ありがとうございます。

事務局（中野）： ありがとうございます。
補足させていだきますと、本PoC、まさに予断を持たないで実施しており、既存のワークフローを前提にせず抜本的な見直しを探索的に検証するということでやっておりまして、だからこそなかなか難しいところも出てきておるところではあるのですけれども、官報電子化の関係でいいますと、今日も参加いただいていますけれども、国立印刷局のシステムの刷新、この取組とも連携してやらせていただいているところになります。どれくらいの業務フローを変えようとしているかという割合はなかなか申し上げにくいところではありますけれども、まさにゼロベースで考えているところになりますので、補足させていただきます。貴重なご指摘をありがとうございます。

藤原構成員： ありがとうございました。

事務局（中野）： 続いて、角田構成員、お願いできますでしょうか。

角田構成員： こんにちは。
私もお話が重なってしまうのですけれども、質問というか意見をさせていただきたい部分があります。それはアーキテクチャーの話のところで、実はこの資料を最初に拝見したときから疑問を感じていて、Gitを使うことを先に目的にしてしまったらまずくて、要件定義というか、そもそも中央省庁ではどういうものが立法のときに必要なのかというところから段階的に具体的な機能を明らかにしていかないと、最終的に目指すべきものと食い違いが起こってきたりするのではないのかと思いました。ただ、これは本日の安野先生や八木田先生など皆さんがおっしゃっている話の中で、そうはならないように行こうという方向に見えましたので、安心してはいます。それでも、どうしても技術者の人たちをベースに話をしてしまいますと、開発者側の気持ちが強くなってしまって、開発者目線の提案に引きずられてしまいそうですので、やはり重要なのはユーザー側というか立法者側の方々は何がしたいのかというところに対して、「うまくそこに合致していますよ」という形で検証してほしいです。「今、既にこういう技術があるからここに使えるよ」という技術ありきのボトムアップの話ではない検討も必要ではないのかと思いましたので、ご考慮されていると思いますので大丈夫だとは思うのですが、確認させていただければというのが一点です。
もう一点は、エディターの開発に関する部分についても気になっております。中央省庁の方々向けに私などもe-LAWSをつくる前にお話しさせていただいた機会があるのですけれども、そのときに、お集まり頂いた中央省庁の方々の中には独自のやり方があるので、一律の改め文作成のシステムには懐疑的な意思を表明される方もいらっしゃいました。実際の利用の有無は別問題として、使いたくないですとか、そういう気持ちの方もいらして、多様な方々がいらっしゃる印象でしたので、ヒアリングなどもどれぐらい広く実施されているのか、その辺の調整をどのようにしていくのかというのは、宮坂さんたちのところだけでは厳しいと思いますし、これはトップダウンにやらなくてはいけないところもあるので、お願いしている第一法規さんやFRAIMさんだけではなくて、デジタル庁の方々をはじめ政府の側というか、発注しているユーザー側での合意形成みたいなものも必要なのではないかと感じました。どなたかに向けた意見ではないのですけれども、技術者の方と、もしかすると中野さんたちにもなってしまうのかもしれないのですが、この点は指摘させていただきたいと思いました。
以上です。

事務局（中野）： ありがとうございました。
宮坂さん、何かありますでしょうか。

FRAIM株式会社（宮坂氏）： ありがとうございます。
最初のGitの件について、ご指摘ありがとうございます。まさにおっしゃるとおりのところかと思っておりますので、使用ツールの手段と目的が逆転しないよう、そこはしっかり本当に達成すべきものをやりながら、その結果としてのツールや技術選定だと思ってはいますので、ご指摘はもっともなところかと思いました。ありがとうございます。
エディターのところ、私から回答できる範囲としましては、おっしゃるとおりヒアリングの中でもかなり多種多様な、例えば財務省の方に改め文からつくるのですというところのご発言をいただいたりとか、逆に新旧からつくるのですというほかの省庁さんもいれば、それだけでもシステムの設計は異なるというところで、どっちをつくればいいのだろうみたいな話になる。全部をかなえるものというのも、なかなか万能だというところだと、結局何でもできるは何もできないみたいな話にもなってしまうと思っています。法律の立案としても、すごくシンプルなものからすごく難易度の高い複雑性なものまでがあって、どうしても複雑なものをカバーしていこうという思考にはなっていくときに、そうすると、今度はだんだん複雑になっていって、シンプルなものですら使いづらいみたいなものも出てくる。法令のサイズ感一つ取っても全然大きさが違うとか、これを1つのシステムで組み立てるときに、どのユーザーを特に重点的にすくっていこうかとか、そういうコンセプトがある程度確かにしっかりしないと、なかなか揺れてしまったり、難しいポイントがあると思っていまして、ご指摘の点については非常におっしゃるとおりだと思ったところになります。ありがとうございます。

角田構成員： ユーザーの側というか、そろそろ中央省庁のデジタル庁の側からも言っていただけるような状況があったらいいし、この会議の場でも議論したらいいのかと思いました。

事務局（中野）： ありがとうございます。
少し補足させていただきます。我々は今回、財務省で税関係の法改正を担当をされている方を含め、束ね法ですとか、単一の法律を改正する法律ですとか、様々な法改正の形式に関しましてヒアリングをしているということでございます。他方で、我々、デジタル庁のこのデジタル法制ワーキングを担当する部署でも、プログラミングは私はやったことがありませんが、実際にGitを使ってみてどういう形で動いているかといったことについて試行してみたりはしているところではあります。どういったインターフェースになるかというところ次第なのかもしれませんけれども、安野構成員からも、大きめの意思決定であり、データ構造の部分は後戻りもしにくい、インパクトが大きいということでご指摘いただいておりますとおり、これはまさに法令のデータが更新される仕組みがようやく今、構築されて回っているわけですが、これを抜本的に変えるようになると、そもそもそれがワークするのかとか、いろいろ問題をはらんでおりまして、慎重な検討を要する部分もあるのかと私自身は思っておりまして、引き続き検証ができればと思っている次第です。貴重なご指摘、誠にありがとうございます。

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

事務局（中野）： 続きまして、議事2に移らせていただければと存じます。AIと法令に関する研究や展望につきまして、角田構成員、そして、静岡大学の狩野先生から、それぞれ15分程度でご説明いただきます。まずは角田構成員、続いて狩野先生の順でご説明いただきまして、本件に関するご意見、ご質問は最後にまとめて頂戴できれば幸いでございます。
それでは、角田先生、引き続いてでございますけれども、よろしくお願いいたします。

角田構成員： こんにちは。角田でございます。
お時間もありませんので、私のほうからプレゼンテーションをさせていただきます。
本日、私のほうでお話しさせていただきますのは「法律分野におけるAI利用の技術的課題と展望」という標題で、目次のような手順でお話しさせていただきます。まず、スライド3枚目の本日の趣旨ですが、先ほどまでのお話のような観点もあるのですけれども、今日の時点での現場の話というよりも、スライドの下のほうにオレンジ色で書いてありますように、法令のシミュレーションですとか、デジタル庁の会合の中で何度か登場してきているRules as Code、RaCと略されるものなどの実現を将来的に見据えたときに、同じような過去の失敗を繰り返さないようにするためという観点で、共有できたらよいのではないか、と思いましてお話しさせていただきます。ここで「法律AI」と書いておりますけれども、これは法律分野のAIという意味で大まかに捉えていただいてよろしいかと思います。スライド4枚目のAIの今昔のお話ですが、この辺は本日の参加の皆さんはもうほとんどご存じのことだと思いますので、本来は割愛させていただきたいところなのですけれども、念のため確認させていただきます。AIといえどもソフトウエアですので、どういうところが普通のソフトウエアと違うのかというと、例えば昔だったら知識に基づくAIといって、人が知識、ほとんどはルールベースドなAIですから、論理式のような形でルールを書いて、ドメインごとの知識をAIの中核部分の「推論エンジン」と当時は言っていましたけれども、そういったものに入力しておいて、そのドメインでのいろいろな質問に対して回答が出てくる、そのようなAIでした。知識はドメインに応じて差し替えて使います。21世紀に入ってきてからは大体機械学習というものを使って、ビッグデータから学習モデルをつくってしまうので、人が知識のところを書かなくても、ドメインに応じた学習モデルをうまく使えれば、問題に対して賢い回答が出力されるようになっています。ただ、学習モデルがそう簡単に人が見て分かるようなものになっていないということが最近のAIの国際会議などでのホットな話題、研究テーマにもなっています。
そういうAIなわけですけれども、スライド5枚目のように、実は法律AIの分野も結構昔からAIの技術の進展とともにいろいろなことが提案され、いろいろな開発が行われたり、法律AIの様々な研究は各時点でのAI技術を受ける形で発展してきたという経緯です。ただ、法律AIの分野では実用的なものは2000年過ぎぐらいまではなかなか出現しなかったのですけれども、近年の「LegalTech」という言葉で代表されるようなテキスト処理を中心としたAIの性能が高くなってきたおかげで、アメリカを中心に結構実用的なものも現れてきて、ようやく少しうれしい状態になってきたところです。
その前段階の「法的推論」が法律AIのテーマの主流だった時代の仕掛けの前提となるモデルの話がスライド6枚目、7枚目なのですけれども、なぜこの話をさせていただくかというと、Rules as Codeなどという話になってくると、結局ルールをコードで書いておいてどう適用するかという話になってしまいますので、そうすると、昔のルールベースドな方式の見直しになる可能性があるということで、一応おさらいをさせていただこうと思いました。本日は時間がないので日本やドイツ、フランスと言われているような制定法の国家、法律の条文があったときに、その条文を裁判で適用することで判決を下していくという主義に基づいているような国家の法的推論の形式なのですけれども、そちらに絞ってお話しさせていただきます。法律の条文というのは、その多くが、条件部分が成り立ったら結論部分となる、つまり、法律要件が成り立ったら法律効果が成り立つという形でルールが書かれていることがほとんどです。その条件部分に当該事件がマッチしたらその効果部分を判決として下すという言わば演繹的な形、三段論法の形で適用していくということで、法学部に入ると「法的三段論法」という言葉が結構出てくることがあります。そういったモデルをそのままコンピューターでシミュレーションできないかということで、1970年代、80年代、90年代と研究が続き、今でもこういうアプローチを採用されている先生方はいらっしゃいますが、こういうものが計算モデルのベースになっています。
ただ、スライド8枚目にもありますように、三段論法というのは形として三段論法の形をとっていても、そこに使われている事実の記述が仮に正しかったとしても、使われているルールが不完全だったりすると、うまくいかないわけです。一番上に書いてあるような全称的ルール、これは多くは定義的なものですね。「人は生物である」ですとか、あるいは数学の公理みたいなものでしたらうまくいくのですけれども、そうではなくて、法律などで使われるルールというのは、法令でさえも、例えば「人を殺したら死刑」というルールがあった場合、結局は2番目の形の例外ありルールでして、違法性が阻却されるといいますけれども、正当防衛だったら違法ではないのだからということで、このルールが結局適用されないということが起こってしまうわけです。そのほかにも確率的なルールなどもよく使われるわけですけれども、こういったものだと、下の左の図に描いたような形ですっぽり「人」が「生物」の中に入っているかのようにはなっていなくて、中の図の「殺した者」というのが「死刑になる者」の中にすっぽり入らずはみ出した、オレンジ色の部分が必ず出てきてしまうような、そういったルールを使っているので、結局は必ずしもうまくいくとは限らないのですね。
そのほかにも、法的推論と言われていたものには問題がありまして、スライド9枚目のように、今お話しした例外が多いというほかに、先ほどもお話に出ていた条文の改正、法改正をするときの問題で、そう簡単に改め文などがつくれなかったり、状況が保持できない、その状態がうまくコンピューターでシミュレートできなかったりということが起こります。それは法律の中では高階の表現が当たり前に使われていて、自他の条文や法律というものを参照するのはもちろんのこと、それに対して操作を加えてしまうという副作用を起こしてしまったりですとか、あるいは文言の中で「～することは」のような表現な形式で、本来文として、命題として成り立つもの自体を条文一文の一つの要素となる対象として扱ってしまう、といった高階表現が頻繁に出現してしまって、高階の対応をしなくてはいけないだとか、あるいは普通の命題と言われているものは事実関係を書いているわけですけれども、法律の場合ですと当然のことながら「～しなければならない」とか、「～してはいけない」とか、あるいは「～してもよい」のような規範論理や義務論理と言われている分野のロジックを推論の仕掛けに入れておく必要もあります。この辺はやろうと思えばできるのですけれども、少々面倒です。
それから、「オープンテクスチャー」と法哲学者などが言っているのですけれども、いろいろな法律に出てくる概念、条文の中に出てくる概念は正確に法律内で定義されるのではなくて、結局は解釈者に依存するというもので、定義条文を読んでも、その定義を構成している一つ一つの単語の意味は文脈依存性や解釈の多様性が入り込んでしまいますし、そもそも法律の場合だと玉虫色に解釈できるようにつくっておくことなどもしばしば行われるわけですね。あるいは本当に解釈に依存する、これは首長に任せるみたいな形で文脈や解釈、そういったものにとにかく依存させてしまうことが多いということ。ここで言うオープンテクスチャーはこういう状況を指しています。
それから、そういう条文やルールだけではなくて、事実の記述もほとんどの場合が社会的事実の記述なので、物理的に何々が壊れたとか、何々がどこの上にあるだとか、そういう話ではなくて、多くが例えばある人がある人にお金を渡したというその行動は物理的に観測できたとしても、それが譲渡なのか、あるいは貸したものなのか、のように、あげたのか貸したのかという事実は、その客観的動作だけからでは推測できない社会的事実なので、それらを評価・解釈できる、文脈の情報をたくさん与えておかないとなかなか分からないという側面があります。結局、そこには解釈や人の認識が入り込んでしまうという厄介な事象が法的推論を困難にする要因になっています。
それから、もちろん類推なども法律分野ではしばしば行われますので、そのような高次推論の類にも対応しなくてはいけないという大変な点もあります。
では、これらのような問題に対して、今のAIでは何かできないのか、という話があるのですけれども、そもそも今のAIは論証をほとんどの場合はしていないので、学習モデルの中に人が分かるような言葉で説明が書いてあるなどということはないわけですね。そうなると、そもそも法律的なものに対してのシミュレーションだとか、利用を検討するときには、説明がとても苦手ということになるので、そこを何とか乗り越えないと、今のAIであってもなかなか使いにくいと思われます。一方、法的推論の昔のアプローチでは、逆に言えば、結論さえ出てしまえばその証明というものは全部担保されているので、論理的に、読みづらいかどうかは別問題として論理的に説明していることにはなります。
そういうことで、スライド10枚目のように、多くの法律AIの学者は1990年頃から法的推論の研究から離れて、「法的論争」といって、AIが推論するのではなく、法的推論するのは人がやる設定にしておいて、その人と人とが弁論で争うときの状況を数学的に形式化しようだとか、その弁論をサポートしようだとか、そういうものが盛んに研究されるようになって、今日まで続いています。これはRules as Codeだとか、そういうところには直接はあまり使われなそうですので本日は触れませんが、立法活動全体として広く見たときは、立法事実の収集や制度設計の意思疎通や合意形成など、そういったところでは有効に今後使われていく技術なのではないかと思われます。
この11枚目のスライドは、念のためつけておいただけのものなのですけれども、結局法令だとかそういったものを知識表現しようとすると、数学的安定性を考えると、論理式を使っていくというのがよくある一番典型的な手段である点を指摘したものです。ただし、論理式を使った場合であっても先ほど言った苦手な問題は全然解決されていなくて、そして、一番大問題は、右下に書いておきましたように、人手でつくらなくてはいけないという本当に大問題、面倒な問題がありまして、今の機械学習とは違って嫌な問題となるわけです。
そして、そういうことを前提としつつも、スライド12枚目の特質の一番上に記しましたように、ルールベースドでシミュレーションなどを実施するとしても、法律のルールは制約ルールというタイプのものがほとんどですので、そのタイプだけでは足りない、という問題があります。それは、人間のほとんどの行動というものは、法的にいうと私的自治の原則というものがあって、基本的に勝手に自由に行っていいわけです。その上で、こういう行動だけはやっては駄目だよとか、こういう範囲内で行動して下さいね、のような制約だけが法律のルールとして書かれているわけです。そうしますと、法令のシミュレーションなどと言葉のイメージで思い描くことはできるかもしれませんけれども、実際には法律には生成系のルールはほとんど書かれていませんので、シミュレーションを行う場合は、結局そこに開発者の恣意性だとか、いろいろなアドホックなものや正規な手続きを経ないもの、整合性が不明なものが入ってきてしまうので、結構大変だという指摘です。
スライド13枚目と14枚目は法律オントロジと呼ばれるものについてのお話です。法律の条文の中にある法律概念みたいなものを計算論的に扱えるようにしたものをオントロジといいますけれども、概念の構造などをきれいにコンピューターで可読な形式で、あるいはいろいろなアプリ、いろいろなAIで使えるような形式にするということも、法律概念に対して、もちろん対応しておかなくてはいけないのですが、これについても問題があります。
ここでいうオントロジというのはもともと1980年代前半くらいに登場してきた哲学的なオントロジとは異なるものでして、その当時は知識に基づくAIの時代だったので、みんなが勝手に知識を書いていて、結局相互に使えないではないか、という話になってしまって、それに対して、共通認識できる対象、例えば物理的な対象のような客観的な存在物のように概念構成が記述できれば、みんなで共有して便利だねという意図が含まれていたのです。
ところが、そうなってくると、物理的なものだったらいいのですけれども、そもそも法律概念は物理的実在が対象ではないので、オントロジの最初の意図からずれてくるというか、衝突してしまう部分があるのですが、これは現在のオントロジの考え方では、オントロジとは概念の仕様なのだ、みんなで共通認識している、あるいは共通認識すべき仕様なのだと考えて、そこからスタートして活用することでオントロジの意義が出てくると考えられるようになっているので、法律オントロジを構築する取り組みもありました。ただし、それがうまく生かされるには、そのためのキーポイントが標準化になると思われます。標準化をするために、例えば司法の分野のようにそもそも原告と被告が同じ概念に対して違う解釈でぶつかってくるというのは裁判では大前提ですので、そうすると、共通認識といっても本当の司法の現場の話になってしまうと難しいところがあります。ただし、ここで我々が検討しようとしているものは、司法ではなく、立法の側でのオントロジだとか、立法の側での知識をどのように記述して蓄えておくかという話ですので、立法者側というのは法律をつくるときに大体皆さんで意思をある程度すり合わせて、それで共通化して進めていくということが通常から行われていますので、司法分野に比べれば立法分野では比較的ではありますが、標準化は進めやすそうだと思っています。つまり、つくってしまった法律がどう解釈されるかはいろいろな解釈に分かれてしまうかもしれないので、標準化は難しいかも知れませんけれども、つくるときには結構共通化や標準化はできるのではないかという淡い期待があります。
最後のスライドでは、課題や提言をまとめさせて頂いていますが、スライド左側で記しましたように、いろいろ難しいことはあっても、皆さんご存じのように大きな技術革新が訪れていますので、これを活用していくのは当然すべきだと思います。時間もありませんので、スライド右側でアプローチというか提言として書いておいたものの中の赤文字のところだけお話ししておきますと、立法分野でのAI適用の対象はとにかく皆さんが今、やっていらっしゃるような感じで、対象を限定した上で進めていただいたほうがいいでしょうという点、そして、そのときに、先ほどの議論でもあったのですけれども、具体的なタスクやユースケースなど、本当に現場でどういうことが必要とされているのかがまず見定められて、それに合うように技術は適用されていかないと、発散してしまったり、失敗してしまったり、最後の最後に出来上がったものを見せたら駄目だと言われたり、ということにもなりかねませんので、タスクやユースケースの整理はしっかりとしたほうがよいでしょう、という点を指摘しておきます。
あとは、立法のAI導入の取り組みは、ばらばらに進めてもよくないので、全体的最適化を図って作業をしていく必要があるのですが、ここで大事な抜けがちな論点が、時間的視点です。様々なDXの状況を見ても、全体的最適化ということである一時期の最適化はされるのですけれども、時間的に長い目で見たときの最適化がされていないという状況をしばしば目にします。そこで時間的視点も考慮すると、恒常的な取組の体制が必要なのだろうということを強く感じています。プロジェクト的に一時期一時期での最適化ということだけではなくて、そういった長い時間的視点での一貫した体制も必要だということを提言したいです。そして、先ほど来申していますように、標準化を進めないと空間的時間的最適化もなかなか難しいですので、共通認識や意図に着目して標準化していくことが必要なのではないかと思っています。
時間がありませんので、ここまでとさせていただきます。ご清聴ありがとうございました。

事務局（中野）： ありがとうございました。
それでは、引き続いて狩野先生、よろしくお願いいたします。

狩野准教授： よろしくお願いします。始めさせていただきます。皆様、何割かの皆様はいつもお世話になっております。静岡大学の狩野と申します。
今日はお話を15分いただいて、どういう構成にしようか大分迷ったのですけれども、角田先生のお話を伺っていて、ちょっと寄せ直したほうがいいかと思いましたので、実はお配りしたスライドに微妙に追加をしましたが、駆け足でご紹介したいと思います。
お話としては、やはりビジョンが欲しいのかと思いまして、できれば今後の見積りが取れるようなお話をしたいと思って、広めのお話をご用意いたしました。タイトルは「生成系AIと自然言語処理研究」なのですけれども、私自身は自然言語処理が専門の研究者でして、いわゆる言葉を使う、今はもはや自己紹介にはChatGPTのようなものをつくっている人たちというと分かっていただけるのですが、そういうことです。そういうことをやっております。
ただ、実際のテーマはたくさんありまして、進行中のものだけでもこれだけあるのですけれども、言語処理の基盤的なところもありますが、応用においても法律系以外に政治系、医療系をいろいろやっておりまして、それぞれ違うように見えますけれども、根っこは同じですので、そういう意味で幾つかご紹介して、ビジョンをご紹介できればと思っているわけです。
ただ、15分しかありませんので、本当はこういう言葉の説明をしようかと思ったのですが、15分で終わってしまいますので、もし皆さんご興味があれば付録につけましたし、また何か機会をつくっていただければご説明できますので、先にお伺いしたところだと、皆さん全部ここはご存じのはずだということだったので省略しましたが、もし言葉が分からなかったら申し訳ありませんが、多少分からなくてもお話としては通じるのではないかと思いますけれども、ご質問いただければお答えもご説明もできようと思います。ですから、この辺りの用語と機械学習回りの言葉は説明なく使わせていただく内容になっています。
私、先ほどお話のあったこのプロジェクトの未来構想というのでしょうか、先々のお話の取りまとめの文書をお手伝いして一緒につくっていますので、大分状況は存じ上げておりまして、その中でこういうロードマップがあったわけですけれども、これが先々どうなるかということを思うと、今、技術がどれくらい進んでいるかということと、以前のものはどれぐらい使えるかが分かる必要があるだろうと思いますので、その辺のお話をしていきたいと思います。
1つ目ですね。医療系の応用テーマをたくさんやっておりまして、その一つが電子カルテを使った自動診断支援というものです。これは大量の電子カルテデータが病院にはありますので、個人情報ではありますが院内であれば利用可能であるということで、共同研究でやっています。今はそのデータを用いて抗がん剤の作用の自動最適化ということをしていて、つまり、どういう患者さんにどういう抗がん剤を使ったら一番副作用が少なくよい効果が見込めるかを予想しようということを、機械学習でやっているということです。
これは言語処理のあるあるなのですけれども、多くは実は数値データのほうが効果が高いというか、出力に貢献することはよくあります。実際にこの場合も検査データがありますので、もちろん検査データは非常に有効なのですが、プラスお医者様がその中のどこに着目したかが文字の電子カルテに書かれていますので、ここの言語処理が大事になってくるということになります。
本当に難しいのは、その2つを重ねて数字と文字と両方を使っていかに予測するかという手法が結構難しくて、今、トライしているところなのですが、そういうことをやっているというお話です。この場合ですと、データが法律系に比べてより口語に近い形で書かれているので、いわゆるブロークンな言語で書かれたものをどう処理するかという問題があるのと、個人情報保護の問題があって、いろいろ大変であると。
そして、先ほどお話しした数字との重ね合わせがありますので、これは法律系でもたまにありますが、そこの扱いは気をつけないと、数字を文字として扱うとうまくいかないことは多々あります。ですから、ここは様々な工夫が必要なところになっております。
医療系の別のものをやっているのですけれども、こちらは精神疾患の自動診断をずっとやっておりまして、いわゆる5大疾患と言われている鬱病、双極性障害、不安症、認知症、統合失調症というものがありまして、これらの患者さんからリクルートした被験者さんと健常者の方々を加えたグループでお願いして会話を録音させていただいていまして、その会話から自動的に診断をつけるということをやっています。結構当たります。こちらはさらに会話寄りですので、法律とは遠いと思うかもしれませんが、もし将来例えば法廷でのやり取りみたいなところが対象になるのであれば、あれは口語ですので、同じようなことが起きようと思います。
もう一つ、これをツイッター、今はエックスですけれども、SNSデータに適用したという研究もやっておりまして、こちらはSNS投稿から同じような判定をしようというので、大量データがありますので、多少ノイズが入るものの、同じようなことができるということでやりました。こちらもそれなりの性能で当たりますので、実用化可能なレベルなのですが、ここは法律系との共通点がありまして、医療系においても結果をどう使うかは常に問題になっていて、我が国の文化だと、人間が責任を取れないと使いたくない、使えないことが多いのですね。この場合だとお医者様がそこに当たるので、お医者様の補助システムに徹するしかないというのが現状です。法律系においても恐らく同様のことが起きて、どのくらい自動化したものを出していいかというのは課題としてあると思います。
ここにどれくらいいわゆる生成系AIが使われうるかという話なのですが、試しているところですが、あまり使えない可能性があると思います。それは口語系のデータがそれほど訓練データに含まれていない可能性が高いのと、先ほど角田先生の話にもありましたけれども、途中の推論過程の説明がしづらいところがあるので、あまり適していないというのがあります。そして、両方とも個人情報で、ChatGPTには出せないということです。
もう一つ、こちらからが本題でして、今回の法律系の話のコアになるところですが、法律系の話というのは論理がありますので、専門用語でいいますと含意といいますけれども、例えば私は人間であるという言葉と私は動物であるという言葉があったときに、人間であるということは動物であることを含んでいますね。そういうものを含意関係といいます。
ある文のペアがあったときに、それが含意なのか、矛盾なのか、中立なのかという判定があらゆる論理的な種類のコアになると考えられます。
例えば私が以前参加していた「東ロボ」というプロジェクトでの社会科の自動解答みたいな問題は、これは教科書の内容が問題文を含意しているかどうかが分かれば一応マル・バツはつけられるということなので、できるわけです。この後にご紹介する今も取り組んでいる司法試験の自動解答というものがありまして、国立情報学研究所の佐藤健先生とずっとご一緒にやっているもので、その言語処理部分を私がやっているわけですけれども、自動的に司法試験の民法短答式の問題に答えられるかということをしております。これも同じように法律文が問題文を含意するかどうかが分かればいいわけです。
これの応用の一つで、先に別件をご紹介しますが、インターネット上の世論の自動推測ということをしていまして、世の中にはフェイクニュースがあふれているので、自動的に分かったらいいのではないかということを考えています。実際にはフェイクかどうかは現場に行かないと分からないのですね。例えば何時何分首相がどこにいたみたいなことは現場の人にしか分かりようがないわけですけれども、それでは難しいので、一歩引きまして、ある人が矛盾した発言をしているのか、あるいはほかの人と含意する発言をしているのかを自動判定しようと。そうすると、同じ方が矛盾した発言をしている場合は、恐らくうそをついているか、気を変えたか、何かおかしなことを言っているかの可能性が高いので、そういうことを積み上げていくと、この人たちは同じことを言っている、この方々は矛盾したことを言っているというグルーピングができて、議論の流れが可視化できようということを考えてやっています。そうすると、フェイクニュースの可能性があることも分かるし、その判断基準として、どこから流れてきたかという情報の流れが分かるだろうということをしているということです。ですから、含意関係、矛盾関係が分かると、法律的な論理だけではなくて様々なことに使えることになるわけです。ちなみに、この件は政治学応用と私は言っていますけれども、世論というのは、今、ネットワーク上、インターネット上でおおむねつくられていますので、そこが分かればこれからの世論の流れが分かるのではないかということをしようとしているということです。
そのためには、実際にはユーザーの属性が分からなくてはいけないと思っていまして、どういう人であれば、どういう情報を摂取すると、それに対してどう反応するか。つまり、リツイートしてしまうのか、意見を変えるのか、意見を変えないのかが分かる必要があって、その際どういう属性かを自動的に分かるようにするために、クラウドソーシングでインターネットユーザーの属性調査をしまして、これに基づいて機械学習で当てようということをしています。そうすると、例えば外交的な人であるとか、年齢層がこれぐらいであるということが分かれば、そこからこういう話が流れてくると、リツイートしてそれを広げるかどうかが分かるのではないかということを全て積み上げれば、全体的な世論の流れが分かるであろうということを考えています。ですから、基盤的には先ほどの文の間の関係性が分かる必要があるというのは、お分かりいただけたのではないかと思います。
そして、本題ですね。法律系ですけれども、長らくCOLIEEというもの、これも佐藤健先生とご一緒にやっておりまして、こちらは毎年開催の国際コンペティションで、法律文書の自動処理をみんなでお題に対してオープン参加で解き合って、自動的なシステムをつくって、その性能を競うというものです。この性能を競うタスクというのは、我々の人工知能系の分野ではよくやられているのですが、その一つで、これは主催者側かつ参加者としてやっています。タスクは大きく2つありまして、片方は判例法、カナダ連邦裁判所の判例を使ったもの、もう一つは成文法で、我が国の司法試験の民法短答式で使ったもので、今日は主に後半のご説明をしたいと思います。
司法試験の民法短答式の問題をうまく再構成しますと、問題文に対して関連する条文があるでしょう、その問題文と関連条文が含意の関係にあるかどうかをマル・バツで答えなさいという形にブレークダウンすることができます。この問題を出題して、機械に自動的に解かせて、その性能を競うというものです。現状、過去問の数は限られているものの、1,000問ぐらいの過去問が使える状態にあり、毎年最新の年の100問程度の問題を出題して機械に解かせようということをしてきているわけです。ちなみに、国際ですので、人間に日本語から英語に翻訳していただいたデータも提供しています。例えばこのような感じで、前半の民法短答式第14問何とかとありますけれども、この文章を与えたときに、関連条文も同時に与えて、これはどれが関連条文かは人間の専門家につけていただいていますけれども、この2つのペアが含意の関係にあるかどうかを当てるということになるわけです。
当然法律条文と全く同じことが書いてあれば適法ですので、それはマルなのですけれども、普通はもちろん違います。この例は簡単な場合で、単語が相当共通していますので、比べやすいのですが、普通は書いてある字面、単語が違いますので、法律というのは抽象的に書かれていますけれども、実際の事件はもっと具体的な個人名、サトウさんですとか、あるいは会社名とか、ある日、何々さんがどこそこにいて包丁で刺したけれども何とかと、そういうことが書いてあるわけですね。そこのひもづけをするには1段抽象化が必要なので、相当に難しい問題であると思います。それがタスクということです。
これはお手元にないスライドなのですけれども、実際にこれまでそういうものをルールベースでやったことがありまして、ルールベースといいますか、言語学的な処理の結果を使って説明可能な形をやってきました。この場合だと、例えば主語、述語と目的語のペアを取って、それが同じかどうかをチェックするとか、そういうことをすればいいのですが、それだけでも結構難しくて、例えばここに「取消権を有する」と書いてありますね。これと「取り消せる」というのは同じ言葉、同じ意味のはずですが、言葉の構成上は違って見えるので、そこが同じであるということすらきちんと処理しないと分からないのです。それぐらいまでに言語の言い回しの違いは様々なレベルでありますので、そこを吸収するのは結構難しいことであることがお分かりいただけると思います。
こちらもお配りしたスライドにはないのですが、さっきの角田先生のお話を聞いて追加したのですけれども、佐藤健先生はずっとこういうPROLEGと言われている言語をつくってくださっていて、この形にさえすれば、判決まで出せるということをおっしゃっています。Prologという言語の発展版、法律版と思っていただければいいと思います。問題は、言語処理屋の役割は上に書いてあるような日本語が与えられたときに下の形に変換することであると言われまして、それはそうなのですけれども、ただ、実際にはここが非常に難しく、この下の論理的な形式における名前は人間がつくっていて、一致しないわけです。さらには書いていないこともたくさんあるので、そこを埋めないといけないということがあって、相当に難しい。例えばこの場合、出世払いの話なのですけれども、出世払いということが「出世したら返す」と書いてあったら分かるか、それが不確定期限付契約だと分かるかというと、相当難しいのは想像に難くないと思います。そのように、実は簡単にできそうに思うところでも言語処理のパートが難しいことがあって、なかなかつながらないということがあったわけです。
これもお手元にないスライドですが、このプロジェクト自体は裁判の自動化をある種、最終目標に置いていますので、最終的には全てつなぐと判決まで出たらいいねということなのですけれども、難しいのは言語処理パートだと私は思っていまして、例えば証拠から事実認定をする部分ですね。あるいは、今、まさにそうでしたけれども、法律文書に事件の要素を当てはめる部分が様々なレベルの抽象化があって、本当に難しいということが少しお分かりいただけたらいいと思います。
そんなわけで毎年やってきたのですけれども、最新のタスクについては2023年6月に結果を報告してきたのですけれども、最新は残念ながらといいますか、いわゆる生成系AIが一番よい性能ではありました。ただ、問題は、これは角田先生もおっしゃっていましたけれども、果たしてこれらシステムが中で論理推論をしているかということですね。あり得るのは、訓練データに答えと似たようなものが実は入っていて、それで分かったという可能性。その場合はもちろん解けますし、実用的にはそれでもいいのかもしれませんが、我々がやらせたいことはどちらかというと一から論理を組み上げて判断してほしいので、それができたとは言えないので、どうしようかということになるわけです。
さらには、現場で使うには根拠、途中の過程の説明が必要で、いわゆる説明可能AIと言われていますけれども、いわゆる生成系AIというのは、今日ご説明していませんが、全てを次の単語の予測で積み上げて文章をつくっているだけの仕組みですので、途中の過程を説明せよと言えば出してきますけれども、出してきたものは恐らく実際の過程とは違います。我々はこの次のステップは、説明可能なAIをつくるための新しいタスク設計とその評価だと思っていて、それを今、ちょうど設計しようとしているところです。
ですから、性能が高いからといって一から組み上げているわけではない可能性があることは考える必要があると思います。実際に生成系AIの場合は、恐らく論理的なことができるように見えても、どちらかというと既存の論理的な結果をうまく引っ張ってきて、その浅い重ね合わせで解いていると思われます。代わりにたくさん知っているのでできるということだと思うので、さあ、いいのかどうかですね。ただ、もしかすると世界の問題のほとんどは、どこかで見たことの似たようなもので収まるのかもしれません。そうすると解けるわけですが、そこはどうかというのは、実際の社会がどうなっているかという問題なのと、実際に使う側がそれでよいと思えるかどうかによると思いますが、我々としては論理的な過程ができるようにしたいと考えているわけです。
最後にご紹介したいのが、もう一つ、生成系AIが難しいと思われる例、これはまた全然別のもので、長らく私は人狼知能という仲間たちとやっているプロジェクトなのですけれども、人狼という会話ゲームをご存じでしょうか。若者は全員知っているので、もし知らないと若者ではないということになるのですけれども、会話でうそつきを見抜くゲームです。1人か2人ゲームのプレーヤーの中にうそつきが交ざっている役割設定になっていまして、その人たちはうそつきではないふりをするのですけれども、人狼と言っていますけれども、それで人をだまそうとするので、その人たちを会話だけで見抜くゲームです。これは相当に高度なもので、例えばうそをつこうと思ったら、自分の中には本当の自分と人に見せたい自分が同居します。さらに、それが外からどう見えるかを考えると、Aさんは自分をうそつきと思っています、Bさんは思っていません、そうすると、Bさんは自分をうそつきと思っているAさんを見ているけれども、それはどうかみたいな、様々な組合せが爆発的に増えます。そういう様々な組合せの可能性を考えることが、恐らく現在の生成系AIでは難しいのではないかと。まだ研究途中ですので分かりませんが、私が試した限りでは難しそうに見えます。そもそもうそをつかせることも難しいので、そこをどうするかが今後の課題の一つになるだろうと思われます。
実際にこれも最新の、これも毎年コンテストでオープン参加で自動プレーヤーをつくって対戦させているのですけれども、ChatGPTをはじめとする生成系AIの結果、会話は非常にきれいになりました。語彙・文法はとても流暢で、実際に人間と見分けがつかないレベルになってきてはいるのですけれど、さっきお話ししたような複雑な設定、複雑な関係というところがまだ取れていないように見えます。ですから、そこが次の課題と考えられるので、もしかすると今の生成系AIの単なる延長ではできないかもしれません。
そうしますと、最後に今後のお話をしたいのですけれども、私自身は言語処理の研究者ですので、研究者は当然常に世界一を目指さなければいけないので、ChatGPTなり既存のものに負けるわけにはいかないわけです。そうすると、それを超えるものをつくろうと思うと、今日は中身のご説明はしていませんが、恐らく今のLLMというか生成系AIの肝は、インストラクション部分だと思うのです。こちらのファインチューニングがどうなっているかに大きく依存しているので、そこの仕組みを探りたいと。現状その仕組みは中身が複雑過ぎてよく分かっていないのですが、どういうものを与えたらよりよくなるか、どういう場合によくなるかを探った上で、その先というのは一つあるかと思っています。
もう一つは、どこかで恐らく限界を迎えますので、私自身は昔から人に近い仕組みにしたいと思っていて、今のトランスフォーマーベースの仕組みはおよそ人間とは遠いと思われますので、もっと人に近い仕組みをつくって、結果的に人に近いことができるようにしたいと思っています。そうすると、最終的には「『古典的な』言語処理と深層学習の融合」と書いてありますけれども、いわゆる記号処理ですね。こうだからこうみたいな決定的な処理と今の確率的なベクトルの演算をうまく結びつけて、性能は高いけれどもちゃんと記号で表現できて説明できるというものをつくりたいと思っています。
駆け足でお話ししましたが、何とか15分に収まっていないような気がしますが、これで一旦終わりにしたいと思います。ありがとうございました。残りの部分は付録ですので、よろしければご覧ください。

事務局（中野）： ありがとうございました。
それでは、何かご意見、ご質問等ある方の挙手をいただければと存じます。
では、安野構成員、お願いいたします。

安野構成員： プレゼンテーションをありがとうございました。大変興味深くお聞きすることができました。
狩野先生に1点ぜひ聞いてみたいと思ったのが、今の生成系AI、ChatGPTなどは次のトークンを予測しているだけで、実際の内部でどういう推論をしているかよく分からないねという話があったと思うのですけれども、これは将来的にどうなのだろうと思っていて、つまり、見栄え上、そのロジックを完璧に説明してくれるようになったAIを見たときに、今、大きなニューラルネットは中でどういう構造があるか分からないですけれども、本当に推論に近いことをやっている可能性もあるだろうし、それを完全に否定はできないと思うのですね。これはニューラルネットベースのものだけではなくて違うアーキテクチャーになったときにも、こいつが本当に理解して推論してこの結果を出しているのか、実は理解していないのだけれどもかなり正解が出てくるようなアーキテクチャーになっているのか、そもそも見分けがつくものなのかが若干疑問に思いまして、そこら辺は議論があったりするのですか。

狩野准教授： これは完全に私の研究なのですけれども、今、確かめている範囲だと、先ほどお話しした含意関係のシンプルなものほどできないです。ということは、恐らく似ている何かの手がかりを知っていないとできないのだろうと思うので、論理推論はできていないことがあると思います。

安野構成員： 現状のAIがというよりかは、何らか複雑な動くシステムがあったときに、本当に中身を理解しているのか、理解していなくてほとんど同じ答えが返ってきているのかの見分けがつくのかどうかという質問でした。

狩野准教授： そもそも理解しているとは何なのかという話になってしまうのですけれども、細かいところを説明できるほどに内部のステップがあるかということだと思うのですね。似ているもので似ているからというだけではないのかというのを試す方法ですが、それがさっきお話ししたところで、下手に情報をたくさん与えると、本質的でない部分で似ているから分かってしまうのですけれども、あまり情報がない状態でシンプルな形で問うとできないということは、恐らくできていないと言えるのではないかと思って、先ほどのお話をしました。

安野構成員： なるほど。理解しました。ありがとうございます。

狩野准教授： ただ、研究中なので、もしかしたらできてしまうかもしれません。まだ試す余地はあると思います。

安野構成員： ありがとうございます。
理解しました。理解が何かがよく分からないと。

事務局（中野）： ありがとうございます。
米田先生、いかがでしょうか。

米田構成員： ありがとうございます。
今日、私の接続環境の関係で最初の部分を聞くことができなかったのですが、全体的な感想を述べさせていただきたいと思います。現在開発しなければならないシステムは、出来上がったものを使う方々がいて、角田先生も少し触れられましたけれども、アウトプットがどのような形のものなのか、なおかつ出てきたものを、実務家の人たちはそのシステムから出てきた言葉を自分で操作、確定して発信していかねばならない。ここから出てきたものが自動的に社会に流通するわけですが、実際に社会に出していく部分についての配慮を踏まえた議論が、まだこれからの課題のままかなと感じました。
機械の中で論理性があるとか、きちんと正しく推論しているとかということについて追求するというのは学問的にも、システムを開発する上でも大きな価値があるのですけれども、社会実装したときに、我々が使う場面では、下手をするとフェイクが通用してしまうように、どのようなものであっても流通してしまえば使われるのですね。そういう社会における言語の特性を踏まえて、そこでよりよい正しさを導けるようにするという部分が必要なのですけれど、それがシステム上どの程度含まれているのかがよく分からなかったというのが感想です。
われわれがこのPoCで成果を上げ、法制事務のデジタル化を推進する上で、角田先生がおっしゃったような身近なところからやっていくという戦略を着実に押さえてやっていくことが重要なのだろうという感想をあらためて持ちました。もちろんこれはたとえばＡＩの活用可能性や、現在の法制事務の取組み方をシステムを使ってもスムーズに再現できるよう操作できる可能性の研究をどんどん進めることについてどうこう言っているわけではなくて、このワーキングチームで出さなくてはいけない結論のところでは、出てきたアウトプットの性質や限界を利用者が共有できて、実務上やアウトプットを踏まえて議論をする作業の文脈にどう内蔵されるか、きちんとそこと結びつけた議論をしなければいけないという感想を持ったということでございます。

狩野准教授： 私がお答えしていいのか分かりませんが、私から見ますと、それこそが説明の要素で、単に出力で結果だけ出した場合に、どのような人であってもそれは何でかと聞きたくなると思うのですね。それがないことには仕方がなく、かつ説明がうそっぱちだとしようがないので、そこなのではないかと私は思っています。

米田構成員： 先ほどの説明がうまくなかったかも知れません。結局社会で人々が使うのは人と人の間に入ってくる情報なので、人と人の間で説得力を生み出せるような情報が提供されていればいいという形になると思うのですね。今日の議論では、機械と人とが1対1で対峙する場面の議論をやっているように思えるのですが、法の世界という立法で法律をつくるのもそうですけれども、必ず人と人とのコミュニケーションで、そこでどのような資源を投入できて議論ができるかということにつながると僕は見ているので、そういったところに出てくるものが、それが具体的に使える形でどのように出てくるのかということの絵が欲しかったというのが、狩野先生については特にそこは思ったところです。

狩野准教授： なるほど。サポートシステムにならざるを得ないので、そうすると、実際の利用は人間が機械を操作するという1対1にならざるを得ないのではないでしょうかね。
そうすると、こういう形になるのかと。

米田構成員： 法的な議論についての何かの結論を出そうというときは、人と人が対立する議論をして、証拠がどうかという議論をして、結論を出すことになるので、そのときにどのような情報が出てくるのかというところの位置づけが、僕が持っている感覚とずれていたところがちょっとあったということです。研究の機械と人との関係で1対1の関係で探求しなければいけないところがあるのは、もちろん当然だと僕は思っています。

狩野准教授： 分かりました。ありがとうございます。

事務局（中野）： 貴重なご意見、米田先生もありがとうございます。
お時間になりまして、まさに米田先生、狩野先生からご議論いただいた内容にも関連すると思いますけれども、次の議事3では、我々職員が実際にAIを使って法制事務をしてみたというところで、担当の山内から5分程度でご説明させていただければと存じます。

事務局（山内）： よろしくお願いいたします。事務局の山内でございます。
AI等を利用した法制事務補助の実験結果についてご報告をさせていただきます。少々早口となりますことをご容赦ください。
冒頭は振り返りでございますので、口頭では割愛をさせていただきます。ページをおめくりいただきまして、7ページ目から今回の本題でございます。
8ページ目をご覧ください。ここからAI等を利用した法制事務補助の実験結果をご説明いたします。左側、実験の概要でございます。本実験は、LLMを用いたAI等の法制事務への適性や、すぐに実現できそうなことなどを整理することを目的として実施しております。
前回法制事務のデジタル化検討チーム第8回会合において予告をさせていただいたものでございます。実験の方法は、職員が実際に既存製品を用いて法制事務補助のアイデアを実験する形で行いました。実験例は、デジタル庁内の職員から募集したものでございます。
右側、実験結果の概要でございます。具体的な実験例は後ほど幾つか紹介させていただきますけれども、概要といたしましては、1ポツ目ですけれども、すぐに実現できそうなものも幾つか見つかっております。条文や政策概要などの文章を基に、資料や図を作成したり、アイデアを出力する実験例がございました。2ポツ目でございます。他方、中長期的にさらなる研究を要すると考えられるものもありまして、条文を生成したり、法令条文特有のチェックを行う実験例がございました。3ポツ目でございます。いずれの場合も、出力結果を法制事務経験者が確認したところ、修正を要する場面が複数あったという点も確認されました。4ポツ目でございます。今回の実験例の中には、法令APIと組み合わせてコードを書くことによる実験例も複数ございまして、実用性が高いと考えられる例も報告されてございます。APIや法令等データとAIの組合せの有用性が示唆されてございます。
次のページは、LLMを用いたAIの特性と法制事務観点での考慮事項について、以前の会合の内容を引用しております。これらの考慮事項については、引き続き注意が必要と考えますので、再掲をさせていただいております。
10ページ目から、実際の実験例をご紹介させていただきます。口頭では簡単な紹介とさせていただきます。まず、現在表示している10ページ目ですけれども、条文案検討の前提となる政策検討のブレストでございます。法律を含む法令案の立案に当たっては、政策の詳細を検討する必要がございますので、これをいわゆる想定問、質問の形でアイデアを列挙するというものでございます。
続いて、11ページ目でございます。この実験例では、右側では行政手続法の条文を入力して、行政手続法で定められているパブコメ、これが必要か不要かを判断するフローチャートを出力してございます。ただ、注意していただきたいのですけれども、当方がこの図を拝見いたしまして、項目が網羅的でなかったりなどの課題があることが分かりました。
とはいえ、図自体は出力されておりますので、法律の解釈が可能な職員が内容の修正を行うことを前提に、作業時間の短縮にはなるかと考えてございます。
12ページ目でございます。こちらは中長期的にさらなる研究を要する課題があると考えられる実験例でございます。条文案をLLMに生成してもらうというものでございますけれども、シンプルなプロンプトでは、法制度として必要な具体的な規定がなされていないなど、課題が多く見られました。具体的な規定を書いてもらうために指示を具体化したり、詳細化していたりすると、だんだんと改善されていきますけれども、そうやってプロンプトを精緻化していくと、正直条文を直接書いたほうが早いと感じる場面もございました。
ですから、アイデア出しとしての効果はあるかもしれませんけれども、プロンプトの工夫や問題を分割するなどのさらなる研究が必要と考えられます。
13ページ目でございます。法令APIと組み合わせる応用例でございます。詳細は割愛いたしますけれども、法令APIと組み合わせることで、条文の正確な内容に基づいたタスクを一定程度実行できることが確認できた例でございます。
14ページ目でございます。こちらの例では、実際の法令立案の現場で頻繁に行われる用例検索を支援するユースケースを実験してございます。こちらは今回新しく開発した、現在公開テストを行っている法令APIプロトタイプを活用しております。右上「調べたいこと」をご覧ください。例えば「計画」という用語が「政府が定めるもの」として使われている用例を調べたいとしたときに、これを入力して検索ボタンを押しますと、まずは自動で法令APIプロトタイプのキーワード検索APIで用語を検索します。それらの用語が、指定した用法、今回の場合「政府が求めるもの」という用法で用いられているか、ここにLLMを用いて判断してございます。フラグが立ったものを一番下の出力のように自動でリストアップいたします。出力結果は法制事務の観点で人によるチェックが必要です。かつ網羅的な調査は難しいという制約がありますけれども、該当する条文を高速でリストアップすることができ、検索の負担を削減できる実験例と考えてございます。
15ページ目をご覧ください。今回の実験結果を踏まえたさらなる検討課題ということでまとめてございます。
1ポツ目でございます。一定の結果が出ている実験例がございました。これらについては、どのようなプロンプトが有効かをさらに検討し、テンプレートやマニュアルの形で整理することが有益と考えられます。
2ポツ目でございます。条文の生成など単純なプロンプトでは、意図した出力がなされないものがございました。これらについては、プロンプトの工夫でどこまで対応することが可能かなど、中長期的にさらなる研究を行うことが有益と考えられます。
3ポツ目でございます。ユーザインタフェースの観点でございますけれども、法制事務において使いやすいユーザインタフェース、また、出力について人によるチェックが必要であるということが明示されるといった誤解を生じにくくするユーザインタフェースの検討が有益であると考えられます。先ほども議論がございましたけれども、現在のLLMの出力、大変流暢です。ですから、一見それらしく見えてしまうのですけれども、それでも使い手が、この場合、法制事務の専門家が、批判的にチェックできるようにというユーザインタフェースの工夫が必要と考えております。
4ポツ目でございます。法令APIの機能拡張の検討や、また、確率論的なモデルだけではなくて、決定論的なルールベースのチェックプログラムとの組合せ、これが有用と考えてございます。これらの自動チェックを行うための機能やAPIの検討、さらにAPIや法令等データの整備、これらとAIを組み合わせることによる法制事務補助アプリの検討も有益と考えられるとまとめてございます。
以上がAI等を利用した法制事務補助の実験結果でございました。事務局からの説明は以上でございます。ありがとうございました。

事務局（中野）： ありがとうございます。
お時間が押してしまっておりまして、大変短い時間になって恐縮でございますが、15時58分ぐらいまでご意見、ご質問等いただければと存じます。
早速、先ほどご発言をご遠慮いただいてしまいました渡部先生、よろしくお願いいたします。

渡部構成員： 今日のいろいろ興味深く聞いている中で一番楽しみにしていたパートでしたので、本当にありがとうございます。
今回私が発言したいのは、特に実際の実験結果がアンダーバリューされないように、しっかり委員としてコメントしておきたいと思います。いろいろな実験結果の中で、うまくいったところうまくいっていないところがあると思うのですけれども、今回のこの結果を見て、だんだんもともとなかった段階から法令APIと組み合わせることによってかなり精度が上がっていること、これはかなり特筆すべき点ではないかと思っています。
加えて、もう一個私から視点を提供したいのは、これは確かに法制事務の現場であれば100％に近いところを求めていくのですけれども、私が実際にAirbnbで住宅宿泊事業法の議論をしているときも、実際に対案を書けと言われても我々弁護士は書けないのですね。
そういう意味でいいますと、実際にレベルとしては100％正確でないにしても、こういうツールを使うことによって民間の法律の専門家または専門家でない方が、条文のようなものまたは突拍子もないものではないのだけれども何だか条文に似ているようなものをつくり出せるというのは、最終的には行政と民間とがしっかりとディベートをしていくためにも非常に有用であると思っているので、今はどうしても行政内部の利用ということで100％正しいというところに動いているのは間違いではないのですけれども、その一方で、実際に我々民間側がこれまで持っていなかったツール、知識が提供されるという意味で、現在の成果であってもかなり社会的に有意義なものなのだということは強調しておきたいと思います。
早口で恐縮ですが、以上でございます。

事務局（山内） ありがとうございました。
おっしゃるとおり、例えば法制事務の現場では100％の精度が必要だけれども、ほかのところでは今の状態でも使えるようなユースケースは確かにあろうと思いまして、用途によって求められる精度が異なるというのはそうですし、先ほどの角田先生の発表にもありましたけれども、AIの進化の中で例えば新しいサービスが出てきたりといったこともありますので、こういった法制事務という中での研究がほかの現場、いろいろな用途に使えるようなサービスを生む原動力になったらうれしいと考えました。どうもありがとうございました。

事務局（中野）： ありがとうございます。
ほかの方、いかがでございますでしょうか。

米田構成員（チャット発言）： 時間もあまりないと思うのでチャット欄にて書いておきますが、諸々の実験面白いと思いました。

安野構成員（チャット発言）： 試してみるといいかもしれないと思ったのは生成物のフィードバックをさせるといった実験です。（書かれていないだけでやっている可能性も高いと思いますが）最近スタンフォード大から出た論文（https://arxiv.org/abs/2310.01783）などではNatureの論文査読をChatGPTにさせてみたとき、意外と使えるフィードバックが出てきた（人間の査読者との一致率が高かった）というのがありました。法制事務でも、例えば法案のドラフトを入れてみると、上長や法制局から出てくるかもしれないインプットと一致率がそれなりに高いフィードバックが貰える可能性があると思いました。どれくらい一致するのかという傾向を見ておくのもいいかもしれません。

事務局（山内）： ありがとうございます。
書いていただいた内容、フィードバックを入れることで精度を高くしていくというような提案かと思います。

安野構成員： そうですね。ドラフトのフィードバックは別に間違っていても考えるきっかけを与えてくれれば有用ということが多くて、いろいろなところで使われているかと思うので、そういうものも試してみるといいかと思いました。

事務局（山内）： ありがとうございました。勉強させていただきます。

事務局（中野）： 安野構成員、ありがとうございました。

事務局（中野）： お時間が短くなってしまって恐縮でございますけれども、本日の議事は以上とさせていただければと存じます。
最後に、デジタル庁の審議官、蓮井からご挨拶をさせていただければと存じます。
蓮井審議官、よろしくお願いします。

蓮井審議官： デジタル庁の蓮井と申します。
本日は様々なご提案や闊達なご議論をいただきまして、誠にありがとうございました。
第一法規株式会社様及びFRAIM株式会社様から、法制事務のデジタル化及び法令データの整備・利活用に関する調査・実証事業の進捗状況についてご報告をいただきました。本事業は国家公務員の働き方改革やBPR、法令案の誤り防止、これは今、非常に重要なのでございますが、こういったものが期待されるところでございまして、各府省庁からも大変関心が高い事業であると同時に、法令ベース・レジストリ整備の基盤の構築につながる事業でございます。今回これまでの実証から課題についてもご紹介があったところでございますが、ぜひ本ワーキンググループでのご意見もいただきながら、着実に取組を進めていただきたいと考えてございます。
また、角田構成員、狩野准教授から、AIと法令についてこれまでの研究や取組の蓄積を踏まえた非常に貴重なご示唆をいただきました。私は現在実はAIも担当しておりまして、その観点でも非常にありがたいご示唆をいただきましたし、なおかつ法令も中野企画官とも担当しているものですから、かつて法令検索をかけたところ、5,000件や1万件という件数が出て、その瞬間にのけぞることがあったことを考えますと、今ははるかに進化しているのだと感じる次第でございます。今日のご指摘を踏まえまして、AIの得意とする分野や活用方法について見極めながら様々な試行をし、デジタル法制ロードマップの描く未来像に関する検討を進めてまいりたいと考えてございます。
以上、簡単ではございますけれども、私からのご挨拶とさせていただきます。今後とも何とぞよろしくお願いいたします。今日はありがとうございました。

事務局（中野）： 蓮井審議官、ご挨拶をありがとうございます。
では、時間となりましたので、本日の議事は以上とさせていただきます。
何分私の進行が悪くて、ご質問の時間、ご意見をいただく時間が足りなくなってしまいまして、誠に申し訳ございません。
本日の議事は、ご異議がなければ、議事録を作成し、皆様にご確認いただいた上で公開、資料につきましても、全て公開させていただきます。
それでは、以上をもちまして、本日の会議を閉会いたします。本日はご参加いただきまして、誠にありがとうございました。

以上

関連会議

• デジタル関係制度改革検討会
• デジタル臨時行政調査会（廃止）
• デジタル臨時行政調査会作業部会（廃止）
• デジタル臨時行政調査会作業部会 法制事務のデジタル化検討チーム（廃止）
• デジタル臨時行政調査会作業部会 テクノロジーベースの規制改革推進委員会（廃止）

関連政策

• 法制事務のデジタル化・法令等データの利活用に関する取組