Claudeの内部サーバーエラー対処法:混雑と応答中断も切り分ける
Claudeのサーバーエラーは、表示された場所によって対処が変わります。まず入力と途中の作業を残し、稼働状況と実際の接続先を確認してください。Claude Codeで処理が進んでいた場合は、元の依頼を送り直す前に実行結果を調べます。
目次

Claudeで「Internal server error」や「サーバーが混雑しています」と表示されたら、まず未送信の入力と残っている回答を保存し、Claude Statusで利用中の機能の稼働状況を確認してください。 障害が公開されている場合は、その案内に従って待ちます。何も掲載されていない場合は、Webの会話、Claude Code、API、連携アプリのどこで失敗したかを確認します。
すぐに送り直してよいかは、途中まで何が完了したかで変わります。特にClaude Codeや外部ツールを使うアプリでは、回答が途切れてもファイルの変更や外部処理は済んでいるかもしれません。自動再試行が終わったことと、同じ処理を繰り返しても問題がないことを確認してから、手動で再試行します。
エラーが出た場所から、最初の操作を選ぶ
同じ「内部サーバーエラー」という言葉でも、Web画面の一般的な表示と、APIが返した500 api_errorは区別します。画面だけでは、AnthropicのAPIが500を返したかどうかまで分からない場合があります。
| エラーが出た場所 | 最初に確認するもの | 次の操作 |
|---|---|---|
| Claude.aiの会話 | 障害情報、画面のエラー全文、途中の回答 | 入力を保存して少し待ち、再試行。特定の会話だけ失敗するなら新規チャットで比較 |
| Claude.aiへのログイン | 障害情報、VPN、拡張機能、ブラウザの状態 | ログインの問題として1項目ずつ確認。保存前にCookieを消さない |
| Claude Code | エラー末尾の接続先、自動再試行、完了した回答やツール操作 | 約1分待つ。処理済みなら実行結果を確認して続行、未処理で安全なら再試行 |
| 直接Anthropic API | HTTPステータス、error.type、リクエストID、SDKの再試行 | 正確なエラー型で分岐し、回数と時間を決めた再試行を行う |
| クラウドや第三者の連携アプリ | そのサービスの稼働状況、選択したモデル、接続先 | 運営者にエラー時刻と表示内容を伝える。中継サービスの500をAnthropic由来と断定しない |
手動での確認は、まず安全な再試行を1回行い、同じエラーなら追加送信を止める、という進め方を勧めます。これは原因を切り分けるための目安です。Anthropicが全製品に定めた「再試行は1回まで」という制限ではありません。 本番のAPI連携では、処理の重要度、重複防止、SDKの設定に合わせて別途上限を決めます。
Claude.aiで混雑やサーバーエラーが出たとき
ステータスが正常でも、混雑は起こります
「Due to unexpected capacity constraints…」と表示された場合、公式ヘルプは一時的な容量不足として、数分後の再試行を案内しています。この容量制約はサービス障害とは別で、ステータスページには掲載されません。 緑の表示を見て、すぐにブラウザやアカウントが壊れたと判断する必要はありません。Claudeのエラーメッセージに関する公式案内
通常の会話で失敗したら、次の順で確認します。
- 入力欄の文章、必要な回答、エラー表示を保存します。
- Claude StatusでClaude.aiの障害情報を確認し、混雑の表示なら数分待ちます。
- 自動処理が続いていないことを確認して、同じ会話で再試行します。
- 同じ会話だけ失敗する場合は、元の会話を残したまま、新規チャットで必要最小限の内容を試します。外部処理を伴う依頼は、その実行状況を先に確認します。
新規チャットで成功すれば、会話ごとの差が手掛かりになります。ただし、それだけで古い会話の破損を証明したことにはなりません。短時間の混雑が解消した可能性もあるため、変更した項目と試した時刻を残してください。
利用上限・会話の長さ・ログイン失敗は別に扱います
再開時刻付きの利用上限表示が出ているなら、その時刻や契約の利用条件を確認します。単なる混雑として何度も送信しても、上限の解除にはなりません。
「このチャットの長さの制限を超える」といった表示なら、添付ファイルや入力を小さくする、必要な情報をまとめて新規チャットに移す、といった対応が必要です。これらは公式ヘルプでサーバー障害とは別に説明されているエラーです。
ログイン時に一般的なエラーが出る場合、公式ヘルプはVPN、ブラウザ拡張機能、キャッシュとCookieの確認を挙げています。作業を保存してから、1項目ずつ変更してください。APIやClaude Codeの実行中に出た500への対策として、最初からブラウザのデータを消す必要はありません。
Claude Codeや連携アプリでは、実際の接続先を確認する

