ローカル画像生成AIはGeminiの代わりになるか？——FLUX・Qwen-Image・Playground v2.5を商用利用前提で実機比較した
この記事で分かること
- クラウドの画像生成API（Gemini）をローカルAIモデルに置き換える検討を、なぜ・どう進めたか
- 商用利用の前提で外せない「ライセンス」の見極め方
- FLUX-schnell / Qwen-Image / Playground v2.5、ローカル3モデルを同一プロンプトで実機比較した結果
- 用途（スタイル）によって最適なモデルが変わるという結論
- 導入前に知っておくべき運用コスト（コールド起動・VRAM）
はじめに
以前の記事「公開ベンチマークだけでLLMを選んでいませんか？——判別力のある評価テストを自作する方法」で、テキスト生成AI（LLM）をローカルとクラウドのどちらで運用すべきかを実測で検証しました。今回はその画像生成版です。
Amanityでは、ブログのヒーロー画像やOGP画像の生成にクラウドの画像生成API（Gemini）を使っています。品質は安定していますが、生成のたびにAPI課金が発生し、生成量が増えるほどコストが積み上がる構造です。「この画像生成業務は、自社の検証用GPUマシン（RX 7900 XTX 24GB）でローカルモデルに置き換えられないか」という問いから、今回の検証が始まりました。
結論から言うと、「Geminiを完全にローカルへ置き換える」という単純な話にはなりませんでした。 ただし、用途によっては明確にローカルのほうが良い場面があることも分かりました。この記事では、その判断に至った実測データと、商用利用する上で必ず押さえるべきライセンスの注意点を共有します。
まず結論——「全置き換え」ではなく「スタイルで使い分け」
先に全体像を示します。
| モデル | 品質 | 文字描画 | 速度（ウォーム時） | ライセンス | 位置づけ |
|---|---|---|---|---|---|
| Qwen-Image | 最良 | ○ 正確 | 約130秒/枚（遅い） | Apache-2.0 | 品質重視の本命 |
| FLUX-schnell | 良 | × 崩れる | 約16〜24秒/枚 | Apache-2.0 | 高速・イラスト/ミニマル向き |
| Playground v2.5 | 良（盛る傾向） | × 崩れる | 約7秒/枚（最速） | 条件付き商用可 | 写実・プレミアム向き |
| Gemini（現行） | 良（安定） | △ | クラウドAPI | ー | 現行のベースライン |
4モデルとも一長一短で、「これ1つですべて解決」というモデルはありませんでした。詳しい根拠は以降で説明しますが、実務的にはスタイル・用途ごとにモデルを使い分けるのが最も合理的だという結論です。
なぜローカル画像生成AIを検討したのか
現行業務の課題
自社のブログ記事では、記事ごとにヒーロー画像・OGP画像を1〜2枚生成しています。現行は共通プロセス（社内のヒーロー画像生成フロー）に沿って、Geminiにスタイル別のプロンプトテンプレート（Corporate Memphis・Glassmorphism・Dark Techなど）を投げて生成しています。
品質面での不満はほとんどありません。課題は生成のたびに発生するAPI課金です。記事の本数が増えるほど、そして試行錯誤（気に入る構図が出るまで複数回生成する）が増えるほど、コストは線形に積み上がります。
クラウドAPI依存という制約
もう1つの観点は、外部サービスへの依存度です。API仕様や料金体系の変更は自社ではコントロールできません。生成頻度が低いうちは問題になりませんが、生成量が増えるフェーズを見据えると、少なくとも一部の用途だけでもローカルで完結できる選択肢を持っておきたい、というのが検討の出発点でした。
商用利用の前提——「無料でDLできる」と「商用利用できる」は別問題
ローカル画像生成AIを検討する上で、最初につまずきやすいのがここです。
重要な前提: 画像生成AIの実行環境（diffusers・ComfyUI等）自体は無料でも、生成した画像を商用利用できるかどうかはモデルのライセンス次第です。オープンソースとして重みが公開されているモデルでも、商用利用が無条件で許可されているものもあれば、用途や再配布に条件が付くものもあります。「ダウンロードできた＝商用利用OK」ではありません。
実務での鉄則は、利用前にモデルカード（配布ページのライセンス記載）を必ず読み、商用案件では確認した条件を記録しておくことです。今回検証した3モデルのライセンスは次の通りでした。
| モデル | ライセンス | 商用利用 |
|---|---|---|
| FLUX-schnell | Apache-2.0 | 可（無条件） |
| Qwen-Image | Apache-2.0 | 可（無条件） |
| Playground v2.5 | Playground v2.5 Community License | 条件付きで可 |
FLUX-schnellについては1つ注意が必要です。公式配布リポジトリは利用規約への同意と認証トークンが必要な「ゲート付き」の状態になっています（ライセンス自体はApache-2.0のままです）。今回は、この規約に同意した上で配布されている非ゲートの正規な再配布版を利用しました。「ライセンス表記」と「実際に無認証でダウンロードできるか」は別のレイヤーの話なので、両方を確認する必要があります。
Playground v2.5は、Apache-2.0ほど無条件ではなく、Playground v2.5 Community Licenseという独自ライセンスの条件を満たす必要があります（画像生成・編集がコア事業で月間ユニークユーザー数が一定規模を超える場合などに条件が付きます。詳細は配布元の最新のライセンス文を都度確認してください）。商用案件でこのモデルを使う場合は、条件を社内でドキュメント化しておくことを推奨します。
検証方法——同一プロンプト・同一条件で4モデルを比較する
比較の軸は次の4つに絞りました。
- プロンプト忠実度——指示した要素がちゃんと描かれるか
- スタイル一致——自社のトンマナ（Corporate Memphis等）にどれだけ寄せられるか
- 速度・VRAM——実務で使える生成コストか
- 商用ライセンス——そもそも使ってよいか
検証対象は、自社のヒーロー画像で使っているイラスト系スタイル（Corporate Memphis・Glassmorphism・Dark Tech・Minimal Flatなど）と、汎用的な実写系スタイル（ポートレート・商品写真等）を含む、複数スタイルのプロンプトカタログです。Geminiで生成した既存のヒーロー画像を基準に、同一プロンプト・同一被写体でローカル3モデルに生成させ、4枚並べて見比べるという単純な方法を取りました。
結果1: スタイル別の得意・不得意がはっきり分かれた
実用対象とした3スタイル（Glassmorphism・Dark Tech・Minimal Flat）を4モデルで横並びに比較すると、スタイルごとに驚くほどはっきりと得意・不得意が分かれました（各行の緑枠が、そのスタイルでの最有力モデルです）。
Qwen-Imageが最良——特に画像内の文字描画
4モデルの中で最も総合品質が高かったのがQwen-Imageです。特に際立っていたのが画像内の文字描画の正確さです。
Dark Tech系（回路基板の上にチェックリストやバイナリ表記を載せるスタイル）で顕著でした。他のローカル2モデルは画像内の文字（チェックリストのラベルや「0101…」のようなバイナリ表記など）がほぼ確実に崩れるのに対し、Qwen-Imageは指定した文字列を潰さずに描画できました。ロゴやラベル・数値など、画像内にテキストを載せたいヒーロー画像では明確な優位があります。
弱点は速度です（詳細は結果3）。
FLUX-schnellは高速・イラスト/ミニマルが得意、文字は崩れる
FLUX-schnellは、ガラス質感の描写（Glassmorphism）やダークテック系のアイソメトリック表現で、Geminiと同等かそれ以上の品質を出せる場面がありました。ミニマルなフラットデザインも綺麗に出ます。
弱点は画像内の文字描画で、チェックリストのラベルやバイナリ表記はQwen-Imageに比べて崩れがちです。テキストを載せないビジュアルであれば、高速さと品質のバランスが最も良いモデルです。
Playground v2.5は最速だが「盛る」傾向——写実は強いがミニマルは苦手
Playground v2.5は生成速度が圧倒的に速く、実測で最速でした。人物表現がリッチで、写実寄りの表現やプレミアム感のあるビジュアルを得意とします。
一方で、「ミニマル」という指示を無視して描き込みすぎる傾向が顕著でした。Minimal Flatスタイルを指示しても情報量の多い絵になりがちで、この用途には最も不向きという結果になりました。Glassmorphismも写実寄りに寄りすぎ、ガラスのクリーンな質感はFLUXのほうが得意でした。
まとめると
| スタイル傾向 | 向いているモデル |
|---|---|
| 人物のプレミアム感・写実 | Playground v2.5 |
| ミニマル・フラット・イラスト調・ガラス質感 | FLUX-schnell |
| 画像内の文字描画・総合品質（Dark Tech等） | Qwen-Image |
単純な上位互換は存在しません。 各モデルの「得意」が明確に逆方向を向いているため、用途に応じた使い分けが実務上もっとも合理的だと判断しました。
結果2: 「Geminiと全然違う」の正体はモデルの実力差ではなかった
検証の初期段階で、Corporate Memphisのローカル生成結果が「Geminiの既存ヒーロー画像と全然違う」という問題に直面しました。人物が主役になったにぎやかな構図になり、狙っていたフラットで落ち着いたトーンから大きく外れていたのです。
最初は「ローカルモデルの実力不足」を疑いましたが、原因を調べるとモデルの実力差ではなく、プロンプトの構造（構図の指示）そのものが違っていたことが分かりました。
Geminiで生成している既存のヒーロー画像は、社内の正式なスタイルテンプレートに沿って「大きなメインオブジェクトを中心に配置し、その周りに小さな人物を添える」という構図を明示的に指示しています。人物は主役ではなく脇役です。
一方、検証用に用意していたテストプロンプトは「複数人の人物が主役として作業している場面」という、まったく別の構図を指示していました。これでは同じスタイル名（Corporate Memphis）を指定していても、出てくる絵が違うのは当然です。
そこで、正式なスタイルテンプレート（メインオブジェクト中心＋周囲に小さな人物という構図）を使って再生成したところ、「Geminiと全然違う」と感じた見た目のズレの大半は解消し、構図はGeminiに揃えられました。 上の図の左（Gemini）と右（構図を揃えたローカル生成）は、狙っている方向性がかなり近づいています。
ただし正直に補足すると、Corporate Memphisというスタイル自体は、構図を揃えてもローカル3モデルではGeminiほど安定した品質に届きませんでした（人物のプロポーションや線の均一さにばらつきが残ります）。そのため今回は、Corporate Memphisはローカルの推奨スタイルからは外し、Glassmorphism・Dark Tech・Minimal Flatを実用対象として扱う判断をしています。
それでも、この一件から得られた実務上の教訓は重要です。
モデル間の見た目の差を評価する前に、まず「同じ構図を指示しているか」を疑う。 プロンプトの構造が違えば、モデルの実力に関わらず結果は一致しません。ローカルモデルへの置き換えを検証する際は、既存のスタイルテンプレートをそのまま流用し、被写体だけを差し替えるのが安全です。
結果3: 実務コストは「速度」だけでは測れない
コールド起動という見落としがちなコスト
ウォーム状態（モデルをロード済みの状態）での生成速度は前述の通りですが、初回だけ極端に時間がかかるという特性が3モデル共通で見られました。
| モデル | コールド起動（初回のみ） | ウォーム時（2枚目以降） |
|---|---|---|
| FLUX-schnell | 約18〜21分 | 約16〜24秒/枚 |
| Qwen-Image | 約20分（DL・ロード込み） | 約130秒/枚 |
| Playground v2.5 | 約25分 | 約7秒/枚 |
FLUX-schnellを例にすると、2回目以降の生成が20〜30秒程度で終わるのに対し、プロセスを起動して最初の1枚を生成するだけで18分以上かかります。原因を調べたところ、GPU側の計算カーネルを初回だけ最適化コンパイルする処理（利用環境特有の初回JITコンパイル）が主因で、モデルを変えても消えない「環境側の税金」のようなコストだと分かりました。しかも、このコンパイルはプロセスを再起動するたびに再び発生します。
実務上の結論はシンプルです。「都度プロセスを起動して1枚だけ生成する」運用は非現実的で、モデルをロードしたまま複数枚をバッチ処理する、あるいは常駐させて使う、という運用でなければコールド起動のコストを吸収できません。低頻度利用であれば「1セッションにつき1回のコールド起動は許容する」という前提で運用するのが現実的です。
VRAMは複数サービスとの共存に注意が必要
もう1つ、運用面での注意点があります。今回使用したFLUX-schnellとQwen-Imageは、GPUメモリが足りない部分をCPU側に逃がす仕組み（CPUオフロード）を使っており、VRAM使用量を必要な分だけに抑えられます。一方Playground v2.5は、モデル全体をVRAMにフル搭載する方式です。
同一GPU上で他の常駐AIサービス（例えばローカルLLMの推論API等）を並行稼働させている場合、VRAMをフル確保するタイプのモデルは、空き容量不足で起動に失敗することがあります。 CPUオフロード型のモデルは専有量が少なく、他サービスと共存させやすいという違いがあるため、GPUを複数用途で共有する構成を検討している場合は、この違いを踏まえてモデルを選ぶ必要があります。
商用ライセンスの実務チェックリスト
ここまでの内容を、導入前に確認すべきチェックリストとしてまとめます。
- モデルカード（配布ページ）でライセンス条件を確認したか
- 「重みが公開されている＝商用利用可」と早合点していないか
- ライセンス表記と、実際にダウンロードできる配布経路（ゲートの有無）を両方確認したか
- 条件付き商用可のライセンス（利用規模制限等）の場合、条件を社内で記録したか
- 既存キャラクター・ロゴ等に類似した生成物を大々的に商用利用していないか（ライセンス上問題なくても意匠権・著作権のリスクは別途残る）
まとめ——結論は「使い分け」
冒頭で述べた通り、Geminiをローカルモデルに全面的に置き換える、という単純な結論にはなりませんでした。 その代わりに得られたのは、用途ごとの明確な判断軸です。
- 品質・文字描画を重視するなら Qwen-Image（生成が遅くても許容できる、低頻度な用途向き）
- 大量・高速に生成したいなら FLUX-schnell（イラスト・ミニマル系のスタイルと相性が良い）
- 写実・プレミアムな質感が欲しいなら Playground v2.5（最速だが、ミニマル系スタイルには不向き）
- 安定運用を優先するなら 引き続きGeminiを併用する選択肢も残る
また、ローカルモデルへの置き換えを検証する際は、モデルの実力を評価する前にプロンプトの構図が既存のスタイルテンプレートと揃っているかを必ず確認することも、今回の検証から得られた重要な教訓です。
今後は、現行業務で実際に使っている「背景だけ後から追加する」といった画像編集（img2img）の再現度についても検証を進める予定です。この記事がローカル画像生成AIの導入を検討している方の判断材料になれば幸いです。
関連記事
