こんにちは、すべての合意をフェアにしたい、MNTSQ（モンテスキュー）の板谷です。

私は「契約×NLP」をテーマとしたSaaS企業のCEOをしています。この投稿は、「”検索” や “推薦” の技術が、社会をフェアにする力になる」ことをお伝えする連続投稿の後編です。

（Part I）なぜ ”検索” と “推薦” で社会がフェアになるのか
（Part II）契約に関する検索の面白さ ←今回

今回は、ひたすら契約というドメインにおける検索の面白さ / 難しさを語っていきます。

契約データの共通性のなかにも顧客ごとの独自性が存在する

契約というデータが、本質的にNLPと非常に相性がよいというのは Part I で触れたとおりです。

他方で、契約データ特有の難しさもあります。その一つは、契約はあらゆるビジネスで締結されることがあるがゆえに、ビジネスごと・顧客ごとに独自性も存在するということです。そのため、MNTSQのSaaS企業としてのアイデンティティを前提としながらも、どこまで個別の最適化を行うかを判断する必要があります。

例①：機械学習によるラベルとカスタムラベル

MNTSQ内には私を含めて契約のDomain Expertが多数在籍しており、例えばアノテーションルールを構築する際にも、できる限り契約一般に適用可能な汎用性の高いものとなるよう努めています。そのアノテーションルールを用いて分類された契約書をもとに機械学習で行っていますが、顧客によってはこの分類に違和感を覚えるケースがあります。

上記の問題に対応するために、検索処理側で機械学習で抽出されたデータを元にして、顧客に馴染みのある契約書名で検索できるようにするなど、MNTSQが考えるスタンダードを機械学習の分類として提供しつつ、顧客ごとの事情に合わせて柔軟に検索ができるような機能も併せて用意しています。

例②：契約一般でのシノニムと、業界ごとのシノニム

MNTSQでは、契約一般にあてはまる単語のルール・パターン性に着目したシノニムの辞書を独自に構築し、ユーザーが探したいデータに実質的に辿り着けるようサポートしています（例：「MOU」と検索すると「基本合意書」がヒットする）

他方で、そのような一般的な処理では回収できない業界ごと / ユーザーごとのシノニムというものも存在します。メーカーであればR&D関連や知的財産関連の契約が多く、自ずと技術的な専門用語が多くなります。一方で、不動産業界では土地・建物の賃貸借契約や売買契約などが多くなります。このような顧客ごとの事情に対処するために共通の辞書を整備しつつ、ユーザー個別にある程度の範囲で辞書設定を可能にしています。

例えば単にPMとあったときに、システム開発の流れならProject Manager、不動産業界ではProperty Management、通信業界ではPhase Modulationなど、業界や部署によって異なっている省略形があります。MNTSQの検索機能ではこの部分をユーザー環境ごとに設定できるようにしてあるため、PMと単に検索してもそれぞれの業界に応じた用語として検索することが可能です。

ペルソナが異なるユーザーを同時に対象とする

契約は、企業のなかで法務部だけが扱うものではなく、むしろ取引を進めたい事業部が主役として扱うものです。MNTSQのユーザーも、例えば1社で8万人が利用する場合がありますが、その99%以上が非法務部門です（今後は日本語ネイティブですらない場合も増えていきます）。

すると、扱っているデータは契約という専門性が高いものである一方で、扱っているユーザーはその専門性が高いとは限りません。法務部／非法務部という異なるペルソナに対してそれぞれ適切な結果を返す必要があります。これらのペルソナは、大企業ならではの複雑な権限設定によって区分されていますが、逆にいえばそれらの権限グループのなかでパーソナライズされた検索体験を設計することが可能たり得ます（現時点ではまだ機能として未成熟であり、今後のチャレンジの一つです。）。

さらに、MNTSQでは部署単位だけでなく個人単位でもUGC(User Generated Contents)をドキュメントに紐付けて登録できるため、それらが存在するものとしないものでランキングをどう構築していくかが重要な検討事項になります。この点もまだ粗い機能ではありますが、契約データに特化した検索という体験自体が新しいものなので、ユーザーにWOWを届けられる可能性があると考えています。

なお、法務部が検索する場合には、キーワードのなかに専門用語が使われるケースが存在します。このようなケースの割合が多いわけではないのですが、法務的な専門用語が使われた場合の検索体験は社内のDomain Expertの定性的な意見を元に実装に落とし込みつつ、他の法務用語の検索体験を壊さないようにするという配慮が求められます。

定常的にデータが入り続ける環境

契約はビジネスのたびに締結されるものですので、MNTSQには絶えず新たな契約データや契約のドラフティング途中のデータがアップロードされ続けます。例えば、あるユーザーの過去3ヶ月での契約データの流入量は以下のとおりです。

かつ、登録されたデータは、NLPによる解析完了次第で検索の対象とされる必要があります。ビジネスが日々変化するなかで、新しいデータにはそれまでのナレッジの蓄積が行われている可能性が高いため、ユーザーに対して推薦する価値が相対的に高いものであるという仮定を置くことができます。

すると、indexingはできる限り高速に実行しつつも検索速度を維持する工夫が必要となります。一般的に検索速度にフォーカスする場合、indexingは夜間バッチで行ったり、数時間に一回などの頻度で行うケースが多いと思いますが、MNTSQの検索処理ではできる限りのリアルタイム性を保とうとしています。

また、対応する業務によっては、RDBと検索エンジンでの処理を組み合わせることにより、より情報のリアルタイム性を高めるように努めています。
例えば、契約内容のレビューなどの複数人で同時に作業する可能性のあるタスクリスト的な要素のある業務では、作業完了から検索に反映させるまでのリアルタイム性が強く求められるため、一部の処理をRDBで実施することでユーザーの検索体験の向上を実現しています。

終わりに

本投稿では、契約に関する検索の面白さについてお伝えいたしました。このような課題の先に、あらゆるビジネスで年間1.5億件が締結され、日本全体で2.8億時間が浪費されている契約というドメインが待ちわびているイノベーションがあります。

最後に、MNTSQの検索に触れたユーザーの声をいくつかシェアさせてください。こうした声は、Sales / CSチームからリアルタイムで共有される体制になっています。

この分野は、まだまだ進化の可能性に溢れており、MNTSQも発展途上です。そんなドメインに深く潜り込みつつ、検索技術で社会全体を一歩前進させたい、そんなエンジニアの皆さんを心からお待ちしています……！

さて、MNTSQアドベントカレンダー2022は本記事をもって終了となります。
18日間にわたりお付き合いをいただき、ありがとうございました。
今後も情報発信により力を入れていきたいと思っておりますので、ぜひご期待ください！