【Dify】Lesson4-2:資料のミスチェックアプリを作ろう|会話変数と変数代入ノード

資料を仕上げる前の「ミスチェック」、地味に時間が溶けますよね。
誤字脱字や表記ゆれだけでなく、抜け漏れや数値の整合性まで見ようとすると、どうしても目が疲れます。
そこでこの記事では、Difyで「資料のミスチェックアプリ」を作りながら、会話変数と変数代入ノードの使い方をしっかり身につけていきます。
今回のアプリのポイントは、チェック基準を “資料ごとにゼロから作らない”ことです。
この記事で習得できるのは、主に次の2つです。
- 会話変数を使ってアプリの状態を会話の中に保持する考え方
- 変数代入ノードで、LLMの出力を会話変数へ安全に書き込み、次のノードで再利用できるようにする実装
これができると、単発で終わらない「業務向けの会話型アプリ」に一気に近づきます。
社内資料の最終確認や、納品前チェックの時短にそのまま使える形を目指して進めていきましょう。
Lesson1:Dify入門|環境構築と最初の生成AIアプリ開発
Lesson2:まずは体験|基本的なアプリを作ろう
Lesson3:文章業務を自動化するアプリを開発しよう
Lesson4:ファイル処理で広がるDifyアプリ開発
・Lesson4-1:PDF資料要約アプリ|ワークフローツール入門
・Lesson4-2:資料のミスチェックアプリを作ろう ◁今回はここ
・Lesson4-3:JSON入門|構造化出力の仕組みを理解しよう
・Lesson4-4:JSON体験|文章作成アシストアプリを作ろう
Lesson5:RAG実践|ナレッジ検索アプリを作ろう
Lesson6:機能拡張と外部システム連携|ツールを使いこなそう
Lesson7:総仕上げ|実践投入への準備
完成イメージ|基準を作る→会話で育てる→資料をチェック
このアプリは「アップロードした資料を、会話しながらチェック精度を上げていけるAIレビュアー」になります。
最初にファイルを渡すと、本文を読み取ったうえで「まずはこの3点で見ましょう」というチェック基準を提案してくれます。
ここで基準を確定させてから、同じ資料に対してミスチェックを実行する流れです。
実際のやり取りは、だいたいこんなイメージです。
あなた:資料ファイルをアップロード
アプリ:資料タイプを推定し、チェック基準を3つ提示「この3点で進めてOKですか?」
あなた:OK(または「数値の整合性も見て」など追加指示)
アプリ:概要(件数・主な種類)+重要度順に指摘を表示
各指摘に「根拠の引用」「問題点」「修正案」「確実/要確認」を添えて返す
この「基準を作る → 会話で基準を整える → 同じ資料をチェックする」という一連の流れを、会話変数と変数代入ノードで実現していきます。
事前知識|会話変数と変数代入ノードの役割
このミスチェックアプリの肝は、「一度作ったチェック基準を、会話の中で育てていく」ことです。
そのために必要になるのが、Difyの会話変数と変数代入ノードです。
ここまでのLessonでワークフローの流れやノードのつなぎ方には慣れてきたと思いますが、今回扱う2つは “会話が続く前提のアプリ” を作るときに必須のパーツになります。
先に概念を押さえておくと、後半の実装で迷いにくくなります。
会話変数とは|会話内で前提を保持する
会話変数は、その名の通り「この会話(チャット)の中で覚えておく値」を保存するための変数です。
1回の実行で消える一時的な値ではなく、同じ会話を続ける限り保持されます。
今回のアプリで言うと、チェック基準(criteria)を会話変数に入れておくことで、あなたが次のメッセージで「OK」や「この観点を追加して」とだけ返しても、アプリ側は前回までの基準を前提にして動けます。
つまり会話変数は、「作業の前提」をアプリが持ち続けるための入れ物です。
ミスチェックのように、基準を調整しながら何度かやり直す業務では特に効果が出ます。
変数代入ノードとは|会話変数へ安全に書き込む
変数代入ノードは、ノードの出力結果を変数に書き込むためのノードです。
「このノードで出たテキストを、会話変数に保存する」といった動きを、わかりやすく分離して実装できます。
この「保存する場所を明確にする」感覚があると、ワークフローが長くなっても整理しやすくなります。
後から見直したときも、“今アプリが覚えている基準はどれか” が追いやすくなるので、実務向けのアプリほど変数代入ノードが効いてきます。
実装手順|資料ミスチェッカーを作ろう
今回作成するミスチェッカーアプリの全体構成は次の通りです。

最初のIF/ELSEノードの後ろから、大きく2つに分岐しています。
上の段が1周目、チェック基準を作る部分であり、下の段が2周目、作った基準をもとに実際にミスチェックを行う部分です。
まずは上のチェック基準作成部から作っていきましょう。
1周目:チェック基準を生成して会話変数に保存する
Difyの開発画面から「最初から作成」を選択。アプリタイプは「チャットフロー」、アプリ名は「ミスチェッカー」としましょう。

