ComfyUIのNode Docsの読み方｜入力・出力・データ型からノードを理解する

ComfyUIの知らないノードは、Node Docsを「入力・処理・出力」の3要素と「各端子に何のデータ型が流れるか」で読めば、説明記事を探さなくても自力で理解できます。型の意味さえ分かれば、配布Workflowを左から右に追う作業も、Docsが無いCustom Nodeをコードから確認する作業も、同じ手順で進められます。

情報確認日：2026年8月22日（日本時間）

結論：ノードは「何を受け取り、何を出すか」で読み、型は「何が流れるか」で覚える

責任範囲

Node Docsの開き方と、入力・処理・出力の順に読む考え方
MODEL・CLIP・CONDITIONING・LATENT・IMAGE・VAEなどのデータ型を「何が流れるか」で理解する表
required・optionalの違いと、Widget（直接入力値）と接続（別ノードからの入力）の見分け方
配布Workflowを依存順に読む手順と、Docsが無いCustom Nodeの調べ方
個別ノードを全件解説する辞書にはしない。KSamplerの各値はKSamplerの記事、Workflow JSONの読み込みはworkflow JSONの記事に渡す

Nodeは入力・処理・出力で読む：未知のノードでも3要素に分ければ読める

ComfyUIのノードはすべて「左側の入力を受け取り、内部で処理し、右側の出力を返す」関数です。見たことのないノードに出会ったら、名前から推測する前に次の3つを順に確認します。

入力：左側の端子とWidgetに何があるか。型の名前と、必須か任意か
処理：Docsの説明文が「入力をどう変えるか」を一文で言っているか
出力：右側の端子の型は何か。入力と同じ型が出るのか、別の型に変わるのか

Node Docsは、現行UI（2026年8月時点）ではノードを選択したときに出る選択ツールボックスの「node info」アイコンから開き、パネル左上の矢印アイコンで閉じます。アイコンの位置や名称はversionで変わるので、見当たらなければ公式ドキュメントで最新の名称を確認してください。組み込みノードのDocsは公式のembedded-docsリポジトリから供給され、Custom Nodeの作者が同じ形式で同梱していれば同じパネルに表示されます。

たとえばCLIP Text Encodeを3要素で読むと、次のようになります。

CLIP Text Encode
  入力: text (STRING, Widget) / clip (CLIP, 接続)
  処理: textをCLIPモデルで数値の列（embedding）に変換する
  出力: CONDITIONING

「文字列とCLIPを受け取り、CONDITIONINGを出す」と言えた時点で役割は理解できています。内部の計算は後回しで構いません。

データ型を意味で理解する：MODEL・CLIP・LATENT・IMAGEに何が流れるか

端子の型は、ノードの間を流れるデータの種類です。公式ドキュメントが「同じ色の端子同士しかつなげない」と明記しているとおり、型が合わない接続はUI上で拒否されます。型の意味を知っていれば、どのノード同士がつながり得るかは見ただけで分かります。

型	流れているもの	主な出どころ	主な行き先
MODEL	ノイズ除去を担う拡散モデル本体	Load Checkpoint、Load LoRA	KSampler
CLIP	テキストを数値に変換するテキストエンコーダ	Load Checkpoint、Load LoRA	CLIP Text Encode
CONDITIONING	プロンプトを数値化した「条件」	CLIP Text Encode	KSamplerのpositive / negative
LATENT	画像になる前の圧縮表現	Empty Latent Image、VAE Encode、KSampler	KSampler、VAE Decode
IMAGE	人が見られるピクセル画像	Load Image、VAE Decode	Save Image、VAE Encode
VAE	LATENTとIMAGEを相互変換する変換器	Load Checkpoint、Load VAE	VAE Encode、VAE Decode
MASK	画像のどこを対象にするかの白黒情報	Load Image	Inpaint系、合成系
INT / FLOAT / STRING	数値や文字列	Widget、Primitive	各ノードのWidget入力

覚えてほしいのは名前ではなく「出どころ」と「行き先」です。LATENTを「KSamplerが書き換え、VAE Decodeで画像に戻るもの」と覚えておけば、LATENTをSave Imageに直接つなげない理由も説明できます。型の色（MODELがラベンダー、LATENTがピンク、IMAGEが青など）は公式ドキュメントに一覧がありますが、色より意味で覚える方がCustom Nodeの独自型にも応用が利きます。

