ComfyUIのLatentは「画像になる前の、生成モデルが直接扱う内部表現」で、KSamplerが何十stepもかけて書き換えているのは画像ではなくこのLatentです。IMAGE型とLATENT型が分かれているのは、この2つが別の形のデータだからで、間に必ずVAEの変換が挟まります。この構造が分かると、配線の型エラーは「何が流れているか」を見るだけで自力で直せます。
情報確認日：2026年8月22日（日本時間）
結論：LatentはKSamplerの作業台で、画像にするにはVAE Decodeが要る
責任範囲
- Latentを「単なる画像の圧縮」と言い切らず、生成モデルの内部表現として捉える考え方
- IMAGE型とLATENT型の違いと、LatentをSave Imageに直接つなげない理由
- Empty Latent Imageの幅・高さ・batch_sizeが生成の出発点になる仕組み
- VAE Encode / DecodeでIMAGEとLATENTを往復する位置と、KSamplerがLatent側を更新すること
- 型エラーを「何が流れているか」で診断する読み方。潜在空間の数学やVAEの詳細は扱わず、VAEはVAEの記事に渡す
Latentを一言でどう捉えるか：圧縮ではなく「モデルが考えるための形」
Latentは「画像を縦横8分の1に縮めたもの」と説明されることが多く、サイズの面ではそのとおりです。ただし、縮小画像やzipのような圧縮ファイルと同じものだと考えると、あとで混乱します。Latentの各数値はピクセルの色ではなく、VAEが学習した「画像の特徴の表し方」に沿った値で、人が見ても画像には見えません。
捉え方として勧めるのは「生成モデルが考えるための作業台」です。拡散モデルは、ピクセルの画像ではなく、この作業台の上でノイズを少しずつ取り除きながら絵を組み立てていきます。ピクセルで直接やるより計算量が桁違いに少なく済むため、家庭用GPUでも画像生成が回る、というのがLatentを使う実利です。
| 観点 | 縮小画像・圧縮ファイル | Latent |
|---|---|---|
| 各数値の意味 | ピクセルの色 | VAEが学習した特徴の値 |
| 人が見て | 小さい画像として見える | 画像には見えない |
| 元に戻すと | 同じ画像（可逆なら完全に） | 細部がわずかに変わる |
| 誰が扱う | 画像ビューア | KSampler（拡散モデル） |
組み込みのEmpty Latent Imageの実装では、Latentは「batch×4チャンネル×（高さ÷8）×（幅÷8）」の数値配列として作られます。512×512の画像なら64×64×4です。この「4チャンネル・8分の1」はSD1.5やSDXL系の値で、モデル系統によって異なります。数字を覚えるより、「画像よりずっと小さい、別の形のデータ」と押さえておけば十分です。
IMAGE型とLATENT型：直接Save Imageできない理由は配線に出ている
ComfyUIでは、端子の型が違うと線をつなげません。公式ドキュメントにも「同じ色の端子同士しか接続できない」とあり、現行UIではLATENTがピンク、IMAGEが青です。KSamplerの出力はLATENTで、Save Imageの入力はIMAGEなので、この2つを直接つなごうとしても線が拒否されます。
つなげない
KSampler ─LATENT─✕─▶ Save Image.images (IMAGE)
つなげる
KSampler ─LATENT─▶ VAE Decode.samples ─IMAGE─▶ Save Image.imagesこれは不便な制限ではなく、「LatentはそのままではPNGにならない」という事実を配線のレベルで教えてくれる仕組みです。型が分かれているおかげで、変換を忘れたWorkflowは実行前に気づけます。
逆方向も同じです。Load Imageの出力はIMAGEで、KSamplerのlatent_image入力はLATENTなので、元画像をそのままKSamplerには渡せません。間にVAE Encodeが必要です。「画像を使いたいのにKSamplerにつながらない」という初心者の詰まりは、ほぼこの型の違いが原因です。
Empty Latent Image：幅・高さ・batchが生成の出発点になる
txt2imgで最初に置くEmpty Latent Imageは、公式ドキュメントの説明どおり「指定した寸法とbatch数の、空のLatent」を作るノードです。中身はすべてゼロで、ここにKSamplerがseedに基づくノイズを乗せ、ノイズ除去を始めます。つまりこのノードが決めているのは「何を描くか」ではなく「どの大きさの作業台を何枚用意するか」です。
| 入力 | 意味 | 現行の実装での範囲 |
|---|---|---|
| width | 出力画像の幅（ピクセル）。Latentはこの1/8 | 16〜16384、8刻み、既定512 |
| height | 出力画像の高さ（ピクセル）。Latentはこの1/8 | 16〜16384、8刻み、既定512 |
| batch_size | 同時に生成する枚数 | 1〜4096、既定1 |
widthとheightが8刻みなのは、Latentが8分の1の大きさで作られるため、8で割り切れない値だと端数が出るからです。batch_sizeを2以上にすると、同じ大きさのLatentが複数枚まとめて流れ、KSamplerもVAE Decodeもその枚数分を一度に処理します。VRAMの消費は枚数に比例して増えるので、解像度とbatchは同時に上げないでください。
ここで出発点がEmpty Latent Imageである限り、生成は「何もない状態から」始まります。元画像から始めたい場合は、次節のVAE Encodeで作ったLatentに差し替えます。
VAEで往復する：IMAGE↔LATENTの変換はWorkflowの両端に現れる
IMAGEとLATENTを行き来させるのがVAE EncodeとVAE Decodeです。Encodeは「画像→Latent」、Decodeは「Latent→画像」で、Workflow全体で見ると、Latentの区間は必ずこの2つ（またはEmpty Latent ImageとDecode）に挟まれています。
IMAGEの区間 │ LATENTの区間 │ IMAGEの区間
│ │
Load Image ──▶ VAE Encode ──▶ KSampler ──▶ (Latent Upscale) ──▶ VAE Decode ──▶ Save Image
│ ▲ │
Empty Latent Image ──────┘ │この図で押さえてほしいのは、Latentの区間の中ではIMAGEを扱うノードが一切出てこないことです。Latentの区間で解像度を変えたいならLatent Upscale（LATENT→LATENT）、画像の区間で変えたいならImage系のUpscale（IMAGE→IMAGE）と、同じ「拡大」でも型ごとに別のノードがあります。どちらを使うかは、その処理を「KSamplerの前後どちらに置きたいか」で決まります。
Encode→Decodeの往復は無損失ではありません。同じ画像をVAE Encodeしてすぐ VAE Decodeしても、細部や色がわずかに変わります。これはVAEが情報を「再構成」しているためで、どの程度変わるかはVAEによります。VAEの選び方と交換の影響はVAEの記事で扱っています。
KSamplerが操作するもの：更新されるのはLatentで、画像ではない
KSamplerの入出力を型で見ると、latent_image（LATENT）を受け取り、LATENTを返します。MODEL・positive・negativeは「どう書き換えるか」の指示で、書き換えられる対象はLatentだけです。公式ドキュメントも、KSamplerを「modelと条件に基づいてlatentを更新するノード」として説明しています。
KSampler
入力
model (MODEL) ← 書き換えの担当者
positive (CONDITIONING) ← こう描けという指示
negative (CONDITIONING) ← こうは描くなという指示
latent_image (LATENT) ← 書き換えられる作業台
seed / steps / cfg / sampler / scheduler / denoise (Widget)
出力
LATENT ← 書き換え後の作業台この整理から、よくある2つの疑問が解けます。1つは「KSamplerの出力をプレビューしたいのに画像が出ない」で、出力がLATENTなのでVAE Decodeを通すまで画像にはなりません。もう1つは「KSamplerを2段つなぐとどうなるか」で、1段目のLATENT出力を2段目のlatent_imageに渡せば、Decodeを挟まずに続けて書き換えられます。高解像度化のWorkflowで、Latent Upscaleを挟んで2段目のKSamplerにつなぐ構成はこの応用です。
steps・cfg・denoiseといった各Widgetが「書き換えの量と方向」をどう変えるかはKSamplerの記事、元画像のLatentをdenoise 1未満で書き換えるimg2imgはimg2imgの記事を参照してください。
Workflow読解へ応用する：型エラーは「何が流れているか」で自力診断する
ここまでの型の理解があれば、配線で詰まったときに調べる順番が決まります。線がつながらない、実行時に型のエラーが出る、画像が出ないといった症状は、次の3問で切り分けられます。
- 詰まっている線の出力側の型は何か（ピンクならLATENT、青ならIMAGE）
- つなぎたい入力側の型は何か。Node Docsの入力一覧で確認する
- 2つが違うなら、間に入れるべき変換ノードはどれか。LATENT→IMAGEならVAE Decode、IMAGE→LATENTならVAE Encode
この3問で解決しないのは、型は同じなのに中身の前提が違うケースです。たとえばSDXL用のCheckpointのVAEで、SD1.5のWorkflowが作ったLatentをDecodeしようとすると、型はLATENTで通りますがエラーか崩れた画像になります。型チェックは「形が合うか」までしか見ないので、モデル系統の一致は自分で確認します。
練習：画像をEncode→Decodeして型を画面で追跡する
型の流れを体で覚えるには、元画像を一度Latentにして、そのまま画像に戻す最小構成が向いています。KSamplerを入れないので、VAEの往復だけを観察できます。
Load Image ─IMAGE─▶ VAE Encode ─LATENT─▶ VAE Decode ─IMAGE─▶ Save Image
▲ ▲
Load Checkpoint.VAE ──┴────────────────────┘| 線 | 端子の色 | 型 | その線に流れているもの（自分の言葉で） |
|---|---|---|---|
| Load Image → VAE Encode（pixels） | |||
| Load Checkpoint → VAE Encode（vae） | |||
| VAE Encode → VAE Decode（samples） | |||
| Load Checkpoint → VAE Decode（vae） | |||
| VAE Decode → Save Image（images） |
実行したら、出力画像と元画像を100%表示で並べてください。構図や色はほぼ同じはずですが、細部がわずかに変わっていれば、それが「Latentは可逆な圧縮ではない」ことの目に見える証拠です。どこがどう変わったかを記録し、次にVAEを別のものに差し替えて同じ表を埋めると、VAEの記事の比較につながります。この表に書くのは自分の環境で観察した内容だけで、変化量を予想で埋めないでください。
ノードの入力・出力の型をDocsから読む方法はNode Docsの読み方で詳しく扱っています。
よくある質問
Latentを直接保存したり読み込んだりできますか？
組み込みにSave LatentとLoad Latentがあり、Latentをファイルとして保存・再利用できます。Decode前の状態を取っておいて、後から別のVAEで画像にする、といった使い方ができます。
Empty Latent Imageのwidthとheightは出力画像のサイズですか？
はい。Latent自体はその1/8の大きさですが、Decode後の画像はwidth×heightになります。8で割り切れる値を指定してください。
Latentの区間で画像を確認したいです。
VAE Decodeを分岐してPreview Imageにつなげば、Save Imageせずに途中の状態を見られます。プレビュー用に軽いVAE（taesd系）を使う方法もありますが、最終出力とは見え方が変わります。
まとめ
Latentは画像の縮小版ではなく、生成モデルが考えるための内部表現です。KSamplerが書き換えるのはこのLatentで、画像にするには必ずVAE Decodeを通します。IMAGE型とLATENT型が分かれているのは、この変換の忘れを配線のレベルで防ぐためです。
Empty Latent Imageは「どの大きさの作業台を何枚用意するか」を決め、VAE Encode / DecodeがWorkflowの両端でIMAGEとLATENTを往復させます。線がつながらないときは、出力側の型・入力側の型・間に要る変換ノードの3問で切り分けてください。