Dify + ナレッジベースで構築する契約レビューアシスタント：PDF 文書の処理と検索パラメータの設定方法

企業シナリオにおいて、契約レビューとは AI が法務を代替することではなく、契約の事前審査、条項識別、リスク提示の第一層の能力として活用することがより適切です。

このようなシナリオは、Dify の Knowledge と Workflow を活用した実装に非常に適しています。なぜなら、契約レビューの基本作業は通常、以下のステップに分解できるからです。

契約テキストを読み取る
テンプレート、規程、ルールから根拠を検索する
構造化されたリスク提示と修正提案を出力する

ここで最も重要な二つの課題は通常「モデルが十分に強力かどうか」ではなく、以下です。

PDF 文書をどのように処理すべきか
検索パラメータをどのように設定すれば結果がより安定するか

本記事ではこの二つの課題を中心に、Dify + ナレッジベースを使って実用的な契約レビューアシスタントを構築する方法を説明します。

一、まず明確にすべきこと：契約レビューアシスタントが担うべき役割

企業の実務において、契約レビューアシスタントは「事前審査ツール」として位置づけるのがより適切であり、最終的な意思決定主体ではありません。

担うのに適したタスクは以下の通りです。

契約の基本情報の抽出。例：当事者、金額、期間、支払条件
重要条項の特定。例：違約責任、秘密保持、知的財産権、自動更新
企業標準テンプレートや法務ルールとの初期比較
リスク提示リストの出力
事業部門や法務が利用する修正提案ドラフトの生成

一方、以下は引き続き人的判断に委ねるべきです。

重大な取引ストラクチャーの判断
越境コンプライアンス問題
業界規制の細則解釈
企業の既存ルール体系を超える複雑な紛争

したがって、成熟した契約レビューアシスタントの目標は「法務を代替する」ことではなく、標準化され、繰り返し性が高く、ルール化可能な第一ラウンドの審査作業を優先的に完了することです。

二、第一ステップ：二種類の資料を準備する

契約レビューアシスタントには通常、少なくとも二種類の入力資料が必要です。

1. レビュー対象の契約

事業部門がアップロードする PDF、Word、またはその他の契約テキストです。

2. レビュー根拠資料

例えば：

企業標準契約テンプレート
法務レビューチェックリスト
リスク条項ルール表
契約承認制度
よくある質問の説明
過去の修正規範

実際のプロジェクトでは、多くのチームが契約そのもののアップロードを優先する一方、「レビュー根拠」の整理を見落とし、結果としてシステムが汎用的な要約しか出力できず、真に価値のあるレビュー結論を生成できないケースがあります。

三、第二ステップ：PDF 文書を処理する

契約シナリオにおいて、PDF は最も一般的であり、検索品質に最も影響を与えやすいファイル形式の一つです。

よくある問題

スキャン版 PDF はテキストを直接抽出できない
後続処理に進むには OCR が必要です。
レイアウトが複雑
ヘッダー・フッター、表、印章、ページ番号がチャンク分割の効果を妨害しやすいです。
複数テンプレートが同一ファイルに混在
後続の検索結果の安定性に直接影響します。
重複条項が多すぎる
ランキング段階で有効なコンテンツが押し出されます。

推奨する処理方法

アップロード前に、PDF の基本的な前処理を行うことを推奨します。

テキスト抽出可能な PDF を優先的に使用する
スキャン版には先に OCR を実施する
実質的な意味のない表紙、空白ページ、署名のみのページを削除する
一つの契約につき一つのファイルを維持する
レイアウトが複雑な場合は、よりクリーンなテキストまたは Markdown 構造に変換する

企業の契約ソースが多い場合は、本格的な構築前に独立した「契約クリーニングフロー」を構築し、原本ファイルを標準化してから Dify のナレッジ体系にインポートすることを推奨します。

四、第三ステップ：ナレッジ層を明確に分割する

契約レビューシナリオでは、すべての資料を一つの統一ナレッジベースにそのまま投入することは推奨せず、役割別に分割することをより推奨します。

ナレッジベース A：企業契約テンプレート

標準調達契約
標準販売契約
サービス契約テンプレート
NDA テンプレート

ナレッジベース B：レビュールールとレッドライン

リスク条項リスト
法務レビュー規程
承認権限ルール
例外事項の説明

ナレッジベース C：補足制度・コンプライアンス資料

印章管理制度
支払承認制度
データコンプライアンス要件
業界固有の制約

このように分割する価値は、システムが後続で契約タイプに応じてより適切なナレッジ範囲を選択でき、全資料に対する無差別検索を行わなくて済むことです。

五、第四ステップ：契約レビュー Workflow を設計する

実装可能な契約レビューの基本フローは、通常以下のように設計できます。

契約アップロード
→ 契約テキスト抽出
→ 契約タイプ判定
→ 対応するテンプレートとレビュールールを検索
→ 重要条項の抽出
→ リスクリストと提案の生成
→ 構造化されたレビュー結果の出力

Dify では、通常以下のノードに分割できます。

Input：契約テキストの入力または処理済みテキストのアップロード
LLM ノード：契約タイプの識別
Knowledge Retrieval：テンプレートとルールの検索
LLM ノード：重要条項の抽出
LLM ノード：ルールに基づくリスク分析の出力
Answer / JSON 出力：構造化されたレビュー結果の出力

推奨する出力フィールド

自然言語の要約を一段出力するよりも、構造化された結果の採用をより推奨します。例えば：

契約タイプ
契約期間
支払条項の要約
自動更新条項
違約責任条項
潜在的リスクポイント
修正提案項目
人的レビューの推奨有無

