リーガルテックのパラリーガルの一日

長島・大野・常松法律事務所から8億円の出資を受け、今夏の一般販売に向けて小松製作所様および福岡銀行様と実証実験を行っているリーガルテックベンチャーであるMNTSQ株式会社でパラリーガルとして勤務している者です。正社員として入社してから1年が経過しました。

コロナ禍で電子締結が話題になり、リーガルテックが注目を集めている状況は内部にいる私も認識しているのですが、「リーガルテックの中の人が具体的に何をやっているのか？」についてはこれまでほとんど発信されてきませんでした。おかげさまで弊社に応募してくれる方もいらっしゃるのですが、毎回説明に苦慮しているという状況です。そこで、イメージをつかんでいただくため、お話しできる範囲で弊社の業務内容をご紹介します。

法律と機械学習に関する大量の専門用語が登場するため「読者0人では？」という不安がありますが、雰囲気が伝われば十分だと思っているので各自ググっていただければと思います。

アドベントカレンダーにかこつけて書いた以前のステマ記事はこちらです。

私自身の自己紹介についてはwantedlyの入社エントリをご覧ください。

リーガルテックをつくるパラリーガル | MNTSQ, Ltd.

１．定義作り

たとえば「損害賠償の責任を制限する条項」を自動検出するアルゴリズムを作りたいとしましょう。こんなの「責任」「賠償」「負わない」みたいな文言で適当に検索すればいいじゃないかと思われるかもしれませんが、本当に実務家が見たいのは「相手方への請求が民法上可能なのに、これを制限する契約がなされている契約条項」なので、そんな解像度では全然ワークしません。なので、より細かく分析する必要があります。

たとえば、「不可抗力が発生した場合には甲は責任を負わない」といったような条項を見たいか？というと全然見たくないです。実務家の頭の中の整理では、こうした不可抗力や反対債権の帰趨の問題である危険負担は、損害賠償の責任を制限するという問題とは別のものと理解されているからです。法解釈は表層的な文言より複雑であることの一つの現れです。「相当因果関係の範囲でのみ責任を負う」という条項も民法のデフォルトルールのまんまなので全然見たくないし（民法416条1項）、同様に「故意または過失がある場合損害賠償責任を負う」という条項もこんな条項書かなくてもいいくらいのやつなので見たくないです。しかし、後者が「故意または重過失がある場合損害賠償責任を負う」であれば、これは軽過失を免責しているので絶対検出すべきです。

そうやって分析していくと、今度は制限の態様も分類してやりたい気持ちが湧いてきます。例えば、小分類として「賠償額を制限している場合」について考えてみましょう。賠償額を制限する場合には、上限金額を絶対値または相対値（取引金額など）で設定している場合と、違約金を固定値で設定している場合とがあります。後者は微妙であり、民法上は損害賠償額の予定と推定されますが（民法420条3項）、あえて違約金について定める場合そんな契約の方がむしろ稀で、だいたいがいわゆる違約罰であり、別途損害賠償を請求することを妨げられません。すなわち、文言上「違約金」と書いてあっても損害賠償を制限する効果を有している場合といない場合とが混在しています。アルゴリズムに判別させようとすると意外と大変です。

また、通常予想される損害より大きい金額が損害賠償額の予定である場合には、この条項は賠償責任をむしろ増大させる効果を持っていることになります。このような解釈は、契約書外の情報（当該事業により発生する損害賠償額の相場等）に依存するため、契約書のみを解析対象とするAIには不可能な業ということになります。AIにできることとできないことの見極めが重要です。そうやっていろいろこねくり回しているうちに、異常な量のマニュアルが出来上がります。よかったですね。

ほとんどの人間は雑にAIに突っ込むといい感じの回答を返してくれる世界を想像していると思いますし、早く私もそうなって欲しいと思っていますが（AI早く仕事を奪ってくれ！！）、アノテーションのリソースも限られている中で、例えば通常のTF-IDFであれば「故意または過失」と「故意または重過失」の差などは狙ってやらない限りほとんど検出できないので、Feature Engineeringでドメイン情報を組み込んでやる必要があります。最近、O’REILLYの「Natural Language Annotation for Machine Learning」を読んでアノテーションについて勉強しているのですが、ルールベースは機械学習アルゴリズムと同じかそれ以上の成果を出しうるし、特にルールベースはドメイン制約的な認識タスク（domain-constrained recognition task）に適用するとよい的なことが書いてありました（p.143）。手段としてのAIに固執することなく、より良い方法があるなら何でも使うべきだということです。

もっとも、最近やっとBERTが何やってるかわかってきたと思ったら先週GPT-3のような革新的な新技術が彗星の如く現れたりする日進月歩の世界なので、機械学習でできることの幅も質もどんどん広がってきています。

２．アノテーション

