Claude Code障害時の対処法｜エラー別に何秒待つか、予備モデルが効く障害を32回実測

11月13日のClaude Code障害では何が起きた？

2026年11月13日の障害は、claude.aiとClaude Codeへの「認証（ログイン）」の障害でした。Anthropicのステータスページによると、日本時間18:58に調査を始め、20:05に修正を出し、20:58に解決しています。影響はclaude.ai・Console・Claude Code・Coworkに及びました。

ステータスページの最初の報告は「ユーザーがClaude.aiとClaude Codeで認証する際の問題を調査している」という内容です。Hacker Newsのスレッドは484ポイント・382コメントまで伸び、「急に再ログインを求められ、ログインしようとするとOAuthの失敗で認証できない」「/loginでCloudflareのエラーが出る」といった報告が並びました。

一方で、少数ですが「エラーは出たけれど、そのままセッションを続けられた」という書き込みもありました。ここが今回の検証のきっかけです。障害にはいくつも種類があって、Claude Codeが自分で待って乗り切れるものと、待っても無駄なものがあるはずなんです。それを実際に確かめてみたくなりました。

Claude Codeは障害時にどれだけ自動で待つ？

Claude Codeは、サーバーエラーや接続の失敗を受けると、間隔を倍々に広げながら最大10回まで自動で送り直します。今回の実測（v2.1.325・APIキー）では、500・429・401・接続不可のどれも、約3分・計11回送ってから止まりました。例外はOpusの529で、3回・約2秒で止まりました。

測り方は単純です。Claude Codeの送り先（ANTHROPIC_BASE_URL）を手元のパソコンで動かす偽のAPIサーバーに向け、そのサーバーにわざとエラーを返させました。本物のAnthropicのサーバーには1通も送っていません。Claude Codeが何回・何秒おきに送り直し、最後に何と表示したかを記録しています。サブスクリプションのログインでは同じ測り方ができないため、数字はすべてAPIキーで使った場合のものです。

送り直す間隔は、0.5秒・1秒・2秒・4秒・9秒・17秒と倍々に伸び、そこから先は約35秒で頭打ちになりました。7回目以降はほぼ35秒おきです。つまり、数十秒で直る短い障害なら、Claude Codeは何もしなくても自分で乗り切ります。実際に「5回目まで500を返し、6回目から正常に戻る」サーバーで試すと、20.7秒後に普通に返事が返ってきました！

いちばん長く待たされたのは、サーバーが接続を受け付けたまま何も返さないケースです。Claude Codeは約6分待っては送り直すのを繰り返し、こちらで25分で打ち切るまで止まりませんでした…。ただしこれは、送り先をANTHROPIC_BASE_URLで変えた「ゲートウェイ経由」の動きです。ネットワーク設定のドキュメントによると、Anthropicに直接つなぐ場合は「最初の1バイトの期限（既定180秒）」が働き、ゲートウェイ経由では働かず約5〜6分の無通信で打ち切る仕組みです。6分おきという結果はこの説明と合っています。

ゲートウェイや社内のプロキシ経由で固まりやすい環境なら、API_TIMEOUT_MSで待つ時間を短くできます。30000（30秒）を指定すると、最初の再送は30.6秒後になり、11回送って約8分で「Request timed out」と止まりました。同時に指定したCLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS=15000は、上の仕組みどおりこの接続では効いていませんでした。

意外だったのは401（APIキーの認証エラー）です。キーが間違っているなら何度送っても同じはずなのに、他のエラーと同じく3分・11回送り直していました、、、 ここは「すぐ止まってほしい」場面なので、少しもどかしい動きです。なお、サブスクリプションのログインが切れた場合は、ドキュメントによると「Login expired」と表示され、送信自体をしません。

なぜOpusの529だけ2秒で止まるのか？

Opusの529が早く止まるのは、Claude Codeの仕様です。公式ドキュメントは、APIキーでOpusを使っている場合は529の3回目で止まると明記しています。529はモデルごとの混雑なので、長く待つより別のモデルに替えるほうが早く復旧する、という設計だと読めます。

グラフにすると差は一目瞭然で、なんとSonnetの約100分の1の時間で諦めていました…！ 最初は計測ミスを疑って3回測り直しましたが、3回とも3回送って1.6〜1.7秒で止まりました。環境変数のドキュメントのCLAUDE_CODE_MAX_RETRIESの項にも、「たとえばAPIキーでOpusを使うと529の3回目で止まる」とそのまま書いてあります。

困るのは、障害が数十秒で直る場合です。「6回目から正常に戻る529」を返すサーバーで試すと、Opusは3回目までで諦めて失敗しました。Sonnetなら待っていれば通ったはずの障害です。エラーのドキュメントも、529のときは/modelで別のモデルに切り替えるよう案内しています。対話中なら、Opusで529が出たらすぐSonnetに替えるのが近道です。

なお、再試行の間隔を広げるCLAUDE_CODE_OVERLOADED_RETRY_BASE_DELAY_MS=4000も試しました。間隔は4.3秒・8.3秒に広がりましたが、回数は3回のままで12.6秒で止まりました。CLAUDE_CODE_MAX_RETRIES=2も、Opusの529には効果がありませんでした（もともと3回なので）。

予備モデル（fallbackModel）はどの障害に効く？

