Claude Code「Connection lost mid-response」の意味と対処｜The response above may be incomplete

API Error: Connection lost mid-response. The response above may be incomplete.

このメッセージは、Claude が文章のまとまりやツール呼び出しを1つ以上書き終えた後、応答の途中で接続が切れたという意味です。Claude Code はリクエストを送り直さず、完成した部分を残し、書き終えたツール呼び出しを実行して、その結果からターンを続けます。欠けるのは、途中で切れた最後の部分だけです。画面に残った応答を確かめてから continue と送れば、Claude は最後に完成したところから続きを書きます。 毎回出る場合は、プロキシ・VPN・パソコンのスリープなど、手元のネットワーク側を疑います。

同じ形で、切れた理由だけが違う次の5つの表示もあります。対処の基本は同じです。

API Error: Server error 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.
API Error: Part of the response never arrived. The response above may be incomplete.
API Error: The response stream was malformed. The response above may be incomplete.

本記事の情報について：2026年10月8日時点の公式ドキュメント（Error reference の「The response above may be incomplete」「Automatic retries」「Network and connection errors」、Network configuration の「Streaming idle watchdogs」）、CHANGELOG（最新は v2.1.293）、GitHub の利用者報告と、手元の Claude Code v2.1.287 に含まれる文言にもとづいています。公式の記載と利用者の報告は書き分けています。エラーを意図的に起こして再現したものではありません。

状況別の読み分け早見表

意味：応答の途中で接続が切れ、完成した部分だけが残った状態

「The response above may be incomplete」は、ストリーミングで届いていた応答が途中で途切れ、Claude Code が完成済みの部分だけを残したことを知らせる表示です。 公式の Error reference によると、この表示が出るのは、Claude が文章のまとまりかツール呼び出しを書き終えた後（または、考える段階を終えて書き始めた後）で、応答の最後まで届く前にリクエストが失敗したときです。

Claude Code の応答は、一度に全部ではなく、少しずつ流れてきます（ストリーミング）。その流れが途中で止まったとき、普通に考えれば「もう一度最初から送り直す」のが簡単です。しかし Claude Code はそうしません。送り直すと、すでに書き終えていたツール呼び出し（ファイルの編集やコマンドの実行）がもう一度実行されてしまうおそれがあるためです。公式ドキュメントは、この理由から Claude Code は完成した出力を残し、書き終えたツール呼び出しを実行して、その結果からターンを続けると説明しています。

つまりこのメッセージは、「失敗したので全部捨てた」ではなく、「途中までは成功していて、その成果は残してある。ただし最後の部分が欠けているかもしれない」という意味です。慌てて同じ指示を最初から送り直す必要はありません。

6つの表示と、それぞれの原因

公式ドキュメントは、どこで切れたかではなくなぜ切れたかで表示を分けています。

表のうち、Server error mid-response だけは Anthropic 側（または Amazon Bedrock などのクラウド事業者側）の原因です。残りの5つは、手元のパソコンから API までの通り道で起きた問題であることが多く、毎回出るなら自分の環境を調べる価値があります。

昔の表記

公式ドキュメントによると、v2.1.227 より前は Connection lost mid-response が Connection closed mid-response、The response stopped arriving が Response stalled mid-stream という表記でした。古いバージョンを使っている人や、古い記事で見かけた表記は、この2つと同じ状態です。

切れた場所で Claude Code の動きが変わる

同じ「接続が切れた」でも、応答のどこまで届いていたかによって、Claude Code は自動でやり直すか、この表示を出すかを変えます。 公式の Automatic retries に書かれた規則を、応答の進み具合に沿って並べると次の図のとおりです。

図の3つの区間を、公式の説明に沿って補足します。

• 何も書き終えていない時点で切れた：Claude Code は、一時的な失敗を最大10回まで、待ち時間を少しずつ延ばしながら（指数バックオフ）自動で送り直します。この区間で接続が切れても、送り直しが成功すればユーザーは気づきません。ただし、Claude が考える段階だけを終えて、まだ文章もツール呼び出しも始めていない時点で切れ続けた場合は、すばやく2回まで送り直し、それでも切れると Connection lost before a response was produced で終わります
• 何かを書き終えた後、最後まで届く前に切れた：本記事の表示です。送り直すと同じツール呼び出しを二重に実行しかねないので、送り直しません
• 最後まで受け取った後に切れた：やり直すものがないので、完全な応答としてそのまま終わります。公式ドキュメントによると、v2.1.222 より前はこの場合にもこの表示が出て、完成していた応答がエラー扱いになっていました

