Claudeで壊れたComfyUIワークフローを修復する方法

最初からClaudeにワークフロー全体を書き直させないでください。 通常のSave形式で元のJSONと正確なエラーを保存し、カスタムノードを無効にした状態で現在のデフォルトワークフローが動くことを確認します。その後、Claudeには渡した証拠だけを分類させます。依存関係は一度に一つだけ変え、最小の実行可能グラフを作り、画像を1枚生成し、Save Imageに結果が表示され、保存して再度開けるところまで自分で確認します。

この方法なら、「ComfyUIが大きく変わった」という曖昧な問題を、ComfyUI core、frontend extension、custom node、model file、旧グラフ本体という検証可能な層に分けられます。公式のComfyUIトラブルシューティングも、修正前にデフォルトワークフローを試し、カスタムノードを無効にし、ターミナルの正確なエラーを確認するよう案内しています。

修復手順の全体像

1. 元のワークフローを通常のSave形式で残し、上書きしない。
2. 完全なエラー、起動ログ、インストール方式、バージョン、直近の変更を保存する。
3. すべてのカスタムノードを無効にし、現在のデフォルト画像ワークフローを実行する。
4. Claudeには範囲を限定した証拠だけを渡し、編集やインストールの前に分析させる。
5. 障害をcore、frontend、custom node、model、unknownに分類する。
6. 互換性のないノードを一つだけ更新または置換するか、現在の最小グラフを再構築する。
7. 小さな画像を1枚実行し、実際の保存ファイルを確認する。

1. 変更前にワークフローと証拠を固定する

旧ワークフローを通常のJSONとして保存し、別の作業コピーを作ります。次のような小さな調査フォルダにまとめると、作業を再現できます。

comfyui-repair-case/
  workflow-original.json
  workflow-working.json
  error-report.txt
  startup-log.txt
  environment.md

workflow-original.jsonは読み取り専用として扱います。error-report.txtには「ノードが壊れた」という要約ではなく、Show reportの全文を入れます。startup-log.txtには起動ターミナルのimport failure、dependency conflict、tracebackを保存します。environment.mdにはDesktop、Portable、手動インストールのどれか、ComfyUIのバージョン、OS、GPU、最近更新したcore、frontend、custom nodes、modelsを記録します。

Save formatとAPI formatも混同しないでください。公式のWorkflow API Formatによると、通常の保存形式にはノード位置、色、グループなどの編集情報が残り、API形式はプログラムから送信するためにUIメタデータを省いた構造です。修復では通常形式の元ファイルを保持し、APIが本当に必要な場合だけ別のAPIコピーを書き出します。

2. 旧グラフより先にクリーンな基準を作る

旧グラフを最初のテストにしないでください。まずサードパーティーノードを一時的に無効にします。Desktopでは設定から操作でき、手動インストールでは通常、次のように起動できます。

python main.py --disable-all-custom-nodes

現在のデフォルトImage Generationテンプレートを読み込み、モデル一覧にすでに表示されている互換checkpointを選び、画像を1枚生成します。公式のカスタムノード障害ガイドでは、カスタムノードを無効にして問題が消えればcustom nodeが関係し、残るならcore、frontend、model、環境を調べるという切り分けを示しています。

結果から次の分岐を選びます。

基準テストの結果	可能性が高い層	次に確認すること
デフォルトワークフローも開かない、または実行できない	Core、frontend、model、hardware	旧グラフより先に基準環境を直す
デフォルトは動くが旧グラフにmissing nodesが出る	欠落、改名、未読込のcustom nodes	JSONのnode typeを所有パッケージに対応付ける
旧グラフは読めるが特定ノードで失敗する	Model architecture、接続、依存関係、メモリ	最初の失敗ノードと完全なreportを保存する
Frontend extensionを切るとUIが戻る	非互換のサードパーティーfrontend extension	半分ずつ有効にして一つを特定する

デフォルトグラフが失敗する状態では、旧JSONを書き換えても修復成功の証明にはなりません。

3. Claudeに範囲を限定した証拠パケットを渡す

Anthropicの説明では、Claude Codeはコードベースを読み、ファイルを編集し、コマンドを実行できます。便利な反面、最初の段階では分析だけに制限する必要があります。上の調査フォルダでClaudeを起動するか、同じファイルをチャットに添付し、次のように指示します。