必須入力と任意入力を見る：requiredが埋まらないと実行できない

ノードの入力には、埋めないと実行できないrequiredと、空のままでも動くoptionalがあります。Pythonの実装ではINPUT_TYPESが返す辞書の"required"と"optional"に分かれており、Docsやノードの表示もこの区分に沿っています。

@classmethod
def INPUT_TYPES(cls):
    return {
        "required": {
            "samples": ("LATENT",),
            "vae": ("VAE",),
        },
        "optional": {
            "mask": ("MASK",),
        },
    }

この例では、samplesとvaeをつながないと実行時にエラーになり、maskは未接続でも動きます。Custom Nodeには「つなげば挙動が変わるが、つながなくても動く」任意入力を多く持つものがあり、配布Workflowで空の端子があっても、それだけでは壊れていません。

見分け方は、Docsの入力一覧で区分を読むか、未接続のまま実行してどの端子でエラーになるかを見るかです。エラーは「どのノードの、どの入力が足りないか」を示すので、required探しの手がかりになります。このほかに"hidden"という区分もあり、UIには表示されず実行時に自動で渡される入力です。Save Imageが画像にWorkflowを埋め込めるのは、この隠し入力で受け取っているからです。

自分でノードを作るときにこの辞書をどう書くかは、Custom Nodeの作り方で扱っています。

Widget値と接続を見分ける：直接入力か、別ノードからの入力か

ノードの入力には、値をその場で打ち込むWidget（数値欄・ドロップダウン・テキスト欄）と、他のノードの出力を線でつなぐ接続の2種類があります。同じINTやSTRINGでも、Widgetは「このノードで決め打ちする値」、接続は「上流の結果で変わる値」という違いがあります。

観点	Widget（直接入力値）	接続（他ノードからの入力）
見た目	ノード内部の入力欄	左側の端子に線が刺さっている
値の決まり方	そのノードで固定	上流ノードの出力で毎回決まる
典型例	KSamplerのsteps・cfg、Empty Latent Imageのwidth	MODEL・CLIP・LATENTなど計算結果の型
共有したいとき	複数ノードで同じ値を使うなら接続に変える	そのまま分岐できる

配布Workflowでは、seedやwidthを複数のノードで揃えるために、Widgetを入力端子に変換してPrimitiveノードから一括で渡す構成をよく見ます。本来Widgetのはずの欄が端子になっていればこの変換です。操作名はUIのversionで変わるため、右クリックメニューか公式ドキュメントで確認してください。

読解のコツは、Widgetと接続を分けて数えることです。Widgetは設定値なので「この値を変えると何が変わるか」を、接続は依存関係なので「この線の上流はどのノードか」を読みます。混ぜると、上流の問題なのに設定値をいじるような空振りが起きます。

配布Workflowを左から読む：Prompt→encode→sample→decode→saveの依存順で追う

配布されたWorkflowを開いたとき、ノードの数に圧倒されがちですが、画像生成の依存順はどのWorkflowでも同じです。公式の最小構成を軸に、次の5段階に当てはめて読みます。

Load：Load Checkpoint（MODEL・CLIP・VAEを出す）、必要ならLoad LoRA・Load VAE・Load Image
Encode：CLIP Text Encode×2（positive・negative）がCLIPを受けてCONDITIONINGを出す。img2imgならVAE EncodeがIMAGEをLATENTにする
Sample：KSamplerがMODEL・CONDITIONING×2・LATENTを受けて、新しいLATENTを出す
Decode：VAE DecodeがLATENTとVAEを受けてIMAGEを出す
Save：Save Image（Preview Image）がIMAGEを受けて終わる

読む手順は、右端のSave Imageから線を逆にたどり、どのノードがどの段階かをラベル付けすることです。配布Workflowは配置が整っていないことも多く、出力から逆にたどる方が迷いません。5段階に当てはまらないノードは前処理（リサイズ、ControlNetの条件づくり）か後処理（アップスケール）で、主経路ではなく枝です。枝は、外しても主経路が動くかどうかで見分けられます。

同じ処理が何度も現れるWorkflowは、Subgraphで1つのノードにまとめられている場合があります。その場合は、まとめられたノードの入力と出力の型だけを読めば主経路は追えます。部品化の考え方はSubgraphの記事を参照してください。

