概要
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)は additionally サポート: