エラーのシナリオ構築の最中（顧客向けのチャットボットや負荷の高いデータパイプラインかもしれません）に、すべてが停止してしまうことがあります。ログには、次のような特定の、いらだたしいメッセージが表示され始めます。
google.api_core.exceptions.ResourceExhausted: 429 RESOURCE_EXHAUSTED
cURLコマンドからの生のJSONレスポンスを確認すると、次のように表示されます。
{
"error": {
"code": 429,
"message": "Quota exceeded for aiplatform.googleapis.com/generate_content_requests per minute...",
"status": "RESOURCE_EXHAUSTED"
}
}
要するに、Gemini APIが交通整理を行っているような状態です。短時間のうちに大量のデータやリクエストを送信しすぎたことを意味します。これは無料枠（Free Tier）で最も一般的ですが、プロジェクトの設定が最適化されていない場合は、有料ユーザーであってもこの制限に直面する可能性があります。
分析：なぜこれが発生するのか？Googleは3つの特定の指標を使用してトラフィックを管理しています。どの指標に抵触しているかを把握することが、解決への第一歩です。
- RPM (Requests Per Minute): 1分あたりのAPI呼び出し回数。- RPD (Requests Per Day): 1日の合計許容量。UTC（協定世界時）の午前0時にリセットされます。- TPM (Tokens Per Minute): プロンプトとモデルのレスポンスの両方を含む、処理されたテキストの量。制限はモデルによって大きく異なります。例えば、Gemini 1.5 Flashの無料枠では15 RPMが許可されています。しかし、Gemini 1.5 Proの無料枠ははるかに厳しく、多くの場合わずか2 RPMに制限されています。50行のCSVを高速なループで処理すると、5秒足らずで429エラーが発生します。
クイックフィックス：エクスポネンシャルバックオフの実装リクエストをすぐに再試行しないでください。これは「群衆の殺到（thundering herd）」問題を引き起こし、ブロックされた状態が続いてしまいます。代わりに、エクスポネンシャルバックオフ（指数関数的後退）を使用します。この手法では、再試行の間隔を徐々に長くすることで、APIがクォータをリセットする時間を確保します。
Tenacityを使用したPythonの例Pythonで再試行を処理するには、tenacityライブラリが最も信頼できる方法です。複雑なループを記述しなくても、ライブラリがタイミングを管理してくれます。
import os
import google.generativeai as genai
from tenacity import retry, stop_after_attempt, wait_random_exponential, retry_if_exception_type
genai.configure(api_key="YOUR_API_KEY")
model = genai.GenerativeModel('gemini-1.5-flash')
@retry(
retry=retry_if_exception_type(Exception),
wait=wait_random_exponential(min=1, max=60),
stop=stop_after_attempt(6)
)
def generate_content_with_retry(prompt):
try:
return model.generate_content(prompt).text
except Exception as e:
if "429" in str(e):
print("Rate limit reached. Backing off...")
raise e
raise e
Node.jsの例JavaScriptでは、シンプルな非同期ヘルパーを使用できます。このバージョンでは、待機時間に「ジッター（ゆらぎ）」を少し加えています。これにより、複数のインスタンスがまったく同じミリ秒に再試行するのを防ぐことができます。
const sleep = (ms) => new Promise(res => setTimeout(res, ms));
async function callGeminiWithRetry(prompt, retries = 5) {
for (let i = 0; i [割り当て]**に移動します。- リストを「Generative Language API」でフィルタリングします。- `generate_content_requests_per_minute`を見つけます。- **[割り当てを編集]**をクリックし、ユースケースを簡単に説明します。リクエストは通常24〜48時間以内に承認されます。## 検証：修正されたか？エラーが消えたと思い込まないでください。Google Cloudの**[API とサービス] ダッシュボード**を監視しましょう。健全なプロジェクトであれば、大量の「200 OK」レスポンスが表示され、「4xx」エラーはごくわずかであるはずです。平均レイテンシが増加している場合は、バックオフのロジックが機能している証拠です。トラフィックのピーク時にリクエストを失敗させるのではなく、正常に遅延させて処理を継続できています。