【Dify】契約書レビューを自動化する方法｜AI一次チェックと法務承認フロー

この記事は約10分で読めます。

「営業から届く契約書の確認依頼が月末に集中し、法務や総務の手が回らない」。そんな悩みを抱えるバックオフィスは少なくありません。専任の法務担当がいない会社では、総務や経理が契約書チェックを兼務していることも多いでしょう。

この記事では、ノーコードのAIアプリ開発基盤であるDify（ディファイ）を使い、契約書レビューの「一次チェック」をAIに任せる方法を解説します。AIが条項を抜き出してリスクを指摘し、最後は担当者が承認する流れを、ノード構成・設定手順・プロンプト例まで具体的に紹介します。

2026年8月に法務省が公表した、AIによる法務業務支援と弁護士法第72条に関する新しいガイドラインの要点にも触れます。対象読者は、契約書チェックを担当する総務・法務・経理の実務担当者と、その仕組みづくりを任された管理職の方です。

スポンサーリンク

Dify で契約書レビューを自動化すると何が変わるのか

契約書レビューの作業は、大きく「読む」「比べる」「判断する」「返す」の4段階に分けられます。このうち、条項を読み取って自社基準と比べる工程は、生成AIが比較的得意とする領域です。一方で、取引の背景を踏まえた最終判断は人が担うべき工程です。

Difyのワークフロー機能を使うと、この分担を1本の流れとして組み立てられます。ファイルを受け取る、文章を取り出す、AIが判定する、人が承認する、結果を返す、という一連の処理をノード（処理の部品）をつなぐだけで作れます。

特に注目したいのが「Human Input（人の入力）」ノードです。ワークフローを途中で一時停止し、担当者にフォームを送って判断を求められます。Dify公式ドキュメントによると、Webアプリ上での表示に加えてメールでの依頼にも対応しています。メールの受信者はDifyのアカウントを持っていなくてもよいとされています。

つまり「AIが下読みし、人が承認ボタンを押す」という承認フローを、外部ツールに頼らずDifyの中だけで完結できます。なお、DifyはGitHub上で頻繁に更新されています。機能の細部は版によって変わるため、導入前に公式ドキュメントで最新情報をご確認ください。

契約書チェックAIのワークフロー構成（ノード一覧）

ここでは、秘密保持契約（NDA）や業務委託契約など、定型的な契約書の一次チェックを想定したワークフローを紹介します。全体のノード構成は次のとおりです。

  • 開始（Start）：契約書ファイル、契約類型（NDA／業務委託／売買など）、相手方名、依頼者名を入力
  • 文書抽出（Doc Extractor）：DOCXやテキストPDFから本文を取り出し、変数 text に格納
  • 知識検索（Knowledge Retrieval）：自社の「契約審査基準」をナレッジから検索
  • LLM①条項抽出：契約期間、損害賠償、解除、再委託、知的財産などの条項をJSONで抜き出す
  • LLM②リスク判定：審査基準と照らし、条項ごとに高・中・低のリスクと修正案を出す
  • 条件分岐（IF/ELSE）：高リスクがある、または紛争の気配がある場合は別ルートへ
  • Human Input：法務・総務担当者へメールでレビュー結果を送り、承認／修正依頼／顧問弁護士へ相談の3択を選んでもらう
  • テンプレート＋終了：選ばれた結果に応じて、依頼者向けの回答文を整えて返す

文書抽出ノードの対応形式は、公式ドキュメントではTXT、DOCX、テキストベースのPDFなどです。紙をスキャンした画像PDFは、そのままでは文字を取り出せない可能性があります。スキャン原本が多い会社は、事前にOCR（画像から文字を読み取る処理）をかけるか、Word形式での提出を依頼者にお願いするのが確実です。

知識検索で使う「契約審査基準」は、AIの判定の質を左右する最重要の材料です。たとえば「損害賠償の上限は委託料総額まで」「管轄裁判所は本店所在地」など、自社が普段どう判断しているかを文章で残しておきましょう。いわゆるプレイブック（審査の型をまとめた手引き）です。

Dify ワークフローの設定手順

