Claude Code API Error 500・529の対処：作業を重複させずに再開

Claude CodeのターミナルにAPI Error: 500が出たら、再試行の前に、どの場面で出たかを確かめます。作業の途中なら、元の会話を残し、完了した処理を確認してから続きを指示してください。 回答が届かなかったことだけでは、ファイル変更やコマンド、外部サービスへの操作が失敗したとは分かりません。529やThe response above may be incompleteで止まった場合も同じです。

会話が開いたままなら、その画面で完成した回答とツールの結果を読みます。プロセスが終了したなら、claude --resumeで対象のセッションを選びます。次にファイル、実行中の処理、外部の記録を照合し、完了済みの操作を除いて残りだけ進めます。

ログインの途中で出た500は、まだ作業が始まっていないので照合は要りません。稼働状況を確認してから、ログインをやり直します。特定の会話を再開したときだけ毎回500になり、新しいセッションは動く場合は、まず元の会話の復旧を試し、直らなければ確認済みの結果を新しいセッションへ引き継ぎます。529の過負荷、利用枠の上限、429は、500とは別に判断します。

API Error 500・529：表示と出た場面で最初の操作を分ける

Anthropic APIに直接つないでいる場合、現在のClaude Codeは500を次のように表示します。

API Error: 500 Internal server error. This is a server-side issue, usually temporary — try again in a moment. If it persists, check https://status.claude.com.

まず、自動再試行のカウントダウンが動いているか、エラーが確定して入力待ちになっているかを見ます。再試行中に同じ依頼を重ねて送る必要はありません。エラーが確定していたら、表示と出た場面から次の操作を選びます。表示の意味は現在のClaude Codeエラー案内に沿っています。ログイン中と再開した会話の行は、後の節で詳しく扱います。

Anthropic直結ならClaude Statusを見ます。Bedrock、Google Cloud、Microsoft Foundry、独自ゲートウェイでは、エラー末尾に示されたサービスを確認してください。Anthropicの表示が正常でも、別の接続先まで正常とは分かりません。Webの会話や連携アプリで出る一般的な表示なら、Claudeの内部サーバーエラーを利用画面から切り分ける方法を参照してください。自分のプログラムからAPIを直接呼んで500 api_errorが返る場合はClaude APIの500 api_error対処法、HTTPステータスが出る前の接続エラーならClaude CodeのUnable to connect to APIを直す方法、403や503ならClaude Codeの403・503・529の発生元と直し方が対象です。

500は待ってから再試行、529は混雑として扱う

APIそのものが返した500は、公式案内ではAPI内部の予期しない障害で、プロンプト、設定、アカウントが原因ではないと説明されています。作業中に出た500だけを理由に、再ログイン、設定の削除、新規セッションでの作業のやり直しへ進む必要はありません。まず待ち、処理の重複が起きないことを確かめて再試行します。

元の依頼は会話に残っているため、本文もツール処理も始まっていない失敗なら、長い依頼を貼り直さずtry againと伝える方法が案内されています。手動の確認はまず1回にとどめ、同じエラーなら送信を止めて原因を調べる、という進め方が実用的です。これは切り分けのための目安であり、公式の一律回数制限ではありません。

繰り返す529は、利用者全体に関わる容量不足です。公式のClaude Code案内では、529は利用枠の上限ではなく、そのエラーは利用枠も消費しないと説明されています。最初にプランを上げるのではなく、数分待つか、使える別モデルを選びます。モデル別の混雑と切り替えはClaude Codeの529過負荷エラーへの対処で詳しく扱っています。500・529の公式説明

「途中で止まったら自動再試行しない」には例外がある

Claude Codeは、一時的な失敗を指数バックオフで最大10回再試行してからエラーを表示します。これは最初の送信を含めた「合計10回」という意味ではなく、すべての中断に同じ回数が適用されるわけでもありません。

