エージェントワークロードにおける429エラーの削減方法：ルーティング、リトライ、フェイルオーバーパターン

• 制限は実在する
• 制限は個々のリクエストレベルより上で適用される
• 制限は組織またはプロジェクトスコープに紐づいている
• 月間使用量が健全に見えても、短いバーストは依然として障害を引き起こし得る

このガイドでは、公式ドキュメントから検証可能な内容に焦点を当て、それを実際に429エラーを削減する本番パターンに落とし込みます。

要約

• エージェントシステムは、バーストを生成するため、シンプルなアプリよりも早く429に到達します。平滑なトラフィックではありません。
• リクエスト数だけでなく、トークンと同時実行数 の予算管理が必要です。
• リトライロジックはプロバイダーの動作に従うべきです：利用可能な場合は retry-after を使用し、利用できない場合はジッター付きバックオフを追加します。
• キュー、チェックポイント、グレースフルデグラデーションは、生のスループットと同じくらい重要です。
• 単一のアップストリーム制限バケットへの依存を減らしたい場合、ルーティングが役立ちます。

エージェントワークロードが429に異なる形で遭遇する理由

従来のアプリケーションは通常このようになります：

• 1つのユーザーリクエスト
• 1つのLLM呼び出し
• 1つのレスポンス

エージェントシステムはそのようには動作しません。以下を頻繁にトリガーします：

• 長コンテキスト推論ステップ
• ツール呼び出しのファンアウト
• マルチエージェント同時実行
• 接続を開いたままにするストリーミングレスポンス
• フォアグラウンド作業と同時に行われるバックグラウンドリトライ

プロバイダーのドキュメントが実際に述べていること

OpenAI：プロジェクトレベルの制御はバーストリスクを排除しない

実務上の意味は明確です：

• 1つのプロジェクト内で機能ごとにトラフィックを分割しても、バーストは消えない
• 一部のモデルファミリーは制限プールを共有することがある
• 高スループットのエージェントトラフィックは、クライアント側でスロットリングしなければ、無関係なリクエストを枯渇させる可能性がある

Anthropic：入力と出力の負荷は別々

Anthropicのレートリミットドキュメントは、以下を明確に区別しているため、エージェントシステムにとって特に有用です：

• RPM
• ITPM（入力トークン用）
• OTPM（出力トークン用）

エージェントシステムにとって、大きなプロンプト、長い出力、並列ツール呼び出しが予算の異なる部分に負荷をかけるため、これは重要です。

Gemini API：プロジェクトスコープは依然として共有負荷を意味する

つまり：

• 1つのプロジェクト下の複数エージェントは依然として制限を共有する
• プロジェクトレベルのティアアップグレードは役立つが、アプリ内のバースト調整は解決しない
• アクティブな制限をインフラストラクチャの制約として扱うべきであり、後付けとして扱うべきではない

実際に429エラーを削減するパターン

1. リクエスト数だけでなく、トークンの予算管理を行う

リクエストカウンターはエージェントシステムには粗すぎます。1つの長コンテキスト推論ステップが、多くの小さなリクエストよりも多くの実質的な予算を消費することがあります。

トークン認識予算を使用します：

import asyncio
import time
from collections import deque


class TokenBudget:
    def __init__(self, tpm_limit: int):
        self.tpm_limit = tpm_limit
        self.window = deque()

    async def reserve(self, estimated_tokens: int) -> None:
        now = time.time()

        while self.window and self.window[0][0] < now - 60:
            self.window.popleft()

        used = sum(tokens for _, tokens in self.window)

        if used + estimated_tokens > self.tpm_limit and self.window:
            wait_seconds = 60 - (now - self.window[0][0])
            await asyncio.sleep(max(wait_seconds, 0))

        self.window.append((time.time(), estimated_tokens))

2. エージェントループの周りに同時実行制限を設ける

多くの429ストームは自ら招いたものです。ツール呼び出し、バックグラウンドジョブ、リトライがすべて重なります。

同時実行制御を使用します：

import asyncio

agent_slots = asyncio.Semaphore(5)


async def run_agent(task):
    async with agent_slots:
        return await execute_agent(task)

これだけでは429を完全に排除できませんが、アプリ自身が1つのスパイクを全面的な崩壊に変えることを防ぎます。

3. リトライをプロバイダー認識にする

リトライレイヤーは、すべての429を同じように扱うべきではありません。

import asyncio
import random


async def retry_with_backoff(call, provider_name, attempts=5):
    for attempt in range(attempts):
        try:
            return await call()
        except Exception as exc:
            retry_after = getattr(exc, "retry_after", None)

            if retry_after is not None:
                await asyncio.sleep(float(retry_after))
                continue

            # Jittered fallback when the provider does not give a wait value
            delay = min(30, (2 ** attempt) + random.random())
            await asyncio.sleep(delay)

    raise RuntimeError(f"{provider_name} retry budget exhausted")

