「temporarily limiting requests」の意味 — Claude Codeの一時的なサーバー制限

API Error: Server is temporarily limiting requests (not your usage limit) — このメッセージは、プランの利用枠やAPIキーのレート制限とは別に、API側がかけた短時間の制限を意味します。メッセージ自体に「not your usage limit」と入っている通り、枠を使い切ったサインではありません。まず少し待って再試行し、続くようならAPIの稼働状況を見るのが基本の対処です。

「Server is temporarily limiting requests」が示すもの

このエラーは、アカウントやプランに紐づく上限とは別に、APIが一時的にかけた短時間の制限(スロットル)です。Claude Codeは、実際のプラン上限による制限とこの一時制限を、レスポンスに付くヘッダーの有無で区別しています。本物の利用上限に達したレスポンスには統一クォータのヘッダーが付きますが、この一時制限にはそれが付きません。

/usageで見た枠に余裕があるのにこのメッセージが出ても、矛盾ではありません。両者は別々の仕組みで、片方が空いていてももう片方で止まることがあります。

画面の文言から原因を切り分ける

Claude Codeが止まったときの文言は複数あり、同じ「制限」でも意味と対処が違います。

429という同じ系統のエラーコードでも、「待てば戻るもの」と「枠を足すか、リセットまで戻らないもの」が混在します。使用量上限とレート制限の全体像はClaude rate limitエラーの対処で扱っています。

利用枠の上限は文言にリセット時刻が付く

「You've hit your session limit」「You've hit your weekly limit」には、リセット時刻が付きます。セッションと週次の上限は全モデルで共通なので、モデルを切り替えても回復しません。Opusの上限とSonnetの上限はそれぞれのモデルファミリーにだけ掛かり、/modelでファミリー外のモデルに切り替えれば作業を続けられます。

この一時制限の文言には、リセット時刻が付きません。表示の違いが、どちらに当たったかを見分ける最初の手がかりです。

429は発生元で対処が変わる

「Request rejected (429)」は、自分のAPIキーやBedrock・Google Cloudプロジェクトに設定されたレート制限に当たったときの表示です。API全体の混雑ではなく、使っている認証情報に紐づく制限なので、対処も別になります。

• /statusでどの認証情報が有効かを確かめる(環境に紛れ込んだANTHROPIC_API_KEYが、サブスクリプションでなく低いティアのキーで通信させることがあります)
• プロバイダーのコンソールで有効な上限を見て、必要ならティアの引き上げを依頼する
• CLAUDE_CODE_MAX_TOOL_USE_CONCURRENCYを下げる、並列のサブエージェントを減らすなどで同時実行数を抑える

表示の末尾には稼働状況の確認先が続きます。Bedrock・Google Cloud・Microsoft Foundry経由ならAnthropicのステータスページでなく、そのプロバイダーのサービス状況が名前で案内されます。ANTHROPIC_BASE_URLでカスタムのエンドポイントを使っている場合は、ゲートウェイのホスト名が出ます。

自社ホストのClaude apps gatewayを経由している場合の「spend limit reached」も見た目は429ですが、原因はゲートウェイ運用者が設定した支出上限の超過です。この429にはx-should-retry: falseが付いて返るため、Claude Codeは再試行せずそのまま表示します。

プロキシやロードバランサーが独自のHTMLの429ページを返した場合は、·の後ろにそのページのタイトル(Too Many Requestsなど)が出ます。v2.1.281より前は、ページ全体のマークアップが表示されていました。

529との違いは「誰の混雑か」

「Repeated 529 Overloaded errors」は、APIが全ユーザーを合わせてキャパシティの上限にいる状態です。529も利用枠を消費せず、Claude Codeは表示の前に何度か再試行しています。

一時制限と529はどちらも待てば戻り、どちらも自動リトライの対象です。違いは、529ではv2.1.198以降、カウントダウンの下の行に稼働状況の確認先(status.claude.comなど)が出る点です。

表示されたときの動き方