先ほど決めた定義に基づいて、大量の契約書を見てラベル付けをしていきます。
今度は例としてあるドキュメントが「約款」かどうかを検出するアルゴリズムについて考えてみましょう。約款といえば新民法でおなじみ定型約款であり、法律家は基本的に約款といえば定型約款だと考えていると思いますが、社会は広いので、アノテーションをしていくうちに「約款」という文字列は思ったよりいろいろな場所で使われていることがわかってきました。

一つは業界の雛形です。例えば定期借家推進協議会という団体は、自身が作成した雛形を「定期建物賃貸借契約約款」と題して公表しており、実際これを利用した契約書がかなり流通していますが、不動産賃貸借契約は不特定性を満たさないため、定型約款とは解されないと思われます（新民法に対応した契約書では約款という呼称は修正されていました。新民法を意識したものと思われます）。もう一つは、自分たちが用意している契約書の雛形を「約款」と呼称して公表している地方公共団体のパターンがあります。さらに、単に条文のことを脈絡なく「約款第n条」と呼んでいる契約書もあります。別につけなくていいじゃんと思いますが、現実にはそういう契約書も少なくない頻度で存在しています。

もちろん探したいものは「約款」と書いてある定型約款に限られません（「規約」「規定」などと題されているものの多くは定型約款ですよね）が、上記の例からわかるとおり、単に「約款」という文字列をヒントにしただけでは区別は困難です。これは自然言語処理の文脈で言えばentity linkingというタスクに近く、例えば「ワシントン」という語は地名（ワシントン州、ワシントンD.C.）、人名（ジョージ・ワシントン、デンゼル・ワシントン）、アメリカ政府を指す俗語（米軍をペンタゴンと呼ぶやつの亜種ですね）、条約名など様々に用いられるため、前後の文脈から曖昧さを回避する処理を施すなど、処理上の工夫の余地があります。

アノテーションではこういったものを定義に照らし合わせて一つ一つ順番に見ていく必要があります。具体例と突き合わせた際には定義の方がブレブレであることが途中で判明する場合もあります。機械学習はアノテーションの一貫性が大事なので、そういうときには定義を修正してアノテーションを再度見直します。抽象と具体のreflective equilibriumを頑張っていくわけです。やっていることは実質法解釈です。

３．エラー分析

アノテーションを頑張って作ったデータセットをもとに、機械学習エンジニアに初期的にアルゴリズムを作ってもらいます。いきなりめちゃくちゃいい精度が出ることは稀なので、どういうエラーが生じているのかを具体の契約書ベースで分析していく必要があります。真に検出すべきなのに検出できていないもの（false negative）や、真に検出すべきでないのに検出してしまったもの（false positive）を中心に、なぜ既存のアルゴリズムが間違っているのかを一つ一つ見ていきます。PCR検査で言うと、「本当はコロナなのに陰性と判断されてしまう」のがfalse negative（偽陰性）であり、「本当はコロナでないのに陽性と診断されてしまう」のがfalse positive（偽陽性）です。

チューニングの方法は非常に多様であり、弊社のノウハウの話になってくるので詳しいことは言えませんが、機械学習のふるまいに対する理解と法律家としての発想力や想像力が勝負になってくる感じです。

エラー分析の過程では、パラリーガルはもともとExcelに出力してもらった解析結果くらいしか見ていませんでしたが、最近は正規表現で書かれたルールベースを直で読んだり、Jupyter Notebook上の処理をエンジニアと一緒に見たり、pandasで検索処理をしたり、アノテーション時に顧客用UIでできること以上のことをする場合には自分でSwagger UI上でAPIを叩いたりなど活動が多岐にわたっており、以前よりリーガルエンジニア感が増しています。が、すべてのツールについて基本的な使い方は弊社ドキュメントにマニュアル化されているので、最低限のITリテラシーがあれば全員キャッチアップできる体制が整っています。

４．フィードバック

既にリリースしているDD支援プロダクト、および現在実証実験中のプロダクトのいずれにおいても、実際の利用者（法律事務所および企業法務部）に最も近いのは弁護士と我々パラリーガルですので、どういう機能が欲しいか、どういうことができると嬉しいか、想像力を膨らませて、顧客の気持ちになることが求められています。特に実証実験中のプロダクトについては超高速でフィードバックサイクルを回しているので、昨日欲しいな～と言った機能が今日追加されているという状況です。

５．おわりに

他にも採用とか組織課題の解決とか全社的に取り組んでいるものもありますが、以上がだいたい今やっていることの中心です。法律×ITだから法律要素は薄まるのかと思いきや、法律家・研究者が長年積み上げてきた法解釈や実務的ノウハウを機械的処理に落とし込む作業は今まで以上に考えることが多いです。法律的に物事を考える力と課題発見・解決能力の両方をバランスよくアウトプットしていく仕事は、以前も書きましたがクッソ楽しいです。しかもITにも強くなれるのでかなりお得感があります。ぜひキャリアの参考にしていただければ幸いです。よければ弊社で一緒に働いてほしいなと思っています。

本稿はMNTSQ株式会社の勤務時間中に書かれました。

ところで、受験票来ちゃったんですが、予備試験マジでやるんですか？