Gemini 429(リクエストが多すぎます)の原因:動画で起きやすい理由と6つの対処法

簡潔な回答

Geminiの「Too many requests in a short time period」は、公式に説明のないロックであり、利用上限ではありません。再送をやめる、ProからFlashに切り替える、動画生成を止めるのが対処です。2025年6月から2026年7月のGeminiコミュニティ19スレッドでは、7人が動画で遭遇し、6人が8時間以上続いたと報告しています。API版は429 RESOURCE_EXHAUSTEDです。

Three black plinths in a dark studio: a brushed silver OpenAI knot, a terracotta Claude starburst, and a rainbow glass Gemini star with a small brass hourglass standing at its base.

Geminiの「リクエストが多すぎます」エラーはどう直す?

次の6つの手順を順番に試してください。チャットを削除するものはなく、最初の3つは1分で終わります。

  1. 数分間、再送をやめる。 メッセージには「Try again later」としか出ず、再試行のたびにリクエストが1回増えます。先にプロンプトを入力欄からコピーしておきましょう。
  2. モデルをProからFlashに切り替えて、同じプロンプトを送り直します。2026年3月のスレッドでは、Proのプロンプトが3日間失敗し続けた一方、FastとThinkingのモデルは「すぐに答えが返ってきた」とのことです。
  3. 動画と画像の生成を止める。 2025年7月のスレッドの返信では、動画だけが失敗し続け、通常のチャットとDeep Researchは使えたと書かれています。
  4. gemini.google.comの左下で、設定、使用上限の順に開く。 そこに更新時刻が出ていれば利用上限に達したということで、対処はGemini usage limit reachedにまとめています。
  5. GoogleのWorkspaceステータスダッシュボードでGeminiの行を確認する。 Workspace向けのページですが、2026年6月10日のGemini障害は個人アカウントにも影響しました。
  6. ロックが1日経っても消えないときは、設定とヘルプからフィードバックを送る。 スクリーンショット、メッセージの全文、始まった時刻を添えてください。

Geminiはこのメッセージを2通りの文言で表示します。2026年にGoogleのGemini Appsコミュニティへ投稿されたスクリーンショットでは、「Too many requests in a short time period. Try again later.」(iPhone、4月)と「Too many requests in a short time period. Please try again later.」(Androidは3月、iPhoneは7月)でした。チャット欄の上に小さなバナーとして出ます。モデル名も時間も書かれていません。

Geminiのリクエストが多すぎるスレッド19件のうち7件は動画の作成中
動画を作成中Veo、無料プランと有料プラン19件中7件通常のテキストプロンプト1語だけのプロンプト、利用が少ないユーザー19件中5件Proモデルでのテキスト2.5 Proで「Hi」、2アカウント19件中3件画像を作成中iPhoneアプリ、2026年4月19件中1件別のエラーの後に再試行2026年6月10日、Googleの障害の日19件中1件記載なしメッセージのみ19件中2件1マスがGemini Appsコミュニティの1スレッド、2025年6月から2026年7月

2026年11月2日にGemini Appsコミュニティ)を検索し、タイトルか最初の投稿でGeminiアプリの「too many requests」を引用しているスレッドをすべて残しました。APIのスレッドは除いています。その結果19件になり、開始は2025年6月2日から2026年7月4日で、うち12件は2025年6月と7月に集中しています。投稿者が何をしていたか書いていない場合は、スクリーンショットから判断しました。2件は1語のテキストプロンプト(「Hi」と「Ftre」)で、1件は動画ボタンがオンになっていました。

Geminiで出ている「リクエストが多すぎます」はどのメッセージ?

文言を見れば、どの壁に当たったかが分かります。Googleはこれらの文字列の一部だけを公開しています。この表はGeminiアプリのみを対象に、どこで報告されたかを載せています。APIのエラーは後半の別の表にあります。

