概要
ComfyUI V3 スキーマは、ノードを定義するためのより整理された方法を導入しており、今後のノード機能の拡張は V3 スキーマにのみ追加されます。このガイドを参考に、既存の V1 ノードを新しい V3 スキーマへ移行してください。核心概念
V3 スキーマは新しいバージョン管理された Comfy API 上に維持されており、将来のスキーマの改訂は下位互換性があります。comfy_api.latest は開発中の最新番号付き API を指し、latest の前のバージョンが「安定版」と見なせます。バージョン v0_0_2 は現在(かつ最初)の API バージョンであるため、警告なしに変更が行われる可能性があります。安定版と見なされると、latest が指すために新しいバージョン v0_0_3 が作成されます。
V1 対 V3 アーキテクチャ
V3 スキーマの主な変更点は以下の通りです:- 入力と出力が辞書ではなくオブジェクトで定義される。
- 実行メソッドは ‘execute’ という名前に固定され、クラスメソッドである。
def comfy_entrypoint()関数が ComfyExtension オブジェクトを返し、NODE_CLASS_MAPPINGS/NODE_DISPLAY_NAME_MAPPINGS の代わりに公開ノードを定義する。- ノードオブジェクトは ‘state’ を公開しない -
def __init__(self)はノードの関数で公開される内容に影響を与えない(すべてクラスメソッドであるため)。ノードクラスは実行前にもサニタイズされる。
V1 (レガシー)
V3 (モダン)
移行ステップ
V1 から V3 への移行は、ほとんどの場合単純で、構文の変更のみです。ステップ 1: ベースクラスの変更
すべての V3 スキーマノードはComfyNode から継承する必要があります。継承チェーンのトップに ComfyNode 親があれば、複数の継承層でも問題ありません。
V1:
ステップ 2: INPUT_TYPES を define_schema に変換
ノード ID、表示名、カテゴリなどのノードプロパティは、以前は辞書やクラスプロパティなどコードの異なる場所に割り当てられていましたが、現在はSchema クラスを介して一緒に管理されます。
関数 define_schema(cls) は、V1 の INPUT_TYPES(s) とほぼ同じ方法で Schema オブジェクトを返すことが期待されます。
サポートされているコア入力/出力型は comfy_api/{version} の _io.py に保存および文書化されており、デフォルトで io として名前空間化されています。入力/出力は辞書や文字列ではなくクラスで定義されるようになったため、カスタム型は独自のクラスを定義するか、io のヘルパー関数 Custom を使用することでサポートされます。
カスタム型については、以下のセクションで詳しく説明します。
型クラスには以下のプロパティがあります:
- 入力用の
class Input(例:Model.Input(...)) - 出力用の
class Output(例:Model.Output(...))。すべての型が出力としてサポートされているわけではないことに注意。 - 型の型ヒントを取得するための
Type(例:Model.Type)。一部の型ヒントは単にanyであり、将来更新される可能性があることに注意。これらの型ヒントは強制されず、有用なドキュメントとして機能するのみ。
ステップ 3: 実行メソッドの更新
V3 のすべての実行関数はexecute という名前で、クラスメソッドです。
V1:
ステップ 4: ノードプロパティの変換
以下にプロパティ名の例を示します。詳細はcomfy_api.latest._io のソースコードを参照してください。
ステップ 5: 特殊メソッドの処理
V1 と同じ特殊メソッドがサポートされていますが、より明確にするために小文字化または完全に改名されています。使用方法は同じです。検証 (V1 → V3)
入力検証関数はvalidate_inputs に改名されました。
V1:
遅延評価 (V1 → V3)
関数check_lazy_status はクラスメソッドになり、それ以外は同じです。
V1:
キャッシュ制御 (V1 → V3)
キャッシュ制御の機能は V1 と同じですが、元の関数名はどのように動作するかについて非常に誤解を招くものでした。 V1 のIS_CHANGED 関数は、戻り値がノードを前回実行したときと同じ場合、ノードの再実行をトリガーしないように信号を送ります。
したがって、関数 IS_CHANGED は fingerprint_inputs に改名されました。開発者による最も一般的な間違いの 1 つは、True を返すとノードが常に再実行されると考えることでした。True が常に返されるため、ノードを 1 回だけ実行してキャッシュ値を再利用するという逆の効果になります。
この関数を使用する例として、LoadImage ノードがあります。選択されたファイルのハッシュを返すため、ファイルが変更された場合、ノードは強制的に再実行されます。
V1:
ステップ 6: 拡張機能とエントリーポイントの作成
ノード ID をノードクラス/表示名にリンクするための辞書を定義する代わりに、ComfyExtension クラスと定義が期待される comfy_entrypoint 関数ができました。
将来、get_node_list を介してノード以外を登録するために、ComfyExtension により多くの関数が追加される可能性があります。
comfy_entrypoint は非同期でも同期でも構いませんが、get_node_list は非同期として定義する必要があります。
V1:
入力型リファレンス
ステップ 2 ですでに説明しましたが、ここに V1 対 V3 の型リファレンス比較をいくつか示します。完全な型宣言はcomfy_api.latest._io を参照してください。
基本型
control_after_generate
Int および Combo 入力は、各生成後に値を自動的に変更するための制御ウィジェットを追加するcontrol_after_generate パラメータをサポートします。V1 ではこれは単純な bool でしたが、V3 では明示的な制御のために io.ControlAfterGenerate 列挙型を使用できます。True を渡すことは io.ControlAfterGenerate.randomize と同等です。
ComfyUI 型
Combo(ドロップダウン/選択リスト)
V3 の Combo 型には明示的なクラス定義が必要です。 V1:スキーマリファレンス
データクラスSchema は V3 ノードのすべてのプロパティを定義します。以下に利用可能なすべてのフィールドの完全なリファレンスを示します:
共通入力パラメータ
すべての入力型はこれらの基本パラメータを共有します:
ウィジェット入力(Int、Float、String、Boolean、Combo)はさらに以下もサポートします:
高度な機能
非表示入力
非表示(Hidden)入力は、プロンプトメタデータ、ノード ID、その他の内部値など、実行コンテキストへのアクセスを提供します。これらは UI には表示されません。 V1 では、非表示入力はINPUT_TYPES 内の "hidden" キーとして宣言されていました。V3 では、Schema の hidden パラメータで宣言し、その値には cls.hidden 経由でアクセスします。
V1:
一部の非表示の値は、Schema のフラグに基づいて自動的に追加されます。出力ノード(
is_output_node=True)は自動的に prompt と extra_pnginfo を受け取ります。API ノード(is_api_node=True)は自動的に認証トークンを受け取ります。UI ヘルパー
V3 には、プレビューやファイル保存などの一般的なパターンを処理するための組み込み UI ヘルパーがui モジュールで提供されています。ui パラメータを介して io.NodeOutput に渡します。
プレビューヘルパー
プレビューヘルパーは一時ファイルを保存し、ノード内表示用の UI データを返します。保存ヘルパー
保存ヘルパーは、適切なメタデータを埋め込んでファイルを出力ディレクトリに保存するメソッドを提供します。通常は出力ノードで使用されます。生の UI 辞書の返却
ヘルパーが存在しない UI データを返す必要がある場合は、辞書を直接渡せます:出力ノード
ファイル保存のような副作用を持つノードに使用します。V1 と同様に、ノードを出力ノードとしてマークすると、ノードのコンテキストウィンドウにrun 再生ボタンが表示され、グラフの部分実行が可能になります。
カスタム型
クラス定義またはCustom ヘルパー関数を使用して、カスタムの入力/出力型を作成できます。
MultiType 入力
MultiType を使用すると、1 つの入力が複数の型を受け入れられるようになります。これは、同じ入力スロットを通じて異なるデータ型を扱えるノードに便利です。
最初の引数(id)が文字列ではなく Input クラスのインスタンスである場合、その入力の上書きされた値を使ってウィジェットが作成されます。それ以外の場合、入力はソケット専用になります。
MatchType(汎用型マッチング)
MatchType は型がリンクされた入力と出力を作成します。ユーザーが特定の型を MatchType 入力に接続すると、同じテンプレートを共有する他のすべての入力と出力が自動的にその型に制約されます。Switch や Create List のようなノードが任意の型で動作するのはこの仕組みによるものです。
動的入力
V3 では、ユーザーの操作に応じて利用可能な入力が変化する動的入力型が導入されました。これらの機能に V1 の相当物はありません。Autogrow
Autogrow は、ユーザーが接続するにつれて自動的に増加する可変数の入力を作成します。テンプレートには 2 種類あります:
TemplatePrefix は番号付きプレフィックスの入力(例:image0、image1、image2…)を生成します:
DynamicCombo
DynamicCombo は、選択したオプションに応じて異なる入力の表示/非表示を切り替えるドロップダウンを作成します。これは、モードごとに異なるパラメータが必要なノードに便利です。
非同期 Execute
V3 は非同期のexecute メソッドをサポートしています。これは、I/O 操作、API 呼び出し、その他の非同期処理を行うノードに便利です。execute を async として宣言するだけです:
ComfyAPI
ComfyAPI クラスは、進捗レポートやノード置換の登録など、ComfyUI のランタイムサービスへのアクセスを提供します。インポートしてインスタンスを作成します:
進捗レポート
ノードのexecute メソッド内から実行の進捗を報告します。進捗バーは ComfyUI インターフェースに表示されます。これは、V1 で comfy.utils.PROGRESS_BAR_HOOK を使用していたパターンを置き換えるものです。
set_progress の preview_image パラメータには、PIL 画像、ImageInput テンソル、または None を指定できます。execute 内から呼び出された場合、node_id は実行コンテキストから自動的に決定されます。ノード置換
ノード置換を使用すると、古いノードや非推奨のノードを新しいノードにマッピングでき、既存のワークフローが自動的にアップグレードされます。拡張機能のon_load メソッドで ComfyAPI を使用して置換を登録します。
old_widget_ids パラメータは重要です:ワークフロー JSON はウィジェットの値を名前ではなく位置インデックスで保存します。このリストは、置換システムが移行中にウィジェットの値を正しく識別できるよう、それらの位置インデックスを入力 ID にマッピングします。
動的入力(Autogrow など)を使用するノードでは、マッピングにドット区切りのパスを使用します:
拡張機能のライフサイクル
ComfyExtension クラスは、get_node_list 以外にもライフサイクルフックをサポートしています:
NodeOutput
NodeOutput クラスは execute の標準的な戻り値です。いくつかのパターンをサポートしています: