AIで法務の工数を激減させる「契約書レビュー自動化システム」の構築方法を解説

ビジネスにおいて、契約書のレビュー（リーガルチェック）は避けて通れない業務の一つであり、担当者は何十ページにも及ぶ難解な条文を確認しなければなりません。

昨今、リーガルチェックを効率化するため、生成AIの活用が注目されていますが、いざ生成AIを実務のルーチンに組み込んでみると、「運用上の新たな課題」が浮き彫りになってきます。

例えば、生成AIに役割や知識を役学習させても、実際の作業は依然として「人間による手動操作」に依存しています。契約書が届くたびに、担当者はチャット画面を開き、ファイルをアップロードし、解析を待つ必要があります。

この「生成AIを動かすための手間」が案件数に比例して増大し、結局は担当者の時間を奪い続けるという状況が生まれてしまいます。

実際、以前の記事では、GoogleのカスタムAIツール「Gem（Gemini）」を活用し、個人で手軽にリーガルチェックのアシスタントを構築しましたが、同様の課題が見えてきました。

以前の記事はこちら：生成AIで契約書の「リーガルチェック」知らないと損するGoogleのGem活用術

この方法では、難しい設定が不要で、プロンプトで指示するだけで生成AIが契約書のリスクを指摘してくれます。

しかし、実際に実務に導入しようとすると、毎回生成AIにファイルをアップロードして指示を送る手間に加え、生成AIの回答の管理、ハルシネーション（もっともらしい嘘）のリスクがあることが分かりました。

生成AIを「単発のツール」として使う段階から、「組織の安定した業務プロセス」として組み込む段階へ進むには、この「手間」と「不安」を解消しなければなりません。

そこで本記事では、さらなる効率化と契約書の管理も同時に行えるように、AIアプリケーション開発のためのノーコード・ローコードプラットフォーム「Dify」とGoogle Apps Script（GAS）を組み合わせたシステムの構築方法を紹介します。

一般的な契約書チェックの流れと、そこに潜む「3つの壁」

まずは、「現実の業務フロー」と、そこに潜む構造的な課題について見ていきましょう。

多くの企業において、契約書のリーガルチェックは概ね以下のようなステップで進められています。

1.受付・一次読解:取引先から届いた、あるいは自社で起案した契約書を最初から最後まで読み込み、全体像を把握する。
2.社内規定（ガイドライン）との照合:「損害賠償額の上限はあるか」「自動更新の条項は弊社ルールに反していないか」など、自社の基準と一字一句照らし合わせる。
3.リスクの抽出と修正案の作成:リスクがある箇所を特定し、相手方に提示するための修正案（カウンター）を準備する。
4.最終確認と決裁:法務担当者や責任者が最終的な判断を下し、締結のGOサインを出す。

一見するとシンプルな流れですが、この「当たり前」のプロセスの中には、現場を疲弊させる「3つの大きな壁」があります。

①時間と精度の「トレードオフ」

契約書は、読めば読むほど時間がかかります。しかし、ビジネスの現場では「明日までに締結したい」というスピードが求められます。

急いで読めば見落としのリスクが高まり、丁寧に読めば事業のスピードを止めてしまう。このジレンマが、常に担当者の肩に重くのしかかっています。

②判断の「属人化（バラつき）」

チェックする人の経験値やその日の体調によって、「どこまでをリスクと見なすか」の基準が微妙にズレることがあります。

AさんはOKと言ったのに、B部長はNGと言う。こうした判断のバラつきは、社内のコミュニケーションコストを増大させ、組織としての意思決定を不透明にします。

③「見えないもの」を探すストレス

契約書チェックの最も過酷な点は、「書かれていること」だけでなく、「本来書かれているべきなのに、書かれていないこと」を見つけ出さなければならない点です。

反社条項が抜けていないか、必要な免責事項が漏れていないか。この「欠落」を探す作業は、人間の脳にとって極めて負荷の高い、神経をすり減らす作業です。

こうした「人間ならではの限界」を補うために生成AIは非常に有効ですが、だからといって「すべてをAIに任せて自動化すれば解決」とはいかないのが、法務という分野の難しいところです。

次の章では、生成AIの可能性を認めつつも、なぜ「生成AIの判断をそのまま信じてはいけないのか」というリスクについて紹介します。

なぜ「生成AIの判断」をそのまま信じてはいけないのか？

生成AIは、「定量的・網羅的な処理」を得意とします。

そのため、数十ページに及ぶ契約書であったとしても、数秒で内容をスキャンし、主要な論点を整理します。

また、疲労や主観に左右されることなく、設定された基準に基づいて、全ての条文を均一な精度でチェックし続けることができます。

このように、生成AIは法務業務の「一次受け」として、人間の脳にかかる負荷を劇的に軽減する力を秘めています。

しかし、こうした目覚ましい進化の一方で、生成AIに全権を委ねることは現時点では極めてハイリスクです。その理由を3つのポイントで整理しました。

「ハルシネーション（もっともらしい嘘）」の存在

一つの目の理由は、生成AIは統計的に「もっともらしい言葉」を繋ぎ合わせる「ハルシネーション（もっともらしい嘘）」のリスクがあるという点です。

時には存在しない法律を引用したり、条文の意味を真逆にとらえたりすることがあります。

100回中99回正しくても、残りの1回で致命的な嘘をつく可能性があるため、生成AIをそのまま「決裁者」にすることはできません。

「自社固有の事情」を汲み取れない

