Gemini画像APIで 429 RESOURCE_EXHAUSTED が返るとき、原因は大きく二つです。1つは、そのプロジェクトに有料の画像生成権限がまだ付いていないこと。もう1つは、Googleがプロジェクト単位で管理しているクォータ窓を使い切っていることです。2026年3月15日時点でも、現在のGemini画像プレビュー系モデルは有料ルートで扱われ、日次クォータは太平洋時間の深夜0時にリセットされ、Free から Tier 1、Tier 2、Tier 3 への移行は課金履歴に依存します。
ここで重要なのは、「とりあえず再試行を増やす」がいつも正解ではないことです。画像権限が実質 0 の状態なら、指数バックオフは同じ失敗を遅らせるだけです。逆に課金が有効なら、見るべきは RPM なのか、RPD なのか、TPM なのか、IPM なのかです。さらに、課金の反映待ちなのか、別プロジェクトの API キーを叩いているのか、実際は 503 過負荷や地域制限の 400 なのかも分けて考える必要があります。
要点まとめ
Gemini画像の 429 は、単なる一時的バーストではなく、「そのプロジェクトに画像用の有料利用権がまだない」ために起きることがあります。公式ドキュメントでは、クォータは APIキー単位ではなくプロジェクト単位、RPD は 太平洋時間の深夜0時 にリセット、Batch API は 50%割引 と別クォータプールを持つ、と整理されています。最短ルートは、正しいプロジェクトに課金が付いているか確認し、その上で再試行、待機、Batch、別ルーティングのどれが適切か決めることです。
| 症状 | 可能性の高い原因 | 最速の対処 | 回復の目安 |
|---|---|---|---|
画像リクエストがすぐ失敗し、クォータが 0 に見える | 画像の有料権限がまだ無い | 正しいプロジェクトに課金を接続して再確認 | 通常は数分、まれに数時間 |
| ピーク時だけ 429 が出る | RPM / TPM / IPM の短時間窓を消費 | ジッター付き指数バックオフと同時実行数の抑制 | 数秒から数分 |
| 半日から1日動かした後に 429 が出る | RPD を使い切った | 太平洋時間のリセット待ち、または Batch へ移動 | リセットまで待機 |
| 課金済みでも 429 が消えない | 別プロジェクト、反映遅延、Tier不足 | project ID、billing account、モデル別クォータを再確認 | 反映遅延なら数分 |
| 実際は 503 や地域制限の 400 | クォータ問題ではない | 503 は短時間再試行、400 は課金または対応地域を確認 | エラー種別次第 |
トラブルシュート: 症状別に最短の修正を選ぶ
まず最初に確認すべきなのは、今使っている API キーがどの Google Cloud プロジェクトを指しているかです。課金を A プロジェクトで有効化したのに、B プロジェクトのキーでテストを続けている、という混乱は実際によく起きます。使用量画面で画像モデルがまだ利用不可なら、再試行では直りません。
次に、課金済みなのに 429 が出る場合は、どのバケットが先に尽きているかを見ます。短時間の集中アクセスなら RPM / TPM / IPM、長時間ジョブの終盤なら RPD の可能性が高いです。量が多くないのに失敗する場合は、反映遅延、別 billing account、または画像プレビュー系モデル固有の上限を疑うべきです。
新規プロジェクトなら、初日から課金を有効にし、429 ごとに quota_limit と project ID を記録し、バックグラウンド生成は Batch API に逃がす設計が最も安定します。詳しいクォータの読み方は /en/posts/gemini-api-rate-limit-explained も参照してください。
もう一つ見落とされがちなのが、「429 と見えているが本当は別エラー」 のケースです。公式の troubleshooting では、503 は一時的な過負荷、400 は free tier 非対応地域や設定不備で起こり得ると整理されています。つまり、レスポンスコードを正確に読まずに全部 429 対策へ寄せると、必要な修正がずれてしまいます。
運用現場では、プロジェクト切り替え、課金反映、日次リセット、モデル上限のどれで詰まっているかを 5 分で切り分けられるだけで復旧速度が大きく変わります。問い合わせを減らしたいなら、まずは障害票やアラート本文に project ID、model、quota_limit、status code を残すようにしておくべきです。
2026年のGemini画像レート制限の仕組み
Gemini画像APIでは、RPM、RPD、TPM、IPM の4軸が別々に効きます。画像ワークロードでは RPM だけ見ても不十分です。公式の pricing page と live quota dashboard を見ながら、現在のモデルの実値を確認するのが前提になります。
RPM は 60 秒窓のリクエスト数、RPD は日次上限、TPM は長いプロンプトや参照画像で効きやすいトークン上限、IPM は画像生成専用の上限です。特に画像モデルでは、テキスト系の Gemini と違って「画像権限そのものが開いていない」ケースがあるため、見かけ上リクエスト数が少なくても失敗します。
2025年12月7日の調整以降、Firebase 側のドキュメントでも 429 RESOURCE_EXHAUSTED が増える可能性が明示されています。古い無料枠前提の記事が危険なのはこのためです。
また、課金ページの説明では、billable usage 自体は設定後すぐ有効になる一方、400 / 500 の失敗リクエストは課金されなくてもクォータには数えられる とされています。ここは見落としやすい点で、雑な自動再試行はコストは増えなくてもクォータだけを削る可能性があります。したがって、画像生成パイプラインでは「料金」だけでなく「クォータ消費」も別メトリクスとして監視するのが安全です。
| 課金とTierで変わるポイント | 現在の公式整理 |
|---|---|
| クォータの帰属 | APIキーではなくプロジェクト単位 |
| Tier 1 入口 | 正しいプロジェクトに課金を接続 |
| Tier 2 条件 | 累計 $250 超 + 支払い成功から 30 日 |
| Tier 3 条件 | 累計 $1,000 超 + 支払い成功から 30 日 |
| 日次リセット | RPD は太平洋時間の深夜0時 |
| Batch 経路 | 別プール、最大24時間、50%割引 |
複数 API キーを作っても、同じプロジェクトなら同じクォータバケットを共有します。容量を増やしたいなら、Tier を上げる、別プロジェクトを使う、Batch に逃がす、または別ルーティングを用意する必要があります。
5分でできる最初の修正: 指数バックオフ
いま最優先で失敗率を下げたいなら、最初のコード変更は指数バックオフです。Google の troubleshooting は 429 に対して「後で再試行」または「クォータ増加」を案内していますが、実運用では「後で」を機械的に行う手段がバックオフです。
やり方は単純で、429 が来たら短く待つ、次にまた失敗したら待ち時間を倍にする、そこへランダムなジッターを加える、という形です。これにより全ワーカーが同時に再送する「サンダリングハード」を避けられます。短時間窓の上限には効きますが、権限がゼロだったり日次上限を使い切っている場合には効きません。
Python と JavaScript の実装例は英語版と同じ構成で十分です。ポイントは、429 と RESOURCE_EXHAUSTED を拾うこと、非429エラーは握りつぶさないこと、最大待機時間を決めることです。
Gemini APIのTierアップグレード
長期的に最も効くのは Tier の見直しです。Free → Tier 1 は課金を有効にするだけで進みます。これは「画像を出せるかどうか」を左右するので、最もインパクトが大きい変化です。課金を付けたからといって月額固定費がいきなり発生するわけではなく、実際に使った分だけ請求されます。
Tier 2 は累計 $250 超 と 30日、Tier 3 は $1,000 超 と 30日 が現在の公式条件です。ここが重要で、今週中に大量スループットが必要なチームにとっては、Tier 2 や Tier 3 の時計は遅すぎます。緊急対応としては、Batch、キュー、別プロジェクト、もしくは中継レイヤーの方が先に効きます。
課金後も 429 が残るなら、project ID、billing account、モデル別クォータページ、そして raw error を再確認してください。「課金済み」の自己申告より、現在の usage dashboard の状態の方が信頼できます。
Gemini画像生成の実コスト
2026年3月15日に再確認した公式価格では、Gemini 3.1 Flash Image Preview は 512 で $0.045、1024 で $0.067、2048 で $0.101、4096 で $0.151。Gemini 3 Pro Image Preview は 1024 と 2048 が $0.134、4096 が $0.24 です。ここを知っておくと、「課金を付けるのが怖い」から「1枚あたりいくらなら許容か」という現実的な判断に変わります。
Batch API はここでも強く、50%割引 と 24時間以内の非同期処理 が公式に示されています。リアルタイム性が不要なら、コストとクォータ圧力を同時に下げられます。
| 使い方 | 月間枚数 | Flash 1024 標準 | Flash 1024 Batch | Pro 2K 標準 | Pro 2K Batch |
|---|---|---|---|---|---|
| Hobbyist | 3,000 | $201 | $100.50 | $402 | $201 |
| Startup | 15,000 | $1,005 | $502.50 | $2,010 | $1,005 |
| Production | 30,000 | $2,010 | $1,005 | $4,020 | $2,010 |
詳しい単価比較は /en/posts/gemini-flash-image-generation-pricing と組み合わせて見ると判断しやすくなります。
スループットを伸ばす上級戦略
まず有効なのは multi-project distribution です。クォータはプロジェクト単位なので、別プロジェクトに分ければ別バケットになります。次に有効なのは Batch API。即時応答が不要なジョブを別プールへ逃がすだけで、本番トラフィックの圧力はかなり下がります。
さらに、queue / rate limiter を入れてアプリ側でバーストを吸収し、cache で似た画像生成を減らし、RPD リセット直後に重い処理を寄せるだけでも安定度は上がります。必要なら laozhang.ai のような relay を使い、モデルやベンダーを切り替えやすくする構成も選択肢になります。
非同期化できる仕事が多いチームでは、「ユーザー待ちの処理」と「後で良い処理」を分けるだけで 429 の出方が大きく変わります。サムネイル大量生成、記事用画像のバックフィル、夜間バッチなどは対話 API に置く必要がありません。最初から Batch へ送るだけで、昼間の本番系リクエストに余白が生まれます。
さらに本番運用では、どの改善が最も安いか を定期的に見直す必要があります。Tier 上昇を待つべきか、別プロジェクトを増やすべきか、あるいは relay でルーティングを単純化すべきかは、月間画像枚数、必要な即時性、運用チームの人数で答えが変わります。ここを曖昧にすると、課金だけ増えて 429 は減らない、という状態になりがちです。
公式ルートと代替ルートをどう使い分けるか
Google Cloud と直接つながる価値が高いのは、SLA、監査、社内承認、他の Google Cloud サービス連携が重要なケースです。一方、今すぐ出荷したい、30日待てない、複数モデルを一つの API で扱いたい なら、relay や aggregator の方が運用コストを下げることがあります。
重要なのは、「今必要なのは即時復旧か、長期の正式運用か」を分けて考えることです。即時復旧なら課金確認 + バックオフ + Batch。長期運用なら Tier 上昇、監視、別プロジェクト、必要に応じた別ルートです。
FAQ
無料枠で画像を何枚生成できますか？
実務上は「画像用の有料アクセスが有効になるまで、安定して使える無料枠は期待しない」が安全です。画像モデルでは、無料前提の古い情報を信用しない方が良いです。
Free から Tier 1 へはどれくらいで上がりますか？
通常は数分です。ただし新規アカウントや支払い確認が入るケースでは遅れます。1時間以上動かなければ、project ID と billing account を確認してください。
API キーを増やせばクォータも増えますか？
増えません。同一プロジェクトなら同じクォータバケットです。
Gemini の日次クォータはいつリセットされますか？
API 利用では 太平洋時間の深夜0時 です。
Batch API は本当に有効ですか？
はい。非同期前提なら、割引と別クォータプールの両方が効くため、429 対策として非常に強いです。
課金後も 429 が消えません。
別プロジェクトを叩いている、反映遅延中、Tier が足りない、またはそもそも 503 / 400 だった、のどれかが多いです。まず raw error と usage dashboard を見直してください。