現行のComfyUI Manager（2026年8月時点）はComfyUI本体に組み込まれ、Custom NodeをComfy Registryのversion単位で導入・更新します。新UIでは、Managerボタンからnode packを検索し、Missing Nodeは読み込み時のプロンプトかMissingフィルタで特定します。更新は本体・Frontend・Manager・Custom Nodeを一度に行わず、1種類ずつ進めるのが基本です。
情報確認日：2026年8月22日（日本時間）
結論：「Registryのversionを選んで入れ、1つずつ更新する」が現行の基本
責任範囲
- 現行のManager・Registry・ComfyUI本体の関係を、確認日付きで整理する
- 新UIでCustom Nodeを検索・導入・更新・削除する操作と、見るべき情報を示す
- 配布Workflowを読み込んでMissing Nodeを特定し、導入して再読み込みする手順を記録表付きで示す
- 更新前の確認項目と、壊れたときの切り戻しの入口を示す
- Import Failedの依存復旧とsnapshotの詳細手順は別記事に送る
UI名称はdocs.comfy.orgのManager節（new UI / legacy UI）とComfyUI-ManagerのREADMEを基準にしています。名称は更新で変わるため、画面と一致しない場合は公式ドキュメントで最新の名称を確認してください。
現在のManagerとRegistryはどういう関係か
ComfyUI Managerは長らく「custom_nodesに入れるcustom nodeの1つ」でしたが、2026年8月時点の公式ドキュメントでは次のように案内されています。
| 環境 | Managerの状態（2026年8月時点） |
|---|---|
| ComfyUI Desktop | 最初から同梱され、既定で有効 |
| Windows portable | ComfyUI coreに組み込まれているが、有効化が必要 |
| 手動install（git clone / venv） | 起動時に--enable-managerを付けて有効化、またはcustom_nodesにclone |
ComfyUI本体のnodes.pyにもargs.enable_managerの分岐があり、Managerが本体のnode読み込み段階に関与している点が以前との大きな違いです。
Comfy Registry（registry.comfy.org）は、公式ドキュメントで「ComfyUI-Managerを支えるcustom nodeの公開コレクション」と位置づけられています。開発者がnodeをsemantic versioningで公開し、一度公開したversionは変更できません。Registry側でnodeのコードを走査し、eval・execの使用、実行時のsubprocessによるpackage導入、コードの難読化などを禁止事項としています。検査を通ったnodeにはManager上で検証済みの印が付きます。
現在の標準は「Registryに登録されたversionをManager経由で入れる」ことです。GitHubのURLを直接指定するinstallやnightly（最新commit）の利用は、security_levelの設定によっては「This action is not allowed with this security level configuration」と拒否されます。security_levelはconfig.iniで、strong（高・中リスク機能を禁止）、normal（高リスクのみ禁止）、normal-（--listenでlocalhost以外に公開しているときだけ高リスクを禁止）、weak（すべて許可）の4段階です。
Custom Nodeを検索して導入する
新UIでは、上部メニューのManagerボタンからcustom nodeの管理画面を開きます。左sidebarのフィルタで「installed」「nodes in workflow」「missing」「updatable」などに絞り込め、検索は「Node Pack（pack全体）」と「Individual Node（pack内の個別node）」を切り替えられます。配布Workflowに書かれたnode名しか分からないときは、Individual Node検索でnode名から所属packを逆引きするのが早道です。
導入前に見る情報
node cardを選ぶと右の詳細panelにdescription、有効状態、version情報が表示され、Descriptionタブにはrepositoryへのリンクがあります。名前が合っているだけで入れるのではなく、次の4点を確認してからInstallを押します。
- 作者・publisherが、配布Workflowの作者が指定したものと一致するか（同名・類似名のpackが複数ある）
- Versionの選択肢に何があるか。Registryのversion番号が並ぶのが通常で、「nightly」だけの場合はRegistry未登録の可能性がある
- Nodesタブのプレビューに、自分が必要としているnodeが含まれているか
- repositoryの最終更新、open issue、READMEに書かれた追加依存（外部モデル・別packageなど）
特定のversionを入れたい場合は、node情報の「Version」で選んでからInstallします。導入後は再起動し、ブラウザを再読み込みしてから、起動logに該当packのimport失敗が出ていないか確認します。
Missing Nodeを特定する
Missing Nodeとは、読み込んだWorkflowが参照しているnode型が、現在のComfyUIに登録されていない状態です。Workflow JSONにはnode型の名前は入っていますが、nodeのコード本体は入っていません。JSONが何を持ち、何を持たないかはComfyUIのworkflow JSONの扱い方で整理しています。
配布Workflowを1つ読み込んで記録する
次の手順を、実際に使いたい配布Workflow 1つで行い、表に記録します。結果はWorkflowごとに異なるため、ここに数値は書きません。
- 現在のWorkflowを保存し、Managerが有効な状態でComfyUIを起動する
- 配布JSONを開く。Managerが正しく入っていれば、Missing Nodeがあるときに読み込み時のプロンプトが表示される
- プロンプトでは「Install All」ではなく「Open Manager」を選び、Missingフィルタで一覧を見る
- 各packについて、前節の4点（作者・version・含まれるnode・追加依存）を確認してから個別にInstallする
- 再起動後、同じJSONを読み込み直し、赤いnodeが残っていないか、起動logにimport失敗がないかを見る
| 不足していたnode名 | 所属pack / publisher | 選んだversion | 追加依存の有無 | 再読み込み後の状態 |
|---|---|---|---|---|
判断の目安は「再読み込み後に赤いnodeがゼロで、起動logに該当packの失敗表示がない」ことです。Missing表示は消えたのに生成で失敗する場合は、依存packageの読み込み失敗（別記事のImport Failed）か、nodeが参照するmodel fileの不足（Workflow JSON記事）のどちらかです。
「Install All」は便利ですが、同名packの取り違えや、不要なpackまで入れてしまう原因になります。初めて扱う配布Workflowでは、1つずつ確認して入れる方が、後で壊れたときの原因が絞れます。
更新前に確認する項目
ComfyUIの更新対象は、本体（Python側のcore）、Frontend（ブラウザ側UI）、Manager、各Custom Nodeの4層に分かれています。Custom Nodeは本体の内部APIに依存しているため、本体を上げた瞬間に一部のnodeが動かなくなることがあり、逆にnodeを上げると新しい本体を要求されることも珍しくありません。4層を一度に更新すると、壊れたときにどの層が原因か分からなくなります。
| 更新する層 | 更新前に確認すること | 更新後に確認すること |
|---|---|---|
| ComfyUI本体 | Settings > Aboutのversion記録、使用中packの対応version | 起動logの「Import times for custom nodes」に失敗がないか |
| Frontend | 現在のversion記録 | Managerボタン・設定画面が開くか |
| Manager | config.iniのsecurity_levelとchannel設定 |
Missingフィルタ・Installが動くか |
| Custom Node | Update availableフィルタで対象を絞り、versionの変更内容を見る | そのnodeを使うWorkflowが1つ動くか |
運用は「更新前にsnapshotを取る → 1層だけ更新 → 代表Workflowを1つ実行 → 次の層」の順を勧めます。Update availableフィルタでは更新があるnodeに矢印が付き、Versionを選んでからUpdateボタンで特定versionに上げられます。「Update All」は、すべてのnodeが最新版で問題ないと分かっているときだけの操作です。
壊れたときに切り戻す
切り戻しの入口は2つあります。1つはManagerのsnapshot機能で、導入済みcustom nodeとそのversion・commitの状態を保存し、Restoreで戻します（再起動後に反映）。保存先はManagerの設定directory配下のsnapshots/です。もう1つはComfyUI DesktopのSnapshotsタブで、こちらはComfyUI version、各custom nodeのversionまたはcommit hash、環境内のpip packageを記録し、起動・再起動・更新前後・復元後に自動で取られます。Desktopの復元では「Diff vs Current」で現在との差分を見てから実行できます。
どちらも「更新前に取っていれば戻れる」道具なので、前節の運用で更新の前に必ず保存しておきます。壊れた直後にまず見るべきは起動logで、「Import times for custom nodes」の一覧に「(IMPORT FAILED)」が付いたpackがあれば、そのpackのimport失敗が原因です。特定のversionに戻す・依存を入れ直すといった復旧の詳細と、snapshotからの復元手順は、それぞれ別記事で扱います。
本体を更新した後に「とりあえずUpdate Allで全部最新にすれば直る」は、壊れる層を増やす方向の操作です。まず切り戻して動く状態に戻し、それから1層ずつ上げ直してください。
安全なCustom Nodeの選び方
Custom Nodeは、ComfyUIと同じPython processで動く実行コードです。Registryの検査はeval・exec・実行時のpackage導入・難読化などを弾きますが、検査を通ったことと、あなたの用途で安全に動くことは別です。導入前に次の観点で見ます。
- Registry掲載と検証済みの印があるか。印がないpackは、リスクを理解したうえで扱う
- publisherと、repositoryのownerが一致しているか
- repositoryの更新履歴が続いているか。最終commitが古く、open issueにimport失敗の報告が積まれていないか
requirements.txtに、用途に不釣り合いな重い依存（別のML framework一式など）が無いか__init__.pyや主要な.pyに、起動時にネットワークへ接続する処理、外部ファイルを自動ダウンロードする処理、shellコマンドを実行する処理が無いか- 同じ機能が本体のbuilt-in nodeで済まないか
コードを全部読む必要はありません。requests・subprocess・os.systemなどをrepository内で検索し、出てきた箇所の用途が説明できるかを見るだけでも、怪しいpackは除外できます。説明できない処理があるpackは、秘密情報や本番データの無い環境以外で動かさないでください。
よくある質問
Managerボタンが表示されません
Desktopでは既定で有効ですが、portableや手動installでは有効化が必要です。起動オプションに--enable-managerを付けるか、公式ドキュメントのInstallation節の手順で導入し、再起動後にブラウザを再読み込みしてください。Frontendが古い場合も表示されないことがあります。
GitHubのURLを指定して入れようとすると拒否されます
security_levelがnormal以上だと、Registry外のURL指定installやnightlyの利用が高リスク機能として止められます。まずRegistryに同じpackが無いか検索し、どうしても必要な場合だけconfig.iniで一時的に下げ、導入後に戻します。
legacy UIと新UIはどちらを使うべきですか
公式ドキュメントは新UI（Pack Management）を主に案内しています。legacy UIにはInstall Missing Custom NodesやSnapshot Managerのメニューが残っており、現時点では両方の説明が公開されています。どちらでも操作の本質（Registryのversionを選ぶ・1つずつ更新する）は同じです。
まとめ
2026年8月時点のComfyUI Managerは本体に組み込まれ、Custom NodeはComfy Registryのversion単位で扱います。導入時は作者・version・含まれるnode・追加依存を確認し、Missing Nodeは「Install All」ではなく1つずつ入れて再読み込みで確かめます。
更新は本体・Frontend・Manager・Custom Nodeを1層ずつ、snapshotを取ってから進めてください。壊れたら起動logの「(IMPORT FAILED)」を見て対象を絞り、切り戻してから上げ直す。この順番を守るだけで、原因の分からない不調の大半を避けられます。