更新で壊れたComfyUIは、更新前に保存したSnapshotを「Restore」して再起動すれば、本体のcommit・Custom Nodeのversion・pip packageをまとめて元に戻せます。Snapshotが無い場合でも、本体・Frontend・Manager・Custom Nodeを別の層として扱い、1層ずつ戻せば原因の層を特定できます。
情報確認日：2026年8月22日（日本時間）
結論：更新の前にSnapshotを取り、壊れたら全部ではなく1層だけ戻す
責任範囲
- ComfyUIを構成する4つの層（本体・Frontend・Manager・Custom Node）と、それぞれの「戻し方」の違い
- 更新前に残す記録（version・Workflow・Node一覧・設定）と、ManagerまたはDesktopでSnapshotを作る手順
- 壊れた環境をSnapshotから切り戻し、最小Workflowで動作を確認する手順
- 一括再更新を避け、差分を1つずつ戻して原因の層を特定する考え方
- OS丸ごとのバックアップやモデルファイルの保管方法は扱わず、Custom Nodeの導入・更新操作そのものはComfyUI Managerの記事に渡す
なぜ復元点が必要か：ComfyUIは4つの層が別々に更新される
ComfyUIの「更新」は1つの操作に見えて、実際には独立した4つの層が別々に変わります。どれか1つを上げただけでも組み合わせが変わるため、動いていた環境が壊れる可能性があります。
| 層 | 何が変わるか | どう記録するか | どう戻すか |
|---|---|---|---|
| 本体（ComfyUI core） | Pythonの実行部、組み込みNode、model読み込み | Gitのcommit hash、またはSettingsのAboutに出るversion | git checkout <commit>、またはSnapshotのRestore |
| Frontend | 画面側のUI。Node Docs、Subgraphなどの機能 | pip packageのversion（comfyui-frontend-package） |
requirements.txtの指定に合わせてpipで入れ直す |
| Manager | Custom Nodeの導入・更新機能自体 | Managerのversion | Managerだけを前のversionに戻す |
| Custom Node | 各packのコード、および各packが要求するpip依存 | Registryのversion、またはGitのcommit hash | Snapshot、または1packずつversion指定で入れ直す |
復元点が必要な理由は、壊れた後に「どの層が変わったか」を思い出せないからです。Update Allのように複数の層を同時に上げると、原因が本体なのか、特定のCustom Nodeなのか、それが要求したpip packageなのかを記録なしに切り分けるのは困難です。
Frontendは本体とは別のpip packageなので、本体のcommitを戻しただけでは画面側が戻らない場合があります。本体のrequirements.txtにversion指定があるため、本体を戻したら依存の再インストールまでを1セットと考えてください。
更新前に残す情報：version・Workflow・Node一覧・設定の4点
Snapshotが記録するのはコードと依存の状態だけで、動いていたWorkflowや設定は含まれません。更新の前に次の4点を残します。
- version：本体のcommit hash（またはAboutの表示）、Frontend・Managerのversion、主要Custom NodeのversionまたはcommitをSnapshotと一緒に控える
- Workflow：普段使うWorkflowを「Export」してJSONで保存する。更新後の動作確認に使う「最小Workflow」も1つ用意しておく
- Node一覧：導入済みCustom Nodeの一覧。Managerのinstalled表示か、
custom_nodes/のdirectory名を書き出す - 設定：
extra_model_paths.yaml、起動引数（.batやshell script）、Managerのconfig.iniなど、自分で編集したファイル
記録は次の表に埋めておくと、復元後の比較がそのまま確認になります。
| 項目 | 更新前 | 更新後 | 復元後 |
|---|---|---|---|
| 本体 commit / version | |||
| Frontend version | |||
| Manager version | |||
| Custom Node数（Import Failed数） | |||
| 最小Workflowの生成可否 | |||
| Snapshotファイル名 |
Snapshotを作成・確認する：Manager・Desktop・CLIの3経路
Snapshotの作成経路は導入形態によって3つあり、記録する範囲と復元の動きが少し違います。以下は現行UI（2026年8月時点）の名称で、画面と異なる場合は公式ドキュメントで最新の名称を確認してください。
1. ComfyUI ManagerでSave snapshotする
Managerのメニューにある「Save snapshot」を押すと、その時点の状態が<USER_DIRECTORY>/default/ComfyUI-Manager/snapshotsにJSONとして保存されます。「Update All」を実行したときにも自動で作られます。記録されるのは、公式READMEによると次の4つです。
- ComfyUI本体のcommit hash
- Gitで管理されているCustom Nodeとそのcommit
- ファイル単位で置かれたCustom Node
- 導入済みのpip依存
保存後のファイルは名前を変えて構いません。「2026-08-22_before_update.json」のように、何の前に取ったかが分かる名前にします。JSON内のキー名はManagerのversionで変わるため、手元のファイルを開いて確認してください。
公式READMEには、Git管理ではないCustom Node（zipを展開して置いたものなど）はSnapshot対応が不完全だと明記されています。そうしたpackはdirectoryごとコピーを残してください。
2. ComfyUI DesktopのSnapshotsタブ
Desktop版のSnapshotは、ComfyUIのversion・各Custom Nodeのversionまたはcommit・pip packageを記録し、起動・再起動・更新の前後・復元後に自動で取られます。手動で取るときは「Manage」パネルの「Snapshots」タブから「Create Snapshot」を押します。復元前に「Diff vs Current」で差分を見られるので、何が戻るかを確認してから実行できます。
3. cm-cliで保存する
画面を開かずに残したい場合や、更新scriptに組み込みたい場合はcm-cliを使います。
# ComfyUI-Manager のdirectoryで実行
python cm-cli.py save-snapshot
python cm-cli.py save-snapshot --output ./before_update.yaml
# 保存済みSnapshotの一覧
python cm-cli.py simple-show snapshot-list作成後はファイルの存在と、中身にCustom Nodeの一覧が入っていることを確認します。
壊れた環境を切り戻す：Restore→再起動→最小Workflow
更新後に起動しない、Nodeが赤くなる、生成が止まるといった症状が出たら、原因探しの前にまず動いていた状態に戻します。戻してから差分を見る方が早いからです。
- ManagerのSnapshot一覧から、更新前に取ったものを選び「Restore」を押す（cm-cliなら
python cm-cli.py restore-snapshot <file>） - ComfyUIを再起動する。Manager版の復元は
startup-scripts/restore-snapshot.jsonに書かれた指示を起動時に適用する仕組みなので、再起動するまで反映されない - 起動logの「Import times for custom nodes:」一覧を見て、「(IMPORT FAILED)」が更新前と同じ数に戻ったか確認する
- 最小Workflow（Load Checkpoint→CLIP Text Encode×2→Empty Latent Image→KSampler→VAE Decode→Save Image）を読み込み、1枚生成する
- 最小Workflowが通ったら、普段使うWorkflowを読み込み、Missing Nodeの警告が出ないことを確認する
最小Workflowから確認するのは、Custom Nodeを使わない構成が通るかどうかで本体の層を先に判定できるからです。通らないなら本体かFrontend、通るのに普段のWorkflowが通らないならCustom Nodeの層に絞れます。
復元テスト：壊れる前にリハーサルしておく
復元できることを一度も確かめていないSnapshotは保険になりません。余裕のあるときに、更新→不具合→復元をリハーサルしておきます。
- 現在の状態でSnapshot Aを取り、最小Workflowで1枚生成して前節の記録表の「更新前」欄を埋める
- 使っていないCustom Nodeを1つ、わざと古いversionで導入する（Registryのversion指定、またはGitの古いcommit）
- 再起動し、logの「(IMPORT FAILED)」の数や、Missing Nodeの警告を「更新後」欄に記録する
- Snapshot AをRestoreして再起動し、「復元後」欄を埋める
- 「更新前」と「復元後」の各行が一致していれば、そのSnapshotは復元に使える
一致しない行があれば、そこがSnapshotの記録範囲の外です。Git管理でないpackが戻らなかったなら、その層は手動コピーで補います。表には実測した値だけを書いてください。
差分を一つずつ戻す：一括再更新は原因を隠す
Snapshotが無い、または復元しても直らない場合に「Update Allで全部最新にする」のは避けてください。複数の層を同時に動かすと、直っても原因が分からず、次の更新で同じ事故が起きます。進め方は、疑わしい層を1つだけ戻し、再起動して最小Workflowを通す、の繰り返しです。
| 順番 | 戻す層 | 戻し方の例 | 確認すること |
|---|---|---|---|
| 1 | 直前に更新したCustom Node | Managerでversionを1つ前に指定、または.disabledを付けて無効化 |
logのImport Failedが消えるか |
| 2 | 本体 | git logで更新前のcommitを確認しgit checkout |
最小Workflowが通るか |
| 3 | Frontend | requirements.txtの指定に合わせてpipで入れ直す | 画面の表示崩れ・Node Docsなどの機能が戻るか |
| 4 | Manager | Managerだけを前のversionに戻す | Manager画面が開き、一覧が出るか |
1つ戻すごとに記録表と同じ項目を確認し、直った時点で止めて原因の層を記録してから、残りを1つずつ上げ直します。無効化すると直るCustom Nodeを使い続けたい場合は、依存エラーの読み方をImport Failedの切り分け記事で確認してください。
Registryに公開されたCustom Nodeのversionは公開後に変更されないため、「動いていたversion」を記録しておけば、同じversionを指定して入れ直せます。Gitのcommitで入れたpackも同様に、hashを控えていれば同じ状態を再現できます。
Gitでも残すべきもの：SnapshotがカバーしないWorkflowと設定
Snapshotはコードと依存の状態を戻す道具で、自分で作ったものは守りません。次のものはGitで履歴を残します。
- Workflow JSON（ExportしたファイルとAPI形式の両方）
extra_model_paths.yaml、起動script、Managerのconfig.iniなど編集した設定ファイル- 更新前後の記録表（Markdownにして同じrepositoryに置く）
- Snapshot JSONそのもの（どの状態で動いていたかの証跡として）
逆に、モデルファイルやCustom Nodeのコード本体はGitに入れません。モデルは大きすぎ、Custom Nodeは配布元に履歴があるからです。Workflow JSONの差分の読み方は、Git管理の別記事で扱います。
よくある質問
Snapshotを取り忘れて更新してしまいました。戻せますか？
本体はgit logで更新前のcommitを探しgit checkoutすれば戻せます。Custom Nodeは、「Update All」が自動でSnapshotを作っているのでsnapshotsのdirectoryを確認してください。Desktop版なら起動のたびに自動Snapshotが残っています。
RestoreしたのにCustom Nodeが古いままです。
Manager版の復元は再起動時に適用されるため、まず再起動したかを確認してください。再起動しても戻らないpackは、Git管理でないpackである可能性があります。そのpackはdirectoryごと手動で入れ替えます。
Snapshotは何個まで残せばいいですか？
「最後に安定していた状態」が1つあれば復元できます。更新のたびに取り、動作確認が済んだら古いものを削除する運用にすると迷いません。Desktop版は自動Snapshotの上限が200個です。
まとめ
ComfyUIを更新前の状態に戻す基本は、更新の前にSnapshotを取り、壊れたらRestoreして再起動し、最小Workflowで本体の層から順に確認することです。Snapshotが無いときや復元で直らないときは、Update Allで全部を動かすのではなく、Custom Node→本体→Frontend→Managerの順に1層ずつ戻して原因を特定します。
Snapshotは復元できることを一度確かめて初めて保険になります。記録表とWorkflow・設定のGit管理を組み合わせ、戻れる状態を先に作ってから更新してください。