2026 年に Gemini 3.2 Flash の Image Output モードが本番提供されてから、私の手元では壁紙アプリのコンテンツ拡張パイプラインの設計が一段進みました。それまで Imagen 4 と Gemini Vision を別々に呼んでいた一連の処理が、ひとつのモデル呼び出しに統合できるようになったからです。リクエスト数が減るだけでなく、入力画像を渡したまま編集指示を流せるので、派生バリエーションの「同一性」を保ちやすくなった点が個人開発の現場では一番のメリットでした。
私は 2014 年から個人で壁紙アプリ・癒し系アプリを運営してきて、累計 5,000 万ダウンロードを超えるユーザーに届けてきました。アプリの心臓部はいつもコンテンツの密度で、季節や時間帯に合わせて画像のバリエーションをどれだけ広げられるかが、AdMob の eCPM とアプリ内課金（IAP）の両方に効いてきます。手描きや撮影だけでコンテンツを増やす時代は終わっていて、AI 生成・編集を「運用」として組み込めるかどうかが、個人開発で 12 年継続できるかの分岐点になっていると感じます。
今回の記事は、Gemini 3.2 Flash の Image Output を本番運用に組み込んだ実装記録です。Imagen 4 との使い分け、Python での具体実装、月額 API コストの実測値、本番でハマった 3 つの罠までを、個人開発者の視点でまとめます。なお、私の現代美術の作品制作は手仕事の領域であり、生成 AI は介在させていません。生成 AI を使うのはアプリ事業側の運用・編集・派生バリエーション生成の領域に限定しています。アーティスト活動と個人開発を 12 年並行してきた経験から、この線引きを最初に意識しておくと記事中の判断軸がきれいに読めるはずです。
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 キーの管理と利用量制御の両方で破綻します。AdMob の収益が月 150 万円ピークまで届いた壁紙アプリ群で、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 まで一気に下げる選択は、私はしていません。アプリストアのレビュー対策（とくに iOS 側）と、子どもが触る可能性のあるアプリだという前提から、最低限のフィルタは残しておくべきだと考えています。
罠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% 程度まで下がりました。
キャッシュ戦略で 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 課金のさらに上位プランの体験設計として、検証を進めています。
実装を始める前に、まずは自分のアプリの月間アクティブユーザー数と Premium 課金率の現在値を一度書き出してみることをお勧めします。粗利を逆算できるとリスク評価が落ち着き、Image Output を試す心理的なハードルが大きく下がります。お読みいただきありがとうございました。