ComfyUI カスタムノード入門2026｜ComfyUI Managerでの導入・依存解決・安全な選び方

ComfyUI カスタムノードは、ComfyUIの表現力を“標準の外”へ広げるための拡張ノードだ。 ComfyUIをしばらく使うと、必ずこの壁に当たる——「ControlNetで構図を制御したい」「IPAdapterで画風を移したい」「生成した画像を動画にしたい」。ところが標準ノードだけでは、これらは組めない。答えがカスタムノードだ。ComfyUIの custom_nodes ディレクトリに拡張を置くと、新しい処理ノードがUIに現れ、標準ノードと同じように配線できるようになる。有志が公開したカスタムノードは6万を超える規模で存在し、これがComfyUIの拡張性と、他の画像生成UIにない表現力の源泉になっている。

だが、この自由には裏側がある。カスタムノードはComfyUIの環境内で任意のPythonコードを実行できる——つまり、素性の分からないノードを入れると悪意あるコードが動くリスクがある。この記事では、ComfyUI カスタムノードの仕組みから、ComfyUI Managerでの導入、手動やcomfy-cliでの入れ方、依存衝突のトラブルシュート、そして「任意コード実行」というリスクを踏まえた安全な選び方までを、公式情報で裏取りしながら解説する。拡張の力を、リスクを管理しながら使いこなすのがゴールだ。

ComfyUIそのものの全体像（基本ノード・ワークフロー・対応モデル）は ComfyUI入門2026｜ノードベースで画像生成ワークフローを組む完全ガイド をご覧ください。本記事はそのComfyUIを「カスタムノードで拡張する」実践編です。

まず、カスタムノードを入れる3つの経路と、その後の流れを1枚で掴んでおこう。どの経路でも最後は custom_nodes に置かれ、再起動で有効になる、という構造は共通だ。

ComfyUI カスタムノードとは——ComfyUIを拡張する仕組み

ComfyUI カスタムノードが解くのは、「標準ノードだけでは組めない処理を、後から足したい」という拡張の問題だ。ComfyUIは、モデル読み込み・プロンプトのエンコード・サンプリング・画像変換といった生成の各工程をノードとして配線するが、公式が同梱するのは基本的なノード群だけ。ControlNet（構図・ポーズ制御）、IPAdapter（画風の転写）、AnimateDiff（動画化）、各種アップスケーラ、便利なユーティリティ——こうした“一歩進んだ処理”は、カスタムノードとして追加する前提になっている。

仕組みはシンプルだ。カスタムノードは、ComfyUIインストール先の custom_nodes ディレクトリに置かれるPythonパッケージで、起動時にComfyUIが読み込んで、そのノードをUIのノード一覧に追加する。だから導入の実体は「custom_nodes に正しくファイルを配置し、依存ライブラリを入れ、ComfyUIを再起動する」ことに集約される。GUIのManagerを使っても、手動でgit cloneしても、最後にやっていることは同じだ。この構造を理解しておくと、次の導入方法もトラブルシュートも一気に腑に落ちる。

具体的に、カスタムノードで何が“足せる”のかをイメージしておこう。制御系なら、ControlNetで線画やポーズ・深度から構図を指定したり、IPAdapterで参照画像の画風を転写したりできる。生成拡張系なら、AnimateDiffやWan系ノードで静止画のパイプラインを動画生成へ広げられる。品質系なら、各種アップスケーラやディテール補正、顔の修復ノードが使える。効率系なら、Impact Packのように複数処理をまとめる高機能ノード群や、ワークフローを整理するユーティリティがある。標準ノードが「生成の骨格」だとすれば、カスタムノードは「肉付けと専門化」を担う——この役割分担が分かると、自分のワークフローに“何が足りないか”を言語化できるようになる。

ComfyUI Managerを入れる——カスタムノード管理の起点

カスタムノードを扱うなら、まず入れるべきはComfyUI Manager（ltdrdata作）だ。これはカスタムノードを検索・インストール・更新・無効化・削除できる管理ツールで、事実上のカスタムノード運用の起点になっている。Comfy Desktop版には同梱されていることも多いが、手動環境なら自分で入れる。方法は主に3つだ。