画面のメッセージ報告された場所示していること最初の対処
"Too many requests in a short time period. Try again later."AndroidとiPhoneのアプリ、ウェブ。Geminiコミュニティ、2025年6月から2026年7月アカウントまたは1つのモデルにかかる、公式に説明のないロック上の手順1から3
"Too many requests in a short time period. Please try again later."同じ。2026年3月と7月のスクリーンショット同じロックで、文言が少し長いもの上の手順1から3
"I couldn't do that because I'm getting a lot of requests right now. Please try again later."Geminiコミュニティのスレッド、2025年12月5日、Proで動画を作成中あなたの回数ではなく、Google側の動画の混雑空いている時間帯に動画を試す
"I'm being asked for a lot of images right now, so I can't create that for you. Can you ask again later?"Ultra契約者のスレッドで引用、2026年1月Google側の画像の混雑後でもう一度。テキストは使えます
"You've reached your video generation limit until" の後に日時Geminiコミュニティのスレッド、2025年5月19日あなたの動画の利用枠と、そのリセット時刻表示された時刻まで待つ
更新時刻付きの利用上限の通知Googleの上限ページ5時間または週ごとの利用上限有料プランならFlash-Lite、または待つ

最後の2行が決め手です。GoogleのGemini Appsの上限ページには、上限に達すると「Gemini Appsは、上限がいつ更新されるかを知らせる別の通知を出す」と書かれています。2025年5月の動画上限のメッセージは、まさにその通りでした。「Too many requests in a short time period」にはそれが一切なく、上限ページにも記載がありません。

バナーに数字付きの「Something went wrong」と出ている場合は別のエラーです。Gemini something went wrongで扱っています。

ほとんど使っていないのに、Geminiで「リクエストが多すぎます」と出るのはなぜ?

このロックは、メッセージが示すようにプロンプトの数を数えているわけではないからです。19スレッドの中には、6日間使っていなかった利用の少ないユーザーが、次の質問で出たという例がありました。ほかの2人は1語のプロンプトで出ています。このロックが何を測っているかはGoogleが公開していないため、何が引き金になるかを示す記録はスレッドだけです。

動画生成。 動画を作っていた投稿者が7人で、ほかのどのグループより多くなりました。Googleの上限ページは動画が重い理由を「動画は一般に最も多くの利用量を必要とする」と説明しています。2025年6月には、投稿者が「使うのをやめて待ったのに、24時間以上たってもメッセージが戻ってくる」と書きました。このスレッドは19件の中で最多の87アップボートを集めています。

Proモデル。 3人がProでのテキストプロンプトで遭遇しました。1人は、同じ携帯の2つのGmailアカウントで同じ朝から出たと報告しています。別の1人は、FastとThinkingなら同じプロンプトにすぐ答えたと書いています。つまりロックは1つのモデルだけにかかり、ほかは使えることがあります。

Googleの障害。 19件のうち、既知の障害と時期が重なるのは1件だけです。2026年6月10日、投稿者はウェブでエラー1076、スマホでエラー13を見た後、再試行のたびに「Too many requests」が出ました。この日はGoogleのステータスダッシュボードがGeminiのプロンプトで50%のエラー率を記録した日です。障害中に再試行を重ねると、エラーの上にエラーが積み重なることがあります。

データを消してもほとんど効果はありません。投稿者はキャッシュ削除、再インストール、シークレットウィンドウ、別の端末、別のアカウントを試しましたが、19スレッドのどれにも、それで直ったという報告はありません。Googleの上限ページには「上限は、容量の制約などを理由に予告なく変わることがある」と書かれています。利用の少ないアカウントでロックがかかる理由に、Googleが最も近づいた説明はこれです。

Geminiの「リクエストが多すぎます」エラーはどれくらい続く?

Geminiのロックに、公表されている長さはありません。メッセージは「Try again later」とだけ言い、Googleは時間を示していません。スレッドで答えるボランティアは数分から1時間までさまざまに推測しますが、19人のうち6人は8時間以上続いたと報告しました。投稿者が自分のスレッドで報告した内容は次のとおりです。

