Claude Codeに頼むだけで、ComfyUIのワークフローはどこまで作れる？

この記事では、Windows環境のClaude Codeで実際に試した結果をもとにまとめています。

ComfyUIのノード、繋ぎ方合ってる自信ありますか？私は何度も画面の前で「これ、どこに繋げばいいんだ」と止まっていました。「Claude Codeに日本語で頼むだけでワークフローJSONを作らせたらどうなる？」——試してみました。この記事は、実際に頼んでみてどこまでできたか、そしてどこから人が確認したかを正直に報告します。

この記事で確かめること

この記事は、「Claude Codeに日本語で頼むだけでComfyUIのワークフローをどこまで作れるか」を検証した記録です。

検証範囲は4つ。シンプルなtxt2img（テキストから画像を生成する基本ワークフロー）、ControlNetやLoRAを組み込んだ高度な構成、カスタムノードの導入、そしてエラーが出た時の修正です。

読み終わる頃には、「自分でも試せそう」という手応えと、「ここから先は自分で確認しよう」という境界線が見えているはずです。

前提となる環境と準備

検証はすべてWindows 10/11環境で行っています。

前提として、ComfyUIがインストール済みで起動できる状態が必要です。ComfyUIのインストール自体はこの記事の対象外なので、「ComfyUI はじめ方」で検索して先に済ませておいてください。

Claude Codeも使える状態にしておきます。コマンドプロンプトかPowerShellでclaudeと打って応答が返ってくれば準備完了です。

モデルはSDXL（stabilityai/stable-diffusion-xl-base-1.0）を前提に進めます。SD1.5でも基本的な流れは同じですが、ノードの構成が少し変わります。

やりたいこと：テキストだけで画像生成ワークフローを作る

ComfyUIを使い始めて最初につまずくのが、ノードの繋ぎ方です。CheckpointLoader、CLIPTextEncode、KSampler、VAEDecode、SaveImage——必要なノードは分かっても、「この出力をあっちの入力に繋ぐ」という作業が慣れるまで大変です。

しかもワークフローを保存すると中身はJSONファイルです。ComfyUIの「Save」ボタンを押して出力されたファイルをテキストエディタで開くと、ノードのIDや接続関係がずらっと並んでいて、手で編集する気にはなれません。

ここで発想を変えます。そのJSONを、Claude Codeに日本語で説明して書かせたらどうなるでしょうか。

「ComfyUIでSDXLを使ったtxt2imgのワークフローJSONを作って」と頼むだけで、ComfyUIにインポートして動くJSONが返ってきたら、GUIでポチポチ繋ぐより楽かもしれません。

missing nodesエラーに悩まされたり、カスタムノードの管理に疲れたりしている人は、このアプローチに期待してしまうのではないでしょうか。

Step 1：最初の依頼 — シンプルなtxt2imgワークフローを作らせてみる

最初の依頼文は、なるべくシンプルにしました。

ComfyUIでSDXLモデルを使った基本的なtxt2imgワークフローのJSONを作ってください。
構成は以下の通りです：
- CheckpointLoaderSimpleでモデルを読み込む
- CLIPTextEncodeでポジティブプロンプトとネガティブプロンプトを設定
- KSamplerでサンプリング
- VAEDecodeでデコード
- SaveImageで保存
steps 20, cfg 7, sampler_name euler, scheduler normal
画像サイズは1024x1024

ポイントは2つ。必要なノードを名前で指定したことと、パラメータ（steps、cfg、samplerなど）を明示したことです。あえて指定しなかったのは、ノード間の接続関係です。Claude CodeがComfyUIのノード接続ルールをどの程度理解しているかを見たかったからです。

依頼文にモデルのフルパスは書いていません。これは意図的で、モデルパスは環境ごとに違うため、後から自分で直す前提にしています。

Step 2：最初の結果 — どこまでできたか