練習：LoRA Workflowを各接続1文で説明する

Docsだけで読めるかを確かめるには、LoRAを1つ足した標準Workflowが手頃です。線を1本ずつ指さして「何が、どこから、どこへ」を1文で書きます。

線	型	1文での説明
Load Checkpoint → Load LoRA（model）	MODEL
Load Checkpoint → Load LoRA（clip）	CLIP
Load LoRA → KSampler（model）	MODEL
Load LoRA → CLIP Text Encode×2（clip）	CLIP
CLIP Text Encode → KSampler（positive / negative）	CONDITIONING
Empty Latent Image → KSampler（latent_image）	LATENT
KSampler → VAE Decode（samples）	LATENT
Load Checkpoint → VAE Decode（vae）	VAE
VAE Decode → Save Image（images）	IMAGE

全部の行が書けたら、そのWorkflowは読めています。書けない行があれば、その線の両端のノードのDocsを開き、入力と出力の型から埋めてください。Load LoRAがMODELとCLIPの両方を受けて両方を出す理由や、強度の決め方はLoRAの記事で扱っています。

Docs不足のCustom Nodeを調べる：Node名→Registry→repo→README→codeの順

Custom NodeにはNode Docsが無いものも多くあります。その場合でも、調べる順番を決めておけば、ほとんどは入力・処理・出力の3要素まで辿り着けます。

Node名：ノードのタイトルと、どのpackに属するかを確認する。タイトルは作者が自由に付けられるので、同名の別ノードがあり得る
Registry：ComfyUI Managerまたは公式Registryでpack名を検索し、リポジトリへのリンクと説明を読む
repo / README：リポジトリのREADMEに、ノード一覧・入出力・サンプルWorkflowの画像があることが多い。サンプル画像はそのままWorkflowとして読み込める場合がある
code：READMEにも無ければ、Pythonファイルでそのノードのクラスを探し、INPUT_TYPES・RETURN_TYPES・FUNCTIONの3か所だけ読む

処理の中身を追う必要はありません。INPUT_TYPESが入力（required / optionalの区分つき）、RETURN_TYPESが出力の型、FUNCTIONで指定された関数の冒頭が処理の概要です。DESCRIPTIONがあれば、それがDocsに出る説明文です。

class SomeCustomNode:
    @classmethod
    def INPUT_TYPES(cls):
        return {"required": {"image": ("IMAGE",), "strength": ("FLOAT", {"default": 1.0})}}

    RETURN_TYPES = ("IMAGE",)
    FUNCTION = "apply"
    DESCRIPTION = "..."

「IMAGEとFLOATを受け取り、IMAGEを返す」と分かれば、Docsがあるノードと同じ水準で扱えます。リポジトリが見つからない、コードが難読化されている、READMEと実装が食い違う場合は、そのpackを使わない判断の材料になります。

よくある質問

Node Docsが英語で読みづらいです。

全文読む必要はありません。入力の型名、出力の型名、説明文の最初の一文の3か所でノードの役割は決まります。型名は英語のまま覚えた方が照合が楽です。

同じ型なのにつなぐとエラーになります。

型は同じでも中身の前提が違う場合があります。SD1.5用のLoRAから出たMODELをSDXL用の経路につなぐと、型は通りますが実行時に失敗します。型チェックは「つなげるか」までで、「意味が合うか」はDocsのモデル互換の記述で確認します。

端子が無い値を他のノードと共有したいです。

Widgetを入力端子に変換して、Primitiveなどの上流ノードから同じ値を配ります。変換の操作名は現行UIの右クリックメニューで確認してください。

まとめ

ComfyUIのノードは「入力・処理・出力」の3要素で読み、端子の型は「何が流れるか」で理解します。MODELはKSamplerへ、CONDITIONINGはプロンプトの条件、LATENTはVAE Decodeで画像に戻る前のデータ、と出どころと行き先で覚えれば、知らないノードでもつながり方が見えます。

配布WorkflowはSave Imageから逆にたどって5段階にラベル付けし、当てはまらないノードは枝として扱います。Docsが無いCustom Nodeは、Registry→リポジトリ→README→コードのINPUT_TYPES・RETURN_TYPES・FUNCTIONの順で確認すれば同じ水準で読めます。