Difyでチャット画面を公開すると、会話履歴やフォローアップ提案まで含んだ使いやすいWebアプリをすぐ出せます。一方で、ワークフローが長いと回答待ちの数秒〜数十秒が不安になり、離脱や再送信が起きやすくなります。2026年4月29日時点の公式ドキュメントでは、進捗バーを直接ONにする設定は確認できませんでしたが、show_workflow_steps と streamingイベントを使えば、待機中の見せ方は十分改善できます。
なぜDifyの応答待ちで離脱が起きるのか？
Dify公式のChat Web Appsは会話履歴を保持し、会話スターターや次の質問候補、フィードバック、音声入力、引用表示などを自動で備えます。つまり土台のUXは強いのですが、社内向けチャットやPoCでは『今なにをしているか分からない』時間が残りやすいです。特にナレッジ検索→ツール実行→要約のように複数ノードを通る構成では、ユーザー視点では無反応に見え、二重送信や離脱、「壊れているのでは」という問い合わせにつながります。
実務では、待機時間そのものをゼロにするより、状態を見せるほうが改善効果が大きいです。たとえば『質問を解析中』『社内ドキュメントを検索中』『回答を整形中』の3段階だけでも表示すると、同じ8秒でも体感待ち時間が短くなります。これはAIアプリの品質というより、期待値コントロールの設計です。
Dify公式で確認できる進捗表示の材料は何か？
今回の実装判断で確認した公式ソースは3つです。1つ目はDifyのPublish系ドキュメントで、Chat Web Appsは公開するとそのままWebアプリ化され、サイトへの埋め込みもchat bubbleやiframeで行えること。2つ目はWebApp Settings APIで、show_workflow_steps という設定項目があること。3つ目はSend Chat Message APIで、streamingモード時に workflow_started / node_started / node_finished / workflow_finished などのイベントが返ることです。
この3点から分かるのは、ワークフローの進行を外部UIへ伝える公式手段がある一方、パーセンテージ付きの進捗バーを標準UIで細かく制御する専用設定は、少なくとも公開ドキュメント上では見当たらないということです。したがって実装方針は、①標準WebAppの範囲で見せ方を整える、または②API経由のカスタムUIで進捗バーを自作する、の2択になります。
自社向けAIチャットをPoC止まりで終わらせず、実運用できるUXまで設計したい場合は、 AI・Claude研修や開発相談はこちら 。ユースケースに合わせてDify実装も整理できます。
最短で改善する方法は？ show_workflow_steps をまず試す
標準のWebAppをそのまま使うなら、まずは show_workflow_steps を有効にして、ワークフローの段階表示を見せるのが最短です。厳密な進捗率ではありませんが、『処理中』の一枚板よりも安心感があり、実装コストも低いです。あわせて会話スターターや事前フォームの文言を調整し、『通常5〜15秒で回答します』『検索と要約を順番に実行します』のように期待値を先に伝えると、離脱率が下がりやすくなります。
この方法が向くのは、社内FAQ、ナレッジ検索、一次回答ボットのように、まずは早く公開したいケースです。iframe埋め込みでも同じWebAppを再利用できるので、既存サイトに置く場合も運用が簡単です。一方で、ノード数が多い業務フローやファイル解析のように待機が長いケースでは、『今どこまで進んだか』をもっと細かく見せたくなるため、次のカスタム実装が候補になります。
進捗バーを自作するには？ streamingイベントをUIに変換する
カスタム実装では、DifyのSend Chat Message APIを response_mode=streaming で呼び、返ってくるSSEイベントをフロントエンドで受け取ります。実装の基本はシンプルで、workflow_started で0〜10%、node_started で現在ノード名を表示、node_finished ごとに進捗を更新し、workflow_finished で100%にする流れです。ノードが4個なら 10→35→60→85→100 のように割り当てるだけでも十分に『進んでいる感』が出ます。
ポイントは、実時間の正確さより、状態の一貫性を優先することです。毎回秒数を予測しようとするとブレが大きくなります。代わりに『入力確認』『検索』『生成』『整形』のような段階固定にすると、ユーザーは安心しやすく、開発側も保守しやすいです。さらに、3秒を超えたら補足文を出す、15秒を超えたら『処理を継続しています』へ切り替える、といったルールを加えると、長文回答や外部API連携でも不安を抑えられます。
実装例としては、ReactやNext.jsのチャット画面でSSEを購読し、progress stateとcurrentStep stateを持たせます。見た目は横棒1本で十分ですが、ステップ名を併記すると効果が上がります。もし業務で承認フローやHuman Inputを使うなら、Difyの関連APIで workflow_paused や human_input_required も拾えるため、『担当者の確認待ち』まで自然に表現できます。
FAQ：どこまで作り込めば十分か？
よくある判断基準は3つです。1つ目、回答が5秒未満なら show_workflow_steps と待機文言の調整で十分。2つ目、5〜20秒ならSSEを使った簡易進捗バーが有効。3つ目、20秒超や承認待ちを含む場合は、進捗バーだけでなく『後で通知する』『別タスクとして処理中』という状態分離まで考えるべきです。最初から完璧なUIを作る必要はなく、再送信率・離脱率・問い合わせ数が減るかで判断すると失敗しにくいです。
つまり、Difyでプログレスバーを表示したいときの本質は、バー自体ではなく待ち時間を意味のある状態に翻訳することです。標準WebAppで早く始めるか、streamingイベントで自作するかを、待機時間と運用要件で選べば十分です。
Difyを使った社内AIチャットや業務エージェントの設計・実装・研修までまとめて進めたい方は、 お問い合わせフォームからご相談ください 。要件整理からUX改善まで伴走できます。