対話で情報を集め、その結果から文書を作るAI機能をDifyで設計するとき、チャット画面の有無だけでアプリタイプを選ぶと、会話の途中経過と業務の確定状態を混ぜやすくなります。

選ぶ前に決めたいのは、何を入力として固定し、どの状態を引き継ぎ、どこまでを成功と扱うかという実行契約です。本稿では、会話による情報収集と、確定入力からの文書生成を分ける設計を例にします。

確認日：2026年10月3日。公式資料に基づく設計案であり、Dify上の実行・負荷試験・本番運用は未検証です。工数削減や精度改善の実測値はありません。

従来の5分類を、そのまま選定の答えにしない

公式のKey Conceptsは、WorkflowとChatflowを主要・推奨タイプとし、Chatbot、Agent、Text Generatorを基本タイプとして説明しています。一方、現在のAPI資料には、新しいAgentのagentとLegacy Agentのagent-chatが別にあります。「Agent」という名前だけでは実行方式が確定しません。Agent API

下表の採用判断は、公式の機能説明を踏まえた本稿の設計判断です。

従来の分類	処理を考える軸	今回の採用判断
Chatbot	シンプルな対話	会話中の検証・分岐を明示したいので、Chatflowを選ぶ
Agent（Legacy）	LLMによるツール選択	手順が決まっている処理には、動的選択を持ち込まない
Text Generator	独立した入力から文章を生成	一段の生成なら候補。検証・差し戻しを組む今回はWorkflowを選ぶ
Chatflow	複数ターンの対話とフロー	聞き取りと下書きの提示を担当させる
Workflow	入力から結果を返すタスク	確定入力からの生成・検証を担当させる

Text Generatorは呼出し間の会話状態を引き継がないことがCompletion App APIで説明されています。Chatflowでは会話変数を使えますが、会話変数を業務記録の正本にするかどうかは、別の設計判断です。

新しいAgentやAgentノードの採用を検討する場合も、アプリ全体の実行方式と、フロー内の一工程に自律性を与えることを分けます。公式のAgentノード資料ではClassicとNewを分けて説明しているため、使う環境のバージョン・機能・APIを先に確認します。

制約から、会話と確定タスクの責務を分ける

想定する機能は「利用者が対話で要件を整理し、確定した入力から社内向け文書を作る」です。以下はこの例の要件であり、Difyの標準保証ではありません。

聞き取り中は訂正できる。訂正前の値で確定処理を進めない。
生成結果には必須項目を要求する。欠落した文章を成功として保存しない。
外部への送信や業務データ更新は、生成処理から分離する。
接続が切れたとき、完了した処理と結果不明の処理を区別できる。

一つのChatflowで全体を組む案は、アプリ数と接続部分を減らせます。会話だけで完結する機能なら有力です。ただし、確定後の処理をバッチや別画面から再利用したい場合、会話状態への依存が扱いづらくなります。

逆に、最初からWorkflowだけにすると実行ごとの入力は揃えやすくなりますが、聞き返しや訂正のUIを別に作る必要があります。

今回は、Chatflowで情報を集め、バックエンドで確定入力を保存し、Workflowへ渡す案を選びます。接続部分は増えるものの、再実行する入力と検証条件を固定できるためです。以下はアプリ独自の構成案であり、Difyが自動で二つのアプリを接続するという意味ではありません。

Agentを採らない理由は、生成・必須項目検査・結果返却の手順が決まっているからです。調査中に次の検索先を選ぶ必要が生じたら、その工程だけに、読み取り用ツールと探索上限を持つAgentノードを検討します。これは将来の選択肢であり、動作確認済みの構成ではありません。

実装では、会話IDと業務タスクIDを別に扱う

Chatflowは会話の各ターンで起動し、会話変数を保持・更新できます。Workflowは単発タスクを扱うタイプです。Key Concepts

この違いを実装へ落とす際には、会話IDを文書生成タスクの識別子に流用しません。同じ会話から、入力を変更して複数の文書を生成する可能性があるからです。

たとえば、バックエンドに次の入力記録を保存します。Dify DSLやService APIのリクエスト形式ではなく、アプリ独自の保存形式の例です。識別子と本文は説明用の架空値です。

{
  "task_id": "demo-document-001",
  "input_revision": 1,
  "contract_version": "document-v1",
  "confirmed_input": {
    "purpose": "製品仕様の説明文を作る",
    "audience": "技術担当者"
  },
  "required_output_fields": ["summary", "limitations"],
  "state": "pending"
}

実装する境界は次のとおりです。

