Difyコミュニティ版のCELERY_AUTO_SCALE設定について🤖
こんにちは。バイタリフィ大阪営業所でディレクターをしている横田です。
2025年も後半に入り、会社全体で、Dify関連の案件がどんどん増えてきました。私自身も2025年の後半から本格的にDify案件の構築に携わっており、毎日新しい発見と格闘の日々、、
今回は、クライアントが作成したDifyアプリをオリジナルUIで出力するという案件で、なかなか情報が出回っていないDify オリジナルUI エラー対策について、試行錯誤の末に見つけた解決策をご紹介します。
今回のプロジェクト概要 ― Dify×オリジナルUIの案件
今回の案件は、クライアント側でDifyを使って構築されたAIチャットアプリを、オリジナルUIでエンドユーザーに提供するという内容。
私は、Dify APIをUIにうまく組み込むための全体設計、進行管理を担当しています。
Dify自体が提供するWebUIはとても優秀。
ただ、クライアントのブランディングやUX要件に合わせようとすると、どうしてもオリジナルUIが必要になるケースもあります。
※DifyのWebUIはカスタマイズの自由度がそれなりにあるものの、細かい挙動までコントロールしたい場合はAPI連携が必須になってきます。
実装で苦労した3つのポイント
1. 音声認識の実装
まず最初につまずいたのが音声認識機能。DifyのAPIで音声入力を受け付ける際、フロントエンドから送信する音声データのフォーマット・サンプリングレート・エンコーディングの組み合わせを適切に設定しないと、認識精度が大きく落ちちゃいました；
特にブラウザ間での挙動差（Chrome、Safari、Firefoxで微妙に違う、、）に対応するための抽象化レイヤーを自前で作る必要があり、想定より工数がかかることに。
2. ファイル添付処理
次に苦労したのがファイル添付処理。Dify側で受け付けるファイル形式・サイズ制限に加えて、オリジナルUI側でのアップロード進捗表示や、Dify側の処理状況をユーザーに見せるためのステータス管理が思ったよりも複雑でした。
「ユーザーにどこまで裏側の処理を見せるか」というUX観点と、「実際のAPIレスポンスのタイミング」のすり合わせで議論を重ねました、、
3. 🔥最大の難題：アプリ側エラーハンドリング
そして、一番厄介だったのが今回のメインテーマであるアプリ側エラー時のエラーハンドリング。
オリジナルUIの立場からするとDify内部のエラーは完全にブラックボックスで、UI側には「500エラー」や「タイムアウト」しか返ってこないことが何度かあり、、
今回は、Issue #21767にて報告されている「Workflow Structured output Failed to parse structured output」で処理がとまってしまうケースがありました。
💡Dify-オリジナルUIのエラー対策で処理を止めない方法
ここからが今回のメインテーマ。様々なログ解析と設定変更を試した結果、Difyパッケージ版（セルフホスト版）の設定を一箇所変更するだけで、エラー時でもシステム全体が止まらない運用ができることが分かりました、、！
作業時間はわずか10〜15分ですが、効果は想像以上。
変更内容
各Difyインスタンスの docker/.env に以下の3行を追記するだけ。
CELERY_AUTO_SCALE=true
CELERY_MAX_WORKERS=4〜8
CELERY_MIN_WORKERS=1〜2これはDifyがバックエンドで使っているCelery（非同期タスクキュー）のオートスケール設定を有効化するもの。
デフォルトではオートスケールがオフになっているため、一つのワーカーが長時間のエラー処理で詰まると、後続のタスクも全部詰まってしまう状態になりがち。
設定を有効化すると、負荷に応じてワーカーが自動で1〜8個の範囲でスケールし、エラー処理で詰まったワーカーがあっても、別のワーカーが後続タスクを処理し続けてくれます、、！
CELERY_AUTO_SCALE設定のメリット・デメリット
Celeryの公式ドキュメントとDify公式のソースコードを調べて、この設定の効果を整理してみました。
メリット
- 負荷に応じて自動でワーカー数を調整
タスクがキューに溜まってきたら自動で最大8ワーカーまで増やし、暇な時間は2ワーカーまで減らしてリソースを節約してくれるのが◎ - エラー処理による詰まりを回避
あるワーカーがエラー処理で時間を食っても、別のワーカーが後続タスクを処理してくれるため、全体が止まる事象を大幅に減らせます。 - 段階的なスケーリングで安定
Celeryのオートスケーラは「1ワーカーずつ増減する保守的な設計」になっているため、急激な負荷変動でシステムが不安定になりにくい印象。 - リソース効率の向上
常時最大ワーカーで動かすよりもメモリ・CPU使用量が最適化されます。クラウドコストの面でも嬉しいポイント。
デメリット・注意点
- 上限値の設定ミスでリソース枯渇
CELERY_MAX_WORKERSを大きくしすぎるとCPUやメモリを食いつくしてサーバーがダウンするリスクがあるので要注意、、 - アプリケーション特性によっては効果が限定的
全タスクが同時に重い処理を行うケースでは、オートスケールの恩恵が少ないことも。 - ワーカー数の最適値はチューニングが必要
サーバースペック・タスクの性質によって最適値が変わるため、本番環境での計測と調整が前提。 - 短時間タスクの連続バーストでは追いつかない場合も
オートスケーラは保守的な設計なので、瞬間的な大量リクエストには対応が遅れることも、、
私たちの案件では、8ワーカー・2ワーカーの組み合わせがチャットボット用途としてちょうど良いバランスでした。※もちろん案件ごとに最適値は変わるので、負荷試験を行った上で調整することをおすすめします。
まとめ
Difyは触れば触るほど奥が深いツールだと感じている今日この頃。
公式情報だけではなかなか出てこない運用知見が多くあり、エラー処理ひとつを取っても複数のレイヤー（Dify本体、LLMプロバイダ、インフラ構成、フロントエンドUI）を横断して考える必要があります。
ただ、最近はClaudeをはじめとしたLLM自身の進化もあり、「こういう設定を変えたいんだけど」と相談すればかなり的確な回答が得られるようになってきた印象で、一人のディレクターでも以前より多くの検証ができるようになったと感じています。
これからも色々試して、クライアントに新しいAIサービスの可能性を提案していこうと思います。同じようにDify×オリジナルUIで悩まれている方の参考になれば幸いです、、！
参考リンク
- Environment Variables – Dify Docs（Dify公式ドキュメント）
- dify/docker/.env.example（GitHub公式リポジトリ）
- Structured Output Parsing Fails in Dify 1.5.1 – Critical Regression（GitHub Issue #21898）
- Workflow Structured output Failed to parse structured output（GitHub Issue #21767）
- Workers Guide（Celery公式ドキュメント）
株式会社バイタリフィでは、DifyをはじめとしたAIエージェント開発・オリジナルUI構築のご相談を積極的にお受けしています。「こんなAIアプリを作ってみたい」「既存のDifyワークフローをもっと使いやすいUIで提供したい」など、お気軽にお問い合わせください。
ご購読ありがとうございました！
