ComfyUIのSubgraphは、複数のノードを「入力と出力を持つ1つのノード」に畳み込み、再利用できる処理単位にする機能です。見た目を囲うだけのGroupと違い、中身を隠したまま別の場所や別のワークフローで同じ処理を呼び出せます。
情報確認日：2026年8月22日（日本時間）
結論：Subgraphは「囲う」ではなく「1つのノードにする」
責任範囲
- SubgraphとGroupの違い（整理か、再利用可能な処理単位か）
- VAE Decodeなど小さな単位で作る手順と、解除（Unpack）の方法
- 外から渡す値と内部で固定する値の境界の決め方
- 前処理・保存・アップスケールなど役割単位での設計
- 命名と依存関係の記録、部品化しすぎる失敗の避け方
ワークフローファイルの保存・読み込み・依存確認の一般論はComfyUIのworkflow JSONを読み込む方法で扱っています。利用者向けに入力と出力だけを見せる画面が目的なら、SubgraphではなくApp Modeが該当します。
SubgraphはGroupと何が違うのか
Groupはノードを色付きの枠で囲み、まとめて動かせるようにする「見た目の整理」です。Subgraphは選んだノードを1つのノードに畳み込み、外から見える入力スロットと出力スロットを定義する「処理の単位」です。公式ドキュメント（2026年8月22日確認）には両者を並べた比較はないため、以下は各機能の説明から整理したものです。
| 観点 | Group | Subgraph |
|---|---|---|
| 目的 | 配置の整理、まとめて移動 | 処理の部品化と再利用 |
| 中身の見え方 | すべて見える | 1つのノードに畳まれ、中は編集モードで見る |
| 入出力 | 定義しない | スロットとして定義する |
| ネスト | 枠を重ねるだけ | Subgraphの中にSubgraphを置ける |
| 別ワークフローでの再利用 | コピー＆ペーストのみ | Blueprintとしてノードライブラリに登録できる |
| 必要バージョン | 従来から利用可 | フロントエンド1.24.3以降（Blueprintは1.27.7以降） |
使い分けの基準は「同じ処理を2か所以上で使うか」です。1か所にしか出てこない処理は、Groupで囲って名前を付ければ十分です。同じ処理を複数のワークフローで使い、直すときは1回で済ませたいならSubgraphにします。
最小の処理をSubgraph化するには
初めて作るなら、VAE DecodeとSave Imageの2つだけをSubgraphにしてみてください。小さすぎて実用性はありませんが、入出力スロットがどう生まれるかが一番よく分かります。手順は現行UI（2026年8月時点）のものです。
- VAE DecodeノードとSave Imageノードを範囲選択する
- 選択ツールボックスに表示されるSubgraphアイコンをクリックする
- 2つのノードが1つのSubgraphノードに置き換わり、外から入っていた配線（LATENT、VAE）が入力スロットとして自動生成される
- Subgraphノードの空白部分をダブルクリックするか編集ボタンを押して、編集モードに入る
- 編集モードの中で、入力スロットと出力スロットの名前を右クリックから変更する
- ナビゲーションバーから親に戻るか、Escキーで編集モードを出る
元のノードに戻したいときは、Subgraphノードを右クリックして「Unpack subgraph」を選ぶか、選択ツールボックスの同名ボタンを押します。作る・戻すを一往復すると、Subgraphが「配線を切らずに畳んでいるだけ」であることが体感できます。
Subgraph作成のキーボードショートカットは、公式ドキュメントに記載がありません（2026年8月22日確認）。この記事ではツールボックスからの操作だけを示します。
入力と出力の境界をどう決めるか
Subgraphの設計で一番悩むのがここです。原則は「呼び出す側が変えたい値だけを入力にし、それ以外は中に固定する」です。
アップスケール処理をSubgraphにする例で考えます。
| 値 | 扱い | 理由 |
|---|---|---|
| 元画像（IMAGE） | 入力スロット | 毎回違う |
| 拡大倍率 | 入力スロット（ウィジェット） | 用途で変えたい |
| アップスケールモデル名 | 内部で固定 | この部品の「性格」そのもの |
| タイル分割サイズ | 内部で固定 | 呼び出す側に判断させたくない |
| 拡大後の画像（IMAGE） | 出力スロット | 次の処理に渡す |
迷ったら「この値を変えるとき、部品の名前も変わるべきか」と考えます。アップスケールモデルを変えると別の部品になるので固定し、倍率を変えても同じ部品なので入力にする、という判断です。
ComfyUI v0.3.66以降では、Subgraphに入らずに内部ウィジェットを操作できるパラメータパネル（「Edit Subgraph Widgets」）があり、ドラッグで並び替え、アイコンで表示・非表示を切り替えられます。「呼び出す側に見せる値」をここで整えると、入力スロットを増やさずに調整余地を残せます。
再利用しやすいSubgraphはどう設計するか
役割単位で分けます。ノードの数ではなく、「この部品は何をする部品か」が一言で言えるかどうかで切ります。
- 前処理：画像の読み込み、リサイズ、ControlNet用の輪郭抽出など「生成の前に素材を整える」部品
- 生成本体：モデル読み込み、プロンプト、サンプラーなど「潜在空間で絵を作る」部品。ここは変更が多いのでSubgraph化を急がない
- 後処理：VAE Decode、アップスケール、顔補正など「できた画像を整える」部品
- 保存：ファイル名の規則、メタデータ、保存先を決める部品
この分け方なら、「保存の規則を変えたい」ときは保存Subgraphだけを開けばよく、「アップスケールモデルを差し替えたい」ときは後処理だけを触れば済みます。生成本体を最後に回すのは、試行錯誤の段階で畳んでしまうと、中を開いたり閉じたりする回数が増えて逆に遅くなるからです。
複数のワークフローで使う部品は、Blueprintとしてノードライブラリに登録します（フロントエンド1.27.7以降）。選択ツールボックスの本のアイコン、またはメニューの「Add Subgraph to Library」から登録し、編集はBlueprint編集モードでCtrl+Sで保存します。
再現手順：表示ノード数の変化を数える
- ノード数が30個前後のワークフローを用意し、画面に見えるノード数を数える
- 前処理・後処理・保存の3か所をSubgraph化する
- 再び画面に見えるノード数と、Subgraphを開かずに変更できるウィジェット数を数える
| 記録項目 | Subgraph化前 | Subgraph化後 |
|---|---|---|
| 最上位に見えるノード数 | ||
| 最上位の配線の本数 | ||
| Subgraphを開かずに変更できるウィジェット数 | ||
| 1つの値を変えるために開いた階層の数 |
最上位のノード数と配線は、畳んだ分だけ減るはずです。見るべきは4行目で、「よく変える値」を内部に固定してしまうと、この数が増えて作業が遅くなります。減った行と増えた行を見比べて、入力スロットの設計を見直してください。
命名と依存関係をどう残すか
Subgraphは中身が隠れるので、半年後の自分や共同作業者が「この部品は何に依存しているか」を外から読めるようにしておきます。
名前は「役割＋前提」の形にします。
良い例
upscale-2x-realesrgan-v1
preprocess-canny-for-sdxl
save-png-with-metadata
避けたい例
subgraph1
new-subgraph
テスト名前だけでは足りない情報は、Subgraphの中にNoteノードを置いて記録します。
purpose: 商品写真の背景を白に統一して保存
inputs: IMAGE（元画像）, scale（倍率）
outputs: IMAGE
fixed: upscale model = <モデルファイル名>, tile = <値>
requires: <custom nodeのリポジトリ名と確認したversion>
base model: SDXL系のみ確認
updated: 2026-08-22Subgraphを含むワークフローJSONを配るときは、中で使っているcustom nodeとモデルが相手側にも必要です。Subgraphに畳んであっても依存が消えるわけではありません。保存前後のJSONをdiffで見ると、Subgraphがどの形で記録されているかが読めます。公式ドキュメントには保存形式の詳細が記載されていないため、キー名はここで断定せず、手元の差分で確認してください。
diff <(jq -S . before-subgraph.json) <(jq -S . after-subgraph.json) | head -n 80ノードごとの説明の書き方と、ワークフローをGitで履歴管理する方法は、別記事で扱います。
Subgraph化しすぎるとどう失敗するか
Subgraphは便利なぶん、やりすぎると「どこで何が起きているか分からない」状態を自分で作ってしまいます。典型的な失敗は3つです。
ブラックボックス化：生成本体までSubgraphに畳むと、エラーが出たときにどのノードで止まったかを探すために階層を掘ることになります。実行中に赤くなるノードが最上位から見えない状態は、デバッグの時間を確実に増やします。
細分化しすぎ：2〜3ノードの塊をすべてSubgraphにすると、最上位はきれいでも、1つの値を変えるたびに開閉が必要になります。上の記録表で「開いた階層の数」が増えたら、この状態です。
コピーによる分岐：同じSubgraphを2つのワークフローにコピーし、片方だけ直すと、名前が同じで中身が違う部品が生まれます。複数で使う部品はBlueprintに登録し、ワークフロー側には「どのBlueprintのどの版か」をNoteで残します。
目安として、最初は「前処理・後処理・保存」の3つだけをSubgraphにし、それで困らなければ増やさない、という運用が安全です。部品の数が増えるほど、命名とNoteの負担も増えます。
よくある質問
Subgraphにすると実行が速くなりますか？
なりません。中のノードはそのまま実行されます。速くなるのは、ワークフローを読む時間と、変更箇所を探す時間です。
Subgraphの中のノードは、外から個別に実行できますか？
編集モードで中に入れば、中のノードを通常どおり扱えます。外からは1つのノードとして見えるので、最上位では内部ノードを個別に選択できません。
Groupで囲ったノードをそのままSubgraphにできますか？
Groupはあくまで枠なので、Subgraphにしたいノードを選択してSubgraphアイコンを押す操作は同じです。先にGroupで役割ごとに囲っておくと、どの範囲をSubgraphにするかの当たりが付けやすくなります。
まとめ
Subgraphは、複数ノードを入力と出力を持つ1つのノードに畳み、再利用できるようにする機能です。見た目を整理するGroupと違い、同じ処理を複数のワークフローで呼び出し、1回の修正で済ませるための仕組みです。
最初はVAE Decodeなど小さな単位で作って解除し、次に前処理・後処理・保存の3つを役割単位で部品化します。入力スロットは「呼び出す側が変えたい値」だけにし、名前とNoteで依存を残し、生成本体は試行錯誤が落ち着くまで畳まないでください。