本番環境でのガイダンス：

• プロバイダーが返す retry-after を尊重する
• ジッター付き指数バックオフ をフォールバックとして使用し、唯一の戦略としては使用しない
• 永遠にリトライしない
• リトライ量をプライマリトラフィックとは別に追跡する

4. フォアグラウンドとバックグラウンドのキューを分離する

同じプールがユーザー向けエージェント作業とバックグラウンド分析ジョブを処理する場合、低価値のバックログが高価値トラフィックをブロックする可能性があります。

少なくとも2つのキューを使用します：

• ユーザー向けレスポンス用のフォアグラウンドキュー
• バッチまたはキャッチアップ作業用のバックグラウンドキュー

これにより、プロバイダーが代わりに行う前に、低優先度トラフィックを破棄または延期する場所ができます。

5. 長時間実行ループにチェックポイントを設ける

429エラーで20分の作業をやり直すことがないようにしましょう。

各コストの高い呼び出しの前にチェックポイントを設定します：

• 現在のタスク状態
• すでに収集済みのツール結果
• 最後に成功した推論ステップ
• リトライ回数と次回試行タイムスタンプ

これにより、429はワークフロー障害からスケジューリング遅延に変わります。

6. ハードな失敗ではなくグレースフルに劣化させる

エージェントは常にシステム内の最大モデルを必要とするわけではありません。

グレースフルデグラデーションは以下を意味する場合があります：

• より小さなコンテキストウィンドウ
• より少ない並列ツール
• より安価または高速なフォールバックモデル
• 即時実行ではなく低優先度ジョブのキューイング

適切なフォールバックはワークフローに依存しますが、アーキテクチャの原則は同じです：部分的な回答は、クラッシュしたエージェントセッションよりも通常は良い結果をもたらします。

ルーティングの位置づけ

ルーティングの正しい考え方は：

• スロットリングはアプリが何を送信するかを制御する
• リトライロジックはアプリがどう反応するかを制御する
• ルーティングは条件が変わった時にアプリが作業をどこに送れるかを制御する

シンプルなビフォーアフター表

EvoLink Smart Routerのリポジトリコピーがサポートする内容

EvoLink Smart Routerの現在のリポジトリコピーは、以下の公開可能な主張をサポートしています：

• EvoLinkは混合ワークロード向けの 自社構築ルーティングレイヤー を提供する
• モデルIDとして evolink/auto を送信できる
• 実際に使用されたモデルはレスポンスで返される
• リクエスト形式は OpenAI互換 のまま
• ルーティングレイヤー自体は個別のルーティング手数料を 追加しない

以下がリポジトリコピーがサポートするリクエスト形式です：

curl https://api.evolink.ai/v1/chat/completions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "evolink/auto",
    "messages": [
      {
        "role": "user",
        "content": "Summarize the latest deployment incident and suggest next steps."
      }
    ]
  }'

実用的なロールアウトチェックリスト

プロバイダーを責める前に、まず以下を確認してください：

FAQ

エージェントは通常のチャットアプリよりなぜ早く429に到達するのか？

エージェントはバーストトラフィックを生成するためです：長いプロンプト、ツールファンアウト、リトライ、バックグラウンドジョブ、同時実行がすべて重なります。

APIキーを増やせば問題は解決するか？

通常、それだけでは解決しません。OpenAIは組織レベルとプロジェクトレベルの制限を、Anthropicは組織レベルの制限を、Geminiはプロジェクトレベルの制限を文書化しています。同じスコープ内の追加キーは、新しいキャパシティプールを作成しません。

すべての429に対して指数バックオフを使うべきか？

スロットリングとルーティングの両方が必要か？

本番スケールで運用している場合は、はい。スロットリングはプロバイダーがリクエストを拒否する前にトラフィックを平滑化します。ルーティングは1つのアップストリームパスへの依存を減らすのに役立ちます。

429のデバッグ時に何をログに記録すべきか？

EvoLinkのようなゲートウェイはいつ有用か？

OpenAI互換のリクエスト形式を維持しながら、モデル選択と混合ワークロードルーティングをアプリコードから移したい場合に有用です。

ルーターは二度と429を見ないことを保証できるか？

いいえ。ルーターは回復力と柔軟性を向上させることができますが、クライアント側のスロットリング、リトライバジェット、キュー制御の必要性をなくすものではありません。

スケールする前にコントロールレイヤーを構築する

エージェントシステムがすでにバースト動作を示している場合、429の修正は通常、プロンプトの問題である前にインフラストラクチャの問題です。

関連記事

• AIモデルルーティングとは？
• LLM APIが標準化されていない理由
• OpenClaw 429レートリミットエラーの修正

出典

• OpenAIレートリミットガイド
• OpenAIプロジェクトレートリミットAPIリファレンス
• Anthropicレートリミット
• Gemini APIレートリミット
• EvoLink Smart Routerガイド