なお、応答のデータが20秒届かないと、画面には Waiting for API response · will retry in … · check your network という表示が出ます。公式ドキュメントによると、これはまだ失敗ではなく、止まった接続を打ち切るまでの残り時間を数えている状態です。データが再び届くか、やり直しが成功すれば自然に消えます。この表示が毎回出るなら、ネットワークの問題として扱うよう案内されています。

対処法

公式ドキュメントの案内を、上から順に試します。

1. 画面に残った応答を確認する

まず、直前の応答のどこまでが残っているかを読みます。 公式ドキュメントによると、Claude Code は表示の前に完成していたまとまりはすべて残しますが、途中で途切れた最後のまとまりはターンの終わりに捨てます。そのため、応答の最後の数文や、最後に予定していたツール呼び出しが抜けていることがあります。

特に確かめたいのは次の点です。

• ファイルの編集が途中で止まっていないか（git diff で実際の変更を見る）
• 最後に実行するはずだったテストやコマンドが実行されたか
• 「次に〇〇します」と書いたところで終わっていないか

2. continue と送って続きを書かせる

対話モードでは、continue と送れば、Claude は最後に完成したまとまりから続きを始めます（公式ドキュメントの案内）。元の指示は会話の中に残っているので、長い指示を貼り直す必要はありません。続きを書かせる前に、手順1で確かめた「抜けている部分」を一言添えると、やり直しの範囲がはっきりします。

3. claude -p や Agent SDK で出たとき

非対話の実行（claude -p、Agent SDK、クラウドのセッション）では、扱いが少し違います。公式ドキュメントの説明は次のとおりです。

• ツール呼び出しを含まない文章だけの応答が切れた場合、Claude Code は自分で Claude に続きを促し、連続3回まで続きを書かせます。それでも切れたときに初めてこの表示を返します（v2.1.246 以降。それより前は最初の1回で表示していた）
• テキスト出力（既定）では、そのターンで最後に完成していた文章のまとまりに続けてこの表示を出力します。持っている文章がないときは、この表示だけを出力します
• --output-format json や stream-json では、この表示を result 欄で返します
• 続きを実行するには、接続が安定してから同じセッションを再開し、continue を送ります（Continue conversations）

スクリプトで claude -p を回している場合は、終了時の result にこの文言が含まれていないかを確認し、含まれていればセッションを再開して continue を送る処理を入れておくと、夜間の自動実行が途中で止まったまま朝を迎える事態を減らせます。

サブエージェントも同じで、文章だけの応答が途中で切れた場合は Claude Code がサブエージェントに続きを促します。続きの回数を使い切ったときに限って、この表示がサブエージェントの最後のメッセージになります（v2.1.257 以降）。

4. 毎回出るなら、ネットワークを確認する

一度だけなら一時的な切断です。ターンのたびに出る、特定の場所（会社・自宅の VPN 接続中など）でだけ出るなら、公式ドキュメントのとおりネットワークの問題として扱います。確認の順番は次のとおりです。

1. 同じターミナルで curl -I https://api.anthropic.com を実行し、API に届くかを確かめる（Windows の PowerShell では curl.exe -I https://api.anthropic.com）
2. 社内プロキシを使う必要があるなら、Claude Code を起動する前に HTTPS_PROXY を設定する（Network configuration）
3. echo $ANTHROPIC_BASE_URL で、昔試したローカルのプロキシやゲートウェイのアドレスが残っていないかを確かめる。設定ファイルの env にも残っていないかを見る
4. macOS では、切断・削除した VPN の名残（ifconfig に出る utun で始まる古いインターフェース）がないかを確かめる
5. Docker Desktop などのコンテナ実行環境が通信を横取りしていないか、いったん終了して切り分ける

curl が通るのに Claude Code だけ切れる場合は、ネットワークそのものより、その間にある設定（上の3〜5）が原因であることが多い、というのが公式ドキュメントの見立てです。証明書のエラー（SSL certificate verification failed）が先に出ているなら、SSL certificate verification failed の対処法を先に片付けてください。

表示ごとの確認ポイント

Server error mid-response：Anthropic 側の一時的な障害

サーバーエラーは手元の設定では直りません。障害情報を確かめて、少し待ってから continue と送ります。 公式ドキュメントは、5xx はプロンプトや設定、アカウントが原因ではないとしたうえで、status.claude.com（Bedrock・Google Cloud・Microsoft Foundry ではそれぞれの事業者の稼働状況）を確認するよう案内しています。障害の告知がないのに続くなら、/feedback で報告します。

なおこの表示は v2.1.199 以降のものです。それより前は、応答の途中でサーバーエラーが起きると、途中まで届いた出力を捨ててターン全体をエラーにしていました。

Your computer went to sleep mid-response：スリープを防ぐ

