Comfy MCPをローカルで使う方法｜Codex・Claude CodeからWorkflowを実行する

Comfy MCPのローカル版はpip install comfy-mcpで導入し、Claude CodeやCodexにstdioサーバーとして登録すると、Agentが手元で動くComfyUIのworkflowをToolとして実行できます。2026年8月時点でpublic betaのため、最初は人が保存した固定workflowと安全な引数だけを許可し、tool名や引数の変更に追従できる形で使い始めます。

情報確認日：2026年8月22日（日本時間）

結論：固定workflowをAgentのToolにし、それ以外は渡さない

責任範囲

Comfy-Org公式のcomfy-mcp（ローカル版）を入れ、起動済みのComfyUIにつなぐ
Claude Codeはclaude mcp add、Codexはconfig.tomlのmcp_serversで登録する
最初のToolはvalidate_workflowとrun_workflowの2つに絞り、workflowは人が保存したものだけ使う
ファイル・パス・node導入・ComfyUIの起動停止はAgentに任せない
MCPの概念はMCPのTools・Resources・Promptsの違い、ComfyUIのHTTP APIはComfyUI APIの使い方に任せる

Comfy MCPで何ができるか

Comfy MCPは、Comfy-Orgが提供するModel Context Protocol準拠のサーバーで、AI AgentからComfyUIを操作するための接続口です。公式ドキュメントでは2系統が案内されています。Comfy Cloud側のGPUを使うCloud接続と、手元にインストールしたComfyUIを動かすローカル接続です。この記事はローカル接続だけを扱います。

HTTP APIを自分で叩く方法と何が違うのかを先に整理します。

観点	API手打ち（`POST /prompt`）	Comfy MCP経由（Agent Tool）
誰が呼ぶか	人が書いたスクリプト	Agentが会話の途中でToolとして呼ぶ
引数の組み立て	自分でJSONを作る	Agentがtool schemaに沿って引数を作る
結果の受け取り	`/history`と`/view`を自分で呼ぶ	`fetch_outputs`等のToolで回収する
向く場面	決まった処理の自動化・アプリ組み込み	「このworkflowを3パターン回して」のような対話的な作業
注意点	自分で書いた範囲しか動かない	Agentが使えるToolの範囲＝与えた権限になる

MCP経由の利点は「人が毎回JSONを組まなくてよい」ことですが、同じ理由で「Agentに何を許可するか」が設計の中心になります。この点は後半の権限境界で扱います。

ローカルComfyUIへ接続するには何が要るか

公式ドキュメントとリポジトリのREADMEで確認できた前提（2026年8月22日時点）は次のとおりです。

Python 3.10以上
comfy-cli 1.14.0以上がPATH上にあること（comfy-mcpの依存には含まれず、実行時に解決される）
ComfyUIのworkspaceが既にあるか、comfy installで用意してあること
ComfyUIが起動していること（公式はcomfy launchを案内）

# 導入
pip install comfy-mcp "comfy-cli>=1.14.0"

# ComfyUI が未導入なら
comfy install

# ComfyUI を起動（別ターミナルで起動したまま）
comfy launch

MCPサーバー本体はcomfy-mcpというコマンドで、クライアント（Claude CodeやCodex）が子プロセスとして起動し、標準入出力で通信します。自分でポートを開く必要はありません。

環境変数で場所を教える

MCPクライアントはシェルのPATHを引き継がないことがあります。comfyが仮想環境の中にあるなら、COMFY_BINで絶対パスを渡してください。ComfyUIが既定以外のアドレスで動いているときはCOMFY_LOCAL_URL、別マシンのComfyUIを指すときはCOMFYUI_URL（またはCOMFYUI_HOST/COMFYUI_PORT）を使います。

公式ドキュメントには、Apple GPUでは現在のopen-weight modelを実用的な速度で動かしにくいためCloud接続を勧める記述があります。Macで試す場合は、軽いworkflowから始めるか、この記事の範囲外であるCloud接続を検討してください。

MCP Clientへどう登録するか

クライアントごとに設定形式が違います。共通しているのは「comfy-mcpコマンドをstdioで起動する」「必要ならCOMFY_BINを環境変数で渡す」の2点です。

Claude Code

公式ページに掲載されている1行です。

claude mcp add comfy-mcp -e COMFY_BIN=/path/to/venv/bin/comfy -- comfy-mcp

Codex

Comfy MCPの公式ページに載っているCodexの例は、Cloud接続（url指定とAPI key）のみでした。ローカルのstdioサーバーとして登録する例は確認できなかったため、以下はCodex側の一般的なstdio登録形式にcomfy-mcpを当てはめた構成です。動作は手元で確認し、公式ページにローカル向けの案内が追加されていればそちらを優先してください。

# ~/.codex/config.toml
[mcp_servers.comfy-mcp]
command = "comfy-mcp"

[mcp_servers.comfy-mcp.env]
COMFY_BIN = "/path/to/venv/bin/comfy"

CLIから追加する場合は次の形です。

codex mcp add comfy-mcp --env COMFY_BIN=/path/to/venv/bin/comfy -- comfy-mcp
codex mcp list

Claude Desktop・Cursor

どちらもJSONのmcpServersに同じ内容を書きます。公式ページの例をそのまま使えます。

{
  "mcpServers": {
    "comfy-mcp": {
      "command": "comfy-mcp",
      "env": { "COMFY_BIN": "/path/to/venv/bin/comfy" }
    }
  }
}

登録後は、クライアントのMCP一覧にcomfy-mcpが表示され、Toolの一覧が読み込めることを確認します。ここで失敗する場合は、ComfyUIが起動しているか、COMFY_BINのパスが実在するかを先に見ます。

