Claude APIの障害・エラー対処|429・529・タイムアウトの確認と再試行

Claude APIの失敗は、HTTPステータスだけでなく、レスポンス本文とリクエストIDを合わせて調べます。529を受け取った時と、401や429を受け取った時では、再試行だけで改善するかどうかが違います。アプリ利用者は管理者へ記録を渡し、開発・運用担当者は実行済み処理を確認してから復旧させましょう。

【要点】連続再送する前の確認

• ステータス、エラー種別、発生時刻、request IDを保存します。
• Claude.aiへのログインと、APIキーの有効性は別に扱います。
• 429は頻度・上限、529は一時的な過負荷の可能性を調べます。
• SDKの自動再試行に独自の再試行を重ね過ぎないようにします。

公式サービス障害モニターほかのサービスの障害・メンテナンス・復旧履歴を確認

ここではClaude APIの公式状態を表示します。Amazon BedrockやGoogle Cloud経由でモデルを使う場合は、その提供元の障害と制限も別途確認してください。

エラーコードごとに対処を変える

具体的な種別はClaude API公式のエラー仕様と照合します。ストリーミングではHTTP 200の後にもエラーが届くため、接続成功だけを完了判定に使わないでください。最後まで受信できたか、途中で切れたかを記録します。

最小リクエストで原因を絞る

1. 本番処理をむやみに再実行せず、エラーの集中時刻と直前の変更を確認します。
2. 同じAPI提供元・モデルで、機密情報やツール実行を含まない小さな入力を試します。外部操作を行わない診断用の処理に限定します。
3. 小さな入力は通るなら、長い履歴、添付、同時実行数、特定ツールを一つずつ比較します。
4. 同じキーを使う別の処理も失敗するかを確認します。キーは画面共有やチャットに貼らず、設定上の識別名で区別します。

APIキーを新しく作れば障害が直るわけではありません。突然の401なら、デプロイ時に環境変数が置き換わっていないか、別ワークスペース用の設定を参照していないかを先に調べます。漏えいが疑われる時の失効・再発行は、通常の接続テストとは分けたセキュリティ対応です。

再試行が必要でも回数と待ち時間を決める

一時的な失敗では、Retry-Afterが返る場合はそれに従います。独自実装なら待ち時間を徐々に延ばし、少量のばらつきと最大回数を設けます。全リクエストを同時刻に再送すると回復直後に再び負荷が集中するため、待ち行列から少しずつ戻す設計にします。

公式SDKにも一時的な失敗への自動再試行があります。アプリ側、キュー側、SDK側それぞれが再試行すると、想定以上の回数になることがあります。実行ログで総回数を数え、400や認証エラーまで無条件に再送しないようにしてください。

特にツール呼び出しで送信・登録・課金を行うアプリは、応答が失われても外部操作だけ成功している可能性があります。業務側の処理IDで完了を確認し、二重登録を防ぐ仕組みを通して再開します。単にプロンプトを同じ内容でもう一度送る方法では、業務上の重複を防げません。

ネットワークと提供元を取り違えない

社内プロキシでのみ失敗する、接続確立前に証明書エラーになる、といった場合は、APIサービスの障害とは別に通信経路を確認します。TLS検証を無効にしたり、機密データを個人回線から送ったりして解決しようとせず、管理者へエラーと接続先を渡します。

BedrockやVertex AI経由の401・429は、その提供元の認証や割り当ての問題も含みます。このモニターが正常でも、その経路まで保証していません。ログに残す時は「Claude API直接」か「他社プラットフォーム経由」かを必ず区別します。

まとめ

Claude APIでは、エラーを分類して小さく再現し、有限回の再試行と実行結果の照合で復旧させます。問い合わせにはモデル、API提供元、時刻、リクエストID、影響した処理数を添えます。復旧後もキューの残件と二重処理を確認し、通常の処理量へ段階的に戻してください。

国内の通信・アプリ・企業システム障害のまとめを見る