ノートパソコンのふたを閉じた、または離席中にスリープした場合の表示です。 長い作業を任せて席を外すときは、作業が終わるまでスリープしない設定にします。CHANGELOG によると、v2.1.290 で、Bedrock・Google Cloud（Vertex）・Microsoft Foundry・独自ゲートウェイの経路で、スリープによる中断を「データが止まった」と誤って扱っていた問題が直っています。この経路で The response stopped arriving がスリープ明けに出ていた人は、claude update で更新すると表示が正しく分かれます。

The response stopped arriving：データを溜める中継機器を疑う

接続は生きているのにデータが一定時間届かなかったため、Claude Code が自分で打ち切った表示です。 Network configuration の「Streaming idle watchdogs」によると、Claude Code は応答が静かになった接続を見張るタイマーを4つ持っています。そのうち、通信に1バイトも流れてこない状態を見張るタイマー（バイト単位のウォッチドッグ）は、Anthropic の API に直接つないでいる場合で180秒です。ANTHROPIC_BASE_URL で独自のゲートウェイを通す場合も、Claude Code が機能の設定（フィーチャーフラグ）を取得できていれば180秒、取得できていなければ300秒です。Google Cloud（Vertex）や Microsoft Foundry ではこのタイマーは動かず、代わりに5分間データが届かないと打ち切る別のタイマー（body idle timeout）が働きます。Amazon Bedrock では、CLAUDE_ENABLE_BYTE_WATCHDOG_BEDROCK=1 を設定したときだけバイト単位の見張りが動きます。

よくある原因は、応答を最後まで溜めてから一度に返すプロキシやゲートウェイです。社内の中継機器が原因で、作業を止めずに待ち時間を延ばしたい場合は、次の環境変数で調整できます（いずれも公式ドキュメントの記載）。

待ち時間を延ばすと、本当に死んだ接続に気づくのも遅くなります。まず中継機器の設定（応答をそのまま流す設定にできないか）をネットワーク担当者に相談し、延長は最後の手段にしてください。CHANGELOG と公式ドキュメントによると、v2.1.222 より前は、ANTHROPIC_BASE_URL 経由のゲートウェイで、サーバーからの生存確認の信号（keep-alive）が届いているのにこの表示が出ることがありました。古いバージョンなら、まず更新します。

Part of the response never arrived / The response stream was malformed：中継機器が応答を落とす・壊す

応答の一部が欠けた、または壊れた形で届いたことを示す表示です。 公式ドキュメントによると、v2.1.281 より前は欠けた場合に API Error: Content block not found で、v2.1.284 より前は壊れたデータの場合に API Error: JSON Parse error で始まるメッセージで、ターン全体が止まっていました。現在は完成部分を残すようになっています。

どちらも、応答を書き換えたり分割したりする中継機器（ゲートウェイ、セキュリティ製品、プロキシ）が原因になりやすい表示です。LLM ゲートウェイを経由しているなら、ゲートウェイを通さずに直接つないで同じ指示を試し、再現するかで切り分けます。

Connection lost mid-response：通り道のどこかで切れた

最も一般的な表示で、原因は Wi-Fi の切り替わり、VPN の再接続、プロキシが接続を閉じたことなど、通り道のどこかの切断です。 公式ドキュメントは、プロキシやゲートウェイが応答の途中で通信を「正常に」終わらせた場合もこの表示になると明記しています。Windows の社内プロキシが通信路を途中で落とすケースは、以前は Socket is closed というエラーで止まっていました（v2.1.214 で、やり直しや完成部分の保持の対象になりました）。

バージョンによる違い

この表示まわりは、最近のバージョンで細かい修正が続いています。公式ドキュメントと CHANGELOG の記載を、関係するものだけ並べました。

古いバージョンで繰り返し出るなら、まず claude update で最新にします。2026年10月8日時点の最新は v2.1.293 です。なお、更新の配信チャンネルを stable（約1週間遅れで、大きな不具合のある版を飛ばす）にしている場合、同じ日の stable は v2.1.285 です（npm の配布情報）。表のうち v2.1.288 と v2.1.290 の修正は、stable の人にはまだ届いていません。急ぐ場合は latest チャンネルに切り替えます（Set up Claude Code の「Configure release channel」）。Homebrew で入れた場合は、cask の claude-code が stable、claude-code@latest が latest を追うので、急ぐなら claude-code@latest に入れ替えます（同じページ）。

社内のネットワーク担当者に伝えること

会社のネットワークで毎回出る場合、手元でできることには限りがあります。 次の内容をそのまま情報システム部門やネットワーク担当者に伝えると、話が早く進みます。いずれも公式ドキュメント（Network configuration、Error reference）に書かれている条件です。

