Nano Banana 2 で 429 が出たときの代替手段: 今使うべき選択肢 (2026)

Nano Banana 2 が 429 RESOURCE_EXHAUSTED を返しているとき、多くのチームにとって最適な答えは一つの万能な代替モデルではありません。実務的なデフォルトはこうです。文字描画や反復編集を最優先するなら GPT Image 1.5、Google 依存そのものを下げたいなら FLUX、モデル自体は正しいのに quota path だけが間違っているなら Nano Banana 2 を残して経路を変える。

重要なのは、429 がいつも「モデル選定の失敗」を意味するわけではないことです。Nano Banana 2 が現在のトラフィック形状に合わなくなっただけかもしれません。Google 側の preview っぽい quota 挙動が本当の不安定要因かもしれません。あるいは、今回の 429 がきっかけで、チームが本当に欲しかったのは最初からもっと強い text / edit contract だったと分かる場合もあります。

Google の現行 Nano Banana 2 公式発表ページ は、Nano Banana 2 を Gemini 3.1 Flash Image と位置付け、Gemini API と Google AI Studio で提供し、AI Studio では有料 API key が必要だと説明しています。OpenAI の現行 画像生成ドキュメント は gpt-image-1.5 を GPT Image 系で最も強いモデルとして扱い、生成と編集の両方をサポートしています。Black Forest Labs の現行 FLUX 価格ページ では、FLUX.1 Kontext [pro] も FLUX1.1 [pro] も 1枚あたり $0.04 です。もしあなたの本当の課題が「Google の quota contract を抜けたい」ことであって、「Nano Banana 2 に一番近い見た目」を探すことではないなら、FLUX は今かなり筋の良い非 Google ルートです。

TL;DR

多くのチームがやってしまうのは、「429 が出た」から即「新しい最強画像モデルに乗り換えよう」と考えることです。でも本当に価値がある問いは別です。あなたは Nano Banana 2 の何を使っていたのか。

答えが「Google ネイティブな高速生成と編集」なら contract を変える方が賢いことが多いです。答えが「文字や編集の安定性」なら GPT Image 1.5 が合っています。答えが「Google の quota path 自体から離れたい」なら FLUX の方が筋が通ります。

最初に切り分けるべきなのは、モデル問題か quota path 問題か

切り替える前に、まず二つのケースを分けてください。

一つ目は比較的単純です。いまの path を本当に使い切っているケース。典型的には burst traffic、弱い queueing、あるいは現在の project tier ともう合っていない負荷です。この場合、モデルを変えると症状は薄まるかもしれませんが、根本では「今の traffic shape がこの contract に合わない」という問題が残ります。

二つ目はもっと厄介です。モデル自体はまだ合っているのに、そのモデルへ到達する path の方が不安定で、もう信用できないケースです。Google の公開ドキュメントからも二つの重要なシグナルが読めます。第一に、Nano Banana 2 は依然として AI Studio / Gemini API の有料 API workflow です。第二に、Gemini Apps Help は、Nano Banana 2 の consumer 側 quota、Nano Banana Pro redo quota、AI Mode の挙動を別々の surface として扱っています。つまり、もう「Google の画像生成」を一つの平坦な contract と見てはいけません。

Google の開発者フォーラムには、paid-tier なのに visible usage が低いまま 429 RESOURCE_EXHAUSTED が返るという報告も複数あります。これは Google が正式に「壊れています」と認めたという意味ではありません。ただし、少なくとも一部の 429 は「Nano Banana 2 というモデルが悪い」のではなく、quota path の不安定さとして考えた方が実務的だというヒントにはなります。

だから最初に自問すべきなのは次の三つです。

1. Nano Banana 2 は動いているとき、ちゃんと欲しい絵を返していたか。
2. 問題は burst traffic、billing propagation、preview throttling、per-project quota 挙動にあるのか。
3. それとも今回の 429 は、自分たちが実は別の workflow contract を欲しがっていたことを露出させただけか。

もし Nano Banana 2 が創作面ではまだ正しいなら、価値が高いのは離脱ではなく path の変更です。queueing で平滑化する、非緊急分を Batch に送る、tier を見直す、あるいは別の quota contract を提供する gateway を使う。Google の 429 をもっと技術寄りに掘るなら、Gemini 画像 429 ガイド を読んでください。

文字と編集を最重要視するなら GPT Image 1.5 が最も強い

多くの Nano Banana 2 ユーザーにとって、最も現実的な直接代替は別の Google image path ではなく gpt-image-1.5 です。

