Nano Banana画像生成APIはなぜQPSではなくRPMを使用するのか：同期呼び出しモードにおけるレート制限の本質的解析

作者注：Nano Banana Pro や Nano Banana 2 といった画像生成 API において、なぜレート制限の指標として QPS ではなく RPM が採用されているのか。Gemini の同期呼び出しにおけるブロッキング特性を紐解きながら、両指標の適用シーンの違いを解説します。

テキスト生成の LLM API を利用したことがある方なら、QPS（1秒あたりのクエリ数）という指標に馴染みがあるかもしれません。しかし、Nano Banana Pro や Nano Banana 2 のような画像生成 API になると、公式ドキュメントで語られるのは専ら RPM（1分あたりのリクエスト数）です。なぜ画像生成 API では QPS を語らないのでしょうか？ これは単なる命名の好みではなく、画像生成特有の同期ブロッキング呼び出しという仕組みが、このシーンにおいて QPS をほぼ無意味なものにしているからです。本記事では、その技術的な背景を詳しく解説します。

核心的価値: 本記事を読めば、API の種類によってなぜ RPM と QPS の本質的な違いが生まれるのか、そして Gemini の画像 API の同期呼び出しモードにおいて、なぜ QPS が「偽の命題」となってしまうのかが理解できます。

RPM と QPS の核心ポイント

結論から先にお伝えします。画像生成 API において QPS ではなく RPM を使用するのは、同期呼び出しのブロック時間が非常に長いため、QPS に実質的な意味がないからです。

概念	定義	適用シーン	画像生成 API への適用
QPS	1秒あたりのクエリ数（Queries Per Second）	ミリ秒単位で応答する高頻度サービス	不適
RPS	1秒あたりのリクエスト数（Requests Per Second）	QPS とほぼ同義	不適
RPM	1分あたりのリクエスト数（Requests Per Minute）	秒〜分単位で応答する低速サービス	適
IPM	1分あたりの画像生成数（Images Per Minute）	画像生成専用	最適
RPD	1日あたりのリクエスト数（Requests Per Day）	クォータ管理	適

なぜ画像生成 API において QPS が無意味なのか

この問題を理解する鍵は、Gemini 画像生成 API の同期呼び出しという特性にあります。

Nano Banana 2 で画像を生成する際、API は同期ブロック状態になります。リクエストを送信すると、HTTP 接続が維持されたまま、画像生成が完了するまで（13〜170秒）クライアントは応答を待ち続けます。この間、接続は何もせず、ただ待機しているだけです。

比較してみましょう：

Claude API（テキスト）：最初のトークンが 50〜200ms で返され、ストリーミングで転送されるため、1秒以内に有用な結果が得られます。
Nano Banana 2（1K 画像）：最短でも 13秒かかり、その間接続は完全にブロックされます。

したがって、画像生成 API において「1秒間に何件のリクエストを処理できるか」（QPS）という問い自体が成立しません。なぜなら、1つのリクエストだけで 13秒以上を占有する可能性があるからです。RPM を指標にするのが合理的です。

🎯 例え: QPS はファストフード店が1秒間に何食提供できるかを測るようなものです。一方、RPM は高級レストランが1時間で何組の客をさばけるかを測るようなものです。コース料理に30分かかる高級レストランの効率を「1秒あたりの提供数」で測ることはありませんよね。
APIYI (apiyi.com) を経由して Nano Banana 2 を呼び出す場合、RPM は公式制限を受けず、より多くのリクエストを並行処理できます。

Gemini 画像生成 API 同期呼び出しの技術詳細

これは RPM と QPS の違いを理解するための基礎となります。

Nano Banana 2 同期呼び出しのブロックプロセス

クライアントがリクエストを送信
    │
    ▼
TCP 接続確立 ──────────────────────────────────┐
    │                                          │
    ▼                                          │
サーバーがプロンプトを受信                          │ 接続を維持
    │                                          │ クライアントがブロック待機
    ▼                                          │
拡散モデルによる推論（13〜170秒）                    │
    │                                          │
    ▼                                          │
画像を base64 にエンコード                         │
    │                                          │
    ▼                                          │
応答を返却（画像データを含む）────────────────────────┘
    │
    ▼
クライアントが画像を受信

このプロセス中、クライアントのスレッドやプロセスは完全に占有されます。シングルスレッドで同期呼び出しを行う場合、1分間に送信できるリクエスト数は最大で 60 / 生成時間 となります。1K 画像（13秒）の場合、シングルスレッドの QPS は約 0.077（1秒あたり 0.077件）となり、RPM に換算するとわずか 4.6 にしかなりません。

