# Nano Banana 2は障害中？公式ステータスと自分だけの不具合を切り分ける > このページはNano Banana 2の稼働中・停止中を固定表示しません。失敗した入口に対応する公式確認先、表示された信号、同じ条件での最小テストを組み合わせ、広い障害か自分の環境だけの問題かを判断します。 - URL: https://blog.laozhang.ai/ja/posts/is-nano-banana-2-down - Published: 2026-03-05 - Updated: 2026-07-22 - Author: LaoZhang AI Team (https://blog.laozhang.ai/ja/about) - Topic: AI 画像生成 - Tags: Nano Banana 2, Gemini 3.1 Flash Image, 障害情報, Gemini API --- Nano Banana 2が使えない時、最初に確認するのは「Nano Banana全体」ではなく、**どの入口で、何が表示され、どこまで影響しているか**です。[Googleの製品発表](https://blog.google/innovation-and-ai/technology/ai/nano-banana-2/)にある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の失敗を入口、信号、影響範囲から切り分ける判断図](https://blog.laozhang.ai/posts/ja/is-nano-banana-2-down/img/cover.png) ## まず、失敗した入口に合う公式確認先を開く Nano Banana 2は、Googleの **Gemini 3.1 Flash Image** です。Gemini APIのモデルIDは gemini-3.1-flash-image と[公式の画像生成ガイド](https://ai.google.dev/gemini-api/docs/image-generation)に記載されています。ただし、モデル名が同じでもステータスは一枚岩ではありません。 | 失敗した入口 | 最初に開く確認先 | そこで分かる範囲 | そこで分からない範囲 | |---|---|---|---| | Geminiアプリ（Web / mobile） | [Geminiアプリの問題報告手順](https://support.google.com/gemini/answer/13275746) | アプリからGoogleへ症状を送る方法 | API、Vertex AI、外部サービスの稼働状態 | | Google AI Studio / Gemini API | [Google AI Studio Status](https://aistudio.google.com/status) | API、Multimodal Live API、AI Studioに掲載された現在・過去のインシデント | Geminiアプリや外部サービス全体の状態 | | Vertex AI | [Google Cloud Service Health](https://status.cloud.google.com/) | Google Cloud / Vertex AI側のサービス状況 | consumer向けGeminiアプリの状態 | | Flow、Search、AdsなどのGoogle内機能 | その製品のヘルプまたはステータス | その製品内の経路、機能、accountに関する情報 | 同じモデルを使う別製品の状態 | | 外部の画像生成サービス、wrapper、SDK連携 | そのサービスの障害ページとsupport | 外部側のmodel alias、upload、tenant、timeout、routing | Googleの直結経路が障害中かどうか | APIのステータス画面が緑でも、Geminiアプリ、Vertex AI、外部サービスまで正常だとは限りません。逆に、外部サービスが「model error」と表示しても、それだけでGoogle側の障害とは判断できません。**公式確認先と失敗した入口を一致させる**ことが最初の分岐です。 ## 「入口 × 信号 × 影響範囲」で判断する 障害らしく見える症状でも、信号によって次の一手は変わります。特にAPIでは、HTTPコードを見ずに「落ちた」とまとめないことが重要です。[Gemini APIの公式トラブルシューティング](https://ai.google.dev/gemini-api/docs/troubleshooting)は、エラーごとに原因候補と対処を分けています。 | 見えた信号 | まず疑う範囲 | それだけでは証明できないこと | 次の一手 | |---|---|---|---| | アプリが「読み込み中」のまま、または「問題が発生しました」 | app session、account route、prompt、アプリ側の一時問題 | Gemini APIやVertex AIを含む全体障害 | 同じaccount・同じ入口で、短い非機密promptを1回だけ試す | | 400 INVALID_ARGUMENT | payload、必須field、API version | サーバー障害 | requestを直す。同じ内容では再送しない | | 400 FAILED_PRECONDITION | country、billing、project条件など、messageに示された前提 | 全地域の障害 | messageとproject設定を確認し、条件を直す | | 403 PERMISSION_DENIED | key、permission、project、access | model全体の停止 | credentialを公開せず権限を確認。同じ条件の再送を止める | | 404 NOT_FOUND | model ID、file、resource、API version | outage | 公式model IDとresourceを確認。同じrequestを繰り返さない | | 429 RESOURCE_EXHAUSTED | Gemini APIのrate、token、daily、spendなどのlimit | Google全体の停止 | responseのmessageと現在のrate limitsを読む。盲目的に再試行しない | | 500 INTERNAL | server側の一時問題、またはinput context | 全user・全surfaceへの影響 | statusを確認し、入力を縮めた検証を1回。続くなら証拠を保存 | | 503 UNAVAILABLE | 一時的なoverloadまたは利用不可 | 全surfaceのグローバル障害 | API statusを確認し、上限付きbackoff。続く503は専門ガイドへ | | 504 DEADLINE_EXCEEDED | caller timeout、request size、処理時間 | model停止 | timeoutとrequest sizeを確認し、同じ巨大requestを連投しない | | 外部サービスだけ失敗 | wrapperのalias、upload、tenant、timeout、routing | Google直結経路の障害 | 外部側のstatus/logを保存し、許可される範囲で公式経路と1回比較 | この表は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が動かない時の入口別トラブルシューティング](https://blog.laozhang.ai/ja/posts/nano-banana-not-working-gemini-image-errors)に分けています。 ### 外部サービス側の可能性が高い - 外部サービスだけが失敗し、許可された公式経路では再現しない。 - 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対策](https://blog.laozhang.ai/ja/posts/nano-banana-2-503-overloaded-fix)へ進んでください。このページでは、retry codeやcircuit breakerの実装を重複させません。 ## 問い合わせ時に渡す「障害メモ」 日本語の障害連絡では、**発生事象**、**発生日時**、**影響範囲**、**状況**を分けると、相手が再現しやすくなります。 - 発生事象： - 失敗した入口： - 発生日時・timezone： - 対象model / 機能： - error code・安全に共有できるmessage： - request ID： - 同じ入口の最小テスト結果： - 別の公式経路との比較結果： - 確認した公式statusと時刻： - 現在の影響範囲： Geminiアプリからfeedbackを送る場合、Googleの[公式手順](https://support.google.com/gemini/answer/13275746)では会話やfileが添付される場合があります。送信前に、prompt、画像、account情報に共有したくない内容がないか確認してください。 Vertex AIでは、Gemini Developer APIの表をそのまま当てはめません。障害確認には[Google Cloud Service Health](https://status.cloud.google.com/)を使い、返された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全体の障害にはなりません。**入口・信号・影響範囲をそろえ、確認できた範囲だけを結論にする**のが安全な切り分けです。 ## 参考資料 本文で参照している外部ページを、登場順に並べています。最終更新日：2026-07-22。 - [Googleの製品発表](https://blog.google/innovation-and-ai/technology/ai/nano-banana-2/) (blog.google) - [公式の画像生成ガイド](https://ai.google.dev/gemini-api/docs/image-generation) (ai.google.dev) - [Geminiアプリの問題報告手順](https://support.google.com/gemini/answer/13275746) (support.google.com) - [Google AI Studio Status](https://aistudio.google.com/status) (aistudio.google.com) - [Google Cloud Service Health](https://status.cloud.google.com/) (status.cloud.google.com) - [Gemini APIの公式トラブルシューティング](https://ai.google.dev/gemini-api/docs/troubleshooting) (ai.google.dev)