Gemini の画像生成に「共通で何枚まで」という 1 つの答えはありません。制限の持ち主は、Gemini Apps、Google AI Studio の Gemini API、Vertex AI のどれを使っているかで変わります。
最初に見るべきなのは数字ではなく利用面です。Gemini Apps はプランごとの 1 日上限、Gemini API はプロジェクトとモデルごとのクォータ、Vertex AI は Google Cloud のプロジェクト、リージョン、IAM、課金、運用ルールを持ちます。ここを取り違えると、待てばよい問題に API キーを増やしたり、API の 429 に対してアプリの上限表を見たりすることになります。
どの Gemini 画像制限に当たっているか
「Gemini 画像生成 制限」という悩みは、実際には複数の問題を含みます。ブラウザ版 Gemini で「今日はこれ以上作成できません」と出る人は、プランの画像生成や再生成の上限を見ています。API を呼ぶ開発者は、プロジェクト、モデル、レート、日次枠、画像出力の容量を見ています。Vertex AI を使うチームは、Cloud プロジェクトとリージョン、権限、監査、請求、クォータ申請の問題を見ています。
| 利用面 | 制限されるもの | 確認場所 | 最初の対応 |
|---|---|---|---|
| Gemini Apps | 消費者向けの画像生成、編集、再生成、プラン機能 | Gemini Apps Help とアプリ内表示 | 1 日リセットを待つ、再生成の連打を減らす、プランを確認する。 |
| Gemini API / Google AI Studio | プロジェクト、モデル、ティア、RPM、TPM、RPD、IPM | Gemini API rate limits と AI Studio の実クォータ | プロジェクトとモデルを確認し、制限、キュー、課金、クォータ申請を選ぶ。 |
| Vertex AI | Cloud プロジェクト、リージョン、IAM、ログ、課金、ガバナンス | Cloud Console と Vertex AI の制限ドキュメント | Cloud 管理が必要なワークロードだけ移す。 |
この分け方は実務上かなり重要です。Gemini Apps の上限と Gemini API のクォータは同じプールではありません。アプリで画像生成が止まっても API プロジェクトのクォータが残っている場合がありますし、API が 429 RESOURCE_EXHAUSTED を返してもアプリの画像生成は別に動く場合があります。同じプロジェクト内で API キーを複数作っても、プロジェクトのクォータが増えるわけではありません。
Gemini Apps の 1 日画像上限
Gemini Apps の上限は、消費者向けプランの機能制限として扱います。2026 年 5 月 3 日時点で確認できる Google Help では、Nano Banana 2 の画像生成と編集、Nano Banana Pro の再生成について、Basic、Google AI Plus、Google AI Pro、Google AI Ultra ごとの 1 日上限が示されています。同時に、画像生成と編集は需要が高く、制限は頻繁に変わる可能性があり、毎日リセットされるとも説明されています。
| Gemini Apps の画像機能 | Basic | Google AI Plus | Google AI Pro | Google AI Ultra |
|---|---|---|---|---|
| Nano Banana 2 の画像生成と編集 | 1 日最大 20 枚 | 1 日最大 50 枚 | 1 日最大 100 枚 | 1 日最大 1000 枚 |
| Nano Banana Pro の再生成 | 利用不可 | 1 日最大 50 枚 | 1 日最大 100 枚 | 1 日最大 1000 枚 |
この表は Gemini Apps の話です。Gemini API の RPM、TPM、RPD、IPM を説明する表ではありません。アプリ内で「今日はこれ以上画像を作成できません」と表示された場合、まず見るのは Help ページと製品内の状態です。API のクォータ画面を見ても、アプリの 1 日上限は変わりません。
対応は単純なことが多いです。リセットを待つ、同じ画像を何度も再生成しない、プランで対象機能が使えるか確認する、上限が実際のボトルネックならプラン変更を検討する。API キーを増やしたり Vertex AI に移したりする前に、そもそも消費者アプリ側の制限なのかを確認するべきです。
Gemini API の画像クォータは AI Studio で見る
Gemini Developer API の上限は、プロジェクト、モデル、ティアに結びつきます。Google の rate limits ドキュメントは、制限が API キー単位ではなくプロジェクト単位で適用されることを示しています。また、requests per minute、tokens per minute、requests per day、画像生成向けの images per minute など、別々の軸で制限がかかります。
API の画像生成が止まったときは、一般的な記事の数字ではなく AI Studio を開きます。実際に API キーを所有するプロジェクトを選び、コードが呼んでいるモデルを確認し、そのモデルの現在のレート制限を見る。preview の画像モデルを使っている場合は、通常のクォータに加えて、容量や提供条件が変わりやすい前提で設計します。
| API 側の症状 | 疑う制限 | 対応 |
|---|---|---|
| 短時間に小さなリクエストが集中して失敗する | RPM または一時的な容量 | 同時実行を落とす、キュー化する、指数バックオフと jitter を入れる。 |
| 長いプロンプト、多画像入力、重い文脈で失敗しやすい | TPM またはリクエスト負荷 | 入力を削る、分割する、再利用できる情報をキャッシュする。 |
| 1 日の後半に安定して落ちる | RPD | 日次予算を設ける、低優先度ジョブを止める、必要なら増枠申請を準備する。 |
| テキストは通るのに画像だけ詰まる | IPM または画像モデル容量 | 画像ジョブ専用キューを作る、同時生成数を下げる、待機状態を見せる。 |
プロジェクト内の複数 API キーは同じクォータを共有します。キーを回して逃げるのではなく、正面からワークロードを制御します。画像生成は同期ボタンの連打に弱い処理なので、キュー、キャッシュ、同時実行制御、リトライ上限、構造化ログを持たせるのが安定します。
価格、モデル対応、クォータを混ぜない
Gemini 画像生成の判断では、モデルが画像を生成できるか、無料または有料の API で使えるか、自分のプロジェクトにどのクォータがあるかを分ける必要があります。価格表は価格とアクセス条件を説明します。画像生成ドキュメントは呼び出し方法を説明します。rate limits と AI Studio はプロジェクトの実クォータを説明します。
2026 年 5 月 3 日時点で、Google の開発者向け価格表では gemini-3-pro-image-preview が paid-only として扱われています。これはアクセスと課金の事実です。すべてのプロジェクトの RPM や IPM がその場でわかる、という意味ではありません。
運用前の確認は、次の順番で行うと誤診を減らせます。コードが呼んでいるモデル名、利用面でそのモデルが対応しているか、free なのか paid-only なのか、API キーを持つプロジェクトはどれか、AI Studio の RPM/TPM/RPD/IPM はどう表示されているか、エラーに retryDelay や quota metric が含まれるか。この順番なら、課金問題、突発的なレート問題、日次枠、画像専用容量を分けて扱えます。
「上限に達しました」と出たときの動き方
Gemini Apps の画面で上限に達した場合は、プランの 1 日画像生成、編集、再生成の枠を使い切った可能性が高いです。リセットを待つ、再生成を減らす、プランに含まれる機能を確認する。API のクォータページを見ても、このアプリ側の制限は解消しません。
API から制限が返っている場合は、AI Studio を開きます。プロジェクトとモデルを特定し、RPM、TPM、RPD、IPM のどれが詰まっているかを見ます。短い時間の失敗ならレートリミッター、重い入力なら入力削減、日次枠なら日次予算、画像だけなら画像専用キューが基本になります。
継続的な負荷があるなら、画像生成をキュー処理として設計します。ユーザーには待機状態を表示し、バックエンドでは同時実行数、再試行回数、最終状態を管理します。プロジェクト、モデル、quota metric、request id、リトライ回数をログに残せば、後で増枠申請や障害分析に使えます。
429 RESOURCE_EXHAUSTED が返っている場合は、retryDelay を尊重し、jitter を加え、すべての worker が同時に再試行しないようにします。コード側の retry、ログ、エスカレーションは、隣接する Gemini image generation error 429 fix の分岐で扱うのが安全です。
API 429 とアプリ上限は別物
アプリの上限は消費者機能の制限です。API の 429 は、プロジェクト、モデル、ティア、クォータ軸、容量のいずれかに関する API 応答です。どちらも「Gemini が制限された」と言えますが、必要な証拠と対処は違います。
429 を見たら、先に retryDelay、quota metric、プロジェクト、モデル、billing state、request id、元のエラー詳細を保存します。RPM と RPD では待つべき時間が違います。IPM と TPM では削るべき負荷も違います。正しいメトリックがなければ、数秒待つべきなのか、当日のジョブを止めるべきなのか判断できません。
危ないのは即時リトライの連鎖です。失敗した worker が全員すぐ再試行すると、クォータ問題が自己増幅します。よりよい実装は、サーバーの待機指示を守る、指数バックオフを使う、同時実行を落とす、非重要ジョブを止める、ユーザーに待ち時間を明示する、という組み合わせです。
Vertex AI を使うべき場面
Vertex AI は Gemini の画像制限を消す魔法ではありません。Google Cloud のプロジェクト、リージョン、IAM、Cloud Logging、請求、セキュリティ、クォータ申請を使うためのルートです。価値は制限回避ではなく、Cloud の運用責任者がワークロードとクォータを管理できることにあります。
AI Studio の試作段階では、Vertex AI は設定が重くなることがあります。まず Gemini API で実際のリクエスト量、モデル、失敗率、入力サイズ、クォータ軸を測る。そのうえで、サービスアカウント、監査ログ、リージョン管理、組織課金、サポートフローが必要なら Vertex AI を選ぶのが筋です。
選択基準は「どちらが無制限か」ではありません。「この画像生成ワークロードをどの運用面で持つべきか」です。個人開発や軽いプロトタイプなら Gemini API、企業運用や Cloud ガバナンスが必要なら Vertex AI、という分け方が実用的です。
よくある質問
Gemini は 1 日に何枚まで画像生成できますか？
Gemini Apps にはプランごとの 1 日画像上限があります。2026 年 5 月 3 日に確認できる Google Help では Basic、Google AI Plus、Google AI Pro、Google AI Ultra の上限が示されています。ただし Google は制限が頻繁に変わる可能性を明記しているため、最終確認は現在の Help とアプリ内表示で行います。
Gemini API の画像生成レート制限はいくつですか？
全プロジェクト共通の 1 つの数値はありません。AI Studio でプロジェクト、モデル、ティアごとの RPM、TPM、RPD、IPM を確認します。公開ドキュメントは仕組みを説明し、実数はプロジェクト側で確認します。
Gemini API キーごとに別の画像クォータがありますか？
ありません。Gemini API の制限はプロジェクト単位です。同じプロジェクト内の複数キーは同じクォータを共有します。
課金を有効にすれば制限はなくなりますか？
なくなりません。課金はティアや paid-only モデルへのアクセス、増枠申請の前提に関係しますが、モデル、プロジェクト、容量、安全性の制限は残ります。
Nano Banana Pro は無料で画像生成できますか？
利用面で答えが変わります。Gemini Apps ではプランと日次上限の話です。Gemini API では価格表、モデルアクセス、プロジェクトクォータの話です。アプリの上限を API の料金や速度に直接置き換えない方が安全です。
画像上限に達したらどれくらい待つべきですか？
Gemini Apps なら日次リセットを待ちます。API の 429 なら retryDelay があれば従い、backoff と jitter を使います。RPD を使い切った場合は、短時間の連続リトライでは解決しません。
Gemini 画像生成の制限を回避できますか？
回避ではなく正規の制御を使います。待つ、同時実行を落とす、キュー化する、キャッシュする、正しい公式ルートを選ぶ、必要な課金を整える、正当なワークロードで増枠申請を行う。キーの使い回しや攻撃的な retry は信頼性を下げます。
429 対応はいつ必要ですか？
API が 429 RESOURCE_EXHAUSTED を返し、quota metric、retryDelay、request id などがある場合です。まず Apps、API、Vertex AI のどの制限かを分け、その後で retry、キュー、ログ、増枠を判断します。