Nano Banana 2 の解像度別ブロック時間

解像度	標準的な生成時間	シングルスレッド RPM 上限	シングルスレッド "QPS"
0.5K	約8秒	約7.5 RPM	0.125
1K	約13秒	約4.6 RPM	0.077
2K	約30秒	約2 RPM	0.033
4K	約90〜170秒	約0.4〜0.7 RPM	0.006〜0.011

おわかりいただけたでしょうか？4K 解像度では、シングルスレッドの "QPS" はわずか 0.006 です。つまり、平均して 170秒に1回しかリクエストを完了できません。このレベルでは QPS を議論することに意味はなく、RPM こそが有効な指標なのです。

RPM と QPS はそれぞれどのようなシーンに適しているか

QPS が適しているシーン

QPS（1秒あたりのクエリ数）がレート指標として意味を持つための前提条件は、**「1回のリクエストに対する応答時間が1秒を大幅に下回っていること」**です。

サービスタイプ	標準的な応答時間	QPS は意味があるか	理由
CDN / キャッシュ	1-10ms	非常に意味がある	毎秒数千のリクエストを処理可能
データベースクエリ	5-50ms	意味がある	毎秒数百のリクエストを処理可能
テキスト LLM 初回トークン	50-200ms	意味がある	毎秒 5-20 リクエストを開始可能
検索 API	100-500ms	意味がある	毎秒 2-10 リクエストを完了可能

RPM が適しているシーン

RPM（1分あたりのリクエスト数）がレート指標としてより合理的になるのは、**「1回のリクエストに対する応答時間が秒単位から分単位に及ぶ場合」**です。

サービスタイプ	標準的な応答時間	なぜ RPM を使うのか	Gemini 公式制限
画像生成	8-170 秒	1秒以内にリクエストを完了できない	RPM + IPM
動画生成	30-300 秒	1リクエストで分単位の時間を占有する	RPM
バッチデータ処理	分単位	タスクの粒度が秒単位より大きい	RPM + RPD
ファイル変換	5-60 秒	1回の処理に時間がかかる	RPM

Gemini 画像生成 API の4次元レート制限

Google は Gemini 画像生成 API に対して4つの次元でレート制限を設けており、いずれか一つでも超過すると制限がかかります。

次元	意味	無料枠	Tier 1（有料）
RPM	1分あたりのリクエスト数	5-15	150-300
TPM	1分あたりのトークン数	制限あり	高め
RPD	1日あたりのリクエスト数	20-100	1,000+
IPM	1分あたりの画像数	制限あり	高め

IPM（1分あたりの画像数）に注意してください。これは画像生成専用に設計された指標です。1つのリクエストで複数の画像を生成する場合があるため、RPM と IPM は単純な1対1の関係ではありません。

画像生成 API の実効スループットを向上させる方法

RPM（1分あたりのリクエスト数）の本質を理解したところで、次の課題は「RPM制限下で画像生成効率を最大化するにはどうすればよいか」です。

マルチスレッド並列処理と RPM 上限の計算

例えば、1分間に 1K サイズの画像を 20 枚生成する必要があるとします：

シングルスレッド RPM = 60秒 / 13秒 ≈ 4.6 枚/分
必要なスレッド数 = 20 / 4.6 ≈ 5 つの並列スレッド

ただし、5 つの並列スレッドの合計 RPM（約 23 RPM）が、アカウントの RPM クォータを超えないように注意する必要があります。無料枠は 5〜15 RPM、Tier 1 の有料枠でも 150〜300 RPM 程度です。

画像生成 API の並列化最適化のヒント

最適化戦略	効果	推奨シーン
マルチスレッド/コルーチン並列化	線形向上（RPM制限あり）	リアルタイム生成
Batch API 非同期	ブロックなし + 50%オフ	遅延許容のバッチ処理
解像度の引き下げ	1枚あたりの時間短縮 → RPM向上	プレビュー、サムネイル
APIYI 中継サービス	公式RPM制限の突破	高負荷な本番環境
クライアントのタイムアウト設定	無駄な待機を回避	全シーン（1Kは300秒、4Kは600秒推奨）

🎯 実践的なアドバイス: 高負荷な画像生成が必要な場合、APIYI (apiyi.com) を経由して Nano Banana 2 を呼び出すのが最もシンプルな解決策です。公式の RPM 制限を受けず、28% の割引価格で利用でき、4K 固定価格はわずか $0.045 です。

よくある質問

Q1: 非同期並列で 10 個のリクエストを送った場合、RPM はいくつになりますか？

