法令APIを利用したリサーチツールを自作してみた【SmartRoppo】

 １． はじめに
 ２． リーガルテックっぽいプロダクトを作ってみた
 ３． SmartRoppoのコンセプト
 ４． SmartRoppoの主な機能・特長
 ５． なぜ自分で作ろうと思ったのか？
 ６． 今後の課題
 ７． おわりに

##１． はじめに

この記事は、じゃんく（@jank_2525）さんからバトンを受け継ぎ、「法務系 Advent Calendar 2019¹」の14日目エントリーとして執筆しています。

皆さんのエントリー、どれも個性あふれる素敵な内容で、毎日大変興味深く拝見しています。

##２． リーガルテックっぽいプロダクトを作ってみた

さて、突然ですが、リーガルテック的なプロダクトを作ってみたので、このエントリーをもってβ版を公開させていただきます。**【SmartRoppo】**といいます。

SmartRoppo －法令データベースを、もっと賢く－
https://smartroppo.com/SmartRoppo/index.html

ユーザー登録など面倒なことは一切不要で、どなたでも利用できます。
※スマホ・タブレットには対応していないので、PC（ブラウザはできればChrome）からご利用ください。

##３． SmartRoppoのコンセプト

SmartRoppoのコンセプトは、「法令のUI/UXをアップデートする」というものです（壮大）。

私自身は金融系の案件を扱うことが多いのですが、金商法や銀行法をはじめとした金融系の法令は、極めて複雑で難解なものが多いです。

それゆえ、恥ずかしながら、弁護士になって5年が経とうとしている今でも、「こんな条文があったのか！」と気づいたり、危うく読み方を間違えそうになることがあります（私だけではないはず…）。

ただ、こうした複雑・難解な法令は、裏を返せば、様々なケースを想定して具体的・詳細に書かれている（解釈の幅が狭い）ということでもあります。実際、業界の法規制に精通したクライアント様からの相談であっても、条文の内容だけでズバリ回答できてしまうケースもそれなりにあったりします。

つまり、法令の内容を「正確に」読み解くことができれば、それだけで求めている情報にたどり着けることも少なくないのです。というか、まずそれができないと解釈も何もないですよね。実務書等の文献に当たることももちろん大事ですが、最終的には原典である条文を確認することが不可欠でしょう。

あるイベントでお話させていただいた際のスライドを抜粋します。
こうした課題をテクノロジーの力で解決することがSmartRoppoのコンセプトです。

##４． SmartRoppoの主な機能・特長

SmartRoppoの機能・特長は、現時点では主に3つです。
（たぶん、文章で説明するよりも、実際に使っていただくか、上記のデモ動画を見ていただいた方が早いです。）

 ① 法令APIからのデータ取得機能（＋法令のリアルタイム検索機能）
 ② 下位規則の自動レファレンス機能
 ③ かっこ書きのハイライト機能

####① 法令APIからのデータ取得機能（＋法令のリアルタイム検索機能）

これまでの電子六法アプリは、自前でデータを保有するデータベース方式が多かったように思います。

これに対し、SmartRoppoでは、総務省が公開している「法令API²」を活用する方式にしました。
つまり、基本的にはアプリ側でデータを保有せず、アクセスの都度、最新のXMLデータをe-govから取得するという設計にしています。

API方式には、（e-govが適時に更新される限り）法令データが常に最新の状態に保たれ、アプリ側のメンテナンス（法改正等の反映作業）が基本的に不要である³という点にメリットがあります。
ただ、都度データを取得してくるという仕組みゆえ、表示速度はデータベース方式に比べて劣っているかもしれません。

####② 下位規則の自動レファレンス機能

#####　　・ 下位規則の重要性

複雑な法令の内容を正確に理解するには、各条文で参照されている「政令」や「内閣府令」といった下位規則を併せて読むことが不可欠です。
ただ、こうした各条文に紐付く下位規則をいちいち特定・確認するのは骨が折れる作業です。紙の分厚い法令集を、行ったり来たりしながら（栞代わりにペンを挟んだりして）確認したことがある方も多いのではないでしょうか。

そこで、SmartRoppoでは、こうした下位規則を自動で取得し、参照元の法令と一覧表示する機能（自動レファレンス機能）を実装しました。

#####　　・ これまでになかった？

これまでの電子六法アプリでも、手作業で（ゆえに限られた法令・条文に対して）レファレンスを付けていると思われるものは少数ながらありました。
一方、少なくとも私の知る限り、「自動で」（ゆえに全法令に対して）レファレンスを付ける機能を備えたものは、これまで見られなかったように思います（違っていたらすみません）。

