ComfyUIで1000枚以上の画像をバッチ処理 - 完全ワークフローガイド

ComfyUIのノードベースのワークフローシステムは、インタラクティブな実験だけのものではありません。適切な設定があれば、数千枚の画像を処理できる強力なバッチ処理エンジンです。ComfyUIバッチ処理は、ワークフローを単一画像の実験から、大規模なデータセットを処理できるプロダクションパイプラインに変換します。製品カタログのアップスケール、データセット全体への一貫したスタイル転送、数千フレームでのオブジェクト検出、入力画像フォルダからのバリエーション生成など、ComfyUIバッチ処理はComfyUIをクリエイティブツールからプロダクションパイプラインに変換します。

このガイドでは、基本的なComfyUIバッチ処理ワークフロー設計から、寝ている間に大量の画像セットを処理できる高度な自動化技術まで、すべてをカバーします。バッチ読み込みノードを効果的に使用する方法、長時間実行されるキューの管理、エラーの優雅な処理、ハードウェア能力に合わせた処理のスケーリングを学びます。最終的には、実際のプロダクションワークロードを処理する信頼性の高いComfyUIバッチ処理システムを構築する知識を得られます。

ComfyUIバッチ処理アーキテクチャの理解

バッチワークフローを構築する前に、ComfyUIバッチ処理が単一画像処理とどのように異なるバッチ操作を処理するかを理解してください。ComfyUIバッチ処理アーキテクチャの理解は、効率的なワークフローを構築するために不可欠です。

単一画像モードでは、画像を読み込み、ワークフローを通して処理し、結果を保存します。各生成は手動で開始されます。バッチ処理では、自動反復が必要です：画像1を読み込み、処理し、結果1を保存し、自動的に画像2に進み、すべての画像が処理されるまで続けます。

ComfyUIは、画像フォルダを反復する専用のバッチ読み込みノードを通じてこれを実現します。バッチローダーでワークフローをキューに入れると、ComfyUIは1回だけ実行するのではなく、ソースフォルダ内の各画像（または画像グループ）に対して自動的に複数の実行をキューに入れます。バッチローダーノードは、各実行でどの画像を読み込むかを追跡し、データセットを通じてインクリメントします。

ComfyUIバッチ処理の重要な概念は、画像ごとのキューモデルです。1000枚の画像を処理する場合、ComfyUIは1000回のワークフロー実行をキューに入れます。各実行はバッチから次の画像を読み込み、処理し、結果を保存します。これは、複数の画像を同時に単一の実行に読み込むバッチアプローチとは異なります。ComfyUIバッチ処理は実行ごとに1つの画像を処理しますが、データセットを通じた反復を自動化します。

このアーキテクチャには重要な意味があります。各画像は完全なワークフローを通じて独立して処理されるため、分離が提供されます。1つの失敗した画像が後続の画像の処理をブロックしません。ただし、これは実行ごとのオーバーヘッド（モデル読み込みなど）がComfyUIが適切にキャッシュしない限り、各画像で発生することも意味します。

ComfyUIバッチ処理に必要なノード

いくつかのノードタイプがComfyUIバッチ処理ワークフローを可能にします。利用可能なものを理解することで、ComfyUIバッチ処理操作のための効果的なパイプラインを設計できます。

さまざまなカスタムノードパックからのLoad Image Batchノードは、フォルダから画像を順番に読み込みます。主要なパラメータには以下が含まれます：

• Directory path: ソース画像を含むフォルダ
• Index: フォルダ内のどの画像を読み込むか（0ベース）
• Pattern: オプションのファイルパターンフィルタリング（例：.jpg、.png）

ワークフローをキューに入れると、ComfyUIはキューに入れられた各実行のインデックスを自動的にインクリメントします。初期インデックスと処理する画像数を設定すれば、ComfyUIが反復を処理します。

ComfyUI-Impact-PackのImage Inputノードは、出力ファイル名の自動保持などの追加機能を持つバッチ機能を提供します。これは、出力ファイルが入力ファイル名に対応する必要がある場合に特に便利です。

Video Helper SuiteのVHS Load Imagesは、良好なファイル名処理でバッチ画像を読み込むことができ、順序で画像シーケンスの読み込みをサポートします。

Save Imageノードはバッチ出力用の設定が必要です。鍵は、各出力が一意の名前を持つことを保証するファイル名テンプレートです。オプションには以下が含まれます：