たとえばv2.1.284以降では、思考が終わっていても、まだ本文やツール呼び出しを始めていない時点の500・過負荷は最大2回再試行します。一方、本文やツール呼び出しのブロックが完成した後、または思考完了後にそれらを開始してから応答が途切れた場合は、元のリクエストをそのまま再送しません。完成した出力を残し、完成したツール呼び出しを実行して、その結果から続けます。重複実行を避けるためです。自動再試行の条件

つまり「画面に何か出た」「途中だった」だけでは判断できません。不完全な応答の通知が出たら、次の復帰手順へ進みます。

500のたびに自動で「続けてください」と送るスクリプトでClaude Codeを包む方法もあります。ただ、エラーが表示された時点で、Claude Codeはすでに再試行を済ませています。ツール呼び出しが完成した後の中断で元のリクエストを送り直さないのも、重複を避けるためです。そこへ外から続行の指示を送り込むと、完了した処理を確かめる段階が抜けます。読み取りだけの作業なら影響は小さい一方、push、デプロイ、DB更新のように結果が会話の外に残る作業では、自動の続行より次の照合を優先してください。

元のセッションを開き、作業履歴を確認する

同じ会話が入力を受け付けているなら、再起動せずそのまま使えます。まず最後に完成した回答、ツール呼び出し、実行結果を読み、どこまで進んだかを確認します。最後の文章やツール呼び出しが途中で切れていた部分は、ターン終了時に破棄されることがあります。途中の文章に「次にデプロイする」と書かれていても、デプロイ完了の証拠にはなりません。不完全な応答の扱い

プロセスが終了した場合は、作業していたプロジェクトのディレクトリで、次のコマンドを使います。

claude --resume

一覧から、時刻と会話内容が合うセッションを選びます。一覧を別プロジェクトまで広げるにはCtrl+Aを使えます。セッションIDが分かっている場合は、次の形式で直接指定します。山かっこの部分を実際のセッションIDに置き換えてください。

claude --resume <session-id>

現在のID指定では、まず現在のプロジェクト、次に同じマシンの他のプロジェクトを検索します。v2.1.223より前は検索範囲が現在のプロジェクトとそのGit worktreeに限られるため、元の作業ディレクトリから開きます。claude -pやAgent SDKで作ったセッションは対話用の一覧に出ません。元のJSON出力にあるsession_idを確認して指定します。セッションが見つからない場合の公式案内

再開後は、会話内容、作業ディレクトリ、ブランチ、最後の操作が中断した作業と合うことを確かめます。履歴を開けたことは、予定されていた全工程が完了したことを意味しません。

画面が固まっているときだけ、取消しと再起動を試す

再試行中の表示が動いている状況と、入力にも反応しない状況は分けます。公式のトラブルシューティングは、操作が固まった場合にCtrl+Cで取消しを試し、反応しなければターミナルを閉じて再起動し、同じディレクトリでclaude --resumeを使う手順を案内しています。

ただし、画面の取消しや再起動だけでは、別のバックグラウンド処理や、外部で受理された操作まで停止したとは確認できません。それらは次の手順で個別に調べます。

ファイル・実行中の処理・外部操作を照合する

会話の履歴は「何を依頼し、どんな結果を受け取ったか」を示します。実際の完了は、対象のファイルやサービスの記録でも確認します。この照合は、完成したツール呼び出しが実行され得るという公式仕様を踏まえた、重複を避けるための進め方です。

Git管理のプロジェクトなら、最初に次の読み取り専用コマンドで状況を確認できます。Claude Code内のスラッシュコマンドではなく、作業ディレクトリのシェルで実行します。

git status --short
git diff --stat
git diff
git diff --cached
git log -3 --oneline

変更済み、ステージ済み、コミット済みの状態を分けて見ます。新規ファイルの内容はgit diffに出ないため、git status --shortで示されたファイルを別途読みます。Gitに含まれない生成物も、必要なファイルが存在するか確認してください。

外部の状態は、そのサービスを確認できる権限で調べます。ローカルにコミットがあることだけではpushの成功は分かりません。同様に、Claude Codeに完了の返答がないことだけでは、デプロイやDB更新の失敗とは判断できません。

必要なら、復帰した会話に次のように確認を依頼します。外部サービスの結果は、確認できたIDと状態を追記してください。