とはいえ、SmartRoppoもまだ精度はイマイチですし、現状全ての法令には対応できていないので⁴、このあたりは順次改善していきたいと思います。

#####　　・ なぜ難しいのか？ ー「逆参照」の壁

なぜ下位規則の自動レファレンス機能が実装されないのか、私は以前から疑問に思っていました。なんとなく、割と簡単に実装できそうな気もします。

しかし、実際に作ってみてよく分かりました。実はこれ、法令の構造的な問題ゆえに、技術的にはそれなりにチャレンジング（というか超面倒くさい）なのです。

特に、API方式と両立させようとすると難しく、いろんな方法を試した結果、それなりの精度でワークしそうなものは、今の自分には一つしか見つけられませんでした。

難しい理由は、端的にいうと、下位規則のレファレンスは、「参照元には参照先を特定する情報がなく、参照先にのみ参照元を特定する情報がある⁵。そうすると、まずは参照先を特定する必要があるが、その参照先をどうやって特定するのかが問題。」という「タマゴとニワトリ」のような構造になっているからです。

私はこれを「逆参照」と呼んでいます。

人間が作業する際は、「ここでの『内閣府令』は『○○府令』のことを指していて、だいたいこの辺に書いてあるはず」といったアタリを付け、その周辺の条文をチェックするといったやり方を採ることが多いように思います。

しかし、こういった「肌感覚」的なものをプログラムに書こうとすると、なかなか難しいわけです。

####③ かっこ書きのハイライト機能

これは見たまんまですが、かっこ書きをその階層ごとに色分けする機能です。かっこ書きが長かったり、かっこが多重になっている条文が読みやすくなります。

ただ、この多重かっこ（ネスト）の処理がなかなかくせ者で、現状バグが出てしまっています。
原因は分かっているのですが⁶、時間が足りずまだ対応できていません。すみません。。

##５． なぜ自分で作ろうと思ったのか？

SmartRoppoの開発にあたっては、コーディングはもちろん、設計や（イケてない）デザインも含め、とりあえず自分一人で手を動かしてやってみました⁷。

私は自他ともに認める「超ド文系」の人間です。技術的なバックグラウンドは何一つありません。プログラミング言語も全く触ったことがなく、「HTML…？」というレベルからのスタートでした。

そんな状態から、どうして自分で作ろう／作れると思い至ったのか。自分でもよく分からない（というか忘れた）のですが、以下のような想いがあったように思います。

• リーガルテックという言葉が広まりはじめ、弁護士等の専門家が自ら起業するケース⁸も出てきた。
• 興味はあるので海外の事例とか調べてみたりアイデア（DDとか自動化できたらいいよね！）とかぼんやり考えてみるものの、具体的に何かするわけでもなく空想で終わる。
• なんかモヤモヤ。せっかく法律の専門性を生かせるテック分野なのに、何も手を動かさずに見てるだけなのはもったいない⁹よなあ。
• どこまでできるか分からないけど、技術的にも興味があるし¹⁰、とりあえず自分が欲しいものを作ってみようか。プログラミングやったことないけどまあ頑張れば何とかなるやろ（適当）。

こうした経緯で開発を始めたわけですが、弁護士業務の合間を縫って、あーでもないこーでもないと考えながらコードを書いては消し、無限エラー地獄と戦うのは、思っていた以上にハードでした。

特に前述の「逆参照」機能については、正直、めちゃくちゃ悩みました¹¹。いろんな技術を試しては壊してを繰り返す中で、頭がハゲそうになりました¹²。

でも、**エンジニア志望でもない自分がプログラミングを学ぶのであれば、何か形にしないとやる意味がない（Deploy or Die¹³）。少なくとも自分自身が実務で使いたいと思えるものでなければ作る意味もない。**そう思っていたので、気合いで乗り切りました。
基本は怠惰なダメ人間ですが、やると決めたことは何だかんだやるんです。

結果、なんとか形になって少しほっとしています（まだまだ課題は山積していますが）。

開発の詳しい経緯（どうやってプログラミングを勉強したか）や技術面の詳細などについては、（もし興味を持ってくださる方がいれば）別の機会に書きたいと思っています。技術面の話は、扱っているデータが**「法令そのもの」**であるだけに、法務パーソンの皆様にも興味を持っていただけるのではないかと思います。

##６． 今後の課題

