ComfyUIのVAEは、人が見る画像（IMAGE）と生成モデルが扱う圧縮データ（LATENT）を相互に変換する「橋渡し役」で、画像の色味・明暗・細部の破綻に直接影響します。KSamplerが作るのはLatentであって画像ではないため、最後にどのVAEで画像に戻すかで、同じ生成結果でも見た目が変わります。
情報確認日：2026年8月22日（日本時間）
結論：VAEは「最後に画像へ戻す変換器」で、交換はモデルの推奨に従う
責任範囲
- VAEが画像空間とLatent空間を往復させる変換器であること、VAE EncodeとVAE Decodeがtxt2imgとimg2imgのどこに現れるか
- Checkpointに内蔵されたVAEと、Load VAEで別読み込みする外部VAEの違いと配線
- 同じLatentを2つのVAEでDecodeして、色・階調の差を自分の環境で観察する手順
- 色崩れ・明暗のずれ・エラーをVAE不一致の候補として切り分ける順番と、むやみに交換しない判断基準
- Latentそのものの仕組みは別記事で扱い、img2imgのdenoiseはimg2imgの記事に渡す。特定VAEの優劣やランキングは扱わない
VAEは画像とLatentの橋渡し：2つの空間を往復させる変換器
画像生成モデルは、ピクセルの画像を直接は扱いません。画像を縦横それぞれ8分の1に圧縮したLatentという数値の塊の上でノイズ除去を繰り返し、最後にその塊を画像に戻します。この「画像→Latent」と「Latent→画像」の2方向の変換を担うのがVAE（Variational Autoencoder）です。
画像空間（IMAGE） Latent空間（LATENT）
人が見るピクセル画像 ──VAE Encode──▶ 縦横1/8の圧縮表現
例: 512×512×RGB ◀──VAE Decode── 例: 64×64×4チャンネル
↑
KSamplerはここを書き換える公式ドキュメントはVAE Decodeを「圧縮されたLatent表現をVariational Autoencoderで画像に変換するノード」と説明しています。圧縮といっても、zipのように元に完全に戻る可逆圧縮ではありません。Encodeで一度捨てた情報はDecodeで「それらしく」補われるため、同じ画像をEncode→Decodeしただけでも、細部や色味がわずかに変わります。この「補い方」がVAEごとに違うことが、VAEを変えると色や階調が変わる理由です。
Latentの中身や、IMAGE型とLATENT型が分かれている理由そのものは、Latentの別記事で扱います。この記事では「変換器としてのVAE」に絞ります。
VAE EncodeとDecode：txt2imgとimg2imgで登場する位置が違う
ComfyUIにはVAEを使うノードが2つあり、向きが逆です。
| ノード | 入力 | 出力 | 役割 |
|---|---|---|---|
| VAE Encode | pixels（IMAGE）、vae（VAE） | LATENT | 元画像をLatentにして、KSamplerの出発点にする |
| VAE Decode | samples（LATENT）、vae（VAE） | IMAGE | KSamplerが出したLatentを画像に戻す |
txt2imgでは、出発点がEmpty Latent Image（空のLatent）なのでEncodeは不要で、最後のVAE Decodeだけが登場します。img2imgでは、元画像をLatentにするVAE Encodeが先頭に加わり、最後のVAE Decodeと合わせて「往復」になります。
txt2img
Empty Latent Image ─LATENT─▶ KSampler ─LATENT─▶ VAE Decode ─IMAGE─▶ Save Image
img2img
Load Image ─IMAGE─▶ VAE Encode ─LATENT─▶ KSampler ─LATENT─▶ VAE Decode ─IMAGE─▶ Save Imageどちらの構成でも、VAE Decodeに渡すvaeは「Load CheckpointのVAE出力」か「Load VAEの出力」のどちらかです。img2imgでは、EncodeとDecodeに同じVAEをつなぐのが基本です。往路と復路で違う変換器を使うと、元画像の色が保たれない原因になります。denoiseで元画像をどこまで残すかはimg2imgの記事を参照してください。
内蔵VAEと外部VAE：Checkpointに含まれる場合と別読み込みを分ける
Load Checkpointは、MODEL・CLIP・VAEの3つを出力します。つまり多くのCheckpointにはVAEが内蔵されており、何もしなければその内蔵VAEでDecodeされます。一方、Load VAEノードでComfyUI/models/vae（またはextra_model_paths.yamlで設定した場所）にあるVAEファイルを別に読み込み、内蔵VAEの代わりにつなぐこともできます。
| 観点 | 内蔵VAE | 外部VAE（Load VAE） |
|---|---|---|
| 出どころ | Load CheckpointのVAE端子 | Load VAEのVAE端子 |
| 配線 | Checkpoint → VAE Decode.vae | Load VAE → VAE Decode.vae（Checkpoint側のVAEは未接続のまま） |
| 使う場面 | 配布元がそのまま使うよう案内しているとき | 配布元が特定の外部VAEを推奨しているとき、内蔵VAEに問題があるとき |
| 注意 | Checkpointによっては内蔵VAEの品質が低い場合がある | モデル系統（SD1.5 / SDXL など）と一致している必要がある |
内蔵VAEを使う
Load Checkpoint.VAE ──▶ VAE Decode.vae
外部VAEを使う
Load VAE.VAE ──▶ VAE Decode.vae
（Load Checkpoint.VAE は何にもつながない）外部VAEに切り替えるときは、VAE Decodeのvae端子の線を差し替えるだけです。img2imgならVAE Encode側も同じVAEに差し替えます。Load VAEの一覧にファイルが出ないときは、拡張子と置き場所を確認し、画面の再読み込みをしてください。Load VAEの一覧にはtaesd系の軽量VAEも出ることがあり、これはプレビュー用途の近似デコーダです。最終出力にはCheckpointの系統に合った通常のVAEを使います。
VAEを変えると何が変わるか：同じLatentをDecodeして色・階調の差を観察する
VAEの影響を理解する一番確実な方法は、「同じLatentを2つのVAEでDecodeして並べる」ことです。KSamplerまでの処理が同一なら、2枚の違いはVAEだけが生んだ差になります。
- txt2imgの最小Workflowで、seedを固定して1枚生成する（KSamplerの設定は変えない）
- KSamplerのLATENT出力を分岐し、VAE Decodeを2つ置く。片方のvaeにLoad CheckpointのVAE、もう片方にLoad VAEで読み込んだ外部VAEをつなぐ
- それぞれの出力をSave Imageにつなぎ、filename_prefixを「vae_builtin」「vae_external」のように分ける
- 1回実行すると、同じLatentから2枚の画像が出る。100%表示で並べて比較する
KSampler ─LATENT─┬─▶ VAE Decode (vae: Checkpoint内蔵) ─▶ Save Image (vae_builtin)
└─▶ VAE Decode (vae: Load VAE 外部) ─▶ Save Image (vae_external)比較するときは、次の観点を表に記録します。差が出る量はモデルとVAEの組み合わせで変わるため、ここでは数値を示しません。自分の環境で埋めてください。
| 観点 | 見る場所 | 内蔵VAE | 外部VAE |
|---|---|---|---|
| 全体の色味 | 肌・空・白い壁など広い面の色 | ||
| 明暗・コントラスト | 最も暗い部分と最も明るい部分の差 | ||
| 彩度 | 鮮やかな色がくすんでいないか | ||
| 細部 | 目・髪・文字・遠景の線 | ||
| 破綻 | 格子状のノイズ、色の斑点、にじみ | ||
| Decode時間 | コンソールの所要時間 |
この比較で変わらないものも把握しておいてください。構図、人物のポーズ、物の配置は、Latentが同じなので2枚で一致します。VAEが変えるのは「Latentを画像に起こすときの解釈」であって、何が描かれるかではありません。構図まで違うなら、seedや他の設定が固定できていません。
VAE不一致の症状：色崩れ・明暗・互換性を候補として切り分ける
生成画像がおかしいとき、VAEが原因である可能性は「どうおかしいか」で見当が付きます。次の表は、VAEを疑う症状と、VAE以外の候補を並べたものです。
| 症状 | VAEが原因のときの特徴 | VAE以外の候補 |
|---|---|---|
| 全体が灰色がかる・くすむ | 構図は正常で色だけ薄い | CFGが低すぎる、promptの指定 |
| 色の斑点・格子状のノイズ | 細部だけ壊れ、大きな形は保たれている | stepsが少なすぎる、VRAM不足による途中打ち切り |
| 明暗が極端に偏る | 白飛び・黒つぶれが広い面に出る | promptの照明指定、LoRAの強度 |
| 実行時にエラーで止まる | VAE Decode／Encodeのノードで止まる | モデル系統の不一致、VRAM不足 |
| img2imgで元画像の色が変わる | denoiseを0に近づけても色が戻らない | EncodeとDecodeで違うVAEを使っている |
切り分けの順番は、まずVAE Decodeのvae端子を「Checkpoint内蔵」に戻して再生成することです。それで直れば外部VAEが原因で、多くはモデル系統（SD1.5用とSDXL用など）の不一致です。直らなければVAEの外に原因があるので、KSamplerの各値やpromptを疑います。VAE Decodeで落ちるのにVAEを戻しても落ちる場合は、解像度が大きすぎてDecode時にVRAMが足りていない可能性があり、タイル分割版のVAE Decode（VAE Decode Tiled）に差し替えて通るかを確かめる手もあります。
むやみに交換しない：モデルの公式推奨とWorkflowの前提を優先する
「VAEを変えると色が良くなる」という話は事実ですが、それは「そのモデルに合うVAEへ変えた場合」に限ります。合わないVAEへ変えると、前節の症状がそのまま起きます。交換するかどうかは、次の順で判断してください。
- モデルの配布ページに「推奨VAE」または「VAE内蔵（baked in）」の記載があるか。記載があればそれに従う
- 配布Workflowを使っているなら、そのWorkflowがLoad VAEを置いているか。置いていれば作者が意図したVAEで、外すと前提が崩れる
- 外部VAEを使う場合、モデル系統（SD1.5 / SDXL / その他）が一致しているか
- 変える前に内蔵VAEで1枚、変えた後に同じLatentで1枚、前節の手順で比較して記録したか
- 比較の結果、色・階調・細部のどれが改善し、どれが悪化したかを言葉にできるか
VAEは「最後の一手」なので、生成の質そのものを上げる道具ではありません。構図や人物が崩れる、promptが効かないといった問題は、VAEを変えても解決しません。まずモデル・prompt・KSamplerの設定で狙いどおりの生成ができてから、仕上げの色と階調をVAEで整える、という順番を守ってください。
よくある質問
VAEを指定しなくても画像が出るのはなぜですか？
Load CheckpointがVAEを出力しており、最小Workflowではそれを直接VAE Decodeにつないでいるからです。内蔵VAEで十分なモデルも多く、外部VAEは必須ではありません。
SD1.5用のVAEをSDXLのモデルで使えますか？
系統が違うVAEはLatentの前提が合わず、エラーか大きく崩れた画像になります。必ずモデルと同じ系統のVAEを使ってください。
VAE DecodeでVRAM不足になります。
Decodeは高解像度ほどメモリを使います。タイル分割版のVAE Decodeに差し替えるか、解像度を下げてから段階的に上げてください。VRAM不足全般の切り分けは別記事で扱っています。
まとめ
ComfyUIのVAEは、IMAGEとLATENTを往復させる変換器です。txt2imgでは最後のVAE Decodeだけ、img2imgでは先頭のVAE Encodeと最後のVAE Decodeの両方に現れ、どのVAEをつなぐかで色味・明暗・細部が変わります。
内蔵VAEと外部VAEの違いは、VAE Decodeのvae端子に何をつなぐかだけです。変えるときは、同じLatentを2つのVAEでDecodeして並べ、色・階調・細部・破綻を自分の目で記録してください。交換の判断は、モデルの配布元の推奨とWorkflowの前提を優先し、VAEは仕上げの一手として扱います。