ComfyUI が動画生成後にフリーズする：回復ガイド

AI 概要

なぜ ComfyUI は動画生成後にフリーズするのですか？

サンプラーは完了しているものの、デコード、エンコード、プレビュー配信、カスタムノード、あるいはブラウザ自体がまだブロックされたままになっている可能性があります。再起動を試みる前に、遅い最終ステージと完全に停止したバックエンドを明確に区別してください。

ComfyUI がまだ動作中かどうかをどう判断すればよいですか？

ターミナル出力、GPU 利用率、キューの状態、および出力フォルダの内容を総合的に確認してください。ログが更新されている、GPU がアクティブである、またはファイルサイズが増加している場合は、処理が進行中であることを示します。一方、スタックトレースが変化せず、GPU デバイスがアイドル状態の場合は、処理が停止（スタック）している可能性が高いです。

ComfyUI が固まったときに VRAM をクリアすべきですか？

証拠を保存し、安全にキャンセルした後のみ実行してください。モデルを解放することで正常なプロセスを回復できる場合がありますが、破損した CUDA コンテキスト、互換性のないカスタムノード、または失敗したエンコーダーを修復することはできません。

最も迅速かつ安全な修正方法は何ですか？

ワークフローとログを保存し、現在実行中のプロンプトを停止してから ComfyUI を再起動し、小さな既知の良好な動画グラフを実行します。その後、元のノードをグループ単位で順次追加していき、フリーズが再発するまで繰り返します。

実際にフリーズしている対象を特定する

「ComfyUI が動画生成後にフリーズする」という現象には、4 種類の異なる障害が含まれる可能性があります。キャンバスの更新が停止してもバックエンドは継続して動作している場合、サンプラーは完了しているものの VAE デコードや動画エンコードがまだ実行中である場合、Python プロセスは生きているもののカスタムノードで待機中である場合、あるいは GPU ドライバ自体が応答を停止している場合です。これらのケースはブラウザ上では同様に見えるため、それぞれに適した異なる対処が必要です。

まず、最後に表示されたノードとターミナルに出力された最後の行を記録してください。すぐにすべてのウィンドウを閉じないでください。有効な診断を行うには、ワークフローの JSON、ComfyUI およびフロントエンドのバージョン、カスタムノードのバージョン、Python および PyTorch のバージョン、GPU モデル、ドライバ、起動引数、解像度、フレーム数、コーデック、および直近の 30–50 行のログが必要です。

フロントエンドのフリーズか、バックエンドのフリーズか？

出力フォルダを開き、ファイルが作成中であるか、そのサイズが変化しているかを確認してください。他のプロンプトを起動せずに GPU の利用率とメモリ使用量を監視してください。ターミナルで進行状況の出力が継続しているにもかかわらずブラウザがフリーズしているように見える場合は、ワークフローを保存したうえでフロントエンドのみ再読み込みしてください。ターミナルの出力が停止し、GPU 利用率がアイドル状態で、キューが一切進まない場合は、バックエンドのスタックとして扱ってください。

軽量な、視覚的に明瞭な基準シーンを使用することで、重いグラフを復元する前にパイプラインが正常に完了したかどうかを容易に判断できます。

サンプリング完了 ≠ 配信完了

動画向けグラフでは、拡散処理（diffusion）の後にデコード・ラテントフレーム、バッチ統合、デバイス間テンソル移動、補間、音声書き出し、コンテナエンコードなど、高負荷の処理が行われることが多いです。したがって、プログレスバーが 100% になっても、それはサンプリング段階が完了したことを意味するだけであり、「MP4 が完成した」ことを保証するものではありません。フリーズと誤認しないよう、「100%」という表示ではなく、実際に最後に完了したノードを正確に確認してください。

再起動の前に証拠を保存する

再起動は診断行為ではなく、あくまで復旧手段です。再起動を実行する前に、ワークフローをエクスポートし、ターミナルのテキストをコピーしてください。OS 全体がフリーズしたのか、ブラウザだけが停止したのか、あるいはキュー内の特定のアイテムだけがスタックしたのかを明記してください。OS 全体がロックアップした場合は、単一の無反応タブよりも、ドライバ、CUDA バックエンド、不安定なオーバークロック、電源、またはメモリ圧迫といった問題を強く疑う必要があります。

簡潔なインシデント記録を作成してください：

