2026.08.27 2026.08.27

挿絵をローカル画像生成でまかなう — ComfyUIとFLUXのライセンスを読み違えないために

ゲンキ

記事1本に挿絵が12枚要る。従量課金の生成サービスで10枚出して1枚選ぶ作り方をすると、捨てた9枚にも金がかかる。ローカル画像生成へ最初に移ってくるのが画像なのは、この構造のためだ。テキスト生成より単価が高く、当たり外れが大きい。

ただし、移す前に確認しなければならないことがある。モデルのライセンスだ。ここを読み違えると、生成した画像を使えないどころか、モデルを動かすこと自体が条件に反する。しかも FLUX.1 の場合、モデルカードの要約だけを読むと誤読する構造になっている。本記事はまずそこから始める。

「商用利用できます」を2つに分けて読む
「非商用」の定義を読む
schnell という選択肢
ComfyUI が何をしているのか
API から叩いて量産する
長時間ジョブとして設計する
量子化でVRAMを下げる
秒数を比べるときの落とし穴
スタイルを固定するという発想
3Dプリントの仕事で何に使えるか
まとめ — ライセンスを先に、秒数は後で
出典・参考

忍者AdMax

「商用利用できます」を2つに分けて読む

FLUX.1 には2つの系統がある。そしてライセンスが根本的に違う。

系統	ライセンス	モデル自体の利用	生成物の利用
FLUX.1 [dev]	FLUX.1 [dev] Non-Commercial License	非商用に限定	商用可
FLUX.1 [schnell]	Apache 2.0	商用可	商用可

この表の1行目が問題になる。モデルの利用と生成物の利用が、別々の条項で扱われているからだ。

条文を見る。FLUX.1 [dev] のライセンス §2(b) はこう書かれている。「You may only access, use, Distribute, or create Derivatives of the FLUX.1 [dev] Model or Derivatives for Non-Commercial Purposes.」モデルへのアクセス、利用、配布、そして二次的な成果物の作成が、非商用目的に限定されている。

一方 §2(d) はこうだ。「You may use Output for any purpose (including for commercial purposes), except as expressly prohibited herein.」生成物は商用を含む任意の目的で使ってよい。

つまり、出てきた画像は売り物に使えるが、モデルを動かす行為そのものには制限がかかる。この2つを一体のものとして読むと、判断を誤る。

「非商用」の定義を読む

では非商用とは何か。§1(c) が定義している。直接的にも間接的にも支払いを受けない利用のことで、具体的には「公共の知識に資する研究・実験・テストのための個人利用」と、「営利企業による、非本番環境でのテスト・評価・非商用の研究開発」が含まれる。

営利企業でも該当しうる点は押さえておきたい。業務で評価するだけなら非商用の範囲に入る。

問題は除外規定のほうだ。§1(c) は次を明示的に除外している。

(a) 収益を生む活動のための利用
(b) エンドユーザーとの直接的なやり取り、またはエンドユーザーに影響を与える利用
(c) 商用目的で他のモデルを学習・ファインチューニング・蒸留するための利用

(a) が効いてくる。広告やアフィリエイトを含むサイトの画像を生成する用途は、収益を生む活動にあたりうる。評価のために動かすのと、収益のために動かすのとでは、扱いが変わるということだ。

なお商用ライセンスの道もある。§2(b) には「you must request a license from Company」とあり、権利者の裁量で付与され、費用・ロイヤリティ・レベニューシェアの対象になりうると書かれている。申請先は bfl.ai である。

筆者は法律の専門家ではないので、個別の用途がどちらに当たるかは断定しない。条文がこう書かれているという事実を提示するに留める。判断が必要なら、権利者に確認するか専門家に相談してほしい。

schnell という選択肢

収益を伴う用途で使うなら、選択肢は明快だ。FLUX.1 [schnell] のモデルカードにはこう書かれている。「Released under the apache-2.0 licence, the model can be used for personal, scientific, and commercial purposes.」

Apache 2.0 で、モデル自体を商用目的で使える。パラメータ数は12Bで dev と同じだ。論点そのものが消えるという点で、迷うくらいなら最初からこちらを選ぶ理由がある。