中断した作業を続けます。まず会話に残っている完了済みのツール結果と、
現在のファイル・Gitの状態、実行中のバックグラウンド処理を確認してください。
この確認中はファイル変更やコマンドの再実行、外部への書き込みをしないでください。
外部処理は、私が示す実行IDと現在の結果に照合してください。
完了・実行中・未着手・結果不明に分け、残っている作業を示してください。

「実行中」は待機か停止の判断が必要で、「結果不明」は追加確認が必要です。どちらも、未着手としてまとめて再実行しないようにします。

確認できた結果を渡し、残りだけ続ける

照合が済んだら、単に元の依頼を貼り直すより、完了済みの処理と次の範囲を明示すると再開しやすくなります。たとえば、編集とテストは済んでいて、CIもすでに開始されているなら、次のように伝えます。以下は実際の実行結果ではなく、再開指示の例です。

確認結果：ファイル編集は反映済み、テストは成功、コミットも存在します。
CIは既存の実行IDで進行中です。編集・テスト・コミット・CI起動は繰り返しません。
残っているのは、そのCI結果の確認と、失敗した場合の原因調査です。
元の会話の続きとして、この残作業だけ進めてください。
新しい外部変更が必要になった場合は、対象と理由を示して確認を待ってください。

対話セッションでは、公式案内もcontinueで最後に完成したブロックから続けるよう説明しています。ただし、変更を伴う長い作業では、上のように確認済みの結果と残作業を添えることで、何を繰り返してはいけないかが明確になります。応答中断後の続行

次の操作が完了したら、その結果が作業の完了条件を満たすかを確認します。たとえば「CIが成功した」「対象ファイルに必要な変更があり、指定のテストが通った」といった結果です。会話が返ってきたことだけを復旧成功の判定にしないでください。

なお、-pやSDKなどの非対話実行では、メインの応答がテキストのみでツール呼び出しを含まない場合、途中の出力を保持して最大3回、自動で続きを生成する条件があります。これは元の処理を丸ごと再送する動作とは別です。「不完全な応答なら常に手動で続行」とは限りません。

セッションを再開できない場合

再開時のエラーは500・529そのものと分けて対処します。公式の再開エラー案内では、状況ごとに次の操作が異なります。

claude --resumeからの読込み失敗は終了コード1で終了します。一方、実行中の会話で/resumeが失敗した場合は、元の会話は動き続けます。失敗したからといって、今ある会話まで消去する必要はありません。

履歴はローカル保存で、既定の保存期間は30日です。削除済みの履歴や別マシンの履歴は、IDを指定するだけで復元できるとは限りません。また、現在のエージェント一覧では、別の実行中のターミナルやプロセスが保持している会話を二重に開くことを拒否します。同じ会話を複数箇所から動かそうとせず、既存の実行を確認してください。会話の占有とバックグラウンド履歴

再試行や必要な更新後も開けない場合は、新規セッションへ移る選択があります。その場合も、同じ作業を初めから依頼するのではなく、照合したファイル・Git・外部処理の結果と、未完了部分をまとめて渡します。会話を復元できないことと、作業ファイルや外部の結果が失われたことは別です。 会話は開けても、送るたびに500が返る場合は次の節に進んでください。

再開した会話だけ500が出続け、新しいセッションは動くとき

会話は開けるのに、その会話で送るたびに500が返り、同じマシンで始めた新しいセッションは普通に応答する。この組み合わせなら、全体の障害よりその会話に固有の問題を疑えます。逆に、新しいセッションでも短い依頼が500になるなら、原因は会話ではなく稼働状況か接続経路の側です。その場合は前の節までの待機と再試行に戻り、障害情報がないまま続くなら/feedbackで報告します。

GitHubには、この状況にあたる利用者の報告があります。大きくなった古い会話を再開するとAPI Error: 500 status code (no body)で失敗し、新しい会話は動くという報告（#58827、2026年5月、v2.1.50）では、報告者が保存された履歴の中の空の思考ブロックと空のツール結果を原因と分析しています。数日続いたワークフローの会話が/rewindの後も毎回500を返し、別のタブで始めたセッションは動いたという報告（#70650、2026年6月、v2.1.178）もあります。どちらもAnthropicが原因を認めたものではなく、現在のバージョンで再現が示されたものでもありません。