ComfyUI / フロントエンドのバージョン:
Python / PyTorch / CUDA / ドライバ:
GPU およびシステム RAM:
起動引数:
ワークフローおよびモデル:
幅 × 高さ、フレーム数、バッチサイズ:
最後に完了したノード:
ターミナルの最後の行:
ブラウザの状態 / バックエンドの状態 / OS の状態:
初回実行時か、再実行時か:

信頼できない部分出力を保存する

MP4 ファイルが存在する場合、それを「完了済み」と見なす前に、その再生時間とストリーム構成を検査してください。切り詰められたコンテナは開けるものの早期終了することがあります。また、画像シーケンスは要求されたフレーム数より少ない枚数しか含んでいない可能性があります。証拠が上書きされないように、部分的な成果物は障害種別に応じた名前で保存してください。

ComfyUI 動画＋音声のクロップガイド では、動画パスと音声パスを明示的に分離しておくべき理由が説明されています。この分離は、フリーズがマルチプレクサ（muxing）の前で発生しているのか、それとも最終エンコードの内部で発生しているのかを特定するのにも役立ちます。

メモリおよびエンコード負荷の低減

動画生成は、解像度、フレーム数、バッチサイズ、ラテントチャンネル数、VAE デコード、補間、エンコードなど、複数の要因によってメモリ負荷を指数関数的に増大させます。ランダムにメモリ関連フラグを切り替えるよりも、いずれかの次元を半分に減らす方が、原因の特定に役立つことが多いです。まずフレーム数を半分にしてください。それでもグラフがスタックする場合は、解像度を下げてください。その後、ベースモデルとサンプラーをそのまま維持した上で、補間、アップスケール、および任意のプレビューを無効化してください。

ステージ式メモリテストの実施

以下のテストを順番に実行し、それぞれが正常終了したかどうかを記録してください：

1. ワークフローがサポートする最小解像度で、1 本の短いクリップを実行。
2. 同じクリップを、意図通りの VAE およびデコーダで実行。
3. 同じクリップを、意図通りのエンコーダで実行（ただし補間は無効）。
4. 短い再生時間で、完全なポストプロセッシングチェーンを実行。
5. 上記すべてのステージが成功した後のみ、意図通りの再生時間を使用。

解像度とフレーム数を同時に増加させるテストは行わないでください。小さなクリップは成功するが、長いクリップでデコード段階で繰り返しスタックする場合は、グラフ自体は有効ですが、メモリまたはデコード計画に問題がある可能性が高いです。最小限のグラフでも失敗する場合は、品質調整の前に互換性を調査してください。

デコードの安定性をテストするには、ディテールが豊富だが短い素材を使用してください。長さと解像度はそれぞれ別々に増加させてください。

ドライバ障害を隠す「修正」は避けるモデルのメモリをクリアする、プレビューをアンロードする、またはフロントエンドを再起動することで、健全なバックエンドがリソースを解放できる場合があります。ただし、これらはすべての失敗した GPU コンテキストをリセットすることはできません。デスクトップ全体がフリーズし、ターミナルが Python 例外を出さずに停止する、あるいはドライバーがリセットされる場合は、まず公式の最小限のワークフローと控えめなハードウェア設定で再現を試みてください。その上で、プロンプトを原因とする判断は避けてください。

モデルファイルとデコーダの不一致については、VAE 読み込みチェックリストに従ってください。読み込み側がファイルを認識できたとしても、単にファイル名が変更されたり配置場所が間違っていたりするだけで、それが互換性のある VAE に自動的に変換されることはありません。

カスタムノードとフロントエンド状態の分離

カスタムノードは、Python パッケージ、コンパイル済み拡張機能、UI コード、エンコーダ、およびデバイス管理動作を追加します。それらを一度にすべて更新すると、原因を特定するための比較が不可能になります。まず、正常に動作する環境を保存し、その後サードパーティ製ノードを無効化して、同じメディアタイプに対応する最小限のコアワークフローを実行してください。

コアグラフが成功した場合、カスタムノードグループを機能別に再有効化します：モデルローダー → 条件付けツール → 動画ユーティリティ → インターポレーション → アップスケーラー → エンコーダ。障害が再発した時点で、該当するグループをさらに細分化します。表示名だけでなく、ノードのリポジトリとコミットハッシュも記録してください。

ブラウザを個別にテストする