Claude Codeが返してきたJSONをComfyUIにインポート（Loadボタン）してみました。

まず良かった点。ノードの基本構成は正しく揃っていました。CheckpointLoaderSimple、CLIPTextEncode（2つ）、KSampler、VAEDecode、SaveImageがすべて存在し、それぞれに正しいclass_typeが設定されていました。ノードのIDも一意に振られていて、JSONの文法エラーはありません。

ただし、そのままでは動きませんでした。

問題は接続（links）の一部にありました。KSamplerからVAEDecodeへのLATENT出力の接続で、入力タイプの番号がずれていました。ComfyUIのノード接続は、出力インデックスと入力インデックスの組み合わせで成り立つのですが、このインデックスの対応関係をClaude Codeが完璧には把握していませんでした。

もう一つ、CheckpointLoaderSimpleのckpt_nameに存在しないファイル名が入っていました。これは想定通りで、環境ごとにモデルファイル名が違うため、ここは自分で修正する前提でした。

人が確認したポイント：
– JSONの文法 — 問題なし（そのままパースできた）
– ノードの種類と数 — 問題なし（必要なノードがすべて揃っていた）
– ノード間の接続 — 一部不正（KSampler→VAEDecodeの接続インデックス）
– モデルファイル名 — 環境依存（自分で修正想定）

一発で完璧ではありませんでしたが、ほぼ動くものが一回で出てきたという印象です。

Step 3：修正指示 — 足りない部分を直させる

Step 2で見つかった問題をClaude Codeに修正してもらいます。

先ほどのJSONで、KSamplerからVAEDecodeへの接続が間違っています。
KSamplerの出力0（LATENT）をVAEDecodeの入力0（samples）に繋いでください。
また、CheckpointLoaderSimpleのckpt_nameを
'sd_xl_base_1.0.safetensors' に変更してください。

修正内容は2点。接続インデックスの修正と、モデルファイル名の変更です。

接続の修正では、どこが間違っているかを具体的に伝えました。「KSamplerの出力0をVAEDecodeの入力0に」と指示すれば、Claude Codeは迷わず直してくれます。ComfyUIのノード接続ルールを完全に把握していなくても、「この出力をあの入力に繋いで」と日本語で指定すれば直る——ここが重要なポイントです。

モデルファイル名の変更は、自分の環境に合わせたものをそのまま渡しました。

Step 4：修正後の結果と次の壁

修正後のJSONを再度ComfyUIにインポートしました。

今度は接続エラーが出ませんでした。ComfyUI上でノードが正しく繋がって表示され、Queue Promptを押すと画像生成が始まりました。1024×1024の画像が無事に出力されています。

ここまででやり取りは2回（最初の依頼＋1回の修正指示）です。

ただし、生成された画像の品質にはこだわっていません。steps 20、cfg 7、euler/nomalというデフォルト寄りのパラメータで出したので、品質としては「そこそこ」です。プロンプトの内容も適当だったので、本格的な画像生成をするならパラメータとプロンプトを自分で調整する必要があります。

ここまでのまとめ：
– 基本的なtxt2imgワークフローは、2回のやり取りで動くものが完成した
– ノードの種類と数は1回目で正解
– 接続の細かいインデックスは人間の指摘が必要だった
– パラメータとプロンプトは自分で調整する前提

Step 5：高度なワークフローに挑戦 — ControlNetとLoRAはどこまで頼める？

基本のtxt2imgが動いたので、次はControlNetとLoRAを組み込んだワークフローに挑戦します。

ControlNetワークフロー

先ほどのtxt2imgワークフローにControlNetを追加してください。
- ControlNetLoaderでControlNetモデルを読み込む（canny）
- ControlNetApplyでControlNetを適用
- 画像入力用にLoadImageノードを追加
ControlNetモデル名は 'control_v11p_sd15_canny.pth' にしてください。

