Claude の Rate Exceeded: 再試行前に制限元を切り分ける

Claude API Error: Rate limit reached と表示されても、利用枠を使い切ったとは限りません。現在の Claude Code はこの大まかな文言ではなく、原因ごとに具体的なメッセージを出します（Claude Code のエラー一覧）。一方、古いバージョンでは、プランに含まれない 1M コンテキストのモデルを選んだときのような権限エラーでも "Rate limit reached" と表示していました。Claude Code の CHANGELOG では 2.1.78（VS Code で Opus を選んだときの誤表示）と 2.1.89（権限エラーを本来のメッセージで表示）で修正されています。

そのため最初にやることは、古いバージョンなら更新し、いま表示される完全なメッセージを読んで、制限を出したのがどこかを特定することです。Claude.ai の "Rate Exceeded" や、直接 API を呼んだときの 429 も同じ考え方で切り分けます。

Claude Code 以外のツールで "Rate limit reached" が出た場合は、そのツールがどの API キーやクラウドで接続しているかを確かめ、表の最終行と同じく 429 の本文とヘッダーから制限元をたどります。

止めるルールは一つです。制限元が分かるまで、API キーの差し替え、プランのアップグレード、プロバイダーやモデルの変更はしないでください。経路を変えてエラーが消えても、原因が分かったのではなく回避しただけのことがあります。例外は Opus / Sonnet の系列ごとの枠と 1M の権限で、この 2 つは /model での切り替えそのものが正しい対処です。

まず制限を出した経路を特定する

rate limit reached という文言だけでは、どの bucket が詰まったかは分かりません。api.anthropic.com への direct request なら HTTP 429、response body、rate-limit headers を見ます。Claude Code は ANTHROPIC_API_KEY が設定されていると、サブスクリプションではなくその API キーのワークスペースの制限に当たることがあります。Bedrock、Google Cloud（Vertex AI）、ゲートウェイでは、プロバイダー側の quota や tenant policy が制限元になる場合があります。

確認するのは、処理した credential、制限元の管理画面、同じ model / provider / region / prompt で一回だけ再現できるかです。

Claude Code のターミナルでこのメッセージが出たときの手順（ログイン方法、利用枠、コンテキスト、API キー）は Claude Code「Rate limit reached」の対処：どの上限か見分けて再開 で順に確認できます。表示が 500 や 529 なら Claude Codeの500・529：重複を避けてセッションを再開する手順 を見てください。

Claude.ai / Desktop は usage window を先に見る

Claude.ai、Desktop、mobile で HTTP headers がない error なら、まず product surface の limit として扱います。usage limits は一定時間で Claude をどれだけ使えるか、length limits は一つの conversation がどれだけ長くなれるかです。長い chat、大きな file、tools、Research、connectors、重い model は usage window を速く消費します。

API key の修正から始めないでください。Settings > Usage を確認し、reset time を読み、current thread が大きければ小さい新規 chat に切り替え、不要な files/tools を外します。capacity constraints は一時的な load management で、status page incident として見えない場合があります。

Direct Anthropic API は header を先に見る

Direct Anthropic API の HTTP 429 は rate_limit_error です。retry-after、anthropic-ratelimit headers、RPM、input tokens per minute、output tokens per minute が次の行動を決めます。月次の残量が見えていても、短い rolling window は詰まります。

次の request は小さく、遅く、検証しやすくします。concurrency を下げ、job を分割し、cache を使い、同じ経路で一回だけ retry します。output tokens per minute は実際に出力された量で数えるため、max_tokens を下げるだけでは枠は空きません。減らすなら出力そのものを短くします。

Claude Code は使用中の認証情報を確認する

Claude Code では /status と credential path が先です。ANTHROPIC_API_KEY が有効なら、subscription の問題ではなく API key workspace の問題かもしれません。Claude CodeのAPIキーとサブスク課金 と Claude Code API 設定：キー、settings.json、モデル、ゲートウェイの確認手順 で境界を確認してください。

usage が残っているのに止まる理由

Rate limit は単一の月次 counter ではなく rolling bucket です。長い context は input token、長い回答は output token、多数の小 request は RPM、急な増加は acceleration control に触れます。

次の request を安全に直す

一度に一つだけ変えます。jitter backoff、worker 制限、max output 低下、queue、request_id と header の logging を入れます。検証は同じ経路、同じ credential、同じ model で行います。

Provider または gateway の制限

Bedrock、Google Cloud（Vertex AI）、ゲートウェイ経由では、Anthropic Console が制限の持ち主ではないことがあります。Bedrock の上限引き上げは AWS の Service Quotas やサポート経由、Google Cloud はリージョンごとの割り当てを Cloud Console で確認し、引き上げは Google Cloud サポートに依頼します。Claude Code の Request rejected (429) で · の後ろにゲートウェイのホスト名や Too Many Requests が出ていれば、間にあるプロキシやゲートウェイが返した 429 です。provider quota、project / location limits、gateway logs を見てから上位対応に進みます。

上位対応用の証拠セット

同じ経路での再現がまだ失敗する場合、exact message、timestamp、request_id、headers、model、workspace/project/region、制限の持ち主、status result、最小 reproduction をまとめます。key、token、個人データは送らないでください。

直 API なら request_id と headers が中心です。Bedrock や Google Cloud なら project、region、quota page が中心です。ゲートウェイなら tenant、上流の接続先、どのポリシーに当たったかが中心です。この区別を先に書くと、support はどの窓口で処理すべきかを早く判断できます。

よくある質問

利用枠が残っているのに「Rate limit reached」が出るのはなぜですか？

2 つの可能性があります。古い Claude Code では、プランに含まれない 1M コンテキストのモデルを選んだときの権限エラーも "Rate limit reached" と表示していました。現在のバージョンなら Usage credits required for 1M context と表示され、/model で [1m] なしのモデルに戻せば解決します。もう一つは、月次の残量と、数分単位で回復する RPM / トークン / 急増の制限が別物であることです。

Claude の Rate Exceeded は常に直接 API の 429 ですか？

いいえ。プランの利用枠、API キーのワークスペース、クラウドのプロジェクト、ゲートウェイのどれが制限したかを先に確かめます。

調査メモには何を残すべきですか？

成功した最後の request、失敗した最初の request、現在の request を並べ、経路、credential、model、region、input size、output limit、concurrency、status result を残します。これで単なる感覚ではなく、どの bucket が変わったかを説明できます。

API key を変えるべきですか？

最初の手ではありません。/status で使用中の認証情報を確認してからです。

status が正常なら？

headers、/status、provider dashboard、gateway logs を続けて確認します。

support に送るタイミングは？

同じ経路で再現し、上の証拠セットが揃った後です。