mcpField
C
comfyui

comfyui

github.com/slavasextonクリエイティブ・メディア11256 回インストール10 週間前に更新
リポジトリ

comfyui について

ComfyUIは、ローカルのComfyUIを操作し、メディア生成ワークフローを構築するためのスキルキットです。タスク・モデル資料に加え、軽量なPythonクライアントとMCPドライバーの利用案内を含みます。

主な機能

  1. 01画像・動画・音声ワークフローのガイド
  2. 02モデルとノードのリファレンス
  3. 03ワークフローをキューに入れるPythonクライアント
  4. 04ワークフローのパラメーター変更と出力取得
  5. 05ワークフローのレイアウトと検証の指針
  6. 06ComfyUI MCPドライバーの利用案内

活用シーン

  1. 01ローカルのComfyUIワークフローを実行
  2. 02タスクに合うモデルやノードの情報を確認
  3. 03ワークフローを実行して生成ファイルを取得
  4. 04ワークフローグラフを構築して検査

MCP 対応

このキットは、生成、ワークフローの編集と検証、モデルのダウンロード、キュー管理、診断用の構造化ツールを備えたMCPドライバーcomfyui-mcpを案内します。利用可能な場合はドライバーを優先し、Pythonクライアントを代替手段として使います。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/slavasexton/comfyui-agent-kit --skill comfyui

インストール後、Claude Code で/comfyuiを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

ADVANCED.md
AGENTS.md
BOOTSTRAP.md
BUILDING_NODES.md
comfy_client.py
EXAMPLE_WORKFLOWS.md
KIJAI.md
KNOWN_ISSUES.md
LAYERS.md
LTX2_TRAINING.md
machine.md
MODEL_INDEX.md
MODELS.md
MODELS/
audio.md
image-api.md
image-edit.md
image-open-more.md
image-open.md
niche.md
three-d.md
utility.md
video-api.md
video-open.md
NODE_LIBRARY/
_INDEX.md
_INVENTORY.md
_SCHEMA.md
advanced.md
audio.md
color-and-transform.md
conditioning-1.md

詳細

ComfyUI:ローカルインストールの操作

ComfyUI を使って画像、動画、音声を生成またはレンダリングするタスクや、ComfyUI ワークフローを構築・実行するタスクでは、これを使ってください。まずこれを読んでから作業してください。

このキットに含まれるファイル(必要に応じて適切なファイルを読み込んでください)

自動で読み込まれるのはこの SKILL.md だけです。それ以外のファイルは関連する場合に読み込むため、未読のままにせず、必要に応じて参照してください。 2 つのディレクトリ構成、ファイルは同じです: インストール済みのスキルでは、すべてのファイルがこのファイルの隣にフラットに配置されるため、以下の docs/TASKS.md はここにある TASKS.md を、docs/NODE_LIBRARY/ocio.md は NODE_LIBRARY/ocio.md を指します。同様に、リポジトリ内の shared/tools/ にあるとドキュメントに記載されたスクリプトは、インストール後、このファイルの隣の tools/ にあります。リポジトリ内では、これらのプレフィックスはそのままのパスです。パスが解決できない場合は、ファイルがないと判断する前に docs/ を外し、このファイルの隣を確認してください。

  • MODELS.md(このファイルの隣にあります)- モデルごとのプロンプトレシピの一覧です。表でモデルを探し、プロンプトを書く前に、MODELS/ 内の該当するファミリーファイルを読んでください。読むのは2つです。1つではありません。一覧にはレシピの詳細が記載されていません。
  • 兄弟スキルの minimax-h3(名前を指定して呼び出します。ディスク上ではこのスキルの隣にあり、Claude Code と Codex では ../minimax-h3/、Gemini と Qwen では minimax-h3/ です)- 専用の MiniMax H3(Hailuo 3)スキルです。プロンプト形式(3つの名前付きフィールド、<d> ダイアログ、カメラ用語)、参照画像のラベル付け、量子化と高速化、症状と原因の対応表を扱います。H3 のプロンプトやローカルウェイトについての質問では必ず読みます。ノードレベルの詳細は MODELS.md にあります。
  • 兄弟スキルの krea(名前を指定して呼び出します。ディスク上ではこのスキルの隣にあります)- 専用の Krea スキルです。Krea のホスト型 API(Krea2ImageNode / Krea2StyleReferenceNode、画像ごとの料金、ムードボード、上限1K)とオープンウェイトの分岐、FLUX.1 Krea Dev グラフ、Krea Realtime 14B と、それに対応する ComfyUI パックが未検証の候補にすぎない理由、ControlNet / ID 編集 / コンディショニング制御用の Krea 2 カスタムノードパックについて説明します。API 経路やモデルの選択についてはこれを読みます。ローカルの Krea 2 グラフは MODELS.md にあります。
  • 兄弟スキルの seedance(名前を指定して呼び出します。ディスク上ではこのスキルの隣にあります)- 専用の ByteDance Seedance スキルです。3つのタスクタイプと、それらを切り替える単語、@Image 1 のラベル構文、全角記号のセット、ショットのシーケンス、アセット数のルール、2.5 で逆転したタイミングルール、失敗の対応表を扱います。Seedance のプロンプトでは必ず読みます。ノードレベルの詳細と料金計算は MODELS.md にあります。
  • docs/TASKS.md - 画像 / 動画 / 音声 / 3D の生成やアップスケール、背景の削除など、名前の付いた共通タスクについて説明します。このマニュアルを補う、そのタスクのローカルなエンドツーエンドの流れを記載しています。
  • docs/NODE_LIBRARY/smart-upscaler.md - Smart Upscaler パック(11ノード)について説明します。タイル分割アップスケーリングを行い、タイルごとに検証済みの個別プロンプトを書き出します。BUSY または MIXED なシーンをタイル分割アップスケールすると、確信ありげに誤ったタイルが生成されたり、継ぎ目が一致しなかったりする場合に読んでください。均一な被写体には、より安価な ADVANCED.md のサンプラータイル方式が引き続き適しています。
  • docs/MODEL_INDEX.md - 160モデルすべてを分類した完全な一覧(レシピ / ユーティリティ / テンプレートのみ)です。指定されたモデルにレシピがあるのか、ユーティリティなのか、テンプレートのみなのかを確認してください。
  • docs/NODE_LIBRARY/training.md - グラフがモデルにプロンプトを与えるだけでなく、モデルを作成するためのノードについて説明します。コアの TrainLoraNode / SaveLoRA / LossGraphNode と16個のデータセットノード(MakeTrainingDataset、 ResolutionBucket、画像テキストローダー、動画の時間方向クロップ)、および最初から最後まで接続した全工程を扱います。何かをトレーニングまたはファインチューニングしたいという依頼では必ず読みます。簡易ルートは docs/TASKS.md にあります。
  • docs/ADVANCED.md - 難しいタスクについて説明します。実際の強み、注意点と回避策、時間的一貫性、高精細なマッティング、クロップ・アンド・スティッチによるインペイント、PBR、ライセンス付きの検証済みツール一覧を扱います。
  • docs/KNOWN_ISSUES.md - 現在壊れている経路を迂回するような構成を組まないよう、構築前に読んでください。
  • docs/NODE_LIBRARY/_INDEX.md - ノードごとのリファレンス(Nuke スタイル)です。各ノードの各入力 / 出力の用途、動作、バグと修正策、アンチパターン、グラフ内での配置場所を説明します。ノードに関する質問では必ずここから読み始め、その後 get_node_info を使って最新の I/O を確認してください。ここに記載のないノードを使用または見つけた場合は、作業を終える前に項目を追加してください(docs/NODE_LIBRARY/_SCHEMA.md)。
  • workflow_layout.py - 作成したワークフローを保存する前に、必ずコード上で配置し、検証してください。auto_layout(wf) は依存関係の深さに応じてノードを左から右へ配置し、並列ブランチを縦に並べて、重なりをゼロにします。inspect(wf) は座標から重なり / 交差 / 範囲を報告します。fit_group(wf, title) は配置済みのノードを囲む背景パネルを作成し、機能グループ全体を端から端まで完全に覆います(ノードがはみ出さないようにします)。スクリーンショットからグラフのレイアウトを判断してはいけません(トークンを消費し、クライアントも同じ問題に直面します)。位置を確認してください。
  • docs/NODE_LIBRARY/ocio.md - 独自の ComfyUI-OCIO パック、v1.3.0(Nuke スタイルの OpenColorIO ノード11個:Read / Write / Player、6個のカラーオペレーター、標準の0..1クランプを行わずにデコードする OCIO VAE Decode / VAE Encode のペア。公開済み、github.com/SlavaSexton/ComfyUI-OCIO)について説明します。色管理 / VFX カラーに関するタスクでは必ず読みます(シーケンスの読み込み、ACES でのグレーディング、ProRes / EXR への書き出し、1.0を超える値や0未満の値を生成モデル内で保持するなど)。v1.3.0 では OCIO Write の from_colorspace が input_colorspace に変更されており、古いキーを含む API 形式のグラフは拒否されます。そのため、グラフを構築する前にこのファイルを読んでください。
  • docs/BUILDING_NODES.md - カスタムノードパックの作成について、実地で得たノウハウをまとめたガイドです(ウィジェットの順序、コンボ検証の落とし穴、JS フロントエンド、サーバールート、ComfyUI の仕様、実ファイルでの検証)。カスタムノードを作成または変更する際は、comfyui-node-* スキルとあわせて最初に読んでください。
  • docs/KIJAI.md - kijai エコシステム(同氏の ComfyUI ラッパーとノード:Wan / Hunyuan / CogVideoX / Florence2 / KJNodes / SUPIR / FramePack / SAM2 / FluxTrainer / IC-Light / DepthAnythingV2 など約50種類)について説明します。それぞれの機能とノード I/O、日付時点で有効なものとレガシーなもの、後継対応表(旧版 -> より優れた選択肢)を扱います。kijai のツールについては必ず読み、提供終了予定のラッパーではなく現行の選択肢を選ぶ際にも参照してください。
  • docs/NODE_LIBRARY/radiance.md - fxtdstudios/radiance のリバースエンジニアリング済みリファレンスです(プロ向けの32ビット色科学 / HDR / VFX スイート、78ノードと v3 の書き換え版。OCIO / カラー分野で公開されている最も強力なパックです)。色科学 / HDR / VFX ビューアーの実装を参考にする場合、独自の ComfyUI-OCIO パックを改善する場合(優先順位付きの「取り入れるべき点」一覧:プロセッサーのキャッシュ、WebGL 32ビットビューアー、OpenEXR ライター、LogC3-EI / LogC4 を掲載)、または radiance ノードに関わるタスクでは読んでください。ノード構築に関する知見は BUILDING_NODES.md に反映されています。
  • docs/LTX2_TRAINING.md - ユーザーが LTX-2 を使用しており、LoRA で捉えたい動作がある場合は、LoRA のトレーニング(公式 Lightricks トレーナー)を提案してください。
  • docs/EXAMPLE_WORKFLOWS.md - エンドツーエンドの実例と、複数モデルによる画像編集の比較テストです。
  • docs/NODES.md はグラフ内の Claude ノード(課金 / 目的)、docs/LAYERS.md は4つのインストールレイヤー、docs/BOOTSTRAP.md は初回マシンセットアップ、docs/AGENTS.md はエージェントごとの対応表(Claude / Codex / Gemini / Qwen)、docs/UPDATING.md はモデルとバグの週次更新サイクルです。

