「Waiting for API response」の意味と対処 — Claude Codeの応答待ちと接続断

Waiting for API response · will retry in … · check your network — Claude Codeを使っていると、こう出たまま画面が止まって見える瞬間があります。結論から言うと、この表示はエラーではありません。応答ストリームで20秒間データが届かないときに出る「保留中」のヒントで、リトライはまだ始まっていません。

この表示はCLI・Desktopアプリ・Web版のいずれでも同じ形で出ます。3つとも同じClaude Code本体をラップしているためです。表示の意味を取り違えると、実は正常に待っているだけの場面でセッションを止めてしまったり、逆に本当のネットワーク障害を「そのうち直る」と放置してしまったりします。

「Waiting for API response」は何のサインか

この文言はv2.1.185(2026年6月20日)で導入されました。それ以前はNo response from API · Retrying in …という文言が、無応答10秒後に表示されていました。v2.1.185からは無応答20秒後に表示が切り替わり、文言も「応答がない」ではなく「応答を待っている」という表現に変わっています。この旧文言がv2.1.181とv2.1.183で頻発した経緯は「No Response From API」が繰り返し出る原因と対処にまとめています。

「応答がない」は障害を疑わせますが、実態はリクエストがまだ生きていて応答を待っているだけのことがほとんどです。カウントダウンは、Claude Codeが止まった接続を諦めてリトライに切り替えるまでの残り時間を示しています。

20秒はいつから数え始めるか — アドバイザー利用時は90秒

しきい値の20秒は、リクエストが保留中のままレスポンスストリームにデータが一切届かない時間で数えます。データが少しでも流れてくれば、その時点でカウントはリセットされます。

例外が1つあります。アドバイザー(advisor)ツール(セカンドモデルに助言を求める機能)を使っている間は、しきい値が20秒ではなく90秒に延びます。アドバイザーへの相談は、応答が長時間ノーデータのまま進むことがあるためです。この例外はv2.1.214(2026年7月18日)で入りました。それより前のバージョンではアドバイザー相談中も20秒のしきい値がそのまま適用されており、実際には何も問題が起きていないのにアドバイザー相談中だけ表示が出るという誤検知がありました。アドバイザーを有効にして使っている場合、20秒経っても表示が出ないのは正常な挙動です。

表示のあと、何が起きるか

この表示が出たあとの流れは一本道ではありません。3つの分かれ方があります。

ここで注意したいのは、Waiting for API response · will retry in …と、その後に出ることがあるRetrying in Ns · attempt x/yは別物だという点です。前者はまだ実際のリトライが始まっていない「保留中」の表示で、後者は実際にリトライ試行が動いている番号付きのカウントダウンです。表示が切り替わったからといって、それだけで状況が悪化したとは限りません。ストリームの停止を検知してリトライフェーズに移った、というだけのこともあります。

テキストだけが完了した状態でThe response stopped arrivingのままターンが終わった場合、対話セッションなら画面に残っている応答はそのまま読めます。Claude Codeは完了したブロックを保持し、未完了だった最後のブロックだけを破棄する挙動です。続きが欲しければ、continueと送ればそこから再開します。

「Connection lost mid-response」は保留表示とどう違うか

API Error: Connection lost mid-response. The response above may be incomplete.というエラーは、応答が完了する前に接続そのものが切断されたときに出ます。Claudeがテキストやツール呼び出しのブロックを完成させたあと、または思考を終えてブロックを書き始めた段階で接続が切れた場合が対象です。思考を終えたあと、テキストやツール呼び出しを始める前に切れた場合はConnection lost before a response was producedという別のエラーになり、この区間だけは最大2回まで即座に再送されます。思考の途中で切れたときは通常のバックオフ付きリトライが働き、ターンはそのまま続きます。ここまでのWaiting for API responseは保留中の表示でした。こちらはすでに確定したエラーです。接続断はデータの滞留とは別の事象なので、20秒の保留表示を経由せずに出ることもあります。

同じThe response above may be incomplete.で終わる確定エラーは、原因違いで6種類あります。

