Nano Banana が Gemini で画像を出さない時、原因は一つではありません。Gemini アプリの会話状態が詰まっている場合もあれば、Pro redo の入口が現在の account route に出ていない場合、prompt が policy boundary に触れている場合、Gemini API の project quota に当たっている場合、third-party wrapper が upload や model alias を壊している場合、または特定 route が一時的に overload している場合もあります。
最初に見るべきなのは失敗した入口です。その入口に合う小さな修正を 1 つだけ入れ、同じ入口で 1 回だけ再検証します。permission、quota、policy、overload、status の信号が見えたら、連続 retry を止めて該当分岐へ移します。
| 失敗した入口 | 見える症状 | 最初の動き | 再検証 | 止める、または渡す条件 |
|---|---|---|---|---|
| Gemini web / mobile app | loading が終わらない、生成が止まる、something went wrong | タブまたは app を再起動し、新しい chat を開く | 同じ account、同じ短い image request を 1 回 | まだ失敗するなら prompt、account route、status を見る |
| Pro redo route | Redo with Pro が出ない、使えない、動きが一定しない | account、plan surface、region、最初の画像の route を確認 | Pro-capable route で同じ種類の task を再実行 | account と route が不明なまま outage と言わない |
| Prompt / policy | text だけ返る、拒否される、画像 part がない | 許可される 1 枚の画像 task まで prompt を縮める | 短い image-only prompt を 1 回 | policy らしければ retry ではなく書き換える |
| AI Studio / Gemini API | 403、429、503、no image、request failure | model ID、key/project、billing、quota、payload、status を確認 | 直した request を同じ route で 1 回 | 429 と 503 は別分岐。app cache では直さない |
| Wrapper / provider tool | Figma、Make、SDK、gateway、upload flow が失敗 | direct Gemini route と wrapper log を比較 | wrapper 側の変数を 1 つ直して再検証 | route、時刻、prompt、model、code、request id、screenshot、log を残す |
| Status / outage suspicion | 複数 route が落ちる、503 が続く、status signal がある | official status owner と direct route を確認 | 待つ、queue、switch は status 確認後 | forum は symptom vocabulary であり live outage 証明ではない |
2026 年 6 月 28 日に確認した Google image generation docs では、Nano Banana 2 は gemini-3.1-flash-image、Nano Banana Pro は gemini-3-pro-image、以前の Nano Banana lane は gemini-2.5-flash-image です。現在の status、quota、price、plan benefit、availability、provider promise は揺れるため、事実として書く前にその時点の official / provider evidence が必要です。
12 個の修正は順番ではなく route で選ぶ
12 個を上から全部実行しないでください。症状で route を決め、その route に合う 1 つの修正だけを入れ、同じ route で 1 回試します。これにより、quota、permission、policy の問題を noisy retry loop に変えずに済みます。
| # | Route | 修正 | 使う場面 | 検証 |
|---|---|---|---|---|
| 1 | App session | タブまたは app を再起動 | Gemini が loading のまま、UI が固まる、初回が完了しない | 同じ chat、同じ短い prompt、1 retry |
| 2 | App session | 新しい chat を作る | 既存 chat に edits、uploads、failed attempts が多い | new chat で同じ簡略 request |
| 3 | App/mobile | app または browser を更新 | mobile と desktop の挙動が違う | update 後に同じ request |
| 4 | Prompt/policy | prompt を短くする | text-only、refusal、no image | short image-only prompt |
| 5 | Pro route | Pro route を確認 | Redo with Pro が missing / inconsistent | account と route を確認してから retry |
| 6 | API | model ID を確認 | generation 前に request が落ちる | current official image model ID を使う |
| 7 | API | key と project を確認 | 401、403、permission wording | verified key/project で同じ request |
| 8 | API | billing と quota を確認 | 429 または RESOURCE_EXHAUSTED | project limit owner を確認 |
| 9 | API | 429 loop を止める | retry が毎回 429 | quota/rate/spend branch を直す |
| 10 | API/status | 503 status を見る | UNAVAILABLE、overload、広い route failure | official status と retry policy を確認 |
| 11 | Wrapper | payload mapping を見る | third-party tool だけ失敗 | direct route と wrapper route を比較 |
| 12 | Escalation | evidence pack を保存 | controlled retest 後も失敗 | timestamp、route、model、prompt、code、request id、screenshot、logs |
Gemini app と mobile は session から見る
Gemini app で失敗しているなら、API key、billing、model ID から始めません。app-route failure は、詰まった conversation state、古い UI route、browser/app cache、network change、uploaded file context、または Gemini が画像 task ではなく text task と解釈したことが原因になりやすいです。
最小の動きは次です。
- browser tab を reload する、または mobile app を完全に閉じて開き直す。
- 現在の conversation に edit、upload、失敗した生成が多い時は fresh chat を使う。
- mobile と desktop で違う時は Gemini / Google app を update して同じ account で試す。
- prompt を 1 subject、1 style、1 output expectation に縮める。
- uploaded image がある時は、まず file なしの baseline、次に必要 file だけの direct edit を試す。
同じ入口で再検証する理由は、原因を守るためです。device、account、network、prompt、cache を同時に変えると、どれが効いたのか分かりません。1 回の検証で変える variable は 1 つで十分です。
loading loop が refusal に変わったら、それは app session ではなく prompt/policy branch です。mobile app だけ失敗して desktop が動くなら、app version、account route、region route を優先し、Gemini API 全体の障害とは扱いません。
Pro redo は account と route を確認する
"Nano Banana Pro が動かない" は、image model failure ではなく access-route problem であることが多いです。見える product route は Google account、subscription surface、region、rollout state、最初の画像が作られた route に影響されます。
| 確認すること | なぜ重要か | 次の動き |
|---|---|---|
| 正しい Google account か | 複数 account では plan と feature route が変わる | 期待する access を持つ account に切り替えて reload |
| 最初の画像が対応 route で作られたか | Pro action は initial image path に依存することがある | target route で clean first image を作ってから redo を見る |
| 今日その surface で機能が出ているか | Gemini app、AI Studio、API、wrapper は別 contract | current help/status owner を確認 |
| region / plan 依存があるか | availability は変わる | current-run verified wording だけを使う |
consumer Gemini app の Pro button 問題を API payload で直そうとしないでください。下の API checklist は、failed surface が AI Studio または Gemini API の場合だけ使います。
Prompt と policy は長くするより小さくする
Gemini が text だけ返す、画像がない、または明確な API code なしに拒否する場合、最初に見るのは intent です。長い prompt ではなく、画像 task だと分かる短い prompt が必要です。
textCreate one image: [subject]. Style: [visual style]. Do not include text unless I explicitly ask for it. Return the image only.
次に曖昧さを減らします。
- multi-step scene を 1 subject と 1 background に分ける。
- 必須でない brand、celebrity、copyrighted character、private-person reference を外す。
- clean base generation が動く前に "fix the previous failed output" を頼まない。
- aspect ratio、file format、editing task を 1 request に詰め込みすぎない。
- uploaded image がある時は、upload なしの baseline と、必要 file だけの edit を分ける。
policy-shaped failure は retry では直りにくいです。同じ prompt を繰り返しても content boundary は capacity problem になりません。
AI Studio と Gemini API は request contract を見る
developer route では、Gemini app の cache clear は役に立ちません。stale model ID、missing project permission、inactive billing path、exhausted quota、malformed payload、file resource、temporary 503 は別の checklist です。
現在の model mapping は先に確認します。
| Market-visible name | Official API model ID |
|---|---|
| Nano Banana 2 | gemini-3.1-flash-image |
| Nano Banana Pro | gemini-3-pro-image |
| Earlier Nano Banana lane | gemini-2.5-flash-image |
古い tutorial の -preview strings を使っている場合、先に current Google AI for Developers image generation docs と照合してください。stale model string は、広い障害のように見えても request contract mismatch です。
| Error / symptom | 見る意味 | 最初の修正 | Stop rule |
|---|---|---|---|
| 401 / 403 | key、project、permission、route access | key、project、API enablement、account、region を確認 | access が直るまで retry しない |
429 RESOURCE_EXHAUSTED | rate、quota、spend、project limit | AI Studio / quota surface で project limit owner を見る | back off。retry loop で bucket を隠さない |
503 UNAVAILABLE | temporary overload または downtime | status と retry policy を確認し pressure を下げる | prompt problem として扱わない |
| text response but no image part | request shape、output modality、parser | image intent を明確にし response parts を見る | outage と決めない |
| wrapper says model failed | provider / transport layer | same prompt を direct Gemini app/API で試す | direct-route comparison 後に escalation |
Google troubleshooting docs は 429 を limit branch、503 を overload / downtime branch として扱います。rate-limit docs では limits が project-owned であるため、同じ project 内の key rotation は通常 first move ではありません。
より深い API branch は Gemini image generation error, limit, and watermark reference、Gemini image 429 rate-limit branch、Gemini 3 Pro Image 503 overloaded branch に渡します。
Wrapper、SDK、provider tool は直接 route と比べる
wrapper failures は owner が見えにくいです。表示上は "model failed" でも、upload mapping、file-size boundary、provider tenant limit、SDK version、webhook timeout、model alias、retry policy が原因になることがあります。
direct-route comparison の手順は次です。
- exact prompt と input file を保存する。
- consumer-facing failure なら Gemini app、developer-facing failure なら AI Studio/API で同じ request を試す。
- direct route が動くなら、wrapper の model alias、payload fields、upload URL、MIME type、file size、timeout を見る。
- direct route も同じ失敗なら、prompt、API、status branch へ戻る。
- SDK version や retry logic を変える前に provider logs を保存する。
gateway / provider route は、API branch が証明された後にだけ意味があります。billing、routing、logs、support ownership を変えますが、Gemini app session、blocked prompt、Pro route entitlement は直しません。
止める、切り替える、エスカレーションする
一番悪い診断は、すべての変数を同時に変えることです。signal が失われ、support が再現できない failure になります。
| Signal | やめること | 代わりにやること |
|---|---|---|
| 403 / permission wording | 同じ credential で retry し続ける | account、key、project、permission、route access を直す |
429 / RESOURCE_EXHAUSTED | blind retry loop | project limits を見て pressure を下げ、429 branch に入る |
| policy-shaped refusal | 同じ prompt の繰り返し | allowed content と clearer image intent に書き換える |
| 503 / overload wording | 最初に prompt を直す | official status を見て retry pressure を下げる |
| wrapper-only failure | prompt を先に変える | direct route と wrapper payload/logs を比較 |
| widespread route failure | forum posts を証明にする | AI Studio status または failed surface の official owner を見る |
エスカレーションには evidence が必要です。最低限、timestamp と timezone、failed route、support に共有してよい account / project identifier、最小 reproduction prompt、API なら model ID、error code、message body、request ID、screenshot、server log、same-surface retest、direct-route comparison を残します。
深い分岐は分類後に開く
最初の診断 board は分類用です。すべての深い問題を置き換えるものではありません。
- current outage reasoning だけなら Is Nano Banana 2 Down?。
- API 429 だけなら Gemini image 429 rate-limit guide。
- persistent 503 overload なら Fix Gemini 3 Pro Image 503 Overloaded。
- price、free access、Nano Banana 2 vs Pro cost なら Nano Banana API Pricing。
- Pro workflow context が必要なら Nano Banana Pro how to use。
実用上のルールは、branch を証明してから、その branch owner に渡すことです。
よくある質問
なぜ Nano Banana は Gemini で画像を生成しないのですか？
failed route が決まっていないことが多いです。Gemini app session、Pro redo route、prompt policy、API project limit、wrapper payload、status problem は、すべて「画像が出ない」に見えます。failed surface を選び、1 つの matching fix を行い、1 回だけ再検証します。
Nano Banana は今日落ちていますか？
forum thread や 1 つの failed prompt からは判断しません。使っている surface の official status owner を確認し、direct route を 1 つ比較します。429、403、prompt refusal、wrapper failure は live outage とは別です。
Gemini image generation の 429 は何ですか？
429 RESOURCE_EXHAUSTED は rate、quota、spend、project-limit branch です。Nano Banana down の証明ではありません。project limit owner を確認し、retry pressure を下げ、必要なら 429 branch へ移します。
Nano Banana / Gemini image errors の 503 は何ですか？
503 UNAVAILABLE は、その route が一時的に overloaded または unavailable であるという signal です。prompt や account settings を変える前に status と retry policy を確認します。続く場合は 503 overload branch に渡します。
API が失敗し、Gemini app が動くのはなぜですか？
app と API は別 contract です。API は model ID、key/project、billing、quota、payload、region で失敗し、consumer app は動くことがあります。app cache ではなく developer branch を見ます。
Gemini app が失敗し、API が動くのはなぜですか？
app route は session state、account route、Pro redo availability、UI rollout、prompt interpretation で失敗し、API は healthy なことがあります。app-session と route checks から始めます。
Nano Banana が失敗したら provider を変えるべきですか？
branch diagnosis の後です。provider route は、証明済みの API routing、billing、logs、integration ownership には役立つことがあります。Gemini app session、blocked prompt、Pro entitlement route は直しません。
support に送る前に何を保存しますか？
timestamp、route、prompt、model、error code、request ID、screenshot or logs、same-surface retest result、direct-route comparison を保存します。広い「動かない」報告よりも owner を決めやすくなります。