ComfyUI ワークフロー再利用ガイド：インポートから再現までのトラブルシュートチェックリスト

他人の ComfyUI ワークフローをインポートしたあと、画面が赤いノードだらけになり、モデル一覧も空になることがあります。私が初めてこの状態に当たったときは、問題が 3 種類に分かれると気づくまで 30 分ほどかかりました。ノード不足、モデルパスの不一致、Python 依存関係の未インストールです。この記事では ComfyUI のインストール方法ではなく、受け取った workflow JSON や PNG をどう補完し、どうデバッグし、サンプル画像に近い結果まで持っていくかだけを扱います。中心になるのは、インポートからアーカイブまで使えるトラブルシュート用チェックリストです。

他人の Workflow が動かない理由

ComfyUI の workflow は、基本的にはノードの接続図です。JSON や PNG metadata が記録するのは、ノードタイプ、パラメータ値、接続関係です。モデルファイル、custom nodes プラグイン、Python 依存関係は含まれません。そのため、共有された workflow を読み込むと、ローカル環境に足りないものがすぐ表面化します。

赤いノードは、ComfyUI が対応するノードタイプを見つけられないという意味です。一部は内蔵の core node なので通常は不足しません。一方で、第三者拡張の custom node はローカルに入っていないことがあります。ノードを補ったあとも、Load Checkpoint や Load LoRA のドロップダウンが空のままになることがあります。これはモデルファイルがデフォルトディレクトリにないか、パス設定が合っていないためです。さらに一部の custom node は、insightface や onnxruntime などの Python パッケージ不足で止まります。

この 3 種類の問題は重なります。1 つの workflow が、3 個の custom nodes、2 個の checkpoint モデル、1 個の Python パッケージを同時に要求することもあります。確認順序がないと、途中で詰まり、関係ないものまで大量に入れてしまいがちです。以下のチェックリストでは、問題を分けて優先度順に処理します。

Workflow の 2 つの入手元：JSON と PNG Metadata

workflow の共有形式は主に 2 つです。独立した JSON ファイル、または metadata 付きの PNG 画像です。JSON は ComfyUI が出力するネイティブ形式で、ノード情報を完全に記録します。PNG metadata は埋め込み形式で、一部の生成画像には workflow データが入っています。ただし、作成者がそれを保持していることが前提です。

JSON ファイルをドラッグする

JSON ファイルを受け取ったら、ComfyUI の画面に直接ドラッグします。画面はノードグラフを読み込み、すべての接続関係を表示します。JSON は画像圧縮に依存せず、ノード情報を保持しやすいため、最も信頼できる方法です。

その JSON が ComfyUI からエクスポートされたものなら、読み込み後のノード配置は相手側とおおむね一致するはずです。レイアウトが崩れている場合は、エクスポート時の ComfyUI バージョン差、または手動編集された JSON を疑います。

PNG metadata を読み込む前提

一部の AI 生成画像は、PNG ファイル内に workflow metadata を埋め込みます。読み込み方法は、画像を ComfyUI 画面にドラッグするか、メニューの “Load” から PNG ファイルを選ぶ形です。

前提条件は明確です。画像に metadata が残っていなければなりません。多くの SNS や画像ホスティングサービスは、アップロード時に画像を圧縮したり metadata を削除したりします。その場合、workflow データは失われます。SNS から保存した画像なら metadata が消えている可能性が高く、ドラッグしても空のキャンバスになるだけです。

基本は JSON ファイルを優先します。PNG metadata は作者自身が生成履歴を保存するには便利ですが、プラットフォームをまたいだ共有には向きません。

JSON と PNG Metadata の比較

観点	JSON ファイル	PNG Metadata
出典の信頼性	独立ファイルなので、プラットフォームに書き換えられにくい	圧縮ツールで metadata が削除されることがある
ノード情報の完全性	ノードタイプ、パラメータ、接続を完全に記録	同じだが、metadata が失われていないことが前提
向いている場面	プラットフォームをまたぐ共有、バージョン管理、アーカイブ	作者のローカル生成履歴
出典確認	ファイル名を追跡でき、説明文書も添付できる	画像だけでは追加説明を持てない
推奨度	優先して使う	作者が metadata 保持を明示したときだけ使う

workflow を受け取ったら、まず出典を確認します。ノード一覧、モデル一覧、README が付いているなら、JSON / PNG だけに頼るより安全です。

赤いノードへの対応：Core Node と Custom Node を分ける

workflow を読み込むと、“Missing” や “Unknown node type” と表示された赤いノードが出ることがあります。ここで急いでパッケージを入れないでください。まずノードの種類を見分け、検索先を決めます。

