【Dify】安全運用の基本｜数値・法務・固有名詞の事故を防ぐ
Difyで文章生成を自動化するときは、数値・日付・固有名詞などの「事実」をLLMだけに決めさせないことが重要です。入力値や参照データで事実を確定し、公開・送信前に人が確認できる工程を残します。
本記事では、数値、契約・規約などの高リスクな文章、商品名・会社名といった固有名詞を対象に、事故を防ぐ方法を「人・データ・工程」の3つに分けて解説します。入力変数、RAG、外部データ連携は、事実をLLMの外で管理する手段として概要だけ取り上げます。
なお、敬語・トーン・禁止表現・定型フォーマットを安定させる方法は「プロンプトで出力のブレを防ぐ方法」をご覧ください。モデルやSYSTEMプロンプトなどの設定操作は「LLMノード設定」で解説しています。
契約・規約などの文章はLLMの出力を確定稿として使用せず、担当者や専門家が最終確認してください。本記事の最後には、公開前に確認できるミス防止チェックリストも掲載します。
Difyでハルシネーションが起こる理由｜自然な文章でも正しいとは限らない
Difyで利用するLLMは、入力された内容や参照情報をもとに、文脈に合う文章を生成します。読みやすく自然な文章を作れる一方、出力内容を一次情報と照合し、正しさまで保証する仕組みではありません。
情報が不足している、参照元が古い、質問の条件が曖昧といった場合には、存在しない数値や固有名詞、条件を自然な文章として補ってしまうことがあります。このような、事実と異なるもっともらしい出力がハルシネーションです。
Difyそのものが誤情報を作るわけではありません。しかし、LLMの出力をワークフローや一括処理で繰り返し利用すると、1回の誤りが複数のメールや資料へ広がる可能性があります。対話画面では気づけた間違いが、自動処理ではそのまま成果物になる点に注意が必要です。
そのため、数値・日付・固有名詞などの事実は、入力値・参照データ・一次情報で確定します。LLMには文章化・要約・整形を担当させ、公開や送信の前に確認できる工程を残すことが安全運用の基本です。
なお、事実は正しいものの敬語・トーン・禁止表現・文章の型が安定しない問題は、ハルシネーションではなく「出力のブレ」です。本記事では詳しく扱わず、出力ブレ防止記事へ役割を分けます。
LLMだけに確定させない文章3種類｜数値・高リスク文書・固有名詞
LLMが得意なのは、与えられた情報を読みやすい文章に整えることです。一方で、正確な計算や最新情報の確認、専門的な判断を単独で任せる用途には向いていません。
ここでは、Difyで文章生成を自動化するときに、LLMだけで内容を確定させないほうがよい情報を3つに分けて解説します。
数値・日付・単位｜計算と確定をLLMに任せない
見積金額、請求額、KPI、期限、割合などは、わずかな違いでも業務上の問題につながります。とくに、桁、税込・税抜、円・ドル、パーセント・倍率などは、自然な文章の中に誤りが紛れると発見しにくくなります。
数値を文章に含めること自体が問題なのではありません。避けるべきなのは、LLMに数値を計算させたり、足りない数値を推測させたりすることです。
金額や日付は入力値や業務システムで確定し、必要な計算は計算式や専用ツールで行います。LLMには、確定した結果をメールや報告文として読みやすく整える役割だけを渡します。
契約・規約などの高リスク文書｜最終判断を人に残す
契約、利用規約、免責、医療、金融などの文章は、条件の抜けや断定表現の追加によって意味が変わる可能性があります。文章として自然でも、法的・専門的に正しいとは限りません。
このような分野でLLMを利用する場合は、確認済みの原文を要約する、指定された表現に整えるなど、元資料の範囲内で下書きを補助させます。存在しない条件を追加したり、判断を代行させたりしてはいけません。
外部へ公開・送信する前に、担当者や必要な専門知識を持つ人が原文と照合し、最終確認する工程を残してください。
固有名詞｜正式名称を入力値や管理データから渡す
会社名、商品名、プラン名、人名などの固有名詞は、似た名称との混同や旧名称の使用、英字の大文字・小文字などの表記ゆれが起こりやすい情報です。
正式名称をLLMの記憶に頼るのではなく、入力値、選択肢、商品マスターなど、管理されたデータから渡します。名称が変更された場合も、元データを更新するだけで対応できる形が安全です。
LLMには、渡された正式名称を変更せずに文章へ組み込む役割を与えます。これにより、文章表現は調整しながら、事実として固定すべき名称を維持できます。
Difyを安全に運用する3つの基本原則｜人・データ・工程で守る
Difyで文章生成を安全に運用するには、プロンプトだけで誤りを防ごうとしないことが重要です。誰が最終判断するのか、事実をどこで管理するのか、公開前にどのように確認するのかを決めます。
ここでは、安全運用の基本を「人・データ・工程」の3つに分けて整理します。
原則1 人：最終判断と公開責任をLLMに渡さない
LLMの出力は、完成品ではなく確認前の案として扱います。とくに数値、契約・規約、固有名詞を含む文章は、誰が最終確認するのかを事前に決めてください。
確認者は、文章が自然かどうかだけでなく、入力値や一次情報と一致しているかを確認します。高リスクな文章では、必要な専門知識を持つ担当者による確認も欠かせません。
LLMは文章作成を補助できますが、公開・送信の判断や内容に対する責任まで代行するものではありません。
原則2 データ：事実はLLMの外で確定する
金額、日付、会社名、商品名などの事実は、入力値や管理データ、確認済みの資料で確定します。情報が不足している状態で、LLMに推測させてはいけません。
LLMには、確定した情報を読みやすく整える、短く要約する、用途に合った文章へ変換するといった編集作業を担当させます。
「事実を決める場所」と「文章を作る場所」を分けることで、内容を修正するときも、どこを直せばよいか判断しやすくなります。
原則3 工程：生成して終わらせず、確認できる場所で止める
外部へ公開・送信する文章は、生成後に確認できる工程を設けます。自動生成した文章が、そのまま顧客へのメールや公開ページへ送られないようにしてください。
確認しやすくするため、数値・日付・固有名詞・注意事項などを本文とは別に表示させる方法も有効です。確認者が重要項目と参照元を比較できる形にします。
基本の流れは「事実を確定する→文章を生成する→重要項目を確認する→人が承認する→公開・送信する」です。用途に応じて必要な確認工程を組み込んでください。
Difyで事故を防ぐ4つの設計パターン｜入力・知識検索・外部データ・確認工程
前章の「人・データ・工程」という原則を、Difyのワークフローへ落とし込む方法を紹介します。
ここでは設定手順ではなく、安全性を高めるために各機能をどのように使い分けるかを整理します。
パターンA：User Inputで数値・日付・固有名詞を確定する
金額、納期、会社名、商品名など、変更してはいけない情報はUser Inputで受け取ります。入力された値は変数として後続のノードから参照できます。
LLMには値を考えさせず、受け取った変数を変更せずに文章へ組み込ませます。たとえば見積メールなら、金額・納期・会社名は入力値で確定し、LLMは文面を整える部分だけを担当します。
入力フィールドの種類、変数名、必須・任意の設定方法は、入力フォーム記事で詳しく解説しています。
パターンB：Knowledge Retrievalで確認済みの情報を参照する
社内ルール、商品説明、正式名称一覧など、根拠となる資料がある場合は、ナレッジベースとKnowledge Retrievalを利用します。
検索された内容をLLMへ渡し、「参照情報にない事実を追加しない」「正式名称を変更しない」といった条件で文章化させます。
ただし、ナレッジを登録しただけで出力の正しさが保証されるわけではありません。古い資料、検索されなかった情報、関係のない検索結果が混ざる可能性があるため、参照内容と生成結果の確認が必要です。
パターンC：HTTP RequestやToolノードで外部データを取得する
価格、在庫、予約状況など、外部システムで管理されている情報は、HTTP RequestやToolノードを利用して取得します。
外部から取得した値を事実としてLLMへ渡し、LLMには説明文や案内文への変換だけを担当させます。情報をプロンプトへ直接書き込む方法より、元データの更新を反映しやすくなります。
ただし、取得に失敗した場合や値が空だった場合に、LLMが不足情報を推測しないようにしてください。データを取得できなかったときは処理を止める、または確認を求める分岐が必要です。
パターンD：Human Inputで公開・送信前に確認する
顧客へのメール、公開記事、契約に関係する文章などは、生成結果をそのまま外部へ送らず、確認できる場所でワークフローを一時停止します。
DifyのHuman Inputノードを利用すると、WorkflowやChatflowの途中で処理を止め、人が内容を確認・修正してから次へ進められます。
確認画面では本文だけでなく、数値・日付・固有名詞・参照元などの重要項目も表示します。確認者が一次情報と比較しやすい形にしてください。
Human Inputは確認する場所を作る機能であり、内容の正しさを自動判定する機能ではありません。誰が何を確認し、どの状態なら承認するのかを別途決めておく必要があります。
Dify文章生成のミス防止チェックリスト｜公開・送信前に確認
Difyで生成した文章を公開・送信する前に、用途に関係する項目を確認してください。すべての項目を毎回確認する必要はありませんが、金額や契約など影響の大きい文章ほど、確認範囲を広く設定します。
前章で紹介したHuman Inputの確認画面へ、必要な項目を表示させる方法も有効です。
| 確認対象 | チェック項目 |
|---|---|
| 数値・日付・単位 | □ 入力値や元データと一致しているか □ 桁や小数点の位置に誤りがないか □ 円・ドル、時間・分、税込・税抜などの単位が正しいか □ 合計や割合は、確認済みの計算結果と一致しているか |
| 固有名詞 | □ 会社名・商品名・プラン名・人名が正式表記になっているか □ 英字の大文字・小文字、全角・半角、記号が元データと一致しているか □ 旧名称や別の商品名が混ざっていないか |
| 契約・規約などの高リスク文書 | □ 原文にない条件や例外が追加されていないか □ 「必ず」「保証する」などの断定表現が追加されていないか □ 適用範囲や責任範囲が変わっていないか □ 必要な知識を持つ担当者が最終確認したか |
| 参照情報・根拠 | □ 使用した資料やデータが最新であるか □ 出力内容が参照元の範囲を超えていないか □ RAGや外部データから必要な情報を取得できているか □ 情報を取得できなかった部分をLLMが推測していないか |
| 公開・送信工程 | □ この出力が下書きか確定稿か明確になっているか □ 最終確認者と承認条件が決まっているか □ 未確認の項目が残ったまま自動送信されないか □ 誤りが見つかった場合に、入力・データ・工程のどこを修正するか判断できるか |
確認できない項目が残っている場合は、そのまま公開・送信せず、元データまたは担当者へ確認してください。
このチェックリストは誤りの発見を支援するものであり、内容の正確性を保証するものではありません。文章の用途と影響範囲に応じて、確認者と確認項目を調整してください。
まとめ：事実はLLMの外で確定し、LLMは文章を整える
Difyで文章生成を安全に運用するには、数値・日付・固有名詞などの事実をLLMだけに決めさせないことが重要です。
事実は入力値、ナレッジ、外部データ、一次情報などで確定し、LLMには文章化・要約・整形を担当させます。契約・規約などの高リスクな文章では、必要な知識を持つ担当者による最終確認も欠かせません。
安全運用の基本は、次の3点です。
- 人：最終判断と公開責任をLLMに渡さない
- データ：数値や固有名詞はLLMの外で確定する
- 工程：生成して終わらせず、公開・送信前に確認する
Difyでは、User Input、Knowledge Retrieval、HTTP RequestやToolノード、Human Inputなどを組み合わせることで、この考え方をワークフローへ反映できます。
ただし、機能を追加するだけで内容の正確性が保証されるわけではありません。誰が何を確認するのか、情報を取得できなかった場合にどう処理を止めるのかまで決めておくことが大切です。