目次
Claude Codeで作業していると、応答の途中で突然こう出て止まることがある。
API Error: Connection closed mid-response. The response above may be incomplete.
長いレポートを書かせている最中、複数ファイルを読ませている最中、あるいは新しいセッションを始めた直後——タイミングはまちまちで、再現条件もはっきりしない。これはプロンプトの書き方の問題ではなく、応答のストリーム（逐次送信）を運んでいた接続が、途中で閉じられたという通信層の事象だ。
そして重要な事実がひとつある。このエラーの報告の多くは、Claude Codeが接続断の扱いを改善する前のバージョンで起きている。公式CHANGELOGを追うと、2.1.179以降だけで接続・リトライまわりの修正が5つ入っている。本記事では、公式のエラーリファレンスと公式CHANGELOG、そしてパケットキャプチャ付きの実Issueに基づいて、①このメッセージの正確な意味 ②いま画面の前でやるべきこと ③切断が起きている層 ④バージョンによる差 ⑤開発者側の防ぎ方を整理する。
すでに流れてきた分は失われていない。continue と返せば続きから再開できる、と公式が案内している。
2.1.198で「一時的なネットワーク断で会話が落ちる」問題が、2.1.214で「切れた接続を使い回す」問題が修正されている。
端末・経路（プロキシ/VPN）・サーバ側のどこで切れているかで対処が変わる。サーバ起点の切断の報告もある。
1. このエラーは何を言っているのか——公式の定義
まず、このメッセージはClaude Codeが独自に出している注記であって、APIが返したエラーレスポンスそのものではない。Claude Code公式のエラーリファレンスは、「The response above may be incomplete.（上の応答は不完全かもしれません）」で終わる一群のメッセージについてこう説明している——すでに目に見える出力が出たあとでストリーミングが失敗した場合、リクエストを送り直すと同じツール呼び出しを二重に実行してしまう恐れがあるため、Claude Codeは流れてきた分をそのまま残し、代わりにこの注記を付ける、と。
そのうえで、末尾のバリエーションが原因の名前になっている。同リファレンスが挙げる3種類は次のとおりだ。
公式の説明は一行——「接続が切断された」。ストリームは動いていたが、それを運ぶ接続そのものが閉じた。
公式の説明は「ストリームがデータを送るのをやめた」。接続は生きているのに無音になる。切断ではなく停止。
ストリームの途中でoverloadedや5xxが発生。公式によればこの表示自体がv2.1.199以降で、それ以前は途中出力を捨てて全体をエラー扱いにしていた。
3つの違いを一言で。 切断されたのが Connection closed、無音になったのが Response stalled、サーバが転んだのが Server error。同じ「途中で止まった」に見えても、通信のどこで何が起きたかが違う。
なお、Claude Code側の挙動としてもうひとつ公式が明記している重要な点がある。目に見える出力が一切出る前に同じ失敗が起きた場合は、Claude Codeはこの注記で終わらせずにリクエストを再試行する。つまり、あなたがこのメッセージを見ているということは、「途中まで出た」＝再送すると副作用が二重に走りうる状態だから、あえて自動リトライしていないということだ。エラーが出た＝何も試していない、ではない。
2. まず最初にやること——出力は消えていない
パニックになって同じ指示を投げ直す前に、次の順で確認してほしい。
公式の案内どおり、失われたものは無い。欠けているのは最後の数文か、最後のツール呼び出しだけの可能性が高い。
continue と返す公式エラーリファレンスが明示している復帰手順。止まったところから続けさせる。最初からやり直させない。
ファイル編集やコマンド実行の途中で切れた場合、途中まで実行済みかもしれない。git status などで実際の状態を見てから続ける。
1セッションで何度も出るなら、対処より先にバージョンの確認へ。後述のとおり、この領域は継続的に修正が入っている。
STEP 3を軽視しないでほしい。公式が「送り直すと同じツール呼び出しを二重に実行しうる」と書いているのは裏を返せば、切れた時点で一部のツールはすでに実行されている可能性があるということだ。ファイルを書く・コミットする・デプロイするといった副作用のある作業の途中で切れたなら、まず実際の状態を見るのが最短の復旧路になる。
3. なぜ切れるのか——切断が起きる3つの層
「接続が切断された」とだけ言われても対処できないので、切断が起こりうる場所を分けて考える。報告されているケースは大きく3層に分かれる。
Wi-Fiの瞬断、モバイル回線の切り替わり、PCのスリープ復帰。公式CHANGELOGにも「マシンがスリープから復帰したあとストリーミングが失敗する」修正（2.1.186）があり、この層は実在する。
効く対処：有線／安定回線、長い作業中はスリープさせない。
Claude API公式のエラードキュメントは「ネットワークによっては、アイドル状態の接続を一定時間後に切断することがある」と明記し、対策としてTCPキープアライブの設定を挙げている。社内プロキシやVPNはこの挙動を持ちやすい。
効く対処：プロキシ／VPNを一時的に外して再現するか確認。
ストリーム配信中にサーバ側から接続が閉じられている、というパケットレベルの報告がある（次章）。この場合、手元をどう整えても防げない。
効く対処：クライアント側のリトライ設計。＝バージョン更新が効く理由。
実際、GitHub Issue #69415（[BUG] API Error: Connection closed mid-response ==> frequent enough to make Claude Code unusable for any task、2026年6月18日起票・記事執筆時点でオープン）の報告者は、Windows 11／WSL2、企業ファイアウォールもプロキシも無い直結環境、Claude Code 2.1.181という条件を挙げている。つまり層①②を潰した環境でも起きている、というのがこの報告の主張だ。同Issueには area:networking／platform:vscode／platform:wsl のラベルが付いている。
同報告者は「同じマシン・同じ回線で、他のAIアシスタント（GitHub Copilot、Cursorなど）では同じ作業が完走する」とも書いている。ただしこれは報告者による比較であって、Anthropicによる原因認定ではない点は区別しておきたい。
もうひとつ、条件がはっきり違う報告もある。Issue #69336（occurs immediately in new context window、2026年6月18日起票・オープン、Claude Code 2.1.173、Debian 13、Claude Agent SDKの自前ホスト）は、コンテキストの要約（compact）が走ったあとに頻度が上がると報告している。こちらは area:agent-sdk／area:api／platform:linux ラベルで、新しい会話を始めると一時的に回避できるとされている。Issue #69517（Claude Cowork上で発生、2026年6月19日、macOS、2.1.183）は重複としてクローズされている。
4. パケットキャプチャが示した「サーバ起点の切断」
この種のエラーで最も踏み込んだ一次調査が、Issue #67766（2026年6月12日起票・オープン）だ。報告者は自分の環境でパケットキャプチャを取り、10件の発生を突き合わせている。
出典：GitHub Issue #67766 の報告者が公開したパケットキャプチャとセッション記録。Anthropicによる検証結果ではなく、1ユーザーの環境での実測である。
技術的に効いてくるのは「選択的だった」という点だ。報告によれば、同じ宛先に張られていた他のコネクションはその瞬間も生きたままで、切断されたのはリクエストを実行中のプロセスが持っていた接続だけだった。同時に走っていた別の claude プロセスの接続は無傷だったという。回線が落ちたのならすべて道連れになるはずで、そうなっていない。
また、10件のうち4件では複数の接続にまとめてFINが飛ぶ「まとめ切り」が観測され、3件は近い分のちょうど54秒地点（01:19:54／01:20:54／01:22:54 UTC）で発生していた——60秒周期の何かが走っている可能性を示す、と報告者は指摘している。
🟡 この章の確度について
Issue #67766 の画面表示は「API Error: The socket connection was closed unexpectedly」であり、本記事のメッセージとは文言が異なる。同じ不具合であるとは断定できない。ただし「ストリーム配信中に接続が閉じる」という同じ層の現象について、現時点で公開されている唯一のパケットレベルの証拠であるため、原因の見立てとして参照する価値がある。また、この報告に対するAnthropicからの原因説明は記事執筆時点で公開されていない。
5. あなたのClaude Codeは古くないか——修正の時系列
ここが本記事でいちばん実利のある部分だ。Claude Code公式CHANGELOGを追うと、ストリーム中の接続断の扱いは継続的に改善されてきている。以下はCHANGELOGに実際に記載されている項目である。
ストリーム中の接続断で、途中までの応答が保持されるようになった。それ以前は生のエラーが出るだけで、スピナーが「running tool」で固まる不具合もあった。
ストリーム停滞時の表示が「Waiting for API response · will retry in …」に変更され、発火が無音10秒から20秒へ。短い揺らぎで警告が出にくくなった。
応答の途中で短いネットワーク断が起きるとターンごと中断されていた問題を修正。ECONNRESETのような一時的エラーは、失敗させずにバックオフ付きでリトライするようになった。
ストリーム中にoverloaded／サーバエラーが出たとき、途中出力を捨てていた問題を修正。途中までを残して「不完全」注記を付ける方式に。前述の Server error mid-response 表示はここから。
キープアライブの接続プールが、古い接続によるエラーの後は無効化されるように変更。リトライが新しいソケットを張り直すようになった——#67766が指摘した「使い回している接続が閉じられる」構図に直接効く変更である。
この時系列を、冒頭に挙げた報告のバージョンと重ねてみてほしい。
| 報告 | 報告時のバージョン | その時点で未適用だった修正 |
|---|---|---|
| #69336 | 2.1.173 | 2.1.179／198／199／214 のすべて |
| #69415 | 2.1.181 | 2.1.198／199／214（＝リトライ改善と接続プール修正） |
| #69517 | 2.1.183 | 2.1.198／199／214 |
3件とも、一時的な接続断をリトライで吸収する2.1.198より前のバージョンである。だからまず確認すべきは自分のバージョンだ。
claude --versionこれが 2.1.198 より小さいなら、切り分けよりも先に更新したほうが早い。CHANGELOGの最新版は記事執筆時点で 2.1.220 で、上の修正はすべて含まれている。
ただし「更新すれば必ず消える」とは言えない。CHANGELOGに「Connection closed」という文字列そのものの修正項目は無く、上記はいずれも隣接する接続処理の改善である。更新は最も費用対効果の高い最初の一手だが、根治の保証ではない——という位置づけで読んでほしい。
6. 起きやすい条件
報告に共通して現れる、確率を上げる要因は次のとおり。
複数の大きなファイルを読んで構造化レポートを書かせる——など、ストリームが長時間開きっぱなしになるタスク（#69415）。
コンテキスト要約が走ったあとに頻度が上がるという報告（#69336）。要約後は送信するリクエストが大きくなりやすい。
#67766の実測では、切断された接続が運んでいたリクエスト本体は1〜2.5 MB。なおMessages APIのリクエスト上限は公式に32 MB。
社内プロキシ・VPN・越境接続。公式ドキュメントが「アイドル接続を切るネットワークがある」と明記している層。
公式CHANGELOG 2.1.186に「スリープ復帰後にストリーミングが失敗する」修正がある。長い作業中にPCを寝かせない。
#67766では171件中87件が直前のAPI通信から5秒未満で発生。アイドル切断だけでは説明できないパターンも含まれる。
7. 今すぐ直す——ユーザー向けチェックリスト
上から順に、コストの低いものから試すのが効率的だ。
| 順 | やること | ねらい |
|---|---|---|
| 1 | continue と返す | 公式が案内する復帰手順。途中まで出た内容を活かして続きから再開する。 |
| 2 | claude --version を確認し、古ければ更新 | 2.1.198のリトライ改善・2.1.214の接続プール修正を効かせる。最優先。 |
| 3 | 副作用の確認（git status など） | 切断時点でツールが途中まで実行されていないかを見る。二重実行の事故を防ぐ。 |
| 4 | タスクを分割する | 1回の応答を短くしてストリームの露出時間を減らす。「全ファイルを読んでレポート」を段階に割る。 |
| 5 | プロキシ／VPNを一時的に外して再現確認 | 層②の切り分け。外して消えるなら経路側の問題と確定できる。 |
| 6 | スリープ・省電力を無効化、有線接続にする | 層①の切り分け。特にノートPCで長時間タスクを回す場合。 |
| 7 | 新しいセッションで試す | #69336で報告されている一時的な回避策。要約直後に頻発する場合に効くことがある。 |
| 8 | 再現するならIssueに情報を添えて報告 | 公式APIドキュメントの案内どおり request_id（req_ で始まる識別子）を添えると調査が早い。 |
やってはいけないこと。「接続が切れる」からといってTLSの検証を無効化する（NODE_TLS_REJECT_UNAUTHORIZED=0 など）のは、症状が別物である上に通信の安全性を捨てる行為で、まったく推奨できない。証明書エラーは別のエラーであり、対処も別だ。
8. 開発者向け——API/SDKで防ぐ
Claude Agent SDKや自作のAPI統合で同種の切断に悩んでいる場合、Claude API公式のエラードキュメントが具体的な設計指針を示している。
公式は「10分を超えるような長いリクエストにはストリーミングかMessage Batches APIを使う」よう警告している。大きな max_tokens を非ストリーミングで投げるのは最も切断されやすい形だ。
公式は、直接API統合を書く場合はTCPキープアライブを設定すればアイドル切断の影響を減らせる、と明記している。公式SDKはこれを既定で設定済み。自前でHTTPクライアントを書いているなら要確認。
公式SDKは接続エラー・レート制限・5xxを既定で2回まで指数バックオフ付きで再試行し、retry-after ヘッダを尊重する。回数はクライアントのオプションで変更・無効化できる。
公式が明記する落とし穴。SSEでは200が返ったあとにエラーが起こりうるため、通常のHTTPエラー処理には乗らない。ストリーム中のエラーイベントを個別にハンドリングする必要がある。
Claude Code自身が2.1.179／2.1.199でこの方向に舵を切った。切断時に受信済みブロックを保持して続きを要求するほうが、全部捨てて再送するよりコストも副作用も小さい。
Claude Codeは2.1.214で「古い接続によるエラーの後はキープアライブのプールを無効化し、リトライは新しいソケットを張る」よう変更した。再試行が同じ死んだ接続を掴んでいないかを確認する価値がある。
バッチ処理のように「途切れない接続を前提にしたくない」ワークロードなら、公式が推奨するとおりMessage Batches APIに寄せてポーリングで結果を取りにいく設計のほうが、ネットワークのリスクを構造的に消せる。
9. 似たエラーとの見分け方
Claude Codeの通信まわりのエラーは表示が似ていて紛らわしい。「どこまで進んだか」で見分けるのが早い。
| メッセージ | どこで止まったか | 主な対処 |
|---|---|---|
| Connection closed mid-response（本記事） | 接続して応答も流れ始めた後に切断 | continue／バージョン更新／経路の切り分け |
| Response stalled mid-stream | 接続は生きているが無音になった | 別記事で詳説（反復ループとの連鎖に注意） |
| Server error mid-response | ストリーム中にサーバ側が5xx／overloaded | 時間をおいて再試行。529/500の記事を参照 |
| Unable to connect / SSL certificate verification failed | そもそも接続できていない | プロキシ・社内CA・ファイアウォール。接続エラーの記事へ |
| Prompt is too long | 送信前に拒否されている（通信は正常） | 文脈を削る。専用記事へ |
いちばん大きな分岐は「画面に応答が出たかどうか」だ。1文字も出ていないなら接続そのもの（設定・経路）を疑う。途中まで出ているなら、それは接続できていた証拠なので、設定をいじるのではなく本記事の切り分けに進むほうが正しい。
10. 公式の対応状況と、確定していないこと
誤解を避けるため、何が公式に確認できて何がそうでないかを分けて示す。
- このメッセージは公式エラーリファレンスに正式に記載があり、意味は「接続が切断された」
- 途中まで流れた出力は保持される（意図的な仕様）
- 復帰手順は
continueと返すこと - 出力が出る前の失敗は自動で再試行される
- 接続断まわりの修正が 2.1.179／198／199／214 に入っている
- サーバ起点でストリーム中にFINが送られている（#67766の実測。ただし表示メッセージは別文言）
- 60秒周期の掃除処理が関与している可能性（同報告者の推測）
- 要約（compact）直後に頻発する（#69336の報告）
- 他のAIアシスタントでは同条件で起きない（#69415報告者の比較）
- Anthropicによる原因の公式説明（#69415／#69336／#67766のいずれにも公開回答なし）
- 「Connection closed」を名指しした修正項目（CHANGELOGに該当文字列なし）
- #69415・#69336・#67766はいずれもオープンのまま
要するに、症状と対処法は公式に文書化されているが、なぜ切れるのかの公式説明はまだ出ていない。この状況では、「原因を特定する」より「切れても損失を最小にする」——短いターンに分ける、副作用のある操作は状態を確認しながら進める、バージョンを新しく保つ——という運用のほうが確実に効く。
FAQ
Q1. 「Connection closed mid-response」が出たら、それまでの出力は消えますか？
消えません。公式エラーリファレンスが明示しているとおり、すでに流れてきた内容はそのまま残されます。Claude Codeがあえて再送せずにこの注記を付けているのは、送り直すと同じツール呼び出しを二重に実行してしまう恐れがあるためです。欠けているのは最後の数文か、最後のツール呼び出しだけの可能性が高いです。
Q2. 何と返せば続きから再開できますか？
continue と返してください。公式エラーリファレンスが案内している復帰手順です。最初から指示をやり直すと、すでに実行済みの操作が重複するおそれがあります。
Q3. トークンは無駄になりますか？
途中まで生成された分は消費されています。Issue #69336の報告者も「消費したトークンは返ってこない」と書いています。だからこそ、切れても続きから再開できるよう continue を使い、最初からやり直させないことがコスト面でも重要です。
Q4. 「Response stalled mid-stream」と同じものですか？
違います。公式の定義では、Connection closed は「接続が切断された」、Response stalled は「ストリームがデータを送るのをやめた」——切断と停止で別の事象です。症状の見え方は似ていますが、stalled 側はモデルの反復ループと連鎖して起きるケースが報告されており、対処も異なります。詳しくはResponse stalled mid-streamの記事を参照してください。
Q5. 自分のネットワークが悪いのでしょうか？
その可能性はありますが、それだけとは限りません。Issue #69415の報告者はプロキシもファイアウォールも無い直結環境で発生したと報告しており、Issue #67766のパケットキャプチャでは切断がサーバ側から開始されていたとされています。まずプロキシ／VPNを外して再現するか確認し、変わらなければ手元だけの問題ではないと判断できます。
Q6. Claude Codeを更新すれば直りますか？
最初に試す価値が最も高い一手です。公式CHANGELOGでは2.1.198で「応答途中の短いネットワーク断がターンを中断していた問題」が修正され、2.1.214で「古い接続によるエラーの後はキープアライブのプールを無効化し、リトライで新しいソケットを張る」よう変更されています。報告が集中している2.1.173〜2.1.183はいずれもこれより前です。ただしCHANGELOGに「Connection closed」を名指しした修正項目はないため、更新は改善の可能性であって根治の保証ではありません。
Q7. 長いタスクで頻発します。回避策はありますか？
タスクを分割して1回の応答を短くするのが最も確実です。「複数の大きなファイルを読んでレポートを書く」ような一括処理は、読み込みと執筆を分けるだけでストリームが開いている時間が短くなり、切断に当たる確率が下がります。Issue #69336では、新しい会話を始めると一時的に回避できたという報告もあります。
Q8. 開発者として自分のアプリで防ぐには？
Claude API公式ドキュメントの指針が明快です。①長い応答は必ずストリーミング（10分を超えるならBatches APIも検討）、②TCPキープアライブを設定する（公式SDKは設定済み）、③SSEでは200のあとにもエラーが起こりうるのでストリーム中のエラーイベントを個別に処理する、④切断時は受信済みの内容を捨てずに続きを要求する——の4点が要です。サポートに問い合わせる際は request_id を添えてください。
Q9. Claude Cowork や Agent SDK でも同じエラーが出ます。
同じメッセージが報告されています。Issue #69517はClaude Cowork上での報告（重複としてクローズ）、#69336は自前ホストのClaude Agent SDK経由での報告です。ストリーミング応答を扱う層に共通する事象なので、対処の考え方（続きから再開する・バージョンを新しく保つ・リトライを設計する）は変わりません。
