Difyでチャットアプリを公開すると、会話スターターや引用表示を備えた画面をすぐ配布できます。一方で、検索や外部ツールをまたぐワークフローは数秒から数十秒の待ち時間が発生しやすく、2026年6月時点でも「何も起きていないように見える」瞬間が離脱原因になりがちです。この記事では、2026年6月時点のDify公式ドキュメントを前提に、標準機能でどこまで改善できるか、必要ならどこからカスタム実装に進むべきかを整理します。
なぜDifyの応答待ちで離脱が起きるのか？
DifyのWeb Appは公開直後から会話履歴、候補質問、音声入力、引用リンクなどをまとめて提供できます。土台のUXは強いのですが、ユーザーが不安になるのは回答品質より「待ち時間の意味が見えない」ことです。特にナレッジ検索、外部API、整形処理を順番に通すチャットフローでは、同じ8秒でも無反応に見えると再送信や離脱が増えます。
実務では待ち時間をゼロにするより、「質問を解析中」「社内情報を検索中」「回答を整形中」のように状態を見せる方が効果的です。応答速度を少し改善するだけより、状態の透明性を上げる方がPoCから本番運用へ移るときに再現しやすい改善になります。
2026年6月時点のDify公式で確認できる進捗表示の材料は何か？
2026年6月25日に更新されたDifyのGet App WebApp Settingsでは、WebApp設定に `show_workflow_steps` があり、ワークフロー手順の表示有無を制御できることが明記されています。また、Workflow Web Appsの説明では、公開したアプリはリアルタイムの処理フィードバックを持つと案内されています。つまり、標準UIでも「処理中の段階表示」を見せるための公式オプションは存在します。
さらに2026年6月時点のSend Chat Message APIでは、SSEで返すストリームを前提に設計されており、少なくとも `message` や `message_end` を軸にチャットの進行を受け取れます。関連するDify APIリファレンスでは `workflow_started` `node_started` `node_finished` `workflow_finished` のイベント系列も案内されており、カスタムUI側で「いま何段階目か」を組み立てる材料は揃っています。
Difyを使った社内AIチャットをPoC止まりで終わらせず、実運用できるUXまで設計したい場合は、HelloCraftAIへご相談ください。
最短で改善する方法は？ `show_workflow_steps` をまず試す
標準のWebAppをそのまま使うなら、最初の打ち手は `show_workflow_steps` を有効にすることです。厳密なパーセンテージ表示ではありませんが、「処理中」の一枚表示より安心感が高く、Dify標準の公開導線を崩さずに済みます。あわせて開始前の説明文で「通常5〜15秒」「検索と要約を順に実行」など期待値を伝えると、問い合わせや二重送信をかなり減らせます。
この方法が向くのは、FAQボット、社内ナレッジ検索、一次受付など、まず早く公開したい案件です。iframe埋め込みでも同じWebAppを再利用できるので、既存サイトに載せるだけの案件なら標準機能の範囲で十分なことも多いです。
進捗バーを自作するには？ SSEイベントをUIに変換する
待機時間が長い業務フローや、ユーザーに段階を明示したいチャットでは、Send Chat Message APIを `response_mode=streaming` で呼び出し、返ってきたイベントをフロントエンドで進捗表示に変換するのが現実的です。たとえば開始時を10%、主要ノードごとに35%、60%、85%と進め、完了で100%にするだけでも「止まっていない」ことを伝えられます。
ポイントは、秒数を正確に予測するより状態の一貫性を優先することです。毎回の処理時間はブレますが、「入力確認」「検索」「生成」「整形」のように固定ステップへ落とせば、ユーザーは安心しやすく、開発側も保守しやすいです。ヒューマンインプットを含む設計なら、確認待ちの状態まで別メッセージとして見せる方が親切です。
FAQ：どこまで作り込めば十分か？
目安は3段階です。5秒未満なら `show_workflow_steps` と事前文言だけで十分です。5〜20秒ならSSEを使った簡易バーやステップ名表示が効きます。20秒を超える処理や承認待ちを含むなら、進捗バーだけでなく「後で通知」「別タスクとして継続中」といった状態分離まで設計するべきです。進捗バーの目的は装飾ではなく、待ち時間を意味のある状態に翻訳することだと考えると判断しやすくなります。
