序章｜Difyで契約書チェックを「成立させる」という話
契約書チェックに生成AIを使う、という話は珍しくなくなった。
条文を読み、怪しい点を指摘し、抜け漏れを洗い出す。
技術的には、すでに十分可能だ。
だが、本稿で扱うのは
「何ができるか」ではない。
どうすれば、現場で“成立するか”という話だ。
前提条件は明確にしておく。
本稿は、
- Difyを使い
- ローカルLLMを前提に
- 契約書という機密情報を扱い
- それでも現場が安心して使える形を探る
そのための実務的な整理である。
派手なAI活用事例は出てこない。
自動化も誇張しない。
判断をAIに委ねることもしない。
目指すのは、
契約書チェックが“事故らずに回り始める最小構成”だ。
契約書は、機密情報の中でも特に厄介な部類に入る。
個人情報だけでなく、
取引条件、価格、責任範囲、交渉の痕跡。
組織の意思決定そのものが、文書として封じ込められている。
だからこそ、
「AIで契約書をチェックできる」という話は、
便利さと同時に、必ずガバナンスの問題を引き連れてくる。
- どこに送られるのか
- 誰が見るのか
- 誤った指摘を信じた場合、誰が責任を負うのか
この問いを曖昧にしたままでは、
どれほど高性能なモデルを使っても、
現場では“使ってはいけないもの”になる。
本稿では、あえて話を単純にする。
- Vision（画像認識）は使わない
- 契約書をPDFのまま読ませない
- 「できなくはない」ことより
「やらないほうが安全な理由」を優先する
結論から言えば、
Difyで契約書チェックを成立させる最適解は、
ただのチャットボットだ。
WordやPDFを放り込んで解析させるのではない。
必要な範囲を、人が一度テキストとして抜き出し、
その内容について論点整理をさせる。
地味だ。
だが、この地味さこそが、
ローカルLLM × Difyという構成で
契約書を扱うための、いちばん安全な道になる。
第1章｜契約書チェックにおけるLLMの本質的な価値
契約書チェックという作業は、
しばしば「正解を当てる仕事」だと思われがちだ。
この条文は問題ないか。
この表現は一般的か。
リスクはどこにあるのか。
だが、実務の現場で行われている契約書チェックは、
それほど単純ではない。
多くの場合、最初に必要とされるのは
結論ではなく、整理だ。
- この契約書は、何についての合意なのか
- どこが通常で、どこが例外なのか
- 読んでいて引っかかる点は、どこに集中しているのか
こうした問いに対し、
即座に「OK」「NG」を出す必要はない。
むしろ、
判断を下す前段階で、
思考を一度、外に出す相手が必要になる。
現場では、すでにこの役割を
LLMが静かに担っていることが多い。
法務に回すほどではない。
上司に聞くには、まだ早い。
だが、自分一人で抱えるには不安が残る。
そうしたときに、
- 契約書の一部を貼り付け
- 「論点として注意すべき点を挙げてほしい」
- 「一般的な契約と比べて違和感が出やすい箇所はどこか」
といった問いを投げる。
返ってくるのは、
断定ではない。
最終判断でもない。
だが、
頭の中に散らばっていた不安が、
言葉として並び直される。
それだけで、
次に何をすべきかが見えてくる。
ここで重要なのは、
LLMが「契約書を理解しているか」ではない。
また、
法的に正しい判断を下せるかでもない。
LLMが果たしている役割は、
考えを整理するための外部化された思考装置だ。
- 抜け漏れに気づく
- 視点を増やす
- 思考の偏りを一度崩す
この用途において、
最新モデルかどうかは本質ではない。
Visionが使えるかどうかも、
まだ関係がない。
必要なのは、
「ここに相談していい」という場所があること。
そして、
その相談が事故らない範囲に収まること。
Dify上のチャットボットは、
この役割を極めて素直に満たす。
- ブラウザで開ける
- LAN内で完結できる
- ログも残せる
しかも、
業務システムほど重くならない。
契約書チェックという題材において、
この「軽さ」は重要だ。
重たい仕組みを用意した瞬間、
相談は減る。
使われなくなる。
結果として、
LLMは再び
「個人が黙って使う裏技」に戻ってしまう。
第2章｜DifyでVisionを使えば、できなくはない
契約書チェックにおいて、
Vision（画像認識）を使いたくなる気持ちは、自然だ。
現実の契約書は、
WordやPDFでやってくる。
スキャンされた書類も多い。
レイアウトも、表も、注釈も混ざっている。
それをそのままアップロードし、
「この契約書の注意点を教えてほしい」
と投げられたら、確かに楽だ。
技術的にも、これはすでに可能である。
- Vision対応のLLMを使えば
- PDFや画像を直接入力し
- 条文構造や文脈を踏まえた応答を得ることができる
Dify自体も、
Vision対応モデルを使えば
チャットUI上で画像アップロードを有効にできる。
商用API、たとえばOpenAIのVisionモデルを使う構成であれば、
この体験は比較的あっさり実現する。
「契約書を放り込むだけでチェックできる」
そう言いたくなる環境は、確かに作れる。
ここで、あえて否定はしない。
Visionを使えば、
- コピペの手間は減る
- OCRの工程は消える
- 見た目そのままの文書を扱える
できなくはない。
少なくとも、
Difyというプラットフォームが
Visionを拒絶しているわけではない。
だが、本稿の前提に戻ろう。
扱っているのは、
ローカルLLMを前提とした
Difyによる“お手軽DX”である。
ここで一つ、視点を切り替える必要がある。
Visionは、
「便利かどうか」以前に、
どこで、誰の責任で使うのか
という問いを強く引き寄せる機能だ。
特に、契約書のような文書では、
その影響が顕著に出る。
Visionを使うということは、
単に入力形式が増える、という話ではない。
- 読み取り精度のばらつき
- レイアウト解釈の揺れ
- 行間を補完してしまう推論
これらが、
ユーザーには見えない形で混入する。
テキストであれば、
「ここに書いてある内容」を
人が一度確認した上で投げられる。
だが、Visionでは、
どこまでをどう解釈したかが曖昧になる。
契約書チェックにおいて、
この曖昧さは致命的になりうる。
もう一つ、無視できない問題がある。
それは、
ローカル運用との相性だ。
Vision対応モデルは、
多くの場合、
商用APIとのセットで語られる。
つまり、
「Visionを使う」という選択は、
そのまま
外部APIを使う判断に直結しやすい。
契約書という題材で、
これは単なる技術選択では済まない。
第3章｜ローカル運用において、Visionは争点を増やす
DifyでVisionを使う、という話は
技術の話であると同時に、
運用とガバナンスの話でもある。
特に、ローカルLLMを前提にDifyを使っている場合、
Visionは単なる入力手段の拡張では終わらない。
理由は単純だ。
ローカルLLMを選ぶ組織は、
すでに何らかの判断をしている。
- クラウドに出したくない情報がある
- 入力内容の所在を明確にしたい
- 説明責任を内部で完結させたい
契約書を扱うなら、
この判断はむしろ自然だ。
ここでVisionを持ち込むと、
一気に論点が増える。
- 画像やPDFは、どこで解析されるのか
- モデルは本当にローカルで完結しているのか
- OCRや画像処理の段階で、外部に出ていないか
商用APIを使えば、
これらは「サービス仕様」に回収される。
だが、ローカル運用を選んでいる組織にとって、
その説明は通らないことが多い。
なぜ、わざわざローカルにしたのに、
契約書だけ外に出すのか。
この問いに、
技術的な正解はない。
あるのは、
組織としての判断だけだ。
さらに厄介なのは、
Visionがもたらす“見えない処理”である。
テキスト入力であれば、
人が一度、内容を確認する。
だが、PDFや画像をそのまま投げる場合、
どこまでが入力として解釈され、
どこが無視されたのかが分からない。
- 脚注
- 但し書き
- 小さな注記
こうした要素が、
Vision推論の中でどう扱われたかは、
ユーザーには確認しようがない。
契約書チェックにおいて、
この不透明さは致命的だ。
つまり、ローカル運用におけるVisionは、
- 技術的に難しい
- 運用上、説明が難しい
- 事故が起きたときに、原因を特定しづらい
という三重苦を抱える。
便利かどうか以前に、
扱いづらい。
第4章｜Dify × LM Studioでは、Visionは使えないという現実
ここまでの話を踏まえたうえで、
いちど感情を排して、現実だけを整理しておく。
2026年現在、DifyとLM Studioを組み合わせたローカル環境では、
Vision推論は実質的に使えない。
これは「設定が足りない」とか
「モデル選択を間違えている」といった話ではない。
まず前提として。
- Vision対応をうたうVLモデルは存在する
- LM Studioでも、それらのモデルは起動できる
- 画像ファイルのアップロード自体は、Dify側で可能
ここまでは事実だ。
問題は、その先にある。
Difyは、モデルがVision対応かどうかを
コネクタ単位で判断している。
OpenAIやGoogleなどの商用APIでは、
この判定が明確に行える。
- Vision対応モデルか
- 画像入力を受け取れるか
- API仕様として保証されているか
その結果、
DifyのUI上で「Vision対応」がONになり、
画像入力が正式に有効化される。
一方、LM Studioはどうか。
LM Studioは、
OpenAI互換APIとしてDifyに接続される。
この互換APIは、
テキスト生成を主目的とした仕様になっており、
Vision入力を正式に扱うための情報を
Dify側に渡さない。
その結果、何が起きるか。
- Vision対応モデルを選んでも
- VLモデルを起動していても
- 画像をアップロードできるように見えても
DifyはVisionをONにできない。
UI上では、
Visionは未対応のままになる。
重要なのは、
これはモデルの性能の問題ではない、という点だ。
- Qwen系
- Gemma系
- その他のVLモデル
どれを選んでも結果は同じ。
Dify × LM Studio という構成では、
Vision推論は前提にできない。
さらに厄介なのは、
中途半端に“動いているように見える”ことだ。
- ファイルはアップロードできる
- LLMは何かしらの返答を返す
だが、その推論は
Visionに基づいていない。
画像の内容を見ているわけではなく、
ファイル名や周辺文脈からの推測で
それっぽい回答を生成してしまう。
これは便利どころか、
最悪の状態だ。
誤っていることに、
ユーザーが気づけない。
この挙動は、
設定ミスでもバグでもない。
DifyとLM Studioの設計上の境界線だ。
- Difyは、Vision対応が保証されない限りONにしない
- LM Studioは、Vision入力を保証するAPIを提供していない
その結果として、
「使えない」という現実が生まれている。
ここで一度、整理しよう。
- Vision対応モデルは存在する
- ローカルでも動かせる
- だが、DifyとLM Studioの組み合わせでは
Visionを安全に使う経路がない
この事実は、
好みや思想の問題ではない。
現在の技術的制約そのものだ。
第5章｜それでもVisionを使わない判断が、いちばん合理的だった
ここまで読んで、
こう思った人もいるかもしれない。
APIを書けばいいのでは？
別の実装をすれば、Visionは使えるのでは？
技術的には、その通りだ。
- 独自にAPIを実装する
- Vision対応の推論経路を自前で用意する
- Difyの外で処理して結果だけ渡す
やろうと思えば、できなくはない。
だが、それは
Difyでお手軽DXをやる
という前提から外れる。
ここで、改めて目的を思い出そう。
本稿の目的は、
「最先端のAI活用」を見せることではない。
- 現場が
- 無理をせず
- 事故らず
- 継続して使える
その状態を、最短距離で作ることだ。
Visionを契約書チェックに使う場合、
この目的に対して
明らかに割に合わない負債が発生する。
まず、技術的負債。
- API実装の保守
- モデル更新への追随
- 仕様変更時の検証
これらは、
契約書チェックという用途に対して
過剰だ。
次に、運用上の負債。
- Vision推論の結果を
どこまで信じていいのか - 誤読が起きた場合、
どこで検知するのか
Visionは、
「間違っていることが分かりにくい」。
この特性は、
契約書という題材と致命的に相性が悪い。
さらに、ガバナンス上の負債がある。
- なぜVisionを使うのか
- なぜローカルで完結しないのか
- なぜ、そのリスクを取るのか
これらの問いに、
明確な業務上の必然性がなければ、
説明は通らない。
便利だから、では弱い。
ここで重要なのは、
Visionを使わないことが、価値の放棄ではない
という点だ。
第1章で整理した通り、
契約書チェックにおけるLLMの本質的価値は、
- 判断を代替することではなく
- 読み飛ばしを防ぐことでもなく
思考を整理し、論点を浮かび上がらせること
にある。
この価値は、
テキスト入力だけで十分に成立する。
つまり、結論はこうなる。
- Visionを使えば、できなくはない
- だが、やる理由がない
- むしろ、やらないほうが安全で合理的
Dify × ローカルLLMという構成において、
契約書チェックにVisionを持ち込まない判断は、
妥協ではない。
設計上の最適解だ。
第6章｜結論：Difyでは「ただのチャットボット」が最適解になる
ここまでの議論を踏まえると、
結論は拍子抜けするほど地味になる。
Difyで契約書チェックを成立させる最適解は、
何の変哲もないチャットボットである。
Visionは使わない。
PDFを直接読ませない。
Wordファイルもアップロードしない。
必要な範囲を、
人が一度テキストとして切り出し、貼り付ける。
それだけだ。
この構成が優れている理由は、
技術的に簡単だからではない。
責任の線が、はっきりするからだ。
- どこまでが入力か
- どの条文を対象にしているか
- 何をLLMに期待しているか
すべてが、
ユーザーの操作として可視化される。
「ここに書いてある内容について相談した」
という事実が、そのままログに残る。
Visionのように、
どこまで読んだのか分からない、
という状態が発生しない。
さらに、この構成は
ガバナンスとの相性が良い。
- 入力は人が選別している
- 判断や結論は求めていない
- あくまで論点整理に限定している
これなら、
- 法務の前段
- 上司レビューの前段
- 自分の思考整理
どこに置いても破綻しない。
Difyというプラットフォームは、
この用途に驚くほどよく合っている。
- UIがある
- LAN内で完結できる
- ログが取れる
それ以上の機能は、
この段階では不要だ。
むしろ、
余計な機能を足すほど、
契約書チェックという用途から
遠ざかっていく。
重要なのは、
この構成が後戻り可能だという点だ。
- Visionを使いたくなったら、後で検討すればいい
- API実装が必要になったら、その時にやればいい
- PhaseDで新たに立案すればいい
だが、最初から
そこに行く必要はない。
Difyでお手軽DXをやる、という文脈では、
- まず置く
- 勝手に使われる
- 事故らない
この3点を満たすことが、
何より重要だ。
ただのチャットボットは、
この条件をすべて満たしている。
第7章｜契約書チェック用・Difyプロンプト道場
ここまでで、構成は確定した。
- Visionは使わない
- ローカルLLM前提
- Dify上のチャットボット
- 役割は「判断しない思考整理役」
あとは、
LLMに余計なことをさせないための制約を与えるだけだ。
この章は、
高度なプロンプト設計の話ではない。
むしろ逆で、
どこまで削れるかの話になる。
7-1. 契約書チェックで、LLMにやらせてはいけないこと
まず、禁止事項を明確にする。
契約書チェック用途で、
LLMにやらせてはいけないのは次の4つだ。
- 判断を下すこと
- 結論を出すこと
- 是非・可否を断定すること
- 修正案を提示すること
これらはすべて、
人間の責任領域に属する。
LLMがここに踏み込んだ瞬間、
便利さと引き換えに、
説明不能なリスクが生まれる。
7-2. 役割を極端に限定する
そこで、役割をここまで絞る。
論点整理だけを行う補助者
具体的には、
- 注意が必要そうな箇所を挙げる
- 一般的な契約で争点になりやすい点を列挙する
- 読み手が確認すべき観点を提示する
それ以上はしない。
「どうすべきか」は聞かせない。
「問題かどうか」も言わせない。
7-3. 最小構成のプレプロンプト例
Difyのチャットボットに設定する
プレプロンプトは、これで十分だ。
あなたは契約書チェックの補助者です。
判断・結論・是非・推奨・修正案を出してはいけません。
断定的な表現を避けてください。
入力された文章について、
・論点になりやすい箇所
・注意して確認すべき点
・読み手が見落としやすい観点
のみを整理してください。
※本整理は一般的な実務上の論点を示すものであり、
個別案件についての法的判断を行うものではありません。これ以上、説明は要らない。
「なぜ禁止なのか」を書き足したくなるが、
それは人間向けの説明であって、
LLMには不要だ。
制約は、
理由ではなく条件として与える。
7-4. 実際の使い方（地味で正しい）
運用は、拍子抜けするほど単純だ。
- 契約書の対象範囲を人が選ぶ
- その部分をテキストで貼り付ける
- 「論点整理をお願いします」とだけ投げる
それだけでいい。
全文を貼る必要はない。
むしろ貼らない方がいい。
- 今どこを読んでいるのか
- 何が気になっているのか
それが曖昧なままでは、
LLMの出力も曖昧になる。
7-5. なぜこの構成が事故らないのか
この使い方には、
事故を防ぐ構造が最初から埋め込まれている。
- 入力は人が選別している
- LLMは判断しない
- 出力は「気づき」に留まる
仮に誤った指摘があっても、
それは判断材料の一つでしかない。
「AIがそう言ったから」
という逃げ道が、
最初から存在しない。
7-6. 使用例（業務委託基本契約書）
しっかり勘所を抑えられおり、十分実用に耐える。
■ 論点になりやすい箇所
「仕様書」の成立条件（第3条）
仕様書の成立は「発注書提出」＋「受注書提出」の時点で成立とされるが、
→「提出」が「合意」を意味しているか不明。
→両方の提出が「成立」の条件として明示されているが、書面の内容や署名・印鑑の有無、双方の承認の有無が明示されていない。
「着手金の返金」の条件（第6条）
→「乙の重過失を除き、返金には一切応じない」とあるが、
→「重過失」という表現が曖昧。**※「重大な過失」や「明確な損害」**の定義が契約内にないため、実務で争いが発生しやすい。
「納品・検収」の期間（第7条）
→「確認依頼通知受領後20日以内に連絡がない→検収完了」とあるが、
→「連絡がない」は「返信がない」であり、「確認依頼」の内容が「納品完了」を意味するか不明。
→「納品完了」の判断が契約上の検収基準として明示されていない。
...
終章｜2026年現在、この判断がいちばん壊れにくい
本稿で示した構成は、
決して洗練されたAI活用事例ではない。
- Visionは使わない
- 契約書を丸ごと放り込まない
- 判断も結論もAIに委ねない
やっていることは、
Dify上に
少し制約の強いチャットボットを置いただけだ。
だが、この地味さには理由がある。
契約書チェックという業務は、
失敗したときの説明コストが極端に高い。
- なぜ、その判断に至ったのか
- どこまでをAIに任せたのか
- 人は何を確認したのか
これらを言葉で説明できない構成は、
どれほど便利でも長くは使われない。
本稿で採った構成は、
最初からその説明ができる。
- 入力は人が選んだ
- AIは論点整理しかしない
- 判断は人が行った
この三点が、
ログと操作履歴としてそのまま残る。
Visionを使わない判断も、
技術的な敗北ではない。
Dify × LM Studio × ローカルLLMという環境において、
Vision推論は現状、
安全に成立させる経路が存在しない。
それなら、
無理に使わない。
使えるようになったら検討すればいい。
別の作戦を立てればいい。
重要なのは、
今この瞬間に
事故らずに回る構成を選ぶことだ。
Difyでお手軽DXをやる、という文脈では、
- 高度さよりも
- 網羅性よりも
- 将来性よりも
「今日から使えて、
明日も止まらない」ことの方が価値がある。
その条件を満たすのが、
この“ただのチャットボット”だった。
これは完成形ではない。
だが、出発点でもない。
すでに現場で行われていた
「黙ってLLMに相談する」という行為を、
公式に置いただけだ。
それだけで、
契約書チェックという重たい業務は、
少しだけ扱いやすくなる。
AIの未来を語る必要はない。
2026年現在、
ここで止めておくのが正解だった。
この判断が、
あとから見て
「賢かった」と評価されるかどうかは分からない。
だが少なくとも、
壊れにくい。
それで十分だ。