Core Node と Custom Node の違い

Core node は ComfyUI の内蔵ノードです。メインプログラムと一緒に入るため、通常は不足しません。代表例は Load Checkpoint、KSampler、VAE Decode、Save Image です。これらが赤くなるなら、ComfyUI のインストールが不完全な可能性があるため、再インストールやバージョン確認が必要です。

Custom node は、別途インストールする第三者拡張ノードです。代表例は IP-Adapter Apply、ControlNet Apply、FaceDetailer です。共有 workflow の赤いノードは、多くの場合 custom node の不足です。

見分けるにはノード名を見ます。IPAdapter、ControlNet、Impact のような有名拡張の接頭辞が含まれていれば、ほぼ custom node です。不確かな場合は、ComfyUI 画面で右クリックし、“Add Node” からノード名を検索します。Core node はデフォルト一覧に出ますが、不足している custom node は出ません。

Custom Node の探し方

custom node だと確認できたら、3 つの経路で探します。

ComfyUI Registry：ノードの公式レジストリシステムです。registry.comfy.org にアクセスし、ノード名や拡張パッケージ名で検索します。Registry には出典、インストール方法、依存関係が表示されます。ComfyUI のバージョンが対応していれば、Manager / Registry エコシステムからインストールできるノードもあります。

ComfyUI Manager：サードパーティの拡張管理ツールです。ローカルに Manager を入れている場合は、ComfyUI メニューの “Manager” → “Install Custom Nodes” でノード名を検索します。Manager は一致する拡張パッケージとインストール状態を表示します。これは ComfyUI core の機能ではなく、安定性はコミュニティメンテナンスに依存します。

GitHub 検索：Registry と Manager で見つからない場合は、GitHub でノード名を検索します。多くの custom node 作者は README にノード名を書いています。リポジトリを見つけたら、README に従って custom_nodes ディレクトリへ clone します。

Python 依存関係の問題

一部の custom node は追加の Python パッケージを必要とします。たとえば IP-Adapter は insightface、一部の ControlNet 拡張は onnxruntime を要求することがあります。

インストール方法は、custom node のリポジトリに入り、README または requirements.txt を確認します。ComfyUI のルートディレクトリで次を実行します。

pip install -r custom_nodes/node-directory/requirements.txt

README に pip install package-name が直接書かれている場合もあります。推測で入れるのではなく、その説明に従います。

実際に不足しているノードを確認する

1 つの workflow が 10 個以上の custom nodes を参照していても、ローカルで必要なのは実際に使われているものだけです。workflow を読み込んだあとの赤いノード一覧が、実際の不足リストです。流行しているノードパックをむやみに入れないでください。パッケージが増えるほど起動時間と競合リスクも増えます。

モデルが見つからないとき：ディレクトリと外部モデルライブラリを確認する

ノードを補ったあとも、Load Checkpoint、Load LoRA、Load VAE などのドロップダウンが空のことがあります。モデルファイルは JSON と一緒に共有されません。ComfyUI の models ディレクトリに手動で置く必要があります。

ComfyUI models ディレクトリ構造

ComfyUI は起動時に models 配下のサブディレクトリをスキャンし、種類ごとにモデルを読み込みます。よく使うディレクトリは次のとおりです。

ディレクトリ名	保存するモデル種類	workflow ノード例
checkpoints	Stable Diffusion checkpoint	Load Checkpoint
loras	LoRA ファインチューニングモデル	Load LoRA
vae	VAE デコーダ	Load VAE
controlnet	ControlNet モデル	Load ControlNet Model
ipadapter	IP-Adapter モデル	IPAdapter Model Loader

workflow の Load Checkpoint ノードが sdxl_base.safetensors を指しているなら、そのモデルを models/checkpoints/sdxl_base.safetensors に置きます。ノードのドロップダウンには、そのディレクトリ内のモデルが表示されます。

extra_model_paths.yaml の用途

モデルライブラリを別の場所、たとえば共有 NAS や集中管理フォルダに置いている場合、毎回 models ディレクトリへコピーする必要はありません。extra_model_paths.yaml で外部パスを指定できます。

設定ファイルは ComfyUI のルートディレクトリにあり、YAML 形式です。例：

my_custom_config:
  base_path: /path/to/external
  checkpoints: models/checkpoints
  loras: models/loras
  vae: models/vae
  controlnet: models/controlnet

ComfyUI は起動時に設定されたパスをスキャンし、デフォルトの models ディレクトリと合わせて表示します。形式はバージョンによって変わる可能性があるため、最終的には公式ドキュメントや起動時のヒントを確認してください。

