Claude Codeが突然止まる「529 Overloaded」の正体

Claude Codeで作業をしていると、それまでスムーズに動いていたのに突然レスポンスが返ってこなくなり、コンソールに「529」というステータスコードが表示されることがあります。

HTTPステータス529は、Anthropic APIが「現在リクエストを処理しきれない状態にある」ことを示す独自のステータスコードです。HTTP標準仕様（RFC 9110）で定義されているコードではなく、Anthropicが自社APIのために設計した、いわば「混雑のお知らせ」です。

このコードが返される瞬間、サーバー側では何が起きているのでしょうか。そして、開発者としてどう対処すべきなのでしょうか。

529エラーが発生するメカニズム

Anthropic APIは、数万の開発者と企業が同時にアクセスする大規模な推論基盤です。Claude Sonnet 4やClaude Opus 4といったモデルが動作する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のクレジット購入）への昇格を推奨します。

リクエスト構造の非効率

1回のリクエストに含めるコンテキスト（会話履歴やシステムプロンプト）が巨大すぎると、1リクエストあたりのGPU処理時間が長くなり、サーバー側のキュー滞留を引き起こします。100Kトークンを超える長大なコンテキストを連続送信している場合、レートリミットに到達していなくても529が返されることがあります。

Claude Code特有の529エラー発生パターン

Claude Codeはバックグラウンドで複数のAPI呼び出しを行うため、通常のチャットUIでの利用よりも529エラーが発生しやすい構造になっています。

大規模なコードベースで「Agent」ツールを多用する場面が最も典型的な発生パターンです。Claude Codeがメインコンテキストからサブエージェントを複数起動すると、それぞれが独立したAPIリクエストを生成します。3つのサブエージェントが同時に動作し、各エージェントが複数回のツール呼び出しを行えば、短時間に10回以上のAPIリクエストが集中することになります。

また、CLAUDE.mdファイルやメモリ情報が肥大化してシステムプロンプトのトークン数が膨らんでいる場合も、1リクエストあたりの処理負荷が上がり、529の発生確率が高まります。コンテキストウィンドウの圧縮が自動で走る頻度が増えていると感じたら、CLAUDE.mdの情報量を見直す良いタイミングです。

529エラーへの実践的な対処法

即座にできること

エラーが発生したら30秒から1分ほど待ってから再実行してみてください。プラットフォーム全体の負荷が原因であれば、多くの場合これだけで解消します。

Claude Codeには自動リトライ機構が内蔵されており、529エラーを受信すると指数バックオフで自動的に再試行します。ユーザーが手動で何かをする必要がない場面も多いのですが、連続して失敗する場合は数分待ってからセッションを再開してください。

コンテキストの最適化

CLAUDE.mdやメモリファイルの内容を見直し、本当に毎回のリクエストに含める必要がある情報だけに絞り込みましょう。不要になったプロジェクトメモリを削除し、レファレンス情報は必要なときにツールで読み取る方式に切り替えることで、リクエストサイズを削減できます。

Claude Codeの /compact コマンドも有効です。会話コンテキストを圧縮して後続のリクエストサイズを抑えることができ、長時間のセッション中に定期的に実行すると529エラーの発生頻度が下がります。

API利用パターンの改善

自前でAnthropic APIを呼び出すアプリケーションを開発している場合は、リクエストの送信パターンを見直しましょう。

リトライの実装では指数バックオフ（Exponential Backoff）にジッター（ランダムな揺らぎ）を加えるのが鉄則です。全クライアントが1秒後、2秒後、4秒後と同じタイミングでリトライすると、リトライの波が同期して再び過負荷を引き起こします（Thundering Herd問題）。各リトライの待ち時間にランダムな0〜1秒のジッターを加えることで、リトライの波を分散させることができます。

Anthropic公式SDK（Python/TypeScript）にはリトライ処理が標準で組み込まれています。自前のリトライ実装で公式SDKの挙動を上書きしないよう注意してください。

バッチAPIの活用

リアルタイム性が求められない処理は、Message Batches APIの利用を検討してください。バッチAPIは通常のAPIとは異なるキューで処理されるため、529エラーの影響を受けにくく、料金も50%割引になります。

大量のドキュメントを一括処理する、夜間にレポートを自動生成するといったユースケースでは、バッチAPIに切り替えるだけで529エラーが完全に解消されることがあります。

529と混同しやすいエラーコード

Anthropic APIで遭遇する主要なエラーコードを整理しておきます。

ステータスコード 意味 原因 対処
429 Too Many Requests アカウントのレートリミット超過 待機してリトライ、プランアップグレード
529 Overloaded サーバー全体の過負荷 待機してリトライ、バッチAPI検討
500 Internal Server Error サーバー内部エラー リトライ、解消しなければサポート連絡
503 Service Unavailable メンテナンスまたは障害 ステータスページ確認

429と529の違いを正確に理解しておくことが重要です。429は「あなたのアカウントが上限に達した」という個別の制限で、プランのアップグレードやリクエスト頻度の調整で解消できます。529は「サーバー全体が処理能力の限界に達した」という状態で、個人の操作では直接解消できません。レスポンスヘッダーの retry-after フィールドに推奨待機秒数が含まれることがあるため、リトライ実装ではこの値を優先的に参照してください。

本番環境での529対策設計

Anthropic APIを本番サービスに組み込んでいる場合、529エラーは「必ず発生するもの」として設計に織り込む必要があります。

サーキットブレーカーパターンの実装が有効です。一定時間内に529エラーが連続した場合にAPIへのリクエストを一時的に停止し、フォールバック処理（キャッシュされた応答の返却、「しばらくお待ちください」のメッセージ表示など）に切り替えます。APIが復旧したことを検知したら、リクエストを再開するという流れです。

クライアントに対しては、529の生のエラーを露出させるのではなく、「ただいま混み合っています。しばらくしてから再度お試しください」のようなメッセージを表示してください。技術的なエラーコードがそのまま表示されると、ユーザーに不安を与えるだけで何の情報も伝わりません。

複数のLLMプロバイダーを利用できる環境であれば、529エラーの検知をトリガーとして別のモデルにフォールバックする設計も検討に値します。ただし、プロンプトの互換性やレスポンス品質の差異を考慮した慎重な実装が求められます。

Anthropic公式のエラーハンドリングガイドに推奨される実装パターンが詳しく記載されています。

まとめ

HTTP 529エラーは、Anthropic APIの需要が供給を上回ったときに発生する一時的な状態です。Claude Codeの利用中に遭遇した場合、大半は数十秒から数分待つだけで自然に解消します。

開発者として意識すべきは、「529は例外ではなく、APIを利用する以上必ず起きる通常のイベントである」という設計思想です。指数バックオフとジッター付きリトライ、サーキットブレーカー、バッチAPIの活用という3つの対策を事前に組み込んでおくことで、529エラーが発生してもサービスの信頼性を維持できます。