スレッドの開始日投稿者がしていたこと続いた時間
2025年6月2日動画を作成中やめてから24時間以上
2025年6月4日記載なし(iPhoneアプリ)24時間以上
2025年7月14日動画を1本、Proプラン24時間たっても変化なし
2025年7月19日動画を約3本、Google AI Pro2日間
2025年7月20日動画の後にまた動画8時間後もそのまま
2026年3月3日Proでテキスト、プランなし3日間。FastとThinkingは使えた
2026年7月4日6日間使わなかった後に質問を1回定期的に再発

まず数分待ち、それから操作を変えましょう。ProからFlashへ、動画からテキストへ切り替えます。別のモデルに移っても追いかけてきて、1日たっても消えないロックは、こちらで直せるものではありません。設定とヘルプメニューの「フィードバックを送信」で報告してください。やり方はGoogleのフィードバックのページに載っています。

Google AI Proに課金すれば「リクエストが多すぎます」は止まる?

いいえ。19人のうち4人はGoogle AIの有料プランに入っていたと書いており、5人目は無料アカウントに与えられる少数のProプロンプトを使っていました。Google AI Proの有料ユーザーの1人は、動画を3本ほど作っただけで2日間ロックされました。2026年6月のスレッドでは別の投稿者が、使用量バーは減っているのに、動画を10回試して「too many requests」で失敗したと書いています。これは、Googleが2026年5月28日に9to5Googleによると「リクエストが失敗した場合、課金されません」と述べた1週間後のことです。失敗した動画でバーが減る場合は、スクリーンショットを撮ってフィードバックに添えてください。

このページを公開しているWhiziも同じ種類の制限を設けており、数字を公開しています。1ユーザーあたり、チャットは1分に10メッセージ、1時間に60メッセージで、どのプランでも同じです。エラーは「Too many requests. Please wait and try again.」と表示され、拒否されたリクエストで利用枠は減りません(Whiziのレート制限)。GeminiはClaudeやGPTと同じモデル選択画面に並びます(WhiziでGeminiを使う)。Whiziが劣る点もあります。1時間60メッセージは固定の上限で、インポートはChatGPTとClaudeのエクスポートに対応していますが、Geminiの履歴には対応していません。

Gemini APIの429 RESOURCE_EXHAUSTEDはどう直す?

指数バックオフで待って再試行し、そのうえでどの上限に当たったかを調べます。Gemini APIの429は、プロジェクトがリクエスト数、トークン数、または支出の上限を超えたか、Google側でそのモデルの容量が足りなくなったことを意味します。Googleのレート制限のページ(2026年10月28日更新)によると、上限は1分あたりのリクエスト数、1分あたりのトークン数、1日あたりのリクエスト数で測られます。さらに「レート制限はAPIキーごとではなく、プロジェクトごとに適用される」とあります。同じプロジェクトで新しいキーを作っても意味がありません。プロジェクトの現在の上限とティアはAI Studioのレート制限ページで確認でき、同じGoogleのページには有料ティアの引き上げを申請するフォームへのリンクもあります。

エラーの文言(Gemini API、2026年11月時点)発生元再試行は有効?対処
429 RESOURCE_EXHAUSTED, "You exceeded your current quota, please check your plan and billing details."Gemini API、無料ティアの割り当て(フォーラムの報告、2025年9月)ウィンドウがリセットされた後のみ1分待つ。1日の上限なら太平洋時間の午前0時まで待つ。Tier 1にするには請求先を紐づける
429 RESOURCE_EXHAUSTED, "Resource has been exhausted"(一度は "(e.g. check quota)" 付き)Gemini API、有料のTier 3プロジェクト(1月と2026年5月のフォーラム報告)有効だが遅いバックオフする。安定版のモデルに移る
支出上限での429 RESOURCE_EXHAUSTEDGemini API、Tier 1から3少し間を置けば有効安いリクエストにする、または上限の引き上げを申請する
too_many_requests, "You have made too many requests in a short period of time."Interactions APIのエラー一覧有効指数バックオフで再試行する
"Resource exhausted, please try again later."Vertex AI(現在のGemini Enterprise Agent Platform)、従量課金有効グローバルエンドポイントを使い、バックオフする
"Too many requests. Exceeded the Provisioned Throughput."Agent Platform、Provisioned Throughput超過分は従量課金で実行されるスループットを追加購入する、または超過を妨げるヘッダーを外す

