API Error: The response stopped arrivingの意味と対処——Claude Codeで応答のデータが途中で止まったとき

「API Error: The response stopped arriving」は、応答が流れている途中で、接続は開いたままなのにデータが届かなくなり、Claude Code自身の監視タイマーがその接続を打ち切ったことを知らせる表示です。それまでに完了した出力は画面に残っています。対話セッションならcontinueと返せば、最後に完了したところから続けられます。

API Error: The response stopped arriving. The response above may be incomplete.

この表示は、v2.1.227より前はResponse stalled mid-streamという文言でした。公式のエラーリファレンスが改名を明記しており、起きていることは同じです。古い文言で書かれた情報や不具合報告を探すときは、両方の文言で検索してください。

1. この表示の意味——切断ではなく「無音」

Claude Code公式のエラーリファレンスは、この表示を「接続は開いたままだったが、データを届けなくなったため、ストリーミングのアイドル監視（idle watchdog）が打ち切った」と説明しています。APIが返したエラーの本文ではなく、応答を受け取っていたClaude Codeが自分で付けている注記です。

同じ「途中で止まった」でも、Claude Codeは原因ごとに言い回しを変えています。公式が並べているのは次の4つで、末尾の「The response above may be incomplete.（上の応答は不完全かもしれません）」が共通です。

API Error: Server error mid-response. The response above may be incomplete.
API Error: Connection lost mid-response. The response above may be incomplete.
API Error: Your computer went to sleep mid-response. The response above may be incomplete.
API Error: The response stopped arriving. The response above may be incomplete.

1行目は応答の途中でサーバーが過負荷や5xxのエラーを返した場合、2行目は接続が切れた場合、3行目は応答の途中でPCがスリープした場合です。4行目のこの表示だけが、エラーも切断も起きていないのに、データが来なくなったことを表しています。

打ち切るのは4つの監視タイマー

公式のネットワーク設定ドキュメントによると、Claude Codeは静かになったストリームを打ち切るタイマーを4つ持っています。死んだ接続がいつまでも固まったままにならず、失敗として扱えるようにするためです。応答が流れ始めてから効くのは、下の表の上から3つです。

Anthropic APIに直接つないでいる場合、目安はバイト単位の監視の180秒です。つまりこの表示が出るまでの間、画面は数分止まって見えます。公式によると、リクエストが生きたまま20秒データが来ないと、先に次のバナーが出ます。これは「まだ失敗していない」という表示で、カウントダウンは打ち切りの時点までを指しています（v2.1.185より前は10秒で、文言も違いました）。

Waiting for API response · will retry in … · check your network

データが戻ればバナーは自然に消えます。消えずに打ち切りまで進み、しかも出力の一部がすでに完了していたときに、この記事の表示が出ます。

2. v2.1.227で「Response stalled mid-stream」から改名された

公式エラーリファレンスは、4つの表示の説明のすぐ後に「v2.1.227より前は、Connection lost mid-responseはConnection closed mid-response、The response stopped arrivingはResponse stalled mid-streamと表示されていた」と書いています。同じ版で、出力が始まる前の表示も付け替えられました。

旧文言のResponse stalled mid-streamが、モデルが同じ語を延々と繰り返す現象と一緒に出た例は、Response stalled mid-streamと「court」の無限ループを扱った記事にまとめています。接続が切れた側の表示は、旧文言の時代の報告をConnection closed mid-responseの記事に、改名後の文言をConnection lost mid-responseの記事に分けて解説しています。

3. 似た表示との違い

どの表示になるかは、応答がどこまで進んだところで止まったかで決まります。公式の「Automatic retries」の説明を、応答の進み方に沿って並べると次のようになります。

③で送り直さない理由も、公式に書かれています。文章やツール呼び出しを1つ完了した後にリクエストを送り直すと、同じツール呼び出しを二重に実行するおそれがあるからです。だからClaude Codeは完了した分を残し、ターンを捨てる代わりに注記を付けます。

Connection lost mid-responseとの違いは「切断か、無音か」