お使いのマシン

セッションで ComfyUI を初めて呼び出す前に、このファイルと同じ場所にある machine.md を読んでください。 このインストール環境の実際のパス、GPU、テンプレートライブラリの場所、起動コマンドが記載されています。意図的にこのファイルには含めていません。インストーラーは更新のたびに SKILL.md を上書きするため、マシン固有の情報をここに記載すると、次の git pull と再インストールで消えてしまい、ブートストラップをやり直す必要がありました(2026-08-06 の監査)。machine.md は一度だけ書き込まれ、上書きされることはありません。

machine.md がない場合、または山括弧のプレースホルダーだらけの場合は、今すぐブートストラップを実行します(docs/BOOTSTRAP.md):health_check、または comfy_client.alive() に加えて GET /system_stats と /object_info を実行し、実際の値を machine.md に書き込みます。別のマシンがサンプルと一致すると決めつけないでください。

4 つのレイヤー(このキットでインストールするもの)

  1. ナレッジとクライアント:この SKILL.md と comfy_client.py(標準ライブラリのみ、依存関係なし)。
  2. MCP ドライバー:comfyui-mcp(artokun、MIT):Claude が ComfyUI を直接操作するための約 90 個の構造化ツール(生成、グラフの構築/編集/検証、モデルのダウンロード、キュー、VRAM、診断、再起動)。利用できる場合は、/prompt への手動 POST よりもこちらのツールを優先してください。これは MCP SDK の 1.x 系列、つまりステートレス仕様(2026-07-28)より前のリビジョンに準拠しています。12 か月の非推奨期間中は引き続きサポートされるため、変更は不要です。独自の MCP サーバーを作成する場合は、まず docs/LAYERS.md のプロトコルに関するセクションを読んでください。制限のない mcp>=x の指定では SDK 2.x がインストールされるようになり、mcp.server.fastmcp が削除されているため、新規インストールが壊れます。
  3. グラフ内の Claude ノード:ワークフロー内のステップとしての Claude(プロンプトの拡充、出力のビジョン QA)。
  4. ノード構築スキル:カスタムノードを作成または変更する場合に使用する comfyui-node-*(V3 API)。

各レイヤーの説明は docs/LAYERS.md にあります。install.ps1 / install.sh でセットアップします。

クライアント(追加の依存関係なし、標準ライブラリのみ)

comfy_client.py はこの SKILL.md と同じ場所にあります。インポートして使用します:

import sys; sys.path.insert(0, r"<this skill dir>")
import comfy_client as c
c.alive()                                  # True if the API answers (override host with COMFY_HOST env)
c.run("path/to/workflow_api.json",
      overrides={"6.text": "a cinematic dragon, dark studio light", "3.seed": 12345},
      outdir=r"...\assets")                # queues, waits, downloads -> returns saved file paths

API の概要:alive()、run(workflow_path, overrides, outdir, timeout)、および queue(workflow)、wait(prompt_id)、download_outputs(rec, outdir)、apply_overrides(wf, overrides) の各関数です。オーバーライドキーは "<nodeId>.<inputName>" です(ノード ID と入力名はワークフロー JSON からそのまま取得します)。MCP ドライバー(レイヤー 2)でも同じことに加えて、さらに多くの操作ができます。利用できる場合は MCP ドライバーを使い、それ以外の場合はこのクライアントにフォールバックしてください。

ワークフロー JSON(API 形式)

ComfyUI は「API 形式」のグラフを実行します。これは { "<nodeId>": { "class_type": "...", "inputs": {...} }, ... } という辞書です。取得するには、ComfyUI で Settings -> Enable Dev mode Options を有効にしてグラフを作成し、Save (API Format) を選択します。公式の開始用グラフは、モデルごとの Workflow -> Templates ブラウザーから取得できます。これらを API 形式で保存してから、パラメーター化してください。

グラフをパラメーター化するには、内容を読み取り、次の項目を見つけます:

  • ポジティブプロンプト:CLIPTextEncode ノードを見つけ、.text をオーバーライドします。
  • シード:KSampler またはサンプラーノードを見つけ、.seed をオーバーライドします(呼び出しごとに異なるシードを使用し、ハードコードしないでください)。
  • 寸法:EmptyLatentImage または EmptySD3LatentImage ノードを見つけ、.width / .height をオーバーライドします。
  • ステップ数/CFG/サンプラー/スケジューラー:サンプラーノードにあります。依頼がない限り、テンプレートの値を維持してください。これらはモデルに合わせて調整されています。

テンプレートライブラリ(信頼できる唯一の情報源。組み合わせて使用できます)

公式の Comfy-Org ワークフローテンプレートは、ComfyUI であらゆるタスクを実行する方法を示す信頼できる唯一の情報源です。このキットはテンプレートをローカルフォルダーに(スパースチェックアウトで)クローンし、コンパクトな検索インデックスを作成します。既定の場所はインストーラーによって設定されます。上記のマシンブロックに記録してください。マスターインデックス:templates/_quick_index.json(名前 -> タイトル、カテゴリ、モデル、タグ、メディアタイプ、VRAM、説明)。shared/tools/gen_quick_index.py で再生成します。更新するには、クローン内で git pull を実行してから、ジェネレーターを再実行します。

流れ: _quick_index.json を読み、リクエストに合う名前/モデル/タグのテンプレートを探し、該当する templates/<name>.json を読み込んでパラメーターを設定します。新しいテンプレートではサブグラフを使用します。実際のパイプラインは definitions.subgraphs[0] の中にあり、公開されているパラメーター(テキスト、幅、高さ、シード、ステップ数、モデル名)は subgraphs[0].inputs にあります。これらは外側ノードの properties.proxyWidgets を介して内側のノードにたどれます。blueprints/ のブロック(再利用可能なサブグラフ部品:text_to_image_z_image_turbo、image_to_video_ltx_2_3、image_upscale_z_image_turbo、remove_background_birefnet、…)を組み合わせて使用します。

widgets_values はフィールド名ではなく順序に基づきます。KSampler = [seed, control_after_generate, steps, cfg, sampler, scheduler, denoise]、EmptySD3LatentImage = [width, height, batch] です。モデルのファイル名は、インストール済みのファイル名と完全に一致させる必要があります。グラフを書き込む前に、/object_info/<NodeType> でノードタイプ/入力を検証してください。

部品から新しいワークフローを組み立てる(組み立てて、正しく接続する)

単一のテンプレートで要件を満たせない場合は、部品を連結して組み立ててください。このスキルの目的は、実行だけでなく組み立ても行うことです。

1. タスクを段階に分解します。 各段階に1つの部品を割り当てます。例:テキストから画像 -> アップスケール -> 画像から動画 -> 音声を追加。各段階にテンプレートまたは blueprints/ のサブグラフを選び(_quick_index.json/ブループリント名で検索)、それぞれを読んで実際の入力ノードと出力ノードを確認します。

2. ノードの接続方法を把握します(重要な仕組み)。

  • API 形式: 各入力は、リテラル値または別のノードの出力への参照のいずれかで、参照は2要素のリスト ["<sourceNodeId>", <outputSlotIndex>] で記述します。ステージAの後にステージBを実行するには、Bの入力を ["<A_id>", <slot>] に設定します。<slot> はAの該当する出力のインデックスです。例:デコードノードの IMAGE をアップスケーラーに渡す -> "image": ["8", 0](ノード8、出力0)。
  • GUI 形式: 接続はトップレベルの links 配列に格納されます。各リンクは [link_id, src_node, src_slot, dst_node, dst_slot, type] で、各ノードの inputs[].link/outputs[].links にはそれらのリンク ID が格納されます。キャンバスにグラフを表示するには、この形式(ブリッジ)を書き込みます。実行には API 形式を書き込みます。

3. 型を一致させるか、変換します。 すべての出力と入力には型があります:IMAGE、LATENT、MODEL、CLIP、VAE、CONDITIONING、AUDIO、MASK、CONTROL_NET、… 一致する型同士のみ接続できます。/object_info/<NodeType> で各ノードの入力型と出力型(input.required/output/output_name)を確認します。接続箇所の型が異なる場合は、変換ノードを挿入します:VAEEncode(IMAGE -> LATENT)、VAEDecode(LATENT -> IMAGE)、CLIPTextEncode(テキスト -> CONDITIONING)、サイズ変更には ImageScale/アップスケーラーを使用します。IMAGE を LATENT 入力に接続してはいけません。 一般的なノードの入出力(これらを覚えてください。それ以外は /object_info/<NodeType> を確認してください)。 ノードのウィジェットは設定する値です。入力スロットには、別のノードの出力から一致するタイプを接続する必要があります。テキストを LoRA 入力に接続したり、モデルをテキストボックスに入力したりすることはできません。

  • CheckpointLoaderSimple -> 出力:MODEL、CLIP、VAE。(Flux/新しい分割ローダーの場合:UNETLoader -> MODEL、DualCLIPLoader/CLIPLoader -> CLIP、VAELoader -> VAE。)
  • LoraLoader:入力 MODEL + CLIP(+ 名前/強度ウィジェット) -> 出力 MODEL、CLIP。LoRA は MODEL + CLIP のストリームに適用するもので、テキストとして接続することはありません。
  • CLIPTextEncode:入力 CLIP + テキストウィジェット -> 出力 CONDITIONING。プロンプトはここで CONDITIONING になります。後続ノードが必要とするのは CONDITIONING であり、生のテキストではありません。
  • EmptyLatentImage/EmptySD3LatentImage:ウィジェットのみ -> 出力 LATENT。
  • KSampler/KSamplerAdvanced:入力 MODEL + 正の CONDITIONING + 負の CONDITIONING + LATENT(+ シード/ステップ数/cfg/サンプラー/スケジューラー/デノイズウィジェット) -> 出力 LATENT。
  • VAEDecode:入力 LATENT + VAE -> 出力 IMAGE。VAEEncode:入力 IMAGE + VAE -> 出力 LATENT。
  • ControlNetLoader -> CONTROL_NET;ControlNetApplyAdvanced:入力 CONDITIONING + CONTROL_NET + IMAGE -> 出力 CONDITIONING。
  • LoadImage -> IMAGE、MASK;SaveImage/PreviewImage:入力 IMAGE。 基本的な txt2img のストリーム:ローダー -> (LoraLoader)-> CLIPTextEncode x2(正/負)-> KSampler(+ EmptyLatentImage)-> VAEDecode -> SaveImage。構築を始める前に、既知の不具合がある経路を避けるため、このファイルと同じ場所、または docs/KNOWN_ISSUES.md にある KNOWN_ISSUES.md と ADVANCED.md も確認し、現在のバグと回避策を把握してください。

4. グラフをきれいに統合します。 2つのテンプレートをつなぎ合わせる場合は、一方のグラフのノード ID を振り直して重複しないようにします。ローダーは共有し(1つの CheckpointLoader/UNETLoader/VAELoader/CLIPLoader から両方のステージに接続し、同じモデルを重複させないでください)、そのうえで接続部分をつなぎます(ステージ A の最終出力 -> ステージ B の最初の入力)。各モデルには、それぞれの VAE/エンコーダーを対応させたままにしてください(Wan の VAE は SDXL の VAE ではありません。LTX はチェックポイントに VAE が含まれています)。

5. 実行前に検証します。 次を確認してください。すべての class_type が /object_info に存在すること、すべての入力がリテラル値、または既存ノードを参照する [node, slot] であること、すべての接続部分でタイプが一致すること、モデルのファイル名がローカルに存在すること、さらにグラフにユーザーの意図を受け取る INPUT ノードが少なくとも1つあり、最終テンソルに接続された OUTPUT/保存ノード(SaveImage/SaveAudio/SaveVideo/VHS_VideoCombine、または PreviewImage)が少なくとも1つあること。API/パートナーノード(Kling、Nano Banana、Veo、Gemini など)はテンソルを出力しても、デフォルトで保存ノードが含まれていないことがよくあります。保存ノードを追加して接続しないと、ジョブが「成功」しても取得可能なものが何も生成されず、計算リソースを浪費します。 その後、配線を確認するため、完全なレンダリングを行う前に、まず小さいサイズ/低解像度で実行してください。両方の形式を出力します。キャンバスに表示する GUI 用と、実行する API 用です。ノードの正確な入出力がわからない場合は、推測せず /object_info/<NodeType> を照会してください。

共有ワークフロー+モデル比較(ルックに最適なモデルを選ぶ)

名前付きのテンプレートライブラリに加えて、ComfyHub にはコミュニティが共有した数千ものワークフローが comfy.org/workflows/<hash> にホストされています。ComfyHub の共有リンクからは、予測可能な URL https://comfy.org/workflows/download/<hash>.json でプレーンな JSON をダウンロードできます。そのため、共有されたワークフローを必要に応じて取得し、読み込んだり実行したりできます。ヘルパー:python shared/tools/fetch_workflow.py <hash> <outdir>(標準ライブラリ)。<hash> は共有 URL 内の ID です。注:cloud.comfy.org/?share=<hash> のリンクは Comfy Cloud 専用で、この方法ではダウンロードできません(Comfy Cloud で開き、キャンバスからエクスポートしてください)。

