Nano Banana 2は障害中？公式ステータスと自分だけの不具合を切り分ける

Nano Banana 2が使えない時、最初に確認するのは「Nano Banana全体」ではなく、どの入口で、何が表示され、どこまで影響しているかです。Googleの製品発表にあるGeminiアプリ、Google AI Studio / Gemini API、Vertex AI、FlowなどのGoogle内機能は、同じ画像モデルを利用していても障害の確認先が異なります。外部サービスには、さらに別の運用主体があります。

この静的な記事だけで「現在は正常」「いま障害中」とは断定できません。次の3点を、その場の時刻とともに確認してください。

1. 入口：失敗したのはアプリ、API、Vertex AI、Google内機能、外部サービスのどれか。
2. 信号：画面の文言、HTTPステータス、エラーメッセージ、request IDは何か。
3. 影響範囲：同じ入口の最小リクエストも失敗するか。別の入口や別モデルではどうか。

公式ステータスに同じ入口のインシデントが掲載され、同じ入口で最小リクエストも失敗するなら、その入口に広い障害が起きている可能性があります。一方、外部サービスだけ、特定projectだけ、特定の画像やpromptだけが失敗する場合は、Google全体の障害とは切り離して調べます。

まず、失敗した入口に合う公式確認先を開く

Nano Banana 2は、Googleの Gemini 3.1 Flash Image です。Gemini APIのモデルIDは gemini-3.1-flash-image と公式の画像生成ガイドに記載されています。ただし、モデル名が同じでもステータスは一枚岩ではありません。

APIのステータス画面が緑でも、Geminiアプリ、Vertex AI、外部サービスまで正常だとは限りません。逆に、外部サービスが「model error」と表示しても、それだけでGoogle側の障害とは判断できません。公式確認先と失敗した入口を一致させることが最初の分岐です。

「入口 × 信号 × 影響範囲」で判断する

障害らしく見える症状でも、信号によって次の一手は変わります。特にAPIでは、HTTPコードを見ずに「落ちた」とまとめないことが重要です。Gemini APIの公式トラブルシューティングは、エラーごとに原因候補と対処を分けています。

この表はGemini Developer APIの信号から調査範囲を狭めるためのもので、原因を確定する表ではありません。429はrate-limit系ですが、返されたmessageを読まなければ、RPM、TPM、RPD、spendなどのどの条件かは決まりません。503も一時的な利用不可を示しますが、それが1つのmodel、1つのregion、1つのproduct route、またはより広い範囲かは追加確認が必要です。

最小テストは「同じ入口」で1変数だけ変える

障害を疑った時に、account、network、prompt、model、regionを同時に変えると、原因が分からなくなります。次の順番なら、余計なrequestを増やさずに影響範囲を絞れます。

1. 先に証拠を残す

失敗直後に、次の項目を保存します。

• 発生日時とtimezone（日本なら例：2026-07-22 18:30 JST）
• 失敗した入口とdevice / client
• 共有してよい範囲のerror文、HTTP code、request ID
• APIならmodel IDとprojectの識別に必要な非機密情報
• アプリなら表示された日本語文言と、どの操作で止まったか
• その時点で確認した公式statusの名称と表示時刻

API key、cookie、full request body、個人情報を含むprompt、user画像は保存用の公開スクリーンショットやforum投稿に入れません。

2. 同じ入口で小さなbaselineを1回だけ試す

Geminiアプリなら、同じaccount・同じappで、新しい会話から非機密の短い画像requestを1回試します。APIなら、同じproject・同じmodel・同じendpointで、file uploadや複雑な編集を外した最小requestを1回試します。

• baselineも同じ信号で失敗：account/projectより広い可能性は上がるが、まだ全体障害とは確定しない。
• baselineは成功し元requestだけ失敗：request、file、context、policy、parser側を優先する。
• 同じprojectだけ失敗：permission、billing、quota、regional contractを優先する。
• 外部サービスだけ失敗：wrapper ownerを優先する。

3. 必要な時だけ、別の公式経路を1回比較する

APIで503が続く場合は、許可される範囲で別の公式modelを1回比較すると、「Nano Banana 2だけ」か「そのprojectのAPI経路全体」かを絞れます。Geminiアプリだけが失敗しAPIが動く場合、app route側の問題が濃くなります。ただし、別経路の成功は元の入口の正常を証明しません。

比較は診断用です。API keyやprojectを次々に替えてquotaを回避したり、VPNやregion spoofingで利用条件をすり抜けたりしないでください。課金されるrequestを無制限に投げることも、障害確認にはなりません。