ノードの追加自体は正しくできました。ControlNetLoader、ControlNetApply、LoadImageが追加され、大まかな接続も合っています。ただし、SDXLのワークフローにSD1.5用のControlNetモデルを指定してしまったことに後から気づきました。これは依頼文の書き方がまずく、私の責任です。

依頼文を書き直してSDXL用のControlNet（sd3.5など対応状況に依存）を指定し直したところ、構造的には正しいJSONが返ってきました。ただし、ControlNetApplyの入力インデックスの一部がやはりずれており、手動での確認が必要でした。

LoRAワークフロー

基本のtxt2imgワークフローにLoRA Loaderノードを追加してください。
LoRAモデル名は 'sdxl_lora_sample.safetensors' にして、
strength_clipとstrength_modelは両方0.8にしてください。
LoRA Loaderの位置はCheckpointLoaderSimpleの直後にしてください。

LoRAは比較的シンプルな追加だったせいか、ほぼ一発で動きました。CheckpointLoaderSimpleの出力（MODELとCLIP）をLoRA Loader経由で後続ノードに繋ぐ構造が正しく生成されています。

カスタムノード（IP-Adapterなど）

IP-Adapterのようなサードパーティ製カスタムノードになると、Claude Codeの知識が怪しくなります。実際に試してみると、ノードのclass_typeは合っているものの、入力パラメータの仕様が現在のバージョンと合わないケースがありました。

高度なワークフローの到達点を整理すると：
– ControlNet：構造は作れるが、バージョン対応と接続インデックスに注意が必要
– LoRA：比較的高成功率
– カスタムノード：class_typeは合うことが多いが、パラメータ仕様の正確さは保証できない
– すべてにおいて、ComfyUIでの読み込み後の目視確認は必須

エラーが出たとき — Claude Codeは自律的に直せるか

ComfyUIで実際によく出るエラーをClaude Codeに投げてみます。

missing nodesエラー

ワークフローを読み込んだ時、「Missing node types: XXXX」というエラーが出ることがあります。このエラーメッセージをそのままClaude Codeに貼り付けました。

ComfyUIで以下のエラーが出ました：
Missing node types: 'ControlNetLoaderSDXL'
このノードが存在しないようです。代替のノードまたは修正方法を教えてください。

Claude Codeはノード名が存在しないことを理解し、代わりに標準のControlNetLoaderを使う修正案を返してきました。エラーメッセージをそのまま貼り付けるだけで、原因の特定と代替案の提示までしてくれます。

モデル不整合エラー

SDXLモデルを読み込んだワークフローにSD1.5用のノードを繋いでしまうと、「Input type mismatch」等のエラーが出ます。このエラーもそのまま貼り付けました。

Claude Codeは「SDXLモデルとSD1.5用ノードの組み合わせが原因」と正しく特定しました。ただし、どのバージョンに対応したノードを使うべきかまでは案内してくれず、自分で調べる必要がありました。

パラメータミス

stepsに0を指定してしまったケースなど、明らかな値のエラーについては、ComfyUI側で弾かれる前にClaude Codeが気づくことがありました。「stepsは1以上の整数にしてください」と提案してきます。ただし、常に気づくわけではなく、無効な値をそのまま出力することもあります。

エラー修正におけるClaude Codeの対応力をまとめると：
– エラーメッセージを貼るだけで原因特定はできることが多い
– 代替案の提示も可能
– ただし「どのバージョンの何を使うべきか」という環境依存の判断は人間の仕事
– パラメータの妥当性チェックは万能ではない

どこまで頼むだけでできたか — 到達点・境界線・完成品

検証を通じて分かった「頼むだけでできたこと」と「できなかったこと」を整理します。

頼むだけでできたこと
– 基本的なtxt2imgワークフローの構成（ノードの選択と配置）
– JSONの文法的に正しい出力
– LoRAの組み込み
– エラーメッセージからの原因特定
– 修正指示に基づく再生成

