529エラーを解読する
アプリケーションを構築し、コードもクリーンなのに、突然ログが529ステータスコードで埋め尽くされることがあります。これは非常にストレスの溜まる状況です。この特定のエラーは通常、スクリプトを停止させ、以下のメッセージを表示します:
anthropic.APIStatusError: Error code: 529 - {'type': 'error', 'error': {'type': 'overloaded_error', 'message': 'Overloaded'}}
なぜこれが起きるのか
529エラーは、AIにとっての「話し中(ビジー信号)」だと考えてください。自分が個別にレート制限を超えたことを意味する429エラーとは異なり、529は完全にAnthropic側の問題です。彼らのインフラが一時的にパンクしており、その瞬間にリクエストを処理できない状態にあります。
以下のような状況で発生しやすくなります:
- 利用のピーク時間帯(一般的に米国の正午頃)。
- Claude 3.5 Sonnetのリリース直後などの大規模なアップデート時。
- 予期せぬ地域的なトラフィックの急増、またはバックエンドのメンテナンス。
実戦で証明された解決策
1. 指数バックオフとジッターの実装
サーバーが負荷に苦しんでいるとき、最も避けるべきことは即座のリトライを繰り返すことです。これは「サンダリングハード(不特定多数の同時殺到)」問題を引き起こします。代わりに、指数バックオフを使用して、試行ごとの待ち時間を増やしてください。「ジッター(ランダムな遅延)」を加えることで、何百ものクライアントが全く同じ瞬間にリトライするのを防ぐことができます。
Pythonプロジェクトでは、tenacityライブラリを使うと非常に簡単に実装できます:
import anthropic
from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception_type
client = anthropic.Anthropic(api_key="your_api_key")
# 4秒、8秒、16秒...と最大60秒まで待機。5回試行後に停止。
@retry(
retry=retry_if_exception_type(anthropic.APIStatusError),
wait=wait_exponential(multiplier=1, min=4, max=60),
stop=stop_after_attempt(5)
)
def call_claude():
try:
return client.messages.create(
model="claude-3-5-sonnet-20240620",
max_tokens=1024,
messages=[{"role": "user", "content": "Explain quantum computing simply."}]
)
except anthropic.APIStatusError as e:
if e.status_code == 529:
print("Server swamped. Retrying...")
raise e
raise e
2. SDKのリトライ設定を調整する
AnthropicのSDKにはセーフティネットが組み込まれていることをご存知でしょうか?デフォルトでは2回リトライします。しかし、不安定な時期には2回では不十分です。これを5回、あるいは8回に増やすことで、追加のロジックを書くことなくアプリケーションの稼働を維持できます。
Python:
from anthropic import Anthropic
# 耐障害性を高めるためにリトライ回数を5に増やす
client = Anthropic(
api_key="my_api_key",
max_retries=5,
)
TypeScript/JavaScript:
import Anthropic from '@anthropic-ai/sdk';
const anthropic = new Anthropic({
apiKey: 'my_api_key',
maxRetries: 5,
});
3. モデルのフォールバックを設定する
Claude 3.5 Sonnetが過負荷でも、より軽量なClaude 3 Haikuは稼働していることがよくあります。Haikuは大幅に高速で安価です。Sonnetほど「賢く」はないかもしれませんが、529エラーを受け取るよりは、わずかに精度の低い回答を得る方がマシです。
def get_completion_with_fallback(prompt):
# 最初に高性能モデルを試し、次に高速モデルを試す
models = ["claude-3-5-sonnet-20240620", "claude-3-haiku-20240307"]
for model in models:
try:
return client.messages.create(
model=model,
max_tokens=1024,
messages=[{"role": "user", "content": prompt}]
)
except anthropic.APIStatusError as e:
if e.status_code == 529 and model != models[-1]:
print(f"{model} is full. Dropping down to {models[1]}...")
continue
raise e
4. タスクキューへのオフロード
5,000件のドキュメントを処理する場合、単一のスクリプトでループ処理しようとしないでください。CeleryやBullMQのようなキューを使用しましょう。タスクが529エラーに遭遇した場合、キューは単にそのタスクを数分間戻します。これにより、バックグラウンドワーカーが重い処理をこなしている間も、メインアプリケーションのレスポンスを維持できます。
修正の検証方法
単にうまくいくことを願うだけでなく、以下の3つの領域を監視してください:
- ログのパターン: 「Retrying...」というメッセージを探してください。これらが表示された後に成功していれば、バックオフは完璧に機能しています。
- レイテンシの急増: リトライが重なるため、529エラー発生時はレスポンス時間が長くなることを想定しておいてください。
- 外部ステータス: 発生しているエラーをAnthropicステータスページと照らし合わせてください。「Major Outage(大規模な障害)」が報告されている場合、どれだけリトライしても解決しません。復旧を待つ必要があります。
プロアクティブな戦略
- セルフスロットリング: 自身の同時実行数を制限します。通常、同時リクエスト数が50で529エラーが発生するとわかっている場合は、アプリの上限を30に設定します。
- 積極的なキャッシュ: Redisを使用してレスポンスを24時間保存します。ユーザーが同じ質問をした場合、APIを叩く必要すらなくなります。
- エラー通知: 5xxエラーに対してSentryやDatadogのアラートを設定します。529の発生率が5%を超えたら、すぐに把握できるようにすべきです。