実際の設定は次の順番で進めます。Dify Cloud・セルフホストのどちらでも、基本の操作は共通です。

  1. 審査基準をナレッジに登録する：「ナレッジ」から新規作成し、契約類型ごとの審査基準をアップロードします。1項目1段落で書くと検索精度が安定しやすくなります。
  2. ワークフローアプリを作成する：「最初から作成」でワークフローを選び、開始ノードにファイル入力と選択式の契約類型を追加します。
  3. 文書抽出ノードをつなぐ：開始ノードのファイル変数を入力に指定します。出力の text が後続のLLMに渡ります。
  4. 知識検索ノードを設定する：検索クエリには契約類型を指定し、手順1のナレッジを選択します。
  5. LLMノードを2つ配置する：条項抽出とリスク判定を分けると、どこで誤りが起きたか追いやすくなります。プロンプトは次章の例を参考にしてください。
  6. 条件分岐を置く：リスク判定の結果に「高」が含まれるか、または紛争の気配があるかで分けます。
  7. Human Inputノードを設定する：配信方法でメールを選び、受信者に法務・総務の担当者を指定します。フォームには判定結果を変数で表示し、コメント欄（Paragraph）と、承認・修正依頼・弁護士相談の3つのボタンを設けます。
  8. タイムアウト時の分岐を決める：執筆時点の公式ドキュメントでは、既定のタイムアウトは3日とされています。期限切れの分岐を何にもつながないとワークフローが終了するため、リマインド通知などに接続しておきます。
  9. テストして公開する：過去の契約書（機密部分を伏せたもの）で動作を確かめ、問題がなければWebアプリとして社内に公開します。

Human Inputのボタンを押すと、後続ノードで __action_id（押されたボタンのID）などの変数が使えます。これを条件分岐に渡せば、「承認なら依頼者へ完了連絡」「修正依頼なら修正案を添えて差し戻し」と処理を分けられます。依頼は最初の1人が回答した時点で閉じる仕様なので、複数人に送る場合は誰が判断するかを事前に決めておきましょう。

コピペで使える契約書チェックのプロンプト例

LLMノードに設定するプロンプトの例です。波かっこの部分はDifyの変数に置き換えてください。まずは条項抽出用です。

あなたは企業法務のアシスタントです。
次の契約書本文から、以下の項目に該当する条項を抜き出してください。

【抽出項目】
契約期間・自動更新／損害賠償（上限の有無）／解除条件
秘密保持の範囲と期間／再委託の可否／知的財産の帰属
支払条件／管轄裁判所／反社会的勢力の排除

【ルール】
・条文番号と原文をそのまま引用する
・該当する条項がない場合は「記載なし」と書く
・推測で補わない
・JSON形式で出力する

【契約書本文】
{{text}}

次に、リスク判定用のプロンプトです。審査基準を一緒に渡すのがポイントです。

あなたは当社の契約審査担当者です。
抽出された条項を、当社の審査基準と比較してください。

【当社の審査基準】
{{knowledge_result}}

【抽出された条項】
{{clauses}}

【出力形式】
条項ごとに次の表形式で出力すること。
| 条項 | 判定(高/中/低) | 理由 | 修正案 | 基準の該当箇所 |

【ルール】
・審査基準に書かれていない論点は「基準外：要確認」とする
・法的な結論を断定しない
・紛争・請求・訴訟などの記載があれば冒頭で「要弁護士確認」と明示する
・最後に、担当者が確認すべき点を3つ以内で挙げる

「基準の該当箇所」を必ず書かせると、AIがどの基準を根拠にしたかを人が検証しやすくなります。根拠のない指摘や、基準にない独自の判断を見つけやすくなるため、ハルシネーション（AIがもっともらしい誤りを出す現象）への対策にもなります。

AIと人の役割分担｜契約審査の判断ラインを比較

AIに任せる範囲を最初に決めておくと、運用が安定します。役割分担の目安を表にまとめました。

工程 AI（Dify）の役割 人の役割
受付 ファイル受領と契約類型の記録 依頼の優先度づけ
条項の読み取り 重要条項の抽出と一覧化 抽出漏れの確認
基準との比較 自社基準との差分と修正案の提示 取引背景を踏まえた妥当性の判断
最終判断 行わない 承認・差戻し・弁護士相談を決定
相手方との交渉 修正依頼文の下書き 送付内容の確定と交渉

