# Nano Banana Pro のレート制限 2026年版: Gemini Apps の上限と API クォータの違い

> 2026年3月27日時点で確認。Nano Banana Pro の答えは、Gemini Apps の redo 上限と Gemini API の project-level quota に分かれています。現在の caps、reset ルール、API 側の注意点をまとめました。

- Source: https://www.aifreeapi.com/ja/posts/nano-banana-pro-rate-limits
- Language: ja
- Published: 2026-03-27
- Updated: 2026-03-27
- Publisher: AI Free API (https://www.aifreeapi.com)

**2026年3月27日時点で、`Nano Banana Pro` にはもう一つの公開上限だけで答えられる時代ではありません。** Gemini Apps の話なら、現在の official answer は `Redo images with Nano Banana Pro` の日次 cap で、**Google AI Plus は最大 50 回/日、Google AI Pro は最大 100 回/日、Google AI Ultra は最大 1,000 回/日** です。Basic には現行の [Gemini Apps limits ページ](https://support.google.com/gemini/answer/16275805?hl=en&ref_topic=13194540) 上で Pro redo entitlement がありません。 一方、Gemini API の話なら、Nano Banana Pro は `gemini-3-pro-image-preview` を指し、現在の [rate-limits ドキュメント](https://ai.google.dev/gemini-api/docs/rate-limits) は一律の固定 RPM ではなく、**RPM、TPM、RPD、project 単位の適用、usage tier、AI Studio での live visibility** という枠組みで答えています。

このズレが、いまも検索結果を分かりにくくしている本当の理由です。古い launch coverage や古い quota guide は、Nano Banana Pro を単独の consumer product のように扱い、きれいな “1日あたり何回” に落とし込みたがります。ですが、現在の Google の first-party answer はそうではありません。Gemini Apps の support table と Gemini API の quota docs という、二つの surface に答えが分散しています。

このキーワードで一番安全な読み方は単純です。まず、自分がぶつかっているのが Gemini Apps の cap なのか、Gemini API の quota なのかを分ける。次に、その surface に対応する official rule だけを見る。最後に、2025年の launch 数字、現在の app caps、API の想像を一枚の tidy な表に混ぜているページを信用しすぎないことです。

![Nano Banana Pro の Gemini Apps 側の上限と Gemini API 側のクォータルールを左右に示した編集用カバー画像](https://www.aifreeapi.com/posts/ja/nano-banana-pro-rate-limits/img/cover.png)

## 要点まとめ

| 何を指しているか | 現在の最善の答え | なぜ重要か |
| --- | --- | --- |
| Gemini Apps の Basic | **Nano Banana Pro の redo entitlement はなく、Nano Banana 2 の image generation lane がある** | 現在の support table では **1日最大20枚** の Nano Banana 2 生成があり、Pro redo row は出てきません |
| Gemini Apps の有料プラン | **Nano Banana Pro redo cap は Google AI Plus 50/日、Google AI Pro 100/日、Google AI Ultra 1,000/日** | consumer 側で最も直接的な公式回答です |
| Gemini API | **Nano Banana Pro は `gemini-3-pro-image-preview` を意味し、active limits は project tier に依存して AI Studio で確認する** | public docs は framework を説明し、live values は AI Studio にあります |
| 日次 reset のタイミング | **Gemini Apps の image limits は daily reset、Gemini API の RPD は Pacific Time の深夜に reset** | 次に待つべきか、route を変えるべきかの判断に直結します |
| なぜ数字がまだ食い違うのか | **検索上位に launch-era coverage、旧 surface、現在の docs が混在しているから** | モデルは **2025年11月20日** に公開され、その後に official framing が変わりました |

実用ルールは短く言えます。Gemini のアプリ内で使っているなら、現在の support page を基準にする。コードで組み込んでいるなら、API rate-limits page、pricing page、AI Studio の project view を基準にする。これだけです。

## 現在の Gemini Apps における Nano Banana Pro のプラン別上限

![Gemini Apps における Nano Banana 2 の生成上限と Nano Banana Pro の再生成上限をプラン別に示した階段図](https://www.aifreeapi.com/posts/ja/nano-banana-pro-rate-limits/img/comparison.png)

Gemini Apps での current official answer は、多くの ranking page が見せているよりも繊細です。Google は現在、image usage を次の二つの行で分けています。

- `Image generation & editing with Nano Banana 2`
- `Redo images with Nano Banana Pro`

つまり、昔のように “Nano Banana Pro は1日 X 回” とだけ言うのは、もう正確ではありません。今の support table が実際に答えているのは、どのプランで Nano Banana 2 の基礎 generation lane が使え、どの有料プランでさらに Nano Banana Pro の redo lane が開くか、ということです。

| Gemini Apps のプラン | Nano Banana 2 の生成・編集 | Nano Banana Pro の redo | 実際の意味 |
| --- | --- | --- | --- |
| Basic | 最大 **20枚/日** | **明示的な Pro redo entitlement なし** | 画像生成の基礎 lane はあるが、有料 Pro redo lane はない |
| Google AI Plus | 最大 **50枚/日** | 最大 **50 redo/日** | 現在の Pro redo access に入る最小の有料入口 |
| Google AI Pro | 最大 **100枚/日** | 最大 **100 redo/日** | やや重い手動ワークに向く現在の middle tier |
| Google AI Ultra | 最大 **1,000枚/日** | 最大 **1,000 redo/日** | 現行 support table 上の最高 cap |

この official page では、数字と同じくらい重要な caveat も二つあります。

一つ目は、**Gemini Apps の limits は変更され得る** こと、アクセスは testing や availability に左右されること、そして **limits は一日の中で distributed throughout the day** されることです。だから、古いブログが大きな見出し cap を書いていても、実際の product behavior がそれと完全に一致しないことがあります。

二つ目は、image generation limits が **daily reset** されることです。support page には、上限に近づいたときや到達したときに Gemini が通知し、refresh のタイミングも知らせると書かれています。つまり、Gemini Apps 側の問題であれば、古い table を追うよりも current support page と in-product notification を頼る方が安全です。

このクエリで最も大きい修正点は、数字の更新ではなく framing の更新です。**今の Gemini Apps limits は、単一の Nano Banana Pro generation quota として表現しない方が正確です。** 現在の official wording は次の二層を分けています。

- Nano Banana 2 の generation and editing lane
- 有料プランの上に載る Nano Banana Pro redo lane

だからこそ、“Free は何回、Pro は100回、Ultra は1,000回” といった旧来の consumer framing を先頭に置く記事は、いま読むと古く見えます。2026年の current answer ではなく、2025年の shorthand を引きずっているからです。

もし実際の悩みが quota ではなく access 側なら、次に読むべきページは [Nano Banana Pro not showing in Gemini（英語）](/en/posts/nano-banana-pro-not-showing-gemini) です。機能が出ない問題と、cap に達した問題は、似て見えても同じではありません。

## 現在の Nano Banana Pro 向け Gemini API クォータルール

![Nano Banana Pro 向け Gemini API の現在のクォータ枠組みを RPM、TPM、RPD、プロジェクト単位適用、usage tier とともに示す技術図](https://www.aifreeapi.com/posts/ja/nano-banana-pro-rate-limits/img/process.png)

開発者向けの正しい official answer は、まず nickname を外すところから始まります。API での Nano Banana Pro は `gemini-3-pro-image-preview` です。現在の [models ページ](https://ai.google.dev/gemini-api/docs/models) と [image-generation ガイド](https://ai.google.dev/gemini-api/docs/image-generation) は、このモデルを 4K output、複雑な layout、強い text rendering、Google Search grounding、より高付加価値の visual asset production に向く professional lane として位置づけています。

現在の API rate-limits page は、“全プロジェクト共通の固定 RPM 表” を公開していません。代わりに Google は、limits が次の軸で測られると説明しています。

- **RPM**: requests per minute
- **TPM**: tokens per minute
- **RPD**: requests per day

そして同じページには、多くの ranking page が埋もれさせている三つの重要点もあります。

- limits は **project 単位** で適用され、API key 単位ではない
- **RPD は Pacific Time の深夜に reset** される
- active limits は **usage tier** に依存し、**Google AI Studio** で確認する

| API ルール | 現在の official answer | なぜ混乱しやすいか |
| --- | --- | --- |
| 公式 model name | `gemini-3-pro-image-preview` | nickname と model ID の対応を書かないページが多い |
| quota dimensions | RPM、TPM、RPD | 読者は単純な “1日何回” を期待しがち |
| 適用範囲 | API key ではなく project 単位 | key を増やせば pool が増えると誤解されやすい |
| reset ルール | **Pacific Time の深夜** に RPD reset | local timezone、app 側 refresh、API quota が混同されがち |
| live limits の確認場所 | **Google AI Studio** | public docs は framework を説明し、live values は dashboard 側にある |
| 保証のされ方 | **specified rate limits are not guaranteed; actual capacity may vary** | 古い blog は copied number を固定 promise のように見せがち |

Google は model-specific quota information を一部公開していますが、現在もっとも具体的なのは live RPM より Batch 側です。`gemini-3-pro-image-preview` の current public Batch API enqueued-token caps は次の通りです。

- Tier 1：**2,000,000**
- Tier 2：**270,000,000**
- Tier 3：**1,000,000,000**

現在の usage tier ladder も重要です。なぜなら、同じ query を読んでいる二人の開発者が違う limit experience をする理由を説明してくれるからです。Google の current public page は次のように書いています。

- **Free**：active project または free trial
- **Tier 1**：active billing account linked
- **Tier 2**：累計 **$100** の支払いと、最初の successful payment から **3日** 経過
- **Tier 3**：累計 **$1,000** の支払いと、最初の successful payment から **30日** 経過

さらに、limit query の裏に隠れている cost question もここで触れておくべきです。現在の [Gemini pricing ページ](https://ai.google.dev/gemini-api/docs/pricing) では、`gemini-3-pro-image-preview` に **free-tier pricing row がありません**。公開されている paid output image prices は次の通りです。

- **1K または 2K：$0.134/枚**
- **4K：$0.24/枚**

これは “私の RPM はいくつか” への直接回答ではありませんが、その次に多い質問には答えています。つまり、この Pro image model に free API lane はあるのか、という問いです。現在の pricing page を基準にすると、答えはありません。

実際にこのモデルを組み込むなら、次に読むと効率が良い companion page は [Nano Banana Pro API](/ja/posts/nano-banana-pro-api) です。setup の詰まりと quota の誤解は、たいてい同時に起きるからです。

## なぜ Nano Banana Pro の制限数値は今も食い違って見えるのか

この矛盾は、ただのノイズではありません。現実に起きた product transition の残りです。

Google の [changelog](https://ai.google.dev/gemini-api/docs/changelog) には、`gemini-3-pro-image-preview` が **2025年11月20日** に公開されたとあります。まさにその launch が、広い市場に Nano Banana Pro という nickname を定着させました。当時の launch coverage では、消費者向けの言い方で limited free use や fallback behavior が説明されていました。

その launch-era framing が検索結果に残ったまま、その後 surface が変わりました。

2026年3月の official support answer は、もはや “みんな共通の Nano Banana Pro generation quota” を中心にしていません。今の中心は次の四つです。

- Nano Banana 2 の generation and editing caps
- Nano Banana Pro の redo-image caps
- daily refresh behavior
- limits may change と distributed throughout the day という caveat

API 側でも、Google の current docs は “誰でも同じ live RPM table” をコピペする流れから離れています。強調されているのは **framework** であり、live answer は **AI Studio** にあります。

だからこそ、検索上位は今も noisy です。ユーザーは昔からの nickname で検索するのに、trustworthy answer は “どの surface にいるかを理解していること” を前提にした文書へ移っているからです。

community friction も、この confusion が今も生きていることを示しています。Reddit には最新の daily limits や cap 後の挙動を尋ねる投稿があり、Google AI Developers Forum でも 2025年12月に free-tier limit 低下と計算資源シフトが話題になっていました。これらは official policy ではありませんが、real user pain が続いていることは示しています。

この query に対する正しい editorial move は、一番大きな数字を叫ぶことではありません。**なぜ数字が surface 依存なのか**、そしてなぜ古い記事の方が current docs よりも断定的に見えるのかを説明することです。

## 上限に達したときに取るべき行動

もし **Gemini Apps** で cap に達したなら、次の行動はだいたいこのどれかです。

1. **緊急でなければ daily refresh を待つ。** support page には image limits が daily reset されると明記されています。
2. **頻繁に当たるなら Google AI plan を上げる。** app workflow 自体は問題ないのに redo cap だけが足りないなら、最も素直な解決です。
3. **古いブログにある大きな数字だけで “今の product が間違っている” と決めつけない。** Google は limits may change と distributed behavior を明示しています。

もし **Gemini API** で当たっているなら、正しい次の手順は別です。

1. **まず AI Studio を見る。** live limit answer は project-specific です。
2. **どの project が実際に request を送っているか確認する。** quota は key 単位ではなく project 単位です。
3. **現在の usage tier を確認する。** 期待できる headroom は tier によって変わります。
4. **429 は mystery outage ではなく quota signal として扱う。** error-handling 寄りの話が必要なら [Nano Banana Pro 429 error（英語）](/en/posts/nano-banana-pro-429-error) を読む方が早いです。

最もよくない動きは、二つの surface を混ぜて考えることです。Gemini Apps の daily cap は API project の throughput を教えてくれませんし、API tier の改善が app redo cap を上げることもありません。最初にこの二層を切り分けるだけで、余計な迷いをかなり減らせます。

もう一つ、production planning で重要なルールがあります。**ブログから copied した RPM number だけで本番の約束を作らないこと。** 現在の rate-limits page には、specified rate limits are not guaranteed であり actual capacity may vary と書かれています。実務上の truth は、次の三つの組み合わせです。

- public quota framework
- 自分の usage tier
- AI Studio 上の current project view

この答えは “100 RPM” のように気持ちよくはありませんが、ずっと正確です。

## Gemini Apps に残るべきか、API に移るべきか

![Gemini Apps に残るべき場合と Gemini API に移るべき場合を示した判断ボード](https://www.aifreeapi.com/posts/ja/nano-banana-pro-rate-limits/img/decision.png)

どちらを選ぶかは、単独の cap よりも workflow の性質で決まることが多いです。

| Surface | 向いていること | 主な制限の形 | cap に達した後の最適行動 |
| --- | --- | --- | --- |
| Gemini Apps | 軽い制作、手動の redo、Gemini 内での対話型作業 | プランごとの daily feature caps | refresh を待つか、Google AI plan を上げる |
| Gemini API | product build、automation、batch work、quota observability | project tier にひもづく RPM + TPM + RPD | AI Studio、tier、project usage を確認する |

**Gemini Apps** に残る方が自然なのは、次のような場合です。

- ほとんどが手動作業
- per-request observability が不要
- current daily cap の中で十分に回る

**API** に移る方が自然なのは、次のような場合です。

- コードで組み込みたい
- project-level の quota visibility が欲しい
- consumer bundle ではなく image-output ベースで cost planning をしたい
- bursty workload で manual cap がボトルネックになっている

最終的な判断文はシンプルです。**頭の中の一番大きい問いが “今日 Gemini の中であと何回できるか” なら、まだ app lane です。 “この project tier でどのくらい throughput があり、どう back off すべきか” が主題なら、もう API lane で考えるべきです。**

予算側まで含めて判断したいなら、次に続けて読む価値が高いのは [Nano Banana Pro price](/ja/posts/nano-banana-pro-price) です。rate limit confusion と pricing confusion は、ほとんどいつもセットで出てきます。

## よくある質問

**Basic でも今は Nano Banana Pro を使えますか。**

現行の Gemini Apps support table では、Basic に `redo images with Nano Banana Pro` entitlement は出ていません。Basic にあるのは Nano Banana 2 の generation and editing lane で、上限は **1日最大20枚** です。

**Gemini API の daily quota はいつ reset されますか。**

現在の rate-limits page では、**RPD は Pacific Time の深夜に reset** されると書かれています。

**なぜ Google は Nano Banana Pro に対して一つの active RPM を公開しないのですか。**

現在の public docs が、API limits を **project-tier-dependent framework** として扱い、live values を **Google AI Studio** で確認するよう案内しているからです。public page が説明しているのは rule set であって、全 project 共通の live number ではありません。

**`gemini-3-pro-image-preview` に free API tier はありますか。**

現在の pricing page では、Gemini 3 Pro Image Preview に **free-tier row がありません**。これは Gemini Apps とは別 surface で、Apps 側では有料 plan が Pro redo access を開く構造です。

**なぜ古い記事はいまも Nano Banana Pro を単純な daily limit で説明しているのですか。**

2025年後半の launch-era framing を引きずっているか、Gemini Apps と API の answer を一つの表に混ぜているからです。現在の official pages は、もっと surface-aware な答え方に変わっています。