この構造は、後続の承認システム、法務台帳、社内レポートフローへの接続により有利です。

六、第五ステップ：検索パラメータを正しく理解する

契約レビューアシスタントでは、検索品質が出力品質を決定します。

システムが正しい条項、テンプレート、ルールを検索できなければ、後続の生成ステップがどれだけ完全であっても、偏差はむしろ大きくなる可能性があります。

そのため、構築段階では以下のパラメータに関する考え方に重点を置くことを推奨します。

1. Top K は小さすぎても、むやみに大きくしてもいけない

Top K はシステムが一回の検索で返す関連チャンクの数を示します。

小さすぎ：重要な根拠を見落としやすい
大きすぎ：ノイズが多くなり、モデルの集中力に影響する

契約シナリオでは、条項特定型の質問はやや小さめに、総合レビュー型の質問はより多くのコンテキストサポートが通常必要です。したがって、Top K は単一の値に固定すべきではなく、質問タイプに応じて調整すべきです。

2. 「無効化」を長期的な戦略にしない

一部の RAG 実践では、重複した、または使用を続けたくないチャンクを無効に設定し、これで結果に影響しないと考えるチームがあります。

しかし多くの場合、重複チャンクはランキングプロセスに引き続き影響を与え、真に有効なコンテンツが上位から押し出される可能性があります。無効化に頼るよりも、より堅実なアプローチは以下です。

アップロード前に重複条項をクリーニングする
古いバージョンを削除する
クリーニング作業を検索後に残さない

3. チャンクは文字数ではなく契約構造に合わせるべき

契約は一般的な文章ではありません。細かすぎる分割では条項の前後関係が断裂し、長すぎる分割では検索の焦点が低下します。

より合理的なアプローチは通常以下の通りです。

条項または小節単位で分割する
条項タイトルを保持する
一つのチャンクが一つの完全なルールを表現するようにする

例えば「支払方法」と「違約責任」を同一の大きなチャンクに入れるべきではなく、一つの完全な条項を人為的に複数の断片に分割すべきでもありません。

4. 曖昧な質問は先にリライトする

契約レビューでは、よくある質問は往々にして曖昧です。例えば：

「この条項にリスクはありますか？」
「ここは修正が必要ですか？」
「この契約はコンプライアンスに準拠していますか？」

このような質問を直接検索に入れても、通常効果は良くありません。より推奨されるのは、前段の LLM ノードで質問をより明確な検索リクエストにリライトすることです。例えば：

「支払条項が会社テンプレートと一致しているか確認してください」
「契約中の自動更新と違約責任に関する内容を特定してください」

この方法により、関連性を大幅に向上させることができます。

七、第六ステップ：プロンプトでは「根拠」と「境界」を必ず強調する

契約レビューシナリオにおける最大のリスクの一つは、資料が不足している場合にもモデルが一見合理的に聞こえるが根拠の欠けた判断を出力することです。

そのため、回答プロンプトでは以下の原則を明確に制約することを推奨します。

あなたは契約レビューアシスタントです。
提供された契約内容とレビュールールに厳密に基づいて分析を行ってください。
要件：
- 存在しない条項を捏造しないこと
- 推測を結論として扱わないこと
- 各リスクポイントについて根拠を説明すること
- 資料が不足している場合は、人的レビューが必要であることを明示すること
- 出力はできるだけ構造化すること

企業がさらに可読性を高めたい場合は、リスクの等級分けを追加することもできます。例えば：

高リスク
中リスク
低リスク
情報不足

八、第七ステップ：小規模テストセットを構築する

正式リリース前に、まず単一の契約カテゴリからテストを開始することを推奨します。例えば：

NDA
標準調達契約
業務委託契約

そして 10 から 20 件のテストサンプルを準備し、以下のケースをカバーします。

標準テンプレートバージョン
人的修正が加えられたバージョン
明らかにリスク条項が存在するバージョン
情報が不完全、または OCR 品質が低いバージョン

評価時に重点的に確認すべき点：

契約タイプの識別は正確か
重要条項が安定して抽出できるか
リスク提示に根拠があるか
結果が事業部門や法務が直接閲読するのに適しているか

九、推奨する導入方式

社内でこのようなプロジェクトを推進する際、第一段階から「AI 契約レビューシステム」と命名することは通常推奨しません。

事業部門や法務により受け入れられやすい表現は通常以下の通りです。

契約事前審査アシスタント
契約情報抽出アシスタント
条項リスク提示アシスタント
契約テンプレート比較アシスタント

このような表現は現在の AI の実際の能力の境界により適合しており、組織内部で合理的な期待を形成するのにも役立ちます。

まとめ

Dify + ナレッジベースを活用した契約レビューアシスタントの構築において、効果を真に決定するのはモデルだけではなく、三つの基本的な工程がしっかりしているかどうかです。

PDF 文書が高品質なテキストにクリーニングされているか
レビュー根拠が明確なナレッジ層として整理されているか
検索パラメータとチャンク分割戦略が契約構造に沿って調整されているか

これら三つが適切に処理されれば、Dify は実用的な契約事前審査フローを十分に担うことができます。まず情報を抽出し、次に条項を特定し、ルールに基づいてリスク提示を出力し、最後に複雑な判断を人的レビューに委ねる形です。

これが現在、企業が最も実際に活用しやすいアプローチでもあります。AI に法務を直接代替させるのではなく、まず AI を法務の手前にある効率的なスクリーニング能力として位置づけること。

Keyboard shortcuts

MKC — Dify Japan コンテンツ体系