Claude Codeが突然止まる「529 Overloaded」の正体
Claude Codeで作業をしていると、それまでスムーズに動いていたのに突然レスポンスが返ってこなくなり、コンソールに「529」というステータスコードが表示されることがあります。
HTTPステータス529は、Anthropic APIが「現在リクエストを処理しきれない状態にある」ことを示す独自のステータスコードです。HTTP標準仕様（RFC 9110）で定義されているコードではなく、Anthropicが自社APIのために設計した、いわば「混雑のお知らせ」です。
この問題はClaude Codeユーザーの間で広く報告されており、GitHubのclaude-codeリポジトリには数千件の関連Issueが投稿されています。Claude Maxプランの契約者でも発生するため、「課金で完全に解決できる問題」ではない点を理解しておく必要があります。
このコードが返される瞬間、サーバー側では何が起きているのでしょうか。そして、開発者としてどう対処すべきなのでしょうか。
529エラーが発生するメカニズム
Anthropic APIは、数万の開発者と企業が同時にアクセスする大規模な推論基盤です。Claude Opus 4.6やClaude Sonnet 4.6といった最新のフロンティアモデルが動作するGPUクラスタには物理的な処理上限があり、リクエスト総量がその上限を超えたとき、新規リクエストの受け入れを一時的に制限します。
この制限が発動する要因は、大きく3つに分類できます。
プラットフォーム全体の負荷集中
Anthropicが新しいモデルをリリースした直後や、大規模な障害復旧後のアクセス殺到が典型例です。この場合は個人の操作とは無関係に発生するため、まずAnthropic Status Pageで現在の稼働状況をリアルタイムに確認してください。障害情報がなければ、一時的な負荷集中であり数分以内に解消されることがほとんどです。
アカウント単位のレートリミット到達
Anthropic APIにはアカウントのプラン（Tier）ごとに同時リクエスト数とトークン消費量の上限が設定されています。レートリミットの制御にはトークンバケットアルゴリズムが採用されており、固定間隔でリセットされるのではなく、容量が連続的に補充される仕組みです。
たとえばTier 1プランでは1分あたりのリクエスト数やトークン数が大きく制限されているため、Claude Codeで複数のサブエージェントが並行して動作すると、短時間にリクエストが集中してリミットに到達します。
Anthropicの公式レートリミットドキュメントにTierごとの具体的な上限値が記載されています。利用実績に応じたプランアップグレードでリミットを引き上げることが可能です。
各Tierの昇格条件と、Claude Codeで使用される主要モデルのレートリミットを以下にまとめます。
| Tier | 累計クレジット購入額 | 月間利用上限 |
|---|---|---|
| Tier 1 | $5 | $100/月 |
| Tier 2 | $40 | $500/月 |
| Tier 3 | $200 | $1,000/月 |
| Tier 4 | $400 | $200,000/月 |
| Tier | モデル | RPM（リクエスト/分） | ITPM（入力トークン/分） | OTPM（出力トークン/分） |
|---|---|---|---|---|
| Tier 1 | Opus 4.x / Sonnet 4.x | 50 | 30,000 | 8,000 |
| Tier 1 | Haiku 4.5 | 50 | 50,000 | 10,000 |
| Tier 2 | Opus 4.x / Sonnet 4.x | 1,000 | 450,000 | 90,000 |
| Tier 2 | Haiku 4.5 | 1,000 | 450,000 | 90,000 |
| Tier 3 | Opus 4.x / Sonnet 4.x | 2,000 | 800,000 | 160,000 |
| Tier 3 | Haiku 4.5 | 2,000 | 1,000,000 | 200,000 |
| Tier 4 | Opus 4.x / Sonnet 4.x | 4,000 | 2,000,000 | 400,000 |
| Tier 4 | Haiku 4.5 | 4,000 | 4,000,000 | 800,000 |
Tier 1のRPMは1分あたりわずか50リクエストです。Claude Codeが3つのサブエージェントを並列起動し、各エージェントが複数のツール呼び出しを行う場面では、数十秒でこの上限に到達する可能性があります。Tier 2に上がるだけでRPMが20倍の1,000になるため、Claude Codeを本格的に使うなら最低でもTier 2（累計$40のクレジット購入）への昇格を推奨します。
なお、より高い可用性が求められる企業向けにはPriority Tierが用意されています。Priority Tierでは99.5%のアップタイム目標と優先的な計算リソースの割り当てが提供され、コミット容量を超えた場合は自動的に標準Tierにフォールバックする仕組みです。
リクエスト構造の非効率
1回のリクエストに含めるコンテキスト（会話履歴やシステムプロンプト）が巨大すぎると、1リクエストあたりのGPU処理時間が長くなり、サーバー側のキュー滞留を引き起こします。
2026年3月にClaude Opus 4.6の1Mコンテキストウィンドウが正式GA（一般提供）となり、最大100万トークンのコンテキストを送信できるようになりました。これにより大規模コードベースの一括分析が可能になった反面、巨大コンテキストのリクエストがサーバー側の処理リソースを長時間占有するケースが増えています。100Kトークンを超える長大なコンテキストを連続送信している場合、レートリミットに到達していなくても529が返されることがあります。
Claude Code特有の529エラー発生パターン
Claude Codeはバックグラウンドで複数のAPI呼び出しを行うため、通常のチャットUIでの利用よりも529エラーが発生しやすい構造になっています。
大規模なコードベースで「Agent」ツールを多用する場面が最も典型的な発生パターンです。Claude Codeがメインコンテキストからサブエージェントを複数起動すると、それぞれが独立したAPIリクエストを生成します。3つのサブエージェントが同時に動作し、各エージェントが複数回のツール呼び出しを行えば、短時間に10回以上のAPIリクエストが集中することになります。
また、CLAUDE.mdファイルやメモリ情報が肥大化してシステムプロンプトのトークン数が膨らんでいる場合も、1リクエストあたりの処理負荷が上がり、529の発生確率が高まります。コンテキストウィンドウの圧縮が自動で走る頻度が増えていると感じたら、CLAUDE.mdの情報量を見直す良いタイミングです。
Claude MaxプランでもHTTP 529は発生する
Claude Maxプラン（月額$100/$200）に加入していれば529エラーから完全に解放されると思われがちですが、実際にはMaxプランでも529エラーは発生します。Maxプランはレートリミット（429）の枠を大幅に引き上げますが、サーバー全体の過負荷（529）は個別のプランとは無関係に発生するためです。「課金で解決できるのは429（レートリミット）であり、529（過負荷）は待つしかない」と覚えておきましょう。
529エラーへの実践的な対処法
即座にできること
エラーが発生したら、まずAnthropic Status Pageを確認してください。大規模な障害やメンテナンスが進行中であれば、そこに情報が掲載されています。特に告知がなければ一時的な負荷集中のため、30秒から1分ほど待ってから再実行してみてください。
Claude Codeには自動リトライ機構が内蔵されており、529エラーを受信すると指数バックオフで自動的に再試行します。ユーザーが手動で何かをする必要がない場面も多いのですが、連続して失敗する場合は数分待ってからセッションを再開してください。
コンテキストの最適化
CLAUDE.mdやメモリファイルの内容を見直し、本当に毎回のリクエストに含める必要がある情報だけに絞り込みましょう。不要になったプロジェクトメモリを削除し、レファレンス情報は必要なときにツールで読み取る方式に切り替えることで、リクエストサイズを削減できます。
Claude Codeの /compact コマンドも有効です。会話コンテキストを圧縮して後続のリクエストサイズを抑えることができ、長時間のセッション中に定期的に実行すると529エラーの発生頻度が下がります。1Mコンテキストが利用可能になった現在でも、必要のない情報はコンテキストに含めないのが基本です。
API利用パターンの改善
自前でAnthropic APIを呼び出すアプリケーションを開発している場合は、リクエストの送信パターンを見直しましょう。
リトライの実装では指数バックオフ（Exponential Backoff）にジッター（ランダムな揺らぎ）を加えるのが鉄則です。全クライアントが1秒後、2秒後、4秒後と同じタイミングでリトライすると、リトライの波が同期して再び過負荷を引き起こします（Thundering Herd問題）。各リトライの待ち時間にランダムな0〜1秒のジッターを加えることで、リトライの波を分散させることができます。
Anthropic公式SDK（Python/TypeScript）にはリトライ処理が標準で組み込まれています。自前のリトライ実装で公式SDKの挙動を上書きしないよう注意してください。レスポンスヘッダーの retry-after フィールドに推奨待機秒数が含まれることがあるため、リトライ実装ではこの値を最優先で参照してください。
バッチAPIの活用
リアルタイム性が求められない処理は、Message Batches APIの利用を検討してください。バッチAPIは通常のAPIとは異なるキューで処理されるため、529エラーの影響を受けにくく、料金も50%割引になります。
大量のドキュメントを一括処理する、夜間にレポートを自動生成するといったユースケースでは、バッチAPIに切り替えるだけで529エラーが完全に解消されることがあります。
529と混同しやすいエラーコード
Anthropic APIで遭遇する主要なエラーコードを整理しておきます。詳細はAnthropic公式のエラーリファレンスを参照してください。
| ステータスコード | 意味 | 原因 | 対処 |
|---|---|---|---|
| 429 | Too Many Requests | アカウントのレートリミット超過 | 待機してリトライ、プランアップグレード |
| 529 | Overloaded | サーバー全体の過負荷 | 待機してリトライ、バッチAPI検討 |
| 500 | Internal Server Error | サーバー内部エラー | リトライ、解消しなければサポート連絡 |
| 503 | Service Unavailable | メンテナンスまたは障害 | ステータスページ確認 |
429と529の違いを正確に理解しておくことは2026年現在でも極めて重要です。以前は「529も429も実質同じ過負荷イベント」と説明されることがありましたが、この理解は不正確です。
- 429（Too Many Requests）: あなたのアカウントが個別のレートリミットに到達した状態。プランのアップグレード、リクエスト頻度の調整、またはClaude Maxプランの契約で解消できます。
- 529（Overloaded）: Anthropicのサーバー全体が処理能力の限界に達した状態。個人の操作やプラン変更では直接解消できません。
この区別を正確に把握しておくことで、無駄なトラブルシューティング（529エラーなのにプランアップグレードで解決しようとするなど）を避けられます。
本番環境での529対策設計
Anthropic APIを本番サービスに組み込んでいる場合、529エラーは「必ず発生するもの」として設計に織り込む必要があります。
サーキットブレーカーパターンの実装が有効です。一定時間内に529エラーが連続した場合にAPIへのリクエストを一時的に停止し、フォールバック処理（キャッシュされた応答の返却、「しばらくお待ちください」のメッセージ表示など）に切り替えます。APIが復旧したことを検知したら、リクエストを再開するという流れです。
クライアントに対しては、529の生のエラーを露出させるのではなく、「ただいま混み合っています。しばらくしてから再度お試しください」のようなメッセージを表示してください。技術的なエラーコードがそのまま表示されると、ユーザーに不安を与えるだけで何の情報も伝わりません。
複数のLLMプロバイダーを利用できる環境であれば、529エラーの検知をトリガーとして別のモデルにフォールバックする設計も検討に値します。マルチプロバイダー構成を採用した本番環境では、単一プロバイダーと比較して大幅に高いアップタイムが報告されています。ただし、プロンプトの互換性やレスポンス品質の差異を考慮した慎重な実装が求められます。
Anthropic公式のエラーハンドリングガイドに推奨される実装パターンが詳しく記載されています。
まとめ
HTTP 529エラーは、Anthropic APIの需要が供給を上回ったときに発生する一時的な状態です。Claude Codeの利用中に遭遇した場合、大半は数十秒から数分待つだけで自然に解消します。
開発者として意識すべきは、「529は例外ではなく、APIを利用する以上必ず起きる通常のイベントである」という設計思想です。指数バックオフとジッター付きリトライ、サーキットブレーカー、バッチAPIの活用という3つの対策を事前に組み込んでおくことで、529エラーが発生してもサービスの信頼性を維持できます。
529は課金では解決できない問題ですが、設計で解決できる問題です。