GEMINI LABEN
NANOLITE — Nano Banana 2 Liteが登場しました。Googleで最も速く、最もコスト効率の高いGemini Imageモデルで、軽量な画像生成を安く回したい用途に向いていますOMNIFLASH — Gemini Omni Flashがpublic previewになりました。ネイティブにマルチモーダルなモデルで、企業や開発者が独自の動的な動画ワークフローを構築できますAGENTS — Managed Agentsが拡張されました。background: trueでサーバー側の非同期実行とポーリング、リモートMCPサーバー連携、対話をまたぐ認証情報のリフレッシュに対応しますMEMORY — Memory BankのIngestEvents APIが一般提供になりました。イベントの取り込みとメモリ生成を分離し、コンテンツを継続的にストリームできますTHROUGHPUT — Provisioned Throughputで、同一モデル・同一リージョンに対して最大7件の保留オーダーを提出できるようになりましたDEPRECATE — 画像生成モデルは8月17日に、Gemini Enterprise Agent PlatformのGrok 4.1系は8月20日に停止される予定ですNANOLITE — Nano Banana 2 Liteが登場しました。Googleで最も速く、最もコスト効率の高いGemini Imageモデルで、軽量な画像生成を安く回したい用途に向いていますOMNIFLASH — Gemini Omni Flashがpublic previewになりました。ネイティブにマルチモーダルなモデルで、企業や開発者が独自の動的な動画ワークフローを構築できますAGENTS — Managed Agentsが拡張されました。background: trueでサーバー側の非同期実行とポーリング、リモートMCPサーバー連携、対話をまたぐ認証情報のリフレッシュに対応しますMEMORY — Memory BankのIngestEvents APIが一般提供になりました。イベントの取り込みとメモリ生成を分離し、コンテンツを継続的にストリームできますTHROUGHPUT — Provisioned Throughputで、同一モデル・同一リージョンに対して最大7件の保留オーダーを提出できるようになりましたDEPRECATE — 画像生成モデルは8月17日に、Gemini Enterprise Agent PlatformのGrok 4.1系は8月20日に停止される予定です
記事一覧/API / SDK
API / SDK/2026-05-31上級

429を出さずにバルク処理を速くする:Gemini APIの適応的並行度制御

数万件をGemini APIに流すバルク処理で、固定並行度はほぼ必ず429と取りこぼしを生みます。429のフィードバックで並行度を自動調整するAIMD方式を、有界ワーカープールとデッドレター、再開可能なチェックポイントのコード付きで本番設計します。

Gemini API191並行処理レート制限4バルク処理本番運用47アーキテクチャ13

プレミアム記事

429を出さずにバルク処理を速くする:Gemini APIの適応的並行度制御

深夜2時、私は40本ほどの壁紙アプリのユーザーレビューを、Gemini APIでまとめて分類するバッチを回していました。2014年から個人でアプリを作り続けてきて、レビューの本数だけは静かに積み上がります。ある晩、約3万件をいっきに流そうとして、並行数を64に設定したところ、ログが真っ赤になりました。429 RESOURCE_EXHAUSTED が連続し、半分近くが処理されないまま朝を迎えていたのです。

並行数を8まで下げると429は消えましたが、今度は完走に1時間以上かかるようになりました。速くすれば壊れ、安全にすれば遅い。この板挟みは、固定の並行数で大量のリクエストを流そうとする限り、誰もが必ずぶつかる壁だと思います。この壁を「並行数をリアルタイムに自己調整する」という発想で越える方法を、私が本番で使っているコードに沿って、順を追ってお伝えします。

固定並行度がうまくいかない理由

固定並行度の根本的な問題は、APIが受け入れられる速度が「その瞬間の状況次第で変わる」点にあります。Gemini APIのクォータは1分あたりのリクエスト数(RPM)とトークン数(TPM)の両方で効きますが、実際に429が返り始める閾値は、同じプロジェクトで動く他の処理や、リクエストごとのトークン量によって刻々と動きます。

つまり「安全な並行数」という固定値は存在しません。レビュー1件が50トークンの日もあれば、長文レビューが続いて1件2,000トークンになる日もあります。前者で快適だった並行数64は、後者では即座にTPMを溶かします。固定値は、最も重い瞬間に合わせれば遅すぎ、軽い瞬間に合わせれば壊れる。どちらに倒しても最適にはならないのです。

ここで効くのが、ネットワークの輻輳制御で長く使われてきたAIMD(Additive Increase / Multiplicative Decrease)の考え方です。うまくいっている間は並行数を少しずつ足し、429に当たったら一気に半分へ落とす。APIが返す429そのものを、最適な並行数を探すセンサーとして使うわけです。

適応的並行度制御(AIMD)の考え方

AIMDの動きは驚くほど素朴です。成功が続いたら並行上限を +1、429を受けたら現在値を ×0.5。これを繰り返すだけで、並行数はその時々の実効クォータの少し下を、のこぎり波を描きながら自動で追従します。固定値が一本の水平線なのに対し、AIMDは天井に合わせて上下する生きた線になります。

実装上の勘所は3つあります。第一に、429を受けたあとの「クールダウン」です。半減した直後にまた増やし始めると、揺り戻しで再び429を踏みます。減少から一定時間は増加を止める沈黙期間を置きます。第二に、下限と上限のガードです。並行数が1未満になると処理が止まり、青天井だとTPMを一撃で溶かします。第三に、429以外のエラー(500/503/タイムアウト)は減少のトリガーにしないことです。これらはクォータ超過ではなく一時障害なので、並行数ではなくリトライで対処すべきものです。

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること
固定並行度がなぜ429と取りこぼしを生むのかを理解し、429のフィードバックで並行度を自動調整するAIMD方式を実装できる
有界ワーカープールとセマフォで安全にスループットを上げ、失敗を捨てないデッドレターと再開可能なチェックポイントを設計できる
固定64並行から適応制御へ移したときに完走時間が42分から19分へ、429率が11%から0.3%へ改善した実測の内訳を学べる
Stripe による安全な決済 · いつでもキャンセル可能

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または
メンバーシップなら全記事が読み放題 →
シェア

お読みいただきありがとうございます

Gemini Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • コピー&ペーストで使える実装コード付き
  • 毎日新しい上級ガイドを追加
  • ¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

関連記事

API / SDK2026-06-26
Gemini API の月額上限に当てた瞬間、有料ユーザーまで止まる — Project Spend Caps の影響範囲をプロジェクト分割で閉じ込める
Project Spend Caps はプロジェクト全体を一度に止めます。無料ユーザーの暴走が有料ユーザーを巻き込まないよう、上限の影響範囲をティア別プロジェクトで分離し、約10分の遅延を埋めるソフト予算ゲートを実装する設計メモです。
API / SDK2026-05-19
Gemini API にサーキットブレーカーと段階的縮退を組み込む — 個人アプリの安定運用に効く設計の所感
個人アプリで Gemini API を本番運用していると、月に数回は確実に外部要因で詰まります。サーキットブレーカーと段階的縮退をどう設計するか、実装の骨組みと運用で詰まりやすい所を所感としてまとめます。
API / SDK2026-04-26
マルチテナント SaaS で Gemini API を安全に提供する設計 — テナント分離・課金計測・暴走防止の本番アーキテクチャ
Gemini API を複数テナントに販売する SaaS で、APIキー漏洩・無限ループによる暴走・他テナントの巻き添え障害を防ぐための実装パターンを、Python のコード付きでまとめました。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →