Claude Code が API Error: 500 を出したとき、まず避けたいのは「とりあえずもう一回」で時間を溶かすことです。この症状は一つの universal retry message ではありません。実際には、Anthropic 側の live incident、login または OAuth の失敗、壊れた resumed session、あるいは想定外の auth route という少なくとも四つの分岐があり、それぞれ最初の動きが違います。
Status が赤いなら、たいてい必要なのはローカル設定をさらに触ることではなく、待つことです。Status が緑でも、次の一手がまた同じ retry になるとは限りません。login path を見直す、新しい session を作る、あるいは Claude Code が今どの auth owner で request を送っているかを確認するほうが、ずっと情報量があります。
このページが狭く作られている理由もそこにあります。Internal server error は login 中にも出ますし、Status が回復した後でも古い resumed session だけが壊れたまま残ることがあります。だからこのページは usage、billing、install の広い話をまとめるのではなく、API Error: 500 をいちばん速く正しい分岐に戻すことだけに集中します。
一つの branch-specific fix を当てたら、必ず同じ経路で再確認してください。緑の Status の下で同じ経路がまだ失敗するなら、request_id、/status、/debug を押さえてからエスカレーションするのが筋です。
Start Here: Which 500 Branch Are You In?
症状は狭く見えても、最初の判断は狭くありません。Anthropic の API docs では HTTP 500 は api_error、HTTP 529 は別の overloaded_error と定義されています。ここまでは基礎知識として有用ですが、実務ではまだ足りません。次に待つべきか、再 login すべきか、新しい session を試すべきか、あるいは Claude Code が本当にどの route で request を送っているかを調べるべきかは、別の判断が必要です。
| いま見えている症状 | まず疑う owner | 最初に取る安全な一手 | 同じ経路で何を確認するか | どこでエスカレーションするか |
|---|---|---|---|---|
| Claude Status が赤い、または incident が進行中 | Anthropic 側の outage や auth incident | ローカル設定変更を止めて回復を待つ | incident 解消後に同じ failing path を再試行する | 緑に戻っても同じ path がまだ 500 を返す |
login または OAuth 中に Internal server error が出る | OAuth expiry、auth degradation、clock skew、local credential state | /status を見てから /login、必要なら claude doctor | 同じ login path が回復したか確認する | 緑の status route でも login path が失敗する |
| Status は緑なのに一つの resumed session だけ壊れている | 壊れた session state または stale context | 古い session を叩かずに fresh session を始める | 同じ task を新しい session で試す | 新しい session でも同じ壊れ方をする |
| Claude Code が API key、proxy、別 provider route を使っている可能性がある | ANTHROPIC_API_KEY override、route mismatch、unexpected auth owner | /status、env、route config を確認する | known-good path で同じ request を比較する | 同じ route が fresh credentials でも失敗する |
この分岐ボードがページの中心です。コミュニティ回答では、どの 500 も「Anthropic が落ちている」か「時間を置けば直る」に圧縮されがちです。けれど、今すぐ戻したい読者にはそれでは足りません。incident は確かに実在する分岐ですが、それだけではありません。
If Claude Status Shows an Incident Right Now
Status を先に見るのは、不要なローカル作業を減らすためです。Claude Status は 2026-04-10 の確認時点では緑でしたが、履歴には 2026-04-08 から 2026-04-09 にかけて authentication、Claude Code、Claude.ai、elevated error rates に関する incident が載っていました。ここで重要なのは「最近も本当に platform incident があった」という事実であって、日付の羅列そのものではありません。
実務ルールは短くて十分です。対象コンポーネントが赤いなら、ローカル設定の変更を止めてください。reinstall、route switch、設定の総入れ替えを incident 中にしても、速く直るより先にノイズが増えやすくなります。incident が解消したら、前に落ちた同じ pathを再試行します。同じ path を使うからこそ、incident が全部だったのか、それとも別の分岐が残っているのかが分かります。
ここでは 500 と 529 を頭の中で分けておくことも大切です。どちらも読者には「いま platform が不安定」に見えるかもしれませんが、docs 上では別の branch です。あとで support に渡すときも、この違いはそのまま価値になります。
ただし、この section を universal explanation にしてはいけません。Status が緑で安定しているなら、次は待つことではなく branch diagnosis です。incident-aware であることと、全てを incident にしてしまうことは違います。
If the Error Appears During Login or OAuth
この分岐は見落とされやすいです。読者が見るのは同じ Internal server error なので、session 中の failure と同じだと思ってしまうからです。けれど、Claude Code の current troubleshooting docs はもっと狭い flow を示しています。まず /status で active auth method を確認し、次に /login で session を更新し、それでも repeated prompts や違和感が残るなら claude doctor で machine time や local keychain を含む環境を確認します。
この順序が重要なのは、login failure と runtime failure が同じ recovery job ではないからです。login 中に失敗しているなら、問いは「Claude Code 全体が壊れているか」ではなく、「auth degradation、expired token、clock skew、damaged local state のどれで login path が壊れているか」です。ここを直接答えるほうが、広い背景説明より役に立ちます。
順序は短くて構いません。最初に /status、次に /login、それでもおかしければ claude doctor。この順序なら OAuth、時計、keychain のどれが怪しいかを推測だけで回す必要がありません。
検証境界も絞っておくべきです。同じ login path を検証してください。別の surface で login できたことを、そのまま Claude Code の回復証拠にしないほうがいいです。緑の status route でも Claude Code の login path が再 login 後に落ちるなら、それは clean な auth-specific support case です。
If Status Is Green but the Resumed Session Still Fails
Status が緑でも、今開いている session が健康とは限りません。これが generic advice が落としやすい分岐です。現在の anthropics/claude-code issue では、API Error: 500 が resumed session に紐づき、context がほぼ壊れ、新しい chat で改善したという報告があります。これだけで universal root cause にはなりませんが、最初の動きを変えるには十分です。
ここでいちばん価値のある control test は、古い session を大事にしすぎないことです。fresh session を作って、必要最小限の context で同じ task をやり直してください。fresh session が通るなら、古い session state が failure source だった可能性が高いと分かります。fresh session でも同じ失敗なら、session-state branch をすぐに外して次へ進めます。
読者がいちばん時間を失うのはここです。Status は緑だから waiting は意味がない、でも old session は context を持っているから、と同じ session を何度も叩いてしまう。これは自然な反応ですが、よく間違います。old context 自体が問題かもしれません。500 に対しては、同じ retry より fresh session のほうが診断価値があります。
もしここで本当の問題が 500 recovery ではなく、usage exhaustion、shared consumption、billing path confusion だと分かったら、このページで引き止めないほうがいいです。その場合はClaude Code の usage limit 診断ガイドのほうが適切です。
If You May Be on an API Key, Provider, or Proxy Route
Claude Code は常に subscription OAuth path で動いている、と考えている読者は少なくありません。ところが Anthropic の troubleshooting docs には、ANTHROPIC_API_KEY が存在すると Claude Code は subscription OAuth ではなくその key を使う、と明記されています。この一行だけで、かなり多くの confused debugging が説明できます。
だから /status は回復フローの前半に置くべきです。active auth method が想定と違えば、その後の結論は全部揺らぎます。official status page が緑でも、API-key route や proxy route の実態は別です。provider や proxy の failure は official route と同じ形で見えないことがあります。
ここで安全なのは、すぐに別 provider へ飛びつくことではありません。active route を確認し、stale credentials や unexpected key を片付け、同じ request を known-good path と比較します。意図しない ANTHROPIC_API_KEY を外す、あるいは intended auth owner に戻したら問題が消えるなら、本当の branch は route mismatch でした。同じ route が fresh credentials でも失敗するなら、ようやく sharper escalation case になります。
この section も install problem まで広げないほうがいいです。もし本質が broken local setup、missing prerequisites、first-time configuration なら、Claude Code の install ガイドに移るほうが読者の仕事に合います。routing は一ページ万能化の口実ではありません。
Verify the Fix and Know When to Escalate
Anthropic の API docs では、error responses に request_id、通常の responses に request-id header が付くと説明されています。取れるなら残してください。Claude Code の current docs では /status、/debug、/cost も diagnostic surface として使えます。巨大な packet は不要です。必要なのは、support が「どの分岐をもう試したか」を理解できるだけの clean evidence です。
エスカレーション前に、同じ failing path から次を集めておくと十分です。
- exact error string と、あれば
request_idまたはrequest-id - failure 発生時の
/statusが赤か緑か - 問題が login 中、old resumed session、一つの auth route のどこで起きたか
/debug出力、または最小の reproduction steps
この違いは大きいです。「Claude Code が 500 を出す」は弱い報告ですが、「緑の status で、同じ login path が /login 後も落ちる。request_id あり」はそのまま使えます。「緑の status、fresh session は通るが old resumed session はまだ 500」も有用です。大事なのは長さではなく、曖昧さを減らすことです。
エスカレーション境界は明確です。緑の status route で、同じ path が最小の branch-specific fix の後も失敗するなら、そこで improvisation を止めてください。その先は random retry より clean handoff のほうが価値があります。
もし見えてきた branch が本当は 500 recovery ではなく usage や explicit rate limit の話なら、Claude Code の rate limit ガイドへ移るのが適切です。そちらは quota と cost interpretation のページで、こちらは 500 を正しく直すためのページです。
Frequently Asked Questions
Claude Code の API Error: 500 と 529 overloaded_error は同じですか。
違います。Anthropic の docs では 500 は api_error、529 は overloaded_error です。どちらも platform instability のように見えますが、documented branch は別です。
Claude Status が緑なのに、なぜまだ 500 が出るのですか。
緑の Status が除外するのは live-incident branch だけだからです。login-path problem、broken resumed session、unexpected auth-route branch はまだ残ります。
最初に Claude Code を再インストールすべきですか。
普通は違います。この症状では reinstall は優先順位が低いです。Status、branch test、same-path verification のほうが先です。
古い session だけ失敗するなら、最初の確認は何ですか。
fresh session を作って、必要最小限の context で同じ task をやり直してください。old session state が原因かどうかを見る最速の方法です。
support には何を渡せばいいですか。
exact error text、あれば request_id、/status の結果、試した branch、最小 reproduction steps です。長い general complaint より clean branch evidence のほうが有用です。
The Working Rule
Claude Code の API Error: 500 は、generic retry message ではなく branch-first recovery problem として扱うほうが速く直せます。Status を見て、分岐を選び、小さく直し、同じ path で確かめ、それでも緑の下で失敗するなら evidence を添えてエスカレーションしてください。