Claude 529 エラー（overloaded_error）の原因と対処法

529 は、自分のコードが原因ではない唯一の Claude エラーです。混雑しているのは Anthropic 側で、こちらから直すことはできません。できるのは「きれいに受け止める」ことだけ — 指数バックオフを入れた粘り強いリトライ、レイテンシに厳しい経路にはフォールバックモデル、そして障害をさらに悪化させる即時リトライの連打をしないこと。この 3 つが対処のすべてです。

表示されるエラー

レスポンス（HTTP 529）

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

原因と対処法の早見表

原因	対処法
プロバイダ側の混雑（新モデル公開日、地域的な障害）。全ユーザーに同時に発生します。	ジッター付きバックオフで待つ。アプリを再デプロイするのではなく、Anthropic のステータスページを確認する。
自分のバースト送信が、すでに逼迫している容量に重なった。	バッチ処理を時間的に分散させる。10 分ずらすだけで解消することがほとんどです。
429 との取り違え。ログ上は似て見えますが、原因はまったく別です。	429 は自分が上限を超えた状態（サーバーは正常）、529 はサーバー側が過負荷（残高・上限は正常）。Retry-After が付くのは 429 だけです。
フォールバックが定義されておらず、プロバイダの問題がそのままエンドユーザーまで届いてしまう。	フォールバックの順序を決めておく。同系統（Sonnet → Haiku）なら挙動が近く、プロバイダをまたぐ（Claude → Gemini）なら全体障害も乗り切れます。

障害を悪化させないリトライにする

529 は「Retry-After のない 429」として扱います。約 2 秒から始める指数バックオフ、ジッターあり、上限は 30〜60 秒、5 回程度で諦めてキューに退避。効くのはジッターの部分です。これがないと全クライアントが同じ瞬間に戻ってきて、抜け出したいはずの混雑をそのまま延長してしまいます。

落とすのではなく、逃がす

レイテンシに厳しい経路にはフォールバックの連鎖を用意します。OpenAI 互換のエンドポイントなら、変えるのは文字列ひとつだけ — SDK を増やす必要も、アカウントを増やす必要もありません:

failover.py

PREFERRED = ["claude-sonnet-4-6", "claude-haiku-4-5", "gemini-2-5-flash"]

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          # 過負荷 — 次の候補へ
    raise last

自分のコードを疑うのは最後

特定のリクエスト種別だけ 529 になり、同時刻の他の呼び出しは通っているなら、それは全体障害ではありません。その経路が異常に大きいプロンプトを送っていないか、短いループで連射していないかを確認します。逆に全呼び出しが一斉に 529 になり、しばらくして自然に収まったのなら原因は容量です。その場合に手を入れるべきはリトライとフォールバックであって、リファクタリングではありません。

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

Kunavo は Claude を複数の上流経路に振り分けており、マルチモデルのカタログによってプロバイダをまたぐフォールバックが「同じキー・同じ残高のままモデル名を変えるだけ」になります。上のコードに 2 つ目のアカウントは必要ありません。それでも到達した 529 が課金されることはありません。容量と価格は別の問題です。後者についてはモデルごとの単価を Claude API 料金表.

よくある質問

529 は自分のせいですか?

違います。プロバイダ側の容量の問題です。こちら側の責任は 2 つだけ — 障害を増幅しないこと（バックオフとジッター）と、障害がレイテンシ許容時間を超えたときの逃がし先を用意しておくことです。

529 と 429 の違いは?

429 は自分が上限を超えた状態で、サーバー自体は正常です。529 はサーバーが過負荷で、こちらの上限・残高は正常です。どちらもリトライ可能ですが、Retry-After のヒントが付くのは 429 だけです。

529 はふつうどれくらい続きますか?

予測できませんし、保証もできません。だからこそ正解は「上限付きバックオフ + キュー」であって、コードに固定の待ち時間を書くことではありません。その経路にレイテンシ許容時間があるなら、待つのではなくフォールバックが引き継ぎます。

529 で失敗した呼び出しも課金されますか?

Kunavo 経由では課金されません。エラーで終わったリクエストは請求対象外です。直接契約の場合は、各プロバイダの課金ルールに従います。

Claude API の 529 overloaded_error — 意味と正しい対処法