ツールを見つけ直し、それが生み出すものを検証しましょう。

検証可能な準備を記述する

成果物から始めましょう。パス付きの完成画像、ポスターの検索、または組み立てるアニメーションです。主要なソフトウェア、エンジン、使用バージョン、納品すべきフォーマットを書き留めます。計算後に行われる処理も加えます。デコード、ノイズ除去、拡大、コンポジット、エンコードなどです。ツールは生成に成功しても、次の工程で失敗することがあります。

コンフィギュレーターでは、Ubuntu、PyTorch、Blender、またはカスタムの準備を指定できます。この選択には短いシートを添えましょう。既存のプロジェクトを再開する場合は「最新バージョン」を避けてください。この表現は意味が変わってしまいます。判明している正確なバージョンを記載し、他の要素は「要確認」と印をつけます。ソフトウェアと処理はご自身で選ぶものですが、そのライセンス、依存関係、要件は検討の余地があります。

Blenderシートをシーンとともに準備する

Blenderのバージョン、レンダリングエンジン、必須の拡張機能、シーンの設定を書き留めます。Cyclesでは、GPU計算の選択はデバイス設定とプロジェクトパラメーターに関わります。予定のバージョンとドライバーでハードウェア対応を確認しましょう。カード名だけではこの互換性を説明できません。

テクスチャ、リンクされたライブラリ、フォント、キャッシュも集めます。エラーメッセージなしで開いても、アニメーションのすべての画像がリソースを見つけられるとは限りません。3Dワークショップでは代表的なレンダリングケースを準備し、Pliフォルダーでは転送を詳しく説明しています。最後に、次のアプリケーションで一貫した色を取り戻すために必要な設定を保存しましょう。

JSONファイルを超えてComfyUIを準備する

ComfyUIのリビジョン、判明している場合はそのインターフェースのリビジョン、ワークフローJSON、そしてモデルの参照情報を保持してください。各ウェイトについて、正確な名前、入手元、バージョンまたはリビジョン、想定される配置場所を記録します。フィンガープリントは、同じ名前でリネームされた2つのファイルを区別するのに役立ちます。グラフは手順を記述するものであり、ウェイトをその場所に運ぶものではありません。

coreノードと拡張機能を分けてください。拡張機能はコードとPython依存関係をもたらすことがあります。それらはComfyUIを起動する環境に属している必要があります。インストール後は、一連の処理を実行する前に読み込みエラーを確認してください。Céramiqueフォルダーには、カスタムノードを使わない例があり、マニフェストと再構築手順が付属しています。ただし、他のグラフが動作することを保証するものではありません。

実際に作業を実行する環境を特定する

システム、Python、PyTorch、使用している計算バリアントを記録してください。ComfyUI は別個の Python 環境で動作するため、そのポータブルインストールでは、隣で開いたターミナルとは別のインタープリターを使うことがあります。ライブラリが存在するように見えても見つからない場合は、パッケージを何度も再インストールする前に、まずこのずれを確認してください。

CUDA のチェーンは ROCm へ自動的に置き換わるものではありません。メインソフトウェアだけでなく、拡張機能やオペレーションの要件も確認してください。カタログの構成を比較する際は、カードごとの公称メモリを、実際に観測した必要量や明示すべき CPU・RAM・ストレージのリソースとは分けて扱ってください。不明な基準値を、いわゆる「標準」とされる値で置き換えないでください。

チェーン全体をカバーするテストを構築する

短いながらも代表的な入力から始めてください。難しい素材を含むフレーミング、最終デコードを含むワークフロー、またはシーン切り替えをまたぐ数枚の画像などです。入力を開き、実際に使用されているデバイスを確認し、処理を実行し、出力を保存して、結果を受け取るソフトウェアでそれを開いてください。得られたファイル名を記録し、「OK」だけでは済ませないでください。

低解像度の出力は、経路の一部を検証するにすぎません。本番前に、負荷を変えうる最終的な寸法、ステップ、フォーマットも試してください。正確なエラー、該当するステップ、試した変更を記録してください。バージョンやモデルを変更したら、この確認を繰り返してください。以前の組み合わせの成功は、新しい組み合わせを検証するものではありません。

仮の例：フレコンキャンペーンを引き継ぐ

Blenderの画像1点と、ComfyUIでのライト探索3点からなるキャンペーンを想像してみましょう。仕様書はPliジェネレーターにBlender 4.5.xを、Céramiqueマニフェストに記載された参照を求めています。これらのバージョンは文書化された出発点であり、インストール済みと主張するソフトウェアではありません。2つのレシピは別々のままです。Blenderから得た画像は、フォルダをコピーしただけでComfyUIの生成物になるわけではありません。

チームはチェーンの確認を2つ予定しています。保存されたBlenderの画像1点と、3つの出力を生み出すCéramiqueの完全な実行1回です。これは所要時間の見込みなしで、4点の画像が期待されることを意味します。その後、各出力のコピーをレイアウトツールで開く予定です。この例では、結果は実行後に記入するままです。あらかじめ埋められる欄はありません。

PliとCéramiqueについてすでに利用可能な証拠は、ファイルと構造に関するものです。これらのパックでは、BlenderのレンダリングもComfyUIの生成も行われていません。ここでの意義は、依存関係と確認を、既知の限界とともに具体的にすることです。

設定全体を変える前に診断する

一度に1つの障害に対処し、最初の記録を保持してください。モデル、ソフトウェア、ドライバー、解像度を同時に変更すると、最終的に成功しても、何が問題を解決したのか分からなくなります。最初のメッセージを保存し、その後、関連する変更を1つだけ比較してください。更新が必要な場合もありますが、それは環境の識別可能な新しいバージョンを形成するものでなければなりません。

生成のシードは保存しておくと有用ですが、バージョンやプラットフォーム間で同一の結果を保証するものではありません。創造的な再開のために、何を求めるのかを定義してください。厳密に同一のファイル、比較可能な構図、許容できる見た目などです。これらの基準は同じ確認を必要とするわけではありません。

初回セッション後も使えるベースを保つ

環境シートは、日付、確認結果、まだ不確かな項目とともにプロジェクトのそばに保管しましょう。許可されたファイルとそのライセンスや参照情報は、独立したコピーとして保持します。拡張機能やモデルの場合、出典を記録することは、その内容を再配布してよいという意味ではありません。

準備とこの初回受け取りは、3日、7日、30日のいずれかの期間に収め、その後は復旧のための時間を確保しましょう。プロジェクトノートはメモと設定を保持しますが、シーンや画像のアーカイブの代わりにはなりません。終える前に、エクスポート確認に従って、この環境で制作した作品も漏れなく見つけられるようにしましょう。