開発実践ガイド
Comfy MCPとは?ローカルComfyUIをAIエージェントから操作する仕組み・導入・注意点

目次
ComfyUIで画像や動画を生成するとき、これまでは人間がワークフローを開き、モデルやノードを確認し、必要ならComfyUIを起動して、実行結果を回収するのが基本だった。
Comfy MCPは、この操作レイヤーをAIエージェントから扱えるようにする公式のMCP サーバーだ。
Comfy Orgは2026年8月18日、ローカル版Comfy MCPをオープンソースとして公開した。Claude Code、Claude Desktop、CursorなどMCPに対応するエージェントから、自分のPCにあるComfyUIを操作できる。
ただし、ここで「ローカルComfyUIを操作する=すべてが完全オフライン」と考えるのは正しくない。
公式リポジトリ自身がComfy MCPをローカル優先, not 完全ローカルと説明しており、提携先モデルや別マシンのComfyUIへ接続する経路もある。
Comfy MCPをローカル画像生成環境へ入れる価値があるかを、できること、導入方法、ローカル/クラウドの境界、安全性の順で整理する。
ComfyUIを日常的に使う人ほど有力。ただし最初から全操作をエージェントへ渡さない
Comfy MCPが特に向いているのは、次のような人だ。
- 同じワークフローを条件違いで何度も回している
- 手元のモデルやカスタムノードが増え、どのワークフローが動くか確認する作業が増えた
- ClaudeやCursorなどのエージェントから画像・動画生成まで連携したい
- ワークフロー JSONを自動で検証・編集・実行したい
- 夜間バッチなど、人が画面を見続けなくてもよい処理を自動化したい
一方、ComfyUIをたまに開いて1枚生成する程度なら、MCPを追加するメリットは小さい。
Comfy MCPの価値は「画像生成そのものを速くする」ことではなく、生成前後の操作と判断をエージェントへ渡せることにある。
Comfy MCPで何ができるのか
公式リポジトリでは、ローカル版Comfy MCPから次の操作が案内されている。
| 機能 | できること |
|---|---|
| 生成 | ワークフロー JSONを実行し、画像などを生成する |
| Job 制御 | 非同期jobの送信、待機、監視、キャンセル、失敗判定、出力回収 |
| Introspection | 実際のComfyUIに入っているノード、モデル、テンプレートを検索する |
| ワークフロービルド | グラフ検証、テンプレートの編集、構成生成 |
| ComfyUI 管理 | サーバーの起動・停止・再起動、log確認、入力素材配置 |
重要なのは、静的なモデル一覧をエージェントへ渡すだけではない点だ。
Comfy MCPは、そのPCで現在読み込めるノードやモデルを実際のインストールから確認する。カスタムノードも対象になる。
たとえば「このPCでWan系ワークフローを動かせるか確認して、必要なテンプレートを使って短い動画を生成して」といった指示を、1つのエージェント会話にまとめやすくなる。
仕組み:Comfy MCP自体が推論するわけではない
構成を単純化すると、次のようになる。
Claude / Cursor / MCP client
↓ MCP
comfy-mcp
↓
comfy-cli
↓
Local ComfyUI (127.0.0.1:8188)
↓
GPU / models / custom nodes / workflows
comfy-mcpはLLM 実行環境ではない。
公式リポジトリによれば、各ツールはcomfy コマンドを--where local --json付きで呼び出し、comfy-cliの結果をMCP側へ返す構成になっている。
つまり、推論・ワークフロー実行の本体はComfyUIであり、Comfy MCPはエージェントとComfyUIをつなぐ操作層と考えると分かりやすい。
最初の導入手順
公式Quickstartでは、まずcomfy-mcpとcomfy-cliを用意する。
pip install comfy-mcp "comfy-cli>=1.14.0"
comfy install
すでにComfyUI ワークスペースがある場合は、comfy installが不要なケースもある。
次にComfyUIを起動する。
comfy launch
そのうえで、Claude Code、Claude Desktop、CursorなどのMCP クライアントからcomfy-mcp コマンドをサーバーとして登録する。
最初の確認では、新しい複雑なワークフローをエージェントに作らせるより、すでに手動で動作確認済みのワークフロー JSONを1本だけ実行する方がよい。
たとえば次の順番で確認する。
- ComfyUIが起動しているかエージェントに確認させる
- 既存ワークフローを指定する
- 1回だけ実行する
- 出力の保存先を確認する
- ComfyUI側のlogを確認する
- 不要なネットワークアクセスが発生していないか確認する
これで、MCP接続・ComfyUI・モデル・ノード・出力までの最低限の経路を一度に検証できる。
「ローカル版」でも完全オフラインとは限らない
ここは最も誤解しやすい。
Comfy MCPの標準的なローカル実行では、自分のマシン上のComfyUIがワークフローを実行する。
しかし公式リポジトリは、ローカル版にも外部へ出る経路があると明記している。
代表例は次の通りだ。
- ホスト型提携先モデルを実行する
partner_generate - ローカルワークフローから提携先 API ノードを使う経路
COMFYUI_URLで自分が管理する別マシンのComfyUIへ接続する構成
したがって、
Comfy MCP = ローカル実行を扱える
は正しいが、
Comfy MCP = すべての処理・通信が必ずPC内だけで完結する
は正しくない。
完全オフラインを重視する場合は、ワークフロー内のノード、モデルダウンロード、提携先 API、エージェントクライアント自体の通信まで分けて確認する必要がある。
Comfy Cloud MCPとは別物
Comfy Orgはローカル MCPとComfy Cloud MCPの両方を提供している。
| 項目 | Local Comfy MCP | Comfy Cloud MCP |
|---|---|---|
| MCP サーバー | 自分のPCで標準入出力サーバーを起動 | リモート HTTP サーバー |
| ワークフロー実行 | 主に自分のComfyUI/GPU | Comfy Cloud GPU |
| ローカル ComfyUI | 基本的に使用 | 不要 |
| ローカルモデル/カスタムノードの確認 | 可能 | ローカルインストールは対象外 |
| ネットワーク | 構成次第で外部経路あり | クラウド接続前提 |
ローカルGPUを活用したい人が選ぶ中心はLocal Comfy MCPだ。
ただし両者は排他的ではなく、公式は同時利用も想定している。
GPUの必要VRAMが減る機能ではない
Comfy MCPを導入しても、モデル自体のメモリ要件は基本的に変わらない。
エージェントが「このGPUならこのモデルが向いている」と判断できるようになることと、物理的にVRAMが増えることは別だ。
重いワークフローでは、従来どおり次の要素が効く。
- モデルサイズ
- 精度 / 量子化
- 解像度
- フレーム数・長さ
- VAE
- オフロード
- システムRAM
- ComfyUIのメモリ管理
VRAM不足が出る場合は、ComfyUIのCUDA out of memory対処を先に切り分けたい。
また、エージェントの判断を信用する前に、ローカルAIのVRAM使用量・ピークを測る方法で自分の実測値を残しておくと判断精度を上げやすい。
カスタムノードの自動導入は便利だが、権限を意識する
Comfy Orgは、エージェントが必要なカスタムノードを見つけてインストールする使い方も紹介している。
便利だが、ここは「画像生成の設定変更」より権限が大きい。
カスタムノードはPython コードを含むため、未知のノードパックを自動でインストールする操作は、単にモデルを切り替える操作とはリスクが違う。
最初から、
- カスタムノードを自由にインストール
- 任意ファイルを読み書き
- 任意コマンドを実行
- 提携先 APIを利用
まで一括で任せる必要はない。
まず既存インストールの読み取りと既存ワークフロー実行だけを許し、必要になった段階で操作範囲を広げる方が安全だ。
Betaであることも忘れない
公式リポジトリは2026年9月2日確認時点でComfy MCPをベータ版と記載している。
また、40 ツールと、ローカル ComfyUIに対するserver_info → run_workflow → fetch_outputsの中核ループを一連の処理全体で検証したと説明している。
これは実用段階に入っていることを示す一方、固定された完成仕様という意味ではない。
導入手順、ツール名、comfy-cli要件、認証、ローカル/クラウドの境界は今後変わる可能性がある。
そのため、エージェント自動化へ組み込む場合はバージョンを記録し、更新後に既存ワークフローが同じように動くか確認したい。
どんな人なら導入価値が高いか
判断をまとめると次のようになる。
| 使い方 | 導入価値 |
|---|---|
| たまに手動で1枚生成 | 低い |
| 同じワークフローを多数の条件で回す | 高い |
| ローカル動画生成をバッチ化したい | 高い |
| モデル/カスタムノードが多く管理が大変 | 高い |
| Claude/Cursorから生成工程を呼びたい | 高い |
| 完全オフラインだけが絶対条件 | 条件確認が必要 |
| 未知のカスタムノードまで完全自動導入したい | リスク管理が必要 |
Comfy MCPは、ComfyUIを「人間がノードグラフを触るGUI」から置き換えるものではない。
むしろ、手動で作ったワークフローやローカル環境をエージェントから再利用できるようにするところに価値がある。
最初に試すなら、小さな既存ワークフローから
導入初日に複雑な動画ワークフローの完全自動化まで進める必要はない。
おすすめは、手動で正常動作が分かっているテキストから画像への生成ワークフローを1本用意し、エージェントに次だけ任せる方法だ。
1. local ComfyUIの状態確認
2. workflowの検証
3. 1回だけ実行
4. job完了待ち
5. outputを指定folderへ回収
ここまで問題なく動けば、次にパラメータ条件違い、バッチ、動画ワークフローへ広げられる。
Wan系動画生成を試す場合も、まずはComfyUIでWan 2.2の画像から動画を始める方法のような短い基準ワークフローを手動で成立させてからエージェントへ渡す方が切り分けやすい。
まとめ
- Comfy MCPはClaude Code、Claude Desktop、CursorなどのMCP クライアントから、自分のマシン上のComfyUIを操作するための公式オープンソース MCP サーバー
- ワークフロー実行だけでなく、稼働中インストール上のノード・モデル・テンプレート検索、ComfyUIの起動・停止・再起動、job監視、出力回収まで扱える
- ローカル優先だが完全ローカルではなく、提携先モデルやリモート ComfyUIへの経路もあるため「Comfy MCPを使えば常に完全オフライン」とは言えない
- ベータ版段階なので、最初は既存ワークフローを限定権限・限定出力先で実行し、エージェントへ任せる範囲を徐々に広げるのが安全