どちらも途中まで出力が出た後の表示で、残る出力とcontinueでの再開は共通です。違うのは止まり方です。lostは接続が失われたという判定で、手元の回線の瞬断やVPNの張り直し、途中の機器による切断を疑います。stopped arrivingは、接続は残っているのに中身が流れてこないという判定で、監視タイマーの時間まで待ってから打ち切られています。そのため、6章で扱うタイマーの調整が効く余地があるのは、stopped arrivingの側だけです。

Streaming response ended…との違いは「止まったか、空で終わったか」

公式によるとStreaming response ended before any complete data was receivedは、応答が使えるデータを1つも届けないまま終わったときの警告です。Claude Codeはストリーミングをやめて同じリクエストを送り直し、ターンを続けます。警告は対話セッションで1セッションに1回だけ出ます（v2.1.239より前は黙って送り直していました）。よくある原因は、途中のプロキシやゲートウェイが応答の本文を消費・変換してしまうことだと公式は書いています。stopped arrivingは応答が途中まで来てから止まったもので、自動では送り直されません。

4. 途中までの作業はどうなるか

公式の説明では、Claude Codeは完了したブロックをすべて残し、ターンの終わりに途中だった最後のブロックを捨てます。画面の最後の数文や、最後のツール呼び出しが欠けていることがあるのはこのためです。完了していたツール呼び出しは実行され、その結果からターンが続きます。実行の環境ごとに、止まった後の扱いが違います。

-pで止まったときの出力と、続け方

非対話モードの既定のテキスト出力では、Claude Codeはそのターンで最後に完了した文章のブロックを出力し、その後にこの表示を続けます（v2.1.219より前は表示だけで、応答は捨てられていました）。--output-format jsonやstream-jsonでは、この表示はresultフィールドに入ります。接続が落ち着いてから、セッションを再開してcontinueを送るのが公式の手順です。

# 直前の会話を続ける
claude -p "continue" --continue

# セッションIDを指定して続ける
claude -p "continue" --resume "$session_id"

なお、フックでの自動再開については、Issue #87972の報告者が「旧文言の時代はStopフックが動いて自動で続けられたが、改名と同じころから動かなくなった」と書いています。これは報告者の観測で、以前の挙動が意図したものだったかは公式には書かれていません。いまの公式ドキュメントどおりなら、フックで記録や通知はできても、ターンを再開させることはできません。

5. 原因——公式に書かれていることと、報告されていること

この表示は「データが来なくなった」という結果を伝えるだけで、なぜ止まったかは表示からは分かりません。確度を分けて整理します。

公式はこの表示を、エラーリファレンスの「Server errors」の節に置いています。節の冒頭には「大半はAnthropicのサービスなど推論プロバイダー側から来る」とありますが、この文言について公式が説明しているのは上の仕組みまでです。手元の回線・途中の機器・サーバーのどこで止まったかを、公式は特定していません。

#88900と#90005は、手元の回線に異常が見当たらないのに止まったと書いています。ただし、それだけでサーバー側が原因だと決めることはできません。#90005の報告者も書いているとおり、短い通信の試験は「数分間開いたままの接続が途中で黙る」状況を再現しないからです。

6. 止まったときの対処手順

上から順に、手間が小さく効き目の大きいものから並べています。1回だけなら手順2で終わりです。

~/.claude/settings.jsonに書く例です（バイト単位の監視を10分にする）。

{
  "env": {
    "CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS": "600000"
  }
}

7. 直ったかを確かめる

1回出なかっただけで完了とせず、同じ規模の作業を流したときに次の4点を見ます。

# 版を確かめる
claude --version

# デバッグログを取りながら起動する
claude --debug

# この文言を含む会話ログのファイルを数える（macOS・Linux）
grep -rl "The response stopped arriving" ~/.claude/projects/ | wc -l

# 同じく、この文言を含む行を数える（PowerShell）
Get-ChildItem "$HOME\.claude\projects" -Recurse -Filter *.jsonl | Select-String -SimpleMatch "The response stopped arriving" | Measure-Object

回数は目安として使ってください。#90005の報告者は、ある85分間に画面で15回止まったのに、会話ログに残った記録は1件だけだったと書いています。会話ログが0回でも、画面で止まった回数を自分でも控えておくと確実です。