• 連番：output_0001.png、output_0002.png など
• 入力ファイル名の保持：入力がphoto_001.jpgの場合、出力はphoto_001_processed.png
• 出力を整理するためのプレフィックス/サフィックスの追加

ほとんどのカスタム保存ノードはこれらのパターンをサポートしています。テンプレート構文については、特定のノードのドキュメントを参照してください。

基本的なComfyUIバッチ処理ワークフローの構築

一般的なタスク：画像フォルダのアップスケールのための完全なComfyUIバッチ処理ワークフローの作成を見ていきましょう。

入力ノードから始めます。Load Image Batchノードを配置して設定します：

Directory: /path/to/input_images
Index: 0
Pattern: *.jpg

インデックスは最初の画像に対して0から始まります。すべての画像を処理するために複数の実行をキューに入れます。

読み込んだ画像を処理パイプラインに接続します。アップスケールの場合、これは次のようになります：

Load Image Batch -> Upscale Image (by Model) -> Save Image

または、より洗練されたアップスケールの場合：

Load Image Batch -> VAE Encode -> KSampler (tile upscale) -> VAE Decode -> Save Image

バッチ出力を処理するためにSave Imageノードを設定します。出力ディレクトリとファイル名テンプレートを設定します：

Output Directory: /path/to/output_images
Filename Prefix: upscaled_

一部の保存ノードでは、元のファイル名を保持できます：

Filename Template: {original_name}_upscaled

次に、処理する画像数を決定します。入力フォルダに何枚の画像があるかを確認します（例：500枚）。ComfyUIで、キュープロンプト数を一致するように設定します。「Extra options」で500を表示してQueue Promptをクリックすると、ComfyUIは500回のワークフロー実行をキューに入れます。バッチローダーは各実行でインデックスを自動的にインクリメントし、画像0から画像499まで処理します。

Queueをクリックして進行状況を観察します。ComfyUIは残りのキュー数を表示し、出力フォルダに出力が表示されるのを見ることができます。

大規模なComfyUIバッチ処理の処理（1000枚以上の画像）

数百または数千枚の画像を処理すると、小さなバッチでは直面しない課題が発生します。大規模なComfyUIバッチ処理を効果的に処理する方法は次のとおりです。

大きなバッチをチャンクに分割することは、管理性に不可欠です。5000回の実行を一度にキューに入れるのではなく、500-1000のチャンクに分割します。これにはいくつかの利点があります：

• より簡単な進行状況の監視（各チャンクがいつ完了するかがわかる）
• チャンク間で一時停止して結果を確認する能力
• バッチの途中で何か問題が発生した場合の簡単な回復
• より良いメモリ管理（一部のキャッシュはチャンク間でクリアできる）

チャンクで処理するには、開始インデックスとキュー数を調整します：

• チャンク1：インデックス0、500枚の画像をキュー
• チャンク2：インデックス500、500枚の画像をキュー
• チャンク3：インデックス1000、500枚の画像をキュー

これをComfyUI APIでスクリプト化して、自動処理を行うことができます。

メモリ管理は長いバッチで重要です。ComfyUIはパフォーマンスのために読み込まれたモデルと中間結果をキャッシュしますが、数千回の反復にわたってメモリが蓄積する可能性があります。時間の経過とともにメモリが増加している場合：

• UIを通じてComfyUIキャッシュを定期的にクリア
• 非常に長いバッチの場合、それらの間にComfyUIの再起動を伴うチャンクをスケジュール
• 必要に応じて--cpu-vaeまたは他のメモリ節約フラグを使用

進行状況の監視は、処理が数時間または数日かかる場合に重要になります。オプションには以下が含まれます：

• UIでキューカウンターを監視
• 出力フォルダに表示される出力ファイルをカウント
• APIベースの監視を使用してプログラムで進行状況を追跡
• スクリプトを作成している場合は各チャンクの完了をログ

エラー処理は、一部の画像が失敗するため重要です。ファイルが破損している可能性があるか、画像がワークフローを壊す異常な寸法を持っている可能性があります。ComfyUIのデフォルト動作はエラーで停止します。つまり、翌朝、処理が5000枚中347枚の画像で停止したことがわかります。

より良いアプローチ：

• 一部のバッチノードには処理を続行するskip-on-errorオプションがあります
• カスタムノードを使用してワークフローにエラー処理を実装
• バッチを続行させながら、後で調査するために失敗した画像をログ
• エラーが影響する画像を少なくするために小さなチャンクで処理