今回は、必要となるノードを先に全て配置してしまいましょう。
細かい設定は置いておいて、左から順に以下のようにノードを配置してください。
[ユーザー入力] → [IF/ELSE] → [回答(IF側)] → [テキスト抽出(ELSE側)] → [LLM] → [変数代入] → [回答]

続いて、各ノードの設定を入れていきます。
1.ユーザー入力:ファイルアップロード設定
資料をアップロードできるよう、入力フィールドを1つ追加します。

- フィールドタイプ:単一ファイル
- 変数名:file
- ラベル名:ファイル
- ファイルタイプ:ドキュメント
- 必須:チェックを外す
2.IF/ELSE:ファイル有無の分岐
ユーザーが正しくファイルをアップロードしたかをチェックします。

- 名称を「IF/ELSE(ファイルがあるか)」に変更。
- 条件に「ユーザー入力ノードの変数file」が「存在しません」を追加
3.回答:ファイル未指定時のメッセージ
ユーザーが正しくファイルをアップロードしなかった場合、そのことを表示します。

- 名称を「回答(ファイルなし)」に変更
- 応答に「チェックするファイルがみつかりません」と書き込む
4.テキスト抽出:アップロード資料から本文を取得
アップロードされた資料からテキストを抽出し、後続のLLMに渡します。

- 入力変数:ユーザー入力ノードの変数file
5.LLMチェック基準を生成
名称を「LLM(チェック基準作成)」に変更し、プロンプトを書き込む。
- プロンプト(クリックして開く)
-
あなたは、アップロード資料(PDF/Word/Excel/CSV/テキスト等)からミスを見つけるための「チェック基準」を設計する専門家です。 ファイル情報と資料テキストを確認し、重要な確認項目を“3つだけ”選んでユーザーに提示してください。 # ファイル情報 - ファイル名/拡張子: ☆☆☆ ユーザー入力ノードのfile.name変数 ☆☆☆ - MIME: ☆☆☆ ユーザー入力ノードのfile.mime_type変数 ☆☆☆ # 資料テキスト(抽出) ☆☆☆ テキスト抽出ノードのtext変数 ☆☆☆ # 候補となるチェック観点(この中から選ぶ) A. 誤字脱字・変換ミス B. 空欄/未記入/未確定(TBD、未定、XXX、— など) C. 重複(同一行、同一ID、同一内容の繰り返し) D. 矛盾/整合性(合計と内訳、条件の不一致、日付の前後関係、数値の食い違い) E. 形式/体裁(見出し階層、番号、参照の欠落、表の列ずれ) F. 表記ゆれ(用語、全角半角、単位、日付表記、記号、スペース) G. 不自然値(ゼロ、負数、桁違い、範囲外、異常に大きい/小さい) H. 表現品質(曖昧語、主語不明、二重否定、指示語だらけ) I. 参照整合(図表番号、リンク、引用、参照先の不足/不一致) J. 機密/個人情報の混入(必要な場合のみ。断定せず要確認) # 選定ルール(厳守) - まず資料のタイプを1つ推定する(例:名簿、議事録、仕様書、請求書、マニュアル等) - 上の候補から、資料タイプに対して重要度が高い順に“3つだけ”選ぶ - 各項目は短く、例は各1つまで(資料テキストに寄せた例にする) - 出力はユーザー向けの本文のみ(前置き・説明は禁止) # 出力形式(この通り) (推定した資料タイプ:○○) 以下の3点でチェックします。よろしいですか? 1) 〔観点名〕(例:…) 2) 〔観点名〕(例:…) 3) 〔観点名〕(例:…) → この3点で進めて良いですか?追加したい観点があればチャットに書き込んでください。なければ「OK」等と書き込んでください。

いつも通り、プロンプト内の変数だけはコピペじゃなく自分で指定してね。
6.会話変数の設定
ここで、ノードの設定を一時中断し、このアプリ全体で使える会話変数の設定を行います。

画面右上の「公開する」の左側にある、「吹き出しからxがはみ出ているアイコン」をクリックすると、会話変数の設定画面が開きます。

「変数を追加」をクリックし、変数file_dataを追加。
この変数には後でテキスト抽出した結果を代入します。

「変数を追加」をクリックし、変数criteriaを追加。
この変数には後でLLMが作ったチェック基準を代入します。
7.変数代入ノード
ここで、先ほど追加した会話変数に値を代入します。

- 変数を2つ追加する
- 変数criteriaにLLMの出力変数textを代入
- 変数file_dataにテキスト抽出ノードの出力変数textを代入
この変数は、アプリが一度動いて結果を表示した後もデータを保持し、次のユーザー入力(次のメッセージ)時にも活用できます。
8.回答:生成したチェック基準の確認を促す