構造上の違いも押さえておきたい。schnell は公式が「can generate high-quality images in only 1 to 4 steps」と説明しており、公式のコード例は4ステップになっている。少ないステップ数で結果を出す設計だ。画質の優劣については、同条件の比較を自分でしていないので書かない。設計思想が違うので、同じ設定で比べること自体が適切でないからである。

ここは乗り換えるときの実務的な注意点にもなる。ステップ数の想定が違うモデルに切り替えるとき、設定をそのまま引き継ぐと結果が壊れる。4ステップ想定のモデルに50ステップを与えても、単に時間が10倍かかるだけで良くなるとは限らない。逆も同じで、多ステップ想定のモデルを4ステップで回せば出力は荒れる。モデルを替えたら、まずステップ数を公式の想定値に合わせる。これを忘れると「新しいモデルは品質が悪い」という誤った結論に着地する。

透明性のために書いておくと、当サイトの画像生成もこの確認を経て dev から離れた。アフィリエイトを含む以上、収益を生む活動にあたりうると判断したためだ。まず schnell へ移し、あわせてサンプリングのステップ数も公式の想定に合わせて変更した。ライセンスの確認が設定変更まで波及するという点は、実際にやってみないと見えにくい部分だろう。

その後さらに、Apache 2.0 の別系統である Z-Image-Turbo へ移している。理由はライセンスではなくメモリで、後述する実測のとおり schnell 構成では VRAM の使用率が9割を超えていた。ライセンスで選択肢を絞った後、その中で機材条件に合うものを選び直したという順序になる。この2段階は、意図せずして本記事の結論そのものを踏んでいる。

ComfyUI が何をしているのか

モデルが決まったら、動かす側を見る。ComfyUI の公式リポジトリは、自らを「The most powerful and modular AI engine for content creation」と説明している。中核は「コードを書かずに画像・動画・音声・3D・テキストのワークフローを構築し再利用するためのビジュアルなノードグラフ」だ。

ノードグラフ方式であることには実務上の意味がある。生成は単一の処理ではなく、モデルの読み込み、テキストの符号化、サンプリング、デコード、後処理という一連の工程だからだ。それぞれを箱として並べ、線でつなぐ。どの工程に何を差し込むかが目に見える。

この可視性は、うまくいかないときに効く。出力が期待と違ったとき、原因がプロンプトの解釈にあるのか、サンプリングの設定にあるのか、それとも後処理で潰れているのかを切り分けられる。1つの箱にすべてが詰まっている道具では、この切り分けができない。生成サービスを使っていて「なぜかうまくいかない」で止まる経験があるなら、その多くは工程が見えないことに起因している。

読み込める資産も公式に列挙されている。「complete checkpoints or separate diffusion models, VAEs, text encoders, LoRAs, ControlNets, adapters, and upscalers」。モデル本体と符号化器を別々に差し替えられる構成になっている点が、量子化版を使ううえで効いてくる。量子化されているのは拡散モデルの部分だけで、符号化器や VAE はそのまま使い回せるからだ。モデルを入れ替えるときに落とし直すファイルが1つで済む。

ライセンスは GPL-3.0 である。

API から叩いて量産する

ここが本題だ。画面を開いて1枚ずつ生成するのでは、記事12枚には向かない。

ComfyUI の公式説明には「Reusable subgraphs, workflow templates, App Mode, and a local API for integrating workflows into applications」とある。ローカルのAPIがあり、ワークフローをアプリケーションに組み込める。

組み込み方の骨格はこうなる。

画面上でワークフローを組み、API 用の形式で書き出す
書き出したものの中で、変えたい箇所をプレースホルダにする（プロンプト、シード、モデル名など）
生成のたびにプレースホルダを置換して投入する
完了を待って画像を取得する

この形にすると、記事の見出し一覧からプロンプトを生成し、まとめて投入するという流れが組める。1枚ずつ画面を操作する必要がなくなる。

メモリ管理についても公式に記述がある。「asynchronous queueing, partial graph re-execution, smart VRAM and RAM management, model offloading, and support for quantized models」。非同期のキュー投入に対応しているので、まとめて積んでおいて待つ形が取れる。

