Claudeの529 overloaded_error — 原因とリトライ戦略

529は、あなたのコードが原因ではない唯一のClaudeエラーです。過負荷なのはAnthropic側です。修正はできませんが、適切に処理することはできます。つまり、バックオフを伴う慎重な再試行、レイテンシーが重要な処理経路でのフォールバックモデル、そして障害を悪化させる即時の大量リトライを避けることが必要です。

エラー

réponse (HTTP 529)

{
  "type": "error",
  "error": { "type": "overloaded_error",
             "message": "Overloaded" }
}

原因と対処法の概要

原因	対処法
プロバイダー側の過負荷（ローンチ時、地域的な障害）。すべての顧客に同時に影響します。	ジッター付きのバックオフを使用し、アプリケーションを再デプロイするのではなくAnthropicのステータスページを確認します。
あなた自身の負荷スパイクが、すでに逼迫しているキャパシティと重なっています。	バッチ処理の実行時刻をずらしてください。通常は10分ずらせば十分です。
429との混同：ログ上ではレート制限に似ていますが、原因はまったく異なります。	429は、あなたが制限を超えたことを意味します（サーバーは正常）。529は、サーバーが過負荷であることを意味します（あなたのクォータは問題ありません）。Retry-Afterの情報が返されるのは429だけです。
フォールバックが定義されていないため、プロバイダーの問題がエンドユーザーまで波及します。	フォールバックチェーンを定義します。同じファミリー内（Sonnet → Haiku）なら挙動が近いままで、プロバイダー間（Claude → GPT）なら完全な障害にも耐えられます。

障害を悪化させずに再試行する

529は、Retry-Afterのない429として扱います。約2秒から指数バックオフを開始し、ジッターを加え、30～60秒を上限とし、約5回の試行後に諦めて処理をキューに入れます。重要なのはジッターです。ジッターがないと、すべてのクライアントが同時に復帰し、解消しようとしている過負荷をまさに長引かせてしまいます。

停止するのではなく切り替える

レイテンシーが重要な処理経路には、フォールバックチェーンを定義します。OpenAI互換エンドポイントなら、変更するのは1つの文字列だけです。2つ目のSDKも、2つ目のアカウントも必要ありません。

failover.py

PREFERRED = ["claude-sonnet-5", "claude-haiku-4-5", "gpt-5-6-terra"]

def complete(messages):
    last = None
    for model in PREFERRED:
        try:
            return client.chat.completions.create(
                model=model, messages=messages, max_tokens=800)
        except APIStatusError as e:
            if e.status_code not in (429, 500, 529):
                raise
            last = e          # saturé — passer au palier suivant
    raise last

その後で初めて自分のコードを確認する

529が1種類のリクエストでだけ発生し、同じ時間帯に他の呼び出しが成功しているなら、全体的な障害ではありません。その経路が通常より大きなプロンプトを送っていないか、狭いループ内で連続的に実行されていないかを確認します。一方、すべての呼び出しで一斉に発生して自然に消えたなら、原因はキャパシティです。その場合、必要なのはリファクタリングではなく、リトライとフォールバックです。

Kunavo経由で呼び出している場合

Kunavoは複数のアップストリーム経路でClaudeを提供しており、マルチモデルカタログによって、プロバイダー間のフェイルオーバーは同じキーと同じウォレットのままモデル名を変更するだけで実現できます。上記のパターンに2つ目のアカウントは必要ありません。それでもあなたに届く529エラーは、決して請求されません。キャパシティと価格は別の問題です。後者については、モデルごとの料金が Claude API料金表に記載されています.

よくある質問

529は私のミスですか？

いいえ。プロバイダー側のキャパシティの問題です。あなたの責任は、バックオフとジッターで障害を悪化させないこと、そして障害がレイテンシー予算を超えて続いた場合に備えて切り替え先を用意することだけです。

529と429の違いは何ですか？

429は、あなたが制限を超えたことを意味し、サーバーは正常です。529は、サーバー自体が過負荷であることを意味し、あなたのクォータは問題ありません。どちらも再試行できますが、Retry-Afterの情報が付くのは429だけです。

529の状態はどのくらい続きますか？

予測できず、保証もできません。そのため、正しい対応は上限付きバックオフとキューであり、コードに固定の待機時間を書き込むことではありません。処理経路にレイテンシー予算がある場合は、待機ではなくフォールバックを使用します。

529の呼び出しは課金されますか？

Kunavo経由では課金されません。エラーで終了したリクエストは請求対象外です。直接契約の場合は、該当プロバイダーの請求ルールによります。

Claude APIの529 overloaded_error — その正体と対処法

エラー