「広域障害」「経路限定」「自分側」をどう言い分けるか

サポートやチーム内で共有する時は、原因を断定する代わりに、確認できた範囲を言葉にします。

広い障害の可能性が高い

• 失敗した入口の公式statusに、該当サービスの未解決incidentがある。
• 同じ入口の最小baselineも、同じserver-side signalで失敗する。
• accountやrequest固有では説明しにくいが、確認できたsurfaceは明示できる。

報告例：18:30 JST時点、Gemini API statusにincident掲載あり。gemini-3.1-flash-imageの最小requestも503。影響範囲はGemini APIで確認中。

「Google全体が落ちている」とは書かず、確認できたsurfaceと時刻を残します。

特定model・製品経路の問題らしい

• Nano Banana 2だけが失敗し、同じ公式APIの別modelは動く。
• Geminiアプリだけが失敗し、API側に同じ症状がない。
• Flowなどの特定機能だけが止まり、他の入口は動く。

この場合は「Nano Banana 2経路」「Geminiアプリ」「Flow内の画像生成」のように、製品経路を主語にします。

account / project / request側の可能性が高い

• 400、403、404が返り、messageにrequestやpermissionの問題が示されている。
• 429が特定projectのlimit文言とともに返る。
• 最小baselineは成功し、特定prompt、file、conversationだけが失敗する。

この場合、status pageを見続けるより、該当条件を修正する方が早いです。幅広い修正手順はGeminiでNano Bananaが動かない時の入口別トラブルシューティングに分けています。

外部サービス側の可能性が高い

• 外部サービスだけが失敗し、許可された公式経路では再現しない。
• wrapperのstatusやlogにupload、timeout、model alias、tenant limitが出ている。
• 外部側が独自のmodel名を使い、公式model IDとの対応が不明。

外部サービスの表示だけでGoogleのincidentを確定せず、まず外部サービスのsupport ownerへ渡します。

再試行を止める条件

障害調査では、試行回数を増やすより、止める条件を先に決める方が安全です。

• 400 / 403 / 404：request、permission、resourceを直すまで同じ内容を再送しない。
• 429：messageとlimitを確認し、pressureを下げる。keyやprojectのローテーションで回避しない。
• 500 / 503など一時的なclass：上限付きの指数backoffとjitterだけを使う。成功するまで無限に送らない。
• 504：caller timeoutとrequest sizeを見直す。timeout延長だけで原因を隠さない。
• アプリのloading loop：同じ操作の連打を止め、最小baselineとfeedbackに切り替える。
• 外部サービスだけの失敗：Google側を推測せず、wrapperのlogとstatus ownerへ渡す。

503が同じAPI経路で継続し、実装側のretry制御まで必要になったら、Nano Banana 2の503 / overloaded対策へ進んでください。このページでは、retry codeやcircuit breakerの実装を重複させません。

問い合わせ時に渡す「障害メモ」

日本語の障害連絡では、発生事象、発生日時、影響範囲、状況を分けると、相手が再現しやすくなります。

• 発生事象：
• 失敗した入口：
• 発生日時・timezone：
• 対象model / 機能：
• error code・安全に共有できるmessage：
• request ID：
• 同じ入口の最小テスト結果：
• 別の公式経路との比較結果：
• 確認した公式statusと時刻：
• 現在の影響範囲：

Geminiアプリからfeedbackを送る場合、Googleの公式手順では会話やfileが添付される場合があります。送信前に、prompt、画像、account情報に共有したくない内容がないか確認してください。

Vertex AIでは、Gemini Developer APIの表をそのまま当てはめません。障害確認にはGoogle Cloud Service Healthを使い、返されたmessage、project、region、利用contractを保存します。継続するproject / region固有の問題はCloud Supportへ渡し、別surfaceの429説明を一般化しないでください。

最後の判断

Nano Banana 2が障害中かを判断する最短ルートは、報告数や第三者の色付きbadgeを見ることではありません。

1. 失敗した入口を特定する。
2. その入口の公式確認先を、現在時刻とともに見る。
3. exact signalを保存する。
4. 同じ入口で非機密の最小baselineを1回試す。
5. 「広い障害」「特定経路」「account/project/request」「外部サービス」のどこまで言えるかを決める。

公式statusにincidentがなくても、まだ掲載前、別surface、特定regionやproject、または外部サービスの問題は残ります。反対に、1件のforum投稿や1回の503だけではGoogle全体の障害にはなりません。入口・信号・影響範囲をそろえ、確認できた範囲だけを結論にするのが安全な切り分けです。