この一覧の中で実務的に効くのが partial graph re-execution だ。グラフの一部だけを再実行できるということは、プロンプトだけを変えたときにモデルの読み込みをやり直さないという意味になる。12枚を連続生成する場面では、この差が所要時間の大半を決める。毎回モデルを読み直す構成にしてしまうと、生成そのものより読み込みのほうが長くなる。

model offloading も押さえておきたい。VRAMに載りきらない分をシステムメモリへ退避する仕組みで、これがあるおかげでメモリの上限を少し超えても動く。ただし退避が発生した時点で速度は落ちる。動いているからといって適正な構成とは限らない。

長時間ジョブとして設計する

まとめて投入する形にすると、実行が長時間ジョブになる。ここには別種の注意が要る。

第一に、他のプロセスとGPUを取り合わないこと。言語モデルのサーバーを常駐させたまま画像生成を始めると、両方が遅くなる。当サイトでも、バッチ生成の前に常駐プロセスを止める手順を運用に入れている。同じGPUを複数の用途で使う構成では、同時実行しないという運用ルールのほうが、設定の最適化より効く。

第二に、途中で失敗したときの巻き戻し範囲を決めておくこと。94枚を1つのジョブにすると、80枚目で落ちたときに何が残るかが問題になる。1枚ごとにファイルとして保存される構成なら、失敗しても済んだ分は残る。逆に全部揃ってから書き出す設計だと、全損になる。

第三に、実行を切り離すこと。ターミナルのセッションに紐づけたまま長時間ジョブを走らせると、接続が切れた時点で終わる。バックグラウンドで独立して走る形にしておけば、待っている間に別の作業ができる。ローカル画像生成の実務では、この運用面の設計が品質と同じくらい効いてくる。

量子化でVRAMを下げる

12Bのモデルをそのまま載せるとメモリを食う。ここで量子化が効く。

schnell の GGUF 変換版は、量子化の度合いによってファイルサイズが大きく変わる。実際に配布されているファイルのサイズを挙げる。

形式	ファイルサイズ
F16	23.8 GB
Q8_0	12.7 GB
Q6_K	9.83 GB
Q5_K_S	8.26 GB
Q4_K_S	6.78 GB
Q3_K_S	5.21 GB
Q2_K	4.01 GB

F16 の 23.8 GB は、一般的な民生GPUには載らない。Q5_K_S の 8.26 GB まで落とせば、16GB のGPUで余裕を持って扱える。量子化は画質のための妥協ではなく、載せるための必須手段だと考えたほうが実態に近い。

ここで注意すべきは、画像生成ではモデル本体以外にもメモリを使う点だ。テキスト符号化器と VAE が別に載る。ComfyUI が完成品のチェックポイントとは別に「separate diffusion models, VAEs, text encoders」を読み込める構成になっているのは、この分離があるからである。つまり、GGUF のファイルサイズだけを見て「載る」と判断すると足りなくなる。符号化器と VAE の分を足したうえで、生成中の作業領域も見込む必要がある。

選び方の目安としては、空きメモリの6割程度に収まるファイルサイズを選ぶところから始めるのが安全だ。動いたうえで余裕があれば、上の形式に上げていけばよい。

テキストモデルの量子化と考え方は同じで、その仕組みは手元のVRAMで動くモデルを見積もる（2026-08-25 公開）で扱った通りである。名前の数字と実ビット数がずれる点も共通する。

秒数を比べるときの落とし穴

所要時間の話をする。条件を書ける形で実測した。機材は NVIDIA GeForce RTX 5070 Ti、VRAM は16GB（16,303 MiB）。出力は1280×720である。

構成	ステップ	1枚あたり	VRAM ピーク
schnell Q5_K_S ＋ T5XXL fp8	4	約7秒	15,416 MiB（94.6%）
Z-Image-Turbo Q6_K ＋ Qwen3-4B fp8（2パス＋拡大縮小）	9×2	約28秒	13,411 MiB（82.3%）

この表から2つ読み取れる。ひとつは、秒数を支配しているのはステップ数だということ。4ステップと9ステップ2パスでは4倍の差がつく。同じ機材でもステップ数を変えれば所要は比例して動く。

