Difyでファイルアップロードが「キューイング中」のまま進まない原因は何ですか

主な原因は3つ。Celery Workerがpriority_pipelineキューに接続されていない設定不備、Embedding APIのレート制限到達、50ファイル以上の同時アップロードによるUIフリーズです。

Difyのキューイング問題を解決するにはどうすればよいですか

docker-compose.yamlでCELERY_QUEUESに全キューを設定し、RedisとベクトルDBの稼働を確認します。大量ファイルの場合は50ファイル未満に分割するか、Knowledge APIでバッチ処理を行います。

Difyで大量のファイルを一括アップロードする方法はありますか

Knowledge APIを使ったバッチ処理が推奨されます。APIエンドポイントにファイルを1つずつPOSTし、間隔を空けて順次処理することでキューイング停止を回避できます。

Difyのキューイング問題はどのバージョンで発生しますか

v0.12.1やv1.9.2で報告されています。GitHub Issue #31932、#27473、#26211などで複数のユーザーが同様の問題を報告しており、バージョンをまたいで発生する既知の問題です。

Dify ファイルアップロードが「キューイング中」で止まる原因3つと解決策【大量ファイルのリセット対応】

Difyのファイルアップロードが「キューイング中」で止まる問題とは

Difyのナレッジベース機能でファイルをアップロードすると、ステータスが「キューイング中（Queuing）」のまま一向に処理が進まない。この問題はGitHub上で複数のIssueが報告されており（#31932、#27473、#26211など）、Dify v0.12.1からv1.9.2まで幅広いバージョンで確認されている既知の問題だ。

ナレッジベースはDifyのRAGパイプラインの中核を担う。ここにファイルを登録できなければ、チャットボットやワークフローにコンテキストを供給できない。本記事では、キューイング停止の3つの主要原因と、それぞれの具体的な解決手順を解説する。

RAGパイプライン構築の選択肢として、RAGFlowのエンタープライズ向けRAGエンジンも参考になる。

原因の切り分けとCelery Workerのキュー設定不備を修正する

問題が発生したとき、まず何を確認すべきか。以下のフロー図で原因を特定する。