予備モデル（fallbackModel）は、メインのモデルが過負荷や利用不可のときに別のモデルへ切り替える設定です。実測では529と500のときに切り替わって作業が続き、401・429・接続不可では切り替わりませんでした。サーバー全体や認証が落ちる障害には効きません。

# その回だけ：起動時に指定（カンマ区切りで最大3つ）
claude --fallback-model sonnet,haiku

# いつも使う：settings.json に配列で書く
{
  "fallbackModel": ["sonnet", "haiku"]
}

驚いたのは500のときです。予備モデルを設定していると、Opusを1回も送り直さずに0秒でSonnetへ切り替わりました…！ 設定しないときは3分粘るので、まったく別の動きです。モデル設定のドキュメントには「過負荷・利用不可・再試行しないサーバーエラー」で切り替えるとあり、手元の偽サーバーの500はこの「すぐ切り替える」側に入ったようです。

逆に401では、予備モデルを設定していても使われませんでした。ドキュメントにも、認証・課金・レート制限・リクエストの大きさ・通信のエラーでは切り替えないと書かれています。認証はアカウント単位の問題なので、モデルを替えても同じ鍵で断られるからです。

どのモデルを予備にするかは、普段の作業の重さで決めます。Opus 5.5とFable 5.2の違いはClaude Fable 5.2の検証記事で比べています。

気をつけたい点が2つあります。切り替えはそのターンだけで、次に送るメッセージはまたメインのモデルから試します。また、起動時に設定内容の確認は出ず、/statusにも表示されません。切り替わったときの通知が、設定が効いていることを知る最初の手がかりになります。

CIや夜間の無人実行で障害を乗り切る設定は？

人が見ていない実行では、環境変数CLAUDE_CODE_RETRY_WATCHDOG=1が効きます。429と529を無期限に、その他の一時的なエラーを最大300回（約3時間）送り直す設定です。実測では、既定なら失敗する障害を2つとも乗り切りました。

Opusの529でも、watchdogを付けると7回目まで粘って成功しました。既定の2秒とはまるで別物です！ 夜間のバッチやCIで、障害のたびにジョブが落ちて困っているなら、まずこれを入れる価値があります。

ただし、無期限に待つのは別のリスクです。障害が長引くと、ジョブがそのまま何時間も止まって見えます。CLAUDE_CODE_RETRY_WATCHDOG_MAX_WAIT_MSで1回の送信が待つ上限を決めておくと安心です。60000（60秒）を指定した回は、60秒・8回できっちり打ち切りました。使用上限（利用枠）に達した429は、watchdogを付けてもすぐ失敗するとドキュメントにあります。

# 429・529を待ち続ける（他の一時エラーは最大300回）
export CLAUDE_CODE_RETRY_WATCHDOG=1
# 1回の送信が待つのは最大30分まで
export CLAUDE_CODE_RETRY_WATCHDOG_MAX_WAIT_MS=1800000

claude -p "今日のログを集計してレポートを作って" --fallback-model sonnet

逆に、スクリプトで失敗を早く知りたいときはCLAUDE_CODE_MAX_RETRIESを下げます。2にすると、500は3回・1.7秒で止まりました。

ログインできない認証障害のときはどうする？

11月13日のような認証障害は、Claude Codeの再試行や予備モデルでは救えません。まずstatus.claude.comで障害かどうかを確かめ、復旧を待つのが基本です。当研究所の見解では、障害中に自分から/logoutするのは避け、ログインし直すのは復旧後にするのが無難です。

手元の実測でも、401（認証エラー）は予備モデルを無視して約3分送り直し、最後に止まりました。認証の障害は、Claude Code側の設定で回避できる種類ではありません。

そのうえで、障害のときに慌てないための手順をまとめておきます。

障害が長引くと、待つ間に使用量を気にする方もいると思います。529は利用枠を消費しないとドキュメントにあります。プランごとの上限の考え方はClaude Codeの使用量制限の解説にまとめています。

検証の方法と限界

今回の数字は、APIキーで認証したClaude Code v2.1.325を、手元の偽のAPIサーバーにつないで測ったものです。本物のモデルは1回も答えておらず、サブスクリプション（claude.aiのログイン）で使う場合とは動きが違う可能性があります。

手順はこうです。Pythonで、決めたエラーを返すだけの小さなAPIサーバーを127.0.0.1で動かし、Claude CodeのANTHROPIC_BASE_URLをそこに向けました。APIキーは形式だけ合わせたダミーで、設定フォルダも空のものを使っています。claude -pで一言の返事を頼み、サーバー側で届いた時刻とモデル名を記録しました。計32回（同じ条件の繰り返しを含む）測りました。

ここで一度つまずきました、、、 サブスクリプションのログインでは、送り先を偽サーバーに向けると「ログインしていない」扱いになり、測れないんです。そのため、サブスクリプションでの回数や時間は今回の結果と同じとは限りません。公式ドキュメントの「Opusは529の3回目で止まる」も、APIキーを条件にした書き方です。

Claude Codeの料金やプランの基本はClaude Codeとは？の入門記事で説明しています。

ほかにも限界があります。偽サーバーはエラーの種類と短い本文だけを返し、本物の障害で付くヘッダーは返していません。各条件は1〜3回で、送り直す間隔には揺らぎがあります。11月13日の認証障害そのもの（ログインの更新の失敗）は再現していません。

まとめ