動画生成AI「LTX-2.3」について解説！（AIによる調査）

🌟はじめに…

LTX-2.3に興味を持たれたのですね！最近話題の強力なAIモデルなので、気になって当然です。

LTX-2.3は、Lightricks社が開発したオープンソースの動画・音声生成AIモデルです。最大の特徴は、テキスト（T2V）や画像（I2V）から、高品質な動画と「それに連動した音声」をひとつのモデルで同時に生成できる点にあります。

初心者の方にも分かりやすく、抽象的な概念は抜きにして「どうやって自分のPCに入れ、どう使うのか」という具体的な手順を解説します。

1. 必要なPCスペック（動作環境）

まず、ローカル環境（自分のPC）で動画を生成するには、かなり強力なパソコンが必要です。ここをクリアしていないとエラーで動かないため、最初に確認しましょう。

注意: AMDやIntelのGPUでは現在ローカル生成はサポートされていません。Macをお使いの方や、強力なグラフィックボードがない方は、後述する「APIモード（クラウド処理）」での利用となります。

2. 具体的なインストール手順（2つの方法）

LTX-2.3を導入するには、主に「LTX Desktop」を使う方法と、「ComfyUI」を使う方法の2通りがあります。ご自身のスキルに合わせて選んでください。

方法A：LTX Desktopを使う（初心者向け・一番簡単）

公式が用意している専用のデスクトップアプリです。面倒な環境構築やフォルダ分けが不要で、すぐに始められます。

1. アプリのダウンロード:

   • 公式のGitHub Releasesページ（Lightricks/LTX-Desktop/releases）にアクセスします。

   • Windowsなら.exeファイル、Macなら.dmgファイルをダウンロードします。

2. インストール:

   • ダウンロードしたファイルを開き、画面の指示に従ってインストールします（警告が出た場合は「詳細情報」から「実行」を選択してください）。

3. 初回起動とデータのダウンロード:

   • アプリを起動すると、初回のみ「Python環境（約10GB）」と「AIモデル本体（約150GB）」のダウンロードが自動で始まります。容量が非常に大きいため、安定したネット環境で行ってください。

   • Macの場合: ローカルで生成は行わないため、大容量ダウンロードはありません。設定画面で「LTX APIキー」を入力し、クラウド上で生成を行います（テキストエンコード自体は無料ですが、生成はLightricksのAPIを利用します）。

方法B：ComfyUIを使う（中級者向け・自由度MAX）

すでに画像生成AIなどでComfyUIを使っている方や、細かい調整（ノードを繋ぐ作業）をしたい方向けです。

1. ComfyUIの準備:

   • 最新バージョンのComfyUIをインストールして起動します。

2. カスタムノードの追加:

   • 「ComfyUI Manager」を開き、「Install Custom Nodes」をクリックします。

   • 検索欄に「LTXVideo」と入力し、「ComfyUI-LTXVideo」をインストールします。

   • インストールが終わったら、ComfyUIを完全に再起動します（ブラウザの更新ではなく、裏で動いている黒い画面のコマンドプロンプトごと閉じます）。

3. ワークフローとモデルの準備:

   • LTXVideoの公式から配布されているワークフロー（.jsonファイル）をComfyUIの画面にドラッグ＆ドロップします。

   • モデル本体（ltx-2.3-22b）、VAE（ltxvideo_vae_bf16）、テキストエンコーダー（T5-XXL）をダウンロードし、ComfyUI内の所定のフォルダ（models/checkpointsなど）に配置します。

3. 具体的な使い方とプロンプトのコツ

準備ができたら、実際に動画を生成してみましょう。基本となる「テキストから動画（T2V）」と「画像から動画（I2V）」の2つの使い方があります。

テキストから動画生成 (T2V)

文字だけでゼロから動画を作る方法です。

1. プロンプト（指示文）の入力:

   • どんな動画にしたいかを英語で記述します。

   • 例: "A red ball rolling slowly on a white table, smooth camera"（白いテーブルの上をゆっくり転がる赤いボール、滑らかなカメラワーク）

2. 生成を実行:

   • 「Generate」（ComfyUIなら「Queue Prompt」）をクリックして完了を待ちます。

画像から動画生成 (I2V)

手持ちの静止画に動きをつける方法です。

1. 画像の読み込み:

   • ベースにしたい画像をUI上にアップロード（またはノードにセット）します。

2. プロンプトの入力:

   • その画像の中の「何が」「どう動くか」をテキストで指示し、生成ボタンを押します。

綺麗に生成するための「3つの鉄則」

初心者が陥りやすい失敗を防ぐための、具体的なノウハウです。

• 鉄則1：カメラは「ゆっくり」動かす

  • 画像から動画を作る（I2V）際、急激なカメラの動き（高速なパンなど）をプロンプトで指示すると、元の画像の被写体が崩れやすくなります。最初は「カメラは固定し、被写体だけを動かす」設定から始めるのが成功のコツです。

• 鉄則2：最初は短い尺（秒数）でテストする

  • 動画の秒数が長くなるほど、PCのVRAM消費量と生成時間が跳ね上がります。最初は短いクリップで構図や動きの方向性が合っているかテストし、うまくいくことを確認してから尺を伸ばすという段階的なアプローチを取りましょう。

• 鉄則3：ネガティブプロンプトで崩れを防ぐ

  • 「こうならないでほしい」という除外指定（ネガティブプロンプト）には、no morphing, no warping, no flickering, no jitter（変形なし、歪みなし、ちらつきなし、ブレなし）というキーワードを入れると画質が安定します。ただし、欲張って5〜6個以上指定すると逆にAIが混乱するため、必要最小限に留めてください。

LTX-2.3は要求されるPCスペックこそ高いものの、個人でこのクオリティの映像と音声を同時に作れるのは驚異的です。

🌟知らない用語・概念を一気に解説・Q&A

ComfyUI（コンフィー・ユーアイ）とは？

＝ AIを動かすための「作業ソフト（操作画面）」

一般的なソフトによくある「ボタンを押すだけ」のシンプルな画面ではなく、「ノード」と呼ばれるブロックを線で繋いで、作業工程（ワークフロー）を自分で組み立てるソフトです。

• なぜ動画生成でよく使われるのか？

  • メモリの節約が上手い: 裏側で無駄な処理を省くように設計されているため、スペックが高くないPCでもギリギリまで性能を引き出せます。

  • 自由度が高い: 「ここは画像を読み込む」「ここでAIに計算させる」「ここで動画として保存する」といった工程をブロック遊びのように組めるため、新しいAI技術（LTX-2.3など）が出たときに、すぐに対応できます。

GGUF（ジー・ジー・ユー・エフ）とは？

＝ 圧縮された「燃費の良いAIモデル（データ）」

AIのモデル（今回で言えばLTX-2.3本体のデータ）のファイル形式のことです。動画ファイルに「.mp4」や「.mov」があるように、AIモデルにもいくつかの形式があります。

• GGUFの最大の特徴は「圧縮（量子化）」

  • 本来のLTX-2.3は、データが大きすぎて16GBのグラフィックボード（VRAM）には入りきりません。

  • そこで、AIの「計算の正確さ」を人間の目には分からないレベルで少しだけ丸めて（小数点以下を切り捨てるようなイメージ）、データ容量と消費メモリを半分近くまでギュッと圧縮したのがGGUF形式です。

  • 画質はほぼ元のままなのに、要求スペックだけをガクッと下げることができます。

なぜ「ComfyUI ＋ GGUF」の組み合わせが必要なのか？

16GBのグラフィックボードで最新の高画質動画生成（LTX-2.3）を行うには、以下の連携が不可欠だからです。

1. GGUFモデルを使って、絶対に入りきらない巨大なAIデータを、16GBのVRAMに収まるサイズ（12GB程度）まで圧縮する。

2. それを、無駄なメモリを食わず、かつGGUFという特殊な形式の読み込みに対応できるComfyUIの上で動かす。

この2つを組み合わせることで、本来なら32GB以上の超高級グラボが必要な処理を、16GBのミドルスペックPCで「ハックして動かす」ことができるようになります。

ComfyUIについての質問

ComfyUIについて、非常に鋭い疑問ですね。「なぜUIじゃないとダメなの？」「スクリプトの方が良くない？」という視点はまさにプログラマーや効率を求める方が必ず行き着くポイントです。

結論から言うと、ComfyUIはただの「画面（UI）」ではなく、強力な「APIサーバー（バックエンド）」です。コマンドラインやPythonスクリプトからの操作も、もちろん可能です。

いただいた疑問を一つずつ、紐解いていきましょう。

1. ComfyUIって何？他のAIでも使えるの？

ComfyUIは、元々は画像生成AI「Stable Diffusion」のために作られたツールですが、現在では「あらゆるオープンソース生成AIを動かすための共通プラットフォーム」になっています。

LTX-2.3（動画）だけでなく、Flux（最新の画像生成）、SVD（動画）、さらには音声生成や3Dモデル生成など、ほぼすべての主要なAIモデルをこの上で動かすことができます。

何がスゴイかというと、「拡張性の異常な高さ」です。新しいAI技術が発表されると、世界中の開発者が数日以内に「ComfyUI用のブロック（カスタムノード）」を作って公開します。ユーザーはそれをダウンロードして線を繋ぐだけで、最新技術をすぐに試せるのです。

2. なぜComfyUIを使うと「軽くなる」のか？

UI（見た目）がノードベースだから軽いわけではありません。ComfyUIの真の価値は、裏側で動いている徹底したメモリ管理（VRAM最適化）プログラムにあります。

AIの生成プロセスは、「テキストの理解」「ノイズの計算」「画像の復元」など、複数の工程に分かれています。一般的なソフトはこれらすべてのデータをVRAM（グラボのメモリ）に載せっぱなしにしますが、ComfyUIは違います。

• 賢い出し入れ: 今計算している工程に必要なデータだけをVRAMに載せ、終わった瞬間にメインメモリ（RAM）に退避させます。

• 分割処理: 一度に処理しきれない巨大なデータは、細かく分割（チャンク化）して少しずつ計算します。

この「裏側のエンジン」が極めて優秀なため、16GBのグラボでもGGUFのような圧縮モデルと組み合わせることで、本来なら動かないはずの巨大なAIを動かせるのです。

3. コマンドラインやスクリプトで操作できないの？

完全に可能です。 むしろ、実務や自動化においてはスクリプト（API）経由で動かすのが標準的です。