モデル比較(このプロンプトに最適なモデルはどれか): テンプレートライブラリには、すでに比較グリッド templates-all_in_one-image_edit_models(「1 input and multiple editing model comparison」)が用意されています。1 枚の入力画像を 7 つの画像編集モデル(Flux.2 Dev/Klein、GPT-Image-1.5、Grok、Nano Banana Pro、Qwen-Image-Edit、 Seedream)に同時に渡し、各出力を並べて保存するため、採用する前に最適なルックを選べます。動画の場合、コミュニティ共有の「Adjustment Frame」(ハッシュ 7dca0438edf4)で、動画バックエンド(Grok/Kling/Veo/Seedance/Wan2.2/LTX-2)を比較できます。まず小規模/低解像度で実行して比較し、最良のものを選んでからスケールアップしてください。これは、以下のモデル別レシピとハードウェアを考慮した適合性チェックに役立ちます。

調査する価値のある実際の制作グラフ: Comfy-Org/creative-campus(github.com/Comfy-Org/creative-campus)には、Comfy Education Initiative の事例研究で実際に使われたワークフローや、受賞歴のあるアーティストの実際のグラフがまとめられています(例:学生アカデミー賞受賞映画『Song of Drifters』の Xindi Zhang による作品。IP-Adapter + ControlNet を使った SD1.5 スタイル転送や、3D + AI モーフィングのグラフ)。制作技法を学ぶために開いて調べてください。リンクして参照するのみです(ライセンスファイルはありません。アーティストの許可を得て共有されています)。JSON は同梱しないでください。

最新情報を把握する(新しいモデルとワークフロー)