- 名称を「回答(チェック基準確認)」に変更
- 「以下の基準でチェックします。よろしいですか?」と書き込む
- 会話変数criteriaを指定
これでこのアプリの前半部分は完成です。実際に公開して動かしてみましょう。
何か適当なファイルをアップロードし、「チェックして」などと書き込んで起動、資料に応じたミスチェック基準を作成するか確認してください。
2周目::基準を更新し、ミスチェック結果を出力する
続いてアプリの後半部分を作成します。
先ほど作ったアプリの先頭部分の、ユーザー入力とIF/ELSEの間を切断し、そこに別のIF/ELSEを追加してください。
その後、以下のようにノードを配置していきましょう。
[ユーザー入力] → [IF/ELSE(追加)] → [IF/ELSE(前半で作った部分)] → ... → [LLM] → [変数代入] → [LLM] → [回答]

1.IF/ELSE:criteriaが空かで「基準作成/チェック」分岐
判断基準がすでにあるか(変数criteriaにデータが入っているか)をチェックし、これからチェック基準を作るのか、基準をもとにチェックをするのかを判断します。

- 名称を「IF/ELSE(チェック基準があるか)」に変更
- 条件に「変数criteria」が「空」を追加
2.LLM:ユーザー指示でチェック基準を更新
1周目で作られたチェック基準を、ユーザーのコメントをもとに修正します。
- プロンプト(クリックして開く)
-
あなたは、資料のミス検出のための「チェック基準」を編集する専門家です。 既存のチェック基準を、ユーザー指示に従って更新してください。 # 既存のチェック基準 ☆☆☆ 会話変数criteria ☆☆☆ # ユーザー指示 ☆☆☆ ユーザー入力のquery変数 ☆☆☆ # 編集ルール(厳守) - ユーザー指示が「それでいい」「OK」「このままで」等の“承認のみ”なら、基準は一切変更せず、そのまま返す - 「○○についても見て」「○○も追加」なら、その観点を追加する(重複する場合は統合) - 「○○は不要」「○○は見なくていい」なら、その観点を削除する - 指示が曖昧な場合は、基準は極力いじらず、既存を維持しつつ最小限の追記にとどめる - 出力は“更新後のチェック基準”だけ(質問・補足・前置きは禁止)

プロンプト内の変数はコピペしないでね。
3.変数代入:criteriaを上書き
ユーザーのコメントをもとに修正したチェック基準を会話変数criteriaに上書きします。

- 名称を「変数代入(基準の更新)」に変更
- 変数criteriaにLLMの出力変数textを上書き
4.LLM:基準×抽出テキストでミスを検出
完成したチェック基準を使って、資料のチェックを行います。
- プロンプト(クリックして開く)
-
あなたは資料内のミス(誤字脱字、表記ゆれ、形式不備、欠損、重複、不自然値など)を発見する専門家です。 以下の「チェック基準」に従い、「資料テキスト」からミスを探してください。 # チェック基準 ☆☆☆ 会話変数criteria ☆☆☆ # 資料テキスト ☆☆☆ 会話変数file_data ☆☆☆ # 実行ルール(厳守) - 資料テキストに存在する情報だけを根拠に指摘する(推測で断定しない) - 指摘には必ず“根拠(該当箇所)”を短く引用して示す(20〜60文字程度) - 行番号やシート名が分からない場合は「列名(分かる範囲)」「該当値」「周辺の文/行」で場所が特定できる形にする - 判定が難しいものは「要確認」と明記する - 重要度が高いものから最大10件まで(小さな表記ゆれだけで埋めない) # 出力形式 ## 概要 - 検出件数(目安):◯件 - 主な種類:◯◯、◯◯、◯◯ ## 指摘(重要度順) 1. [重要度:高/中/低] 種類(例:表記ゆれ/形式不備/欠損/重複/不自然値) - 場所:列名/項目名(分かる範囲) - 根拠:"...(該当箇所)..." - 問題点: - 修正案: - 判定:確実 / 要確認 ## 追加で有効なチェック提案(任意・最大3つ) - (資料の内容に即したものだけ)

プロンプト内の変数は(略)
5.回答ノード:最終結果を表示
最後に回答ノードにてチェック結果を出力します。

- 名称を「回答(最終回答)」に変更
- 応答に「LLMの出力変数text」を設定
これでアプリは完成です。
公開して実行し、意図通りに動くか確認してください。
まとめ
この記事では、資料のミスチェックアプリを題材にしながら「会話が続く前提のDifyアプリ」を作るための基本を押さえました。
ポイントは、チェック基準や抽出テキストのような “作業の前提” を会話変数に保持し、必要なタイミングで変数代入ノードを使って更新していくことです。
この2つが使えるようになると、単発で完結するアプリから一歩進んで、ユーザーの指示に合わせて状態を更新しながら動くアプリを作れるようになります。
今後もこの考え方は頻繁に出てくるので、今回の構成をベースとして「どの情報を会話に残すか」を意識しながら開発していきましょう。
- 記事改善アンケート|ご意見をお聞かせください(1分で終わります)
-
本サイトでは、みなさまの学習をよりサポートできるサービスを目指しております。
そのため、みなさまの意見をアンケート形式でお伺いしています。1分だけ、ご協力いただけますと幸いです。
(※)APIキーや個人情報等は入力しないようお願いします。
【Dify】記事改善アンケート