• 通信先の許可：Claude Code は api.anthropic.com（API）、claude.ai（claude.ai アカウントの認証）、platform.claude.com（Console アカウントの認証と、claude.ai アカウントのログイン情報の更新）などに接続する。ファイアウォールとプロキシでこれらを許可してほしい
• 応答をそのまま流す：応答は少しずつ流れてくる（ストリーミング）。プロキシやゲートウェイで応答の本文やヘッダーを溜めたり書き換えたりせず、そのまま通してほしい。公式ドキュメントは、途中の機器が応答を書き換えることを、応答の欠けや中身の無い応答の典型的な原因に挙げている
• 静かな時間で切らない：Claude Code は、Anthropic の API に直接つなぐ場合、180秒間1バイトも届かないと接続を打ち切る。サーバーは途中で生存確認の信号（keep-alive）を送るので、それを遮らないでほしい。逆に、機器側の無通信タイムアウトがこれより短いと、応答の途中で切られる
• 社内プロキシ経由で使う場合の設定：利用者側は Claude Code を起動する前に HTTPS_PROXY を設定する。証明書を差し替える検査型のプロキシなら、社内の証明書を NODE_EXTRA_CA_CERTS で渡す必要がある

上の条件を満たせない事情がある場合は、利用者側で待ち時間を延ばす（前述の CLAUDE_STREAM_IDLE_TIMEOUT_MS など）ことで影響を小さくできます。ただし根本の解決にはならないので、まず機器の設定から相談するのが順番です。

長い作業を途中で止めないためのチェックリスト

長いリファクタリングや夜間の自動実行を Claude Code に任せる前に、次の項目を確かめておくと、途中で切れても被害が小さくて済みます。

• claude update で最新版にした（途中の切断の扱いは、ここ数か月で何度も改善されている）
• 作業を任せる前に Git でコミットし、どこまで変わったかを git diff で確かめられるようにした
• ノートパソコンのスリープを、作業が終わるまで止める設定にした
• 不安定な Wi-Fi・つなぎ直しの多い VPN を避け、安定した回線で実行する
• claude -p のスクリプトでは、結果にこの表示が含まれていないかを確かめ、含まれていればセッションを再開して continue を送る処理を入れた
• 社内プロキシやゲートウェイを通すなら、上の「伝えること」を担当者と確認した
• 遅いプロキシを通す環境では、API_TIMEOUT_MS などの待ち時間を見直した

公式には未確認の報告

GitHub には、表示と実際の原因が食い違っていたという利用者の報告があります。公式ドキュメントで確認できた内容ではないため、参考情報として扱ってください。

• Windows の Claude Desktop（Code タブ）と claude -p で、Claude が文章を書いた後に最初のツール呼び出しを始める瞬間にだけ、ターンが断続的にこの表示で失敗したという報告（anthropics/claude-code #87324、v2.1.229、Anthropic の API に直接接続）。報告者はログ上はサーバー側の server_error だったとして、通信環境の確認を促す案内が実態に合わないと指摘しています。この報告は重複として閉じられており、原因についての公式の回答は本文にありません

この報告のように、手元のネットワークに問題がなくても出ることはあります。自分の環境を一通り確かめても直らず、ほかの場所（別の回線）でも同じように出るなら、/feedback で報告し、リクエストの情報を Anthropic に渡すのが近道です。

似ているが別のエラー

見分けるポイントは、画面に Claude の応答が途中まで残っているかどうかです。残っていれば本記事の表示で、continue で続けられます。何も残っていなければ、まだ応答が始まっていない段階のエラーなので、同じ指示をもう一度送ります。そのほかのエラーは Claude Code エラー一覧と対処法 から逆引きできます。長い作業の途中で別の種類の止まり方（VS Code のタブが反応しなくなる）をした場合は、stopped responding の対処法も参照してください。

よくある質問

まとめ

• 「Connection lost mid-response. The response above may be incomplete.」は、Claude が何かを書き終えた後、応答の途中で接続が切れた状態。完成した部分とツールの実行結果は残っている
• 送り直さないのは、ツール呼び出しの二重実行を防ぐため。まだ何も書き終えていない段階の切断は自動でやり直される
• 対処は、残った応答（特に最後の部分とファイルの変更）を確かめてから continue と送る
• 表示は6種類。Server error は Anthropic 側、それ以外は通り道（Wi-Fi・VPN・プロキシ・ゲートウェイ・スリープ）が原因であることが多い
• 毎回出るなら curl -I、HTTPS_PROXY、ANTHROPIC_BASE_URL の残り、スリープ設定を確認し、claude update で最新版にする

参考：

• https://code.claude.com/docs/en/errors
• https://code.claude.com/docs/en/network-config
• https://code.claude.com/docs/en/headless
• https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md