理由はブランドの知名度ではありません。OpenAI の現行ドキュメントは gpt-image-1.5 を GPT Image 系の最新・最上位モデルとして扱い、API でも generation と edit の両方を提供しています。そもそも多くのチームが Nano Banana 2 を離れたくなるのは、純粋な photorealism が足りないからではなく、本番でより予測しやすい text / edit contract を求めているからです。

ここで GPT Image 1.5 が強い。

たとえばプロンプトが頻繁に次のような要求を含むなら:

• 図の中で読めるラベルや見出し
• ソーシャルや商品画像のテキスト
• 既存アセットに対する反復編集
• 編集時に入力画像の重要ディテールをできるだけ保ちたい

そのとき GPT Image 1.5 は、Nano Banana 2 contract に留まり続けるより自然な移行先になりやすいです。

OpenAI の現行 docs は価格の見積もりも比較的しやすいです。正方形出力の現行公式価格はこうです。

もちろん、これだけで「常に Nano Banana 2 より安い」とは言えません。そもそも output contract が違うからです。ただ、少なくとも enterprise 向けの複雑な手続きを待たずに試せる、という意味ではとても実務的です。

代償も正直に見ておくべきです。OpenAI の現行 docs は、latency、composition control、正確な text placement をなお limitation として挙げています。つまり、GPT Image 1.5 は旧世代よりずっと良くなったが、どんな複雑レイアウトでも完全に保証されるわけではありません。また、公式サイズは現時点で主に 1536x1024 と 1024x1536 で、Nano Banana 2 的な 2K / 4K 路線ではありません。だから、あなたが Nano Banana 2 で本当に好きだったのが「高解像度を速く回せること」なら、GPT は完全な drop-in ではありません。

それでも、求めているのが「画像 API にもっと安定した文字と編集の contract が欲しい」ことなら、いま最も筋の良い直接代替は GPT Image 1.5 です。

provider contract を変えたいなら FLUX の方が筋が良い

最良の代替は、必ずしも Nano Banana 2 に一番似た出力のモデルではありません。ときには、嫌になった運用 contract ごと変えてくれるルートの方が価値があります。

だからこそ FLUX をここで扱う必要があります。

Black Forest Labs の現行公式価格はかなり分かりやすいです。

• FLUX.1 Kontext [pro]: \$0.04/枚
• FLUX.1 Kontext [max]: \$0.08/枚
• FLUX1.1 [pro]: \$0.04/枚
• FLUX1.1 [pro] Ultra: \$0.06/枚

価格以上に重要なのは、BFL が workload をどう分けているかです。FLUX.1 Kontext [pro] は text と images を使った create / edit 用、FLUX1.1 [pro] は標準的な高速 text-to-image 用。これは、単なる「画像モデルランキング」よりも実務に近い切り方です。欲しいのが現代的な edit contractなのか、安定した generation contractなのかを分けて考えられるからです。

FLUX が GPT Image 1.5 より向いているのは、たとえばこういうケースです。

• 本当の問題が single provider 依存にある
• consumer app 的な経路ではなく、きちんとした非 Google ルートが欲しい
• Nano Banana 2 にどれだけ似ているかより、provider control の方が大事
• 開発者視点で routing しやすい model family が欲しい

これは、FLUX がすべての人にとって最も Nano Banana 2 に近い置き換えという意味ではありません。違います。文字や multi-turn edit が最優先なら GPT Image 1.5 の方が勧めやすいです。ただし、「Google の quota path に uptime を握られたくない」が最優先なら、FLUX の方が戦略的に正しいです。

要するに、GPT はworkflow override、FLUX はprovider overrideです。

いちばん価値が高い答えは、モデルを変えず path だけ変えることもある

ここが、多くの「代替案」記事が雑になる部分です。

Nano Banana 2 がいまでも欲しい速度、Google ネイティブな編集体験、出力の方向性を返しているなら、価値が高いのは別モデルに乗り換えることではなく、Nano Banana 2 を残したまま contract だけを変えることです。

それは例えば次のような動きです。

• queue と backoff を見直して burst を平滑化する
• 非緊急ジョブを Batch 側に寄せる
• billing tier を上げる、もしくは quota 姿勢の違う project へ移す
• model family は変えず、gateway や relay で quota contract だけ変える

次の一文がまだ真実なら、このルートはかなり有力です。

“

Nano Banana 2 そのものは欲しい。ただし今の quota path では持たない。

あなたのチームが Nano Banana 2 を選んだ理由が次のどれかなら、なおさらです。

• もともと Gemini / Google stack 上に構築している
• Nano Banana 2 の speed-to-edit バランスがちょうど良い
• 新しい model family に合わせて prompt や審査基準を学び直したくない

