Claude Code が API Error: 529 を返したら、最初にやるべきことは「自分の利用上限に当たった」と決めつけることではありません。Anthropic の API error docs では、529 は overloaded_error と定義されています。つまり最初の問いは plan や billing ではなく、いま起きているのが live incident なのか、status は緑なのに同じ path だけ落ち続けているのか、実は 429 を見ているのか、それとも Claude Code が想定外の auth route を使っているのか、です。
最初に Claude Status を見てください。そのうえで /status と environment variables を合わせて確認し、Claude Code が実際にどの route でリクエストを送っているかを把握します。status が緑でも、次の一手は設定を大量にいじることではありません。同じ path を保ったまま短い retry か route check を一回行い、その結果だけを見ます。
status と route を確認しても同じ path がまだ 529 を返すなら、そこで初めて「ローカルで少しずつ調整する」段階を終えます。正確な error text と request_id を残し、きれいにエスカレーションしてください。Anthropic の error docs、Claude Code help、status surface は 2026-04-11 に再確認しました。その時点で公開 status は緑でしたが、それは 529 の分岐が消えたことを意味しません。次の切り分けがより狭くなるだけです。
30 秒の分岐ボード
API Error: 529 は説明記事より先に分岐判断が必要な症状です。問いは「Claude Code では一般に何が起こりうるか」ではなく、「いま自分がどの枝にいるか」と「その枝で最小の正しい一手は何か」です。最初に error code を補正してください。実際に 429 が出ているなら、このページの overload playbook を続けるべきではありません。529 なら、そのまま過負荷のルートで考えます。
| いま見えているもの | まず疑うべき owner | 最も安全な最初の一手 | 同じ path で何を確認するか | エスカレーションする境界 |
|---|---|---|---|---|
実際は 429 や usage warning で、529 ではない | rate-limit / usage branch | 529 の手順を続けず、usage / limit 側へ切り替える | 正確な code と、自分の問題が plan か API usage かを確認する | 補正後も実際の code が 529 のまま |
| Claude Status が赤い、または新しい incident が進行中 | Anthropic 側の過負荷や劣化 | ローカル設定の変更を止めて復旧を待つ | incident 解消後に同じ path を再実行する | status が緑に戻っても同じ path がまだ 529 |
| status は緑だが、同じ path が 529 を返し続ける | 一時的または局所的な過負荷 | 同じ path に対して短い bounded retry を一回行う | 余計な変数を変えずに、その path 自体が回復したかを見る | 同じ path で短い retry を重ねてもまだ 529 |
| Claude Code が API key、proxy、別 provider route を使っている可能性がある | ANTHROPIC_API_KEY、proxy path、想定違いの auth owner | /status、env variables、route config を先に見る | 想定していた route で同じリクエストを比較する | intended route に戻しても current evidence 付きで 529 が残る |
この表がページの中心です。以降の本文は、各行をもう少し確実に判断できるようにするための補助です。読者が時間を失う最大の理由は、修正手順が足りないことではなく、最初に違う枝へ入ってしまうことです。
529 は何を意味し、なぜ 429 ではないのか
Anthropic の API error docs では、429 は rate_limit_error、529 は overloaded_error です。どちらも「先へ進めない」という体感は似ていますが、最初の一手は同じではありません。
code が本当に 529 なら、まず service saturation と考えるのが安全です。つまり、status の確認、同じ route の維持、短い retry が先であり、quota や billing の議論は後です。逆に 429 なら、問題は overload より rate limit や usage interpretation に近いので、Claude Code token usage guide や Claude Code rate limit reached ガイド の方が適切です。
ここで大事なのは「止められた感覚」ではなく「正確な code」です。529 は個人の上限切れを自動で意味しませんし、429 は service が忙しそうに見えるからといって overload にはなりません。
Claude Status がいま incident を出している場合
status を最初に見る理由は、不要なローカル作業を丸ごと省けるからです。Claude Status が Claude API、Claude Code、login まわりで赤いなら、最も正しい一手はたいてい「待つ」です。
error が自分の terminal に出るので、問題も自分の設定に違いないと思いがちです。それでも incident が進行中なら、reinstall、route の切り替え、login のやり直しを増やしても、signal より noise が増えることが多いです。
この枝で残すべきものは少なくて十分です。正確な error text、時刻、そして手元にあるなら request_id。Anthropic は docs で error response に request_id が含まれると説明しています。incident が解消したら、同じ path をもう一度試してください。same-path verification がないと、incident が全部の原因だったのかどうかがわかりません。
ただし、この枝を万能説明にしてはいけません。status が緑に戻ったら、問いは「いま落ちているか」から「なぜこの path だけまだ戻っていないのか」に変わります。
status は緑なのに、同じ path がまだ 529 を返す場合
緑の status page は、local change を乱発してよいという許可ではありません。live incident の枝が薄くなっただけで、overload diagnosis が終わったわけではありません。
ここが最も厄介な枝です。公式 code は overload を示し、公開 status は正常に見え、それでも terminal は失敗し続けます。この状況では #3558 や #3572 のような official-repo issue が役に立ちます。これらは一つの万能な root cause を証明しませんが、「緑の status と反復する 529 が同時に起こりうる」ことを示します。
ここでの正しい一手は bounded same-path retry です。少し待って、同じ action を同じ route で一度だけ試します。model、billing path、auth route、session state を同時に変えないでください。いくつも変えてしまうと、元の path が自力で回復したのか、別の枝へ逃げただけなのかがわからなくなります。
この枝でありがちな失敗は、upgrade、reinstall、大規模な config 変更といった「大きい修正」を早く打ちすぎることです。最初に答えるべき問いはもっと小さいはずです。同じ path は短い待機のあとに戻ったのか。それとも support に渡すべき再現性のある failure なのか。
usage や API key の route に入っているかもしれない場合
529 の切り分けがずれる大きな理由の一つは、読者が「Claude Code は自分が思っている auth route を使っている」と信じやすいことです。Anthropic の Pro / Max 向け help では、ANTHROPIC_API_KEY が設定されていると Claude Code は subscription auth ではなくその key を使うと説明されています。これだけで、多くの誤診を説明できます。
subscription path を見ているつもりでも、shell が ANTHROPIC_API_KEY を export していれば、その前提は崩れます。まず /status と環境を確認し、active route を確定してください。route を誤認したまま quota や service availability を論じると、以降の判断が全部ぶれます。
proxy、wrapper、alternate provider route でも同じです。最初の一手は provider shopping ではありません。intended route に戻し、古い思い込みを外し、その route で同じ request を比較することです。意図しない API key を外したり、想定していた auth path に戻したあとで 529 が消えるなら、本当の枝は route mismatch でした。intended route に戻しても 529 が残るなら、overload の解釈の方がまだ強いです。
この節も広げすぎないでください。根本問題が usage exhaustion や shared-plan drain なら、Claude Code usage limits 診断ガイド へ渡した方が早いです。実際の症状が 500 なら、Claude Code API Error 500 ガイド の方が合っています。
修正後の確認と、エスカレーションの境界
529 の recovery を速くする一番の習慣は、「何か変わったか」ではなく「この path がこの一手のあとに戻ったか」を見ることです。same-path verification は blind retry、無自覚な branch switching、弱い support report を同時に防ぎます。
エスカレーション前に、同じ failing path から最低限これだけを集めてください。
- 正確な error text。
529やoverloaded_errorを含むもの request_idまたはrequest-id- その時点の Claude Status の表示
- bounded retry 後も失敗したのか、intended route に戻しても失敗したのか
- 最小の reproduction steps、または relevant
/statusoutput
このリストは短い方がよいです。support に必要なのは、長い試行錯誤日記ではなく、再現性のあるきれいな話だからです。「緑の status、同じ path が短い retry 後も 529、request_id あり」は十分に強い報告です。「いろいろ変えたが直らない」は弱い報告です。
エスカレーションの境界も短くて構いません。status checked、route checked、bounded retry done、それでも同じ path がまだ 529。そこまで来たら、これ以上の improvisation より clean handoff の方が価値があります。
Frequently Asked Questions
Claude Code の API Error: 529 と 429 rate_limit_error は同じですか。
違います。Anthropic の API error docs では別の error type として定義されています。429 は rate limit、529 は overload です。
Claude Status が緑なのに、なぜまだ 529 が出るのですか。
緑の public status が除外するのは live incident branch だけです。あなたの Claude Code path そのものが回復したことまでは保証しません。次の一手は same-path retry か route check です。
529 を見たら、すぐ plan を変えるべきですか。
最初の一手としては勧めません。529 はまず overload を意味します。code と active route を確定してから plan や billing を考えてください。
subscription path のつもりだったのに挙動がおかしい時は何を見ればいいですか。
ANTHROPIC_API_KEY が設定されていないか確認し、/status と environment variables で active route を確定してください。Anthropic はこの key が subscription auth を上書きすると説明しています。
support には何を送ればいいですか。
正確な error text、request_id、status の状態、試した path、最小の reproduction steps です。目的は長い説明ではなく、曖昧さを減らすことです。
Working Rule
Claude Code の API Error: 529 は、「個人の上限かもしれない」という話より先に「過負荷としてどう戻すか」という話として扱う方が安全です。まず Status、次に path を固定し、bounded move を一つだけ行い、同じ path で確認する。それでも失敗するなら、evidence を添えてエスカレーションします。