Claudeというモデル名が表示されていても、リクエストの提供元はAnthropic直結とは限りません。Claude Codeの現在のエラー案内では、500のメッセージ末尾に、利用中のプロバイダーに応じた稼働状況の確認先が表示されます。
- Anthropic APIならClaude Status。
- Amazon Bedrock、Google CloudのAgent Platform、Microsoft Foundryなら、それぞれのサービスの状態。
ANTHROPIC_BASE_URLを指定した独自接続先なら、そのゲートウェイのホスト。
まず末尾の案内と、アプリ側の設定や管理者の説明を照合します。クラウド経由なら、対象のリージョンやプロジェクトも確認してください。Anthropicのステータスが正常でも、別サービスの接続先まで正常だと分かるわけではありません。
プロキシやゲートウェイがHTMLのエラーページを返す場合もあります。Claude Code v2.1.281以降は、たとえばAPI Error: 502 Bad Gatewayのように、ステータスとページのタイトルを表示します。HTMLのエラーが出たという理由だけで、Anthropic内部の500と同一視しないでください。公式の500とプロキシエラーの説明
Claude Codeは再試行済みか、応答のどこで止まったかを確認する
Claude Codeは、一時的な失敗を指数バックオフで最大10回再試行してからエラーを表示します。「最初の送信を含めて必ず10回」という意味ではなく、すべての失敗が同じ上限に従うわけでもありません。エラーが表示された時点で、その失敗に適用される自動再試行はすでに行われています。自動再試行の公式説明
思考だけが完了した場合は、再試行されることがあります
思考が完了していても、回答テキストやツール呼び出しがまだ始まっていない場合、現在のClaude Codeはその時点のサーバーエラーや過負荷に対して最大2回再試行します。この動作はv2.1.284以降です。それ以前は、その時点でエラーとして終了していました。適用条件とバージョン
したがって、「少しでも途中の表示があるなら、自動再試行は一切しない」とは言えません。思考だけが完了したのか、テキストやツール処理まで進んだのかが重要です。接続切断や応答の停滞にはそれぞれ別の再試行条件もあるため、画面のエラー全文を残してください。
テキストやツール呼び出しが進んでいたら、元の依頼を丸ごと再送しない

