AI / LLM

Firebase Imagen が 6/24 で全停止 — Gemini Image (Nano Banana) への移行を実コードで整理する

FirebaseGeminiImagenFlutterAI

はじめに

Google は Firebase AI Logic 経由で提供してきた Imagen 全モデルを 2026-06-24 にシャットダウンする と告知した。対象は Gemini Developer API (Google AI) と Vertex AI Gemini API の両バックエンド。停止後はモデル名でリクエストすると 404 が返るだけで、グレースフルな後方互換は用意されない。代替は「Nano Banana」と呼ばれる Gemini Image 系列で、gemini-2.5-flash-image を最小構成として、上位の Pro / Flash 系もすでに利用可能だ。本記事ではこの停止に必要な移行を、Flutter (Dart) の実コード差分と Firebase AI Logic 側の API 変更点に絞ってエンジニア視点で整理する。

何が止まるのか — Imagen シャットダウンの全体像

止まるのは「Firebase AI Logic SDK 経由で Imagen モデルにリクエストを送る経路」全部だ。imagen-3.0-generate-002 のような世代別モデルだけでなく、画像編集向けの imagen-3.0-capability-001 系（outpainting、object removal、controlled customization など）も一括で対象になる。Firebase Studio の App Prototyping エージェント側はすでに gemini-2.5-flash-image-preview へ切り替わっているので、影響は アプリ側のクライアントコードと、サーバ側で Firebase AI Logic を呼んでいる Genkit フロー に閉じる。

注意したい挙動として、シャットダウン後のモデル指定は警告ログではなく単純な 404 になる。例外として握りつぶしている箇所があると、ユーザー向けには「画像生成が無音で失敗する」状態になる。Firebase Crashlytics と Cloud Logging のリクエスト失敗率に頼っている運用だと、404 を黙って return null してしまっているコードが見えにくいので、移行作業に入る前に 既存の Imagen 呼び出し箇所を grep して一覧化 しておくのが先決だ。Flutter 側なら ImagenModel、generativeModelForImagen、imagen- を含むモデル名文字列を grep すれば概ね出る。

Nano Banana 系列の中身 — どのモデルに移行するか

Firebase AI Logic で現在使えるのは次の 3 モデルだ。

  • gemini-2.5-flash-image — いわゆる無印 Nano Banana。出力サイズは 1024 (1K) 固定。参照画像は最大 3 枚まで。コストとレイテンシを重視するならまずこれ。
  • gemini-3.1-flash-image-preview — Nano Banana 2。512 / 1024 / 2048 / 4096 のサイズ切替に対応し、参照画像も最大 14 枚。プレビュー扱い。
  • gemini-3-pro-image-preview — Nano Banana Pro。サイズ・アスペクト比のレンジは Flash と同等で、品質特性が違う。テキストレンダリングや高解像度出力が必要な領域向け。プレビュー扱い。

アスペクト比は 1:1 / 9:16 / 16:9 / 3:4 / 4:3 / 2:3 / 3:2 / 4:5 / 5:4 / 21:9 / 4:1 / 8:1 / 1:4 / 1:8 が指定できる。ベスト性能の言語は英語・スペイン語・日本語・中国語と明記されているので、日本語プロンプトでの品質は引き続き期待してよい。一方で 音声・動画入力はサポート対象外 で、Imagen がもともと持っていなかった機能なのでこの点は変化なし。

設計上の大きな違いは Gemini Image が「画像と並んでテキストも返せる」点だ。responseModalities で text と image を両方指定すれば、生成過程の説明文を一緒に取れる。チャット UI に組み込みやすくなる一方、レスポンスのパース処理は Imagen 時代より一段増える。response.candidates[0].content.parts を回して inlineData を持つパートだけ画像として扱う形になるので、ここが既存コードと噛み合うかは事前に確認しておきたい。

Flutter で実コードを置き換える — 最小差分

Firebase AI Logic SDK for Flutter (firebase_ai) を前提に、最小の置き換えを示す。Imagen 時代は次のような形だった。

final imagen = FirebaseAI.googleAI().imagenModel(
  model: 'imagen-3.0-generate-002',
);
final result = await imagen.generateImages('Eiffel Tower with fireworks');
final bytes = result.images.first.bytesBase64Encoded;

これを Nano Banana に置き換えると、generativeModel 経由になり、responseModalities を明示する。

final model = FirebaseAI.googleAI().generativeModel(
  model: 'gemini-2.5-flash-image',
  generationConfig: GenerationConfig(
    responseModalities: [ResponseModalities.text, ResponseModalities.image],
  ),
);