flowchart TD A["ファイルアップロードが
キューイング中で停止"] --> B{"Redisは
稼働しているか"} B -->|No| C["Redisコンテナを
再起動"] B -->|Yes| D{"Celery Workerの
ログにエラーは
あるか"} D -->|キュー未接続| E["CELERY_QUEUES
設定を修正"] D -->|レート制限エラー| F["Embedding API
のレート制限を確認"] D -->|エラーなし| G{"アップロード
ファイル数は
50以上か"} G -->|Yes| H["50ファイル未満に
分割 or
Knowledge API使用"] G -->|No| I["ベクトルDBの
稼働状態を確認"]

最も多い原因がCelery Workerのキュー設定不備だ。

Difyの内部アーキテクチャでは、ファイルのアップロード処理はCeleryタスクキューを経由して非同期に実行される。Celery Workerが priority_pipeline キューを監視していない場合、タスクがキューに投入されても処理されず「キューイング中」のまま停止する。

Celery Workerのログを確認する

まず、Workerが正しいキューに接続しているかログで確認する。

# Celery Workerコンテナのログを確認
docker compose logs worker --tail=100

# 特定のキーワードでフィルタリング
docker compose logs worker --tail=200 | grep -E "queue|priority_pipeline|error"

ログに priority_pipeline キューへの接続が表示されていない場合、設定の修正が必要だ。

docker-compose.yamlでCELERY_QUEUESを設定する

docker-compose.yaml のworkerサービスに、全キューを明示的に指定する。

# docker-compose.yaml（workerサービスの環境変数）
services:
  worker:
    image: langgenius/dify-api:latest
    environment:
      MODE: worker
      # 全キューを明示的に指定
      CELERY_QUEUES: "dataset,generation,mail,ops_trace,priority_pipeline"
      # Redisの接続先
      CELERY_BROKER_URL: "redis://redis:6379/0"
      CELERY_RESULT_BACKEND: "redis://redis:6379/0"
    depends_on:
      - redis
      - db

設定変更後、workerコンテナを再起動する。

# workerコンテナのみ再起動
docker compose restart worker

# 再起動後、キュー接続状態を確認
docker compose logs worker --tail=50 | grep "queue"

GitHub Issue #13093 では、この CELERY_QUEUES の設定漏れがキューイング停止の根本原因として報告されている。

原因2：Embedding APIのレート制限でキューイングが詰まるケース

ファイルがキューに投入されても、Embedding APIのレート制限に到達するとチャンク処理が失敗し、結果としてキューイング中のまま止まる。OpenAI Embedding APIやローカルのEmbeddingモデルそれぞれに、1分あたりのリクエスト上限がある。

レート制限エラーの確認方法

# APIエラーログの確認
docker compose logs api --tail=200 | grep -E "rate_limit|429|embedding|RateLimitError"

# Workerのエラーログも確認
docker compose logs worker --tail=200 | grep -E "rate_limit|429|Too Many Requests"

429 Too Many Requests や RateLimitError が出力されていれば、レート制限が原因だ。

対処法

レート制限への対処は、使用しているEmbeddingプロバイダーによって異なる。

OpenAI API: プランのアップグレード、またはリクエスト間隔の調整
ローカルモデル（Ollama等）: 同時処理数の制限、GPUメモリの確認
Azure OpenAI: デプロイメントのTPM（Tokens Per Minute）上限を引き上げ

大量ファイルを処理する場合は、一括投入ではなく段階的にアップロードすることでレート制限を回避できる。

原因3：大量ファイルの同時アップロードによるUIフリーズとリセット

Difyの管理画面（Web UI）から50ファイル以上を同時にアップロードすると、UIがフリーズしてアップロード処理自体が正常に完了しないケースがある。GitHub Issue #27168 で報告されており、フロントエンドのメモリ消費とバックエンドのタスクキュー両面で問題が発生する。

ファイル分割アップロードの目安

ファイル数	推奨方法	備考
1〜20ファイル	Web UIから直接アップロード	問題なし
21〜49ファイル	Web UIで分割アップロード（10ファイルずつ）	前のバッチ完了を確認してから次を投入
50ファイル以上	Knowledge APIでバッチ処理	自動化推奨
100ファイル以上	Knowledge API + インターバル付きスクリプト	レート制限も考慮

Knowledge APIを使ったバッチアップロードでキューイングを回避する

大量ファイルのアップロードでは、Web UIを使わずKnowledge APIを直接呼び出すのが安定する。APIでは1ファイルずつ制御できるため、キューイング停止やUIフリーズのリスクを回避できる。

Knowledge APIでファイルをアップロードするスクリプト

import requests
import time
import glob
import os

DIFY_BASE_URL = "http://localhost/v1"
API_KEY = "dataset-xxxxxxxxxxxxxxxxxxxxxxxx"  # Knowledge APIキー
DATASET_ID = "your-dataset-id"

headers = {
    "Authorization": f"Bearer {API_KEY}"
}

# アップロード対象のファイル一覧
files_to_upload = glob.glob("/path/to/documents/*.pdf")

for i, file_path in enumerate(files_to_upload):
    filename = os.path.basename(file_path)
    print(f"[{i+1}/{len(files_to_upload)}] Uploading: {filename}")

    with open(file_path, "rb") as f:
        response = requests.post(
            f"{DIFY_BASE_URL}/datasets/{DATASET_ID}/document/create-by-file",
            headers=headers,
            files={"file": (filename, f, "application/pdf")},
            data={
                "data": '{"indexing_technique": "high_quality", "process_rule": {"mode": "automatic"}}'
            }
        )

    if response.status_code == 200:
        doc_id = response.json().get("document", {}).get("id", "unknown")
        print(f"  -> Success: document_id={doc_id}")
    else:
        print(f"  -> Error: {response.status_code} {response.text}")

    # レート制限回避のため3秒間隔
    time.sleep(3)

print("All files uploaded.")

このスクリプトは公式のKnowledge API仕様に基づいている。time.sleep(3) でリクエスト間隔を空けることで、Embedding APIのレート制限とCeleryキューの過負荷の両方を防ぐ。

LangChainを使ったRAGパイプライン構築では、Embeddingとベクトル検索の仕組みをより詳しく解説している。

RedisとベクトルDBの稼働確認・キューイングのリセット手順

Celery WorkerはRedisをメッセージブローカーとして使用している。Redisが停止していると、タスクキュー自体が機能しない。また、ベクトルDB（Weaviate、Qdrant等）が停止している場合も、Embeddingの保存先がないためキューイングが停止する。

# 全コンテナの稼働状態を一覧表示
docker compose ps

# Redisの接続テスト
docker compose exec redis redis-cli ping
# 期待される出力: PONG

# Redisのキュー内タスク数を確認
docker compose exec redis redis-cli LLEN priority_pipeline

# ベクトルDB（Weaviateの場合）のヘルスチェック
curl -s http://localhost:8080/v1/.well-known/ready | jq .

# ベクトルDB（Qdrantの場合）のヘルスチェック
curl -s http://localhost:6333/healthz

Redisの LLEN priority_pipeline で大量のタスクが溜まっている場合、Workerが処理できていない状態を意味する。Workerのログとあわせて原因を特定する。

原因別の対処法を比較する

3つの原因と対処法を一覧で整理する。

原因	症状	確認方法	対処法	所要時間
Celery Workerのキュー未接続	全ファイルがキューイング中のまま	`docker compose logs worker` でキュー名確認	`CELERY_QUEUES` に `priority_pipeline` を追加	5分
Embedding APIレート制限	一部ファイルは処理済み、途中で停止	`docker compose logs api` で429エラー確認	プランアップグレード or 分割アップロード	10〜30分
大量ファイル同時アップロード	UIフリーズ、50ファイル以上で発生	ブラウザのDevToolsでメモリ使用量確認	50ファイル未満に分割 or Knowledge API	15〜60分
Redis停止	全機能停止、キュー投入自体が失敗	`docker compose ps` で状態確認	Redisコンテナ再起動	2分
ベクトルDB停止	Embedding生成後に保存失敗	ヘルスチェックAPIで確認	ベクトルDBコンテナ再起動	2分

キューに溜まったタスクをリセットする

既にキューに溜まったタスクをリセットして、最初からやり直す場合の手順を示す。

# 1. 全Workerを停止
docker compose stop worker

# 2. Redisのキューをフラッシュ（該当キューのみ）
docker compose exec redis redis-cli DEL priority_pipeline
docker compose exec redis redis-cli DEL dataset
docker compose exec redis redis-cli DEL generation

# 3. docker-compose.yamlのCELERY_QUEUES設定を修正（前述の設定を適用）

# 4. Workerを再起動
docker compose up -d worker

# 5. ログで正常起動を確認
docker compose logs worker --tail=30

リセット後、ナレッジベースの管理画面からファイルのステータスが「未処理」に戻っていることを確認し、改めてアップロードを実行する。

LangChainのRAG from Scratchで、RAGの基本的なチャンキングとEmbeddingの仕組みを理解しておくと、キューイング問題のデバッグがスムーズになる。

まとめ：Difyファイルアップロードのキューイング問題は設定で解決できる

Difyのファイルアップロードが「キューイング中」で停止する問題は、多くの場合インフラ設定の修正で解決できる。

Celery Workerのキュー設定: CELERY_QUEUES に priority_pipeline を含む全キューを明示指定
Embedding APIのレート制限: ログで429エラーを確認し、プランアップグレードか分割処理で対応
大量ファイル対策: 50ファイル以上はKnowledge APIバッチ処理を使用
インフラ確認: RedisとベクトルDBの稼働状態を定期的にチェック

セルフホスティング環境でDifyを運用する場合、Onyxのような社内データ活用プラットフォームも選択肢として検討する価値がある。