対話で情報を集め、その結果から文書を作る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を記録する - 同じ評価入力で、分割構成と一体構成の品質・遅延・費用を比較する
- 実行回数だけでなく、検証を通過して完了したタスク当たりの費用を見る
- 会話の訂正・接続断・二重操作を含む受入条件を実環境で検証する
業務上の効果は、文章が速く出ることに加えて、再実行対象と人が確認すべき対象を識別できることです。ただし、その効果は設計上の狙いです。削減工数や費用対効果は、確認・復旧の時間と利用費用を含めて測定するまで確定できません。
参考リンク
- Dify Key Concepts
- Chatbot and Legacy Agent API
- Text Generator API
- Agent API
- Agentノード
- Get Started with the Dify API
- End User Identity
- Handle Errors and Rate Limits
同様の仕組みの設計・構築・運用については相談可能。
この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。