また、生成AIは一般的な法律知識は持っていますが、「今回の取引先とは10年来の付き合いだから、この条項は多少緩めてもいい」「この事業は我が社の命綱だから、知財条項だけは一歩も引けない」といった、個別のビジネス背景やリスク許容度までは把握できません。

「RAG（検索拡張生成）」という技術を使えば、自社の法務ガイドラインや過去の修正履歴をAIに「知識」として読み込ませることは可能です。

しかし、RAGで補えるのはあくまで「過去のデータ」や「形式的なルール」です。

「ルールには反しているが、この契約を逃さないためにあえてリスクを飲む」という攻めの経営判断や、相手方とのパワーバランスを考慮した最終的な「落としどころ」の決定は、責任を負うことができる人間にしか下せない決断です。

責任の所在が曖昧になる

万が一、生成AIの判断ミスによって契約トラブルが発生した際、生成AIが責任を取ることはできません。

最終的に会社を守り、責任を負うのは常に人間です。プロセスの中に「人間が確認した」という事実がない自動化は、コンプライアンスの観点からも非常に危険です。

人間介在型で自動化するための構成

上記のようなリスクを回避するためには、「Human-in-the-Loop（人間介在型）」という設計思想が重要になります。

これは、「生成AIに下書き（分析）をさせ、人間が最終判断（承認）を下す」というサイクルをシステムの中に組み込むことを指します。

生成AIが、膨大な条文の中からリスクがありそうな箇所をピックアップするという役割を果たし、人がピックアップされた場所を確認することで、自社のルールに照らして「GO」か「NG」かを判断するという流れを作ります。

今回は、「解析」「実行」「管理」といった役割に対し、それぞれ「Dify」「GAS」「スプレッドシート」という3つのツールを組み合わせて構成しています。

解析・判断エンジン（Dify）

Difyは、システムにおける「知能」の部分を担います。単に生成AIに質問を投げるだけでなく、自社の法務ルールや過去の契約事例（ナレッジ）を生成AIに読み込ませ、それに基づいて条文を精査するRAG（検索拡張生成）の実行エンジンです。

一貫した基準で「解析」を行うことで、担当者による判断のバラつきを抑えます。

システム間の接続と処理の実行（GAS）

Google Apps Script（GAS）は、異なるツールを繋ぎ合わせ、一連の動作を完結させる「自動化の司令塔」の役割を果たします。

Googleドライブ内のファイルを検知し、Difyへデータを送り、返ってきた結果をスプレッドシートへ流し込む。この「実行」と「外部連携」を担うことで、人間が介在しなくても業務が回る仕組みを作ります。

データ蓄積・管理インターフェース（スプレッドシート）

スプレッドシートは、全ての「データの蓄積」と、人間が最終判断を下すための「ユーザーインターフェース」の役割を果たします。

生成AIの解析結果がデータベースとして蓄積されるため、過去の傾向分析も容易になります。

また、チェックボックスという馴染みのある形式で「人間による最終承認」を行うことで、安全性を担保します。

人間介在型のリーガルチェック自動化システムの構築方法

ここからは、実際に構築したシステムを詳しく解説していきます。

プログラミングの知識がなくても、それぞれのツールの役割を理解すれば、パズルのように組み上げていくことが可能です。

土台となるGoogleエコシステムの準備

まずは、すべての入り口となる「Googleドライブ」と、管理画面となる「スプレッドシート」を整えます。

Googleドライブ内には、生成AIに読み込ませたい契約書をアップロードするための専用フォルダを一つ作成します。

このフォルダの「ID（URLの一部）」が、後ほどシステムを繋ぐための住所になります。

AIで法務の工数を激減させる「契約書レビュー自動化システム」の構築方法を解説 — Googleドライブ内に作った専用のフォルダ

次に、スプレッドシートを用意します。ここには「ファイル名」「判定結果」「指摘理由」といった項目を並べ、「承認」ボタン（チェックボックス）も配置します。

また、「ファイルID」を記録する列も必要となります。ファイルIDとは、生成AIが同じファイルを二度読みすることを防ぐためにあり、人が確認する必要はないため、この列は非表示にしておくと誰が使っても混乱がなくなります。

Difyで「生成AIの思考プロセス」を設計する

次に、今回のシステムの「知能」にあたるDifyの設定に移ります。

新たにワークフローを作成し、「開始（契約書本文の受け取り）」→「LLM（分析）」→「出力（結果の整理）」というパイプラインを構築します。

今回のLLMノードのプロンプト（指示文）では、「あなたは一流の企業法務担当者です」という役割を与えた上で、出力形式を「JSON」というプログラムが読み取りやすい形式に指定することで、スプレッドシートの各セルへ正確に情報を流し込めるようにしました。

設定したプロンプト
あなたは一流の企業法務担当者です。入力された文章を分析し、以下の項目を厳密にチェックしてください。

反社会的勢力排除条項の有無
自動更新の有無と通知期限
損害賠償額の制限（弊社に著しく不利でないか）

出力形式（重要）: 必ず以下のJSON形式だけで回答してください。
{
“judgment”: “要確認または問題なし”,
“reason”: “具体的なリスク箇所と理由”,
“summary”: “契約書の概要”
}

設定が終わったら「公開」ボタンを押し、外部から呼び出すための「鍵（APIキー）」を発行します。

なお、RAGを活用して「自社の法務ガイドライン」や「過去の修正事例」をAIに学習させる場合、Difyのトップ画面から「ナレッジ」タブを開き、アップロードします。Difyがこれらを自動で解析し、生成AIが検索可能な「知識データ」に変換してくれます。