法務契約書比較 Workflow：Dify の迭代ノードと Human-in-the-Loop による実践設計

はじめに

企業法務において、契約書のレビューは最も工数がかかる業務の一つである。新規契約のドラフトと自社テンプレートの差異確認、取引先から送付された修正版（レッドライン版）の変更点把握、複数の関連契約書間での条項整合性チェック――これらの作業は、高い専門性を要するにもかかわらず、その大部分は「定型的な差異の抽出」に費やされている。

本稿では、Dify の Workflow 機能を活用し、複数ファイルの契約書比較を自動化しつつ、高リスク条項については人間による確認を必須とする法務契約書レビューシステムの設計と実装を解説する。

背景と課題

契約書レビューの現状

本 Workflow が解決すること

• 定型的な差異抽出の自動化: 条項単位での比較を LLM に委任
• リスク分級の標準化: 条項ごとのリスクレベルを一貫した基準で判定
• Human-in-the-Loop: 高リスク・低確信度の判断は必ず人間に回す
• 複数ファイル対応: 迭代（イテレーション）ノードによる逐次処理

全体アーキテクチャ

flowchart TD
    A[契約書ファイルアップロード<br>主契約 + テンプレート + 附属書] --> B[ファイル解析ノード]
    B --> C[契約タイプ分類]
    C --> D[迭代ノード:<br>ファイルごとに条項抽出]
    D --> E[条項マッピング・差異検出]
    E --> F[リスク分級ノード]
    F --> G{高リスク条項あり?}
    G -->|Yes| H[Human-in-the-Loop:<br>法務担当に確認依頼]
    G -->|No| I[レビュー結果出力]
    H --> J{承認 / 差戻し}
    J -->|承認| I
    J -->|差戻し| K[修正指示付きで再レビュー]
    K --> E
    I --> L[構造化レポート出力]

Workflow ノード設計の詳細

ノード 1: ファイル受信・前処理

Dify Workflow の 開始ノード でファイルをアップロードする。複数ファイルを受け付ける場合、各ファイルにメタデータを付与する。

{
  "files": [
    {
      "name": "master_agreement_v2.pdf",
      "role": "review_target",
      "type": "主契約",
      "version": "v2.0"
    },
    {
      "name": "standard_template_2024.pdf",
      "role": "template",
      "type": "業務委託契約テンプレート",
      "version": "2024年版"
    },
    {
      "name": "appendix_a.pdf",
      "role": "attachment",
      "type": "別紙A（SLA条件）",
      "version": "v1.0"
    }
  ]
}

ノード 2: テキスト抽出

PDF からテキストを抽出する。Dify では以下の方法が利用可能である。

契約書は通常テキスト PDF であることが多いため、まずは直接解析を試みるのが効率的である。

ノード 3: 契約タイプ分類（LLM ノード）

System Prompt:
あなたは日本の企業法務の専門家です。
アップロードされた契約書のテキストを分析し、以下の契約タイプに分類してください。

- 業務委託契約
- 秘密保持契約（NDA）
- ソフトウェアライセンス契約
- SaaS 利用規約
- 売買基本契約
- 共同開発契約
- その他（具体的に記述）

出力フォーマット:
{"contract_type": "...", "confidence": 0.0-1.0}

契約タイプに応じて、後続のリスク判定基準やテンプレートを切り替える。

ノード 4: 迭代ノードによる条項抽出

Dify Workflow の 迭代（Iteration）ノード を使用し、アップロードされた各ファイルに対して同一の条項抽出処理を適用する。

迭代ノードの設定:
- 入力配列: files[]
- 各イテレーションの処理:
  1. テキスト抽出
  2. LLM ノードで条項単位に分割
  3. 各条項をJSON配列として出力

条項抽出の LLM プロンプト例:

以下の契約書テキストから、主要条項を抽出してください。
各条項について以下のフィールドを出力してください。

- clause_id: 条番号（例: "第3条第2項"）
- clause_title: 条項名（例: "秘密保持義務"）
- clause_text: 条文全文
- clause_category: カテゴリ（以下から選択）
  [契約主体, 契約期間, 業務範囲, 報酬・支払条件, 
   知的財産権, 秘密保持, 損害賠償, 解除条件, 
   自動更新, 準拠法・管轄, 反社会的勢力排除, その他]

JSON配列で出力してください。

迭代ノードを使う理由: 全ファイルのテキストを一括で LLM に投入すると、コンテキストウィンドウの制約により条項の見落としが発生しやすい。ファイル単位で逐次処理し、中間結果を保持することで、後から「この差異はどのファイルから検出されたか」を正確にトレースできる。

ノード 5: 条項マッピング・差異検出（LLM ノード）

迭代ノードから出力された各ファイルの条項リストを受け取り、テンプレートとレビュー対象の条項を突き合わせる。

System Prompt:
あなたは契約書の比較分析エキスパートです。
テンプレート条項とレビュー対象の条項を比較し、
以下のフォーマットで差異を報告してください。

各条項について:
{
  "clause_category": "...",
  "template_clause": "テンプレート側の条文",
  "review_clause": "レビュー対象側の条文",
  "status": "identical | modified | added | deleted | missing",
  "diff_summary": "差異の要約（日本語）",
  "risk_level": "high | medium | low | info",
  "risk_reason": "リスク判定の根拠"
}

リスク判定基準:
- high: 損害賠償上限の撤廃、自動更新の無制限化、排他的拘束、
        準拠法の変更、データ越境義務、競業避止の過度な拡大
- medium: 支払条件の変更、解除条件の非対称性、保証範囲の縮小
- low: 通知期間の軽微な変更、形式的な文言修正
- info: 差異はあるが実質的影響なし

ノード 6: リスク分級と集計

差異検出結果を集計し、レビューサマリーを生成する。

{
  "total_clauses_compared": 24,
  "identical": 15,
  "modified": 6,
  "added": 2,
  "deleted": 1,
  "high_risk_count": 2,
  "medium_risk_count": 3,
  "requires_human_review": true,
  "high_risk_clauses": ["..."]
}

Human-in-the-Loop 審査ノードの設計

なぜ完全自動化してはいけないのか

契約書レビューにおける AI の役割は「差異の検出と分類」であり、「法的判断」ではない。法的責任は最終的に人間が負うため、高リスクな判断を AI に委ねることは、コンプライアンス上も実務上も許容されない。

トリガー条件の設計

人間の入力ノードの分岐

Dify の「人間の入力」ノードは、以下の 3 つの分岐をネイティブでサポートする。

• ACCEPT: 法務担当が確認し承認 → レポート出力へ進む
• DENY: 法務担当が差戻し → 修正指示を付与して条件分岐へ戻す
• TIMEOUT: 一定時間内に応答なし → 自動承認せず保留状態を維持

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
契約書レビュー: 人間による確認が必要です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

■ 高リスク条項:

1. 第12条（損害賠償）
   テンプレート: 賠償上限は委託料の12ヶ月分
   レビュー対象: 賠償上限の記載なし（無制限）
   → リスク: 損害賠償上限の撤廃

2. 第15条（自動更新）
   テンプレート: 1年ごとの自動更新、解約通知3ヶ月前
   レビュー対象: 3年ごとの自動更新、解約通知6ヶ月前
   → リスク: ロックイン期間の大幅延長

■ 判断をお願いします: [承認] [差戻し]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

条項比較のチェックリスト

比較すべき主要条項

出力レポートの設計

構造化出力（JSON）

下流の契約管理システムやワークフロー承認システムとの連携を想定し、構造化された JSON 形式で出力する。

{
  "review_id": "REV-2026-0412-001",
  "review_date": "2026-04-12",
  "reviewer_ai": "Dify Workflow v1.2",
  "reviewer_human": "法務部 田中",
  "contract_type": "業務委託契約",
  "review_target": "master_agreement_v2.pdf",
  "template": "standard_template_2024.pdf",
  "summary": {
    "total_clauses": 24,
    "differences": 9,
    "high_risk": 2,
    "medium_risk": 3,
    "human_review_status": "approved_with_comments"
  },
  "high_risk_details": [
    {
      "clause_id": "第12条",
      "category": "損害賠償",
      "diff_summary": "賠償上限の記載が削除されている",
      "recommendation": "上限条項の追記を交渉"
    }
  ],
  "recommendations": [
    "第12条の損害賠償上限を明記するよう交渉を推奨",
    "第15条の自動更新期間を1年に短縮するよう修正依頼"
  ]
}

実装上の注意点とアンチパターン

やってはいけないこと

1. 契約書全文を一括で LLM に投入して「違いを教えて」と聞く — 条項単位に分解しないと、重要な差異が埋もれる
2. 主契約・附属書・変更覚書を区別せずに処理する — バージョンと適用優先順位が混乱する
3. AI の判定結果をそのまま最終判断として扱う — 法的責任は人間が負う前提で設計する
4. リスクレベルの判定基準を組織のルールと切り離す — 決裁権限・コンプライアンスポリシーと連動させる
5. Human-in-the-Loop のトリガー条件を定義しない — 「どの条件で人間に回すか」が不明確だと、全件人間に回るか、全件スルーされるかの両極端になる

導入ステップ

API 連携例

Dify Workflow は REST API として公開できるため、既存の契約管理システムから呼び出すことが可能である。

curl -X POST 'https://dify.example.com/v1/workflows/run' \
  -H 'Authorization: Bearer {api_key}' \
  -H 'Content-Type: multipart/form-data' \
  -F 'inputs={"contract_type":"業務委託契約"}' \
  -F 'files=@master_agreement_v2.pdf' \
  -F 'files=@standard_template_2024.pdf' \
  -F 'response_mode=blocking' \
  -F 'user=legal_team_tanaka'

まとめ

法務契約書比較 Workflow の本質は、「AI に契約書を読ませる」ことではなく、標準化可能な差異抽出を自動化し、高リスクな判断を確実に人間に委ねる仕組みを構築することにある。

Dify の迭代ノードにより複数ファイルの逐次処理が実現でき、Human-in-the-Loop ノードの ACCEPT / DENY / TIMEOUT 分岐により、法務レビューに求められる「人間が最終判断する」原則を Workflow レベルで担保できる。

重要なのは、この Workflow を「法務部門の省力化ツール」としてではなく、**「契約リスクの可視化と標準化の基盤」**として位置づけることである。AI が差異を見つけ、リスクを分類し、人間が判断する――このサイクルを継続的に回すことで、組織全体の契約リスク管理能力を底上げすることが可能になる。