Stability MatrixでForge Neo・ComfyUIを始める方法｜モデル共有までまとめて管理

Stable Diffusion系のローカル画像生成を始めるとき、最初からPython、Git、仮想環境、モデルフォルダをUIごとに手動管理する必要はない。

Forge NeoとComfyUIのどちらを使うか迷っているなら、Stability Matrixを一段上の管理アプリとして使う方法がある。

Stability Matrixは複数の画像・動画生成パッケージを個別の環境として導入・管理し、Checkpoint、LoRA、VAE、ControlNet、アップスケーラーなどのモデル資産を共有ライブラリから扱える。

2026年9月時点の公式対応一覧には、Stable Diffusion WebUI Forge - NeoとComfyUIの両方が現行の推論パッケージとして掲載されている。一方、上流のStable Diffusion WebUI ForgeやForge ClassicはLegacy Packages側に分けられている。

図を拡大して見る

図1：最初からUIを一つに固定する必要はない。Forge Neoを普段のフォーム型生成、ComfyUIを複雑なワークフローへ使い分けながら、モデル資産は共有できる。

この違いは重要だ。

「Forgeを入れる」という古い手順をそのまま使うのではなく、いまStability Matrixがどのパッケージを現行として扱っているかを確認して導入する。

Stability Matrixを使う最大の利点はUIを交換しやすいこと

通常、画像生成UIを個別に入れると、UIごとにPython環境やモデルフォルダを持ちやすい。

すると、

• 同じCheckpointをForge系とComfyUIへ二重保存する
• LoRAの保存場所がUIごとに違う
• どのPython環境へ何を入れたか分からなくなる
• UIを試すたびに数十GB単位で資産が増える

といった管理問題が起きる。

Stability Matrixは、対応パッケージを分離した環境として管理しつつ、モデル資産は共有モデルライブラリから扱える設計になっている。

そのため、Forge Neoで普段生成し、必要なときだけComfyUIを使う構成を作りやすい。

最初のUIはForge NeoとComfyUIのどちらがいいか

画質だけで決めるものではない。

同じモデルと近い生成条件を再現できるなら、UI名そのものが画質を決めるわけではない。

違いは操作方法にある。

まず画像を生成したいならForge Neo

Forge NeoはAUTOMATIC1111系のフォーム型UIを引き継ぐ。

プロンプト、Checkpoint、サンプラー、ステップ数、CFG、解像度などを画面上の欄へ入れて生成するため、処理のノードを一から組まなくても画像生成へ進める。

次のような用途なら、最初のUIとして理解しやすい。

• txt2imgをすぐ使いたい
• CheckpointやLoRAを切り替えて試したい
• プロンプトと設定値を触りながら覚えたい
• ノード構成そのものを今は学びたくない

ただしForge Neoは上流Forgeがそのまま改名したものではなく、派生した継続系統だ。公式のStability Matrix対応一覧でも独立したパッケージとして扱われている。

また、Forge Neo側はNVIDIA中心の対応方針を示している。AMDやIntelで同じ手順が使えると決めつけない。

複雑な処理を組みたいならComfyUI

ComfyUIは、モデル読み込み、テキスト条件、サンプリング、VAEデコード、保存などをノードとして接続する。

最初の1枚だけを見るとForge Neoより操作量が多く感じやすいが、処理が複雑になるほど強みが出る。

• ControlNetを複数使う
• 処理途中で分岐する
• 画像から動画生成へつなぐ
• アップスケール後に再生成する
• 同じ処理をAPIから繰り返す
• 配布されたワークフローを再利用する

といった用途では、処理全体をグラフとして保持できることが利点になる。

Stability Matrix自身のInference UIもComfyUIを実行バックエンドとして利用する構成を持っている。

つまり、ComfyUIは「ノード画面を毎回自分で操作するためだけのUI」ではなく、画像生成処理を実行する基盤としても使える。

初めて導入するときの進め方

初めてローカル画像生成を触るなら、次の順番が分かりやすい。

1. Stability Matrixを導入する
2. データ保存先を決める
3. Forge NeoかComfyUIのどちらか一方だけ入れる
4. 共有モデルライブラリへCheckpointを1つ追加する
5. 標準的なtxt2imgを1枚成功させる
6. LoRAを1つ追加する
7. 必要になったら2つ目のUIを追加する

最初からForge NeoとComfyUIの両方へ大量の拡張機能やカスタムノードを入れる必要はない。

先に「どのモデルで、どのUIなら正常に1枚生成できるか」を基準として残した方が、問題発生時に切り分けやすい。

モデルを共有できても、すべてが完全互換になるわけではない

共有モデルライブラリは便利だが、同じファイルが見えることと、同じ方法で使えることは別だ。

たとえば、

• SD1.5用LoRAとSDXL用LoRA
• 特定のComfyUIカスタムノードを必要とするモデル
• Forge Neo側の実装に依存する機能
• UIごとに読み込み方が異なる新しいモデル形式

は個別に確認する必要がある。

Checkpoint、VAE、LoRAの役割が曖昧なら、ComfyUIのチェックポイント・VAE・LoRAは何が違う？で先に整理できる。

ComfyUI Desktopを単独で使う方法もある

Stability Matrixが常に最適という意味ではない。

ComfyUIだけを使い、ComfyUI Desktopの管理方法に統一したいなら、WindowsでComfyUI Desktopを始める方法の方が構成は単純になる。

ComfyUI Desktop・Portable・手動導入の違いはComfyUI Desktop・Portable・手動インストールはどれを選ぶ？で分けている。

一方、Forge NeoとComfyUIを比較したい、モデルを共有したい、後から別UIも試したいなら、Stability Matrixを管理層に置く意味が大きい。

GPUより先にUIを増やしすぎない

画像生成ではVRAM容量も重要だが、環境が複雑になる原因はGPUだけではない。

UI、モデル系列、Checkpoint、LoRA、拡張機能を同時に変えると、エラーが起きたときに原因が分からなくなる。

まず一つの環境で生成を成功させ、そのあと必要な機能だけ増やす。

GPU容量を選ぶ段階なら、画像生成用GPUのVRAMは8GB・12GB・16GB・24GBで何が変わる？で、モデル・解像度・バッチ・オフロード条件から考えられる。

Stability Matrixの価値は「全部を自動で正解にしてくれる」ことではない。

複数の画像生成UIとモデル資産を、一つの入口から整理して管理できることにある。

最初はForge Neoで簡単に生成し、必要になったらComfyUIを追加する。その逆に、最初からComfyUIの処理構造を学びたいならComfyUIだけ入れる。

どちらも同じ管理環境から始められることが、Stability Matrixを使う大きな利点になる。