高度なComfyUIバッチ処理パターン

基本的な反復を超えて、いくつかのパターンがより洗練されたComfyUIバッチ処理ワークフローを可能にします。

ペア入力処理は、各入力画像に対応するコントロール画像、マスク、またはプロンプトファイルがあるケースを処理します。例えば、画像ごとのマスクを使用したインペインティング：

Load Image Batch (images) -> index 0, 1, 2...
Load Image Batch (masks) -> index 0, 1, 2... (同じインデックス)
Inpaint Node -> 画像と対応するマスクを受け取る

両方のバッチローダーは同じインデックスを使用するため、画像0はマスク0とペアになります。

テキストファイルプロンプトは画像ごとのプロンプトを可能にします。データを次のように構造化します：

/images/image_000.jpg
/prompts/image_000.txt (image_000のプロンプトを含む)

各画像に対応するプロンプトテキストファイルを読み込み、サンプラーノードのプロンプト入力にパイプします。

条件付き処理は、画像プロパティに基づいて異なる処理を適用します。画像特性（寸法、コンテンツなど）を検出して異なる処理ブランチにルーティングするノードを使用します：

Load Image -> Detect Orientation -> If Portrait: Processing A, If Landscape: Processing B

これにより、多様な入力に適応するバッチ処理ワークフローが可能になります。

マルチ出力ワークフローは、入力ごとに複数の出力を生成します。例えば、各画像の3つのバリエーションを生成：

Load Image -> Process with Seed 1 -> Save as {name}_var1
           -> Process with Seed 2 -> Save as {name}_var2
           -> Process with Seed 3 -> Save as {name}_var3

キューに入れられた各実行は、1つの入力に対して3つの出力を生成します。

API経由のプログラムによるComfyUIバッチ処理制御

ComfyUIバッチ処理の最大の制御には、UIではなくComfyUIのAPIを使用します。APIベースのComfyUIバッチ処理は、本番環境に最大の柔軟性を提供します。

ComfyUIは、ワークフローJSONを受け入れて実行をキューに入れるWebSocket APIを公開しています。次のことを行うスクリプトを書くことができます：

• ワークフローテンプレートを読み込む
• 各バッチアイテムのパラメータを変更（入力パス、出力パス、プロンプト）
• APIに送信
• 完了を追跡
• 結果を処理

API制御によるバッチ処理のPython例：

import json
import requests
import time
from pathlib import Path

COMFYUI_URL = "http://127.0.0.1:8188"

def load_workflow_template(template_path):
    with open(template_path, 'r') as f:
        return json.load(f)

def queue_prompt(workflow):
    response = requests.post(
        f"{COMFYUI_URL}/prompt",
        json={"prompt": workflow}
    )
    return response.json()

def get_history(prompt_id):
    response = requests.get(f"{COMFYUI_URL}/history/{prompt_id}")
    return response.json()

def wait_for_completion(prompt_id, timeout=300):
    start = time.time()
    while time.time() - start < timeout:
        history = get_history(prompt_id)
        if prompt_id in history:
            return history[prompt_id]
        time.sleep(1)
    raise TimeoutError(f"Processing did not complete within {timeout}s")

def process_batch(input_folder, output_folder, workflow_template_path):
    workflow = load_workflow_template(workflow_template_path)
    input_path = Path(input_folder)
    output_path = Path(output_folder)
    output_path.mkdir(exist_ok=True)

    images = sorted(input_path.glob("*.jpg")) + sorted(input_path.glob("*.png"))
    print(f"Processing {len(images)} images")

    for i, image_path in enumerate(images):
        print(f"Processing {i+1}/{len(images)}: {image_path.name}")

        # この画像用にワークフローを変更
        workflow["1"]["inputs"]["image"] = str(image_path)
        workflow["10"]["inputs"]["filename_prefix"] = image_path.stem + "_processed"

        # キューに入れて待機
        result = queue_prompt(workflow)
        prompt_id = result["prompt_id"]

        try:
            completion = wait_for_completion(prompt_id)
            print(f"  正常に完了")
        except TimeoutError:
            print(f"  エラー: {image_path.name}の処理がタイムアウト")
        except Exception as e:
            print(f"  エラー: {e}")

    print("バッチ処理完了")