公式のエラー案内は、500と保存された履歴の関係には触れていません。ただし、いくつかの400エラーについては、保存された履歴に含まれる内容のせいで、再開した会話のすべてのターンが失敗する例を挙げています。そこでの対処は、claude updateで更新して会話を再開し、それでも続くなら/clearでその内容を引き継がない会話を始めることです。/clearの後も同じエラーが出るなら、原因は保存された会話ではなくリクエストの経路にある、とも説明されています。履歴が原因の400エラーの例

次の手順は、この切り分けの考え方を500に当てはめたものです。

1. 稼働状況を確認し、新しいセッションで読み取りだけの短い依頼を送って、応答が返るかを確かめます。返らなければ、会話に固有の問題ではありません。
2. 新しいセッションが動くなら、元の会話を閉じてclaude updateで更新し、claude --resumeで同じセッションを開き直して1回だけ送ります。元の会話には完了した作業の記録が残っているので、ここで直れば最も確実に続きへ戻れます。
3. それでも毎回500なら、その会話での送信を止めます。前の節の手順でファイル、Git、外部処理の状態を照合し、確認できた結果と残作業を新しいセッションに渡します。元の依頼をそのまま貼り直すと、完了済みの編集やコマンドを最初からやり直させることになります。
4. 失敗した会話のセッションID、エラー全文、発生時刻を控えて、/feedbackで報告します。

新しいセッションは前の会話の文脈を持っていません。次のように、確認済みの状態と、繰り返してはいけない操作を明示して始めます。以下は引き継ぎの例です。

前の会話は再開後、毎回API Error 500で応答が止まるため、新しいセッションで続けます。
確認済みの状態：ファイル編集は反映済み、テストは成功、コミットはローカルにあり、pushは未実施です。
編集・テスト・コミットは繰り返さないでください。
残っているのはpushとCI結果の確認です。始める前に、現在のGitの状態を読み取りだけで確認してください。

~/.claudeの中の履歴ファイルを手で書き換えたり、フォルダーごと削除したりする必要はありません。書き換えた履歴は読み込めなくなることがあり、フォルダーを消すと他の会話の履歴や設定まで失います。作業の結果はファイル、Git、外部サービスの側に残っているので、新しいセッションでもそこから続けられます。

ログイン中の「OAuth error」500：稼働状況を見てから再ログイン

/loginや初回起動のサインインで500が出ることもあります。GitHubの報告では、ターミナルにOAuth error: Request failed with status code 500が表示され、その前にOAuth error: timeout of 15000ms exceededが出ることもあります。ブラウザ側のclaude.aiの認可画面に「Authorization failed」と「Internal server error」が出た例と、認可画面では完了と表示されたのにターミナルが500になった例の両方があります。OAuth error: Failed to fetch user roles: Request failed with status code 500という形の報告もあります（#33226、#44271、#44725、2026年3〜4月、v2.1.72〜v2.1.92）。いずれも利用者の報告で、Anthropicが原因を説明したものではありません。

この段階ではまだ作業が始まっていないので、ファイルや外部操作の照合は必要ありません。次の順に進めます。

最初にClaude Statusの履歴を確認します。2026年8月24日には、UTCの16:02〜16:08と20:00〜20:08に、Claude Codeをサブスクリプションでつなぐ際のログインを含む、Claude.aiのログイン障害が記録されています。どちらも数分で収まっているので、障害が出ていれば解消を待ってから1回だけ試し直します。

障害が出ていない、または解消後も失敗するなら、公式のログインと認証のトラブルシューティングに沿ってサインインし直します。Claude Codeの中で/logoutを実行して完全にサインアウトし、Claude Codeを閉じてからclaudeで起動し直し、認証をもう一度済ませます。ブラウザが自動で開かない場合や、狭いターミナルでURLが折り返してクリックできない場合は、ログイン画面でcを押すとOAuthのURLをコピーできます。/logoutは保存された認証情報をすべて消すため、MCPサーバーへのログインやプラグインの秘密情報は後で入れ直しになります。

