プライベートLLMに戻る

法務・契約チーム · 01 / 12

契約業務向けプライベートLLM

すべての契約書を自社サーバー上のAIが読み、自社の標準と違う条項を数分で洗い出します。社外に出る契約書は1通もありません。

ランプの下に付箋とマーカーだらけの契約書。ノートPCは第14.2条の責任上限が標準と違うと指摘し、外部送信は0件 法務・契約チーム
「法務はAIに契約書を読ませたい。でも契約書にはどれも取引先の情報が入っていて、公開ツールに貼れば社内ポリシー違反になる」

よくある課題

契約書1通を読むのに半日かかります。2〜3人の法務チームに、購買、営業、人事から毎週契約書が届き、1通ずつ自社のひな形と並べて条項ごとに確認します。取引先がどこを書き換えたか、別紙に何か紛れ込ませていないか。順番待ちが長くなると、営業から「いつ署名できるのか」と催促が来ます。

公開ツールを使えば楽になりますが、どの契約書にも取引先の名前、価格、秘密の条件が書かれているため、コンプライアンス部門が貼り付けを禁じています。結局チームは目で読む作業に戻り、その日10通目の契約書で、本来気づくべき条項を見落とします。

解決の方法

Llama、Qwen、タイ語ならTyphoonといったオープンな言語モデルを自社サーバーまたは自社のクラウドアカウントに導入し、SharePointやGoogle Driveにある既存の契約書アーカイブとつなぎます。法務担当者はActive Directory経由で会社のアカウントにログインし、契約書をアップロードすると、ひな形と異なる条項の比較表とリスクの要約が数分で届きます。

質問も回答もすべて自社ネットワークの中で完結し、外部APIは呼び出しません。誰がどの契約書を開き、いつ何を質問したかは監査ログに残ります。取引先の個人情報を含む契約書は、自社の法律顧問と私たちで設計したタイの個人情報保護法(PDPA)の方針に沿って保管し、閲覧できる人を絞ります。

システムが受け持つのは指摘と要約で、判断は人が行います。ハイライトされた条項を読み、受け入れるか交渉するかを決めるのは自社の弁護士です。契約書を相手方に戻す前にも、毎回弁護士が承認します。

仕組みの流れ

業務の入口
  • 購買・営業から届く契約書
  • SharePointの過去の契約書
  • 自社の標準ひな形
AIが行うこと
  1. 別紙を含めて契約書全体を読む
  2. 全条項をひな形と照合
  3. 異なる条項の指摘とリスク要約
  4. 全質問を監査ログに記録
結果の届け先
  • 弁護士向けの条項比較表
  • 依頼部署へのリスク要約
  • 契約書アーカイブの検索結果
  • コンプライアンス部門向け監査ログ

導入前と導入後

導入前
導入後
契約書1通を読むのに半日、ひな形との照合も目視
条項比較表とリスク要約が数分でそろい、弁護士は違う条項だけを読む
営業が毎日「まだ順番が来ないのか」と聞きに来る
営業は契約書を送ったその日に一次回答を受け取る
似た条件の過去の契約書は、ファイルを1つずつ開いて探す
1文で質問すれば、該当する契約書の一覧が参照ページ付きで出る

導入で得られるもの

  1. 01

    PDFやWordでアップロードした契約書を読む、自社サーバーまたは自社のクラウドアカウント上の言語モデル

  2. 02

    全条項を自社の標準ひな形と照らし合わせ、違う条項を、どこが違うかの説明付きでハイライト

  3. 03

    支払条件、違約金、契約解除、裁判管轄といった項目別に、平易な言葉でまとめたリスク要約

  4. 04

    「競業避止義務が2年を超える契約は」のような普段の言葉で、過去の契約書全体をページ参照付きで検索

  5. 05

    誰がどの契約書を読み、いつ何を質問したかを記録する、コンプライアンス部門向けの監査ログ

立場ごとのメリット

経営者

人を増やさずに法務の契約審査が速くなります。取引先には、預かった書類は自社のサーバーにしか置いていないと説明できます。

IT責任者

自社サーバーまたは自社のクラウドアカウントに導入し、既存のActive Directoryでログインします。外部APIの呼び出しはなく、すべての質問が監査ログに残ります。

毎日使う現場のチーム

弁護士はひな形と一字一句同じ条項を読み直す必要がなくなり、本当に交渉が必要な条項に時間を使えます。

向いている業種

取引先との契約が多い企業建設会社・工事業者メーカー・卸売業不動産法務部門を本社に集約したグループ企業

お使いのシステムと連携

Microsoft 365SharePointGoogle WorkspaceActive Directory文書管理システムDocuSign

開発プロセス

  1. 1

    ヒアリング

    要件・ユーザー・成功指標を定義し、着手前に範囲と価格を確定。

  2. 2

    設計

    UXとアーキテクチャを設計。プロトタイプ承認後に開発へ。

  3. 3

    開発

    AIで加速したスプリント。毎週デモ、シニアがレビュー。

  4. 4

    テスト

    合意した範囲に対してQA・セキュリティ・性能を検証。

  5. 5

    公開・保守

    本番リリース、チームトレーニング、月次保守プラン。

ビジネス課題を、動くシステムに変える

今日ご相談いただければ、計画と予算をまとめた経営層向けの提案書をご提示します。

この内容をエンジニアに相談