Nano Banana Pro で HTTP 503 UNAVAILABLE が返ってきたとき、最初に信じるべきなのは message string ではなく code と status です。ここが重要なのは、gemini-3-pro-image-preview が Deadline expired before operation could complete という wording を出しながら、実際には true 503 UNAVAILABLE で返ってくるケースがあるからです。文面は timeout に見えても、それだけで 504 分岐にはなりません。
この症状で多くの troubleshooting ページが弱いのは、その矛盾を速く解いてくれないことです。503 だから retry と言うだけのページもあれば、deadline を見てすぐ timeout tuning に寄るページもあります。でもこの exact symptom で最初に必要なのは、もっと単純なことです。今やるべきことが retry なのか、timeout 調整なのか、それとも 503 のページから離れるべきなのかを、先に決めることです。
2026 年 4 月 15 日時点で、Gemini API troubleshooting guide、Gemini image generation docs、そして exact match の公式 forum threadを見直した結論は変わっていません。
- response が本当に
503 UNAVAILABLEなら、まず temporary capacity loss として扱い、same path で bounded backoff を試す。 - response が本当に
504 DEADLINE_EXCEEDED、または client 側が先に timeout したなら、timeout tuning と request load の見直しに入る。 - error が
429、400、403なら、この 503 page に居続けない。
診断を壊さないための rule も一つあります。branch を見極めるまでは、model、prompt、SDK surface、auth owner、payload shape を一度に変えないことです。そうしないと、service が回復したのか、自分が問題をすり替えたのか分からなくなります。
まず 30 秒で 503 と 504 を切り分ける
この症状を最短で読むなら、考えるべき branch は三つだけです。
503 UNAVAILABLE: temporary capacity failure。まず retry。504 DEADLINE_EXCEEDED: timeout budget mismatch。まず timeout または load の調整。429、400、403: 別ページに移るべき error class。
これは convenience のための shorthand ではありません。Google の current troubleshooting docs も、今なお 503 UNAVAILABLE と 504 DEADLINE_EXCEEDED を分けています。Nano Banana Pro の exact symptom でも、まずその split に従うのが一番安全です。message wording は「似た症状だ」と認識する助けにはなりますが、response class より上には置けません。
もし今すぐ最小の確認だけしたいなら、HTTP code を読み、status を確認し、same path で一回だけ retest してください。branch がそのまま 503 に残るのか、504 に変わるのか、それとも別の class に移るのか。それだけで次に読むべき section が決まります。
なぜ 503 なのに Deadline expired と書かれるのか
この症状がややこしいのは、message が timeout diagnosis そのものに見えることです。そのため、多くの readers は response class より literal phrase を先に検索します。ただ、この case では official forum の exact example が重要です。Nano Banana Pro image endpoint では、503 UNAVAILABLE と Deadline expired before operation could complete が同時に出た例がすでにあります。つまり、deadline wording の存在だけでは true 504 を証明しません。
この point から得るべき practical rule は一つです。literal phrase は orientation bridge として使い、final diagnosis には使わないことです。読者が「このページで合っている」と確認するためには役立ちますが、code/status split を飛ばす理由にはなりません。
なぜこれが大事かというと、first move が違うからです。true 503 branch はあくまで temporary capacity loss の branch です。true 504 branch は timeout budget と request load の branch です。wording だけで timeout tuning を始めると、service 側が自然回復しただけの 503 event に対して、関係のない variable を触ってしまう可能性があります。
true 503 capacity failure なら何をするか
response がまだ 503 UNAVAILABLE なら、最初にやるべきことは大改修ではありません。最小の手数で recovery を確認することです。
最も実用的なのは、same path で bounded backoff をかけることです。ここでいう same path とは、できるだけ同じ model、同じ route、同じ auth owner、同じ SDK surface、そして大きく変わらない request shape を保つことです。prompt を書き換えたり、SDK を変えたり、timeout を上げたり、fallback model に飛んだりするのは、その前ではありません。
retry rhythm は複雑でなくて構いません。
- 少し待って一度 retest する。
- まだ 503 なら、wait を少し伸ばしてもう一度。
- bounded な回数に達したら、さらに待つか、queue に送るか、temporary fallback に切り替えるかを決める。
bounded にする理由は、無限 retry loop にすると branch decision が曖昧になるからです。bounded retry なら、「短い capacity wobble なのか」「もう別の運用判断に移るべきか」が見えます。
注意したいのは、503 を quota problem と誤読しないことです。branch がまだ 503 のままなら、billing upgrade や client-side throttling は first move ではありません。429 RESOURCE_EXHAUSTED に変わったときに初めて rate-limit diagnosis へ移るべきです。その branch は Gemini API rate limits guide で扱っています。
true 504 または client timeout なら何をするか
timeout branch が成立するのは、response が本当に 504 DEADLINE_EXCEEDED になったときか、client が先に timeout したときです。ここで初めて timeout tuning が main move になります。
この branch では、いま解いている問題自体が違います。temporary capacity loss ではなく、timeout budget と request load のバランスが合っていないという問題です。だから対策も変わります。
最初の一手としては、次の三つで十分です。
- client timeout を合理的に引き上げる。
- request load を少し軽くする。
- そして same path で再確認する。
ここでいう「load を軽くする」は、system 全体を作り直すことではありません。timeout branch を証明できる程度に request shape を少し軽くしてみる、という意味です。目的は恒久的な quality downgrade ではなく、本当に timeout budget の問題なのかを確認することです。
重要なのは、deadline という word を含む every message に timeout advice を流し込まないことです。このページの value は、timeout-like wording と real timeout branch を切り分けるところにあります。
same path で branch を証明してから route-out する
この verification step があるからこそ、この page は generic explanation ではなく rapid-recovery guide になります。
branch を見極める retest では、できる限り同じ model、同じ route、同じ auth owner、同じ SDK surface、そして近い payload shape を保ってください。model、prompt、timeout を一度に変えると、success しても何が効いたのか分からなくなります。
retetst のあとの outcomes で重要なのは三つだけです。
-
まだ
503 UNAVAILABLEのまま。
503 capacity branch に残る。bounded retry、queueing、deliberate fallback の判断へ進む。 -
504 DEADLINE_EXCEEDEDになる、または client が再び timeout。
timeout branch に移る。 -
429、400、403に変わる。
この 503 page はここで役目を終え、別の guide に移る。
exact-error page の強さは、狭いことです。どこまでも何でも扱うのではなく、branch が変わった瞬間に clean route-out できることです。
FAQ
Deadline expired と見えたら、すぐ timeout を上げるべきですか？
いいえ。true 504 DEADLINE_EXCEEDED または confirmed client timeout のときだけです。response がまだ 503 UNAVAILABLE なら、最初は 503 branch です。
なぜ 503 なのに Deadline expired before operation could complete と書かれるのですか？
message string が final diagnosis ではないからです。その exact combination は official forum でも確認されています。だから wording は symptom bridge にはなりますが、code/status を上書きしません。
これは quota や rate limit と同じですか？
通常は違います。quota / rate-limit branch は 429 RESOURCE_EXHAUSTED です。response が 429 に変わった時点で、この page から離れるべきです。
model、prompt、timeout を一気に変えるべきですか？
いいえ。まず same path で branch を確定させてください。複数の variables を同時に動かすと diagnostic signal が消えます。
いつこのページを離れるべきですか？
response が true 504、client timeout、または 429 / 400 / 403 に変わった時です。exact-error page は狭く保たれているからこそ useful です。
最後に残すべき rule は一つ
Nano Banana Pro が 503 UNAVAILABLE を返したら、message string より先に response code と status を見ることです。Deadline expired before operation could complete という variant でも、response 自体が 504 でない限り、最初は still 503 branch です。
この rule を外さなければ、最も時間を無駄にする誤修正はかなり避けられます。