ポイントは、AIを「判断者」ではなく「下読み担当」と位置づけることです。最終判断のボタンを人が押す設計にしておけば、責任の所在が明確になります。後から監査や社内確認があっても、誰がいつ承認したかを説明しやすくなります。

導入時の注意点・リスク（弁護士法第72条と情報管理）

契約書は機密情報と個人情報のかたまりです。仕組みを作る前に、次の論点を必ず確認してください。

弁護士法第72条との関係

弁護士法第72条は、弁護士でない者が報酬を得る目的で法律事務を取り扱うことを禁じた規定です。法務省は2026年8月21日に「ビジネス分野におけるＡＩ等法務業務支援サービス提供と弁護士法第７２条の関係について」というガイドラインを公表しました。主な対象はサービスの提供者で、紛争が現に生じている案件などを扱うかどうかが重要な判断要素とされています。

自社の契約書を自社の担当者がチェックする用途は、外部にサービスを提供する場面とは前提が異なります。ただし、紛争が起きている、または起きることがほぼ避けられない案件はAIの一次チェックに頼らず、顧問弁護士に相談するルートを用意しておくのが安全です。前述の条件分岐とHuman Inputの「弁護士相談」ボタンは、この考え方を仕組みにしたものです。個別の判断は弁護士にご相談ください。

情報漏えい・個人情報

契約書には取引条件や担当者の氏名などが含まれます。利用するAIモデルの提供元が入力データをどう扱うか、学習に使われない設定になっているかを確認しましょう。社外秘の度合いが高い契約は、セルフホスト環境で運用するという選択肢もあります。

権限管理と社内規程

Difyのワークスペースに誰が入れるか、ナレッジの審査基準を誰が編集できるかを決めておきます。審査基準が勝手に書き換えられると、AIの判定もそのまま変わってしまうためです。生成AIの社内ガイドラインに「契約書をAIで扱う際のルール」を追記しておくと、現場も安心して使えます。

導入前チェックリスト

  • 審査基準（プレイブック）を契約類型ごとに文書化したか
  • AIモデルのデータ取り扱い条件を確認したか
  • 最終判断を人が行うフローになっているか
  • 紛争案件を弁護士へ回すルートがあるか
  • Human Inputのタイムアウト時の処理を決めたか
  • ナレッジとワークフローの編集権限を限定したか
  • スキャンPDFなど読み取れない書類の扱いを決めたか

よくある質問（FAQ）

Q1. 専任の法務担当がいない会社でも使えますか？

使えます。むしろ総務や経理が兼務している会社ほど、AIによる一次チェックの効果を感じやすいはずです。ただし、AIの指摘を正しく判断できる人が最後に確認する体制は欠かせません。判断に迷う契約は顧問弁護士へ回すルールをあらかじめ決めておき、Human Inputの選択肢にもその道を用意しておくと安心です。

Q2. 英文契約書にも対応できますか？

多くの生成AIモデルは英語の文章も扱えるため、同じワークフローで抽出や判定を試すことは可能です。ただし、準拠法や用語の解釈など英文契約特有の論点は、日本語の審査基準だけでは拾いきれない場合があります。英文用の審査基準を別に用意し、出力は日本語で返すようプロンプトで指定すると、確認がしやすくなります。

Q3. Human Inputノードが使えない場合はどうすればよいですか？

Difyのバージョンが古いと、Human Inputノードが表示されないことがあります。セルフホストの場合は、公式のアップグレード手順を確認したうえで更新を検討してください。すぐに更新できない場合は、AIの判定結果をSlackやメールに送り、承認は既存のワークフローシステムで行う方法でも代替できます。

まとめ｜Dify の契約書レビューはAI一次チェック＋人の承認で始める

Difyを使えば、契約書の読み取りから自社基準との比較、担当者の承認までを1本のワークフローにまとめられます。中心になるのは、文書抽出・知識検索・LLM・Human Inputの4つのノードです。

成功のカギは、AIを最終判断者にしないことと、審査基準を文書として整えることです。紛争案件を弁護士へ回すルートも最初から組み込んでおきましょう。次のアクションとして、まずは自社で最も件数の多い契約類型（たとえばNDA）について、審査基準を10項目ほど書き出すところから始めてみてください。

関連記事

参考リンク

スポンサーリンク
タイトルとURLをコピーしました