529 overloaded claude codeの意味と対処｜復旧までの手順
Claude Codeで突然「API Error: 529」「Overloaded」と表示され、作業中のセッションをどう再開すべきか迷う人に向けた記事です。529が自分の設定や契約プランの問題なのか、429・500と何が違うのかを切り分け、待機・再試行・モデル変更・障害確認の順番を整理します。
529 Overloadedは、Claude Codeの利用枠ではなく、Anthropic APIが一時的に混雑している状態です。まず status.claude.com を確認し、連打せず数分待って再試行、続くときは /model で別モデルへ切り替えることで、原因を誤認せず作業を再開できるとわかる。
Contents (8)
目次
529 Overloadedとは
Claude Codeで表示される529は、Anthropic APIが一時的に処理能力を超えたときのサーバー側エラーです。代表的な表示は次のとおりです。
API Error: 529 {"type":"error","error":{"type":"overloaded_error","message":"Overloaded"}}
Anthropic公式のエラーリファレンスでは、529を overloaded_error、429を rate_limit_error と定義しています。529は「APIが一時的に過負荷」という意味で、入力したコードの文法ミス、APIキーの打ち間違い、Claude Codeの利用枠到達を直接示すものではありません。エラーの分類とレスポンスの形式は、Claude API errorsで確認できます。
Claude Codeの公式エラーリファレンスも、繰り返し発生する529は全ユーザーに対する一時的な容量不足であり、利用上限には数えないと説明しています。CLIが内部で何度か再試行した後に同じ表示が出るため、画面にエラーが出た時点で初回の失敗とは限りません。まず端末やプロジェクトを壊したと考えず、サービスの混雑として扱うのが適切です。
ただし、ステータスページが正常でも特定モデルだけ混み合っている場合があります。したがって「公式障害がないから自分の設定が原因」と即断せず、モデル別の状況と再試行結果を分けて見ます。
最初の5分で行う対処手順
529が出た直後は、次の順序で確認すると、不要な再ログインや再インストールを避けられます。
- エラー文と現在のモデルを記録する。
529、overloaded_error、429、500のどれかを確認し、可能なら使用中のモデル名、発生時刻、実行していた操作をメモします。ログを残すと、再発時に同じ症状か判断できます。 - 公式ステータスを確認する。 status.claude.comで、Claude CodeやAPIに障害・性能低下の表示がないか見ます。障害が掲載されているなら、設定変更より復旧待ちを優先します。
- 数分待ってから一度だけ再試行する。 失敗直後に同じ入力を連打すると、混雑中のリクエストを増やします。Claude Codeのエラー対処ガイドも、529が続くときは数分待って再試行するよう案内しています。
- 同じモデルで続くなら
/modelを実行する。 セッション内でモデル選択画面を開き、別の利用可能なモデルへ切り替えます。公式ドキュメントでは、容量がモデル単位で管理されるため、混雑しているモデルから切り替える方法が示されています。 - 長い作業を小さく分けて再開する。 巨大な依頼をそのまま再送せず、調査・変更・テストに分割します。再開後はいきなり複数ファイルの大きな変更を依頼せず、最初に短い確認を送ると失敗時の影響を抑えられます。
ここで大切なのは、529に対してAPIキーの再発行やClaude Codeの再インストールから始めないことです。認証エラーなら401、権限なら403のように別のエラーになります。529だけが出ている間は、サーバーの回復とモデル切替を先に確認します。
529・429・500の違い
似た表示でも、原因と次の行動は異なります。エラーコードを読み違えると、プラン変更や設定変更に時間を使ってしまいます。
| コード | 表示・意味 | まず行うこと |
|---|---|---|
| 529 | overloaded_error。API全体または利用中のモデルが一時的に過負荷 |
ステータス確認、待機、再試行、モデル変更 |
| 429 | rate_limit_error。アカウントや組織のレート制限に到達 |
送信頻度・並列数を下げ、指定された待機時間を確認 |
| 500 | api_error。Anthropic内部で予期しないエラー |
ステータス確認、時間を置いた再試行、継続時は報告 |
529と429は、どちらも混雑時に見えるため混同されがちです。しかし、公式APIドキュメントでは429はアカウントのレート制限、529は全ユーザーに影響し得る一時的な過負荷として区別されています。529が出たからといって、利用量の上限に達した、または上位プランへ変更すれば必ず解決する、と判断するのは危険です。
APIを自分のプログラムから呼び出している場合は、公式SDKの自動リトライも確認します。Anthropic公式SDKは一時的な失敗に指数バックオフを使い、既定では2回再試行し、retry-afterヘッダーがあればその値を尊重します。固定間隔で無限に再送する実装は避けてください。詳しい仕様はClaude API errorsの「HTTP errors」を参照できます。
Claude Codeで再発を減らす運用
529を完全にゼロにする設定はありません。代わりに、混雑が起きても作業を失わず、リクエストを集中させない運用を作ります。
まず、同じセッションで短時間に何度も送信しないことです。Claude Codeは529を検知すると、表示の前に自動で再試行します。そこへ手動の連打を重ねると、復旧前の判断が難しくなります。画面に「Repeated 529 Overloaded」と出たら、内部リトライも終わった合図として、いったん待機へ切り替えます。
次に、同時実行数を見直します。複数の処理を同時に走らせる使い方では、短い時間にリクエストが集中しやすいため、作業を一つずつ進める、並列数を下げる、軽いモデルを選ぶ、といった調整が有効です。Claude Code公式のエラーリファレンスにも、CLAUDE_CODE_MAX_TOOL_USE_CONCURRENCYで同時実行数を下げる方法が記載されています。
長いセッションでは、必要な情報だけを残して依頼を分割します。プロジェクト全体を一度に説明させるより、対象ファイル、変更目的、テスト条件を小さく渡すほうが、失敗したときに再送する量を抑えられます。これは529の発生を保証付きで防ぐ方法ではありませんが、復旧後の再実行を軽くする実務上の対策です。
モデルを起動時から変えたい場合は、次のように--modelを指定できます。利用できる別名やモデル名はアカウント・時期によって変わるため、固定のバージョン名を記事の手順として決め打ちしないほうが安全です。
claude --model sonnet
セッション中だけ変更するなら/model、新しいセッションの起動時に指定するなら--modelを使います。設定の優先順位や現在のセッションだけに適用される動作は、Claude Codeのモデル設定で確認できます。
直らないときの切り分けと問い合わせ
数分待っても複数回失敗する場合は、次の情報を揃えて「サービス全体の問題」「モデル固有の混雑」「自分の通信経路」の順に切り分けます。
- 同じモデルで再発するかを確認する。
/modelで別モデルへ切り替え、片方だけ成功するならモデル固有の容量不足が考えられます。どのモデルでも失敗するなら、次の確認へ進みます。 - 公式ステータスと発生時刻を照合する。 障害の開始・更新時刻と、自分のエラー発生時刻をメモします。ステータスが正常でも局所的な混雑は残るため、正常表示だけで529を否定しません。
- 新しい短い依頼で再現性を見る。 長い会話だけで失敗するなら、会話を分割して再開します。短い依頼でも全モデルで続くなら、無理な再送を止めて待機します。
- API連携ならリクエストIDを保存する。 エラー本文の
request_idやレスポンスヘッダーのrequest-idは、サポートへ状況を伝える手掛かりです。プロンプト全文や秘密情報を公開せず、時刻・モデル・コード・リクエストIDをまとめます。 - 障害表示がなく再発するなら報告する。 Claude Codeでは
/feedbackから、再現条件とログを添えて報告できます。設定変更を繰り返すより、同じ条件での発生を記録したほうが調査につながります。
ネットワークやVPNが原因だと決めつける必要もありません。529の定義はサーバー側の過負荷ですが、別の通信エラーが同時に出ている場合は、VPN・プロキシ・社内ネットワークを一時的に切り分けます。529だけならサーバーの回復を待ち、接続エラーも併発するときだけ通信経路を調べる、という順番が効率的です。
まとめ
Claude Codeの529 Overloadedは、Anthropic APIが一時的に混雑していることを示すエラーです。まず公式ステータスを見て、連打せず数分待ち、同じモデルで続くときは/modelで切り替えます。429のレート制限や500の内部エラーとは原因が違うため、コード・プラン・認証の設定をむやみに変更する必要はありません。
再発時は、同時実行数と依頼の大きさを抑え、発生時刻・モデル・エラー本文・リクエストIDを残します。529を「すぐ直す設定探し」ではなく「混雑を前提に安全に再開する手順」として扱えば、開発作業の中断を短くできます。