OAuth error: Invalid codeと出た場合は、ログインコードの期限切れか、コピー時に途中で切れています。ブラウザが開いたら、すぐに手続きを終えてください。

WSL2、SSHの接続先、コンテナでClaude Codeを動かしている場合は、ブラウザが別のホストで開くため、認証後のリダイレクトがローカルのコールバック用ポートに届きません。ブラウザに表示されるログインコードを、ターミナルのPaste code here if promptedに貼り付けます。貼り付けが入力欄に届かないときは、標準入力からコードを読む次のコマンドを使えます。

claude auth login

同じアカウントが別のマシンではログインでき、このマシンだけ失敗する場合は、このマシンのファイアウォール、プロキシ、コールバック用ポートへの経路を疑います。Windowsで、受信を遮断する管理ポリシー付きのファイアウォールがあるマシンだけ失敗したという報告（#44725）がありますが、原因として確かめられたものではありません。

ログインできたら、/statusで有効な認証方法を確認します。承認済みのANTHROPIC_API_KEYが環境にあると、Claude Codeはサブスクリプションのログインではなくそのキーを使い、-pでの実行では常にキーが使われます。以前のプロジェクトのキーがシェルの設定に残っていると、思っていたのと違う経路で動きます。どちらで課金されるかはClaude CodeのAPIキーとサブスク課金: どちらを使うべきかで整理しています。

500ではなく、何度もログインを求められる場合は、システムの時刻が正しいか確認します。トークンの検証は時刻に依存するためです。macOSでclaude doctorがmacOS Keychain is not writableと報告するなら、次のコマンドでキーチェーンのロックを解除してから、/logoutと/loginでログインし直します。

security unlock-keychain ~/Library/Keychains/login.keychain-db

時刻とキーチェーンは、OAuthの500の原因と分かっているものではありません。稼働状況の確認とログインのやり直しを済ませた後に見る項目です。Login expired、Not logged in、OAuth token revoked、「Unable to authenticate」など500以外のログイン表示は、Claude「Unable to authenticate」対処で扱っています。

429・一時的なリクエスト制限・利用枠のリセットは別に判断する

Server is temporarily limiting requests (not your usage limit)は、利用枠とは無関係な一時的なリクエスト制限です。v2.1.199以降は認証方法によらず、自動再試行してから表示します。少し待っても続くなら稼働状況を確認します。一時的なリクエスト制限の公式説明

You've hit your session limitやweekly limitなら、/usageと表示されたリセット時刻を基準にします。セッションと週の利用枠はモデル共通なので、モデルを変えても解除されません。OpusまたはSonnetのモデル系列別の上限なら、その系列以外の利用可能なモデルへ切り替える選択があります。

claude.aiのサブスクリプションで使う対話版CLIには、v2.1.234以降、開いたセッションでリセットを待ち、続行する機能があります。Desktopのセッション上限カードのAuto-continue when limits resetと、CLIの/configにある自動続行設定は別です。Desktopの週上限カードにはそのチェックボックスがありません。外部操作が残っているなら、自動で続ける設定も含め、再開前に状態を確かめてください。利用枠とリセット待機

Request rejected (429)では、/statusで有効な認証情報を確認します。承認されたANTHROPIC_API_KEYが環境にあると、サブスクリプションではなくそのキーの経路を使うことがあります。キー本体を公開せず、該当サービスの管理画面で制限を確認します。429と認証経路

直接Anthropic APIを使う場合、429には通常のレート制限のほか、利用ティアの月間支出上限やClaude Code workspaceの支出上限も含まれます。ティアの支出上限に達した429はretry-afterがなく、利用を再開できる状態になるまで失敗し続けます。一時的なリクエスト制限として無期限に送信しても解消しません。APIの429の条件