# 使用法
process_batch(
    "/path/to/input_images",
    "/path/to/output_images",
    "/path/to/workflow_api.json"
)

このスクリプトは完全な制御を提供します：ログを追加したり、リトライロジックを実装したり、複数のComfyUIインスタンスで並列化したり、完了時に通知を送信したり、他のシステムと統合したりできます。

APIベースのバッチ処理の主な利点：

• 単一のフォルダだけでなく、どこからでも画像を処理
• 画像ごとにプロンプトやパラメータを動的に生成
• 洗練されたエラー処理とリトライロジックを実装
• 詳細なメトリクスとタイミングを追跡
• より大きなパイプラインと自動化システムと統合
• オフ時間の処理をスケジュール

ComfyUIバッチ処理のパフォーマンス最適化

ComfyUIバッチ処理のパフォーマンスは、ジョブが数時間で完了するか数日かかるかを決定します。ComfyUIバッチ処理のスループットを最大化するために、これらの要因を最適化します：

モデル読み込みオーバーヘッド：ComfyUIは実行間で読み込まれたモデルをキャッシュするため、最初の画像は後続の画像より遅くなります（モデル読み込み）が、残りの画像はより速く処理されます。ワークフローがモデルの再読み込みを強制しないことを確認してください。モデルパスが一貫しており、新しい読み込みを強制するノードがないことを確認してください。

VRAM管理：長いバッチでは、VRAMの断片化が蓄積する可能性があります。時間の経過とともに遅延が見られる場合、キャッシュをクリアする必要があるかもしれません。モデルを読み込んだままにする（高速）ことと、キャッシュをクリアする（より大きな個別操作のためにVRAMを解放する）ことのバランスを取ります。

ディスクI/O：数千の入力画像を読み取り、数千の出力を書き込むとストレージに負荷がかかります。高速SSDストレージは大幅に役立ちます。可能であればネットワークドライブからの読み取りと書き込みを避けてください。ローカルNVMeストレージが最高のパフォーマンスを提供します。

並列処理：複数のGPUがある場合、それぞれがバッチの異なるチャンクを処理する複数のComfyUIインスタンスを実行します。1つのGPUでも、ワークフローがVRAMを完全に使用していない場合は2つのインスタンスを実行できる可能性がありますが、これにはテストが必要です。

ワークフローの最適化：バッチ処理のためにワークフローを簡素化します。プレビューノードを削除します（オーバーヘッドが追加されます）。不要な操作を行っていないことを確認します。ワークフローをプロファイリングしてボトルネックを特定します。

解像度と品質のトレードオフ：1024x1024画像の処理は、生成タスクでは512x512の約4倍かかります。速度が重要なバッチ処理では、低解像度が許容できるか、入力をダウンスケールして処理し、出力をアップスケールできるかを検討してください。

一般的なバッチ処理アプリケーション

異なるアプリケーションには異なるワークフローパターンが必要です。

アップスケーリングは最もシンプルなバッチアプリケーションです。画像を読み込み、アップスケーラーモデルを通して実行し、より高い解像度で保存します。これは embarrassingly parallel であり、バッチ処理に適しています：

Load Image Batch -> RealESRGAN Upscale -> Save Image

良いGPUがあれば、一晩で数千枚の画像をアップスケールできます。

スタイル転送はデータセット全体に一貫した芸術的スタイルを適用します。IP-Adapterまたは類似のものを使用して、各画像にスタイル参照を適用します：

Load Image Batch (content) ->
Load Image (style, 単一参照) ->
IP-Adapter -> KSampler -> Save Image

すべての画像が同じスタイル参照で処理されます。

画像から画像への生成は構造を保持しながら入力を変換します：

Load Image Batch -> VAE Encode -> KSampler (low-medium denoise) -> VAE Decode -> Save Image

構成を維持しながら既存の画像に生成強化を適用するのに便利です。

オブジェクト検出/セグメンテーションはデータセット全体で検出モデルを実行します：

Load Image Batch -> SAM Model -> Export Masks -> Save

さらに使用するために各画像からマスクまたは検出を抽出します。

データ拡張はトレーニングデータセット用に各画像の複数のバリエーションを生成します：

Load Image Batch -> Random transforms -> Save multiple variations

トレーニング目的でデータセットサイズを倍増させます。

一貫したキャラクター生成はバッチプロンプトを使用して、多くのシーンでキャラクターを生成します：