エラーが画面に残ってしまった場合は、軽い手順から順に試します。

Claude Codeが自動で待ってくれる範囲

Claude Codeは、一時的な失敗を最大10回まで、間隔を指数的に伸ばしながら再試行してから、エラーを表示します。この一時制限も対象で、認証方法によらず自動で再試行されます。

リトライ中は、エラーのラベルの後ろにRetrying in Ns · attempt x/yのカウントダウンが出ます。ラベルは、ネットワーク切断・TLSハンドシェイクの失敗・レート制限のように、すぐ対処できる失敗では最初の試行から理由を示します。それ以外のエラーは最初はAPI errorと出て、再試行の途中で具体的な理由に切り替わります。

このあたりの挙動は、数バージョンのあいだに変わっています。

再試行される失敗と、されない失敗

何が対象で何が対象外かを分けておくと、「待てば戻るのか、設定を直す必要があるのか」を判断しやすくなります。

最後の2行は、待っても戻らない種類です。証明書の検証失敗はプロキシやCA証明書の設定を直す必要があり、v2.1.199より前は再試行で時間を使ったあとに表示されていました。

無人ジョブではCLAUDE_CODE_RETRY_WATCHDOGで粘る

CIなどの無人実行でこの制限に頻繁に当たるなら、粘り方を環境変数で変えられます。

export CLAUDE_CODE_RETRY_WATCHDOG=1

CLAUDE_CODE_RETRY_WATCHDOGを1にすると、429と529の容量系エラーを、CLAUDE_CODE_MAX_RETRIESの回数で打ち切らずに再試行し続けます。バックオフは最大5分までで、レスポンスにリセット時刻が付いている場合は、その時刻まで待ちます。そのため、プランの利用上限に当たったセッションも、残りの時間を待って再開します。

v2.1.199以降は、サーバーエラーやタイムアウト、接続の切断といった他の一時的な失敗の既定の再試行回数も300回(バックオフで約3時間)に上がります。CLAUDE_CODE_MAX_RETRIESを明示した場合の上限15も外れるので、回数を別に指定しなくても粘れます。

注意点は、止まる条件です。標準速度のリクエストが、支出上限や使用量クレジットの枯渇を報告する429を受けたときは、ウォッチドッグを付けていても即座に失敗します。ゲートウェイの支出上限が定期的にリセットされるタイプでも同じです。

逆に、スクリプトで素早く失敗を知りたい場合は、CLAUDE_CODE_MAX_RETRIESを下げてリトライに時間を使わせない選択もあります。環境変数の一覧はClaude Code環境変数リファレンスにまとめています。

CLIでもDesktopでもWeb版でも意味は同じ

このメッセージは、CLI・Desktopアプリ・Claude Code on the webのどこで見えても同じ意味です。3つの形態はいずれも同じClaude Code CLIをラップしているため、エラーの発生条件も対処も共通です。IDE拡張などの起動元が自分で表示するラッパー固有のエラーは別ですが、API由来のこの一時制限は含まれません。

表示された環境を変えても結果は変わらないので、環境を替えるより、待つかAPIの稼働状況を見るほうが解決に近づきます。

それでも解消しないとき

自動リトライを経ても同じメッセージが出続けるなら、最初に疑うのはAPI全体の稼働状況です。大規模な障害であれば、リトライ設定をどう調整しても解消しません。確認の手順はClaude障害の確認方法にまとめています。

稼働状況が正常なら、経路の側を見ます。企業のプロキシやLLMゲートウェイを経由している構成では、エラーの発生元が経路の途中にあることもあります。ANTHROPIC_BASE_URLでゲートウェイを指定している場合は、メッセージに出るホスト名や·の後ろのタイトルが、どこが応答を返したかの手がかりになります。

まとめ

待つ長さは、表示で決まります。リセット時刻が付いていればその時刻まで、付いていない一時制限や529ならしばらく間を置いての再送です。間を置いても続くなら、稼働状況に障害が出ていないかを見ます。