古いComfyUIワークフローが動かないときの更新・移行手順

以前は動いていたComfyUIのワークフローが、ComfyUI本体やカスタムノードを更新した後に動かなくなることがある。

このとき、最初から関連するものを全部最新版へ上げると、どの変更が原因だったのか分からなくなりやすい。まずやるべきなのは、最後に動いていたワークフローをそのまま残すことだ。

元のワークフローは上書きしない

最初に、動かなくなったワークフローのJSONを別名で複製する。

workflow-original.json
workflow-migration.json

修正するのは複製側だけにする。元ファイルを残しておけば、変更を重ねて状況が悪化しても、最初の状態へ戻って比較できる。

分かる範囲で、最後に動いていた環境も控えておく。

ComfyUIのバージョン:
フロントエンドのバージョン:
使っていたカスタムノード:
モデルのファイル名:
最後に生成できた日:

すべて正確に残っていなくてもよい。後から比較できる情報が一つでも多い方が原因を追いやすい。

「何が見つからないのか」を分ける

古いワークフローが動かない原因は一つとは限らない。

たとえば、次のような違いがある。

症状	主に確認する場所
ノード自体が見つからない	カスタムノードの配布元、導入状態
ノードはあるが入力項目が違う	カスタムノードのバージョン差
指定していたモデルが選べない	モデル名、保存先、読み込みノード
接続できない端子がある	ノードの入出力仕様の変更
標準ノードでも動かない	ComfyUI本体やフロントエンドの変更

赤いノードがあるからといって、すべて同じ原因だと考えない。

不足しているカスタムノードが明確なら、赤いノード・Missing Custom Nodeの直し方で配布元とバージョンを確認する。

本体とカスタムノードを一度に更新しない

原因を追える状態にするには、変更を一段階ずつ行う。

たとえば、

1. ComfyUI本体が起動するか確認する
2. 標準ノードだけの簡単なワークフローが動くか確認する
3. 必要なカスタムノードを一つ確認する
4. 元のワークフローを読み直す
5. 次のカスタムノードへ進む

という順にすると、どの段階で状態が変わったかが分かる。

複数のカスタムノードをまとめて更新し、モデル名も変え、ワークフローの接続も同時に直すと、生成できるようになっても「何が必要な修正だったのか」が残らない。

カスタムノードは名前だけで入れ直さない

古いワークフローに存在しないノード名が出ていても、検索結果で見つかったリポジトリをすぐに導入しない。

カスタムノードはPythonコードを含むため、ワークフローの配布元が案内していたリポジトリか、現在の正式な配布元かを確認する必要がある。

また、古いワークフローが特定のバージョンを前提としていた場合、最新版ではノード名や入力項目が変わっていることもある。

「入れれば直る」ではなく、元のワークフローが何を前提としていたかを見る。

モデル名や保存先の変化も確認する

ノード側に問題がなくても、ワークフローが古いファイル名を参照しているだけということがある。

Checkpoint、VAE、LoRAなどの読み込みノードを開き、現在の環境で目的のファイルが選べるか確認する。

以前とファイル名が変わった場合は、似た名前の別モデルを推測で選ぶのではなく、配布元とモデル系列を確認してから置き換える。

一度動いた状態を新しい基準点にする

修正版のワークフローで再び生成できたら、その時点の状態を保存する。

元のワークフロー:
修正版ワークフロー:
変更したノード:
変更したモデル:
生成結果:
確認した日:

これを新しい基準点にしてから、追加の更新や整理を進める。

古いワークフローの移行で大切なのは、単に「最新状態にする」ことではない。どの変更が必要だったのか追跡できる状態で、もう一度動かすことだ。

外部から受け取ったJSONや画像を初めて読み込む場合は、ワークフローJSON・画像を読み込む前の確認手順も合わせて確認すると安全に進めやすい。