バックエンド入口：認証済み利用者の権限を確認し、入力の型・長さ・必須項目を検証する。
Chatflow：不足情報の聞き取りと下書き提示を行う。利用者の確定操作で、バックエンドが入力を保存する。
Workflow：保存した入力を渡し、生成結果の必須項目をCode／If-Elseなどで検査する。不正な出力は成功経路に流さない。
結果保存：タスクID、入力の版、利用したアプリ設定の版、取得できた実行ID、結果状態を関連付ける。

型が合っていることと、文書の内容が正しいことは別です。必須項目検査に加え、用途に応じて根拠の確認や人のレビューを加えます。LLM自身の「正しい」という回答だけを通過条件にしません。

APIキーはブラウザへ配布せず、バックエンドに置きます。これは公式APIガイドの方針です。またDifyはuser値そのものを認証しないため、利用者が送った値をそのまま信用せず、バックエンドの認証結果から安定した識別子を設定します。End User Identity

再試行より先に、残る状態を定義する

以下の状態名はアプリ独自の定義です。Difyの実行状態とは別に保存します。

状態	保存する意味	次の動作
`pending`	入力は確定したが、実行開始前	実行権を取得した処理だけが開始
`running`	実行中	同じタスクへの二重起動を防ぐ
`succeeded`	完了を確認し、出力検証と保存も成功	保存済み結果を返す
`rejected`	出力の品質検証に不合格	理由を保存し、修正か人の確認へ
`unknown`	通信断などで完了を確定できない	実行IDや外部操作の記録を照合
`cancelled`	中止を確認した	確定済みの副作用があれば別途照合

runningへの変更は、DBの条件付き更新などで一つの処理だけが取得します。Difyからの完了と保存の間にも障害が起こるので、保存失敗を生成失敗に置き換えず、照合対象として残します。

公式資料では、ストリーム開始後のエラーはHTTP 200のままerrorイベントとして届くと説明されています。したがってHTTP 200、最初の文字列、正常終了を同じ成功条件にしない設計が必要です。Handle Errors and Rate Limits

同資料は一時的な並行数制限とクォータ超過も区別しています。前者は上限付きのバックオフ候補、後者は設定・利用枠の確認対象です。ネットワーク失敗時も、生成のみの再試行と、書き込みを伴う処理の再試行を分けます。

外部操作を加えるなら、操作単位の重複防止キー、操作内容の版、承認記録、実行結果を別に保持します。承認後に内容を変えたら再承認が必要です。停止要求を送ったことは、既に成立した外部操作の取消しを意味しません。

本番化前に確認する失敗パターン

失敗のきっかけ	期待する動作	検証対象
会話中に用途を訂正	確定入力へ訂正後の値だけを採用	保存した入力の版とWorkflowへ渡す値
必須項目が空／出力形式が不正	開始前または出力検査で止める	成功結果や外部操作が作られないこと
他の利用者の会話IDを指定	バックエンドで拒否	認可と情報の分離
ストリーム途中にエラー	成功にしない	最終イベントと保存状態
同じ確定操作を同時に送る	同じタスクの二重起動を防ぐ	DBの競合と呼出し回数
接続切断後に再送	結果照合を先に行う	`unknown`からの復旧手順
人の確認が期限切れ	外部操作を保留する	期限・内容の版・操作記録

これらは未実施の受入条件です。モックで状態遷移を確認するだけでなく、使用するDify環境で、会話の分離、エラーイベント、停止、タイムアウトを確認する必要があります。

分割の代償は、アプリ間の受け渡し、設定の版管理、結果保存を自分で持つことです。短い会話だけで完結するなら、一つのChatflowに収める方が保守しやすい場合もあります。再利用・再実行・監査が必要かを、分割の判断材料にします。

改善は、観測できる失敗から始める

初期の監視項目は、生成時間、トークン利用量、品質不合格率、unknownの件数と滞留時間、人の確認待ち時間です。ログにはタスクID・入力の版・実行段階・エラー分類を残し、入力全文や認証情報を無条件で保存しません。

採用判断を再評価するため、最低限、次を確認します。

使うDify環境のバージョン、アプリのmode、対応APIを記録する
同じ評価入力で、分割構成と一体構成の品質・遅延・費用を比較する
実行回数だけでなく、検証を通過して完了したタスク当たりの費用を見る
会話の訂正・接続断・二重操作を含む受入条件を実環境で検証する

業務上の効果は、文章が速く出ることに加えて、再実行対象と人が確認すべき対象を識別できることです。ただし、その効果は設計上の狙いです。削減工数や費用対効果は、確認・復旧の時間と利用費用を含めて測定するまで確定できません。

参考リンク

同様の仕組みの設計・構築・運用については相談可能。

この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。