頼むだけで到達しなかったこと
– ノード間接続のインデックスの完全な正確性
– カスタムノードのパラメータ仕様の正確な把握
– ControlNetのバージョン対応関係の理解
– 生成画像の品質の最適化（パラメータ調整）

人が確認・修正すべきだったこと
– モデルファイル名の環境への合わせ込み
– ノード接続の読み込み後の目視確認
– パラメータ（steps、cfg等）の妥当性の最終チェック
– カスタムノードのバージョン互換性の確認

やり取りの回数
– 基本txt2img：2回（初回＋修正1回）
– ControlNet追加：3回（初回＋バージョン修正＋接続修正）
– LoRA追加：1〜2回
– エラー修正：1回で解決することが多い

最終的に完成したワークフロー

検証を通じて完成したのは、SDXLモデルを使ったtxt2img＋LoRAのワークフローです。CheckpointLoaderSimple → LoRA Loader → CLIPTextEncode（2つ） → KSampler → VAEDecode → SaveImageという流れで、ComfyUIで実際に読み込んで画像を生成できました。生成された画像はデフォルトパラメータのため品質に詰める余地はありますが、ワークフロー自体はエラーなく動いています。完成までのClaude Codeとのやり取りは合計3回でした。

JSONの構造を知らなくても、ComfyUIの画面上でノードが正しく繋がっているかを確認する目だけで、ここまで進められました。

この検証の振り返りと次に試すこと

依頼→結果→修正→限界→完成の全過程を振り返ります。

依頼：最初の依頼文でノードの種類とパラメータを明示したことが功を奏しました。曖昧な指示だと出力も曖昧になるので、ノード名は具体的に書く方が結果が安定します。

結果：1回目の出力はほぼ正解。ノードの種類と数は合っていて、接続の一部だけが外れていました。ComfyUIのノード接続ルール（入出力インデックスの対応）は、Claude Codeが完全には把握していない領域です。

修正：エラーの箇所を具体的に伝えれば、修正は1回で済むことが多いです。「KSamplerの出力0をVAEDecodeの入力0に」というレベルで指示すれば確実です。

限界：カスタムノードのパラメータ仕様とバージョン対応が境界線です。標準ノードは高精度でも、サードパーティノードはドキュメントの更新頻度が高く、Claude Codeの知識が追いついていない可能性があります。

完成：最終的に動くワークフローが完成するまで、対話形式で3〜4回のやり取りでした。慣れれば10〜15分程度で基本ワークフローが完成します。

初心者が試す際のコツ：最初はシンプルなtxt2imgだけを頼むこと。いきなりControlNetやIP-Adapterまで盛り込むと確認箇所が増えて挫折しやすいです。基本が動いてから追加していく方が確実です。

次に試すなら

API連携が面白いテーマです。ComfyUIにはAPI形式のワークフローJSONがあり、これを使えば生成をスクリプトから自動化できます。この変換をClaude Codeに頼めるかどうかは、また別の検証が必要です。

Claude Codeに頼むときのコツをまとめると：
– ノード名はclass_typeレベルで明示する
– パラメータ（steps、cfg等）は数値で指定する
– 接続関係は「あの出力をこの入力に」と日本語で書く
– モデルパスは自分の環境に合わせて後から直す前提にする
– 1回で完璧を狙わず、対話で詰める

まとめ

Claude Codeに頼むだけで、ComfyUIの基本的なtxt2imgワークフローは作れました。LoRAの組み込みも比較的スムーズです。ただしノード接続のインデックスやカスタムノードのパラメータ仕様については、ComfyUIに読み込んだ後の目視確認が必須でした。「頼むだけでここまでは進められた。ただし最後は人が確認する」——これが今回の検証の結論です。

今回の結果は、利用モデル、接続先、時期、環境によって変わる可能性があります。再現する時は検証条件もあわせて確認してください。

Claude Codeでどこまでできる？