2026 年に Gemini 3.2 Flash の Image Output モードが本番提供されてから、私の手元では壁紙アプリのコンテンツ拡張パイプラインの設計が一段進みました。それまで Imagen 4 と Gemini Vision を別々に呼んでいた一連の処理が、ひとつのモデル呼び出しに統合できるようになったからです。リクエスト数が減るだけでなく、入力画像を渡したまま編集指示を流せるので、派生バリエーションの「同一性」を保ちやすくなった点が個人開発の現場では一番のメリットでした。
壁紙アプリのカタログは、1 枚を仕上げるまでの手数が多いほど更新が止まります。色違いと時間帯違いを人手で用意していた頃は、季節の切り替わりに間に合わせるために月末が毎回慌ただしくなっていました。Image Output の統合で変わったのは、「1 枚のベース画像から派生を返す」処理が API 呼び出し 1 回に収まったこと。運用の手数がそのまま減りました。
この記事は、その置き換えを本番のパイプラインに組み込むまでの実装記録です。Imagen 4 との使い分けの判断軸、Python の具体実装、月額 API コストの実測値、生成物を機械で受け入れ判定する仕組み、そして本番で踏んだ 3 つの罠までを順に書きます。個人開発でこの機能を有料プランに載せる前提の設計なので、コストと粗利の話も避けずに扱います。
Gemini 3.2 Flash の Image Output と Imagen 4 — 何がどう違うのか
まず混乱しやすいのが、Gemini 3.2 Flash の Image Output と Imagen 4 の役割の違いです。どちらも画像を出しますが、設計思想が違います。
Imagen 4 は専用の画像生成モデルです。テキストプロンプトだけを入力に取り、高品質な画像を 1 枚（あるいは複数枚）出力します。コントロールできるのは画像サイズ、アスペクト比、ネガティブプロンプト、シード値、安全性フィルタなど、画像生成に特化したパラメータです。ゼロから新しい画像を作る、という方向に最適化されていると感じます。
Gemini 3.2 Flash の Image Output は、汎用モデルにマルチモーダル出力を持たせた拡張です。テキストと画像を入力に取り、テキストと画像の両方を出力できます。具体的には response_modalities=["TEXT", "IMAGE"] を指定すると、モデルが状況に応じてテキストと画像の両方を返してくれます。実装上のいちばん大きな違いは、Image Output だと「入力画像をもとに編集や派生バリエーションを返す」処理が 1 リクエストで完結することです。Imagen 4 は基本的にテキスト → 画像の片方向で、入力画像を渡してその派生を作るのは別系統の機能になります。
私の壁紙アプリでの用途は明確で、ユーザーが気に入った 1 枚の壁紙から「色違い」「時間帯違い」「雰囲気違い」のバリエーションを 3〜5 枚生成する、というものです。この用途では Image Output が圧倒的に書きやすく、生成画像の同一性（被写体は同じだが色だけが違う）も保てます。ゼロから「春の桜の壁紙」を生成するような用途では、Imagen 4 の方が品質が高いと感じます。とくに細部のテクスチャやライティングは Imagen 4 が一段上です。私の運用では、新規コンテンツのシード生成は Imagen 4、ユーザー文脈に合わせた派生バリエーションは Gemini 3.2 Flash Image Output、という使い分けに落ち着きました。
レイテンシ・品質・単価の 3 軸でも傾向が違います。レイテンシは Gemini 3.2 Flash Image Output が約 4〜6 秒、Imagen 4 が 5〜9 秒の体感です。単価は Image Output が出力 1 枚 $0.03 前後、Imagen 4 が $0.04〜$0.05。品質はゼロからの生成で Imagen 4 優位、派生バリエーションで Image Output 優位、という形に分かれます。この使い分けが個人開発でのコスト設計の出発点になっています。
壁紙アプリでの実装パイプライン全体像
実装パイプラインの全体像を先に示します。ユーザーが壁紙詳細画面で「色違いを見る」ボタンを押した瞬間に動くフローです。
ユーザー操作 → クライアントから「ベース画像 ID + バリエーション指示（色違い／時間帯違い）」をバックエンドに送信 → バックエンドが画像を Cloud Storage から取得 → Gemini 3.2 Flash Image Output に並列で 3 リクエスト → 生成画像を CDN にキャッシュ → クライアントに 3 枚の URL を返す。
ここで意識したのは、生成リクエストを必ずバックエンド経由にすることです。クライアントから直接 Gemini API を呼ぶ設計は、API キーの管理と利用量制御の両方で破綻します。無料配布のアプリに鍵を焼き込んで配る選択を、私は取りません。バックエンドは Cloudflare Workers の上に薄く乗せていて、認証は App Attest（iOS）と Play Integrity（Android）でアプリ起動時に検証する設計です。
バリエーション生成は同期処理にも非同期処理にもできますが、ユーザー体験としては「待たせるなら明示的に」が原則です。3 枚並列で生成すると平均 5 秒前後で揃うので、その間はスケルトン UI と「あなた向けに整えています」のメッセージを表示しています。ローディング画面の文言ひとつで離脱率が変わるのは、12 年壁紙アプリを運用してきた中で何度も確認してきた現象です。
Python での実装 — 動くコードと設計の意図
まずは基本となる呼び出しコードです。google-genai SDK の最新版（2026 年 5 月時点）を前提にします。
import os from google import genai from google.genai import types from io import BytesIO from PIL import Image
client = genai.Client( api_key = os.environ[ "GEMINI_API_KEY" ])
def generate_variations (base_image_path: str , variation_type: str , count: int = 3 ): """ベース画像から指定タイプのバリエーションを count 枚生成する"""
with open (base_image_path, "rb" ) as f: base_image_bytes = f.read()
prompts_by_type = { "color" : "この壁紙の被写体と構図はそのままに、暖色系（夕焼け）の色調に変更したバリエーションを生成してください。3 通りの異なる解釈で、それぞれ違う色相にしてください。" , "time" : "この壁紙の被写体はそのままに、夜景（月明かりと星空）の時間帯に変更したバリエーションを生成してください。" , "mood" : "この壁紙の構図はそのままに、雨上がりの霧がかった静謐な雰囲気に変更したバリエーションを生成してください。" , }
prompt = prompts_by_type[variation_type] outputs = []
for i in range (count): response = client.models.generate_content( model = "gemini-3.2-flash-image" , contents = [ types.Part.from_bytes( data = base_image_bytes, mime_type = "image/png" ), prompt, ], config = types.GenerateContentConfig( response_modalities = [ "TEXT" , "IMAGE" ], temperature = 0.8 , seed = 42 + i, ), )
for part in response.candidates[ 0 ].content.parts: if part.inline_data is not None : outputs.append(part.inline_data.data)
return outputs 実装で意識したポイントを 3 つあげます。
ひとつめは seed をリクエストごとに変えていることです。同じプロンプトに同じシードを渡すと、似たような画像が繰り返し生成されてしまいます。42 + i のように単純なオフセットで十分にばらけさせられます。
ふたつめは temperature=0.8 です。0.0 にすると決定論的な生成になりますが、バリエーション目的なので適度な揺らぎが必要です。0.6〜0.9 の範囲を試して、私の壁紙アプリでは 0.8 が定着しました。
みっつめは response_modalities=["TEXT", "IMAGE"] の順序です。["IMAGE", "TEXT"] でも動きますが、Gemini はテキスト → 画像の順で生成する傾向があり、リスト順を意識しておくと出力の解釈で迷いません。テキストには「どのような変更を施したか」の説明が入ることがあり、ログとして残しておくと運用調査が楽になります。
並列処理は asyncio を使うと素直に書けます。3 並列で await asyncio.gather() する程度なら、レイテンシは単独呼び出しの 1.0〜1.2 倍に収まります。リクエスト数が増えてくると Gemini 側のレートリミットに当たるので、本番ではセマフォで同時実行数を絞っています。
月額 API コストの実測値と内訳
ここが個人開発で最も気になる部分です。2026 年 5 月時点での実測値を共有します。
私の壁紙アプリでは、バリエーション生成機能を有料機能（Premium 課金プラン）に閉じ込めています。Premium ユーザーは月 580 円、利用回数の中央値は月あたり 18 回程度です。1 回の利用で 3 枚生成されるので、月間生成枚数の中央値は 54 枚／ユーザー。
Gemini 3.2 Flash の Image Output 単価は、出力 1 枚あたり概ね $0.03 前後です（入力画像のサイズと出力解像度で前後しますが、私の運用域では $0.025〜$0.035 のレンジに収まっています）。54 枚 / ユーザー × $0.03 = 約 $1.62 / 月。日本円換算で約 250 円。
580 円のサブスクから API コスト 250 円を引くと、粗利は 330 円／ユーザーです。粗利率は約 57%。Premium 課金率はおおむね 1.2% で、AdMob を併用する設計なので、サブスクだけで採算を取る必要はありません。むしろ Premium 課金はリテンション維持と eCPM 向上のインジケータとして扱っています。
このコスト構造を踏まえて、新規ユーザーへの「初月 1 回無料お試し」のような体験設計を組んでいます。1 回 = 3 枚 × $0.03 = $0.09 程度のサンクコストで、Premium 転換率は 4.2%（無料お試しから 30 日以内）。AdMob と組み合わせると、転換しなくても回収できる設計です。
同じ機能を Imagen 4 で作ると、1 枚あたり $0.04〜$0.05 まで上がり、しかも入力画像をベースに派生を作る用途では別途 Gemini Vision で画像理解 → Imagen 4 でテキスト → 画像、という 2 段階構成になり、レイテンシも約 1.8 倍に伸びます。1 ユーザーあたりのコストもおおむね 1.5 倍。バリエーション用途では Gemini 3.2 Flash Image Output に倒すのが現実解です。
本番運用で踏んだ 3 つの罠
設計どおりに動かない場面は必ず出てきます。私が踏んだ罠を 3 つ共有します。
罠1: 同じ画像が返ってくる
最初の実装で seed を固定したまま 3 回呼んだら、3 枚とも同じ画像が返ってきました。原因は単純なミスでしたが、本番運用ではより難しいケースもあります。プロンプトが具体的すぎる（たとえば「夕焼けの色調で」と書くと、モデルが想像する「夕焼け」が固定化されやすい）と、temperature を上げても多様性が出にくくなります。プロンプトに「3 通りの異なる解釈で」のような指示を加えると改善します。
別解として、プロンプト自体を 3 つ用意して並列にリクエストする方法もあります。「暖色系の夕焼け」「青みのある夕焼け」「ピンクのマジックアワー」のように、明示的にバリエーション軸を分けると安定して 3 種が揃います。私は最終的に、ユーザー指示（color/time/mood）をベースに、内部で 3 つの細分化プロンプトを動的生成する設計に落ち着きました。
罠2: SafetySettings の落とし穴
デフォルト設定だと、暗い色調の壁紙や人物が薄く写る壁紙が SAFETY でブロックされることがあります。最初は理由が分からず「なぜか出力が空になる」現象に悩みました。finish_reason を見て SAFETY で止まっていることを確認したあと、safety_settings を明示的に緩めに設定（HARM_CATEGORY_DANGEROUS_CONTENT は BLOCK_NONE に下げない範囲で）してから安定しました。
config = types.GenerateContentConfig( response_modalities = [ "TEXT" , "IMAGE" ], temperature = 0.8 , seed = 42 + i, safety_settings = [ types.SafetySetting( category = "HARM_CATEGORY_HARASSMENT" , threshold = "BLOCK_ONLY_HIGH" , ), types.SafetySetting( category = "HARM_CATEGORY_HATE_SPEECH" , threshold = "BLOCK_ONLY_HIGH" , ), ], ) ここで BLOCK_NONE まで一気に下げる選択は、私はしていません。App Store の審査で指摘を受けたくないという事情と、子どもが触る可能性のあるアプリだという前提から、最低限のフィルタは残しておくべきだと考えています。
罠3: 出力フォーマットの一貫性
response_modalities=["TEXT", "IMAGE"] を指定しても、テキストだけ返ってくる、画像だけ返ってくる、両方返ってくる、の 3 パターンがランダムに混ざります。クライアント側で parts をループで回して inline_data がある場合のみ画像として処理する、というガード処理が必須です。
for part in response.candidates[ 0 ].content.parts: if part.inline_data is not None : image = Image.open(BytesIO(part.inline_data.data)) outputs.append(image) elif part.text: # テキスト処理（ログにだけ残す） print ( f "Model text: { part.text[: 100 ] } " ) 画像が 1 枚も返ってこなかった場合のリトライポリシーも必要です。私の実装では、最初の試行で画像が 0 枚なら同じプロンプトで seed を変えて 1 回だけリトライし、それでも 0 枚なら別プロンプト（雰囲気違い）にフォールバックする、という階層構造にしています。ユーザーに「生成に失敗しました」を見せる頻度は月間 0.4% 程度まで下がりました。
生成物を機械で受け入れ判定する — pHash による近似重複の排除
プロンプトを 3 通りに分けても、3 枚のうち 1 枚が「ほぼベース画像のまま」で返ってくる事象は残ります。等倍で並べれば気づける差でも、サムネイルサイズだと運用側の目をすり抜けます。ユーザーの画面には 3 枚が横に並ぶので、そのうち 1 枚が実質同じ絵だと体験としては失敗です。
そこで生成直後に知覚ハッシュ（pHash）で受け入れ判定を挟みました。ベース画像に近すぎる候補と、候補どうしで近すぎる組を機械的に落とします。
from io import BytesIO from PIL import Image import imagehash
# 手元の 200 枚で距離分布を取ってから決めた閾値 MIN_DIST_FROM_BASE = 8 # これ未満はベースとほぼ同一とみなす MAX_DIST_FROM_BASE = 26 # これを超えると別の絵になっている MIN_DIST_BETWEEN = 6 # 候補どうしに求める最小距離
def perceptual_hash (image_bytes: bytes ) -> imagehash.ImageHash: image = Image.open(BytesIO(image_bytes)).convert( "RGB" ) # 出力解像度がぶれてもハッシュが揺れないよう先に正規化しておく return imagehash.phash(image.resize(( 256 , 256 )))
def accept_variations (base_bytes: bytes , candidates: list[ bytes ]) -> list[ bytes ]: base_hash = perceptual_hash(base_bytes) accepted: list[tuple[imagehash.ImageHash, bytes ]] = []
for candidate in candidates: candidate_hash = perceptual_hash(candidate) distance = candidate_hash - base_hash
if distance < MIN_DIST_FROM_BASE or distance > MAX_DIST_FROM_BASE : continue # 同一すぎる / 別物になりすぎ if any (candidate_hash - accepted_hash < MIN_DIST_BETWEEN for accepted_hash, _ in accepted): continue # 既に採用した候補と近すぎる
accepted.append((candidate_hash, candidate))
return [image_bytes for _, image_bytes in accepted] 閾値の決め方について補足します。imagehash.phash の既定は 64bit なので、ハミング距離の取りうる範囲は 0〜64 です。手元の壁紙 200 枚で「人が見て色違いと判断できる」ペアの距離を測ったところ、大半が 8〜24 の帯に入りました。被写体の輪郭まで変わってしまった失敗例は 26 を超えることが多く、この 2 つの実測から上下の閾値を置いています。数字は素材の傾向で動くので、導入時は自分のカタログで一度分布を取ることをお勧めします。
受け入れ後に 3 枚に満たない場合は、不足枚数だけ seed を変えて追い生成します。ただし追い生成は 2 回までで打ち切り、それでも 2 枚しか揃わなければ 2 枚のまま返す設計にしました。枚数を無理に揃えるより、似た絵を並べない方がユーザーの納得感は高い、というのは、私自身 A/B で確かめた実感です。
この判定を入れてから、再生成が発生するのは全リクエストの 11% 前後、API コストの増分は約 4% に収まっています。「色が変わっていない」旨の問い合わせは、導入前は月に数件届いていましたが、いまはほとんど届きません。4% の増分で消せる不満としては安い、と判断しています。
ひとつ正直に書いておくと、pHash はグレースケール化した DCT が土台なので、色相だけを動かしたバリエーションには鈍いです。「色違い」軸のときだけは HSV の H チャンネルを併用しています。
import numpy as np
def mean_hue (image_bytes: bytes ) -> float : hsv = Image.open(BytesIO(image_bytes)).convert( "HSV" ).resize(( 128 , 128 )) return float (np.asarray(hsv)[:, :, 0 ].mean())
def hue_shift (base_bytes: bytes , candidate_bytes: bytes ) -> float : """H チャンネル平均の差。色違い軸の検証に使う（0〜255 スケール）""" return abs (mean_hue(candidate_bytes) - mean_hue(base_bytes)) variation_type == "color" のときは hue_shift が 12 未満の候補も落とす、という条件を pHash 判定に足しています。色相だけが動いて構図が変わらないケースは pHash の距離が伸びにくく、この 1 行がないと素通りしてしまいます。
キャッシュ戦略で API コストをさらに圧縮する
ベース画像が同じで、同じバリエーション指示を別ユーザーが投げてくることは現実に頻繁にあります。たとえば「桜の壁紙の夕焼けバリエーション」は、季節要因で複数ユーザーが同時期に要求します。
私の実装では、ベース画像 ID + variation_type + seed の組をキーにして Cloudflare R2 に生成画像をキャッシュしています。キャッシュ命中率は 33% 程度。これだけで API コストを名目より 30〜33% 圧縮できています。先に書いた「月 250 円／ユーザー」の数字には、このキャッシュ命中後の値が反映されています。
ただし、無限にキャッシュを溜めるとストレージ料金が逆に重くなるので、生成から 60 日アクセスがない画像は削除しています。Cloudflare R2 の lifecycle policy で自動運用しているので、運用負荷は実質ゼロです。
もう一段の最適化として、Gemini の context cache を使ってシステムプロンプトを共有する手もあります。ただ、Image Output 用途のシステムプロンプトはそれほど長くないので、context cache のコスト効果は限定的でした。私の運用では temperature と seed の組み合わせを工夫してプロンプトを短く保つ方向に倒しています。
効果測定 — DAU リテンションと課金率の変化
機能リリース後の 30 日間で計測した数字を共有します。バリエーション生成を有効化したコホート（Premium ユーザー）と、コントロール（バリエーション無効化を A/B テストの片側に）で比較しました。
DAU リテンション（Day 7）は、コントロールが 38.4%、バリエーション有効化が 42.1%。差分は 3.7 ポイントで、A/B テストの統計的有意性も確認できました。Day 30 リテンションも、コントロール 18.2% → バリエーション 21.4% と 3.2 ポイント改善。これは個人開発の規模でも十分手応えのある数字です。
課金率（Premium 転換率）はもう少し劇的で、コントロール 0.84% → バリエーション 1.21%。約 1.44 倍の改善です。バリエーション機能を「Premium にだけ開放する」設計が課金動機につながった、と分析しています。
eCPM（広告収益）も微増しました。理由は単純で、リテンション改善 → 1 ユーザーあたりの広告表示回数の総量が増えるから、です。Day 30 までの 1 ユーザー LTV は約 19% 改善しました。個人開発の規模では、こうした 2 桁パーセントの改善が事業の継続性を直接押し上げます。
どんな個人開発者にこの構成を推奨するか
最後に、誰にどう推奨するかを整理します。
私が推奨するのは、すでにアプリ内に「画像コンテンツのカタログ」があり、ユーザー入力をきっかけに派生バリエーションを返したい個人開発者の方です。壁紙アプリだけでなく、レシピアプリ（料理写真の盛り付け違い）、ファッションアプリ（同じアイテムの色違い表示）、書籍カバーや CD ジャケットを扱うアプリでも応用できます。
逆に、ゼロから新規画像を生成して提供するサービスでは、Imagen 4 を主軸にする方が品質的に有利です。Gemini 3.2 Flash Image Output は派生バリエーション用途に最適化されている、と私は捉えています。両者を組み合わせる「シード生成 = Imagen 4、派生 = Gemini Image Output」の構成は、個人開発の規模でもコストと品質のバランスが取りやすく、推奨できます。
実装スピード重視で言えば、google-genai SDK の response_modalities=["TEXT", "IMAGE"] の挙動を 1 度動かしてみるところから始めるのがお勧めです。Imagen 4 の API より少しシンプルで、入力画像の渡し方も Part.from_bytes で完結します。
ユーザーが毎日触る画面に置く機能ほど、レイテンシ・品質・コストの 3 軸で妥協しない設計をしておきたい、というのが私の考えです。次に試したいのは、ユーザーごとの好み履歴を Gemini の context cache に保存して「あなた向けのバリエーション」を返す設計。上位プランの体験として、いま検証を進めています。
実装を始める前に、まずは自分のアプリの月間アクティブユーザー数と Premium 課金率の現在値を一度書き出してみることをお勧めします。粗利を逆算できるとリスク評価が落ち着き、Image Output を試す心理的なハードルが大きく下がります。お読みいただきありがとうございました。