10 と計算されます。RPM は 1 分間に送信したリクエスト数をカウントするものであり、それらのリクエストが既に返ってきているかどうかは関係ありません。非同期並列で同時に 10 個のリクエストを送信しても、それぞれが 13 秒間ブロックされて順次返ってくる場合、これら 10 個のリクエストはすべて同じ 1 分間の RPM にカウントされます。したがって、マルチスレッド並列化はスループットを向上させますが、RPM クォータを回避することはできません。

Q2: Gemini Batch API は非同期ですか？RPM を回避できますか？

はい。Gemini Batch API は非同期モードです。リクエストのバッチを送信すると即座にタスク ID が返され、クライアントをブロックしません。タスクはバックグラウンドで処理され、完了後に通知を受け取って結果を取得します。Batch API には独立したクォータ（トークン数ベース）があり、リアルタイムの RPM クォータを消費せず、価格も 50% 安価です。欠点はリアルタイム性が保証されないことで、「急がない」バッチ処理に適しています。

Q3: OpenAI の chatgpt-image-latest も同期ブロックされますか？

はい。chatgpt-image-latest も同期呼び出しであり、応答時間は約 44〜60 秒です。開発者コミュニティでは gpt-image-1 のタイムアウト問題が頻発していると報告されており、少なくとも 300 秒のタイムアウト設定が推奨されています。そのため、OpenAI の画像 API も RPM をレート制限の指標としており、ロジックは Gemini と同じです。同期ブロックの応答時間が長すぎるため、QPS（1秒あたりのクエリ数）は意味を成しません。

Q4: APIYI はどのようにして公式の RPM 制限を突破するのですか？

APIYI は、マルチアカウントプールによるローテーションメカニズムを採用しています。プラットフォームが複数の Gemini API アカウントを管理し、クライアントからのリクエストを自動的に異なるアカウントへ割り振るため、各アカウントが個別の RPM クォータを保持します。開発者にとっては、自分で複数の API キーを管理することなく、実質的に RPM が大幅に向上した状態となります。さらに、28% の割引と 4K 固定価格 $0.045 という価格メリットも享受できます。

まとめ

Nano Banana 画像生成 API において、QPS（1秒あたりのリクエスト数）ではなく RPM（1分あたりのリクエスト数）が採用されている主な理由は以下の通りです。

同期ブロッキングが指標を決定: Gemini の画像生成 API は同期呼び出しであり、1つのリクエストに 13〜170 秒のブロッキングが発生します。1秒以内に1つのリクエストすら完了しないため、「1秒」という粒度の QPS は意味をなさず、RPM（1分間）が合理的な指標となります。
低速サービスには RPM、高速サービスには QPS: シンプルな判断基準として、レスポンスが 1秒未満なら QPS、1秒以上なら RPM を使用します。画像生成、動画生成、ファイル変換などはすべて RPM が適したシナリオです。
スループット向上の鍵は「並行処理 + クォータ」: マルチスレッドによる並行処理でスループットを線形に向上させることができますが、RPM クォータの制限を受けます。APIYI のマルチアカウントプールによるローテーション機能を利用すれば、単一アカウントの RPM 上限を突破可能です。

Nano Banana 2 の呼び出しには、公式の RPM 制限を受けず、28% オフの割引価格（4K 固定価格 $0.045）で利用できる APIYI (apiyi.com) を推奨します。

📚 参考資料

Gemini API Rate Limits: 公式レート制限ドキュメント
- リンク: ai.google.dev/gemini-api/docs/rate-limits
- 説明: RPM、TPM、RPD、IPM の4つの次元における制限の完全な説明
Nano Banana Pro 同期 vs 非同期 API 比較: 2つの呼び出しモードの技術的な違い
- リンク: help.apiyi.com/en/nano-banana-pro-sync-async-api-comparison-en.html
- 説明: ブロッキング時間、タイムアウト設定、スループット計算について
OpenAI Rate Limits: OpenAI のレート制限ドキュメント（RPM 体系）
- リンク: developers.openai.com/api/docs/guides/rate-limits
- 説明: Gemini と OpenAI のレート制限設計思想の比較
APIYI ドキュメントセンター: RPM 制限を突破する画像生成 API 接続
- リンク: docs.apiyi.com
- 説明: Nano Banana 2 の高並行接続と割引価格について

著者: APIYI 技術チーム
技術交流: コメント欄での議論を歓迎します。その他の資料は APIYI ドキュメントセンター (docs.apiyi.com) をご覧ください。

Nano Banana画像生成APIはなぜQPSではなくRPMを使用するのか：同期呼び出しモードにおけるレート制限の本質的解析