Load Prompt Batch (scene descriptions) ->
Character LoRA -> KSampler -> Save Image

多くの異なるコンテキストで同じキャラクターを生成します。

よくある質問

1000枚の画像を処理するのにどのくらい時間がかかりますか？

ワークフローの複雑さとハードウェアに完全に依存します。単純なアップスケーリングは画像あたり3-5秒かかる可能性があります（合計約1時間）。複雑な生成ワークフローは画像あたり30-60秒かかる可能性があります（合計8-16時間）。画像あたりの時間に画像数を掛けて見積もりを出します。

バッチ処理を一時停止して再開できますか？

キューはいつでも停止できます。再開するには、どのインデックスで停止したかをメモし（出力をカウントするかキュー位置で）、バッチローダーをそのインデックスに設定し、残りの画像をキューに入れます。一部のバッチノードには明示的な再開機能があります。

処理中に1つの画像が失敗したらどうなりますか？

デフォルトの動作はキューを停止します。エラーにもかかわらず続行するには、skip-on-errorオプションを持つバッチノードを使用するか、失敗が影響する画像を少なくするために小さなチャンクで処理します。後で調査するために失敗した画像を常にメモしてください。

どの画像がエラーを引き起こしたかをどうやって知りますか？

現在のキュー位置がどのインデックスが処理されていたかを教えてくれます。それを入力フォルダのリストと照合します。一部のバッチノードは、失敗を特定するのに役立つ現在のファイル名を出力します。

各画像に異なるプロンプトで処理できますか？

はい、各画像に対応するプロンプトファイルを読み取るテキストファイル読み込みノードを使用します。image_001.jpgがそのプロンプトを含むimage_001.txtを持つようにデータを構造化します。

バッチ処理は単一画像よりも多くのVRAMを使用しますか？

画像あたりのVRAM使用量は同じです。ただし、キャッシュ管理なしの長いバッチはメモリを蓄積する可能性があります。長いバッチ中の使用量を監視し、メモリが増加したらキャッシュをクリアします。

入力と出力の間でファイル名の対応をどのように維持しますか？

{original_name}_processedのようなファイル名テンプレートをサポートする保存ノードを使用します。これにより、出力に入力ファイル名が保持されます。テンプレート変数については、特定のノードのドキュメントを確認してください。

動画をバッチ処理できますか？

はい、フレームを抽出し、フレームをバッチ処理し、再組み立てします。VHS（Video Helper Suite）ノードは動画の読み込みと保存を処理します。動画を画像シーケンスとして処理します。

処理できる最大バッチサイズは何ですか？

ComfyUIではなく、ディスク容量と忍耐力によって制限されます。入力と出力のストレージがあれば、数万枚の画像が実現可能です。すべてを一度にキューに入れるのではなく、管理可能なチャンクで処理します。

バッチ内の異なるサイズの画像をどのように処理しますか？

処理前にすべての入力を一貫した寸法にリサイズするか、さまざまなサイズを優雅に処理するワークフローノードを使用します。一部の操作には一貫した寸法が必要ですが、他の操作は自動的に適応します。

バッチ処理を複数のマシンに分散できますか？

はい、それぞれがComfyUIを実行するマシン間で画像セットを分割します。これには、同じ画像を2回処理しないようにし、出力を結合するための調整が必要です。ネットワークストレージまたはクラウドオーケストレーションが役立ちます。

結論

バッチ処理は、ComfyUIをインタラクティブなクリエイティブツールから、本番対応の画像処理パイプラインに変換します。主要な原則は、適切なバッチ読み込みノードを使用すること、チャンキングを通じて長いキューを管理すること、エラーを優雅に処理すること、特定のハードウェアとワークフローのパフォーマンスを最適化することです。

設定が正しく機能することを確認するために、小さな画像セットを処理するシンプルなバッチワークフローから始めます。ワークフローに自信が持てたら、より大きなバッチにスケールアップします。複雑なバッチ操作を最大限に制御するには、APIベースのスクリプティングを使用します。

バッチ処理を学ぶ投資は、手動でクリックするよりも多くの画像を処理する必要があるときに報われます。それが数十枚でも数千枚でも、バッチ処理がそれを実現可能にします。

インフラ管理なしで信頼性の高いバッチ処理が必要なユーザーには、Apatero.comがプロフェッショナルな監視とエラー処理を備えた大規模画像セットのスケーラブルな処理を提供します。