とりあえず公開はしてみたものの、時間や技術力の制約もあり、まだまだ十分な性能・機能を備えているとはいえません。
今後の課題や追加予定の機能をざっと書き出してみると、こんな感じでしょうか（順不同）。

• 処理速度の向上（API方式と自動レファレンス機能のせいですがそれにしてもちょっと遅い）

• 自動レファレンス機能（逆参照）の精度向上・対象拡大
• 条数検索・用語検索機能（UIはありますがこれも時間が足りず）
• 順参照の自動レファレンス機能（逆参照の前にこっちをやるべきでした）
• 法令外国語訳DBの自動参照機能¹⁴
• 判例・パブコメ等の関連資料のレファレンス機能
• メモ・ブックマーク等のパーソナライズ機能
• デザインの改修（絶望的にセンスがないので誰か助けてください…）
• XMLデータ化されていない法令（裁判所規則、告示等）のカバー
• 正規表現による検索機能
• その他細かいバグの修正

##７． おわりに

まだまだ未熟なプロダクトですが、是非一度触ってみていただければと思います。
そして、どんな内容でも結構ですので、ご意見ご要望などいただけるととても嬉しいです（@lawyer_alpaca）。

長々とお付き合いいただきありがとうございました！
次は10ru（@oga10ru）さんです！よろしくお願いします！

1. 「裏」もあります。 ↩

2. https://www.e-gov.go.jp/elaws/interface_api/index.html ↩

3. 法令APIに対応していない法令もあります（データ容量が大きい等）。とはいえ、それほど数は多くないので、定期的に改正の有無をチェックし、手動で最新のXMLデータに差し替えることで対応可能です。 ↩

4. レファレンスの処理自体はプログラムで自動的に行っているのですが、プログラムにデータを渡す際の前処理的な作業を一部手作業でで行っているためです。公開までに時間が足りませんでした。。 ↩

5. 例外として、参照元にも参照先にも両者を「明確に」紐付ける情報がないケースもあります。 ↩

6. いわゆる「読み替え規定」がかっこの対応関係を崩しているためです。例えば、「この場合、●条の『▲▲▲・・・（◆◆◆・・・』という規定は、『△△△・・・（◇◇◇・・・』と読み替えるものとする。」という条文があった場合、「開きかっこ」に対応する「閉じかっこ」がデータ上は存在しないことになります。これにより、かっこの対応関係にズレが生じ、ネストが意図せず深く（あるいは浅く）なってしまうのです。 ↩

7. もちろん、一般的なフレームワークやライブラリは使用しています。その意味で、「粉からカレーを作る」「牛を育てるところからハンバーグを作る」といったレベルでスクラッチしたわけではありません。念のため。 ↩

8. 代表的な例として、Holmesの笹原さん（@kenta_holmes）、GVA TECH（AI-CON）の山本さん（@gvashunyamamoto）、LegalForceの角田さん（@NT_LegalForce）、Legal Technology（Legal Library）の二木さん（@LEGALLIBRARY_F）などが挙げられます。ゼロから事業を立ち上げられたこれらの方々を、私は心の底からリスペクトしています。自分には到底マネできないので。。 ↩

9. とはいえ、リーガルテックについては、起業する人、開発する人、使ってみる人、情報発信する人、静観する人など、関わり方は人それぞれだと思います。個々の技術やプロダクトに対する評価も人それぞれだと思いますし、それでいいと思います。 ↩

10. このときは、プログラミングを学べば技術のことが分かるようになると思っていました。しかし、今はちょっと違って、両者は（相互補完的な関係にはあるものの）基本的には別個のものであり、それぞれ勉強する必要があると考えています。法務に例えるならば、「契約書を何百通レビューしたところで、それだけでは民商法のことが分かるようにはならない。逆もまた然り。両方とも、それはそれとして勉強しなければならない。」という感覚でしょうか。 ↩

11. 全然関係ないですが、バチェラー3面白かったですね。 ↩

12. もともと髪の毛は多い方なので、まだ大丈夫だと思います。 ↩

13. MITメディアラボ（元）所長・伊藤穣一氏の有名なフレーズ。スピーチの全文はこちら。 ↩

14. 日本法令外国語訳データベースシステムで公開されている英訳法令は現在約750（全法令の1割弱）にとどまりますが、重要法令を中心に今後3年間で大幅な拡充が予定されているようです。http://www.moj.go.jp/housei/hourei-shiryou-hanrei/housei03_00013.html ↩