フロントエンドは、バックエンドが処理を完了しているにもかかわらず進行状況を表示しなくなることがあります。Python を終了させる前に、新しいブラウザタブから再接続し、キューまたは履歴を確認してください。1 回のテストではブラウザ拡張機能を無効化し、複数の重いワークフロータブを開きっぱなしにしないよう注意してください。また、フロントエンドのバージョンとバックエンドのバージョンを比較してください。ステータスが復元されるキャンバスの更新は、表示状態の問題である証拠であり、GPU がフリーズしたという証拠ではありません。

フルパイプラインの完了後には、完成した配信フレームは、信頼できる肌の質感、湯気、食品のテクスチャ、および手の小さなディテールを保持すべきです。

既知の正常動作ワークフローを実行する

安全な再起動後に、まず本番用のフルグラフをキューに入れることは避けてください。このマシンで以前に成功した、極めて小さなワークフローを使用してください：1 つのモデル、1 つの短いクリップ、オプションのカスタムノードなし、インタープレートなし、アップスケールなし、標準エンコーダのみ。これにより、最も重要な問い——「このインストールの動画スタックがそもそも動作しているか？」——に答えられます。

src=https://r2.seedance.tv/blog/comfyui-freezes-after-video-generation/known-good-motion-baseline-v1.mp4
poster=https://r2.seedance.tv/blog/comfyui-freezes-after-video-generation/known-good-motion-baseline-poster-v1.jpg
label=ComfyUI 回復テスト用の短い既知の正常動作モーションベースライン

5 秒間の動きのある出力があれば、高コストのグラフを再構築する前に、生成・デコード・エンコード・再生の各ステップが正しく動作することを検証できます。

チェックポイントごとにグラフを復元する

各チェックポイントごとに JSON を 1 つずつ保存します：01-core、02-loader、03-conditioning、04-post、05-final。診断中は、同時に 1 つのジョブのみをキューに入れます。チェックポイントで失敗が発生した場合、そのターミナル出力を前回成功したチェックポイントの出力と比較し、新たに追加されたノードの半分を削除します。この二分探索的手法は、仮説を持たずにフラグを変更するよりも迅速です。

キュー自体が問題の原因である場合、ComfyUI バッチ処理ガイドが、独立したジョブ、明示的な出力名、再開可能なバッチを実現するより安全なパターンを提供しています。1 つのアイテムが失敗しても、承認済みのすべてのクリップを再実行する必要はありません。

ローカル回復かホスティングされたワークフローかを選択する

ローカル ComfyUI は、正確なノード、カスタムモデル、再現可能な環境制御、およびマシンへの直接アクセスが必要な場合に価値があります。一方で、ドライバーの互換性、Python の依存関係、カスタムノードのコミット、メモリ計画、ログ出力、再起動など、すべての責任もユーザーにあります。最適な選択は、これらの制御が創造的優位性の一部であるか、単なる制作上のオーバーヘッドにすぎないかによって決まります。

ローカル vs クラウド AI 動画生成ガイドでは、実践的な意思決定フレームワークを提供しています。グラフ自体が再利用可能な資産であり、誰かがその保守を担当している場合はローカルを維持してください。チームが主に承認済みショット、一貫した参照、予測可能な再実行、および納品を必要としており、継続的な環境修復作業を要しない場合は、ホスティングされたルートを利用してください。

Seedance Agent の位置づけ

Seedance Agent は、編集者が大規模なローカル依存関係グラフを維持する必要なく、参照、ショットプラン、承認、再実行を制作タスクに紐づけて管理できます。ただし、壊れたローカル ComfyUI インストールを「健康」にすることはありません。ドライバー、ノード、エンコーダの診断にかかるコストが、影響を受けたショットを管理されたワークフローで再実行するコストを上回る場合、代替の制作経路を提供します。

有用な引継ぎは選択的です：承認済みのプロンプト、ソース画像、アスペクト比、再生時間、モーション要件、および失敗したショットの証拠を保持します。拒否されたユニットのみを再生成し、同一の承認チェックリストと照合したうえで、承認されたクリップを編集工程へ戻します。

結論

ComfyUI が動画生成後にフリーズした場合、まずブラウザ、バックエンド、ポストプロセッシングノード、エンコーダ、GPU ドライバー、あるいは OS 全体のいずれが停止したかを特定してください。ワークフローとログを保存し、極小の既知の正常動作クリップでテストを行ってください。解像度を上げる前にフレーム数を減らし、カスタムノードを機能ごとに分離し、名前付きチェックポイントを通じてグラフを段階的に復元してください。ローカルでのメンテナンスがもはや有益な制御を提供しなくなった場合、次の承認済みショットを管理型 Seedance ワークフローへ移行してください →