LASSIC Media らしくメディア
契約審査システムの選び方|リーガルチェック自動化
LASSIC IT事業部|元請(プライムベンダー)として業務システムの開発・保守を受託
この記事のポイント
- 契約審査・リーガルチェック支援システムは、締結後を管理するCLMとは異なり、締結前の契約書レビューを支援する仕組みです。
- 法務省は2023年8月、AIを用いた契約書等関連業務支援サービスと弁護士法第72条の関係を整理した文書を公表しています。
- パッケージ(リーガルテックSaaS)かスクラッチかは、自社ひな形の活用度と既存の審査ワークフロー・電子契約連携で判断材料が分かれます。
目次
契約審査・リーガルチェック支援システムとは、締結前のレビューを支える仕組み
契約審査・リーガルチェック支援システムとは、事業部門から回ってきた契約書ドラフトを法務が締結前にレビューする一連の作業を支援する仕組みを指します。自社ひな形や条項ライブラリとの差分表示、リスクになり得る条項の指摘、審査依頼から法務レビュー、承認までの進捗管理までを一つの流れとして扱う点が特徴です。
ここで押さえておきたいのが、締結後を扱うCLM(契約ライフサイクル管理。締結済み契約の保管・更新期限や自動更新の管理・検索を担う仕組み)との違いです。CLMは締結された契約をどう管理するかに主眼を置きます。一方、契約審査・リーガルチェック支援システムが軸足を置くのは、締結前のレビューとリスク指摘です。時間軸が締結の前か後かで、扱う課題は大きく変わります。
もっとも両者は連続した業務です。締結前の審査を終えた契約が、そのまま電子契約やCLMに引き継がれる設計であれば、審査から締結、保管までが一つの流れになります。本稿では締結前の審査支援を中心に、機能とシステム化の判断軸を整理します。
なぜ仕組み化が求められるのか——法務の属人化と審査の滞留
契約審査の現場では、依頼がメールや口頭で個別に届き、進捗が担当者の手元にしか見えないという状況が起こりがちです。どの案件が誰の手元で止まっているのか、過去に似た契約をどう判断したのかが共有されにくく、業務が特定の担当者に依存します。この属人化は、担当者の不在時に審査が滞る一因になります。
経済産業省は2019年11月、「国際競争力強化に向けた日本企業の法務機能の在り方研究会報告書」を公表し、法務機能を事業の創造や価値の保全に資する機能として位置づけ、その強化と人材育成の必要性を提言しました*5。契約審査を含む法務業務を仕組みとして整えることは、こうした機能強化の実務的な一歩と位置づけられます。
審査依頼の受付から進捗、判断根拠の記録までをシステムに集約すると、案件の停滞が可視化され、過去の交渉履歴や判断がナレッジとして蓄積されます。誰が対応しても一定の観点でチェックできる状態に近づく点が、仕組み化の狙いといえるでしょう。
弁護士法第72条との関係——2023年8月の法務省文書が示した整理
契約審査にAIを使う際にまず確認したいのが、弁護士法第72条との関係です。同条は、弁護士または弁護士法人でない者が、報酬を得る目的で、訴訟事件や一般の法律事件に関して鑑定その他の法律事務を取り扱うことを禁じています。いわゆる非弁行為の禁止です。
この点について法務省大臣官房司法法制部は2023年(令和5年)8月、「AI等を用いた契約書等関連業務支援サービスの提供と弁護士法第72条との関係について」と題する文書を公表しました*1。契約書の作成・審査・管理業務を一部自動化して支援するサービスを対象に、予測可能性を高める観点から考え方を整理したものです*2。
文書では、第72条に該当し得るかを判断する要素として、報酬を得る目的があること、対象が争いや疑義を含む「法律事件」に当たること、そして鑑定その他の「法律事務」を取り扱うことが挙げられています*1*3。そのうえで、通常の業務に伴う契約の締結に向けた話合いや法的問題点の検討については、多くの場合「事件性」がないとされ、これらは同条が想定する場面から外れる方向で整理されました*1*4。
ここで大切なのは、AIによる指摘はあくまで審査の支援であり、法的な最終判断を代替するものではないという理解です。システムが差分や着目すべき観点を提示しても、その契約を締結してよいかを決めるのは法務担当者や弁護士です*4。AIが法的結論を出してくれると受け止めてしまうと、判断の責任が曖昧になりかねません。導入時には、機能があくまで補助にとどまる設計かどうかを確認しておくとよいでしょう。なお、個別の適法性は自社の利用形態によって変わるため、判断に迷う場合は弁護士や専門家に相談することが望ましいといえます。
契約審査システムの主な機能——条項ライブラリ・差分・ワークフロー・ナレッジ
ひな形・条項ライブラリとの差分表示とリスク条項の指摘
中心となるのが、提出された契約書ドラフトを自社のひな形や条項ライブラリと突き合わせ、差分を示す機能です。自社に不利になり得る条項や、通常入れているはずの条項が抜けている箇所を洗い出し、担当者が確認すべき観点として提示します。AIによる条項抽出やチェック観点の提示を備えるものもあり、レビューの見落としを減らす助けになります。
審査依頼から承認までのワークフローと案件管理
事業部門からの審査依頼を受け付け、法務レビューを経て承認へ至る流れを、決められたワークフローとして扱います。案件ごとに進捗や担当者、期限が一覧で見えるため、どこで止まっているかを把握しやすくなります。依頼の受付窓口を一本化することは、属人化の解消にもつながるでしょう。
過去契約・交渉履歴のナレッジ化
審査した契約や、その過程での修正・交渉のやり取りを記録として残す機能です。似た論点が再び出てきたときに過去の判断を参照でき、担当者が変わっても対応の一貫性を保ちやすくなります。蓄積された履歴は、社内の判断基準を育てる資産になります。
電子契約・CLMとの連携
審査を終えた契約は、電子契約サービスで締結され、締結後はCLMで保管・管理されるのが一般的な流れです。審査支援システムがこれらと連携できれば、審査から締結、保管までのデータが分断されずにつながります。連携の可否は、後述するシステム選定でも重要な確認点になります。
パッケージ(リーガルテックSaaS)かスクラッチか——判断の分かれ目
契約審査の仕組みを整えるとき、既製のリーガルテックSaaS(クラウドで提供される契約審査支援サービス)を導入するか、自社向けにスクラッチ開発するかで悩む場面があります。判断の分かれ目は、いくつかの軸で整理できます。
第一に、自社ひな形や自社固有の審査観点をどこまで反映したいかです。汎用的なチェックで足りるなら、導入が早く運用の手間も抑えやすいパッケージが有力な選択肢になります。一方、業界固有の条項や自社ならではの判断基準を深く作り込みたい場合は、スクラッチや個別カスタマイズの余地が広がります。
第二に、既存の業務システムやワークフローとの結び付きです。社内の稟議・決裁システムや文書管理、電子契約との連携を密にしたい場合、既存環境に合わせやすいかどうかが判断材料になります。第三に、初期費用と運用コスト、そして自社で保守できる体制があるかという観点でしょう。スクラッチは自由度が高い反面、開発と保守の負担が継続します。
多くの企業では、まずパッケージで運用を始め、足りない連携やカスタマイズだけを個別開発で補うという組み合わせが現実的です。すべてを一から作るのではなく、どこを既製品に任せ、どこを作り込むかを見極めることが要点になります。
外注先に確認したいこと——ひな形の学習・審査ワークフロー・CLM連携
個別開発やカスタマイズを外部に委託する場合、確認しておきたい点があります。まず、自社のひな形や条項ライブラリをどのように取り込み、差分チェックに反映できるかです。自社の判断基準をシステムに載せられなければ、審査支援の精度は上がりません。
次に、審査依頼から承認までのワークフローを、自社の実際の決裁ルートに合わせて設計できるかどうかです。既存の稟議や文書管理と噛み合わない仕組みは、かえって現場の手間を増やします。あわせて、電子契約やCLMとのデータ連携の範囲、将来の拡張余地も確認しておきたい点です。
加えて、前章で触れた弁護士法第72条との関係を踏まえ、システムがあくまで審査を支援する設計になっているか、最終判断は人が担う前提かを、委託先と共有しておくことが大切です*1*4。開発の依頼範囲を、要件定義から機能設計、既存システム連携、公開後の保守まで一括で任せられるかどうかも、元請(プライムベンダー)を選ぶ際の分かれ目になります。
まとめ:契約審査システム導入で押さえる3つの判断軸
本稿では契約審査・リーガルチェック支援システムについて、締結前の審査という観点から機能と導入の判断軸を整理しました。要点は3つに集約できます。第一に、締結後を扱うCLMとは異なり、締結前のレビューとリスク指摘に軸足がある仕組みだという理解です。第二に、AIによる指摘はあくまで支援であり、法的な最終判断は人が担う点で、法務省が2023年8月に公表した文書が弁護士法第72条との関係を整理しています*1。第三に、自社ひな形の活用度や既存ワークフロー・電子契約連携の要件によって、パッケージとスクラッチの判断が分かれます。現状の審査フローを棚卸ししたうえで、どこを既製品に任せ、どこを作り込むかを見極めることが実務的です。
よくある質問
契約審査システムとCLM(契約ライフサイクル管理)はどう違いますか。
契約審査・リーガルチェック支援システムは、締結前の契約書ドラフトのレビューやリスク条項の指摘を支援する仕組みです。一方CLMは、締結済み契約の保管・更新期限の管理・検索など締結後の管理に主眼があります。両者は連続した業務のため、審査から締結、保管まで連携させる構成もよく採られます。
AIによる契約書チェックは弁護士法違反になりませんか。
法務省大臣官房司法法制部は2023年8月、AI等を用いた契約書等関連業務支援サービスと弁護士法第72条の関係について考え方を整理した文書を公表しています。通常の業務に伴う契約の検討は多くの場合「事件性」がないと整理されていますが、個別の適法性は利用形態によって変わる点に注意が必要です。AIの指摘はあくまで支援であり、最終判断は人が担う点を押さえ、判断に迷う場合は弁護士等に相談することが望ましいといえます。
パッケージのリーガルテックSaaSと個別開発、どちらを選ぶべきですか。
汎用的なチェックで足り、早く運用を始めたい場合はパッケージが有力です。自社ひな形や業界固有の条項を深く作り込みたい、既存の決裁システムや電子契約と密に連携したい場合は個別開発の余地が広がります。まずパッケージで始め、足りない連携やカスタマイズだけを個別開発で補う組み合わせも現実的な選択肢です。
自社のひな形や過去の判断はシステムに反映できますか。
多くの契約審査支援システムは、自社ひな形や条項ライブラリと突き合わせて差分を示す機能を備えています。過去の審査や交渉履歴を記録してナレッジとして蓄積する機能もあり、担当者が変わっても判断の一貫性を保ちやすくなるでしょう。反映の範囲や精度は製品や開発内容によって異なるため、導入前に確認することをおすすめします。
審査システムの開発を外部に委託する際、何を確認すればよいですか。
自社ひな形の取り込みと差分チェックへの反映方法、審査依頼から承認までのワークフローを自社の決裁ルートに合わせて設計できるか、電子契約やCLMとの連携範囲をまず確認します。加えて、システムが審査を支援する設計で最終判断は人が担う前提かを委託先と共有しておくことが大切です。要件定義から保守まで一括で任せられるかも選定の分かれ目になります。
著者:テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典:法務省大臣官房司法法制部「AI等を用いた契約書等関連業務支援サービスの提供と弁護士法第72条との関係について」(令和5年8月)(https://www.moj.go.jp/content/001400675.pdf)
- *2 出典:法務省「弁護士法(その他)」(https://www.moj.go.jp/housei/shihouseido/housei10_00134.html)
- *3 出典:One Asia Lawyers Group「AI等を用いた契約書等関連業務支援サービスの提供に関する指針の概要」(https://oneasia.legal/11389)
- *4 出典:JIIMA(日本文書情報マネジメント協会)「AI契約関連業務支援サービスと弁護士法72条について」(https://www.jiima.or.jp/im/im_bn/ai-contract-support-law72/)
- *5 出典:経済産業省「国際競争力強化に向けた日本企業の法務機能の在り方研究会報告書」(2019年11月19日)https://www.meti.go.jp/press/2019/11/20191119002/20191119002.html