Claude Code が 500、繰り返す 529、または「response may be incomplete」を表示したら、task 全体を再送しないでください。応答が切れたことは、file edit、shell command、外部 write が何も起きなかった証明にはなりません。同じ prompt の再送で、完了済み tool call が二度走ることがあります。
先に error branch を決め、対象 service path の回復を待ち、同じ session を resume して実状態を照合します。その後でだけ continue を送ります。500 は api_error、繰り返す 529 は全体 capacity overload、mid-response notice は完了 block が残り、最後の block だけ欠ける可能性がある状態です。
特に危ないのは 529 です。Claude Code の説明では、繰り返す 529 は過負荷であり、個人の利用上限ではなく、quota にも数えられません。まず終端の文言を下の表に当ててください。
| 見えている文言 | まず扱う分岐 | 最初の一手 | 同じ path で確認すること | 深掘りする境界 |
|---|---|---|---|---|
出力開始前の 500 | service-side internal error | Claude Status を見て短く待つ | 同じ session、auth route、model | incident がなく同じ path が失敗 |
出力開始前に繰り返す 529 | 全ユーザー側の capacity overload | status を見て待つ。task が許す時だけ /model | 同じ session と route を cool-down 後に確認 | status と route を見ても繰り返す |
Server error mid-response、connection closed、stalled stream | turn の一部が完了済み | task を再送せず、残った output と state を確認 | 同じ session を resume し、照合後に continue | tool や外部 write の完了を証明できない |
429 | API key または provider の制限 | 待機時間、Console limits、model limits、API 経路を見る | window 後、または経路 correction 後に retry | headers や Console が limits を示す |
Server is temporarily limiting requests、session limit、weekly limit | Claude Code throttle または usage window | cool down、または plan/session window を確認 | window 変化後に同じ workflow を再開 | 文言が plan や reset window を示す |
| plan が想定と違う | route override | /status と ANTHROPIC_API_KEY、proxy を確認 | intended subscription / API-key route を確認 | 正しい route でも同じ分岐で失敗 |
先に分岐し、理屈は後で足す
Claude Code の error reference は、runtime errors を Claude API の code に対応させています。また、Claude Code は一部の transient failures を表示前に自動 retry します。つまり終端に見えている一行は、すでに自動処理が終わった後の判断点です。
最初の問いは「Claude が落ちているのか」でも「自分の quota が尽きたのか」でもありません。その一行がどの document class に属するかです。500 なら status、短い待機、同じ path の一回 retry。繰り返す 529 なら capacity。429 なら API key / provider / model limits。session や weekly limit なら usage window。route が怪しいなら /status を先に見ます。
2026-08-04 の確認時点では、Claude Status は Claude API と Claude Code を operational と表示し、履歴には 8 月 3 日に解決済みの model error incident がありました。この snapshot は現在の原因を決めません。読者の時点で live status を確認し、続けて session と state を照合します。
500 分岐：status、短い待機、一回だけ同じ command
Anthropic の API error docs は HTTP 500 を api_error に対応させています。Claude Code の error reference でも API Error: 500 Internal server error は infrastructure-side の問題であり、prompt、settings、account が直接原因ではないとされています。
安全な順序は短くできます。
- Claude Status を確認する。
- 少し待ち、同じ command または message を一度だけ retry する。
- 検証中に model、auth route、shell profile、prompt をまとめて変えない。
- incident がなく同じ path がまだ失敗するなら、詳細を保存して
/feedbackまたは support route に進む。
症状が持続する API Error: 500 だけなら、次は Claude Code API Error 500 ガイド です。ここでは 500 を rate limit や 529 と誤処理しないことだけを担当します。
529 分岐：過負荷であって、利用上限ではない
Claude Code docs は繰り返す 529 について明確です。API が全体の capacity pressure を受けており、Claude Code はすでに retry 済みで、529 は利用上限ではなく quota にも数えられません。
最初の一手は upgrade ではありません。
- status に capacity notice がないか見る。
- 数分待ってから試す。
/modelは、task が別 model を許す時だけ使う。- 短い cool-down 後、同じ session と route を確認する。
それでも repeated 529 が戻るなら、Claude Code overloaded error ガイド に進みます。529 overloaded_error と 429 rate_limit_error を同じ扱いにすると、billing、key rotation、plan change に早く寄りすぎます。
元の session を再開し、task を再構成しない
現在の Claude Code error reference は、生成開始後の失敗を別扱いにしています。server error mid-response、connection closed、stalled stream では、完了した response block を会話に残し、途中の final block を破棄します。再送で同じ tool call が二度走る可能性があるため、incomplete notice が表示されます。
画面が残っているなら、まず保持された response を読みます。完了した edit、command result、test、deployment step は、実状態を確認する evidence です。「その後の予定も完了した」という意味ではありません。service が戻っても、照合前に元の task を送らないでください。
process が終了した場合は、task を始めた project directory で次を使います。
bashclaude --continue claude --resume
claude --continue は current directory の直近 session、claude --resume は picker を開きます。Session 管理では、resume により tool calls と results を含む history が戻ると説明されています。新しい session に記憶だけで説明するより、重複防止に必要な evidence を保てます。
同じ session を二つの terminal で同時に resume しないでください。message が一つの transcript に混ざります。別案が必要なら、明示的に fork/branch します。
continue の前に side effect を照合する
Conversation は試行内容を示し、system of record は実結果を示します。
| 可能な side effect | 確認する evidence | 安全な判断 |
|---|---|---|
| direct file edit | git status --short、git diff -- <path>、file contents | 現在の edit を保持または明示的に戻し、同じ edit を依頼しない |
| Bash が file を変更 | working tree、generated files、output、timestamp | checkpoint 対象外の可能性があるため、完了した前提で確認 |
| test、build、migration が実行中 | terminal、process、lock、report、migration table | 待つか明示的に停止し、二つ目を起動しない |
| commit / branch 操作 | git status、current branch、git log -1 --oneline | 観測した Git state から続ける |
| CI、deployment、ticket、API、DB write | run/deployment/request ID、record、idempotency key | 外部 owner で確認し、stream 切断を失敗と推測しない |
Git ではまず read-only で確認できます。
bashgit status --short git diff --stat git diff git log -1 --oneline
これは remote state の証明ではありません。PR、deployment、database、message、payment の可能性があるなら、対象サービスの記録を確認します。local session の再起動は、外部で受理済みの処理を取り消しません。
照合後、resume した会話に次のような境界を渡します。
text中断した turn で完了した tool call を列挙し、現在の working tree と 私が示す外部 state に照合してください。command の再実行や外部変更はせず、 次の一手を一つだけ提示して確認を待ってください。
checkpoint は local undo であり transaction log ではない
Checkpointingは direct file-editing tool の snapshot を session と共に保存するため、resume 後も /rewind を使えます。誤った edit が特定できている時に有効です。
一方、Bash による file change、多くの background subagent edit、session 外の同時編集、一部の link path は対象外です。deployment、API、database、message、payment も戻せません。file history は Git、remote state は各サービスの audit trail で確認します。
何を戻すかを確認してから rewind してください。blind rewind と blind replay の組み合わせは、別の重複を作ります。
レート制限分岐：429、temporary limiting、利用枠を分ける
Claude Code で「制限」と見えるものは少なくとも三つあります。
一つ目は実際の API 429 rate_limit_error です。API key、provider project、model-specific limits、concurrency、retry-after が evidence になります。この場合は Claude Code rate limit ガイド が担当します。
二つ目は Server is temporarily limiting requests (not your usage limit) という temporary limiting です。これは短い throttle として扱い、少し待って同じ path を再確認します。plan が尽きた証拠ではありません。
三つ目は本当の usage window です。session limit、weekly limit、Opus limit、reset time を含む文言なら、/usage、reset timing、plan window を見ます。続きは rate-limit reached ガイド または usage limits 診断 です。
route override 分岐：plan の前に auth を見る
Claude Help は、ANTHROPIC_API_KEY の environment variable が authenticated subscription より優先されること、/status で active auth method を確認できることを説明しています。だから route check は補助ではなく復旧フローです。
secret を出さずに確認します。
- Claude Code で
/statusを実行する。 ANTHROPIC_API_KEYが shell や environment にあるかだけ確認し、key 自体は貼らない。- subscription auth、direct Anthropic API、Bedrock、Vertex、proxy のどれかを確認する。
- 本来使うつもりだった route で同じ request を再実行する。
route を直したら結果が変わる場合、本当の問題は route mismatch です。同じ intended route でまだ同じ分岐が出るなら、support 用の evidence がきれいになります。
エスカレーション前に残す evidence
Anthropic API の error response には top-level request_id が入る場合があり、API response には request-id header があります。Claude Code には /status、/model、/usage、/feedback もあります。
保存するものは短くて十分です。
500、529、429、または limiting message の正確な終端文言- 失敗時刻と timezone
- その時点の Claude Status
/statusで見えた active route- model と
/modelの変更有無 - same-path retry の結果
- request ID または feedback context
分岐を決め、最小動作を行い、同じ path で失敗が残ったら、そこで止めます。無作為な retry は evidence を弱くします。
よくある質問
Claude Code の 529 はレート制限ですか？
いいえ。繰り返す 529 は overload として文書化されています。本当の API rate limiting は 429 rate_limit_error で、temporary limiting と plan-window message も別です。
Claude Code API Error 500 で最初に何をしますか？
Claude Status を確認し、少し待ち、同じ command または message を一度だけ retry します。incident がなく同じ path がまだ落ちるなら、詳細を残して 500 ガイドまたは /feedback に進みます。
Claude Status が緑なのに失敗しますか？
緑の status は live incident を一つ除外するだけです。正確な error、active auth route、model、same-path retry result はまだ確認が必要です。
API key が subscription を上書きしているか確認する方法は？
Claude Code で /status を実行し、shell に ANTHROPIC_API_KEY が設定されているか確認します。key 本体は貼らないでください。
529 を見たら plan を上げるべきですか？
最初の一手としては不要です。繰り返す 529 は overload branch です。upgrade 判断は、明確な plan-limit または usage-window wording の時だけです。
障害後に同じ task を再送してよいですか？
incomplete notice がある場合は危険です。同じ session を resume し、残った block、local state、remote state を確認してから、境界付きの continue を送ります。
/rewind は shell command や deployment を戻しますか？
戻しません。checkpoint は対応する direct file edit の安全網です。Bash、process、CI、deployment、API、database はそれぞれの owner で確認します。