テキストまたはツール呼び出しのブロックが完了した後、あるいは思考を終えてそれらを開始した後で応答が途切れた場合、Claude Codeは元のリクエストを再実行しません。完了したブロックを保持し、完成したツール呼び出しを実行して、その結果から処理を続けます。 同じツールを二重に実行しないための動作です。終了時に中断された最後のブロックは破棄されるため、画面の末尾にあった文やツール呼び出しが欠けることがあります。途中の応答に関する公式説明
The response above may be incompleteと表示されたら、次を確認します。
- 画面に残っている回答とエラー全文を読みます。
- ファイルの変更、実行したコマンド、ジョブや外部サービスの結果を確認します。エラーが出ても、実行済みの変更が自動で取り消されたとは考えないでください。
- 接続が安定したら、対話セッションでは
continueと返信して、最後に完了したブロックから続きを求めます。実行済みの作業と、残っている作業を具体的に添えると、再開の判断がしやすくなります。
たとえば「ファイルの更新は完了している。未実行のテストから続けて」と伝える前に、実際のファイルとテストログを確認します。確認せずに「最初からもう一度」と指示すると、通知やデプロイなどを重複して行うおそれがあります。
非対話モードでは、メインの回答にテキストだけがありツール呼び出しがない場合、v2.1.246以降は途中の出力を残して最大3回続きを要求する動作があります。これは続きを生成する処理であり、元の依頼を丸ごと最大3回やり直す意味ではありません。実行モードとバージョンで表示や継続方法が変わります。非対話モードの条件
処理前の500や、繰り返す529が出た場合
部分的な作業がなく、安全に再送できる500なら、公式案内は約1分待ってからメッセージを再送するよう勧めています。元のメッセージは会話に残るので、長い内容を貼り直す代わりにtry againと送る方法もあります。公開障害がないのに続く場合は、/feedback、または利用環境で提供されるエラー報告の方法に進みます。Claude Codeの500への対処
Repeated 529 Overloaded errorsは、適用される再試行後も容量不足が続いた表示です。数分待ち、メッセージに記載されたサービスの状態を確認します。使える別モデルがある場合は/modelで切り替える方法もありますが、すべての契約や接続先で代替モデルが使えるわけではありません。モデル変更で作業を続けられても、元のモデルが復旧した証拠にはなりません。繰り返す529の公式案内
APIの500・529・429・504は、エラー型で分ける
APIを開発・運用している場合は、画面の言葉よりHTTPレスポンスとerror.typeを優先します。以下は直接Anthropic APIの公式分類です。中継サービス独自のコードには、そのサービスの説明を使ってください。APIエラー一覧
| HTTPステータスと型 | 意味 | 対処の起点 |
|---|---|---|
500 api_error | Anthropic内部で予期しないエラーが発生 | リクエストIDを保存し、安全な処理を指数バックオフ付きで再試行 |
529 overloaded_error | APIが一時的に過負荷 | 少し待ち、並列数を下げる。再試行を集中させない |
429 rate_limit_error | レート制限、利用階層の月間支出上限、またはClaude Codeワークスペースの支出上限 | エラー本文と制限情報を確認し、待機で解消する制限か判断 |
504 timeout_error | リクエストの処理がタイムアウト | 長時間の処理ならストリーミングを検討。再送前に処理状況を確認 |
429をすべて「少し待てば直る」と扱わないことが重要です。利用階層の月間支出上限による429にはretry-afterヘッダーがなく、アクセスが再開するまで失敗し続けます。逆に500だけを見てAPIキーを交換したり、利用プランを上げたりする根拠はありません。認証・支払い・権限には、それぞれ別のエラー分類があります。429の支出上限とエラー分類
また、ストリーミングではHTTP 200の後にエラーイベントが届くことがあります。200だけを見て「回答が完了した」と判断せず、ストリームの終了状態まで確認してください。HTTPレスポンス自体が得られていない場合は、接続、プロキシ、DNS、TLS、クライアント側のタイムアウトを調べる必要があり、500とは断定できません。ストリーミング時のエラー
SDKとアプリの再試行を重ねない
公式SDKは接続エラー、レート制限、5xxなどの一時的な失敗を、既定で2回再試行します。指数バックオフを使い、retry-afterがあれば従います。max_retriesで設定でき、Claude Codeの最大10回とは別の仕組みです。公式SDKの再試行仕様
アプリ、SDK、ゲートウェイ、ジョブキューがそれぞれ再試行すると、利用者が1回送っただけでも複数のリクエストが発生します。ログで各段階の回数を確認し、総送信回数と経過時間に上限を設けてください。経路によって動作が異なるため、画面だけから一律の総回数を計算することはできません。
500が続くAPI連携の再試行上限や重複防止は、Claude APIの内部サーバーエラーを運用で扱う方法で詳しく説明しています。529への並列数・キューの調整は、Claude APIの過負荷対策を参照してください。
再発する場合は、追跡できる情報を問い合わせ先へ渡す
同じエラーが続く場合、設定をまとめて変える前に次の情報を保存します。Webしか使っていない読者は、表示内容と時刻からで十分です。見えていないHTTPコードやリクエストIDを推測して書く必要はありません。
- 発生日時とタイムゾーン。運用ログと照合する場合はUTCも記録。
- Claude.ai、Claude Code、直接API、連携アプリのどこで起きたか。
- エラー全文と、取得できたHTTPステータス・エラー型。
- 利用中のモデル、接続先、Claude CodeやSDKのバージョン。
- 自動・手動の再試行履歴と、残っている回答や実行済みの作業。
- APIのリクエストID、または連携サービスの問い合わせ用ID。
- 稼働状況を確認した時刻と、そのときの表示。
直接Anthropic APIでは、エラーJSONのrequest_idとヘッダーのrequest-idは同じ識別子を示します。取得できる方を残し、両方取得できるなら対応も確認します。Python・TypeScript SDKでは、トップレベルのレスポンスの_request_idでも参照できます。リクエストIDの公式説明
ゲートウェイを使っている場合は、アプリが受け取ったエラーと、その運営者が持つ上流側のエラーを対応付ける必要があります。上流のサービス、ステータス、リクエストID、再試行回数を、取得できる範囲で問い合わせに添えます。運営者が上流へ送る前に失敗していれば、AnthropicのリクエストIDがないこともあります。
問い合わせ先は、直接APIならAnthropic、クラウド経由ならそのプロバイダーや管理者、連携アプリなら運営者です。Claude Codeでは公式のエラー報告方法も使えます。APIキー、環境変数一式、顧客情報、非公開の入力全文は添付せず、追跡用IDと機密情報を取り除いた再現条件を共有してください。
よくある質問
Claudeは今、障害が起きていますか?
現在の状態はClaude Statusで、利用中の機能を確認してください。過去の「正常」の記録では今の状態は分かりません。また、公式ヘルプでいう一時的な容量制約は、ステータスページに掲載されません。
「サーバーが混雑しています」は利用上限に達したという意味ですか?
混雑の表示だけでは、個人の利用上限に達したとは判断できません。Webの容量制約と、再開時刻を示す利用上限は公式ヘルプでも別に扱われています。APIの場合も、529 overloaded_errorと429 rate_limit_errorを区別してください。
エラーが出たら、何回再試行すればよいですか?
まず自動再試行が終わったか、処理済みの作業がないかを確認します。手動の切り分けでは、安全な再試行を1回行って再発したら止める方法を勧めます。これは本記事の進め方で、全製品共通の公式上限ではありません。公式SDKは既定で2回、Claude Codeは対象の一時的な失敗を最大10回再試行しますが、途中の応答には別の条件があります。
Claude Codeで途中の回答が残っていたら、やり直せますか?
元の依頼を送り直す前に、残っている回答とツールの実行結果を確認してください。テキストやツール処理が進んだ後の中断では、Claude Codeは完了したブロックを保持します。対話セッションでは、接続が安定した後にcontinueで続きを求めます。ただし、思考だけが完了してテキスト・ツールが未開始の場合は、現在の版では再試行されることがあります。部分応答と再試行の条件
キャッシュやCookieを消せば直りますか?
ログイン時の一般的なエラーでは、公式ヘルプの確認項目に含まれます。ただし、Webの混雑、APIの500、別プロバイダーの障害を解消する共通の方法ではありません。未送信の作業を保存し、ログインの問題だと切り分けてから試してください。