final response = await model.generateContent([
  Content.text('Generate an image of the Eiffel Tower with fireworks'),
]);

final imagePart = response.candidates.first.content.parts
    .whereType<InlineDataPart>()
    .first;
final bytes = imagePart.bytes;

Imagen 系の imagenModel() ファクトリは消える方向なので、generativeModel() ベースに寄せておくと将来も読みやすい。Vertex AI 経由で使うなら FirebaseAI.vertexAI() に差し替えれば、モデル名と config の組み立てロジックは再利用できる。

画像編集系（参照画像入力）も Content.multi で画像と指示文を同時に渡す形になる。Imagen 時代に分かれていた generate / edit / outpaint / remove のエンドポイントが、Gemini 側では 同じ generateContent に集約される ため、ユースケースごとの分岐は SDK 呼び出しよりプロンプト側で書くことになる。逆に言えば、既存コードで edit / generate を別クラスに切っていた箇所は、移行のタイミングでまとめて簡素化できる。

移行で詰まりやすい論点

実務でぶつかりやすいポイントを 3 つに絞る。

ひとつ目は 課金プラン。Gemini Image 系は Blaze プラン (pay-as-you-go) でしか使えない。Spark プランの開発環境で動かしていたチームは、移行と同時に Blaze 化と予算アラート設定が必須になる。請求は出力画像のトークン換算で走るので、Imagen 時代の「リクエスト単価」感覚で見積もると外す。Firebase コンソールの予算アラートと、Cloud Billing の予算上限を両方仕掛けておくと安全だ。

ふたつ目は プロンプトの再評価。Imagen は画像生成専用に学習されているため、Gemini Image とは得意なテイストが微妙に違う。同じプロンプトを流すと、構図やテキストレンダリングの傾向が変わるケースがある。プロダクション投入前に、主要プロンプトをまとめて回す A/B 比較スクリプトを 1 本書いておくと、後からユーザー報告でブレに気づくよりずっと安く済む。Pro と Flash でも傾向は揺れるので、用途ごとにモデル固定にしておきたい。

みっつ目は App Check と利用上限。Gemini Image はマルチモーダル出力なので、レスポンスサイズが Imagen より大きくなり得る。Firebase Functions やクライアントから直接叩いている場合、レスポンス保存先 (Cloud Storage / Firestore のフィールド) のサイズ制限と App Check のレート制御の閾値を見直しておくと、移行直後の障害リスクが下がる。

まとめ

  • Firebase AI Logic の Imagen は 2026-06-24 に全停止、Nano Banana 系 (gemini-2.5-flash-image ほか) への移行が必須。
  • Flutter 側の置き換えは imagenModel() → generativeModel() への寄せと、responseModalities の追加が中心。
  • 課金は Blaze 必須、レスポンス形式と画像品質の傾向が変わるため、プロンプト・予算・App Check は移行と同時に再点検すべき。

公式の完全な移行ガイド本体はまだ準備中（プレースホルダーページが公開されている段階）なので、現実的にはモデル仕様ページと Gemini 画像生成ドキュメントを正本に据えて先回りで動かしておくのが安全な姿勢だ。残り 23 日、移行を後ろ倒しにする余地は薄い。

今日のその他のニュース

Anthropic「Zero Trust for AI agents」を公開

Anthropic 公式ブログが AI エージェントに Zero Trust モデルを適用する設計指針を提示。エージェントを信頼しない前提で、ツール呼び出し・データアクセス・出力先すべてを最小権限化する具体プラクティスをまとめている。Claude Code でエージェントを業務に組み込む際の設計指針として読む価値が高い。はてブ 313 users。

GKE 2026 が大型刷新 — Pod Snapshots と Agent Sandbox

Google Cloud が GKE の 2026 大型アップデートを公開。AI エージェントの状態を瞬時にチェックポイント／復元する Pod Snapshots によりコールドスタートを 90% 削減、Agent Sandbox で非決定的 AI エージェント向けのカーネルレベル隔離を提供、Carbon-Aware Scheduling と FinOps Hub 2.0 も導入。エージェント基盤を GKE に乗せる構想がある案件は、ロードマップを再評価したい。

「論理削除をやめて状態をテーブルで分ける」DB 設計が反響

Zenn で 148 likes を集めた設計記事。is_deleted フラグを捨てて active / archived / deleted を別テーブルで持つことで、参照側のクエリをシンプルに保ちながら履歴も追える。設計時の判断軸として持っておくと議論しやすい。

ソース

Back to articles