だから、この中間ルートは重要です。モデル切り替えは高くつきます。Prompt の癖が変わる。Edit の癖が変わる。コストの読み方も変わる。レビュー基準まで変わる。創作 contract がまだ正しいなら、先に直すべきは traffic contract です。

必要なら gateway 層も役に立ちます。複数 provider をまたぐ routing や、複数 API を自前で抱えたくないなら、LaoZhang AI のような infra 層も意味があります。ここでの理解は「魔法の無限 Nano Banana」ではなく、「既存 workflow を保ちながら routing / billing contract を差し替える」です。

Gemini App や AI Mode を API の drop-in 代替と考えない

ここでも時間を無駄にしやすいです。

Google の consumer 向け help ページは、現在の product map を理解するには有用です。でも、それがそのまま API 429 の解決策になるわけではありません。

現行の Gemini Apps Help では Image generation & editing with Nano Banana 2 の subscriber quota と、別枠の Redo images with Nano Banana Pro quota が文書化されています。さらに AI Mode の help page は、Nano Banana Pro を infographic / diagram 寄りの特殊ルートとして扱っています。これらは real な surface ですが、production API path と同じ contract ではありません。

だから、アプリを作っている人がこれを読んで、

“

API が 429 だから Gemini app や AI Mode に移せばいい

と理解するのは、ほぼ間違いです。

正しい読み方はこうです。

• Google の Nano Banana family はもう複数の product contract に分かれている
• 「Google の画像アクセス」は一枚岩ではない
• Google に残るとしても、失敗した path と別の技術的な pathが必要になる場合が多い

最速で使える判断表

最短で判断したいなら、この表で十分です。

この query に対する本当の判断軸は「どの画像モデルが最強か」ではありません。Nano Banana 2 のどの価値を残したいのかです。

多くのチームが本当にやりがちな移行ミス

チームは大きく二つの方向で失敗します。

一つ目は過剰移行。429 を見た瞬間に「モデルが悪い」と決めつけ、画像スタック全体を作り直す。でも本当は queueing や Batch、billing path の修正だけで済んだ。

二つ目は移行不足。現在の quota path がもう合っていないのに、それでも Nano Banana 2 に留まり続ける。本当はもっと強い text / edit contract や非 Google provider contract が必要なのに、そこを認めない。

この二つの極端を避けるために、このページがあります。

一つだけ覚えるなら、これで十分です。

• 文字 / 編集に強い近い代替が欲しい → GPT Image 1.5
• 本気で非 Google ルートが欲しい → FLUX
• Nano Banana 2 自体は正しい。今日の quota path だけが間違っている → NB2 を維持して path を変える

これが、ただの「おすすめ画像生成ツール一覧」よりはるかに役に立つ理由です。

FAQ

いま一番 Nano Banana 2 に近い代替は何ですか？
多くの API チームにとっては gpt-image-1.5 です。特に詰まっている workload が文字や編集寄りならそうなりやすいです。ただ、Google ネイティブ workflow 自体を残したいなら、一番近い答えは別モデルではなく、Nano Banana 2 の別 quota path です。

Nano Banana 2 の 429 はダウンしている意味ですか？
違います。429 は今の request path が quota か throttling の境界に当たったという意味です。深刻ではありえますが、全面 outage とは別です。もっと広い error taxonomy は Gemini 画像の common errors ガイド を見てください。

待つべきですか、それともすぐ切り替えるべきですか？
Nano Banana 2 が創作面でまだ明らかに正しく、queueing・billing・tier まわりを直す道があるなら待って修正する価値があります。逆に、今回の 429 で「本当はもっと強い text / edit contract か non-Google provider が欲しかった」と分かったなら、すぐ切り替える方がいいです。

GPT Image 1.5 は Nano Banana 2 より安いですか？
場面によります。OpenAI の現行 square pricing は low で \$0.009、medium で \$0.034 から始まりますが、output contract 自体が違います。単価だけでなく、仕事に対して比較してください。

Gemini app や AI Mode をそのまま API の代わりにできますか？
drop-in の engineering 代替として考えるべきではありません。それぞれ独自の product contract と limit があり、API path が落ちたときの自動代替とは別物です。

緊急の fallback ではなく、長期の image stack を選びたい場合は？
その場合は、このページより広い判断が必要です。まずは ベスト AI 画像モデルガイド で上位の workflow 判断をしてから、最後の詰まりどころが Nano Banana 2 の quota 行動ならこのページに戻ってきてください。

Nano Banana 2 の 429 が厄介なのは、一つの問題に見えることです。実際には、その裏に三つの意思決定が隠れています。この三つを分けて考えれば、使うべき代替手段はかなりはっきりします。