Server error mid-responseはv2.1.199で追加された区分です。6つとも、完成済みのブロックを破棄しない点は共通です。なおv2.1.226以前は、Connection lost mid-responseがConnection closed mid-response、The response stopped arrivingがResponse stalled mid-streamという文言でした。古いバージョンでこれらの文言を見た場合も、原因と対処は同じです。

エラー後の流れも共通です。完了したツール呼び出しがあればClaude Codeはそれを実行し、その結果からターンを続けます。テキストだけの場合は前述のcontinueで再開します。

非対話モード(-p)では挙動が少し変わります。デフォルトのテキスト出力は最後に完成したテキストブロックをそのまま表示したうえで、このメッセージを追加します。--output-format jsonまたはstream-jsonを使っている場合は、resultフィールドにこのメッセージが報告されます。なお、-p・Agent SDK・Claude Code on the webのような非対話のセッションでは、テキストだけで途切れても、continueを自分で送る必要がありません。Claude Codeが最大3回まで続きを促します(v2.1.246以降)。

エラー別に見る、出たあとの動き

確定エラーは文言で次の動きが分かれます。どれも完成済みのブロックは残るので、まず画面の応答を読み返します。

Server error mid-responseは、過負荷や5xxが原因のため、時間を置いてcontinueを送る方法があります。

Your computer went to sleep mid-responseでは、復帰後にClaude Codeがその接続を壊れたものとして扱い、読み取りを止めます。続きが必要ならcontinueで再開します。

Connection lost mid-responseは、プロキシやゲートウェイが応答の本文を途中で閉じたときにも出ます。同じ症状が続くなら、次の節の切り分けに進みます。

Part of the response never arrivedとThe response stream was malformedの対処も、他の文言と同じでcontinueで続きを送ります。

毎回のターンで出るなら、疑う順番

たまに一瞬出るだけなら気にする必要はありません。問題は、ほぼ毎回のターンで出て、しかも最終的にエラーで終わるケースで、この場合はネットワーク側の問題として切り分けます。

curl -I https://api.anthropic.com

Windows PowerShellでは、組み込みのInvoke-WebRequestエイリアスに引っかからないようcurl.exe -I https://api.anthropic.comと明示します。curlとだけ打つと別のコマンドを実行してしまい、誤診断につながります。

企業のLLMゲートウェイやリレーを経由している場合は、疎通確認の相手先も変わります。ANTHROPIC_BASE_URLを設定して自前のゲートウェイ経由でAnthropicへつないでいる構成では、通信は直接api.anthropic.comへは向かいません。curlで叩く先もapi.anthropic.comではなく、設定したANTHROPIC_BASE_URLのホストに変えて確認します。ゲートウェイ側の応答が遅い、あるいは途中で詰まっているだけのことも多く、その場合は運用担当への確認が近道です。

curlが通るのにClaude Codeだけ失敗するときは、上の右側を疑います。WSLはホストの壊れたリゾルバーをそのまま引き継ぐことがあり、macOSの古いutunはifconfigで確認できます。Docker Desktopは一度終了して切り分けます。

回線が正常なのに繰り返し出るとき

curlが通り、/etc/resolv.confやVPNにも問題がないのに、何分も止まる報告がGitHubに複数あります。「check your network」と出ていても、回線が原因とは限りません。

3つとも、どれもユーザーの報告で、原因が確定したわけではありません。3件ともオープンのままで、公式の見解も示されていません。

#88178には、デスクトップアプリ固有の指摘があります。アプリがCLIを起動するときにAPI_TIMEOUT_MS=900000を環境に入れており、プロセスの環境変数はsettings.jsonのenvより優先されるため、API_TIMEOUT_MSをsettings.jsonで短くしても効かなかった、という報告者の実測です。デスクトップアプリで3〜15分の停止に当たる場合、settings.jsonで待ち時間を縮めたつもりでも変わっていない可能性があります。

回線を疑って時間を使う前に、次の順で確かめる手があります。

1. 停止中にcurl -wで所要時間を測り、数十ミリ秒で返るかを見る(回線は無実であることが分かる)
2. 数分止まったらEscで中断し、同じ内容を送り直す。再送がすぐ通るなら、止まっていたのは接続のほうです
3. --debug-fileでログを残し、止まった時刻の前後に何が出ているかを見る(次節)
4. デスクトップアプリなら、環境変数側でAPI_TIMEOUT_MSが上書きされていないかを疑う