モデルバージョンを確認する

モデル名だけでは判断できないことがあります。同じファイル名でも別バージョンのモデルかもしれませんし、別名にリネームされた同一モデルかもしれません。workflow を再現するときは、次を確認します。

• checkpoint 名とバージョン
• LoRA 名、バージョン、weight
• VAE ファイル
• ControlNet または IP-Adapter モデル
• 量子化、pruned、merged モデルを使っているか

モデルバージョンは出力差の大きな要因です。完全に同じファイルが見つからない場合は、同じアーキテクチャのモデルで一時的に代替できます。ただし、結果が完全には一致しないことを記録しておきます。

同じ workflow でも同じ画像にならない理由

ノードとモデルをそろえても、出力がサンプル画像と違うことがあります。これは普通です。workflow は再現環境の一部にすぎません。

パラメータ影響表

パラメータ	結果への影響	確認方法
seed	ランダムな出発点を決める	固定 seed かランダムかを確認
sampler	sampler により生成の進み方が変わる	KSampler の sampler 名を比較
steps	少なすぎても多すぎてもディテールと安定性が変わる	step 数を比較
CFG	prompt の効き方を調整する	CFG Scale を比較
画像サイズ	構図と VRAM 使用量を変える	幅と高さを比較
モデルバージョン	見た目への影響が最も大きいことが多い	ファイル名、hash、出典ページを比較
LoRA weight	スタイルや被写体の強さを変える	LoRA strength 値を比較
参照画像	構図、顔、ポーズの制約を変える	入力画像を使っているか確認
後処理ノード	顔補正、アップスケール、色味を変える	不要な後処理を一時的に無効化

モデルバージョンが最大の変数

サンプル画像が SDXL モデルで作られているのに、手元で SD1.5 モデルに置き換えると、結果はまったく違います。同じアーキテクチャ内でも、checkpoint のバージョンが違えば、画風、顔、照明、質感が変わります。

prompt を調整する前に、まずベースモデルが合っているか確認します。作者がモデルバージョンを示していない場合、再現目標は近似だと考えてください。

目標は「完全一致」ではなく「スタイルと構図を近づける」

共有 workflow の多くでは、現実的な目標は完全に同じ画像ではなく、スタイルと構図を近づけることです。完全再現には、同じモデル、同じパラメータ、同じ custom node バージョン、同じ参照画像、場合によっては同じ実行バックエンドが必要です。1 つでも条件が変わると、出力はずれます。

実用的な方法は、まず小さいサイズで主経路を試すことです。不要な後処理ノードを無効化し、seed を固定して、基本構図が近いか確認します。その後、アップスケール、顔補正、色処理のノードを 1 つずつ戻します。

コピーして使える Workflow 再利用チェックリスト

workflow を受け取るたびに、このリストを使ってください。

Step 1：出典を確認する

• 元の JSON または PNG ファイルを先に保存する。
• 作者、プラットフォーム、投稿、リポジトリなど、出典を記録する。
• README、モデル一覧、ノード一覧があるか確認する。
• PNG だけの場合は、metadata が残っているか確認する。
• 出典を確認する前に、自分のデフォルト workflow を上書きしない。

出典が不明で、多数の未知 custom nodes のインストールを求める workflow は慎重に扱います。workflow は単なる画像ではなく、実行可能な設定です。

Step 2：ノードを補う

• workflow をインポートし、赤いノード名をすべて記録する。
• core node と custom node を分ける。
• まず Registry または Manager で custom node を検索する。
• 見つからない場合は GitHub を検索し、README を読む。
• 1 回分をインストールしたら ComfyUI を再起動し、再確認する。
• まだ赤い場合は、モデルパスを変える前に custom node フォルダの requirements.txt を確認する。

チュートリアルで見たからという理由だけで、無関係なノードパックを入れないでください。この workflow が実際に必要とするものだけを入れます。

Step 3：モデルを対応づける

• Load Checkpoint、Load LoRA、Load VAE、ControlNet、IP-Adapter ノードが参照するモデル名を確認する。
• checkpoint は models/checkpoints に置く。
• LoRA ファイルは models/loras に置く。
• VAE ファイルは models/vae に置く。
• ControlNet と IP-Adapter のファイルは対応するフォルダに置く。
• 外部モデルライブラリを使う場合は extra_model_paths.yaml を設定する。
• ComfyUI を再起動し、モデルがドロップダウンに出るか確認する。

モデルバージョンの不一致は再現に最も強く影響します。まずここを確認します。

Step 4：パラメータを固定する

モデルがそろったら、workflow のパラメータを確認します。

