Claude Fable 5 の 429 rate_limit_error

実際に超えたのはどの上限か

エラーメッセージには超過した上限が記載されています。何かを変更する前に必ず読んでください。

• トラフィック急増による加速制限

  組織の利用量が急増すると、公表されているティアの数値を下回っていても加速制限によって 429 が返ることがあります。新しいワークロードをいきなり全量で稼働させるのではなく、段階的に増やし、利用パターンを安定させてください。

• 毎分の入力トークン

  Fable 5 利用者が最初にぶつかるのはたいていこの軸です。Start ティアで 500,000 ITPM（Opus 5 は 2,000,000）である一方、100 万トークンのコンテキストウィンドウが巨大なプロンプトを誘発するためです。カウントされるのは未キャッシュ分、つまり input_tokens と cache_creation_input_tokens だけで、キャッシュ読み取りは含まれません。

• 毎分の出力トークン

  Fable 5 は Start で 100,000 OTPM、Build で 300,000、Scale で 800,000 です。OTPM は実際に生成されたトークンに対してリアルタイムで評価されるため、max_tokens は計算に影響しません。高い effort での長時間の自律実行は、他モデルの短いターンよりこの軸を速く消費します。

• 毎分のリクエスト数

  Fable 5 は Start ティアで 1,000 RPM、Build で 2,000、Scale で 4,000 です。リミッターは固定時刻でリセットされるのではなく継続的に補充されるトークンバケットなので、バーストが 1 秒で 1 分ぶんの枠を使い切り、平均レートが上限を大きく下回っていても 429 が発生します。

• 意図しない認証情報でリクエストが送られている

  上限は組織レベルで適用され、ワークスペースごとにより低い上限を設定できます。環境に残った ANTHROPIC_API_KEY があると、想定とは別の低ティアのキー経由でトラフィックが流れ、そのキーの上限に当たってしまいます。

この順序で対処する

まずレスポンスを読み、次に需要を減らし、最後に上限引き上げを申請します。キャッシュを整える前に申請しても、キャッシュで得られる効果には届かないのが普通です。

1. 1

   3. プロンプトの繰り返し部分をキャッシュする

   ほとんどのモデルで cache_read_input_tokens は ITPM にカウントされません。2,000,000 ITPM の上限でキャッシュヒット率 80 パーセントなら、毎分 10,000,000 の総入力トークンを処理できます。システム指示、ツール定義、大きなコンテキスト文書、会話履歴をキャッシュしてください。

2. 2

   4. 発生源で並列度を下げる

   自前のクライアントでは同時実行数に上限を設け、ファンアウトではなくキューイングにします。Claude Code では既定値 10 の CLAUDE_CODE_MAX_TOOL_USE_CONCURRENCY を下げ、多数の並列サブエージェントを避け、大量実行のスクリプトでは /model で小さいモデルに切り替えてください。

3. 3

   2. レスポンスヘッダーから軸を特定する

   anthropic-ratelimit-requests-remaining、anthropic-ratelimit-input-tokens-remaining、anthropic-ratelimit-output-tokens-remaining と、対応する limit・reset ヘッダーを読んでください。違う軸を最適化してしまうのが、ここで最もよくある無駄です。

4. 4

   1. retry-after が示す秒数をきっちり待つ

   retry-after ヘッダーは再試行できるまでの秒数を示します。それより早いリトライは定義上失敗するため、提案ではなく下限として扱い、ワーカー群ではさらにジッターを上乗せしてください。

5. 5

   5. 実数値を添えて上限引き上げを申請する

   Claude Console の Limits ページで Request rate limit increase を使います。モデルごとの毎分入力・出力トークンのピーク値と、入力のうちキャッシュまたは繰り返しコンテキストが占めるおおよその割合を用意してください。申請はこの内容で評価されます。

関連ページ