ComfyUIを起動すると、実は裏でローカルサーバー（通常は [http://127.0.0.1:8188](http://127.0.0.1:8188)）が立ち上がっています。つまり、ComfyUI自体がヘッドレスなAPIサーバーとして機能します。

なぜ最初はUIを使うのか？

それは、「ノードの設計図（JSONファイル）」をテキストエディタで手書きするのが人間には複雑すぎるからです。

1. UIで組み立てる: 最初だけブラウザの画面を開き、ノードを繋いで「プロンプト入力 → モデル読み込み → 動画出力」というワークフローを作ります。

2. API形式で保存: メニューから「Save (API Format)」を選ぶと、その設計図がJSON形式で書き出されます。

3. スクリプトで自動化: あとはPythonスクリプトからそのJSONを読み込み、プロンプトの文字や設定値だけをプログラムで書き換えて、バックエンドのComfyUIサーバーにリクエストを投げるだけです。

また、最近では公式から comfy-cli というコマンドラインツールも提供されており、ターミナルから直接モデルのインストールやワークフローの実行ができるようになっています。

4. なぜ「これ一択」のような状況なのか？

「スクリプトで直接AIモデルを叩けばいいのでは？」と思うかもしれませんが、LTX-2.3のような最新モデルをゼロからPythonスクリプトで動かす環境（推論コード、メモリ管理、GGUF読み込み等の実装）を自作するのは、非常に骨の折れる作業です。

結論として、「人間が設計図を視覚的に作るためのUI」と、「それを効率よく実行するためのAPIサーバー」を兼ね備えているのがComfyUIの本当の姿です。

🌟ComfyUIについて

GGUFと「量子化」の正体、そしてそのメリットと代償について、専門用語を極力省いてスパッと解説します。

1. 「量子化（Quantization）」ってなに？

＝ AIの脳内にある「数字のケタを四捨五入して、記憶容量を節約する技術」です。

AIのモデル（データ）は、何百億個もの「数字（パラメータ）」の集まりでできています。 本来、この数字は「3.14159265...」のように非常に細かく精細なデータ（16ビット）として保存されています。これを「3.14」くらいまで大胆に丸めてしまう（4〜8ビットなどに削る）作業が「量子化」です。

• 例え話: 10,000円の買い物をするときに、1円単位までキッチリ割り勘するのが「元のモデル」。「だいたい1人3,300円でいいよね！」とざっくり計算するのが「量子化モデル」です。

2. 量子化で「失われるもの」は？無傷なの？

結論から言うと、無傷ではありません。「計算の正確さ（精度）」が少し失われます。

数字を丸めているため、AIが出力する結果に以下のような影響が出ることがあります。

• 画質の微細な劣化: 髪の毛の1本1本の繊細さや、肌の質感が、元モデルに比べてわずかに甘くなる。

• 指示（プロンプト）への忠実さ: 複雑な指示を出したときに、AIが混乱しやすくなる（「赤い服を着た青い目の男性」が「青い服」になるなど）。

• ノイズの発生: 動画の背景が少しチラチラする（フリッカー）などのバグが起きやすくなる。

何がスゴイのか？ スゴイのは、「データを1/3に削っても、人間の目には95%同じクオリティに見える」という点です。AIの数字には「そこまで細かくなくても結果に影響しない無駄な部分」が多く含まれており、そこを賢く削ぎ落とす技術（GGUFなど）が発達したため、画質劣化を最小限に抑えつつVRAMを劇的に節約できるのです。

3. GGUF以外の「軽く使う方法」はある？

量子化以外にも、以下のような軽量化アプローチがあります。

• 蒸留（Distillation）: AIに「もっと早く描くコツ」を教え込んだモデル。通常20回かかる計算（ステップ）を、4〜8回で終わらせる技術です。VRAMの節約というより「時間の節約（爆速化）」になります。

• クラウドAPIの利用: 重い計算はLightricks社やfal.aiなどの巨大サーバーに任せ、自分は指示出しと結果の受け取りだけを行う方法（Macユーザーや低スペックPCの基本戦術）。

• 生成サイズを小さくする: 単純ですが効果絶大です。解像度を下げ、秒数を短くすればVRAM消費は減ります。

4. LTX-2.3でLoRAを使うと、結局重たくなる？

少し重くなりますが、破綻するほどではありません。

LoRA（追加の学習データ。例えば「特定のアニメキャラの顔にする」「特定の実写カメラの画質にする」など）は、ベースモデルに比べて非常にサイズが小さい（数百MB〜1GB程度）です。

• 16GBのグラボの場合: GGUFモデルで12GB消費したとして、残り4GBの空きがあります。LoRAを1〜2個追加してもVRAM内に収まるため、極端に重くなる（エラーで止まる）ことは少ないです。ただし、欲張ってLoRAを5個も6個も重ねると、計算量が増えてVRAMがパンク（OOM）します。

5. 実際の使われ方と、GGUF（量子化）の「できないこと」

現場では、GGUFはこのように割り切って使われています。

「ComfyUI ＋ GGUF」ではどのくらい長い動画が生成できるの？

結論から言うと、16GB環境で一度に生成できる実用的な長さは「5秒 〜 10秒」が目安です。

詳細な限界値と、それを突破する「裏技」について解説します。

1. 16GB環境での「画質 vs 秒数」の限界目安

一度の処理（シングルパス）で生成しようとした場合、以下のようになります。

• 720p（1280×720）の場合：約5秒 〜 10秒

  • これが16GB環境の「スイートスポット」です。高画質を保ったまま、VRAMのパンク（OOMエラー）を起こさずに安定して生成できます。生成時間は数分〜10分程度かかります。

• 1080p（フルHD）以上の高画質：約3秒 〜 5秒

  • フルHDになると一気にVRAMを食うため、GGUFを使っても5秒前後が限界になります。

• 360p（テスト用の低解像度）：最大20秒

  • 動きや構図を確認するためだけの荒い画質であれば、モデルの最大値である20秒まで一気に生成できる可能性があります。

2. モデル本来の限界（LTX-2.3の仕様）

ちなみに、パソコンのスペックを無視して「LTX-2.3というAIが公式にサポートしている最大の長さ」は「最大20秒（50fps）」です。

一昔前のAI動画モデルが「2〜4秒」しか作れなかったことを考えると、20秒の動画と音声を一度に作れるLTX-2.3は、非常に強力なモデルと言えます。

3. 16GBで10秒以上の動画を作りたい場合の「裏技」

「最大10秒しか作れないなら、長いショート動画やMVは作れないの？」と思うかもしれませんが、ご安心ください。ComfyUIを使えば「Extend（延長）」というテクニックが使えます。

【Extend（延長）ワークフローの仕組み】

1. まず、普通に「5秒」の動画を生成します。

2. ComfyUIのノードで、その動画の「最後の数フレーム（映像の終わり際）」をAIに読み込ませます。

3. 「この続きを、同じプロンプトであと5秒作って」と指示を出します。

AIが「前のシーンの終わり」を記憶したまま続きを作ってくれるため、これを繰り返して繋ぎ合わせれば、VRAM16GBのPCでも実質的に何分でも長い動画を作ることが可能です。

最初は「720pで5秒」の設定からスタートし、少しずつ秒数を伸ばしてご自身のPCの限界値を探っていくのが一番安全な使い方です。

動画の長さについてはイメージが湧きましたでしょうか？ 他にも「こんなことはできる？」といった疑問があれば、どんどん聞いてくださいね！

「ComfyUI」も「GGUF」も、LTX-2.3のためだけに作られた言葉ではありません。「あらゆる最新AIを、普通のPCで動かすための最強の汎用コンビ」といった立ち位置です。

それぞれの本来の由来と、他にどんなAIで使われているかを整理します。

1. GGUFの本来の姿

GGUFは元々、動画や画像用ではなく「ChatGPTのような文章作成AI（LLM）を、ローカルPCで動かすため」に開発されたファイル形式でした（Llama.cppという有名なプロジェクトが発祥です）。

テキストAIの世界で「品質を保ったまま劇的にデータを軽くできる魔法のフォーマット」として大成功したため、最近になって「これ、画像や動画の重たいAIにも使えるんじゃない？」と応用されるようになりました。

2. ComfyUIの本来の姿

ComfyUIは元々、「画像生成AI（Stable Diffusion）」を動かすために作られたソフトでした。

しかし、その「ノードを繋ぐだけでどんな新しい処理でも組み込める」という異常な拡張性の高さから、今では画像だけでなく、動画、音声、3Dモデルなど、ありとあらゆる生成AIの「ベースキャンプ（共通基盤）」として使われています。

「ComfyUI ＋ GGUF」で動かせる他の有名なAI

LTX-2.3以外にも、このコンビを使うことで、本来なら16GBでは重すぎて動かない超高性能なモデルをサクサク動かすことができます。

• FLUX.1（フラックス）: 現在の画像生成AIの頂点に君臨するモデル。本来なら24GB以上のVRAMが必要ですが、「ComfyUI ＋ GGUF」を使うことで12GBや16GBのPCでも最高品質の画像が作れます。

• Stable Diffusion 3 / SDXL: 有名な画像生成AIの最新シリーズ。これもGGUF化することで、驚くほど爆速で生成できるようになります。

• HunyuanVideo / Mochi: LTX-2.3のライバルにあたる、他の高画質動画生成AIモデル。

🌟ComfyUIの使い方解説

本記事は、生成AIツール「ComfyUI」について、そもそも何ができる道具なのかという基礎から、実際のインストール手順、基本操作、応用的なワークフロー構築、トラブル対処までを一気通貫で解説するものです。ComfyUIは開発のペースが非常に速く、細かな名称やバージョン番号は数週間単位で更新されていきます。本記事の内容は2026年7月時点で確認できる情報をもとにしていますが、実際に触るときは公式ドキュメント(docs.comfy.org)や公式GitHub(github.com/Comfy-Org/ComfyUI)のChangelogで最新情報を確認することをおすすめします。

第1章 ComfyUIとは何か

1-1. 一言でいうと

ComfyUIとは、Stable DiffusionやFlux、WANといった生成AIモデルを、画面上に配置した「ノード」という部品を線でつなぐことで操作する、無料でオープンソースのソフトウェアです。開発・配布を行っているのはComfy Orgという組織で、2023年1月に個人開発者(comfyanonymous氏)によって公開されたのが始まりです。現在はGitHub上のリポジトリもComfy-Org/ComfyUIという組織アカウントに移管され、より組織立った体制で開発が続けられています。

「ノードベース」という言葉にピンとこない方は、映像編集ソフトのノードエディタや、電子回路の配線図をイメージするとわかりやすいです。1つ1つのノードは「モデルを読み込む」「テキストを解析する」「ノイズを除去して画像を作る」「画像として書き出す」といった、たった1つの処理だけを担当する小さな部品です。これらを入力・出力の端子(ソケット)で線をつなぎ、データが左から右へ流れるようにレイアウトすることで、1枚の画像が生成されるまでの全工程を目に見える形で組み立てます。

多くの画像生成ツール(後述するAUTOMATIC1111など)は、あらかじめ処理の流れが固定されていて、ユーザーはテキスト欄やスライダーで数値を変えるだけです。いわば「1つの黒い箱」に対して設定を変えているだけの状態です。一方ComfyUIは、その黒い箱の中身を分解し、部品それぞれを自由に並べ替えたり、途中に別の処理を挟んだり、複数のモデルを組み合わせたりできる状態にしたものだと考えると理解しやすいでしょう。

1-2. ComfyUIで何ができるのか

2023年の登場当初は静止画のtxt2img(テキストから画像への変換)が主な用途でしたが、2026年現在のComfyUIは画像生成にとどまらない統合的な生成AIプラットフォームへと発展しています。具体的には次のようなことが可能です。

• 画像生成:テキストから画像を作るtxt2img、既存画像を下敷きに新しい画像を作るimg2img、画像の一部だけを描き直すインペインティング、線画やポーズを指定して構図を制御するControlNetの活用など

• 動画生成:テキストや1枚の画像から短い動画を生成する、既存動画にポーズ情報を適用するなど。動画特化モデルへの対応も早く、音声を同時に生成できるモデルまで登場している

• 音声・音楽生成:音声生成モデルへの対応も進んでいる

• アップスケール・高画質化:生成した画像を後から高解像度化する

• 3Dやその他の実験的な処理:ノードという仕組み自体は画像生成に限定されないため、コミュニティ主導で3D関連や他のAIモデルと連携する拡張ノードも登場している

• 外部ツールとの連携:ComfyUI自体がAPI(外部プログラムから呼び出す仕組み)としても動作するため、業務自動化ツールと組み合わせ、画像生成を作業フローの一部に組み込むことも可能

つまりComfyUIは「1枚のきれいな画像がすぐ欲しい」というより、「同じ生成を何度も安定して繰り返したい」「独自の生成パイプラインを組みたい」「最新モデルをいち早く試したい」というニーズに強いツールです。逆に手軽さだけを求めるなら、他のSaaS型の画像生成サービスの方が速いという点は率直に述べておきます。

1-3. 他の画像生成UIとの違い

Stable Diffusion系のGUIには他にAUTOMATIC1111(WebUI)、Forge、Fooocusなどがあります。ざっくりとした使い分けの目安は以下の通りです。

ComfyUIの最大の強みは「再現性」です。ワークフロー全体を1つのJSONファイルとして保存できるうえ、生成した画像のファイル自体にもワークフロー情報が埋め込まれるため、同じノード構成・同じシード値であれば、別の人が別のPCで実行してもほぼ同一の結果を再現できます。チームでの共有や、過去に作った作品の設定をあとから追いたい場合に大きな武器になります。また内部処理を細かく制御できる分、無駄な処理をそぎ落としやすいため、同じハードウェアでも他のツールよりメモリ効率や速度で有利になるケースが多いとされています。

一方で、最初にノードという考え方に慣れるまでのハードルは他のツールより高めです。慣れるまでの数時間から数日を乗り越えられるかどうかが、最初の分かれ目になります。

1-4. 開発体制とライセンス

ComfyUIはオープンソースで、ソフトウェア自体は無料です。商用利用も可能ですが、これは「ComfyUIというアプリ」の話であり、実際の生成に使うモデル(チェックポイントやLoRAなど)ごとに個別のライセンスが設定されているため、商用利用の可否はモデルごとに配布ページで確認する必要があります。またAIが自律的に生成した画像そのものには著作権が発生しないという解釈が一般的ですが、プロンプト設計や生成後の編集に人の創作性が加わっている場合は話が変わってくるとも言われています。事業で本格的に使う場合は、使用するモデルのライセンスを確認したうえで、必要に応じて専門家に相談することをおすすめします(本記事はその点についての法的助言を行うものではありません)。

第2章 導入前に知っておきたいこと

2-1. 必要なPC環境の考え方

ComfyUIそのものは軽量なアプリケーションで、本体だけなら数GB程度のストレージしか使いません。しかし実際に画像を生成するには、別途モデルファイル(チェックポイントなど、1つ2〜10GB程度)をダウンロードして配置する必要があるため、ある程度のストレージの余裕(最低でも20GB以上、複数モデルを扱うなら100GB以上)を見込んでおくと安心です。

生成速度や扱えるモデルの大きさを最も左右するのはGPU、特にVRAM(GPU専用メモリ)の容量です。目安としては次のように考えるとよいでしょう。

• 4〜6GB:SD1.5系モデルなら動作可能。SDXLやFluxは解像度を落とすか、軽量化された形式(後述のGGUF量子化モデルなど)が必要になることが多い

• 8〜12GB:SDXLや量子化されたFluxが実用的な速度で動く、一般的な目安ライン

• 16GB以上:Flux本来の品質や動画生成モデルも比較的快適に扱える

• 24GB以上(RTX4090/5090クラス):高解像度のバッチ生成や動画生成、複数モデルの同時運用でも余裕が出てくる

2-2. 対応ハードウェア

もともとComfyUIはNVIDIA GPU(CUDA)を主戦場として開発されてきましたが、2026年に入ってからは対応ハードウェアの幅が大きく広がりました。AMD GPU(ROCm)は公式に統合され、SDXLやFluxで大幅な高速化が報告されています。Apple Silicon搭載のMac(M1以降)はMetalによるGPUアクセラレーションに対応しており、M3 Pro以上であれば実用的な速度で生成できます。Intel Arc系やCPUのみでの動作も可能ですが、CPUだけの場合は1枚の生成に数分から十数分かかることもあるため、動作確認程度の用途と考えたほうがよいでしょう。

GPUがない、あるいは非力な環境でも、クラウドGPUサービスを間借りする方法や、ブラウザだけで完結する公式のComfy Cloud(2026年3月開始、無料枠として月間クレジットが付与される仕組み)を使う方法があります。ノートPCや会社支給のPCでも、ひとまずComfyUIがどんなものか試すことは十分可能です。

第3章 インストール方法

ComfyUIの導入方法は主に4つあります。それぞれ長所と短所があるため、自分の目的に合わせて選びましょう。

3-1. Comfy Desktop(初心者に最もおすすめ)

Comfy Orgが公式に配布しているデスクトップアプリケーションです。以前は「ComfyUI Desktop」という名称でしたが、2026年6月に大幅に刷新され「Comfy Desktop」という名前に変わりました。インストーラーを実行するだけでPython環境の構築からComfyUI Managerの導入まで自動的に完了するため、コマンド操作に不慣れな人でも迷わず始められます。

刷新後のComfy Desktopは、単なる「ComfyUI本体のラッパー」ではなく、複数のComfyUI環境をまとめて管理するランチャーのような性格を持つようになりました。主な特徴は次の通りです。

• 複数インスタンス管理:バージョンや導入済みカスタムノードが異なる複数のComfyUI環境を並行して管理できる

• スナップショット:ある時点の環境(ComfyUI本体のバージョン、カスタムノード、Pythonパッケージ構成)を丸ごと保存し、あとから復元できる

• モデルの共有ストレージ:複数の環境で同じモデルファイルを共有し、ディスク容量を節約できる

• 自動アップデート

• 既存インストールの取り込み:手動インストール版やPortable版としてすでに導入済みの環境も、管理対象として追加できる

• クラウド連携:Comfy Cloud上のインスタンスもここから起動・接続できる

ただし、WindowsのDesktop版はNVIDIA GPUのみ対応、macOS版はApple Siliconのみ対応で、Linux版は提供されていません。AMD GPUを使っている場合やLinux環境の場合は、次に紹介するPortable版か手動インストールを検討してください。

3-2. Portable版(Windows向け、持ち運び可能)

zipファイル(7z形式)をダウンロードして展開するだけで動作する、Windows専用のパッケージです。Python本体やPyTorchなどの必要なライブラリがあらかじめ同梱されているため、フォルダごとコピーすれば別のPCや外付けSSDにそのまま持ち運べるのが特徴です。

以前はComfyUI ManagerもPortable版に最初から入っていましたが、現在はComfyUI Manager自体がComfyUIのコア機能に統合される形に変わり、Portable版・手動インストール版では起動時に有効化の作業(起動用batファイルに--enable-managerという起動オプションを追記するなど)が必要になっている点に注意してください。Desktop版では最初から有効になっています。

ダウンロード時はグラフィックボードの世代に応じてCUDAのバージョンが異なるパッケージ(例:CUDA 12.6版、12.8版、13.0版など)が用意されているため、自分のGPUに合うものを選ぶ必要があります。また展開先のパスに日本語や全角文字を含めるとエラーの原因になりやすいため、「C:\ComfyUI_windows_portable」のように半角英数字だけのパスに置くことをおすすめします。

3-3. 手動インストール(git clone、全OS対応・上級者向け)

Windows・Mac・Linuxいずれでも使える、最も自由度の高い導入方法です。GitとPythonを自分で用意し、GitHubから直接ソースコードを取得(git clone)したうえで、仮想環境(venv)を作ってPyTorchなどの依存ライブラリを手動でインストールしていきます。

自由度が高い反面、PythonやCUDAのバージョンの組み合わせ次第でエラーが起きやすく、ある程度のトラブルシューティングの知識が必要です。公式が提供するcomfy-cliというコマンドラインツールを使うと、comfy installという1コマンドで手動インストールに近い環境を半自動で構築でき、近年はこちらが推奨されつつあります。

3-4. クラウドで利用する方法

自前のGPUを用意しなくても、ノートブック環境からComfyUIを起動する方法、クラウドGPUを時間貸しで借りてDockerごと構築する方法、そして公式のComfy Cloudをブラウザだけで使う方法があります。特にComfy Cloudは、アカウントを作ればGPU環境を意識せずにすぐ試せる無料枠(月間クレジット制)が用意されており、ComfyUIがどのようなものかをまず体験してみたい人に向いています。本格的に使い込むには有料プランやクラウドGPUの従量課金が必要になる点は踏まえておきましょう。

3-5. どれを選べばよいか

初めてで、Windows・NVIDIA GPU・macOS(Apple Silicon)のいずれかであれば、まずComfy Desktopから始めるのが最も迷いが少ない選択です。AMD GPUやLinuxの場合、あるいはDesktop版よりも早く最新機能を試したい場合はPortable版(Windowsのみ)か手動インストールを検討してください。GPUを持っていない、あるいはまず雰囲気だけ確認したい場合は、Comfy Cloudのようなクラウドサービスから触ってみるのがおすすめです。

第4章 画面構成とノードの基本操作

4-1. 起動画面

ComfyUIを起動すると、ブラウザ上(Desktop版の場合はアプリのウィンドウ内)にノードエディタの画面が表示されます。初回起動時にはすでに基本的なワークフロー(後述するtxt2imgの構成)が読み込まれた状態になっていることが多く、モデルファイルさえ配置してあれば、画面上部やサイドバーにある「Queue」(キュー、実行)ボタンを押すだけで画像を生成できます。

4-2. ノードとリンク(配線)

ノードは四角い箱として表示され、左側に入力用の端子(ソケット)、右側に出力用の端子が並びます。ある処理の結果を次の処理に渡したいときは、出力側のソケットをクリックしたままドラッグし、次のノードの対応する入力ソケットへ線(リンク)を伸ばして接続します。

ソケットにはMODEL(モデル本体)、CLIP(テキストエンコーダ)、VAE(画像と潜在空間を変換する部品)、CONDITIONING(プロンプトをエンコードした条件情報)、LATENT(潜在空間上の画像データ)、IMAGE(実際の画像データ)といったデータの「型」があり、型ごとに色分けされています。異なる型のソケット同士は接続できない仕組みになっているため、色を頼りに「このソケットにはどのノードがつながるか」を視覚的に把握できます。

新しいノードを追加するには、キャンバスの何もない場所を右クリックして「Add Node」からカテゴリをたどって選ぶ方法と、ダブルクリックで検索ボックスを出してノード名を直接入力する方法があります。ノード名やカテゴリの多くは英語表記なので、英語表示のまま使うユーザーが多いのもComfyUIの特徴の一つです。日本語表示に切り替えることも可能ですが、コミュニティの情報の多くが英語のノード名を前提にしているため、検索や質問のしやすさを考えると英語のまま使うメリットも大きいです。

4-3. ウィジェットとパラメータ

ノードの中には、線でつながずに直接数値やテキストを入力する項目(ウィジェット)を持つものもあります。例えばCLIP Text Encodeノードのテキスト入力欄や、Empty Latent Imageの幅・高さの数値、KSamplerのステップ数などがこれにあたります。ウィジェットの値は、右クリックメニューから「入力化」して他のノードの出力を接続する形に変更することもでき、これによりプロンプトや解像度を別のノードで動的に生成する、といった応用も可能になります。

4-4. 実行とプレビュー

画面上の「Queue Prompt」に相当するボタンを押すと、現在組まれているワークフロー全体がサーバー側に送られ、上流のノードから順に処理が実行されます。実行中のノードは枠が光るなどして視覚的に分かるようになっており、エラーが発生したノードは赤い枠で表示されます。赤くなったノードの設定や接続を確認すれば、何が不足しているかのヒントを得られます。

任意のノードの出力に対して、右クリックでプレビュー用のノードを追加すると、生成途中の画像やマスクなどを確認できる小窓を追加でき、複雑なワークフローのどこで意図と違う結果になっているかを切り分けるのに役立ちます。

4-5. 画面を整理するための機能

ワークフローが大きくなってくると、ノードの数が増えて画面が煩雑になりがちです。ComfyUIには画面を整理するための機能がいくつか用意されています。

• グループ:矩形の枠を配置し、その枠に触れているノードをまとめて色分け・ラベル付けする機能。見た目の整理には便利ですが、枠の位置次第では意図しないノードまで一緒くたに扱われることがある点に注意してください

• サブグラフ:2025年8月に正式機能となった比較的新しい仕組みで、選択した複数のノードを「1つの疑似ノード」としてカプセル化できます。グループが見た目の整理にとどまるのに対し、サブグラフは入出力を明確に定義したうえで中身をブラックボックス化するため、複雑な処理のまとまり(例えば「アップスケール一式」「顔補正一式」など)を再利用可能な部品として扱いたいときに向いています。作成したサブグラフはノードライブラリに登録して、他のワークフローでも呼び出せます

• ワークフローテンプレート:主要なモデル・用途ごとに、あらかじめ組まれたワークフローのひな形が用意されており、検索欄からテンプレート名を入力するだけですぐに呼び出せます。ゼロから組む前に、まずテンプレートを覗いてみると全体像をつかみやすくなります

第5章 はじめての画像生成(基本ワークフロー)

ComfyUIで画像を生成するために最低限必要なノードは、実質6つだけです。ここではそれぞれの役割と設定項目を順番に見ていきます。この6ノードの流れさえ理解すれば、あとは「どこに何を挟むか」という応用でほとんどのワークフローを読み解けるようになります。

5-1. 全体の流れ

基本の流れは次のようになります。

Load Checkpoint
 ├─ MODEL ────────────────────────────────┐
 ├─ CLIP ─┬─ CLIP Text Encode (Positive) ─┤
 │        └─ CLIP Text Encode (Negative) ─┤
 │                                         ▼
 │                                    KSampler ── LATENT ── VAE Decode ── IMAGE ── Save Image
 │                                         ▲                    ▲
 └─ VAE ───────────────────────────────────────────────────────┘
              Empty Latent Image ── LATENT ┘

5-2. Load Checkpoint(モデルの読み込み)

使用する生成モデル(チェックポイント、拡張子は主に.safetensors)を選択して読み込むノードです。MODEL(画像生成本体の重み)、CLIP(テキストエンコーダ)、VAE(潜在空間と画像を変換する部品)という3種類のデータを出力します。多くのチェックポイントはこの3つを一体で含んでいますが、モデルによっては外部のVAEを別途読み込んで差し替えることもあります。

5-3. CLIP Text Encode(プロンプトの指定)

Load CheckpointのCLIP出力を受け取り、テキスト欄に書いたプロンプト(AIへの指示文)を、モデルが処理できる数値表現に変換するノードです。基本的にポジティブプロンプト(描いてほしいもの)用とネガティブプロンプト(描いてほしくないもの)用の2つを用意し、それぞれ別のCLIP Text Encodeノードに入力します。

プロンプトは基本的に英語で書くのが一般的です。CLIPやT5といったテキストエンコーダの多くは英語を中心とした学習データで作られているため、日本語で入力しても意図通りに解釈されないことが多いためです。例えば「美しい山の風景、夕日、写真風」と書くよりも、"beautiful mountain landscape, sunset, photorealistic, detailed, 8k"のように英語の単語やフレーズをカンマ区切りで並べる書き方のほうが安定した結果を得やすいでしょう。ネガティブ側には"blurry, low quality, extra fingers, watermark"のような、避けたい要素を書きます。

なお、Fluxのように複数のテキストエンコーダ(CLIPとT5など)を同時に使うモデルでは、専用のエンコードノードやガイダンス用ノードが必要になるなど、SD1.5・SDXLとはやや構成が異なる点も知っておくとよいでしょう。

5-4. Empty Latent Image(何もない下地の用意)

生成する画像のサイズ(幅・高さ)とバッチ数(一度に何枚生成するか)を指定し、何も描かれていない潜在空間のデータを用意するノードです。AUTOMATIC1111ではこの工程はユーザーが意識しなくても自動的に処理されますが、ComfyUIでは内部処理をそのまま可視化しているため、明示的にノードとして存在します。

推奨される解像度はベースにするモデルの世代によって異なります。SD1.5系なら512×512〜768×768前後、SDXL系なら1024×1024前後、Flux系もおおむね1024×1024前後を基準に考えるとよいでしょう。学習時の解像度から大きく外れると、構図が破綻しやすくなります。

5-5. KSampler(生成処理の心臓部)

ワークフロー全体の中核を担うノードです。ノイズだらけの潜在空間の情報から、少しずつノイズを取り除きながら意味のある画像の情報を作り上げていきます。主なパラメータは以下の通りです。

• seed:乱数の種。同じ値・同じ設定であれば同じ結果を再現できます。ランダムにする、固定する、生成のたびに増減させるといった挙動を選べます

• steps:ノイズ除去を何段階に分けて行うか。多いほど精緻になりますが、その分時間もかかります。20前後を基準に、モデルやサンプラーに応じて調整します

• cfg(CFGスケール):プロンプトの指示にどれだけ忠実に従わせるか。一般的なSD1.5・SDXLでは7前後が標準的ですが、Fluxのように1.0〜3.5程度を基準にするモデルもあり、モデルごとの目安を確認する必要があります

• sampler_name:ノイズ除去のアルゴリズム(euler、euler_a、dpm++ 2m、dpm++ sdeなど)。仕上がりの質感や収束の速さに影響します

• scheduler:ステップごとのノイズ除去量をどう配分するか(normal、karras、exponentialなど)

• denoise:どれだけ元の潜在情報を残すか。テキストからの新規生成では1.0、既存画像を土台にするimg2imgでは0.3〜0.8程度に下げて使います

初めのうちはデフォルト値のまま実行し、慣れてきたらsteps・cfg・samplerあたりから少しずつ動かして、結果の変化を確かめていくのがおすすめです。

5-6. VAE Decode(画像への変換)

KSamplerが出力した潜在空間のデータ(LATENT)を、実際に目で見えるピクセル画像(IMAGE)に変換するノードです。Load CheckpointのVAE出力と接続する必要があります。ここで使うVAEがモデルと合っていないと、色がおかしくなったり、真っ黒・真っ灰色の画像しか出力されなかったりするので、うまくいかないときにまず疑うポイントの一つです。

5-7. Save Image / Preview Image(保存・プレビュー)

VAE Decodeの出力を受け取り、画像として保存する、あるいは画面上でプレビューだけするノードです。Save Imageで保存した画像には、生成に使ったワークフロー全体の情報がファイルのメタデータとして自動的に埋め込まれます。あとで同じ画像をComfyUIの画面にドラッグ&ドロップするだけで、当時のノード構成がそのまま復元できるという便利な仕組みです。

5-8. 実際に生成してみる

以上の6ノードをすべて線でつなぎ終えたら、ポジティブプロンプトに描きたいものを、ネガティブプロンプトに避けたいものを入力し、Queueボタンを押してみましょう。数十秒から数分ほど待つと、Save ImageまたはPreview Imageのノード上に生成結果が表示されます。うまくいかない場合は、赤く縁取られたノードがないか、各ソケットがつながっているかを確認してください。特に「Empty Latent Imageを接続し忘れる」「VAEの接続を忘れる」は、初心者が最初につまずきやすいポイントとして知られています。

第6章 モデルの種類と管理方法

ComfyUIで生成の質やスタイルを決めるのはモデルファイルです。アプリ本体には画像生成に必要な重みファイルは含まれていないため、目的に応じて別途ダウンロードし、正しいフォルダへ配置する必要があります。主なモデルの種類は次の通りです。

6-1. チェックポイント(Checkpoint)

画像生成の土台となる、最も重要なモデルです。大量の画像で学習済みの重みファイルで、ファイルサイズは2GBから10GB超までさまざまです。SD1.5、SDXL、SD3.5、Fluxなど世代(アーキテクチャ)によって扱えるデータ形式や推奨解像度、必要なファイル構成が異なる点に注意してください。初めての場合はSD1.5かSDXL系のチェックポイントから触り始め、慣れてから構成がやや複雑なFlux系に進むのがつまずきにくい順序です。

6-2. LoRA

チェックポイントに対して、特定のキャラクター・画風・概念だけを軽量に追加学習させたファイルです(数十MBから数百MB程度)。フィルターのようなイメージで、Load CheckpointとKSamplerの間にLoad LoRAノードを挟み込むことで、ベースのモデルに特定の絵柄やキャラクターの特徴を上乗せできます。複数のLoRAを直列につなげて重ね掛けすることも可能です。

6-3. VAE

潜在空間の情報と実際のピクセル画像を相互変換する部品です。多くのチェックポイントは内蔵のVAEを持ちますが、色味や発色を改善するために外部の専用VAEに差し替えることもあります。

6-4. ControlNet

エッジ検出・深度・ポーズ推定といった追加の画像情報をもとに、構図や姿勢を指定しながら生成する仕組みです。参照したい画像をLoad Imageノードで読み込み、専用の前処理ノード(プリプロセッサ)で線画やポーズ情報を抽出したうえで、ControlNet適用ノードを経てKSamplerの条件情報に接続します。

6-5. Embeddings(Textual Inversion)

特定の概念やスタイルを短いキーワードとして呼び出せるようにする、小さな補助ファイルです。主にネガティブプロンプト側の底上げ(画質の底上げなど)に使われることが多く、SD1.5用とSDXL用で内部構造が異なるため、対応バージョンを確認して使う必要があります。

6-6. アップスケールモデル

生成済みの画像を、ディテールを保ったまま高解像度化するための専用モデルです。VAE Decodeのあとにアップスケール用のノードを挟むことで、仕上げの一手間として利用します。

6-7. 入手先とフォルダへの配置

これらのモデルファイルは、CivitaiやHugging Faceといった配布サイトからダウンロードするのが一般的です。ダウンロードしたファイルは、ComfyUIをインストールしたフォルダの中にある「models」フォルダの、種類ごとのサブフォルダへ配置します。代表的な構成は次の通りです。

ComfyUI/models/
├── checkpoints/               ← チェックポイント
├── loras/                     ← LoRA
├── vae/                       ← VAE
├── controlnet/                ← ControlNetモデル
├── embeddings/                 ← Embeddings
├── clip/ (text_encoders/)     ← テキストエンコーダ(Flux等で使用)
├── clip_vision/                ← CLIP Vision(IPAdapter等で使用)
├── diffusion_models/ (unet/)   ← Flux等のUNet単体モデル・GGUF量子化モデル
└── upscale_models/             ← アップスケーラー

ファイルを配置したら、ComfyUIを再起動するか、ノード上のドロップダウンを更新すれば選択肢に表示されるようになります。注意点として、拡張子が同じ.safetensorsであっても、チェックポイント・LoRA・VAE・Fluxの拡散モデル・テキストエンコーダはすべて別のフォルダに入れる必要があります。ダウンロードページの説明をよく読み、対応するローダーノード名(Load Checkpoint、Load LoRA、Load VAE、UNETLoaderなど)を確認したうえで配置場所を決めましょう。またCivitaiなどでダウンロードする際は、配布ページに記載されている「Base Model」欄で対応する世代(SD1.5用なのかSDXL用なのかFlux用なのか)を必ず確認してください。世代が合わないモデル同士を組み合わせるとエラーになるか、意図しない出力になります。

複数のComfyUI環境やほかのツールとモデルを共有したい場合は、extra_model_paths.yamlという設定ファイルを編集することで、modelsフォルダの外にあるモデル群を追加の参照先として登録することもできます。

第7章 応用ワークフロー

基本の6ノード構成を土台に、目的に応じてノードを足し引きすることで、さまざまな応用ワークフローが組めます。

7-1. img2img(既存画像をもとに生成する)

Empty Latent Imageの代わりに、Load Image(画像読み込み)からVAE Encode(画像を潜在空間に変換)という流れでLATENTを用意し、KSamplerに接続します。KSamplerのdenoiseを0.3〜0.85程度まで下げることで、元画像の構図や色味をある程度残しながら、プロンプトに沿ったスタイル変換や細部の調整を行えます。denoiseを1.0のままにすると元画像の情報がほぼ無視されてしまうため、img2imgらしい効果を出すにはこの値の調整が要になります。

7-2. LoRAを組み込む

Load CheckpointとKSamplerの間にLoad LoRAノードを挟みます。MODEL側の出力とCLIP側の出力の両方をLoad LoRAに通してから、それぞれKSamplerとCLIP Text Encodeに接続し直す形になります。複数のLoRAを使いたい場合は、Load LoRAノードを縦列につなげていくことで重ね掛けができます。strength(強さ)のパラメータで効果の強さを調整できます。

7-3. ControlNetで構図を制御する

Load Imageからプリプロセッサ(OpenPose、Canny、Depthなど、参照画像から線画やポーズや深度情報を抽出するノード)を経てControlNet Applyへ、そしてKSamplerの条件情報へという流れを追加します。これにより、参照画像のポーズや構図を保ったまま、まったく違う画風やキャラクターで生成することができます。

7-4. インペインティング(部分修正)

画像の一部だけをマスクで指定し、その部分だけを描き直す手法です。マスク付きの画像を読み込み、専用のインペイント用ノード構成(VAE Encode for Inpaintingなど)を経由してKSamplerに渡します。顔だけを修正したい、背景だけを描き直したいといった細かい調整に向いています。

7-5. アップスケール(高画質化)

VAE Decodeで得た画像を、さらに専用のアップスケールモデルに通して高解像度化します。単純な拡大に加え、もう一度低いdenoise値でKSamplerに通す手法(いわゆるHires fixに相当する処理)を組み合わせることで、拡大時のディテールの粗さを補いながら仕上げることもよく行われます。

7-6. 動画生成の概要

2026年現在、ComfyUIは複数の動画生成モデルにも早期から対応しています。基本的な考え方は静止画のワークフローと共通しており、テキストや1枚の画像を入力として、時間方向の一貫性を保ちながらフレームを生成していきます。音声を同時生成できるモデルや、ControlNetを組み合わせて既存動画のポーズ情報を新しい動画に転写する手法も実用段階に入っています。動画生成はモデルサイズも大きく、要求されるVRAMも静止画より大きくなりやすいため、まずは静止画のワークフローに慣れてから挑戦することをおすすめします。

第8章 カスタムノードとComfyUI Manager

8-1. カスタムノードとは

ComfyUI本体が持つ「組み込みノード」に加えて、世界中の開発者が公開している追加ノード群を「カスタムノード」と呼びます。2026年時点で非常に多くのノードがエコシステムとして公開されており、標準では対応していない処理(顔の自動補正、高度なマスク処理、外部連携など)を柔軟に追加できます。ComfyUIが新しいモデルや技法にいち早く対応できるのも、このカスタムノードのエコシステムの活発さによるところが大きいです。

8-2. ComfyUI Managerの導入と使い方

カスタムノードやモデルのインストール・更新・管理をまとめて行える、事実上必須の拡張機能がComfyUI-Managerです。Comfy Desktop版には最初から組み込まれ、有効化された状態で入っています。Portable版や手動インストール版では、現在はComfyUI本体のコア機能として組み込まれてはいるものの、依存関係のインストールと起動オプションの追加(--enable-managerなど)という有効化の作業が別途必要になっている点は覚えておいてください。

Managerの使い方はシンプルです。画面上の「Manager」ボタンから、カスタムノードやモデルを検索してインストール・更新・無効化ができます。特に便利なのが「不足しているカスタムノードの自動検出」機能で、SNSやCivitaiで配布されているワークフロー(JSONファイルや、ワークフロー情報入りの画像)を読み込んだときに、自分の環境にまだ入っていないノードがあれば警告が表示され、その場でまとめてインストールできます。手作業でgit cloneして依存関係を1つずつ入れる手間が、ボタン操作だけで済むようになる、非常にありがたい機能です。

8-3. 代表的なカスタムノード

• ComfyUI-Manager:前述の通り、カスタムノード管理の入り口

• ComfyUI Impact Pack:顔の自動検出・修復、セグメンテーションなど実用的な後処理をまとめたパック

• ComfyUI ControlNet Auxiliary:ControlNet用の各種プリプロセッサをまとめたノード群

• AnimateDiff Evolved:SD1.5・SDXL系モデルに動きの概念を追加し、短いアニメーションを生成するための統合ノード

• IPAdapter:参照画像の雰囲気やキャラクターの特徴を、プロンプトなしで反映させるための仕組み

• ComfyUI-Custom-Scripts:ワークフローの保存・読み込みの利便性向上や、ノード・グループのロックなど、細かい使い勝手を改善する定番ノード集

導入したいワークフローで使われているカスタムノードが分からない場合も、まず読み込んでみて赤くなったノードをManagerの「Install Missing Custom Nodes」で解決する、という流れを覚えておけば困りません。

第9章 ワークフローの整理・保存・共有

9-1. JSON形式での保存・読み込み

組んだワークフローは、メニューからJSON形式のファイルとして保存できます。保存したJSONは、別のPCのComfyUIにドラッグ&ドロップするだけでそのまま読み込め、ノード構成を完全に再現できます。SNSやCivitaiで配布されているワークフローの多くもこの形式です。

9-2. 画像ファイルへの埋め込み

Save Imageノードで書き出したPNGやWebPには、ワークフロー全体の情報がメタデータとして自動的に埋め込まれます。そのため、生成された画像ファイル自体をComfyUIの画面にドラッグ&ドロップするだけで、その画像を作ったときのノード構成をまるごと復元できます。「この画像、どうやって作ったんだろう」を再現できるのはComfyUIならではの強みです。

9-3. グループとサブグラフによる整理

前述の通り、見た目の整理にはグループ、機能単位でのモジュール化にはサブグラフを使い分けます。よく使う処理のまとまり(例えば「顔補正一式」や「2倍アップスケール一式」)をサブグラフとしてノードライブラリに登録しておけば、新しいワークフローを組むたびにゼロから配線し直す必要がなくなります。

9-4. ワークフローテンプレート

主要なモデルや用途向けに、あらかじめ組まれたワークフローがテンプレートとして用意されています。新しいモデル(例えば新しく対応した動画生成モデルなど)が正式にサポートされると、多くの場合そのモデル用のテンプレートも合わせて追加されます。何もないところから毎回考えるのではなく、まずテンプレートを開いてみて、そこから少しずつ自分好みに手を加えていくというのが効率のよい学び方です。

第10章 パフォーマンスを最適化する

10-1. VRAM関連の起動オプション

VRAMが足りない環境では、起動時に付け加えるオプション(コマンドライン引数)で挙動を調整できます。代表的なものに、モデルの一部を都度システムメモリへ逃がしながら動作する--lowvram、より強力に節約する--novram、演算精度をfp16に統一してメモリ使用量をおよそ半分にする--force-fp16などがあります。2026年に入ってからは、中間的な計算結果(中間テンソル)だけをfp16で保持してVRAMをさらに削減する--fp16-intermediatesのようなオプションも追加されており、VRAMの搭載量が少ない環境でも、動画生成のような重い処理を扱いやすくなってきています。

10-2. バッチ処理と量子化モデル

Empty Latent Imageのバッチ数を増やせば、1回の実行で複数枚をまとめて生成できます。またGGUF形式のような量子化(データを間引いて軽量化する技術)されたモデルを使うことで、本来なら重いFlux系のモデルでもVRAM8GB程度のGPUで動かせるようになるなど、環境に応じた工夫の余地が広がっています。

10-3. その他の高速化の工夫

生成速度が遅いと感じたら、まずステップ数を必要以上に増やしていないか見直してみましょう。多くのサンプラーは20〜25ステップ程度でも十分な品質が得られることが多く、30〜40ステップに設定されたワークフローをそのまま流用している場合は、少し減らすだけで体感速度が変わることがあります。またWindows環境では、セキュリティソフトがComfyUIのフォルダやモデルファイルを常時スキャンしていると、生成速度が大きく落ちることがあるため、除外設定を検討する価値があります。複数GPUを搭載している場合は、並列処理用のノードを使ってバッチ生成を分散させる方法も用意されています。

第11章 よくあるトラブルと対処法

11-1. CUDA out of memory(VRAM不足)

最もよく遭遇するエラーです。エラーメッセージには「どれだけのメモリが必要で、実際にどれだけ空いているか」が具体的に表示されるので、まずそこを確認しましょう。対処の基本方針は、(1)画像の解像度やバッチ数を下げる、(2)前述の--lowvramなどの起動オプションを追加する、(3)fp8・GGUFなど軽量化されたモデル形式に切り替える、(4)VAE Decodeでのエラーであれば「VAE Decode (Tiled)」のような分割処理版のノードに差し替える、の4点です。単純にVRAMを使い切ったあとの断片化が原因のこともあるため、まずComfyUIを再起動してから同じワークフローを試すだけで解決することも少なくありません。

11-2. ノードが赤く表示される・ノードが見つからない

他人が作ったワークフローを読み込んだときに、自分の環境に入っていないカスタムノードがあると、そのノードは赤い枠で表示されます。この場合はComfyUI Managerの「Install Missing Custom Nodes」機能を使えば、不足しているノードをまとめて検出・インストールできます。ノードの問題が解決したあとに、今度はモデルファイル自体が足りないというエラーに変わることもありますが、これはノードの導入自体は成功し、次の段階(モデルの配置)に進めているということなので、慌てず該当のモデルを正しいフォルダに配置しましょう。

11-3. 真っ黒・真っ灰色の画像しか出ない

エラーメッセージが出ないまま、生成結果だけが真っ黒や単色のグレーになる場合、多くはVAEの不一致が原因です。チェックポイントに内蔵されたVAEとは別の、世代の合わないVAEを外部から接続していないか確認してください。またFluxのようにCFGスケールの適正値がSD1.5・SDXLと大きく異なるモデルで、そのままCFG7前後の設定を流用すると、露出過多のような破綻した画像になることがあります。モデルごとの適正なCFG値を確認しましょう。

11-4. 生成が遅い・GPUを使っていない

想定より明らかに遅い場合は、まず起動時のログにGPU名やCUDAという文字列が表示されているかを確認し、CPUだけで動作していないかをチェックしてください。CPU動作になっている場合は、PyTorchを正しいCUDAバージョン向けのものに入れ直す必要があります。また前述の通り、セキュリティソフトのリアルタイムスキャンやステップ数の設定も速度に影響します。

11-5. 起動しない・キューが固まる

最近追加したカスタムノードが原因で起動プロセスが止まっている可能性があります。ComfyUI Managerからカスタムノードを1つずつ無効化して原因を切り分ける、あるいはcustom_nodesフォルダの名前を一時的に変更して起動できるか確認する、といった手順で切り分けられます。特定のワークフローだけでキューが固まる場合も、同様にカスタムノードを1つずつ無効化しながら原因のノードを特定するのが確実です。GPUドライバが古いことが原因で、新しいモデルアーキテクチャに対応できず不可解なエラーが出るケースも報告されているため、Fluxや最新の動画モデルで原因不明のエラーが出た場合は、GPUメーカーが提供する最新ドライバへの更新も選択肢に入れてください。

第12章 よくある質問

Q. プログラミングの知識は必要ですか? 基本的な画像生成だけであれば、プログラミングの知識は不要です。ノードを配置して線をつなぐだけで完結します。ただし、独自のカスタムノードを自作したい場合や、込み入ったエラーの原因を追いたい場合には、Pythonの基礎知識があると理解が早まります。

Q. 商用利用はできますか? ComfyUI自体はオープンソースで商用利用の制約はありませんが、実際に使用するモデル(チェックポイントやLoRA)のライセンスはモデルごとに異なります。配布ページに記載されたライセンス条件を確認したうえで判断してください。

Q. スマートフォンだけでも使えますか? ComfyUI本体はローカルにインストールして使うのが基本のため、スマートフォン単体で完結させるのは現実的ではありません。ただし、自宅PCや外部サーバーで動かしているComfyUIに、スマートフォンのブラウザからネットワーク経由でアクセスする使い方や、ブラウザだけで完結するクラウド版サービスを利用する方法はあります。

Q. 日本語で使えますか? インターフェース自体は日本語表示に対応していますが、実際にノードを検索したり調べたりする場面ではノード名は英語のまま使われることがほとんどです。またプロンプトについても、テキストエンコーダの学習データの都合上、英語で書いたほうが安定した結果を得やすいのが実情です。

Q. 最初にどのモデルを使えばよいですか? 初めての場合は、比較的軽量で情報も豊富なSD1.5系、またはより高品質な出力が期待できるSDXL系のチェックポイントから始めるのがおすすめです。Flux系は品質が高い一方でワークフローの構成がやや複雑になりやすいため、基本操作に慣れてから挑戦するとつまずきにくいでしょう。

第13章 まとめ:学習の進め方

ComfyUIは決して「触ってすぐ完璧に使いこなせる」ツールではありません。ノードという考え方に慣れるまでの数時間から数日は、多くの人がつまずきを感じる時間です。しかしいったん基本の6ノード構成(Load Checkpoint→CLIP Text Encode→Empty Latent Image→KSampler→VAE Decode→Save Image)の意味を理解してしまえば、あとは「LoRAを足すならここ」「ControlNetを足すならここ」という応用の組み合わせとして、驚くほど素直に理解が進んでいきます。

学習の進め方としては、以下のような順序をおすすめします。

1. まずComfy Desktopなどでインストールし、初期状態で用意されているtxt2imgのテンプレートをそのまま1回動かしてみる

2. 6つの基本ノードの役割を、この記事や公式ドキュメントと照らし合わせながら確認する

3. プロンプトやKSamplerのパラメータを少しずつ変えて、結果の違いを体感する

4. LoRAやControlNetなど、他の人が公開しているワークフロー(JSON、または画像に埋め込まれたもの)を読み込んで動かしてみる

5. ComfyUI Managerで不足ノードを解決しながら、徐々に自分用にアレンジしていく

6. 慣れてきたらグループやサブグラフで自分のワークフローを整理し、再利用しやすい形に育てていく

ComfyUIは開発ペースが非常に速く、新しいモデルや機能が数週間単位で追加され続けています。本記事の内容も執筆時点のスナップショットに過ぎないため、実際に運用する際は、公式ドキュメント(docs.comfy.org)やGitHubのChangelog、ComfyUI Managerの更新履歴を定期的にチェックする習慣をつけておくと、最新の環境に迷わずついていけるはずです。

🌟LTX-2.3 を ComfyUI で「軽量に」使うための徹底ガイド

― そもそも論から順を追って理解する、低 VRAM 環境での動画生成 ―

目次

1. はじめに ―「軽量」とは何を指すのか

2. そもそも LTX-2.3 とは何なのか

3. なぜ動画生成モデルは「重い」のか（軽量化を理解するための土台）

4. 軽量化を考えるための「4つの軸」

5. モデルの種類をそもそもから理解する（dev / fp8 / distilled / GGUF）

6. 付随ファイルの正体（テキストエンコーダ・VAE・アップスケーラ・LoRA）

7. 自分の GPU で何ができるのか ― VRAM 別の現実的な指針

8. 軽量セットアップの実際の流れ

9. 「2段階（two-stage）」ワークフローの考え方

10. VRAM 不足（OOM）で落ちるときの具体的対処

11. 品質と軽さのトレードオフを賢く取る

12. よくある失敗と対策

13. おわりに

1. はじめに ―「軽量」とは何を指すのか

動画生成モデルの世界で「軽量に使う」という言葉は、実は複数の意味を含んでいます。話を始める前に、この記事で扱う「軽さ」を定義しておきます。ここが曖昧なまま手を動かすと、「速くしたかったのにメモリ対策の記事を読んでいた」といったすれ違いが起きるからです。

「軽さ」には大きく分けて次の3種類があります。

第一に メモリの軽さ（VRAM をどれだけ使わずに済むか） です。動画生成でもっとも人を悩ませるのがこれで、そもそもモデルがグラフィックボードのメモリ（VRAM）に載らなければ、生成は1フレームも始まりません。「16GB や 12GB のカードで動かしたい」という要望は、ほぼこの軸の話です。

第二に 速度の軽さ（1本の生成にかかる時間） です。メモリには載っても、1本の動画に何十分もかかっては実用になりません。ステップ数を減らす、蒸留モデルを使う、といった工夫がここに効いてきます。

第三に 手間・ストレージの軽さ（導入や運用の負担） です。LTX-2.3 はフルセットで約 46GB という大きさがあり、ダウンロードや置き場所の管理も無視できません。どのファイルを最小限そろえれば動くのか、という視点もまた「軽量運用」の一部です。

この記事では、まず動画生成モデルがなぜ重くなるのかという原理を押さえたうえで、この3つの軽さをバランスよく実現する具体策を扱っていきます。原理が分かっていれば、新しいバージョンが出ても、あるいは他の動画モデルに乗り換えても、同じ考え方を応用できるからです。

2. そもそも LTX-2.3 とは何なのか

LTX-2.3 は、テキストや画像を入力すると動画を生成してくれる、いわゆる 動画生成 AI モデルの一つです。開発元がモデルの重み（ウェイト）を公開している オープンウェイトモデルであり、誰でもダウンロードして自分のマシンで動かせる点が最大の特徴です。ここが、クラウド上でしか使えない多くの商用動画モデルとの決定的な違いになります。手元で動かせるからこそ「軽量化」という工夫が意味を持ちます。

技術的に押さえておきたい特徴は次の通りです。

音声と映像を1つのモデルで同時に生成できる。 多くの動画モデルは映像だけを作り、音は別のツールで後付けします。LTX-2.3 は映像・セリフ・音楽・環境音をまとめて生成できる統合モデルとして設計されており、口の動きと声を合わせるようなリップシンク用途にも使われています。ただしこの「音も一緒に扱う」設計は、後述するようにメモリと処理の負担を増やす要因でもあります。

パラメータ数は 22B（220 億）クラス。 モデルのファイル名に「22b」と付いているのはこのためです。パラメータ数はモデルの「規模」を表す数字で、大きいほど表現力が高い一方、必要なメモリと計算量も増えます。この 22B という規模が、後述する「重さ」の根本原因です。

スペック面もオープンモデルとしては最高クラス。 ネイティブの生成解像度は最大 1080p 前後、フレームレートは 24 / 25 / 48 / 50fps から選べ、1回の生成で最大 20 秒程度のクリップを出力できます。付属のアップスケーラを組み合わせれば、さらに高解像度・高フレームレートへ拡張することも可能です。カメラワークやプロンプト追従性も、前世代（LTX-2）から着実に強化されています。

ComfyUI にネイティブ対応している。 LTX-2.3 は ComfyUI のコア機能として組み込まれており、公式のカスタムノード群（ComfyUI-LTXVideo）とリファレンスワークフローも配布されています。つまり「ComfyUI で使うこと」が、開発元が想定する主要な使い方の一つになっています。この記事が ComfyUI を前提にするのはこのためです。

ここまでで「高性能だが規模が大きい統合モデル」というイメージが持てれば十分です。次章では、その規模がなぜ具体的な「重さ」に直結するのかを見ていきます。

3. なぜ動画生成モデルは「重い」のか（軽量化を理解するための土台）

軽量化の話に入る前に、そもそも何がメモリを食っているのかを理解しておくことが決定的に重要です。ここを飛ばして小手先の設定だけ真似すると、少し状況が変わっただけで対処できなくなります。逆にここさえ分かれば、あとの章はすべて「この重さをどこで削るか」という応用問題として読めます。

3-1. VRAM という制約

生成 AI の計算は基本的に GPU（グラフィックボード）の上で行われます。GPU には専用のメモリである VRAM（ビデオメモリ）が搭載されており、モデルの重みも、計算途中のデータも、まずこの VRAM に載せる必要があります。VRAM に載りきらないと、多くの場合 OOM（Out Of Memory、メモリ不足） というエラーで処理が止まります。「軽量に動かす」の大半は、この VRAM の限界とどう折り合いをつけるかという戦いです。

3-2. パラメータ数はそのままメモリ量に化ける

モデルの重みは、膨大な数の数値（パラメータ）の集まりです。この数値をどれくらいの精度（何バイト）で保持するかによって、必要なメモリが決まります。

• 標準的な bf16 / fp16（16 ビット）形式では、1 パラメータあたり約 2 バイト。

• fp8（8 ビット）形式なら、1 パラメータあたり約 1 バイト。

22B のモデルを bf16 で持つと、ごく単純計算で 22,000,000,000 × 2 バイト ≒ 約 44GB。実際にフルセットで約 46GB というサイズになるのは、まさにこの計算が効いているからです。この時点で、24GB や 16GB のカードには「そのままでは絶対に載らない」ことが分かります。軽量化の第一歩が量子化（精度を落としてバイト数を減らす）である理由が、ここにあります。

3-3. 本体だけではない ― 積み重なる「脇役」たち

やっかいなのは、VRAM を食うのがモデル本体だけではないことです。LTX-2.3 を動かすには、以下のような構成要素が必要になります。

• テキストエンコーダ（プロンプトを数値に変換する部品）。LTX-2.3 は Gemma 3 12B という 120 億パラメータ級の言語モデルをエンコーダに使います。これ単体でも相当なメモリを要求します。

• VAE（潜在表現と実際の映像・音声を相互変換する部品）。映像用と音声用があります。

• アップスケーラ（低解像度で作ったものを高精細に引き上げる部品）。

本体・エンコーダ・VAE・アップスケーラが順に、あるいは同時にメモリを占有するため、「本体だけなら載るのに全部そろえると落ちる」という状況が頻発します。軽量運用では、これらを同時に載せず順番に入れ替える(オフロードする)発想が鍵になります。

3-4. 動画特有の「フレーム爆発」

静止画生成に対して動画生成が桁違いに重い最大の理由は、フレーム数 × 解像度で計算量とメモリが膨らむことです。5 秒 24fps の動画は 120 枚分の画像を、しかも時間的な一貫性を保ちながら同時に扱う必要があります。解像度を上げれば1枚あたりの負荷も上がるため、負荷は掛け算で増えていきます。

この事実は、軽量化の非常に強力な打ち手を示唆しています。すなわち 「解像度・尺（秒数）・fps を落とす」だけで、メモリも時間も劇的に軽くなるということです。量子化やオフロードといった技術的な工夫に走る前に、まずここを見直すのが定石です。

以上を一言でまとめると、「22B の本体」＋「大きなテキストエンコーダ」＋「VAE などの脇役」＋「フレーム爆発」という4つの重さが積み重なっているのが、動画生成モデルの実像です。次章では、この4つの重さをどこで削るかを整理します。

4. 軽量化を考えるための「4つの軸」

軽量化のテクニックは無数にありますが、突き詰めると次の4つの軸に整理できます。個々の設定を覚えるより、「今やっている対策はどの軸か」を意識するほうが応用が利きます。

軸 A ― モデルの量子化（精度を落として容量を削る）

パラメータを bf16（2 バイト）から fp8（1 バイト）へ、さらに GGUF の各段階（Q8 → Q6 → Q4 → Q3…）へと精度を落とし、必要メモリを減らす方法です。軽量化の中でもっとも直接的で効果が大きい軸です。代償として画質やプロンプト追従性がわずかに落ちますが、多くの場合は許容範囲に収まります。詳しくは第5章で扱います。

軸 B ― 蒸留モデル・少ステップ化（生成時間を削る）

通常モデル（dev）は 1 本仕上げるのに 20 ステップ以上の反復計算が必要ですが、**蒸留（distilled）**されたモデルは 4〜8 ステップで結果を出せます。ステップ数がそのまま計算時間に効くため、これは主に「速度の軽さ」に効く軸です。メモリよりも「1本にかかる時間」に悩んでいるなら、ここが効きます。

軸 C ― オフロード / ウェイトストリーミング（VRAM の外へ逃がす）

VRAM に載りきらない部分を、より大容量なシステム RAM（メインメモリ）へ一時的に退避させながら計算する仕組みです。「載らないものを無理やり載せる」のではなく「載らない分は外に置いて、必要なときだけ持ってくる」という発想です。動作はしますが、VRAM ↔ RAM のデータ移動が発生するぶん速度は大きく落ちます。メモリの壁を越えるための最後の手段、という位置づけです。ここが効くぶん、システム RAM は 64GB 以上、理想的には 128GB を確保しておくと安定します。

軸 D ― 生成パラメータの節約（そもそも作る量を減らす）

第3章で触れた通り、解像度・尺・fps を下げれば、掛け算的に負荷が減ります。加えて VAE タイリング（映像を小さなタイルに分割して順に処理する）などの「分割処理」もこの軸に含まれます。技術的な難しさがほぼなく、効果が確実なため、最初に手を付けるべき軸です。

この4軸は排他的ではなく、実際の軽量運用では組み合わせて使います。たとえば「fp8 本体（軸 A）＋ 蒸留 LoRA で少ステップ化（軸 B）＋ Gemma エンコーダを CPU へ退避（軸 C）＋ 解像度控えめ（軸 D）」といった具合です。次章からは、この軸に沿って具体的なファイルや設定を見ていきます。

5. モデルの種類をそもそもから理解する（dev / fp8 / distilled / GGUF）

軽量運用でまず迷うのが「どのモデルファイルを落とせばいいのか」です。LTX-2.3 には用途とハードウェアに応じた複数のバリアントがあり、これを理解することが軽量化の第一歩になります。

5-1. dev（bf16）― フル精度・最高品質・最重量

dev モデルは bf16 のフル精度版で、もっとも高品質な出力が得られます。ファイル名は ltx-2.3-22b-dev.safetensors のような形です。その代わり VRAM 消費が最大で、フル精度で快適に動かすには 32GB 以上の VRAM が目安とされます。24GB 以下のカードでは、そのままではまず動きません。品質を最優先し、かつハイエンド GPU を持っている場合の選択肢です。

5-2. fp8 ― 精度をわずかに落として省メモリ

fp8 量子化版（ltx-2.3-22b-dev-fp8.safetensors）は、精度を 8 ビットに落とすことでメモリ使用量をおよそ半減させたバリアントです。品質の低下はわずかで、24GB クラスの GPU で 1080p 生成を狙う際の現実的な第一候補になります。「フル精度は載らないが、GGUF ほど落としたくない」という中間層に最適です。

5-3. distilled（蒸留）― 速度重視の軽量版

distilled モデルは、大きなモデルの振る舞いを小さく速いモデルに写し取った「蒸留版」です。少ないステップ（4〜8 程度）で出力でき、推論速度を重視する用途に向きます。同じプロンプトで安定した出力が得やすい反面、微細なテクスチャの表現にやや硬さが出る傾向があるとされます。

なお LTX-2.3 では、蒸留を単独モデルとしてではなく distilled LoRA（ltx-2.3-22b-distilled-lora-384.safetensors）という形で配布し、これを dev モデルなどに重ねて使う運用が一般的です。後述する「2段階ワークフロー」では、dev で下地を作り、distilled LoRA で仕上げを速く整える、といった合わせ技が使われます。

5-4. GGUF ― 低 VRAM 環境の主役

GGUF は、もともと大規模言語モデルの軽量化で広まった量子化フォーマットで、コミュニティ有志が LTX-2.3 用に変換版を公開しています。16GB、さらには 12GB クラスの環境で動かすなら、この GGUF が主役になります。

GGUF には量子化の強さに応じた段階（クオンツ）があり、代表的なものを軽い順に並べると Q3 → Q4 → Q5 → Q6 → Q8 となります。数字が小さいほどファイルが小さく省メモリですが、品質は落ちます。実務での定番は Q4_K_M で、「品質と圧縮率のバランスが良い」とされる一つの目安です。より攻めるなら Q3 系でさらにメモリを節約できますが、長いプロンプトのニュアンスが失われやすくなるため、複雑なシーン記述をしたい場合は注意が必要です。GGUF には dev 用と distilled 用の両方が公開されており、dev 用は 20 ステップ以上、distilled 用は 4〜8 ステップ、という使い分けは通常版と同じです。

GGUF を使うには、ComfyUI 側に GGUF を読み込むためのカスタムノード群（コミュニティ製の ComfyUI-GGUF など）が別途必要になります。この点は第8章で触れます。

5-5. どれを選ぶかの早見表

バリアント 精度/形式 主な狙い 向いている VRAM dev bf16 フル精度 最高品質 32GB 以上 fp8 8 ビット量子化 品質と省メモリの両立 24GB 前後 distilled（LoRA） 蒸留・少ステップ 速度重視・仕上げ用 併用前提 GGUF（Q4 など） 強い量子化 低 VRAM で動かす 12〜16GB

「まず動かすこと」を優先するなら、16GB 以下なら GGUF（Q4_K_M 目安）、24GB なら fp8、32GB 以上なら dev、という選び方が出発点になります。

6. 付随ファイルの正体（テキストエンコーダ・VAE・アップスケーラ・LoRA）

本体モデルだけでは LTX-2.3 は動きません。第3章で「脇役が積み重なる」と述べた、その脇役たちの正体と置き場所をここで整理します。軽量運用では、この脇役の選び方もメモリに効いてきます。

6-1. テキストエンコーダ（Gemma 3 12B）

プロンプトの意味を数値ベクトルに変換する部品で、LTX-2.3 は Gemma 3 12B を採用しています。ここにも軽量化の選択肢があります。

• 公式の量子化済み版：ComfyUI 公式配布の gemma_3_12B_it_fp4_mixed.safetensors は、あらかじめ低精度化されており省メモリです。まず動かすならこれが手軽です。

• GGUF 版：llama.cpp 系のノードで読み込むタイプ。Q4_K_M あたりが「品質を保ちつつ省メモリ」の落としどころとされます。

エンコーダは本体と同時に VRAM を占有すると OOM の引き金になりやすいため、低 VRAM 環境ではこの Gemma エンコーダを CPU 側に退避（オフロード）させるのが定番の対策です。テキストのエンコードはサンプリングほど GPU 性能を要求しないため、CPU に逃がしても数秒の追加で済み、そのぶん本体のための VRAM を確保できます。

6-2. VAE（映像用・音声用）

潜在空間と実際の映像・音声を変換する部品で、LTX-2.3 は音声も扱うため映像用・音声用の VAE が存在します。VAE のデコード（最終的に映像へ戻す工程）は解像度が上がるほどメモリを食うため、後述の VAE タイリングで分割処理するのが低 VRAM での常套手段です。

6-3. アップスケーラ（spatial upscaler）

低解像度で生成したものを高精細に引き上げる部品です。ltx-2.3-spatial-upscaler-x2-1.0.safetensors は 2 倍のアップスケール用で、後述の 2 段階ワークフローで中核的な役割を果たします。「低解像度で作ってから引き上げる」という発想自体が軽量化そのものなので、低 VRAM 運用ではむしろ積極的に使う部品です。

6-4. distilled LoRA

前章で触れた仕上げ用の LoRA です。dev の出力に重ねて使うと、少ステップで品質を整えられます。重ねる強さ（ウェイト）は 0.6〜0.8 あたりが良好という報告があり、弱すぎると効果が薄く、強すぎると出力が硬くなります。

6-5. ファイルの置き場所（標準構成）

ComfyUI で公式ワークフローを使う場合の標準的な配置は次の通りです。ファイル名の部分一致でノードが検索する仕組みのため、ダウンロード後にファイル名を勝手に変えないことが重要です（改名すると読み込み時にエラーになることがあります）。

ComfyUI/
├── models/
│   ├── checkpoints/
│   │   ├── ltx-2.3-22b-dev.safetensors        （dev 本体）
│   │   └── ltx-2.3-22b-dev-fp8.safetensors    （fp8 本体）
│   ├── loras/
│   │   └── ltx-2.3-22b-distilled-lora-384.safetensors
│   ├── latent_upscale_models/
│   │   └── ltx-2.3-spatial-upscaler-x2-1.0.safetensors
│   └── text_encoders/
│       └── gemma_3_12B_it_fp4_mixed.safetensors

なお GGUF を使う場合は配置が変わる点に注意が必要です。GGUF の本体は checkpoints ではなく unet（または diffusion_models）フォルダに置き、専用のローダノードで読み込むのが一般的です。GGUF ワークフローの多くはこの前提で組まれているので、配布元の手順に従うのが確実です。

7. 自分の GPU で何ができるのか ― VRAM 別の現実的な指針

ここまでの知識をもとに、自分の環境で何が現実的かを整理します。公式の推奨環境は VRAM 32GB / RAM 32GB / ストレージ 100GB 程度ですが、これを下回っても工夫次第で動きます。以下はあくまで目安であり、尺や解像度によって上下します。

VRAM 32GB 以上（A100 / RTX 6000 Ada など） フル精度の dev を含め、ほぼ制約なく運用できる領域です。オフロードに頼らず PyTorch のまま高速に回せます。品質を追い込みたい人向け。

VRAM 24GB（RTX 4090 など） fp8 量子化を使えば 1080p 生成も視野に入ります。ただし VRAM 使用率が 95% を超えると OOM が出やすくなるため、解像度・フレーム数は少し控えめが安全です。720p・24fps・5 秒程度なら安定動作が見込めます。

VRAM 16GB GGUF（Q4 目安）や fp8 を使い、後述のオフロードやタイリングを併用すれば動きます。報告例では、この帯でも本体 46GB クラスを RAM の助けを借りて動かせています。ただし 1 本あたりの時間はそれなりにかかります。

VRAM 12GB（RTX 4070 / RTX 3060 など） GGUF 量子化モデルとウェイトストリーミング（RAM オフロード）の併用が必須の領域です。Stage 1 を半解像度で回し、VAE をオフロードし、Gemma エンコーダを CPU に逃がす、といった総動員でようやく通ります。動きはしますが、5 秒のクリップに 45 分〜1 時間かかるケースもあるため、快適なイテレーションには不向きです。

共通して重要なのがシステム RAM。 オフロードは VRAM の不足を RAM で肩代わりする仕組みなので、低 VRAM 環境ほど RAM が効きます。最低 64GB、理想は 128GBを確保しておくと、オフロード時の安定性が大きく変わります。

GPU を持っていない/性能が足りない場合。 ローカル構築にこだわらず、クラウドの API で先に品質を確かめてから導入判断する、という選択肢もあります。開発元は用途別に「高速版」「本番品質版」といった API バリアントを提供しており、720p / 1080p などの解像度で秒課金の形で使えます。「そもそも自分の用途に LTX-2.3 が合うのか」を、機材投資の前にクラウドで見極めるのは合理的な進め方です。

8. 軽量セットアップの実際の流れ

考え方が整理できたところで、実際に軽量構成を組む手順を追います。ComfyUI の基本操作は割愛し、LTX-2.3 特有のポイントに絞ります。

8-1. まず ComfyUI を最新にする

これは軽視されがちですが最重要です。LTX-2.3 は比較的新しく、対応ノードやサンプラー、アップスケーラのローダは新しいバージョンにしか入っていないことがあります。「ノードが見つからない」というトラブルの大半は、ComfyUI が古いことが原因です。GGUF や KJNodes 系のコミュニティノードを使う場合は、それらも合わせて最新にしておきます。デスクトップ版は安定版ベースで更新が遅れることがあるため、最新機能を追う場合はポータブル版やナイトリー版が確実です。

8-2. 公式テンプレート/ワークフローから始める

ゼロから自分でノードを繋ぐのは、バージョン不整合の温床です。開発元と ComfyUI 公式が配布しているリファレンスワークフローを使うのが、遠回りに見えて一番の近道です。ComfyUI の「テンプレート（Template Library）」から「LTX-2.3」を検索し、まずは Text to Video か Image to Video の雛形を開き、案内に従って必要モデルをダウンロードするのが基本の流れです。低 VRAM 向けには、コミュニティが GGUF・オフロード前提で調整したワークフローも数多く公開されています。

8-3. 軽量構成のファイルを選んで配置する

第5〜6章の知識で、自分の VRAM に合わせてファイルを選びます。たとえば 16GB なら「GGUF 本体（Q4_K_M）＋ Gemma の GGUF または fp4 版 ＋ VAE ＋ spatial upscaler ＋ distilled LoRA」といった最小構成を、それぞれ正しいフォルダに配置します。ここでも改名しないことと、GGUF は unet 系フォルダという点を守ります。

8-4. 必要なカスタムノードを入れる

GGUF を使うなら GGUF 読み込み用のノード、低 VRAM 向けのローダやプレビュー用の軽量 VAE を使うなら対応するノードパッケージ（KJNodes 系など）を、ComfyUI Manager 経由で導入します。ここでも各ノードを最新に保つことが、LTX-2 系対応の前提になります。ワークフローを開いたときに「Install Missing Custom Nodes」の案内が出たら、それに従うのが手軽です。

8-5. 起動オプションを添える（任意だが有効）

低 VRAM 環境では、ComfyUI 起動時のオプションが効きます。代表的なのは、VRAM を一定量あらかじめ空けておく --reserve-vram（例：--reserve-vram 5 で 5GB 予約）や、メモリ移動を積極化する省 VRAM モードです。開発元のリポジトリには、32GB に収まるよう実行順序とオフロードを制御する低 VRAM 専用ローダも用意されています。

9.「2段階（two-stage）」ワークフローの考え方

低 VRAM 運用を理解するうえで欠かせないのが、この 2段階（two-stage / マルチステージ）パイプラインです。これは単なる小技ではなく、LTX-2.3 の軽量運用の設計思想そのものと言えます。

9-1. なぜ2段階に分けるのか

第3章の「フレーム爆発」を思い出してください。高解像度でいきなり生成すると、メモリも時間も跳ね上がり、しかも構図が気に入らなければ全部やり直しになります。そこで発想を変えます。

• Stage 1（下地作り）：まず低解像度で生成し、構図・動き・全体の方向性を素早く固める。負荷が軽いので何度も試せる。

• Stage 2（仕上げ）：Stage 1 の結果をアップスケーラで引き上げ、細部を精細化する。

こうすると、重い高解像度処理は「これで行く」と決まった1本にだけ掛ければよくなります。低 VRAM のカードでは、この分割が「動くか落ちるか」の分かれ目にもなります。1枚あたりの負荷を小さく保てるからです。

9-2. dev と distilled の組み合わせ方

2段階の各ステージに、どのモデルを割り当てるかにもコツがあります。よく使われるのは、**Stage 1 に dev（自由度が高く発想を広げやすい）、Stage 2 に distilled（引き締まって仕上がりが安定）**という組み合わせです。あるいは dev モデルに distilled LoRA を重ね、少ステップで下地から仕上げまでを通す構成もあります。distilled LoRA を使うときは、前述の通りウェイト 0.6〜0.8 が目安です。

9-3. ステップ数と CFG の考え方

• ステップ数：dev 系は 20 ステップ以上、distilled 系は 4〜8 ステップが目安。ステップは計算時間に直結するので、速度を稼ぎたいなら distilled 側を活用します。

• CFG（プロンプトへの従わせ具合）：高すぎると破綻や過剰な演出を招きやすく、これは「品質を落とす典型的な原因」の一つです。うまくいかないときは、まず CFG を下げてみるのが定石です。

2段階の狙いを一言でいえば、「軽い工程で方向を決め、重い工程は最小限に」です。この考え方は解像度・尺・fps の節約（軸 D）とも噛み合い、低 VRAM 運用の背骨になります。

10. VRAM 不足（OOM）で落ちるときの具体的対処

どれだけ準備しても、低 VRAM 環境では OOM に出くわします。ここでは「落ちたとき」に効く対処を、効果が確実な順に並べます。上から順に試すのが効率的です。

① まず解像度・尺・fps を下げる（軸 D）。 もっとも確実で副作用が少ない対処です。1080p を 720p に、10 秒を 5 秒に、48fps を 24fps に落とすだけで、負荷は掛け算的に軽くなります。「まず通すこと」を優先するなら、思い切って下げて成功体験を作り、そこから少しずつ上げていくのが賢いやり方です。なお解像度は縦横とも 32 の倍数にする必要がある点に注意します。

② 2段階パイプラインにする（第9章）。 いきなり高解像度で1発生成するのをやめ、低解像度 Stage 1 →アップスケール Stage 2 に分けます。1工程あたりの瞬間的なメモリ需要を下げられます。

③ Gemma エンコーダを CPU にオフロードする。 テキストエンコードを CPU 側に逃がすことで、本体サンプリングのための VRAM を空けます。数秒の追加時間で OOM を回避できることが多く、低 VRAM では定番の一手です。ノードが混在デバイス読み込みに対応していれば、負荷の重い層だけ GPU、残りは CPU、という細かい割り当ても可能です。

④ VAE をタイリング/分割デコードする。 最終の映像化工程でメモリが跳ねる場合、VAE を小さなタイルに分けて順に処理します。デコード時の OOM に効きます。

⑤ 起動オプションと「keep loaded」の見直し。 --reserve-vram で余白を確保する、省 VRAM モードでモデル入れ替え時のスパイクをならす、テスト中は大きなモデルの「keep loaded（常駐）」を切って使い終わったら解放する、といった運用面の調整が効きます。開発元提供の低 VRAM 専用ローダは、こうした実行順序とオフロードを自動で面倒見てくれます。

⑥ より強い量子化に落とす（軸 A）。 ここまでで足りなければ、fp8 を GGUF Q4 へ、Q4 を Q3 へと一段階落とします。品質とのトレードオフが最も大きい対処なので、他の手を尽くしてから検討します。

⑦ RAM を増やす/クラウドに逃がす。 オフロードは RAM に依存するため、そもそも RAM が少ないと③〜⑤の効果が頭打ちになります。ハードの増設が難しければ、その生成だけクラウド API に逃がすのも現実的な判断です。

「①→⑦の順で試す」と覚えておけば、OOM に遭遇しても闇雲に設定をいじらずに済みます。

11. 品質と軽さのトレードオフを賢く取る

軽量化は「品質をどこまで捨てるか」の判断でもあります。ここでは、無駄に品質を落とさずに軽くするための実践的なコツをまとめます。

量子化は「必要なだけ」落とす。 とにかく Q3 まで落とせば軽いのは確かですが、長いプロンプトのニュアンスが失われるなど代償も大きくなります。まず Q4_K_M や fp8 で試し、それでも載らない場合にだけ一段下げる、という順序を守ると、無駄に画質を落とさずに済みます。

プロンプトは「動き」で書く。 LTX-2.3 は動きやカメラワークの記述に強く反応します。「golden hour の市場を歩く女性」よりも、「カメラが左へゆっくりトラッキングし、夕暮れの屋外市場を歩く女性、背景に布地の露店」のように、カメラの動き・被写体の動作・光を具体的に書くと出力が安定します。一方で、要素を詰め込みすぎると破綻しやすくなるため、欲張りすぎないバランスが大切です。

「品質を殺す三大原因」を先に潰す。 アスペクト比の誤り、CFG の上げすぎ、プロンプトの詰め込みすぎ ― この3つが典型的な品質低下要因です。細かいチューニングに入る前に、まずこの3点を正すのが近道です。

激しい動きと複雑な人物描写は苦手と心得る。 大きなカメラ移動や被写体の激しい動作を入れると、動いた瞬間に被写体が崩れることがあります。低 VRAM で試行回数が稼げないときほど、まずはカメラ固定・穏やかな動きから始め、安定を確認してから難度を上げるのが安全です。実写系に比べてアニメ系はやや不得手とされる点も、素材選びの参考になります。

日本語のセリフを喋らせるときの工夫。 音声も生成できるのが強みですが、日本語のセリフ部分はヘボン式ローマ字に変換してから渡すと発音が改善する、という運用ノウハウがあります。変換には十分な性能の言語モデル（9B 級以上）を使うと失敗が減り、同梱の Gemma 3 12B を流用すれば外部ツールなしでも処理できます。

まずクラウドで「当たり」を付ける。 ローカルで低 VRAM と格闘する前に、クラウド API で数本作ってみて、狙った品質や表現が出るのかを確かめる。そのうえでローカル軽量構築に踏み込む ― これは時間もお金も節約できる、地に足のついた進め方です。

古いバージョンの重みを混ぜない。 LTX-2.3 は前世代から潜在空間や内部構造が更新されています。過去バージョン（2.0 / 2.1 / 2.2）の重みや、旧バージョン向けに作られた LoRA をそのまま 2.3 のワークフローに流用すると、クラッシュしたり、エラーも出ないまま出力が崩れたりします。2.3 は「まっさらな新規導入」として扱うのが安全です。自作 LoRA を持っている場合は、2.3 の潜在空間向けに作り直す必要があります。

12. よくある失敗と対策

最後に、つまずきやすいポイントを一覧で整理します。

13. おわりに

LTX-2.3 の軽量運用は、突き詰めれば「22B の本体・大きなテキストエンコーダ・VAE などの脇役・フレーム爆発という4つの重さを、量子化・少ステップ化・オフロード・生成量の節約という4つの軸でどこまで削るか」というシンプルな構図に還元できます。

この記事で一貫して伝えたかったのは、個別の設定値を暗記するのではなく、原理から逆算する姿勢です。「なぜ VRAM が足りないのか」が分かれば、次に打つべき手（解像度を下げるのか、量子化を強めるのか、オフロードするのか）は自ずと選べます。バージョンが上がっても、別の動画モデルに乗り換えても、この考え方はそのまま使えます。

現実的な始め方をまとめると、次のようになります。まず自分の VRAM を確認し、それに合ったバリアント（12〜16GB なら GGUF、24GB なら fp8、32GB 以上なら dev）を選ぶ。公式のリファレンスワークフローを最新の ComfyUI で開く。最初は解像度・尺・fps を控えめにして「まず通す」。うまく通ったら 2 段階パイプラインで品質を引き上げ、OOM が出たら第10章の順序で対処する。品質が用途に合うか不安なら、ローカル構築の前にクラウド API で試す ― この流れをたどれば、限られたマシンでも LTX-2.3 の実力を引き出せるはずです。

参考にした主な情報源

• ComfyUI 公式チュートリアル「LTX-2.3 ComfyUI Workflow Examples」（docs.comfy.org）― モデル一覧・配置・公式ワークフロー

• 開発元公式ドキュメント（docs.ltx.video）およびモデル配布ページ ― バリアント構成・API・移行ガイド

• 開発元の ComfyUI 用カスタムノードリポジトリ（ComfyUI-LTXVideo）― 低 VRAM 向けローダ・起動オプション・サンプルワークフロー

• コミュニティ配布の GGUF 量子化版および解説（QuantStack / unsloth ほか、ComfyUI-GGUF 対応）― 量子化段階と品質の目安

• 各種セットアップ実践記事 ― 2 段階パイプライン、CPU オフロード、VRAM 別の実測傾向