• seed が固定されているか確認する。固定されていなければ、同じ画像は再現できず、スタイル調整しかできません。
• sampler、steps、CFG Scale、画像サイズを確認する。
• VAE が読み込まれているか、LoRA weight が設定されているか確認する。
• サンプル画像とパラメータを見比べ、明らかな差がないか確認する。
• 作者がパラメータ調整を明記している場合は、その説明に合わせる。

作者が JSON のエクスポート後にパラメータを微調整していることもあります。サンプル画像と JSON のパラメータが一致しないときは、手動でそろえます。

Step 5：最小構成で試す

パラメータを確認したら、まず簡単なテストをします。

• “a cat sitting on a chair” のようなシンプルな prompt で 1 回実行する。
• エラー、空白画像、明らかな崩れがないか確認する。
• エラーが出たら terminal log を見て、失敗したノードまたはモデルを特定する。
• 出力が正常なら、prompt とパラメータを少しずつ調整し、サンプル効果に近づける。
• 最初から複雑な prompt を使わない。複雑な prompt はノードやモデルの問題を隠すことがあります。

Step 6：名前を付けてアーカイブする

再現できたら、workflow を保存して整理します。

• workflow を新しい JSON ファイルとして保存する。
• 命名例：[topic]-[model-name]-[date]-v1.json。例：portrait-sdxl-base-20260623-v1.json。
• JSON コメントに頼らず、対応する README.txt でモデルバージョン情報を記録する。
• checkpoint 名とバージョン、LoRA 名と weight、VAE、sampler パラメータ、主要設定を記録する。
• あとで共有するなら、ノード一覧、モデル一覧、サンプル画像、パラメータ説明を添える。モデルファイル自体は共有しない。

このチェックリストをローカルにコピーし、workflow を再利用するたびに 1 つずつ確認できます。

Workflow 管理：命名規則と共有のコツ

再現に成功したあとは、整理とアーカイブで次回の再調査を減らせます。共有するときも、情報がそろっていれば相手のトラブルシュート時間を短縮できます。

命名規則

ファイル名が混乱していると、workflow が数十個に増えたときに探せなくなります。

推奨形式：[topic]-[model-name]-[date]-v1.json

例：

• portrait-sdxl-base-20260623-v1.json：portrait 用途、SDXL Base モデル、2026 年 6 月 23 日、バージョン 1
• landscape-sd15-controlnet-20260620-v1.json：landscape 用途、SD1.5 + ControlNet

トピックは portrait、landscape、anime、product、concept-art のような用途でかまいません。モデル名は主 checkpoint の短い名前にします。日付は YYYYMMDD 形式。v1、v2 で反復版を分けます。

モデルバージョンの記録方法

workflow JSON 自体は通常、モデルファイル名を記録するだけで、完全なモデルバージョンまでは記録しません。モデルライブラリに同名の複数バージョンがあると、次に開いたときにどれを使ったかわからなくなります。

対応する README.txt を使う

workflow と同じディレクトリに README-[file-name].txt を作り、checkpoint の出典、LoRA の weight、VAE の出典、sampler、steps、CFG、画像サイズ、結果を大きく変えるその他の主要パラメータを記録します。

モデルバージョン記録の主な情報源は README.txt にします。互換性が高く、JSON やサンプル画像と一緒にまとめやすいからです。

Workflow を共有するときのコツ

workflow を共有するときは、情報が完全なほど受け取る側が早く動かせます。

含めるもの：

• 完全な workflow ファイル。最優先です。
• すべての custom node 名と出典。Registry リンクや GitHub リポジトリなど。
• checkpoint、LoRA、VAE、ControlNet などのモデル名と出典メモ。直接ダウンロードリンクは載せません。
• 生成結果を 1 枚添え、再現目標を確認できるようにする。
• JSON のパラメータとサンプル画像が違う場合、実際に使ったパラメータを明記する。

含めないもの：

• ライセンスが複雑なため、直接共有しません。
• モデルライブラリのページ URL は許容できますが、直接リンクはリスクがあります。
• custom node に特殊な依存関係がある場合はパッケージ名を示し、正確なコマンドは README を読んでもらいます。

短い README を添え、上記の情報を書いておきます。受け取る側は推測ではなくチェックリストに沿って確認できます。

次に読むもの

まだ ComfyUI を入れていない場合は、まず ComfyUI 入門完全ガイド でインストール、モデルディレクトリ、最初の画像生成を確認してください。prompt の調整は Prompt Engineering のビジネス実践 を参照できます。メディア横断の AI 支援制作フローは メディアを横断する制作フロー を、ローカルで大規模言語モデルを動かす話は Ollama 入門 を読むとつながります。