したがって、ステップ数を併記しない生成秒数は比較に使えない。ネット上の「何秒で生成できた」という報告を読むときは、まずステップ数を探すべきだ。それが書かれていなければ、その数字は自分の判断材料にならない。同じ理由で、この表の秒数もGPUの型番と出力解像度を併記して初めて意味を持つ。

もうひとつが VRAM だ。schnell 構成は16GBのうち15.4GBを使い、ピーク時の空きが890MiBしかなかった。この状態では生成中にデスクトップ全体が重くなる。モデル本体8.26GBに加えてテキストエンコーダのT5XXLが約4.9GB載るためで、モデルを小さくするだけでは解決しない構造になっている。テキストエンコーダの取り替えまで含めて構成を見直す必要があった。

ここが機材選定と直結する。ライセンスで選択肢を絞ったうえで、手元のメモリに収まるかどうかで最終的に決まる。画像生成では特に、テキストエンコーダの分を見落としやすい。モデルのファイルサイズだけを見て「16GBなら載る」と判断すると、実際には載っても余裕がない状態になる。

スタイルを固定するという発想

量産するときに効いてくるのが、出力の揃え方だ。記事12枚がバラバラの雰囲気だと、読み物として成立しない。

手段は2つある。ひとつはプロンプトの共通部分を固定すること。配色、構図の方針、禁止事項を全プロンプトに同じ文言で入れる。当サイトの画像プロンプトも、スタイル指定の一文を全セクションで共有する形にしている。

もうひとつが LoRA だ。ComfyUI の公式説明にも読み込める資産として挙げられている。特定のスタイルを学習させた小さな追加データを、モデルに重ねて使う。プロンプトだけでは揃いきらない領域を、こちらで吸収できる。

ただし注意点がある。LoRA を作る場合、元モデルのライセンスが二次的な成果物にも及ぶ。FLUX.1 [dev] の §2(b) は「create Derivatives」も非商用の範囲に置いている。スタイルを学習させて商用に使う計画があるなら、この点も含めて元モデルを選ぶことになる。

プロンプト側の固定については、もう少し具体的に書いておく。当サイトの画像プロンプトは、ファイル冒頭に共通のスタイル指定を1行置き、各セクションのプロンプトはその指定を前提に書く形にしている。指定に含めているのは、配色、イラストの様式、背景の扱い、余白の取り方、そして文字を描き込ませない指示だ。

最後の項目は地味だが重要で、生成モデルは頼まなくても看板や見出しらしきものを描き込む。そして描かれた文字はたいてい崩れている。日本語ならなおさらだ。文字は後から重ねるという前提に切り替えると、この問題は構造的に消える。当サイトも、画像の上に見出しを重ねる処理を生成とは別工程に分けている。

3Dプリントの仕事で何に使えるか

生成した画像の使い道を、モノづくりの側から挙げる。

商品写真の補助が最も直接的だ。実物の撮影は必要だが、背景の作成やイメージカットは生成でまかなえる。撮影環境を持たない個人にとって、この差は小さくない。この領域の考え方は「映え」は計算できる（2026-03-19 公開）で扱っている。

説明図にも使える。組み立て手順やパーツの位置関係を示す図は、写真より図解のほうが伝わることが多い。ただし寸法を含む正確な図面は生成に向かない。生成が得意なのは雰囲気であって、精度ではないからだ。

販売ページのバナーも用途に入る。ここで冒頭のライセンスの話が効いてくる。販売ページは明確に収益を生む活動なので、モデル選びの段階で条件を確認しておく必要がある。データやモノを売る話は3Dプリントで何を売るかを先に決める（2026-08-17 公開）で整理した通りだ。

逆に、生成に向かない用途もはっきりさせておきたい。寸法が意味を持つ図は生成の対象外である。組立図で「ここは3mm」と示したいなら、それはCADか作図ツールの仕事だ。生成モデルは「それらしい図」を作るのが得意で、正確な図を作るのは得意ではない。ここを混同すると、読者に誤った寸法を伝えることになる。

もうひとつ、実物の代替にはしないという線も引いておきたい。売り物の外観を生成画像で示すのは、実物と違えば表示の問題になる。生成が担えるのは、実物写真の周辺にある補助的な画像までだ。この線引きを最初に決めておくと、後から作り直す手間がなくなる。