こんにちは。GitHub Copilotを先日初めて触って、感銘を受けたMNTSQ代表の板谷です。MNTSQの代表をしておりますが、現役の弁護士でもあります。
なぜ私が、GitHub Copilotに感銘を受けたかというと、「プログラミングの LLM による進化」は、契約という言語をコーディングするためにもドンピシャで使えそうだと感じたからです。
例えば、GitHub Copilot では、自分の過去のコードを参照して、最適なコードをサジェストしてくれます。
これは、契約に関わるすべてのビジネスパーソンが求めていたものです！契約の 99.9%が過去のコードの使い回しであるにもかかわらず、毎回ゼロからコーディングするのが本当に苦痛だからです。ちなみに、前回契約と理由なく diff があると取引先に怒られます。笑
しかし、GitHub Copilot 的なものがプログラミング言語だけでなく契約言語でも求められるのは、よく考えると当然です。以前にも記事にしたのですが、プログラミング言語と契約言語はとても似ているためです。
どちらも「一定のインプットを入れると、必ず一定のアウトプットが返ってくるように設計された独自の言語体系」だからです。 契約言語とは「一定の紛争⇒一定の判決が出るように構造化されたコード」です。処理するのがコンピューターではなく裁判官であるというのが違いでしょう。
もし「リーダブルコード」を弁護士が読んだら？ - MNTSQ Techブログ
もし、契約言語の世界に GitHub Copilot が産まれたら、すべてのビジネスが圧倒的に加速し、無駄に難解な契約というものが変革されるのではないでしょうか…？
この記事では、このすべてのビジネスパーソンの夢を追及してみます。
プログラミングと LLM
コード / コードコメント / コミットメッセージ
ソフトウェア開発においては、まずコードを書き、コードの変更箇所の説明のためコミットメッセージやプルリクエストの説明を書きますよね。
GitHub Copilot は、自然言語での指示によって、これらの作成を助けてくれます！1
これらのアウトプットの流れは、契約業務でも実はまったく変わりません！
・まず契約本文（＝コード）を書き、
・次にその意図が伝わるようにMicrosoft Word にコメント（＝コミットメッセージ）をして、
・差分の発生理由をメールに記載して関係者に通知するのが（＝プルリクエストの説明）、契約業務の流れです。
すべて、心をこめて手作りしています。もしも、これらの契約業務のアウトプットを GitHub Copilot のように助けてくれるなら、本当に夢のようです。確信があります、私なら泣きます。
Copilot？いやまずは VS Code だ
GitHub Copilot の素晴らしいところは、LLM によるサジェストが、例えば VS Code などエディタのなかで完結するところです。コミットメッセージは、GitHub に一元的に記録されます。
ここで契約に関わるビジネスパーソンは、そもそものプログラミング環境の違いに絶望します……
VS Code？？…それって、Word のこと？ GitHub？？…それって、メールのこと？
そう、GitHub Copilot 以前に、そもそも契約にはプログラマーを思った開発環境がないのです。Word とメールと紙だけで、歯を食いしばって生きてきました。
しかし、この 1 年に私たち MNTSQ が解決してきた課題はまさにそこでした。いかに Word を契約のプログラマーにとって開発しやすい環境にできるか、GitHub のようなチームでの開発基盤を提供できるかが、ちょうど今クリアされたところです！
RAG の設計
なぜ RAG なのか？
GitHub Copilot が手に馴染む理由は、利用者の過去のコードを参照して、コードの記述の仕方を合わせてくれるところです。
その裏側にあるのは RAG という構造に近く、現在作業中の内容を踏まえて、過去のデータのうち参考になるものを特定し、それを変形して適用する（generation）という流れを辿っています。
契約に LLM を活用するため、RAG は非常に重要です！なぜなら、会社ごとに法務戦略は異なっているためです。
法務戦略は、それ自体が言語化されることは少なく、過去の類似シチュエーションにおける交渉データとしてのみ表現されています。これを踏まえて新たな契約を生成できれば、契約の世界では本当に革命が起こせるはずです。
そもそも DB がない…！
しかし、契約業界ではまたもここで、そもそも論にぶつかります……
「過去データの DB？そんなものなくね？」
契約データは、オンプレのファイルサーバーに格納されていればまだマシで、メールの添付ファイルとして探せば残っているかも…という状況です。
実は、これこそ MNTSQ が創業以来解決してきた問題です。MNTSQ の登場以前には、一流企業ですら「自分たちがどのような契約を締結しているかわからない」という状況でした。
しかし、私たちが契約をデータベース化して、NLP によって自動的にタグ付け・整理をすることで、契約というデータはようやく活用可能な状態になりました。
「データベースを提供している＝ RAG で使えるベストな参考情報を持っている」ということです。ここをレバレッジして、最高品質の契約を誰もが作れるようにしていきたい。
推薦 AI
DB があれば、そのうち参考になるデータを特定できるか（retrieval）が次のポイントです。
これこそ、ドメイン特化 NLP の腕の見せ所です！ユーザーの意図に沿った過去データを特定できるように、ドメイン特化のメタデータを自動付与し、絞り込みをかけていきます。
その選りすぐりされたデータを、いかに Word を VS Code 化し、最高の UX でサジェストするかをデザインしていきます。まさに契約のプログラミング基盤を作っているようなワクワク感があります。
ベストプラクティスの提供
なお、皆さま日本最高の法律事務所をご存じでしょうか？その一つが「長島・大野・常松法律事務所」という、形態素解析が難しすぎる事務所です。
MNTSQ では、この長島・大野・常松法律事務所のトップ弁護士によるコード（＝契約文言）を、ベストプラクティスとしてコンテンツ化し、オープンに提供しています。
このベストプラクティスであるコードも RAG においてサジェストし、ユーザーの契約に自然と取り込ませていくことによって、社会全体からアンフェアな契約を駆逐していきたいと考えています。
終わりに
プログラミング言語と比べると技術的進歩の余地がある契約言語ですが、これからアルゴリズムによって変革されるスピードはプログラミング言語よりも圧倒的に速いはずだと考えています。まもなく契約は、アルゴリズムが書き、交渉するものになるでしょう。
なぜなら、契約言語はプログラミングより圧倒的にパターン性が高いためです。実は、100-200 くらいのライブラリ（＝契約条項）を組み合わせるだけで、90%以上のビジネスシーンを網羅できるのではないかと思います。
これが実現したときの社会的意義も大きいです。契約が不要であるビジネスはありません。また「契約言語は、全国民が完全理解できることがなぜか前提になっている」なかで、アンフェアな契約に騙されてしまう人を減らせるかもしれません。
「契約をつくるアルゴリズム」が誕生するとすれば、これまで最前線の弁護士が書いてきたような最高品質のものにしたいと私は考えています。そのための、長島・大野・常松法律事務所というトップ事務所との提携です！
誰もが一瞬で、フェアな合意ができるようなプラットフォームを作れれば、職業人として一つ社会貢献ができるかな…という想いです。今まさに社会が大きく変化しようとしているところですので、もし興味を持ったエンジニアの皆さまがいれば、是非私とカジュアル面談をさせてください！
