ローカル画像生成スタックの現在地 — 商用OKモデルの選び方とMacの落とし穴
この記事について
メディア運営で使う記事画像を、外部の従量課金APIからローカル生成（ComfyUI）へ全面的に寄せた構成の棚卸しだ。
要点は三つ。モデルはクオリティより先にライセンスで選んだこと、Apple Silicon（Mac）には他プラットフォームで踏まない地雷が二つあること、そして「ローカルにやらせない」と割り切った領域を先に決めたこと。 個人開発者や小規模メディアで「画像コストを月ゼロにしたいが商用利用でつまずきたくない」という向けに、選定の判断基準と、実際に踏んだ落とし穴を書く。
試した環境: Apple Silicon 64GB機上の ComfyUI（ローカルサーバ localhost:8188）。スタック総量はモデル込みで約60GB。生成は自作の gen ラッパー経由で回している。
モデルはライセンスで決めた — 似た名前が別ライセンスという罠
画質で選ぶと足をすくわれる。メディアの記事画像は商用利用なので、まず「商用可のライセンスか」で足切りしてから画質を見る。 採用したのは次の3本で、いずれも商用利用できるものに絞った。
| モデル | ライセンス | 生成時間の目安 | 得意領域 |
|---|---|---|---|
| Z-Image Turbo | Apache 2.0（商用可） | 約29秒 | 万能・第一候補。写実／アニメ／静物すべて |
| Flux.2 Klein 4B | Apache 2.0（商用可） | 約23秒 | 実写の人物・物撮りの自然な質感 |
| Animagine XL 4.0 | OpenRAIL++（商用可） | 約42秒 | アニメ全般。タグ式で28step |
一番の地雷は名前が近いのにライセンスが違うモデルが混在することだ。ラッパーのエイリアスで言うと、anima は商用可の Animagine XL 4.0（＋高速化用の蒸留を乗せた8step版）を指すが、一文字違いの animanc は別物の非商用モデルを指す。後者は素の手が綺麗で個人評価用には手放したくないが、非商用ライセンスなので記事には一枚も使えない。エイリアスが一文字しか違わないので、非商用モデルを商用配信してしまう事故が容易に起きる。ここは「商用枠と評価専用枠を別コマンドに分け、非商用側は起動時に注意文を自動表示する」という運用でガードした。
# 記事用（商用可）はこの3本のどれかだけを使う
gen z "prompt" # Z-Image Turbo（万能・第一候補）
gen klein "prompt" # Flux.2 Klein（実写・物撮り）
gen anima "prompt" # Animagine XL 4.0（和アニメ・タグ式）
# animanc は非商用。記事に使わない（評価専用）
Macの落とし穴その一 — fp8が動かない
配布モデルには軽量化のため fp8（8bit浮動小数）版が出ていることが多い。ダウンロードサイズも小さく一見お得だが、Apple Silicon の演算バックエンド（MPS）は fp8 演算を実質サポートしていない。fp8単体の重みを掴むと動かないか破綻する。
結論はシンプルで、ローカルは必ず bf16 かGGUF量子化を使う。fp8版が公式に出ていても掴まない。上のKleinもfp8版はMPSで動かず、bf16のフル版を使っている。ダウンロードは接続が切れやすいので、ブラウザ任せにせずターミナルから直接、レジューム付きで落とすのが安定した。
Macの落とし穴その二 — 真っ黒画像（NaN）が間欠で出る
生成結果がたまに真っ黒の一枚になる。中身が数値的に発散（NaN）した結果で、Apple Silicon 環境の持病に近い。厄介なのは毎回ではなく間欠で出ることで、切り分けに時間を取られた。
犯人を切り分けた結果はこうだった。
- 最大の引き金は高解像度化（hires fix）。蒸留を使わない清書用の設定でも、
1216×832 + hiresは2回連続で真っ黒になった。同じサイズでも hires を外せば正常に出る - 蒸留を乗せた高速版でも間欠で黒が出る。清書は蒸留なしの28step版に寄せると黒はほぼ消える
対処は泥臭い。ラッパー自体には自動再試行を入れていないので、生成直後に黒画像を検出して、シードを変えて振り直す運用にした。真っ黒画像は一様な塗りつぶしなので出力ファイルサイズが極端に小さくなる。これを閾値で弾けば、目視しなくても機械的に検出できる。ワイド比で描き込みたいときは hires に頼らず、素のstepで解像度そのものを上げるほうが安全だった。
ローカルにやらせないと決めた領域
全部ローカルに寄せたが、最初から手を出さないと決めた領域が二つある。ここを無理にローカルで押し切ると品質が崩れる。
- 日本語の文字入り画像。ローカルの全モデルで漢字が崩れる（Qwen系でも崩壊した）。文字入れが要るバナー類は、生成そのものはローカルでやらず、文字は後工程（クラウドの画像生成AIや手作業の合成）に分離した
- 食べ物のビジュアル。料理・麺類はローカルが弱く、ラーメンを描かせるとうどんのような質感に化けた。食べ物が主役の画像はクラウドに外注したほうが早い
ローカルが強いのは人物キャラ・小物・抽象イメージ。「文字なしビジュアルの商用量産機」と役割を割り切ったことで、無理筋な期待で時間を溶かさずに済んだ。
やってみてわかったこと
ローカル画像生成を実運用に乗せる勘所は、画質のベンチマークではなく**「ライセンス」「動くプラットフォームか」「そもそもローカルに向くお題か」の三つを先に固定する**ことだった。商用可のモデルに絞り、Apple Silicon では bf16／GGUFだけを掴み、文字と食べ物は最初からクラウドに投げる。この3点を運用ルールに落とした瞬間、月あたりの画像コストは従量課金からほぼゼロになり、記事の起稿と同時に画像が付くようになった。ローカル生成の失敗の大半は、モデルの実力ではなく「使ってはいけないモデル・環境・お題」を選んだことに起因する、という回だった。
更新履歴
- 2026-07-08: 初稿