8. 報告するときに残す情報

公式エラーリファレンスは、解決しないときの窓口として次の4つを挙げています。

• Claude Codeの中で/feedbackを実行する。会話の記録と説明がAnthropicに送られ、内容を埋めたGitHubのIssueを開くこともできる。BedrockやVertexなどのプロバイダーでは、送る代わりに手元に保存される
• シェルでclaude doctorを実行し、インストールの読み取り専用の診断を見る
• status.claude.comで障害を確かめる
• GitHubの既存のIssueを探す。新旧どちらの文言でも検索する

9. 確定していること／していないこと

10. まとめ

「API Error: The response stopped arriving」は、応答が途中まで流れた後、接続は開いたままデータが止まり、Claude Codeの監視タイマーが打ち切ったことを示す表示です。v2.1.227より前のResponse stalled mid-streamと同じもので、完了した出力は残っています。まず作業の状態を確かめてからcontinueと返してください。

何度も出るなら、版の更新、VPN・プロキシ・ゲートウェイの切り分け、1回の応答を短くする工夫、の順に試します。経路が長く黙る環境に限って、バイト単位の監視の時間を伸ばす手があります。接続そのものが切れるConnection lost mid-responseとは疑う場所が違うので、表示の文言を最初に見比べてください。ほかのエラーはClaude Codeのよくあるエラーと解決法まとめにまとめています。

FAQ

Q. 「API Error: The response stopped arriving」はどういう意味ですか？
A. 応答が流れている途中で、接続は開いたままデータが届かなくなり、Claude Codeの監視タイマーがその接続を打ち切ったという意味です。文章やツール呼び出しを1つ完了した後に止まった場合の表示で、それまでの出力は残っています。

Q. 「Response stalled mid-stream」とは別のエラーですか？
A. 同じものです。公式エラーリファレンスが、v2.1.227より前はこの表示がResponse stalled mid-streamだったと明記しています。表示が変わっただけで、新しい種類の障害が起きたわけではありません。

Q. 何と返せば続きから再開できますか？
A. continueと返してください。最後に完了したブロックから続きます。ファイル操作やコマンドの途中で止まった場合は、先にgit statusなどで実際の状態を確かめてから返すと安全です。

Q. 再試行の回数を増やせば出なくなりますか？
A. 出なくなりません。この場面は、同じツール呼び出しを二重に実行しないよう、Claude Codeが最初から送り直さない設計です。CLAUDE_CODE_MAX_RETRIESが効くのは、出力が始まる前の失敗です。

Q. 「Connection lost mid-response」とは何が違いますか？
A. lostは接続そのものが切れたという判定で、stopped arrivingは接続が残ったままデータが来なくなったという判定です。どちらも完了した出力は残り、continueで再開できますが、監視の時間の調整が効く余地があるのはstopped arrivingの側だけです。

参考にした一次情報

• Claude Code — Error reference（公式ドキュメント）：The response above may be incompleteの4つの表示とv2.1.227の改名、v2.1.222より前の誤報、Automatic retries、待機のバナー、No response from API、Streaming response ended before any complete data was received、Report an error
• Claude Code — Enterprise network configuration（公式ドキュメント）：4つの監視タイマーと既定の時間、設定用の環境変数、デバッグログ、バックグラウンドのエージェントへの設定の渡し方
• Claude Code — Environment variables（公式ドキュメント）：CLAUDE_STREAM_IDLE_TIMEOUT_MS・CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS・API_FORCE_IDLE_TIMEOUTの説明
• Claude Code — Hooks reference（公式ドキュメント）：APIエラーで終わったターンのStopFailure
• Claude Code — Run Claude Code programmatically（公式ドキュメント）：--continue・--resumeでの再開
• anthropics/claude-code — CHANGELOG（公式）：v2.1.222、v2.1.227、v2.1.229、v2.1.232、v2.1.246、v2.1.257の各項
• GitHub Issue：#88900、#90005、#89027、#87246、#87972（いずれも利用者の報告。2026年9月22日に確認）