固定workflowをどう実行させるか

最初に使うToolは2つで十分です。validate_workflow(workflow_path)でworkflow JSONを事前確認し、run_workflow(workflow_path, wait=True)で実行します。結果はfetch_outputs(prompt_id, out_dir)で指定フォルダに回収します。どれもREADMEに記載のある引数ですが、beta中のため名前は変わりえる、という前提で扱ってください。

workflowは人がUIで作り、API形式で書き出して決まった場所に置いたものだけを使います。Agentに「workflowを考えて」とは頼みません。依頼文の例は次のようになります。

./workflows/portrait_v1.json を validate_workflow で確認してから、
run_workflow で wait=True のまま1回実行してください。
workflow の中身は変更しないでください。
終わったら fetch_outputs で ./outputs/run-01/ に保存し、
呼び出した tool 名と引数、返ってきた prompt_id を報告してください。

「workflowの中身は変更しない」と明示するのは、READMEにset_workflow_slotやvary_workflowのようにworkflowの値を書き換えるToolも含まれているためです。値を変えたい場合も、最初は人がlist_workflow_slotsで差し替え可能な箇所を確認し、「seedだけ」「promptだけ」のように範囲を指定してから任せます。

3回呼んで記録する

動作確認は、同じworkflowを3回呼び、Agentが実際に送ったTool引数と結果を表に残す形で行います。数値の良し悪しではなく「毎回同じ引数で呼べているか」「prompt_idごとに出力が回収できているか」を見ます。

回	呼ばれたTool（順に）	引数（workflow_path / wait など）	prompt_id	出力ファイル	想定外の挙動
1
2
3

「想定外の挙動」の列には、頼んでいないToolが呼ばれた、引数が勝手に変わった、ComfyUIが再起動された、といった事象を書きます。ここが3回とも空欄になって初めて、許可するToolや引数を少し広げます。

権限境界はどこに引くか

Comfy MCPのローカル版には、実行系だけでなくlaunch_comfyui・stop_comfyuiのようにComfyUIそのものを起動停止するTool、テンプレートをダウンロードするfetch_template、任意フォルダへ書き出すfetch_outputsのout_dirがあります。便利ですが、Agentに渡す範囲は自分で決める必要があります。

Agentに許可しないもの：任意パスへの読み書き、custom nodeやmodelの導入、ComfyUIの起動停止、workflow構造の変更、Cloud側のcreditを消費するpartner_generateなどの実行。confirm_spendはTool名ではなく、課金を伴う呼び出しで利用者の同意を確認する引数です。

境界の引き方は3層で考えます。

クライアント側の許可設定：Claude CodeやCodexには、Tool呼び出しごとに確認する設定や許可リストがあります。最初は「毎回確認」のまま運用します
依頼文での制限：使ってよいTool名と触ってよいファイルを依頼文に書きます。これは補助であって、技術的な制限ではありません
ファイルシステム側の制限：workflowと出力の置き場を専用フォルダにし、models・custom_nodes・設定ファイルの場所と分けておきます

MCPサーバーが公開するToolをクライアント側でどう絞るかは、使うクライアントのバージョンで方法が変わります。現行の設定項目はそれぞれの公式ドキュメントで確認してください。

Beta更新にどう追従するか

公式ページには、Comfy MCPがpublic betaであり、APIと挙動が変わる可能性があると明記されています。READMEでも「Beta」と「39 tools」という記載があり、Toolの数や引数は今後増減しえます。

追従のために、最初から次を記録しておきます。

記録する項目	確認コマンド・場所	変わったときに起きること
`comfy-mcp`のversion	`pip show comfy-mcp`	Tool名・引数名の変更
`comfy-cli`のversion	`comfy --version`	起動・接続手順の変更
ComfyUI本体のversion	ComfyUIの起動ログ	保存したworkflowが通らなくなる
使っているTool名と引数	3回呼びの記録表	依頼文の書き直しが必要になる
公式ページの確認日	docs.comfy.org/agent-tools/mcp	新しい前提や注意事項の追加

更新したら、まずvalidate_workflowだけを呼ばせ、次にrun_workflowを1回だけ、と段階を戻してから通常運用に戻します。この記事の記載も同じ前提で、名称が変わっている場合は公式ドキュメントの最新表記を優先してください。

よくある質問

ComfyUIを起動していなくてもComfy MCPは動きますか？

ローカル接続はComfyUIが起動済みであることが前提です。launch_comfyuiというToolはありますが、この記事では起動停止をAgentに任せない方針のため、人が先に起動しておきます。

CloudとローカルでToolは同じですか？

共通のToolと、ローカル固有のTool（server_info、run_workflow、fetch_outputsなど）があります。認証もそれぞれ別です。Cloud接続の詳細は別記事で扱います。

自作のMCPサーバーでComfyUIのAPIを包む方が安全ですか？

公開するToolを自分で決められるため、権限を最小にしやすい利点があります。代わりに、Comfy MCPが持つテンプレート検索やslot操作は自分で実装しなければなりません。固定workflowを数個回すだけなら、Comfy MCPをクライアント側の許可設定で絞る運用でも十分に始められます。

まとめ

Comfy MCPのローカル版は、pip install comfy-mcpで入れて、Claude Codeならclaude mcp add、Codexならconfig.tomlのmcp_serversで登録すれば、Agentから手元のComfyUIを呼べるようになります。

最初に許可するのはvalidate_workflowとrun_workflow、対象は人が保存した固定workflowだけです。3回呼んで引数と結果を記録し、想定外がなくなってから範囲を広げます。public betaのため、versionと使っているTool名を記録し、更新のたびに段階を戻して確認してください。