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

API Error: Server is temporarily limiting requests (not your usage limit) — このメッセージは、あなたのプランの利用枠やAPIキーのレート制限とは無関係に、API側がかけた短時間の一時制限を意味します。メッセージ自体に「not your usage limit」と明記されている通り、枠を使い切ったサインではありません。待てば通ることがほとんどで、Claude Codeもバージョンによっては自動でリトライします。

「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」は、この一時制限とは別に、プランの利用枠そのものを使い切ったときに出ます。セッション枠は5時間ごと、週次上限は割り当てられた曜日と時刻にリセットされ、モデルを切り替えても回復しません(Opus専用の週次上限だけは、別モデルへの切り替えで回避できます)。「temporarily limiting requests」はこの利用枠とは無関係なので、/usageで見た枠に余裕があるのにこのメッセージが出ても、矛盾ではありません。

「Request rejected (429)」は自分のAPIキーやBedrock・Google Cloudプロジェクトに設定されたレート制限に達したときの表示で、Server is temporarily limiting requestsとは発生元が違います。こちらはAPI全体の一時的な混雑ではなく、あなたが使っているキーやプロジェクトのティアに紐づく制限です。表示の末尾に稼働状況の確認先が続きますが、Bedrock・Google Cloud・Microsoft Foundry経由の場合はAnthropicのステータスページではなく、それぞれのプロバイダーの状況ページが案内されます。まぎらわしい環境変数の混入で意図しないキーを使っていないか、/statusでどの認証情報が有効かを確認しておくと切り分けが早くなります。

自社ホストのClaude apps gatewayを経由している場合の「spend limit reached」も見た目は429ですが、原因はゲートウェイ運用者が設定した支出上限の超過で、こちらもAPI側の一時制限とは別物です。この429はスロットルではないため自動リトライの対象外で、x-should-retry: falseが明示的に付いた状態で返ってきます。

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

Claude Codeは、この一時制限をv2.1.199以降、自動的にリトライしてから画面に表示するようになりました。認証方法によらず、この挙動が適用されます。

v2.1.199より前は認証方法によって扱いが分かれていました。claude.aiのサブスクリプションでサインインしている場合、この一時制限は初回で即座にターンを失敗させていました。APIキーやEnterpriseサインインの場合だけ、当時からリトライの対象でした。現在はどちらのサインイン方法でも自動リトライが働きます。

自動リトライの対象は、指数的に間隔を伸ばしながら最大10回までです。リトライ中は画面にRetrying in Ns · attempt x/yという表示が出て、v2.1.198以降は3回目の試行から具体的な理由(レート制限であること)が表示されます。それより前のバージョンでは、最後の試行になるまで理由が明かされませんでした。

リトライの粘りを調整する

無人で長時間動かす構成では、リトライの回数と粘り方を環境変数で調整できます。

export CLAUDE_CODE_MAX_RETRIES=15
export CLAUDE_CODE_RETRY_WATCHDOG=1

CLAUDE_CODE_MAX_RETRIESはリトライ回数そのものを指定する設定で、既定は10回、v2.1.186以降は15回が上限です。CLAUDE_CODE_RETRY_WATCHDOGを1にすると、この一時制限のような容量系のエラーを、上限を気にせず粘って再試行し続けます。CI等の無人ジョブでこの制限に頻繁に当たる場合は、失敗として扱う前にこの設定を検討する価値があります。設定の一覧はClaude Code環境変数リファレンスにまとめています。

逆に、スクリプトで素早く失敗を検知したい場合はCLAUDE_CODE_MAX_RETRIESを下げて、リトライに時間を使わせない選択もできます。

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

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

つまり、CLIで様子を見て、Desktopアプリに切り替えれば別の結果になる、ということは基本的にありません。表示された環境を変えるより、待つかAPIの稼働状況を確認するほうが解決に近づきます。

それでも解消しないときに確認すること

自動リトライを何度か経ても同じメッセージが出続ける場合、待つだけでは解消しない規模の問題が起きている可能性があります。最初に確認する対象はAPI全体の稼働状況です。大規模な障害であれば、個々のリトライ設定をいくら調整しても解消しません。稼働状況の確認方法はClaude障害の確認方法にまとめています。

ネットワーク環境固有の要因も見ておく価値があります。企業のプロキシやLLMゲートウェイを経由している構成では、ゲートウェイ側が独自の制限をかけている場合があり、この一時制限とは別の原因で似た症状が出ることがあります。ANTHROPIC_BASE_URLでゲートウェイを指定している場合は、ゲートウェイの運用者に状況を確認してください。

よくある質問

プランの利用枠は減りますか

減りません。このエラーが出た時点では、プランの利用枠にはまだ到達していないと判断できます。減っているように見える場合は、別の要因(セッション枠や週次上限)が同時に起きていないか/usageで確認してください。

429と表示されないのに出ることはありますか

あります。Claude Code上ではメッセージが整形されて表示されるため、生のHTTPステータスコードが画面に出ない場面が増えています。文言で検索するほうが、原因の特定には近道です。

何回リトライされてから表示されますか

v2.1.199以降は、最大10回までの指数バックオフを経てから画面に表示されます(CLAUDE_CODE_MAX_RETRIESで回数を変更していない場合)。リトライ中はRetrying in Ns · attempt x/yという表示で経過が分かります。表示の理由部分は、v2.1.198以降なら3回目の試行から「レート制限」であることが分かる形になり、それより前のバージョンでは最後の試行になるまで理由が明かされません。

overloadedとは何が違いますか

overloadedはClaude側の一時的な混雑を示す529エラーで、Claude自体の処理能力に起因します。この一時制限は文言どおりAPI側のリクエスト受け付けを一時的に絞るもので、原因の層が異なります。どちらも待てば戻る点は共通していて、Claude Codeはどちらも自動リトライの対象にしています。

DesktopアプリとCLIで対処は変わりますか

変わりません。CLI・Desktopアプリ・Claude Code on the webは同じClaude Code CLIをラップしているため、このエラーの意味も自動リトライの挙動も共通です。どの環境で遭遇しても、待つか稼働状況を確認するという対処の方向性は同じです。

まとめ

「Server is temporarily limiting requests (not your usage limit)」は、プランの利用枠とは無関係な、API側の短時間の一時制限です。統一クォータのヘッダーが付かないレスポンスとして、本物の利用上限とは区別されています。v2.1.199以降は認証方法によらず自動リトライの対象になっていて、多くの場合は数十秒から数分待てば解消します。

無人ジョブで頻繁に当たるならCLAUDE_CODE_RETRY_WATCHDOGで粘りを増やし、リトライを重ねても解消しないなら、個々の設定より先にAPI全体の稼働状況を疑ってください。似た文言の429やoverloadedと取り違えないよう、まずメッセージそのものを読み直すところから始めると、余計な設定変更をせずに済みます。