更新後に動かなくなったComfyUIワークフローを診断してください。

読むファイルは次だけです。
- workflow-original.json
- workflow-working.json
- error-report.txt
- startup-log.txt
- environment.md

まだインストール、更新、削除、改名、編集をしないでください。
最初に次を行ってください。
1. ノード型と参照しているモデルファイルを一覧化する。
2. 各問題をComfyUI core、frontend extension、custom node、
   model file、unknownに分類する。
3. 各結論について正確なJSONフィールドまたはエラー行を引用する。
4. 最小で元に戻せる変更を提案する。
5. workflow-working.jsonを編集する前に承認を待つ。

私が画像を1枚実行し、保存ファイルを確認するまで、修復成功と断定しないでください。

有用な回答は、旧ノード型、所有extension、入出力契約、置換候補、パラメータ移行、根拠、リスクを並べた表です。所有元や置換先を確認できない場合、似た名前から推測せずunknownと記載させます。

4. 全更新ではなく、障害の層を分類する

Missing node：置換前に所有元を確認する

通常のSave JSONから、欠落ノードのtype、タイトル、リンクを調べます。名前が似ていてもsocketやwidget valuesが互換とは限らないため、JSON内の文字列だけを置き換えるのは安全な移行ではありません。coreか特定のcustom-node repositoryかを確認し、新旧の入力、出力、パラメータを比較します。

Extensionが保守されているなら、そのextensionだけを更新して再テストします。保守終了なら、保守中の代替を選ぶか、その小さな機能をcore nodesで再構築します。公式ガイドも、update、replace、作者へのreport、remove/disableを選択肢として示しています。

Frontend conflict：無効化して二分探索する

一部のcustom nodesはfrontend extensionsも注入します。白画面、接続切れ、preview消失、frontendとbackendの通信失敗はこの層が原因のことがあります。まずサードパーティーfrontend extensionsを無効にします。症状が消えたら、半分ずつ有効にして再テストします。このbinary searchは原因と結果を保ち、全再インストールより安全です。

Missing model：フォルダと検索パスを確認する

旧グラフが、削除、改名、移動されたcheckpoint、VAE、LoRA、ControlNetを参照している場合があります。ComfyUIはComfyUI/models/以下の分類フォルダとextra_model_paths.yamlの設定パスからモデルを検出します。選択欄が空、またはnullなら、実際の場所を確認し、その後にrefreshまたはrestartします。古いファイル名に合わせる目的で、非互換モデルを改名しないでください。

Architecture mismatch：ファイル名よりモデル系統を見る

公式のモデル障害ガイドは、ワークフロー内のモデルを同じarchitecture familyにそろえるよう勧めています。異なる系統のcheckpoint、VAE、text encoder、ControlNetを混ぜると、samplingやVAE decodeでtensor shape errorが出ることがあります。Claudeはstack traceとgraphを対応付けられますが、対象モデル系統の公式templateを互換性基準にする方が確実です。

5. 作業コピーのノードを一つだけ変更する

編集を承認する前に、Claudeに次の変更計画を出させます。

項目	必ず答える質問
旧ノード	JSONの正確なtypeは何か
所有元	Core、custom node、frontend extensionのどれか
置換先	入力と出力の型は一致するか
パラメータ移行	残せるwidget valuesと再設定が必要な値は何か
ロールバック	以前のworkflow-working.jsonをどう戻すか

変更はworkflow-working.jsonだけに、一度に一つの障害だけ許可します。各編集後に再読み込みし、ノードが存在するか、接続が有効か、パラメータがずれていないかを確認します。すべてのcustom nodesを一括更新すると別の互換問題が生まれ、どの変更が効いたのかという証拠も失われます。

コミュニティページは症状の照合には使えますが、普遍的な診断ではありません。frontend issue #6328とComfyUI discussion #14344は個別のユーザー報告です。バージョン、エラー、ノード状況が一致する場合だけ参考にします。

6. 現在の最小画像グラフを再構築する