見落としやすい点が3つあります。1日あたりのリクエスト数は「太平洋時間の午前0時にリセット」されるため、1日の上限は1時間では解除されません。「実験版とプレビュー版のモデルではレート制限が厳しくなる」ので、上のTier 3のスレッドとも合います。そして支出上限は10分間のローリングウィンドウで動き、Tier 1は$10、Tier 2は$50、Tier 3は$200です。Tier 2には$100の支出と3日間が、Tier 3には$1,000の支出と30日間が必要です。

再試行のループを自分で書く必要はないかもしれません。Googleのトラブルシューティングのページによると、Python SDKはすでに最大4回、約1秒から60秒の間隔で再試行します。GoogleのAPIエラーのページには、アプリとほぼ同じ文言のtoo_many_requestsコードが載っています。このコードはInteractions APIのものです。Vertexについては、Googleの429のページにもう1つ対処があり、リージョンのエンドポイントではなくグローバルエンドポイントを使います。

Gemini CLIにも、素の「429 Too Many Requests」が出ます。2026年4月のGitHub issueでは、Googleでサインインしたgoogle AI Proの契約者がバージョン0.36.0で遭遇しました。Gemini CLIのメンテナーは3日後に重複としてクローズしています。CLIの1日あたりのリクエスト上限と、Proを使い切ったときの挙動はGemini usage limit reachedにあります。

チェックリスト
  • プロンプトをコピーし、数分間は再送をやめる。再試行のたびにリクエストが1回増えるため。
  • 同じプロンプトをProではなくFlashで送り直す。
  • 動画と画像の生成を止め、テキストのプロンプトを送る。
  • 設定、使用上限の順に開く。そこに更新時刻があれば、このロックではなく利用上限。
  • ほかの操作をする前に、GoogleのWorkspaceステータスダッシュボードでGeminiの行を確認する。
  • APIでは、上限はキーごとではなくプロジェクトごとに適用され、1日の上限は太平洋時間の午前0時にリセットされると覚えておく。

よくある質問

Geminiの「リクエストが多すぎます」は、利用上限に達したのと同じ?

いいえ。Googleによると、利用上限には更新時刻を知らせる通知が付き、設定の使用上限で確認できます。「Too many requests in a short time period」には時間が書かれておらず、2026年11月2日に確認した範囲ではGoogleのヘルプページにも載っていません。ProからFlashへ、または動画からテキストへ切り替えてください。

1つ質問しただけなのに、Geminiで短時間にリクエストが多すぎますと出るのはなぜ?

このロックはプロンプトの数だけを数えているわけではないからです。Googleのコミュニティの投稿者は、6日間使わなかった後、1語のプロンプト、Proモデルだけの利用で遭遇しています。何を測っているかはGoogleが明らかにしていません。モデルを変え、数分待ち、1日続くなら報告してください。

新しいAPIキーを作れば、Geminiの429エラーは直る?

いいえ。Googleのレート制限ページには、上限は「APIキーごとではなく、プロジェクトごとに適用される」とあり、同じプロジェクトの2本目のキーも同じ割り当てを共有します。1分待つか、1日の上限なら太平洋時間の午前0時まで待つか、請求先アカウントを紐づけてプロジェクトをTier 1にしてください。