前回作ったキャラクターの画像を「参照画像」として渡し、同じ人物のままポーズを変えられるかを試しました。あわせて、その手順をワークフローとして保存し、ほかの人が再現できる形にまとめられるかも検証しています。
結論として、前回揃わなかったヘッドホンの細部や指定外の要素は、モデルの変更と参照画像の組み合わせでほぼ解消しました。3つのポーズとも、基準にした画像の絵柄と色が保たれています。
キャプション：［図：基準画像（左）と、今回参照画像を使って生成した3枚（腕組み、手を上げる、立ち姿）］
ノードベースの画像生成AIツール「ComfyUI」を実際に使い、業務に利用できるのかを検証する本企画も、今回が最終回です。
第1回ではComfyUI Desktopを導入して最初の1枚を生成し、第2回では記事のアイキャッチ制作に挑戦しました。第3回ではControlNetで構図を固定する方法を比較し、第4回ではアニメ調のキャラクターで連作に挑戦しています。
【入門編】高品質AI画像生成の定番ComfyUI入門！ 最初の1枚とワークフローの再現まで試してみた
【実践編】ComfyUIで記事のアイキャッチを制作！ 横長構図とタイトル余白を狙ってみた
【実践編】ComfyUIのControlNetで構図を狙う！ Canny・Depth・OpenPoseを比較してみた
【応用編】ComfyUIで同じキャラを描き続けられる？ アニメ調の連作イラストに挑戦
第4回では、同じ設定の人物を3枚作ることはできたものの、次の課題が残りました。
- ヘッドホンのライン色など、装飾の細部が毎回変わる
- リュックの肩ひもなど、指定していない要素が消えない
- ポーズの破綻を避けられたのは、seedの当たりによるもの
第5回では、この3つを参照画像で解消できるかを確かめたうえで、手順をチームで再利用できる形にまとめます。最後に、5回分の検証から「ComfyUIは業務で使えるか」を評価します。
参照画像を使う前に、使えるものを仕分ける
参照画像から特徴を受け継ぐ仕組みとして、企画段階で予定していたのは「IP-Adapter」でした。参照画像の色味や雰囲気を生成に反映させる補助モデルで、Stable Diffusion向けに広く使われています。
ただ、第4回でモデルをFLUX.1 Schnellに切り替えたことで、事情が変わりました。そこで前回の教訓どおり、機能を比べる前にライセンスで仕分けています。
| 候補 | ライセンス | 判定 |
| IP-Adapter（SD1.5／SDXL向け） | Apache-2.0 | 使えるが、ベースのSD1.5は第4回でキャラクターを描けなかった |
| IP-Adapter用の代表的なカスタムノード | GPL-3.0 | 2025年4月から保守のみ |
| FLUX向けIP-Adapter（XLabs、InstantX） | FLUX.1 [dev]（非商用） | 使えない |
| FLUX.2 [klein] 4B | Apache-2.0 | 採用。標準ノードで参照画像を使った編集ができる |
| FLUX.2 [klein] 9B | 非商用 | 使えない |
| Qwen-Image-Edit-2511 | Apache-2.0 | 手元の環境では動かせず除外（後述） |
SD1.5向けのIP-Adapter自体は、商用利用を妨げないライセンスです。しかしベースとなるSD1.5は、第4回でキャラクターの髪色や衣装を描けなかったモデルでした。また、ComfyUIでIP-Adapterを使うための代表的なカスタムノードは、2025年4月から作者が保守のみの状態にしています。チームで長く使うワークフローの土台としては不安が残ります。
FLUX向けのIP-Adapterは、いずれもFLUX.1 [dev]を前提にした非商用ライセンスでした。前回のControlNetと同じ構図です。
そこで浮上したのが「FLUX.2 [klein] 4B」です。開発元のBlack Forest Labsが公開している軽量モデルで、文章からの生成に加えて、参照画像を渡して編集する機能を備えています。4BはApache-2.0で、商用利用が可能です。ComfyUIの標準ノードで動き、カスタムノードを追加する必要もありません。
ここで1つ、つまずきがありました。kleinには4Bと9Bの2つのサイズがあり、9Bは非商用ライセンスです。ComfyUIのテンプレート一覧から画像編集のテンプレートを開いたところ、それが9B版でした。テンプレート名を取り違えていたのですが、保存ファイル名の初期値は「Flux2-Klein-4b-base」となっていて、名前だけでは気づけません。実行前にノード内のモデル名（unet_name）を見て気づき、9B系のファイルは削除しています。
同じ「FLUX.2 [klein]」でも、サイズによってライセンスが分かれます。名前ではなく、ファイル単位で確認する必要があります。
ファイル単位の確認が必要な例は、ほかにもありました。公式ガイドが案内するVAEは、「flux2-dev」という名前のリポジトリで配布されています。FLUX.2 [dev]本体は非商用ですが、VAE（オートエンコーダー）については、Black Forest LabsがGitHubでApache-2.0での公開を明記しています。「dev」と名の付く場所から入手しても、ファイル自体は商用利用できるということです。証跡には、再配布ページではなく開発元の一次情報を残しました。
今回の環境
今回の環境はComfyUI Desktop v0.42.1です。第4回のv0.35.1から、大きな更新をまたいでいます。
そこで最初に、第4回の採用画像（seed 4015）のPNGをキャンバスへドラッグし、設定を変えずに再生成しました。結果は同じ画像です。ソフトを更新しても、保存した条件から同じ画像を再現できることを確かめてから、検証に入りました。
GPUはRTX 5070（VRAM 12GB）、メインメモリは16GBです。参照画像を使った編集に強いとされるQwen-Image-EditもApache-2.0で候補でしたが、軽量版でも約20GBあり、この環境では動かせないため外しています。手元の機材で選択肢が絞られるのも、実務では起きることです。
使用したファイルは次の3つです。比較用に、kleinのBase版（後述）も使いました。
- 拡散モデル：flux-2-klein-4b（蒸留版）
- テキストエンコーダー：qwen_3_4b
- VAE：flux2-vae
入力に使った画像は、第4回で基準キャラクターにしたseed 4003の画像1枚だけです。連載内で生成した画像なので、本連載の入力素材のルールの範囲内です。前回は見た目の判定基準としてのみ使ったこの画像を、今回初めて入力として渡します。
モデルを替えただけで、細部のばらつきが消えた
参照画像を渡す前に、まずモデルの違いだけを確かめました。第4回の立ち姿のプロンプトを、一字も変えずにkleinへ渡しています。
kleinには、Base版と蒸留版があります。蒸留版はBase版を少ない工程で動くようにしたもので、Base版が20ステップ・CFG 5.0で動くのに対し、蒸留版は4ステップ・CFG 1.0です。両方で、seed 4001〜4004の4枚ずつを生成しました。
キャプション：［図：同じプロンプトをBase版（上段）と蒸留版（下段）へ渡した結果。seedは左から4001〜4004］
8枚すべてに、銀髪のボブ、緑の目、黄色のパーカー、首にかけた黒いヘッドホンが反映されました。第4回で毎回変わっていたヘッドホンのライン色は出ず、8枚とも指定どおりの黒です。リュックの肩ひもも描かれていません。参照画像を使う前の段階で、前回の課題のうち2つがほぼ解消したことになります。
ただし、絵柄は変わりました。第4回の画像は目が大きく頬に赤みのある絵柄でしたが、kleinはどちらの版も大人びた顔立ちで、やや写実寄りです。プロンプトが同じでも、モデルによって「アニメ調」の解釈が違います。
2つの版の違いは次の通りです。
| Base版 | 蒸留版 | |
| 描き込み | 細かく、立体的 | 平塗りで、線がはっきりしている |
| seedを変えたときの差 | 顔立ちや髪の分け方が変わる | 4枚がよく似ている |
| 生成時間（RTX 5070） | 約20秒（初回は約35秒） | 約5秒（初回は約10秒） |
今回の目的は同じキャラクターを揃えることなので、seedを変えてもぶれにくく、4倍速い蒸留版を主軸にしました。条件を何度も振って比べる検証では、1枚あたりの時間の差が効いてきます。
画像の「渡し先」を変えると、絵柄が残る
次に、seed 4003の画像を参照として渡しました。使ったのは、ComfyUIのテンプレートにある「FLUX.2 [Klein] 4B: 画像編集 Distilled」です。
指示文は、ポーズを指定する一文と、維持してほしい項目を並べた一文の2つで組み立てました。3枚とも後半の文はそのままにし、前半のポーズの一文だけを差し替えています。seedは4000で固定です。
腕組み
Change her pose so she stands with her arms crossed, upper body visible. Keep the same character, face, hairstyle, hair color, eye color, yellow hoodie, black headphones around her neck, art style, line art and white background unchanged.
手を上げる・立ち姿は、前半の一文をそれぞれ「raises her right hand in a friendly wave」「a relaxed standing pose with both arms down at her sides」に替えています。
キャプション：［図：基準画像（左）と、参照画像を渡して生成した3枚］
3枚とも、絵柄は基準画像の側に残りました。大きな目、頬の赤み、線の太さまで、第4回の画像の特徴が保たれています。参照なしでkleinに描かせた先ほどの8枚と並べると、参照画像が絵柄ごと引き継がせていることがよく分かります。
第4回のimg2imgでは、下絵の画像を生成の出発点（潜在画像）として渡していました。そのため、ノイズ除去を上げると下絵がノイズに置き換わり、結果に影響しなくなりました。
今回のワークフローは仕組みが違います。参照画像は潜在画像に変換されたうえで、「ReferenceLatent」というノードによって、プロンプトから作られる「どう描くかの指示」（条件付け）の側に添付されます。生成の出発点は、何もない空の潜在画像のままです。
同じ画像を渡しても、出発点に渡せば上書きされ、指示の側に渡せば最後まで効力を持ちます。ワークフローの画面で線のつながりを追えば、この違いはそのまま目で確かめられます。
キャプション：［図：画像編集のワークフロー。参照画像がReferenceLatentを経由して条件付けへ渡っている］
第4回と同じ項目で、基準キャラクターと見比べた結果は次の通りです。
| 項目 | 腕組み | 手を上げる | 立ち姿 |
| 顔立ち・絵柄 | 基準どおり | 基準どおり | 基準どおり |
| 髪型 | 一致 | 一致 | 一致 |
| 髪色 | 一致 | 一致 | 一致 |
| 目の色 | 一致 | 一致 | 一致 |
| 衣装 | 一致 | 一致 | 一致 |
| ヘッドホン | 一致（黒、同じ形） | 一致 | 一致 |
| 表情 | 無表情を維持 | 笑顔に変化 | 無表情を維持 |
| 指定外の要素 | なし | なし | ポケットとズボン |
前回の表と比べると、ヘッドホンと指定外の要素の行がほぼ埋まりました。残ったのは、表情の変化と、立ち姿での描き足しの2点です。
1つずつ変えて、何が効いているかを確かめる
ここからは、条件を1つずつ変えて結果を比べました。前回の教訓どおり、見た目の印象だけでなく、画素単位の差も測っています。
seedを変えても揃うか
腕組みの指示文のまま、seedを4001〜4003に替えて3枚を生成しました。
キャプション：［図：腕組みをseed 4000〜4003で生成した4枚］
4枚とも、髪型、色、ヘッドホン、腕の組み方まで揃い、破綻はありません。違いは人物の大きさや袖口の形といった程度です。第4回の「ポーズの破綻を避けられたのはseedの当たり」という状態から、どのseedでも使える画像が出る状態に変わりました。
表情は、指示しないと変わる
手を上げるカットだけ、基準画像の無表情が笑顔に変わっていました。指示文の「friendly wave」に引っ張られたうえ、維持する項目に表情を入れていなかったためと考えられます。
そこで、維持する項目に「neutral expression」を足し、同じseedで生成し直しました。結果は無表情に戻り、前の画像との差は画像全体の2.8%で、ほぼ口元に集中していました。維持してほしい項目は、明示的に並べないと守られないということです。
キャプション：［図：手を上げるカット。「neutral expression」を足す前（左）と後（右）］
同じ「neutral expression」を、もともと無表情だった腕組みにも足してみました。見た目はほとんど変わりません。
前回は「値を変えたのに画像が変わらない」ことが問題でした。今回はその逆で、意味を変えないつもりの一語でも、画像が変わることがあります。設定値だけでなく、指示文の言い回しも記録の対象にする必要があります。
写っていない部分は、モデルが描き足す
残る論点は、立ち姿での描き足しです。基準画像は胸から上しか写っていませんが、立ち姿では腰のあたりまで描かれ、パーカーのポケットや紺のズボンが加わりました。
自然な補い方ではあるものの、連作で使うなら、写っていない部分がカットごとに変わらないかが問題になります。そこで、指示文を変えずにseedだけを替えて確かめました。
結果、ズボンは写ったり写らなかったりしました。ただし原因は、ズボンを描くかどうかではありません。人物をどこで切るかがseedごとに変わり、ズボンが画面に入るかどうかが変わっていたのです。写ったときの色はいつも紺で、ポケットはすべての画像に描かれていました。
次に、維持する項目に「dark navy pants」を足しました。すると3枚ともズボンがはっきり描かれ、構図そのものが太ももあたりまで下に広がりました。指示した要素を見せるために、モデルが構図まで変えたことになります。
キャプション：［図：立ち姿。指示なし（上段）と「dark navy pants」あり（下段）］
運用としては、ズボンの指定は立ち姿のときだけ入れることにしました。上半身の構図で入れると、構図が崩れる恐れがあるためです。なお、今回採用した3枚は、生成後に人の手で修正する必要はありませんでした。
共有で詰まるのは、画面に見えない設定だった
検証の最後に、手順をチームで再利用できる形にまとめました。
採用したのは次の3枚です。
- 腕組み：seed 4000
- 手を上げる：seed 4000、「neutral expression」あり
- 立ち姿：seed 4002、「dark navy pants」あり
ワークフローは、テンプレートに付いていた使わないノードを削除し、採用した立ち姿をそのまま再現する状態で書き出しました。キャンバス上には、次の内容を書いたメモノードを置いています。
- 用途
- 使用モデル、ライセンス、入手元
- 使ってはいけないモデル（9B系）
- 入力してよい画像
- 固定する設定
- 指示文の型と注意点
- 公開前チェックの項目
キャプション：［図：共有用に整えたワークフローとメモノード］
ComfyUIは生成したPNGにワークフローを埋め込むため、このメモも採用画像のPNGに一緒に保存されます。採用画像を1枚渡すだけで、設定とメモの両方が相手に届くというのが、便利な点です。
今回の失敗の切り分け
第4回と同様に、今回の失敗を整理しておきます。
| 失敗 | 気づいたきっかけ | 対策 |
| テンプレートを選び間違え、非商用の9B版を開いた | ノード内のモデル名 | 実行前にunet_nameを確認する。不要なファイルは削除する |
| seedがランダムのまま1枚生成していた | PNGに埋め込まれた生成条件 | seedを固定し、保存後に記録を確認する |
| ファイル名と中身のseedが食い違っていた | 2枚の画像が画素単位で完全に一致した | 同上 |
| 維持する項目に入れなかった表情が変わった | 基準画像との見比べ | 維持したい項目をすべて並べる |
4つのうち3つは、生成した画像を眺めるだけでは気づけないものでした。手がかりになったのは、PNGに埋め込まれた生成条件と、ワークフローのファイルそのものです。
モデルのライセンスと、生成後の確認
今回使用したファイルと、確認したライセンス表示は以下の通りです。
| ファイル | ライセンス表示 | 確認した一次情報 |
| flux-2-klein-4b（蒸留版） | Apache License 2.0 | Hugging Face（black-forest-labs/FLUX.2-klein-4B） |
| flux-2-klein-base-4b／base-4b-fp8（比較用） | Apache License 2.0 | Hugging Face（black-forest-labs）［ページ名を確認］ |
| qwen_3_4b | Apache License 2.0 | Hugging Face（Qwen/Qwen3-4B）。入手はComfy-Orgの再配布版 |
| flux2-vae | Apache License 2.0 | GitHub（black-forest-labs/flux2）。入手はComfy-Org/flux2-dev |
使わなかったものは、FLUX.2 [klein] 9B（非商用）、FLUX向けのIP-Adapter（FLUX.1 [dev]が前提で非商用）、Qwen-Image-Edit（環境の制約）です。
権利面では、次の点を確認しています。
まず、入力した画像は、連載内で生成した基準画像1枚だけです。他人の写真、SNS画像、既存作品は入力していません。
次に、参照画像を渡すと、入力した画像の特徴が強く引き継がれる点です。今回は基準画像の絵柄や色が細部まで保たれましたが、裏を返せば、他人の写真や既存キャラクターの画像を入れれば、それによく似た画像が作れてしまうということです。参照画像を使う仕組みでは、入力素材のルールが一層重要になります。
また、作業環境に入っていたカスタムノード2つ（VideoHelperSuite、Use Everywhere）は、今回のワークフローでは使っていません。ただし、企画時の使用ソフト一覧には載っていませんでした。
連載総括：ComfyUIは業務で使えるか
本連載では、企画時に4つの観点を掲げていました。5回分の検証をもとに評価すると、次のようになります。
| 観点 | 評価 | 根拠 |
| 実務で使える品質に届くか | ◯ | アイキャッチ（第2回）、構図の指定（第3回）、キャラクターの連作（第5回）で、記事に使える水準の画像を作れた |
| 業務用途で再現性があるか | ◎ | 同じ条件なら画素単位で同じ画像が出る。ソフトの更新後も、ファイルの修正後も再現できた |
| 権利リスクに配慮して使えるか | △〜◯ | 商用利用できる構成は組める。ただしファイル単位の確認が欠かせず、テンプレート1つで非商用モデルに切り替わる |
| チームで共有できるか | ◯ | 設定とメモはPNG1枚で渡せる。一方で受け取る側の機材も前提になる |
向いているのは、条件を固定して同じ種類の画像を繰り返し作る仕事です。案内役キャラクターの別カット、シリーズ記事のアイキャッチ、資料用の図版などがこれにあたります。
導入するなら、少なくとも次の3つが必要です。
- VRAM 12GB級のGPUと十分なメモリを積んだPCを、使う人数分
- 使用するファイルごとのライセンス確認と、その記録の担当
- 生成条件をPNGやワークフローの記録で確かめる習慣
おわりに
5回の検証を通じて、ComfyUIの価値は、きれいな画像が1枚出ることよりも、条件を固定し、比べ、記録できることにあると感じました。第4回で「思い通りにならなかったときに原因を特定できること」と書きましたが、今回はそれが共有の場面でも同じように効いています。seedの取り違えにも、見えない設定の食い違いにも気づけたのは、記録が残っていたからです。
逆に言えば、記録を確かめる習慣がなければ、同じ失敗はチームの中で何度でも起きます。ComfyUIを業務に入れるかどうかは、ツールの性能よりも、チームで記録を残せるか、という点にあると感じました。
記録を残せれば、チームでワークフローを作って、簡易的な「特殊用途特化の生成アプリ」のようなものが作れます。この点が、ComfyUIが生産性において特にアドバンテージが大きい部分だと感じました。
本連載もここまでとなります。最後までお付き合いいただき、ありがとうございました。