# 方法1: git clone（標準）— ComfyUI/custom_nodes で実行して再起動
cd ComfyUI/custom_nodes
git clone https://github.com/ltdrdata/ComfyUI-Manager comfyui-manager

# 方法2: comfy-cli（推奨・仮想環境を作ってから）
pip install comfy-cli
comfy install        # ComfyUI本体＋Managerをまとめてセットアップ

Managerを入れて再起動すると、UIに「Manager」ボタンが現れる。ここからカスタムノードを名前で検索し、「Install」を押すだけで導入できる。特に強力なのが 「Install Missing Custom Nodes（不足ノードの一括導入）」 で、他人のワークフローを読み込んだときに足りないノードを検出し、まとめてインストールしてくれる。共有されたワークフローを再現する際の定番手順だ。さらに、更新・無効化・削除、モデルのダウンロード管理、そしてスナップショット（今の構成を保存して後で戻す）まで揃う。カスタムノードの入り口としても、日々の管理の中心としても、Managerは外せない。ワークフローの共有・再現の詳しい仕組みは ComfyUI ワークフロー共有・再現ガイド2026｜JSONとPNGメタデータで完全再現する で扱う。

カスタムノードの導入3経路と、依存衝突のトラブルシュート

導入経路は「Manager」「手動git clone」「comfy-cli」の3つだが、実務では次のように使い分ける。

なお、ComfyUI Managerが参照するノードの一覧は、Comfy-Orgが運営するレジストリ（Comfy Registry）や登録チャンネルに基づく。comfy-cliの comfy node install <名前> は、このレジストリからノードを名前で取得してインストールする仕組みで、CI/CDやセットアップスクリプトに組み込めば「同じ環境をコマンド一発で再現する」ことができる。チームで環境を揃えたい、サーバに自動デプロイしたい、という場面ではManagerのGUIよりcomfy-cliの方が再現性を担保しやすい。用途に応じて、探索・試行はManagerのGUIで、確定した構成の再現はcomfy-cliで、と使い分けるとよい。

手動導入は、Managerに登録されていないノードや、特定のブランチ・フォークを使いたいときの手段だ。custom_nodes にクローンし、そのノードの依存を入れて再起動する。

# 手動導入: clone → 依存インストール → 再起動
git clone <repoのURL> ComfyUI/custom_nodes/<node-name>
pip install -r ComfyUI/custom_nodes/<node-name>/requirements.txt
# ComfyUI を再起動すると新しいノードが一覧に出る

依存衝突と並んで多いのが、ComfyUI本体とノードのバージョン不整合だ。ComfyUIは活発に更新され（たとえば2026年6月末にはv0.27.0が公開されている）、本体の内部APIが変わると、追従できていない古いカスタムノードが読み込みに失敗することがある。逆に、最新ノードが要求する本体機能に、古いComfyUIが対応していないケースもある。原則は「本体とよく使うノードを、まとめて・こまめに更新する」こと。ただし更新は壊れる可能性も伴うので、Managerのスナップショットで直前の動く構成を保存してから実行するのが安全だ。「昨日まで動いていたのに」の多くは、本体かノードのどちらかだけを更新したときに起きる。

そして、カスタムノードで最も詰まりやすいのが依存衝突だ。カスタムノードはそれぞれ独自のライブラリ（requirements.txt）を要求し、あるノードが求めるバージョンと別ノードのそれが食い違うと、片方または両方が読み込みに失敗する。対処の定石は、①起動ログでどのノードがどのライブラリで落ちているかを特定する、②Managerの更新や「Install Missing」で依存を揃える、③疑わしいノードを一時無効化して切り分ける、④用途ごとにvenvを分ける、の4つだ。動いている構成はManagerのスナップショットで保存しておけば、壊れても戻せる。「入れた瞬間に全部動かなくなった」は、たいてい直前に入れたノードの依存が原因——まずそれを疑うのが近道だ。

カスタムノードの安全な選び方——任意コード実行というリスク

ここが本記事で最も重要なセクションだ。ComfyUI カスタムノードは、ComfyUIの実行環境で任意のPythonコードを実行できる。便利さの裏返しで、これはソフトウェアのサプライチェーンリスクそのものだ。素性の分からないノードを入れることは、正体不明のプログラムに自分のマシンの実行権限を渡すのに等しい。ComfyUI-Manager公式も「カスタムノードの正常動作は保証しない」と明記している。

守りの第一歩は、ComfyUI Managerのセキュリティレベル（config.ini で設定）を理解することだ。

高リスク操作には、登録チャンネル外からの非safetensorsモデルのダウンロードなどが含まれる。加えて、Git URLからの直接インストール（allow_git_url_install）やpipインストール（allow_pip_install）は独立した設定で、明示的な許可とループバック限定のアクセスが必要になっている。つまりManagerは「危ないことは既定で止める」設計だ。この既定を安易に緩めないことが第一の防御になる。

導入するかどうか迷ったら、次の判断フローに当てはめてみてほしい。素性・実績・隔離の3点で振り分けるだけで、リスクは大きく下げられる。

そのうえで、選定の原則はサプライチェーン衛生と同じだ。① 開発元が明確で、広く使われ、更新が続いているノードに絞る。② スター数・issue・最終更新を確認し、放置ノードや無名ノードは避ける。③ どうしても必要な素性不明ノードは、隔離環境（使い捨てのvenvやコンテナ）で試す。④ モデルは信頼できる配布元の safetensors を優先する（任意コードを含みうる古い形式を避ける）。この考え方の土台は サプライチェーンセキュリティ完全ガイド2026 と共通で、カスタムノードもまた「他人のコードを自分の環境で動かす」以上、同じ警戒が要る。

定番カスタムノードと、入れすぎない運用

最後に、実際の運用指針を示す。まず、広く使われる定番カテゴリを押さえておくと、無名ノードに手を出す前に「まず定番で足りないか」を確認できる。構図・ポーズ制御のControlNet系、画風転写のIPAdapter系、動画化のAnimateDiff系、ワークフローを効率化するユーティリティ系（Impact Pack等）、そしてすべての起点となるComfyUI Manager——このあたりは採用が広く、情報も多い。まずは定番で組み、どうしても足りない処理だけ個別ノードを足す、という順序が安全だ。

そして繰り返したいのが、入れすぎないこと。カスタムノードは増えるほど、起動が遅くなり、依存衝突が起きやすくなり、全体の把握が難しくなり、攻撃面（セキュリティ上の隙）が広がる。「便利そうだから」で片っ端から入れると、いずれ動かなくなって原因も追えなくなる。実際に使うワークフローに必要なノードだけを入れ、使わなくなったものはManagerで無効化・削除し、動く最小構成を保つ。定期的に棚卸しして、スナップショットで安全地点を残しておく。これが、6万超のエコシステムと長く付き合うための現実的な作法だ。ComfyUIをワークフロー基盤として他ツールと比較したい場合は AI自動化ツール完全ガイド2026 も参照してほしい。

最初の一歩に迷うなら、順序はこうだ。まずComfyUI Managerを入れ、セキュリティレベルを既定（strong寄り）のまま確認する。次に、作りたいワークフローに必要な定番ノード（ControlNetやアップスケーラなど）を1〜2個だけManager経由で入れて動かす。そこで挙動と依存の感覚を掴んでから、必要に応じて範囲を広げていく。いきなり大量に入れるのではなく、「1つ入れて、動かして、理解する」を繰り返すのが、遠回りに見えて最も早い。

拡張の力は大きいが、その力は「任意コードを自分の環境で動かす」ことの上に成り立っている。Managerで賢く入れ、依存を管理し、素性を確かめ、最小構成を保つ——この4つを守れば、ComfyUI カスタムノードは怖い存在ではなく、頼れる相棒になる。

参照ソース

・comfyanonymous/ComfyUI — GitHub 公式リポジトリ（GPL-3.0）
・ComfyUI-Manager（ltdrdata） — カスタムノード管理
・comfy-cli — ComfyUIのCLIツール（Comfy-Org）
・ComfyUI 公式ドキュメント（docs.comfy.org）