はじめに MNTSQ 株式会社 アルゴリズムエンジニアの内海です。 弊社では最近、MNTSQ契約レビューという機能をリリースしました。 私自身は今年の5月に入社したばかりなのですが、AIエージェントが人間に代わって契約書の条文を読んでリスクをチェックし修正までしてくれる、便利な時代になったものだなと感心するばかりです。 さて、そんな便利な機能ですが当然素のLLMだけで実現できるわけではなく、裏では契約書を解析してどのようなチェックを行うべきかを判断したり、過去の案件や文書で関連しているものを検索して参照したりしています。 そのため、関連情報を見つける検索の性能は契約レビューの性能にも関わってくる大事な要素になります。 まだまだ取り組み始めたばかりの段階ですが、この記事では法務担当者が担当業務を達成するためにどのような情報を必要とするのか、それを検索で実現するにはどうしたら良いかを考えたいと思います。 契約レビューで必要となる情報とは何か 契約は、自社と相手方が、取引を通じてそれぞれの目的を達成するために締結するものです。そのため契約レビューでは、条文単体の文言を見るだけでは不十分です。 同じ条文でも、交渉の経緯や社内規定、取引の背景、当事者の立場、その時点の状況などによって、判断すべきリスクは変わります。こうした事情と条文の内容が組み合わさったときにリスクが顕在化し、それを最小限に抑えるための修正が必要になります。 つまり、検索の目的は、法務担当者がリスクを判断するために必要な情報を、さまざまな状況や事情も含めて過不足なく集めることだといえます。 では、これらの情報を得るためにはどのような検索が必要でしょうか。 キーワードによる文書検索からナレッジグラフを用いたRAGへ ある契約書の条文のレビューを行う際、必要となる情報は具体的な過去の契約書全文でしょうか。勿論類似する案件の修正内容は重要な参考資料ですが、一つの条文をレビューするために契約書全体を読むのは過剰です。また、修正内容そのものも重要ですが、その判断の背景にある交渉内容や社内規定、その時の状況や事情も重要な情報です。 MNTSQ契約レビューはLLMが検索先と検索キーワードを考えて、ヒットした文書を取得します。取得した文書をすべてLLMのコンテキストに含めると入力が非常に長くなるため、参照できる文書数は少数に限られます。 また、検索結果はLLMが生成する検索キーワードにも左右されます。たとえば「秘密保持」や「損害賠償」のような一般的な語では、それらを含む大量の契約書がヒットし、本当に関連する文書を絞り込むことが難しくなります。 このように、検索キーワードを使って文書単位で関連情報を取得する方法には、次の2つの課題があります。 レビューに必要な粒度でコンテキストを得られない 多様かつ包括的な情報が得られない そこで、現在取り組んでいるのがナレッジグラフに基づく検索・回答生成です。 まず、契約書の条文、案件のコメント、プレイブックのチェック項目など、各種のデータソースをチャンク（意味的なまとまり）単位に分割します。次に、それぞれのチャンクからエンティティ（人物、組織・会社など、特定の物事や概念）と、エンティティ間の関係を抽出します。たとえば、MNTSQが当事者となる秘密保持契約であれば、「MNTSQ」と「秘密保持契約」という2つのエンティティの間に、「甲」「締結当事者」といった関係が抽出されます。こうして抽出したエンティティをノード、関係をエッジとして表したものがナレッジグラフです。 グラフのノードとエッジには、エンティティ名や関係だけでなく、LLMがチャンクから生成した説明と、根拠となるチャンクの情報も持たせます。同じエンティティが複数のチャンクに現れる場合は、それらの情報を統合してノードの説明を作ります。同じエンティティ間の関係が複数のチャンクから抽出された場合も、重複を排除しながら情報を統合します。 現在試作しているナレッジグラフの全体像は、次のとおりです。 具体的なキーワードと、状況や事情を表す複数の観点を組み合わせて検索する ナレッジグラフを構築するだけでは、検索の課題は解決しません。法務担当者からの質問は、必ずしも条文の言い回しをそのまま含んでいるとは限らないからです。具体的なキーワードだけで検索すると同じ語を含む大量の情報がヒットし、反対に条文の表現へ寄せすぎると、言い回しの異なる情報を見落としてしまいます。 そこで、チャンクから抽出した関係には、条文に現れる具体的な表現だけでなく、リスク判断に必要な状況や事情を言い表すラベルも付与します。ここでいうラベルは単語ではなく、取引の背景、当事者の立場、義務・責任の内容、リスクの型といった複数の観点を組み合わせた、一文程度の短い説明です。一つの抽象的な言い回しに集約するのではなく、観点ごとに複数のラベルを持たせます。これらを関係の説明とともに関係索引へ埋め込むことで、質問と条文の表現が一致しなくても、質問の意味に近く、その状況や事情に合う関係を検索できるようにします。 検索時には、一つの質問から2種類の検索語を生成します。図2で「低レベルキーワード」と呼んでいるのは、契約種別や条文に現れる語など、具体的なエンティティを探すための単語レベルの検索語です。一方、「高レベルキーワード」は名前に反して単語ではありません。質問に含まれる背景や当事者の立場、確認したい義務・責任などに対応する関係を、複数の観点から探すための短い説明文です。前者でエンティティ索引を、後者で関係索引を検索します。 たとえば、「MNTSQが甲（開示者）となる秘密保持契約で注意すべき論点は？」という質問では、「秘密保持」「開示範囲」といった具体語でエンティティ索引を検索します。同時に、関係索引では「秘密保持契約における当事者の義務」という高レベルキーワードを使います。この高レベルキーワードは、単に具体的な文言を抽象語へ置き換えたものではなく、「秘密保持契約」という契約の種類と、「当事者の義務」という確認の軸を組み合わせ、質問の状況に関係するエッジを探すための検索語となっています。「MNTSQ」「甲（開示者）」といった具体的な当事者や立場の情報は、エンティティ側の検索結果や、そこにつながる関係と組み合わせて補います。 両方の索引でヒットしたノードやエッジについて、つながっている情報（1-hop近傍）を集約し、元のチャンクから根拠となる原文を取得します。そのうえで、LLMが根拠付きの回答を生成します。具体的なキーワードだけに依存せず、複数の観点を持つ関係の意味からも検索することで、表現の異なる条文や、質問に明示されていない関連情報を拾いやすくなります。 整理すると、先に挙げた2つの課題に対して、次のような解決を試みています。 レビューに必要な粒度でコンテキストを得られない → 文書全体ではなく、ヒットした関係やエンティティに直接紐づくチャンクだけを回答のコンテキストに渡す 多様かつ包括的な情報が得られない → 具体的なキーワードによるエンティティ検索と、状況や事情を表す複数の観点を用いた関係検索を組み合わせる 自然言語処理に明るい方はもう既にお気付きかもしれませんが、これは LightRAG [Guo+, EMNLP2025] という手法で、それを法務業務で必要とする検索に合わせて調整しています。 PoCで実際に効果を検証してみる 仕組みの説明だけでは効果が分からないため、開発環境にある開発用データを使って、一連の処理を動かしてみました。なお、使用したのは本番データではなく、あくまで検証用のデータです。投入したデータと、構築されたグラフのサイズは次のとおりです。 データ種別 データ源 投入件数 案件管理 mntsq matters 8件 契約管理 mntsq documents / clauses （条=level1） 42件 ナレッジ mntsq-knowledge playbook_items 15件 コメント mntsq matter_timeline_comments 1件 ノード数 エッジ数 355 615 埋め込みにはGemini Embedding（768次元）を使っています。 契約書からチャンクを作る際に、条=level1 単位としていることに対して、法務担当者の方は、「定義条項で定義された語や『前条の規定を準用する』といった条をまたぐ参照が切れるけどどうするんだろう？」と感じるかもしれません。 しかし、ナレッジグラフではエンティティはグラフ上で1つのノードに統合されます。 定義条項で定義したエンティティと条項間で関係が抽出されるため、グラフとしてエンティティが統合されていく過程で定義条項のチャンクの情報はエンティティの説明に含まれることになります。 その上で他のエンティティとの関係にも説明が付与されるため、条でチャンクを作ったために条を跨いだ参照が途切れてしまうという心配はありません。 ナレッジグラフを用いた検索の効果を見るために、以下の3つの質問を使って、現行の検索と比較しました。 MNTSQ契約レビューは MNTSQ AI Agent の機能で、関連文書の検索は MNTSQ AI Agent がツールとして呼び出しています。今回は、この検索部分をナレッジグラフに置き換えた場合の効果を検証しています。 3つの質問 「委託先や外部の協力者に社内情報を渡す場面で、委託先に、その再委託先や従業者の行為まで責任を負わせ、報告・監査で情報の取扱いを確認できるようにするには、過去の契約ではどのような設計がされていたか比較して」 「Playbook株式会社が委託者として関与する契約について、相手方ごとの委託者・受託者の役割と支払関係を比較して」 「MNTSQが甲（開示者）となる秘密保持契約で注意すべき論点は？」 また、今回の実験では検索結果の上位20チャンクを取得して回答しています。 結果から、それぞれ異なる種類の差が見えてきました。 比較結果 コンテキストの量の差 MNTSQ AI Agent ナレッジグラフ検索 質問1 15,749文字 8,144文字 質問2 6,587文字 7,205文字 質問3 10,089文字 6,509文字 質問1、質問3ではLLMへ与えるコンテキストの量が減らせていることが分かります。 質問1では検索結果の網羅性はどちらも同程度でした。これは質問に適切な観点を表す「報告・監査」というキーワードが存在しているため、MNTSQ AI Agent では LLM が適切な検索キーワードを用いて検索ができているためです。 取得できた文書・案件の件数 MNTSQ AI Agent ナレッジグラフ検索 質問1 4文書 7件（契約テンプレート5種+2案件） 質問2 1案件 3案件 質問3 4文書 13件（テンプレート3種+案件10件） ※ ナレッジグラフ検索はこの表の件数をすべて使って回答するわけではなく、この中から必要なチャンクを選んで根拠付きで回答を生成します。 質問2で特に大きな差が出ました。MNTSQ AI Agentは、案件を横断して検索する仕組み自体は備えているものの、実際に生成された検索キーワードでは1つの案件しか見つけられませんでした。一方、ナレッジグラフ検索では同じ質問から3件の候補を発見し、その中から回答に必要な2つの案件（残り1件は質問とは無関係）を正しく選んで、相手方ごとの役割と支払関係を比較する回答を生成できていました。これは、LLMが生成した検索キーワードが実際の文書の表記と一致しない場合に、関連する案件そのものを丸ごと見落としてしまう、キーワード検索特有の弱点を示す結果です。 質問3の論点網羅性 質問3（「MNTSQが甲（開示者）となる秘密保持契約で注意すべき論点は？」）は、案件を横断する質問ではなく、単一のテーマについて論点を網羅できるかを見るための質問です。取得したコンテキスト量は表1に示した通り（MNTSQ AI Agent: 10,089文字／ナレッジグラフ: 6,509文字）ですが、ここでは論点の網羅性を比較します。 MNTSQ AI Agent ナレッジグラフ検索 挙げられた論点の数 5/6 6/6 MNTSQ AI Agentは文書4件を取得し、ナレッジグラフ検索が挙げた6つの論点（秘密情報の定義・除外事由、目的外利用の禁止、第三者開示の制限、善管注意義務・調査権、漏洩時対応・損害賠償、終了時の返還・破棄）のうち5点をカバーし、1点（漏洩時の通知義務）は明示されていませんでした。ナレッジグラフの回答は、実際の過去案件5件の具体的な条項（案件番号・条項番号付き）を根拠に、6つの論点すべてをカバーしています。 まとめ 3つの質問の結果を整理すると、次のようになります。 質問 差の種類 結果 委託先・再委託先・従業者への責任と報告・監査の設計比較 コンテキストの量 回答の網羅性は同程度。入力コンテキストはナレッジグラフが約52%（15,749文字 → 8,144文字） Playbook株式会社が関与する契約の相手方ごとの比較（案件横断） 検索の再現率・正確性 MNTSQ AI Agentは案件を見落とし「比較対象は存在しない」と誤答。ナレッジグラフは2案件を正しく発見 MNTSQが甲となる秘密保持契約の論点（単一案件・網羅性） コンテキストの量・網羅性 ナレッジグラフでは論点を網羅。入力コンテキストはナレッジグラフが約65%（10,089文字 → 6,509文字） 今後の展望 今回の検証は、開発環境のシードデータを使った小規模な実証実験に過ぎません。データ量が少ないため、たまたまうまく検索できた可能性も否定できません。 今後は、より多くの案件・契約書・プレイブックを投入し、質問のパターンも増やして効果を検証するとともに、プロダクトへ導入するための権限管理や、ノードやエッジに持たせるプロパティに時間軸を追加して、期限切れの情報のフィルタリングや法令改正の前に関係する契約の棚卸しに繋げられるようにするなど、より実務を意識した検証を行っていく予定です。 あわせて、MNTSQ AI Agentなどの既存のAIエージェントからナレッジグラフを実際に呼び出すための接続も進め、契約レビューの現場で使える形に近づけていきたいと考えています。 注記：この記事の図は Claude を用いて作成しています。また、文章の添削には ChatGPT も使用しました。 謝辞：この記事を書くにあたり、法務担当者が必要とする検索や論点とは何かについて、テックリードの平田氏、PdMの松葉氏に資料の共有や法務領域の知識に基づいたアドバイスを頂きました。ドメイン知識が不足していることもあり大変感謝しております。

はじめまして！しまと申します。 新卒1年目で毎日学ぶことがたくさんあって大変ですが、甘いもので糖分補給しながら頑張っています！ この度、AI-901を受験して無事に合格できたので記録を残そう！！ ということで作成してみました！ 今後受験予定の方や、資格対策に困っている方の参考になれたら幸いです🍀

こんにちは。クラウドエース株式会社で Google Cloud 認定トレーナーをしている廣瀬 隆博です。 最近はメタルライブの開催が多く、「あのバンドが来日？！」みたいなニュースを度々見かけるのですが、家庭持ちということもあってほとんど観に行けず、悔しい思いをしています。 嬉しい悲鳴というやつでしょうか。界隈が盛り上がっていることは間違いなく良いことなので、いずれ子どもが手を離れるまで、この勢いが続けばいいなーと祈る日々ですね。 そんな折、久々に Professional Cloud Architect を更新するタイミングがあったのですが、最近のリニューアルで AI 関連の設問が増えて