旧グラフに古いLoRA、ControlNet、upscale、preview、utilityの枝が多い場合、全部を一度に直すより、中心を再構築する方が安全です。ComfyUIの公式最小Save形式サンプルを基準に中心部を作り直します。これは直列チェーンではなく分岐グラフです。複数の出力がKSamplerへ入り、VAEDecodeにはcheckpointのVAEも別経路で入ります。

出力ポート	入力ポート
CheckpointLoaderSimple.MODEL	KSampler.model
CheckpointLoaderSimple.CLIP	positive側のCLIPTextEncode.clip
CheckpointLoaderSimple.CLIP	negative側のCLIPTextEncode.clip
positive側のCLIPTextEncode.CONDITIONING	KSampler.positive
negative側のCLIPTextEncode.CONDITIONING	KSampler.negative
EmptyLatentImage.LATENT	KSampler.latent_image
KSampler.LATENT	VAEDecode.samples
CheckpointLoaderSimple.VAE	VAEDecode.vae
VAEDecode.IMAGE	SaveImage.images

EmptyLatentImageはconditioningを受け取りません。KSamplerにはmodel、positive、negative、latent_imageの4系統が独立して必要で、VAEDecodeにはサンプル後のsamplesとcheckpointのvaeが必要です。表のとおりに接続して初めて、最小グラフをキューに入れて画像を保存できます。

この接続は、選んだcheckpointのアーキテクチャが公式サンプルと一致する場合だけ使います。新しいモデルでは別のloader、text encoder、latent node、VAE経路が必要なことがあります。その場合は、この表を無理に当てはめず、モデル固有の公式workflowに従ってください。基準テストではLoad Checkpointにすでに表示される互換checkpointを選び、batch sizeは1、解像度は控えめにし、旧グラフの追加枝はまだ接続しません。基本線が通った後に、LoRA、ControlNet、upscaler、custom post-processingを一つずつ戻し、追加ごとに再実行します。

新グラフを旧グラフと同じ見た目にすることが目的ではありません。現在動くことを証明した基本線を先に作り、必要な機能だけを移行します。Claudeは二つのJSONを比較して移行表を作れますが、実行結果が受入テストです。

7. 画像を1枚実行し、保存結果を検証する

開くだけのワークフローは修復済みではありません。公式の初回生成ガイドに沿って最後まで確認します。

1. モデルを追加または移動した後はRでモデル一覧を更新し、必要なら再起動する。
2. Load Checkpointに表示される互換モデルを選んだことを確認する。
3. RunをクリックするかCtrl + Enterを押す。
4. Queueが完了し、missing node、validation error、赤い失敗ノードがないことを確認する。
5. 画像がSave Imageに表示されることを確認する。
6. 右クリックでローカル保存し、ファイル名を記録して画像ビューアーで開き直す。
7. 任意で、生成したComfyUI PNGを画面に戻し、埋め込みworkflow metadataを読めるか確認する。
8. 修復した通常形式のグラフをworkflow-repaired.jsonとして保存し、workflow-original.jsonは変更しない。

受入記録には、修復ワークフロー名、画像ファイル名、使用モデル、有効なcustom nodes、置換内容、既知の制限を残します。ここまで確認して初めて「修復済み」と言えます。

まだ失敗する場合の分岐

• **Custom nodesを無効にしてもデフォルトが失敗する：**旧グラフ編集を止め、install、model、driver、frontendの基準環境を直す。
• **デフォルトは動くが旧グラフにmissing nodesが残る：**所有元と置換の対応付けを続け、JSON typeを推測で改名しない。
• グラフは読めるが生成で失敗する：Show reportの最初の失敗ノードから始め、メモリの前にmodel familyと接続を確認する。
• **拡張の一群を有効にすると再発する：**custom nodeまたはfrontend extensionが一つになるまで二分探索を続ける。
• **元ノードが保守されていない：**機能を置換または再構築し、動作差を明記する。
• **ClaudeがエラーやJSONの根拠を引用しない：**提案を仮説として扱い、まだ実行しない。

まとめ

この作業でClaudeが最も信頼できるのは、証拠の整理役と変更計画役です。未検証の自動修復ボタンではありません。確実な流れは、バックアップ → クリーンな基準 → 分類 → 最小変更 → 画像1枚 → 保存ファイル確認です。元グラフを残し、一度に一変数だけ変え、自信のある説明ではなくComfyUIの実出力で修復完了を判断してください。