復帰後も使用量が大きい理由を調べたい場合は、Claude Codeのコンテキスト・キャッシュ・MCP使用量の確認へ進めます。使用量の調査と、中断した処理を重複なく続ける確認は分けて行います。

/rewindを使うのは、戻す編集が決まっているとき

500や529が出たというだけで、コードを巻き戻す必要はありません。正しい変更が残っているなら、その結果を使って続けます。/rewindのコード復元は、特定の編集を戻したい場合の選択肢です。会話の再開や、外部処理の取消しとは目的が異なります。

現在の公式案内では、リンクや通常ファイル以外のパス、ディレクトリが変わったパス、安全に読めないバックアップは復元時に除外されることがあります。Restored the code, but skipped N filesなら、除外されたファイルは現在の内容のままです。No files were restoredなら、何も復元されていません。保存期間を過ぎてバックアップが失われる場合もあります。コード復元の警告と失敗

復元メッセージと実際の差分を確認してください。そのメッセージを、Bashで起動した処理、CI、デプロイ、DB更新まで取り消した証拠として使うことはできません。それぞれの状態を確認して対応します。

同じ失敗が続くときに残す情報

待機と安全な再試行、必要な状態確認をしても同じエラーが続くなら、追加送信を止め、調査に使える情報を残します。

• エラー全文、発生時刻とタイムゾーン、Claude Codeのバージョン。
• 作業中、ログイン中、特定の会話の再開後のどれで出たか。新しいセッションでも出るか。
• エラー末尾のサービスと、その稼働状況。
• /statusで確認した接続先・認証方法、利用モデル。
• 自動再試行と手動再試行の結果、会話を再開できたか。
• 完了済み・実行中・結果不明の操作と、取得できたリクエストID。

API由来の500が障害情報なしで続く場合、公式案内は/feedbackによる報告を勧めています。秘密鍵や顧客データを除き、問題が起きた操作と確認結果を渡してください。500の報告方法

本文の手順は2026年10月5日時点の公式資料に基づきます。障害を再現して試した結果ではありません。

よくある質問

529が出たら、利用枠が回復するまで待つのですか？

529は、公式のClaude Code案内では一時的な容量不足です。利用枠のリセットとは別で、数分待つか、作業に使える別モデルへ切り替えます。session limitやweekly limitと表示されている場合は、そのリセット時刻を確認してください。529と利用枠の違い

不完全な応答が出ても、ファイルは変更されていますか？

変更済みの可能性があります。Claude Codeは完成したツール呼び出しを実行し、その結果から続けるため、通知だけで未実行とは判断できません。残ったツール結果とファイル差分を確認し、完了した編集は繰り返さないようにします。不完全な応答の仕様

セッションを再開できなければ、全部やり直しますか？

まず表示されたIDで再開を試し、IDや保存期間、別プロセスの占有を確認します。それでも新規セッションが必要なら、現在のファイルと外部操作の結果を渡し、残りだけを依頼します。会話の読込み失敗は、ファイルやデプロイ結果の消失を意味しません。再開に失敗した場合

ステータスが正常なら、すぐ同じ依頼を送ってもよいですか？

正常表示だけでは、個別のリクエストの成功や、途中の処理が未実行だったことまでは分かりません。自動再試行が終わっていることと、完了済み・実行中の操作を確認します。外部処理の結果が不明なら、その処理を照会してから再送を判断してください。

Claude Codeのログイン中に500が出たら、再インストールが必要ですか？

通常は必要ありません。公式のログインのやり直し手順は、/logout、Claude Codeの終了、claudeでの再起動と再サインインで、再インストールは含まれていません。先に稼働状況を確認し、WSL2やSSHの接続先ではログインコードの貼り付けかclaude auth loginを使います。ログインと認証の公式案内

Claude Codeで500が出たら、自動で「続けて」と送らせてもよいですか？

ファイル編集や外部操作を伴う作業では避けてください。Claude Codeはエラーを表示する前に再試行を済ませ、ツール呼び出しが完成した後の中断では元のリクエストを送り直しません。自動の続行は、完了した処理を確かめる段階を飛ばします。残った結果と外部の状態を確認してから、残りだけを指示してください。