手元の環境で再現するか記録する — v2.1.285のフラグで確認できること

切り分けの材料が欲しいときは、デバッグログをファイルに残す手があります。v2.1.285のclaude --helpには次の項目が出ます。

claude --version
# 2.1.285 (Claude Code)
claude --help | grep -A1 -e "--debug-file"
#   --debug-file <path>                   Write debug logs to a specific file path
#                                         (implicitly enables debug mode)

--debug-file <path>を付けて起動すると、デバッグモードが暗黙で有効になり、ログが指定ファイルに書かれます。表示が出た時刻の前後のログを、curlの結果と並べて見られます。カテゴリで絞るなら--debug=api,hooksのように=でつなぎます。空白区切りで渡すと絞り込みは効かず、全カテゴリのデバッグになります。

もう1つ、v2.1.285の--helpの全オプションを見渡しても、タイムアウトやリトライ回数を直接指定するフラグは見当たりません。待ち時間とリトライは、後の「待ち時間そのものを調整する設定」で挙げる環境変数で調整します。会話に戻るための-c, --continue(現在のディレクトリで直近の会話を再開)と-r, --resume [value](セッションID指定、または検索語つきの選択画面)はあります。

保留表示と確定エラーを取り違えない

この表示を、確定済みのエラーと混同しないことも重要です。使用量の上限に達したときの429や、Claude側が混雑している529 Overloadedは、待っている状態ではなくすでに失敗が確定した表示で、対処もまったく別です。この2つの切り分けはClaude rate limitエラーの対処にまとめています。プロキシ環境で接続が途中で切れるSocket is closedは、v2.1.214以降は完了済みの出力がなければ自動でリトライされるようになっており、これも今回の保留中バナーとは別の症状です。

待ち時間そのものを調整する設定

20秒(アドバイザー利用中は90秒)というしきい値は、あくまで表示が出るタイミングです。カウントダウンが尽きた先で止まった接続を切るのは、ストリームのアイドル監視という別の仕組みです。調整先は、何を待たせたいかで分かれます。

ストリームが止まる症状には、API_TIMEOUT_MSだけを上げても効きません。アイドル監視は独立して動くので、止まったストリームをもっと待たせたいなら、その閾値も一緒に上げる必要があります。ANTHROPIC_BASE_URLでゲートウェイを通している場合、バイト単位の監視は既定で300秒の無通信で接続を切ります。

たとえば、ゲートウェイ越しで応答が途中で止まり、5分前後で切れるなら、2つの監視を併せて10分に上げます。settings.jsonのenvに次のように書きます。

{
  "env": {
    "CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS": "600000",
    "CLAUDE_STREAM_IDLE_TIMEOUT_MS": "600000"
  }
}

応答ヘッダがそもそも届かない症状なら、上げる対象はCLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MSです。変数どうしの組み合わせはClaude Code環境変数リファレンスにまとめています。

よくある質問

企業のLLMゲートウェイ経由でも同じしきい値ですか

はい、20秒(アドバイザー利用中は90秒)というしきい値自体はゲートウェイ経由でも変わりません。ただし、アドバイザーツール自体はAnthropic APIを直接使う構成向けの実験的機能です。Amazon Bedrock・Claude Platform on AWS・Google Cloud Agent Platform・Microsoft Foundry経由では利用できません。これらの面では90秒側のしきい値は関係せず、20秒のしきい値だけを見ておけば十分です。バイト単位の監視の既定が変わる点は、上の表のとおりです。

まとめ

表示が出るタイミング(20秒)と、接続を切るタイミング(アイドル監視)は別の仕組みです。症状がストリーム停止ならアイドル監視の2変数、ストリーミングでヘッダが来ないならCLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS、非ストリーミングを含む各試行の上限ならAPI_TIMEOUT_MSと、症状から表の行を選びます。

起動時の認証エラーやMCP接続エラーなど、この表示以外の症状はClaude Codeでよくあるエラー10選で幅広く扱っています。