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

この記事ではRAGに特化して解説します。RAG全般は RAGとは？仕組み・構築・ベクトルDB選定まで【2026年完全ガイド】 をご覧ください。

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

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

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

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

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

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

最も多い原因が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 で報告されており、フロントエンドのメモリ消費とバックエンドのタスクキュー両面で問題が発生する。

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

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つの原因と対処法を一覧で整理する。

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

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

# 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の仕組みを理解しておくと、キューイング問題のデバッグがスムーズになる。

関連記事: RAGとは？仕組み・構築・ベクトルDB選定まで【2026年完全ガイド】

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

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

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

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

参照ソース

• GitHub Issue #31932: Files stuck in queuing status
• GitHub Issue #27473: Knowledge base file upload stuck
• GitHub Issue #26211: Embedding queue not processing
• GitHub Issue #13093: Celery worker queue configuration
• GitHub Issue #27168: UI freeze on bulk file upload
• Dify Knowledge API公式ドキュメント
• Dify公式リポジトリ