ComfyUI では新しいモデルが絶えずリリースされ、まずテンプレートライブラリに追加されます。新着情報を確認するには、テンプレートのクローンで git pull を実行し、クイックインデックス(gen_quick_index.py)を再生成してから、モデル一覧を差分比較します(これまでにない名前が新しいモデル/テンプレートです)。また、アナウンスの RSS(https://blog.comfy.org/feed)も確認してください。このキットには、これらすべてを 1 つのコマンドで実行する shared/tools/check_updates.py(pull + 差分比較 + RSS)が含まれています。レシピのない新しい生成モデルが登場したら、公式のプロンプト情報(メーカーのドキュメント/モデルカード/docs.comfy.org)を調査し、同じ形式で MODELS.md に追加してください。新しいユーティリティ/アップスケーラーは Enhancement セクションに追加します。LinkedIn はスクレイピングしないでください(認証が必要で、スクレイピング対策があり、利用規約に違反します)。ブログの RSS とテンプレートリポジトリには、同じニュースが機械可読形式で掲載されています。一連の手順の詳細は、キットの docs/UPDATING.md を参照してください。

モデルごとのプロンプト作成(巨大な頭脳):モデル名を指定してプロンプトを作成する前に必ずお読みください

生成モデルにはそれぞれ独自の表現方法があります。SDXL はカンマ区切りのタグを求め、FLUX は自然言語の文章を求め、動画モデルはカメラと動きの方向を求め、音声モデルはジャンル/テンポ/楽器を求めます。また、ネガティブプロンプトへの対応状況はモデルによって異なり(FLUX や多くの Turbo モデルはネガティブプロンプトを無視したり、指定すると問題が発生したりします)、キットにはモデルごとのプロンプト作成リファレンス MODELS.md(このファイルと同じ場所にあります)が含まれています。これは各メーカーの公式ドキュメント/モデルカード、docs.comfy.org、および anthropic-claude ノードのモデル別テンプレートを要約したものです。

自動参照ルール。読み込みは 2 回です: リクエスト、ワークフロー、または選択したテンプレートで特定のモデルが指定されている場合は、MODELS.md を開き、「every model with a recipe」テーブルでそのモデルを見つけてから、プロンプトを書く前に MODELS/ 内の該当するファミリーファイルを読み込んでください。そのプロンプト構成、ネガティブプロンプトのルール、設定に従ってください。あるモデルのスタイルを別のモデルに使い回してはいけません。

MODELS.md は索引であり、リファレンスそのものではありません。2026-08-06 の監査でサイズが 174 KB と測定され、項目の 57% が読み込み時に内容が返されなくなる範囲を超えていたことが判明するまでは、1 つのファイルでした。そのため、ほとんどのモデルで、このルールは機能しているように見えながら、実際には何もしていませんでした。現在は、各ファミリーファイル全体を 1 回の呼び出しで読み込めます。

MODELS.md では、次のモデルを扱っています。(画像)FLUX.1/.2 + Kontext、Z-Image-Turbo、Qwen-Image/Edit、SDXL、SD1.5、SD3.5、HiDream、Ideogram、Nano Banana Pro/2、Seedream 4.x/5 Lite/5 Pro(5.0 Pro Layer Separation を含む)、Qwen Image 3.0 Pro(パートナーノードは core v0.32.0 でリリース)、Recraft、GPT-Image、Grok(Grok Imagine Image 2.0 および V2 編集ノードを含む)、Reve(core v0.31.0 で非推奨)、Kandinsky、BRIA、OmniGen、Chroma、Krea(core ノードの Turbo 画像スタイル参照 LoRA を含む)、ERNIE-Image、Mage-Flow(Microsoft 4B、ネイティブ解像度、MIT)。(画像編集)FLUX Kontext、Qwen-Image-Edit、FireRed、LongCat、ChronoEdit、JoyAI Image Edit、Mage-Flow-Edit。(動画)Wan 2.1-2.7(Uni3C カメラ軌道 ControlNet を含む)、Wan Animate 2(ローカルでのキャラクターアニメーション、ポーズ抽出なし)、LTX-2.5(オープンウェイトと API パートナーノードの両方、core v0.32.0 と同時リリース)、LTX-2.3 / 2 Pro(API ノードは現在非推奨)、Hunyuan Video、SVD、Kling、Veo、Sora、FLUX 3 Video(BFL、音声同期対応)、Seedance(1.0 / 1.5 Pro / 2.0 / 2.5)、Luma、Runway、MiniMax(H3、API とローカルのオープンウェイトを含む)、PixVerse、Vidu、Pika、Sync 3(リップシンク)、HeyGen(アバター動画、トーキングフォト、動画翻訳、TTS)、HappyHorse、HuMo、SCAIL-2。(音声)Stable Audio、ACE-Step、MiniMax Music 3(ボーカル入りのフル楽曲を生成するオープンウェイトモデル、core v0.33.1)、ElevenLabs、ChatterBox、Seed Audio、Sonilo。(3D) Hunyuan3D、Tripo、Rodin、Meshy。(新しいモデル/ニッチなモデル)Capybara、Bernini-R、Anima(ControlNet-LLLite 制御およびインペイントパッチを含む)、NewBie、PixelDiT、Ovis-Image、Lens、Quiver。

トーキングヘッドの振り分け: 静止したポートレート画像と音声トラックを使う場合は、Sync 3 と HeyGen Talking Photo のどちらも利用できます。すでにある映像のリップシンクの忠実度だけが目的なら Sync 3 を優先してください。モデルにスクリプトを話させる必要がある場合(テキスト読み上げ機能と音声ライブラリが組み込まれています)、または再利用可能なアバターとして表示させる場合は HeyGen を選んでください。どちらもシーンプロンプトは受け付けません。

また、Enhancement and utility セクションもあります(プロンプト駆動ではないため、プロンプトではなく設定を使ったパイプラインのステップとして利用します):アップスケール/復元/補間(Real-ESRGAN、SUPIR、SeedVR2、FlashVSR、Topaz、Magnific、FILM、RIFE)、セグメンテーション/深度/ポーズ/コンディショニング(SAM3、BiRefNet、Depth Anything、DWPose、MoGe、IP-Adapter、LivePortrait、Mediapipe)、および動画のオブジェクト除去(VOID)。ここに詳細が記載されていないモデルでは、テンプレートライブラリと /object_info を代わりに使用し、該当する公式ドキュメントへのリンクを参照してください。

グラフ内のClaudeノード(レイヤー3):適切なノードを選ぶ

インストール後、Claudeノードは3種類存在する可能性があります。それぞれ課金方法と用途が異なります(docs/NODES.mdを参照)。

  • AnthropicClaudeNode(カテゴリ LLM/Anthropic、コミュニティ製、自分のキーを使用)。特定のモデル(Ideogram 3、LTX 2.5、LTX 2.3 / LTX 2 Pro、Wan 2.1 & 2.2、FLUX、Nano Banana、Veo 3、Sora 2など)向けにプロンプトを書き換える40種類以上のテンプレートがあります。画像認識と拡張思考に対応しています。CLAUDE_API_KEY環境変数が必要です。グラフ内で自律的にプロンプトを拡充するための主力ノードです。
  • ClaudeNode(カテゴリ partner/text/Anthropic、公式のComfy-Org製)。Comfy.orgクレジットで課金され、自分のキーは不要です。最新のOpusまでのモデルを利用できます。代替手段です。
  • ClaudeCustomPrompt(Claude Prompt Generator)。シンプルなノードで、文字列入力としてapi_keyを指定します。

Claudeノードが必要なのは、Claudeを介さずにグラフでプロンプトを拡充する必要がある場合だけです(例:無人の自動ヒーロー画像生成パイプライン)。すでに自分で操作しているなら、プロンプトは自分で書くほうがよく、無料です。

ワークフローを構築し、オーナーのGUIにも表示する(双方向ブリッジ)

オーナーは、Claudeが構築したグラフを自分のComfyUIキャンバスで確認し、調整したい場合があります。このブリッジとなるのがGUIワークフローフォルダーで、双方が読み書きできます:<ComfyUI>/user/default/workflows/。

JSON形式は2種類あります。両方を覚えておいてください。

  • GUI形式(キャンバスが読み込み、「保存」で生成する形式):トップレベルに nodes(各ノードに id、type、pos、size、widgets_values、inputs、outputs)、links、groupsがあります。オーナーがグラフを開いて確認できるよう、この形式をワークフローフォルダーに書き込みます。ノードは左から右へ列状に自動配置します(ローダー -> エンコード -> サンプラー -> デコード -> 保存)。各ステージにはGroupボックスを配置し、列ごとにy座標のカーソルを使ってノードが重ならないようにします。具体的な配置方法については、以下の「グラフをきれいに配置する」を参照してください。
  • API形式(/promptの実行で使う形式):{ "<id>": {class_type, inputs} }。ヘッドレスで実行するには、この形式を送信します。

フロー:

  • Claudeが構築 -> GUI形式の.jsonをuser/default/workflows/<name>.jsonに書き込み -> 組み込みのWorkflowsサイドバー(フォルダーアイコン)を更新して開くようオーナーに伝えます -> オーナーはClaudeが構築したものをそのまま確認できます。
  • オーナーが構築・編集 -> API Formatで共有のworkflows/フォルダーに保存 -> Claudeが読み込んで実行します。

グラフをきれいにレイアウトする(構造化されたブロック、重なりなし)

ノードが 0,0 に積み重なったり、重なったりするグラフは、キャンバス上で使いものになりません。実際のパイプラインのようにレイアウトしてください。すべてのノードには pos:[x,y] と size:[w,h] があり、各ブロックは {title, bounding:[x,y,w,h], color} という groups エントリです。位置は計算してください。目分量で決めてはいけません。

  • 列=ステージ。左から右へ厳密に並べます。 パイプラインの各ステージを 1 列に配置します(ローダー -> コンディショニング -> サンプル -> デコード -> 保存 -> 後処理)。列の x 座標は x0 + col * COL_W、COL_W = 最も幅の広いノードの幅 + 80(通常は約 360)です。データが逆方向に流れることはありません(右から左へのワイヤーは禁止)。
  • 列ごとの y カーソルで重なりをなくします。 列の上から下へ積み重ねます。y = y0 とし、ノードを配置した後、y += node_h + 60 とします。次の配置位置は常に前のノードの全高より下になるため、同じ列のノードは重なりません。また、COL_W >= 最も幅の広いノード + 80 によって水平方向の重なりも防げます。テンプレートから実際の size を読み取ってください(およそ [320,200] と仮定し、KSampler / CLIPTextEncode はさらに高くなります)。2 つのノードに同じ pos を指定してはいけません。
  • ステージごとに 1 つのグループボックスを作ります(これでブロックとして見えるようになります)。 ステージのノードを配置したら、余白を含めて囲むグループを追加します。bounding は [minX-30, minY-50, (maxX+w)-minX+60, (maxY+h)-minY+80] とします(タイトルバー用に上部に余分なスペースを確保します)。ステージ名をタイトルにします(「モデルの読み込み」「コンディショニング」「サンプル」「デコード + 保存」「アップスケール」「画像から動画へ」)。色分けします(ローダーはグレー、コンディショニングは青、サンプラーは緑、デコード/保存は紫、後処理はオレンジ)。共有ローダーは左上の 1 つのグループにまとめ、すべてのステージに接続します。
  • 長いワイヤーや交差するワイヤーは引き直します。 共有出力を離れた列に接続する必要がある場合は、Reroute ノードを挿入し、グループ間の水平の空き領域に沿ってワイヤーを通します。グラフがごちゃごちゃして見えるのを防げます。
  • 保存前に整える作業を行います。 列ごとのノード幅をそろえ、左端を一直線に合わせ、シードと保存ノードを最後に配置します。すべてのノードを所属するグループボックス内に収め、グループボックス同士が重ならないようにします。MCP では visualize_workflow_hierarchical を使ってレイアウトを描画し、所有者に渡す前に重なりがないか確認できます。

ステージを 1 つの再利用可能なノードにまとめる(サブグラフ)

ComfyUI の サブグラフ(2025-08 から公式機能。旧 グループノードに代わるもので、旧機能は後方互換性のためにのみ維持されています)を使うと、複数のノードを選択して、必要な少数のパラメーターだけを公開する 1 つのスーパーノードにまとめられます。パイプラインの部品を構築して再利用する最もすっきりした方法です。テスト済みの 20 ノードのアップスケールや動画ステージを、3 つの調整項目を備えた 1 つのノードにでき、大きなパイプラインに入れ子にできます。

GUI では(所有者に伝えるか、操作する場合は自分で実行してください):

  • まとめる: ノード(グループと reroute も含む)を選択し、ツールバーのサブグラフアイコンをクリックします。ComfyUI が選択範囲の外部入力/出力を自動的に配線します。
  • 内部を編集する: サブグラフの空の領域をダブルクリックして中に入り、Esc または上部のナビゲーションバーで終了します(ナビゲーションバーには入れ子の階層が表示されます)。
  • 必要なものだけを公開する: Edit Subgraph Widgets ボタン(パラメーターパネル)を使うと、内部に入らずにウィジェットの並べ替えと表示/非表示の切り替えができます。編集モードでは、境界スロットを右クリックして名前の変更、削除、切断ができます。ラベル付きのデフォルトスロットを使うと、新しい入力/出力を追加できます。シード/ステップ数/cfg/プロンプトを公開し、それ以外は非表示にします。
  • 再利用可能な部品にする: Add Subgraph to Library(公開/ブックアイコン、ComfyUI v1.27.7 以降)を使うと、サブグラフが Subgraph Blueprint になり、他のノードと同じように検索してドラッグできます。これは、このキットの blueprints/ にある部品そのものです。
  • サブグラフの中にサブグラフを入れ子にして階層的なパイプラインを作成できます。Unpack subgraph(右クリックまたは選択ツールボックス)を使うと、サブグラフを元のノードに戻せます。

自分で JSON を構築する場合(クリック操作ではない場合):内部グラフは definitions.subgraphs[] に格納されます。外側の SubgraphNode は properties.proxyWidgets を介してパラメーターを公開し、境界の入出力はサブグラフの入力/出力ノードを介して公開します(上記のテンプレート読み取りに関する注意を参照してください)。ばらばらのノードを 20 個並べるのではなく、ステージごとにすっきりした部品を 1 つ用意してください。出典:docs.comfy.org/interface/features/subgraph ; blog.comfy.org/p/subgraph-official-release。

クリエイターレベルの深掘り:強み、実際の制約、シーケンス作業の高度なテクニック

クリエイターレベルの完全なリファレンス(強み、実際に注意すべき点と回避策、高度なシーケンステクニック、ライセンス付きの検証済みツール一覧)は ADVANCED.md にあります(インストール済みスキル内のこのファイルの隣、またはリポジトリ内の docs/ADVANCED.md)。難しい作業では、こちらをお読みください。開かなくても覚えておくべき重要な注意点は次のとおりです。

  • デコード後に画像が黒くなる/NaNになる、または色やコントラストが変わる場合はVAEが原因です。 --fp32-vae(または --bf16-vae)を使い、デコードは最後に一度だけ行い、ヒストグラム/LABマッチングで元のプレートに合わせてください。VFXでfp16 VAEは絶対に使わないでください。
  • カスタムノードが再実行されない場合は、IS_CHANGED の落とし穴です。return float("NaN") を返して再実行を強制してください。シードを変えても何も起きない場合は、キャッシュが古い状態です。入力を変えてキャッシュを無効化してください。
  • **生成ごとにモデルの再読み込みが繰り返される、または4090/5090で速度が低下する(2026年初頭以降)**場合は、Dynamic VRAMが原因です。問題が起きる場合は --disable-dynamic-vram を指定してください。
  • 巨大なグラフでキャンバスのFPSが1桁になるのは、バックエンドではなくlitegraphが原因です。サブグラフにまとめ、グループをミュートしてください。
  • カスタムノードには実際のマルウェアリスクがあり、core/numpyの更新で壊れることがあります。 検証済みの作成者のものだけをインストールし、バージョンを固定してください。

このスキルで対応できるようになった高度な作業(検証済みツールとレシピはADVANCED.mdに記載):

  • シーケンスの時間的安定性/ちらつき防止: ネイティブ動画モデル(Wan 2.2 + VACE/HunyuanVideo 1.5/LTX-2)> コンテキストウィンドウ + FreeNoise > 構造を固定するフレームごとの深度/ポーズControlNet > 軽量RIFE + 軽量デフリッカー。SD時代の手法:アンサンプリング(Flip Sigma、Euler、add-noise OFF)+ フローアテンション。細かなテクスチャ/アイデンティティとウィンドウの継ぎ目には、依然としてちらつきが残ります。
  • 映像からのPBR/マテリアルパス: 正直に言うと、2Dシーケンスから時間的に安定したネイティブPBRを生成する方法は、2026年時点ではまだ解決されていません。フレームごとに分解(Apache-2.0のMarigold-IID + StableNormal + StableDelight)し、オプティカルフローで時間方向に平滑化するのが現実的な方法です。rgb2x/CHORDは忠実度が高いものの非商用です。UniRelightは唯一の真の時間的手法ですが、アルベドのみ、非商用、ノードなしです。TRELLIS.2(MIT)は実際のPBRを生成できますが、フレームごとではなく3Dメッシュ上で行います。
  • ディテールと精度を最大限に高める: タイル分割リファイン(Ultimate SD Upscale/Tiled Diffusion)+ 継ぎ目用ControlNet Tile、微細なディテール用Detail Daemon/PAG/FreeU、dpmpp_2m + Karrasで約20~35ステップ、VFX向けに32ビットEXRシーケンスI/O(HQ-Image-Save、CoCoTools)+ sRGB/Linear変換を使用します。フレームごとのディテールとフレーム間の安定性には、実際にトレードオフがあります(SeedVR2をバッチサイズ>= 5で使うか、構造を固定して微細なディテールのみを変化させてください)。
  • 細部まで精密なマッティング(髪/毛皮/半透明部分/モーションブラー): 複数段階で行います。粗い選択(SAM3/BiRefNet)-> トライマップ -> アルファマット(ViTMatte/SDMatte/Matte-Anything)-> エッジリファイン(LayerStyle MaskEdgeUltraDetailV2)。動画には、時間的モデルのMatAnyone2(SAM2/SAM3/SeCのキーフレームマスクが必要。NTUの研究ライセンス)か、輪郭がきれいな人物向けのRVMを使います。公式ライブラリには remove_background_birefnet(画像)+ SAM3セグメンテーションが含まれますが、無料でローカル実行できる時間的動画マットはありません(動画マットのテンプレートは有料のBria APIです)。完全なレシピはADVANCED.mdにあります。
  • 2つの形式の同期を保ちます。一度ビルドして、両方を出力してください。書き込む前に /object_info/<NodeType> に照らしてノード名と入力を検証し、開いたときにグラフが赤く表示されたり壊れたりしないようにしてください。

この用途に追加の「エージェントパネル」ノードは必要ありません。組み込みのWorkflowsサイドバーが橋渡し役です。(comfyui-mcp エコシステムにはライブストリーミング用のオプションパネルがありますが、これは見栄えを良くするためのもので、必須ではありません。)

モデルの保存場所とダウンロード方法(推測せずに検出する)

ComfyUI は、1 つ以上のモデルルートからモデルを読み込みます。ソースからインストールした場合は <ComfyUI>/models/<type>/ です。Comfy Desktop では、通常、extra_model_paths.yaml で設定された SHARED フォルダーが有効なルートであり、<ComfyUI>/models ではありません。ダウンロードする前に、必ず実際のルートを検出してください。間違ったフォルダーに置いたファイルは、ComfyUI から認識されません。

まず、実際のモデルルートを検出します。

  • ComfyUI の起動ログを読み取ります。モデルタイプごとに Adding extra search path <type> <PATH> が表示され、さらに Setting output/input directory to: ... も表示されます。これらの PATH が正しい場所です(MCP の get_logs、または Desktop のログファイル)。
  • または、<ComfyUI>/extra_model_paths.yaml(および .example)を読み取ります。
  • または、稼働中のサーバーに問い合わせます。/object_info/CheckpointLoaderSimple、/UNETLoader、/VAELoader、/CLIPLoader には現在認識されているファイルが一覧表示されます。ファイルを配置した後に確認すれば、フォルダーが正しく接続されていることを確認できます。

モデルタイプ -> サブフォルダー(検出したルートの下):

  • diffusion / UNET の単一ファイルモデル -> diffusion_models(unet の場合もあります)
  • フルチェックポイント(model+clip+vae を同梱。一部の LTX などの動画モデルはこの形式です) -> checkpoints
  • テキストエンコーダー / CLIP(T5、umt5、gemma、clip_l、llava) -> text_encoders(古いインストールでは clip)
  • VAE -> vae · LoRA -> loras · アップスケーラー(ESRGAN など) -> upscale_models
  • ControlNet -> controlnet · IP-Adapter -> ipadapter · CLIP vision -> clip_vision

ダウンロード方法(Desktop でも安全):

  • 直接ダウンロードが最も確実です:curl -fL -C - -o "<root>/<type>/<filename>" "<url>"。Comfy-Org が再パッケージした Hugging Face リポジトリの公式リンク(.../resolve/main/... の直接リンク)を使用してください。-C - を指定すると、途中までダウンロードしたファイルの続きを取得できます。数十 GB の大きなモデルもバックグラウンドでダウンロードできます。完了後にサイズを確認してください。
  • COMFYUI_PATH が必要なのはダウンロードだけではなく、MCP ツールの一群全体です。 設定されていない場合、HTTP API ではなくインストール先のファイルシステムを読み取るツールはすべて COMFYUI_PATH is not configured で失敗します。最初に問題になるのは list_output_images です。これは、生成した画像を探すときに自然に使うツールだからです。2026-08-06 の実行環境で確認済みです。設定不要の回避策があります。 GET /history/<prompt_id> からファイル名を取得し、GET /view?filename=...&type=output&subfolder=... からファイルの内容を取得してください。これは純粋な HTTP 通信なので、常に動作します。ファイルシステム関連のツールも使う場合は、COMFYUI_PATH に実際の ComfyUI ルートを設定してください。
  • MCP の download_model が動作するのは、MCP サーバーに COMFYUI_PATH が設定されている場合のみです。また、ファイルは COMFYUI_PATH/models/<type> に保存されますが、Desktop では通常、この場所は共有ルートではないため、ComfyUI から認識できない場所にファイルが保存される場合があります。検出したルートに直接ダウンロードするか、先に COMFYUI_PATH を実際のルートに設定してください。
  • アクセス制限のあるモデル(Stability Stable Audio など)では、Hugging Face へのログインとライセンスの承諾が必要です。所有者にライセンスを承諾してファイルを配置してもらうか、認証付きダウンロード用の HF トークンを提供してください。
  • モデルごとに必要なファイル一式(diffusion model + text encoder(s) + VAE、および各ファイルの配置先フォルダー)は、モデルの docs.comfy.org/tutorials/... ページに記載されています。量子化レベルやファイル名を推測せず、記載内容に従ってください。
  • ダウンロード後、ComfyUI が認識していることを確認します:/object_info/<LoaderNode> に再度問い合わせてください。ほとんどのモデルフォルダーはリアルタイムで更新されますが、新しいサブフォルダーの場合は、Workflows サイドバーを更新する必要がある場合があります。

このマシンに適したモデルバリアントを選ぶ(ハードウェアを考慮し、ダウンロード前に推奨する)

モデルをインストールまたはダウンロードする前に、実際のハードウェアに照らしてサイズを確認し、やみくもにダウンロードせず、推奨してください。3つの数値を検出し、モデルの容量と比較します。

検出(ブートストラップのマシン情報ブロックを再利用するか、更新します):

  • GPUごとのVRAM(空き容量+合計容量):MCP get_system_stats / health_check、または GET /system_stats (devices[].vram_free / vram_total)。GPUが2枚ある場合は、それぞれ個別に記録してください。
  • システムRAM(空き容量+合計容量):同じく /system_stats。RAMは重みのオフロードやスワップに関係します。
  • MODELドライブの空き容量:検出されたモデルルートを保持するドライブを確認します(システムドライブではありません)。 Git Bashでは df -h "<model root>" を実行し、またはプラットフォームに応じた同等の方法を使います。ダウンロードサイズは数十GBに及ぶため、収まらない場合は絶対に開始しないでください。

モデルの容量を見積もる:

  • 必要なVRAMは、おおよそ拡散モデルのディスク上の重みサイズにVAE、テキストエンコーダー、アクティベーションを加えた量です(目安:重みサイズ+約2~6 GBの余裕。動画モデルでは潜在フレームのため、さらに多く必要です)。
  • 精度の段階は、小さいほど収まりやすくなります:bf16/fp16(フル)> int8-convrot と fp8(約半分)> GGUF Q8 > Q6 > int4-convrot と Q4(最小)。MODELS.md には、モデルごとの推奨バリアントとVRAMに関する注意事項が記載されています。
  • 半分のサイズの段階では、モデルがfp8のみを提供している場合を除き、fp8よりint8-convrotを優先してください。 core v0.27.0からネイティブ対応しており、fp16より高速で、品質はfp8と同等かそれ以上です。TuringとAmpere(RTX 20xx / 30xx)にも明示的に対応しています。手法全体、ConvRot論文、変換ツール、既知のint8のバグについてはdocs/ADVANCED.mdを参照してください。この1行は要約であり、選択のルールそのものではないため、バリアントを選ぶ前に必ず読んでください。
  • 「Pruned」は、この段階の一つではなく、4つ目の軸です。 Prunedチェックポイントは精度を下げるのではなく、重みを削除します。そのため、上記のいずれとも組み合わせられ、品質への影響はモデルによって異なります。 nvfp4はBlackwell世代の形式(RTX 50xx)です。Ampereでは選択できません。
  • ディスク上のダウンロードサイズは、おおよそすべてのファイル(モデル+エンコーダー類+VAE)の合計です。まず合計してください。

判断して推奨する:

  • 1枚のGPUに余裕を持って収まる場合 -> フル精度で使用します。
  • 1枚のGPUには少し大きすぎる場合 -> ComfyUIの重みオフロード(重みをRAMに置き、VRAMにストリーミング)またはfp8バリアントを使います。これを推奨し、bf16を無理に使わないでください。
  • 1枚のGPUには大きすぎるものの、2枚のGPU全体には収まる場合 -> MultiGPU DisTorchのレイヤー分割を使います(この場合に限ります。速度は低下します)。
  • 分割しても合計VRAMを超えるものの、RAMが十分に大きい場合 -> CPU/RAMオフロード(低速)またはGGUF Q4/Q5を使います。量子化版を推奨してください。
  • どの精度でもVRAMが不足する、または空きディスク容量が不足する場合 -> ダウンロードしないでください。具体的な不足量(例: 「LTX-2.3 fp8はディスク上で約28 GB、VRAMは約24 GB必要ですが、モデルドライブの空き容量は12 GBしかありません」)と、最も安価な解決策(小さいバリアント、ディスクの空き容量を増やす、または見送る)を伝えてください。
  • 他のGPUユーザー(Ollama)と調整してください。空きVRAMが使用中の場合があります。VRAMのセクションを参照してください。

ダウンロードの前には必ず: ダウンロードサイズの合計をモデルドライブの空き容量と比較し、モデルの必要VRAMを実行先のGPUと比較してください。結果だけでなく判断理由も所有者にわかるよう、結論を伝えてください:「収まるため、ダウンロードします」/「24 GBには大きすぎるため、fp8を使用します」/「E:の空き容量は10 GBしかなく、約28 GBは収まらないため、中止します」。

複数の GPU を使用する(レイヤー分割型の LLM サーバーとは異なります)

1 回の生成は 1 枚のカードで実行されます。ComfyUI は 1 つの小さなジョブを複数のカードに自動で分散しません。
MultiGPU ノード(SelectModelDevice、SelectCLIPDevice、SelectVAEDevice、MultiGPU_WorkUnits)で得られるメリット:

  • カード間でコンポーネントをオフロード(モデル -> cuda:0、CLIP + VAE -> cuda:1):メインカードの VRAM を解放し、大型モデル(大規模な動画/画像モデル)を収められます。
  • DisTorch によるレイヤー分割(MultiGPU_WorkUnits):1 枚のカードに収まらないモデルのレイヤーを複数のカードに分散します。モデルが 1 枚のカードに収まらない場合にのみ使用してください。
  • 並列スループット:カード 1 枚につき 1 つ、別々の生成を 2 つ同時に実行できます(バッチ処理に最適です)。1 枚の画像を分割するのではなく、生成画像の数が 2 倍になります。

ターボ画像モデルは通常、24GB のカード 1 枚に収まります。マルチ GPU は大規模な動画モデルで利用してください。

VRAM の調整(重要な注意点)

同じ GPU で別のワークロード(例:Ollama 経由のローカル LLM)も実行している場合、GPU リソースを奪い合います。ComfyUI で負荷の大きいバッチを実行する前に、GET /system_stats で空き VRAM を確認してください。空きが少ない場合は、別のワークロードがカードを使用しています。対処方法:それを解放し(ollama stop <model> を実行するか、サーバーを停止する)、バッチを実行してから、再読み込みさせます。または、別のワークロードがアイドル状態のときに ComfyUI を実行してください。NVIDIA ドライバーを再インストールした後は、別の GPU サービスを再起動してください(CPU にフォールバックする場合があります)。

MCP 経由で Comfy Desktop を絶対に再起動しないでください(重要な注意点)

Comfy Desktop のインストールに対して、MCP の restart_comfyui/start_comfyui/stop_comfyui を呼び出さないでください。MCP の再起動処理は CLI からの起動(python main.py)を前提としているため、spawn ComfyUI\main.py ENOENT というエラーで失敗します。サーバーは強制終了されますが、再起動できません。Desktop は Electron アプリであり、独自の引数(ポート、共有モデルディレクトリを指定する extra_model_paths)を使ってサーバーを起動するためです。python main.py で手動再起動しても、この設定が反映されません(「ComfyUI を自分で起動する」を参照し、--base-directory/--extra-model-paths-config を渡せば解決できます)。また、Electron の GUI ウィンドウは対話型でないシェルから起動できません(ただし、必要なのはサーバーだけであり、GUI は不要です)。したがって、Desktop では MCP による再起動を使わず、自分でサーバーを起動してください。新しくインストールしたカスタムノードを読み込むには、OWNER にアプリを再度開くよう依頼してください。CLI/ソースからの ComfyUI では、MCP による再起動を使用できます。

ComfyUI が停止しているときに自分で起動する(サーバーの自動起動)

生成には ComfyUI の GUI ウィンドウではなく、ComfyUI サーバー(:8188 の API)が必要です。サーバーが停止している場合は、アプリを開くよう所有者に頼むだけでなく、記録済みの起動コマンド(BOOTSTRAP マシンブロックに記録)を使ってバックグラウンドで自分でサーバーを起動し、:8188 が応答するまで待ってください。

  • ソース/CLI インストール: ComfyUI ディレクトリから python main.py をバックグラウンドプロセスとして実行します。:8188 にバインドされます(GUI ではなくコンソールサーバーなので、バックグラウンドシェルから起動できます)。指示された場合に限り、--listen/--port を追加します。

  • Comfy Desktop(Electron): Electron ウィンドウではなく、バンドルされたサーバーをヘッドレスで起動します。Desktop の venv の Python を使い、ComfyUI コアディレクトリの main.py を実行して、共有モデルを認識させます。素の python main.py では誤った(空の)モデルディレクトリが読み込まれる場合があるため、共有モデルを参照できるよう --base-directory <Desktop base> または --extra-model-paths-config <the Desktop's extra_model_paths.yaml> を渡します。マシンごとに、動作する正確なコマンドを一度だけテストしてから BOOTSTRAP マシンブロックに記録します(起動後、/object_info/UNETLoader に実際のモデルが一覧表示されることを確認します)。所有者がキャンバスを表示または調整したい場合にのみ GUI が必要です。

  • Windows:起動時に PYTHONUTF8=1(または PYTHONIOENCODING=utf-8)を設定します。 カスタムノードは絵文字をログに出力します(例:rgthree の「Loaded 48 nodes」の後にパーティーの絵文字が付きます)。UTF-8 以外のコンソールコードページ(cp1251 など)では、ロガーが UnicodeEncodeError を発生させ、モデルパスを読み取った後、起動途中でクラッシュします。Desktop アプリは自動で UTF-8 を設定しますが、素のヘッドレス起動でも設定が必要です。検証済み:これを設定しないと起動時にサーバーが終了し、設定すると正常に起動します。

  • Desktop インストールでは MCP の restart_comfyui/start_comfyui を使わないでください(前述の問題を参照)。自分で記録したコマンドを使います。

  • アプリのプロセスがすでに存在するのに :8188 が停止している場合: 初回起動時のモデル読み込み中か、処理が停止している可能性があります。少し待ってポーリングし、停止したままなら、2 つのサーバーは :8188 を共有できないため、2 つ目のサーバーを起動せず、アプリを再度開くよう所有者に頼んでください。

  • 起動中のサーバーを所有者に見せる場合: ヘッドレスサーバーはすでに http://127.0.0.1:8188 で ComfyUI の完全な Web UI を提供しています。所有者にキャンバスや作成したものを見せるには、Comfy Desktop のショートカットをクリックするのではなく、その URL をブラウザーで開くよう伝えてください(Desktop ウィンドウと同じ UI です)。ショートカットをクリックすると :8188 で 2 つ目のサーバーが起動し、競合します。ブラウザーのタブを閉じてもサーバーは動作し続けます。完全な Desktop アプリを使いたい場合は、まず自分のサーバーを停止してからアプリを開いてもらい、そのアプリのサーバーに再接続します。

起動後、GET /system_stats が応答するまでポーリングします(初回起動ではモデルの読み込みに 10~30 秒かかる場合があります)。その後、処理を続け、サーバーを起動したことを所有者に伝えます。

セッションプロトコル(起動方法を確認し、後でオーナーが見つけられるように保存します)

2 つのアクセスモードと 1 つの永続化ルールがあります。何も失われないよう、オーナーに明確に伝えてください。

起動(ComfyUI が停止している場合は最初に確認します)。 :8188 がすでに起動している場合は、そのまま使用してください(オーナーが ComfyUI を開いているか、サーバーが実行中です)。別のサーバーは起動しないでください。停止している場合は、一度だけ確認します。「ComfyUI をご自身で開いて接続しますか。それともヘッドレスでサーバーを起動しましょうか(ブラウザーで http://127.0.0.1:8188 を確認できます)?」オーナーの選択に従ってください。「自動で起動して」と言われた場合は、その設定を記憶し、次回から質問を省略します。

起動ポリシーの設定(プロジェクトとパイプライン)。 確認できるのは対話形式の場合だけです。無人のパイプラインでは、エージェントが処理を止めないよう、事前に選択肢を設定する必要があります。次の順に確認し、最初に見つかった設定を使用してください。

  1. 環境変数(優先度が最も高く、CI/実行ごとに設定):COMFY_HOST(サーバーの場所)、COMFYUI_START_POLICY = connect(実行中のサーバーに接続し、停止中なら明確なエラーを表示) | autostart(停止中ならヘッドレスサーバーを起動) | ask(対話形式)、COMFYUI_LAUNCH_CMD(autostart で使用するヘッドレス起動コマンド)。
  2. プロジェクト設定: プロジェクトルートに .comfyui-agent.json を配置します。例: { "host": "127.0.0.1:8188", "startPolicy": "autostart", "launchCmd": "..." }。プロジェクトと一緒にコミットされるため、プロジェクトごとにパイプラインを再現できます。
  3. マシンのデフォルト: このスキルのマシンブロックにある起動コマンドとホスト。
  4. フォールバック: 対話形式の場合は確認します。対話形式でなく、何も設定されていない場合は connect を使用し、明確なメッセージを表示して失敗します(指示がないまま CI でサーバーを起動しないでください)。

つまり、対話形式ではオーナーに確認します。パイプラインでは一度 COMFYUI_START_POLICY=autostart と COMFYUI_LAUNCH_CMD(または .comfyui-agent.json)を設定すれば、無人で実行できます。comfy_client はすでに COMFY_HOST を読み取ります。以下の永続化ルールは、どちらの場合にも同じように適用されます。

永続化(常に適用する重要なルール)。 オーナー向けのワークフローを作成または実行したら、必ず GUI 形式の .json として <ComfyUI>/user/default/workflows/ に保存し、内容が分かる日付入りの名前を付けてください(例: 2026-06-21_zimage_hero.json)。このファイルはユーザーディレクトリに永続的に保存されるため、ヘッドレスサーバーの停止後や、後日 Desktop セッションで作業する際にも、オーナーは Workflows サイドバーから開けます。API で生成するだけではキャンバスに何も残らないため、保存しなければ作業内容を確認できません。(GUI 形式にする方法については、双方向ブリッジのセクションを参照してください。)

引き継ぎ。 作業を終えたら、オーナーに次の 3 点を伝えてください。保存したワークフロー名(Workflows 内)、出力ファイルの場所、今すぐ確認する方法(ブラウザーで :8188 を開くか、保存したワークフローをいつでも開く)。完全版の Desktop アプリを使用したい場合は、そのアプリが :8188 を使用できるよう、先にヘッドレスサーバーを停止してください。

手順(毎回実行)

  1. health_check(MCP)または comfy_client.alive() を実行します。起動中なら使用してください。停止中ならセッションプロトコルに従い、オーナーに起動方法を確認するか、オーナーが常時希望している設定に従って、記録済みの起動コマンドでヘッドレスサーバーを自動起動します。:8188 が起動するまで待ってから続行します。新しいマシンでは、最初に BOOTSTRAP を実行してください。
  2. テンプレートのクローンから適切なテンプレートを選ぶか読み込みます(_quick_index.json を使い、モデル/タグで照合します)。適切なものがなければグラフを作成し、/object_info を参照してノードタイプを検証します。
  3. /system_stats で VRAM を確認します。残量が少ない場合は、ほかの GPU ワークロードと調整してください。
  4. パラメーター(プロンプト、異なるシード、寸法)を設定して実行し、出力を取得します。
  5. 出力を使用する前に、画像を読み込むか MCP 経由で表示して、目視で確認します。未確認の生成物を納品しないでください。
  6. 作成または実行したワークフローは必ず GUI 形式の .json として <ComfyUI>/user/default/workflows/ に保存し、内容が分かる日付入りの名前を付けてください(セッションプロトコルを参照)。これにより、オーナーは後から見つけて開けます。その後、名前、出力、確認方法を伝えてください。

コメント