「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秒後に表示が切り替わり、文言も「応答がない」ではなく「応答を待っている」という表現に変わっています。

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

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

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

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

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

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

1. データが再開する: ストリームが動き出せば、バナーは自動で消えます。何もする必要はありません
2. リトライが成功する: Claude Codeが接続を諦めて再送し、それが通れば同じくバナーは消えてターンが続きます
3. リトライも尽きる: 完了したブロックがあれば、そこまでの出力を保持したままAPI Error: Response stalled mid-stream. The response above may be incomplete.が表示されます。完了したツール呼び出しがあればClaude Codeはそれを実行してその結果からターンを続け、完了していたのがテキストだけならそこでターンが終わります。何も完了していなかった場合は、通常のエラーとして扱われます

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

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

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

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

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

Server error mid-responseはv2.1.199で追加された区分です。3つとも、完成済みのブロックを破棄しない点は共通です。

エラー後の流れも共通です。完了したツール呼び出しがあればClaude Codeはそれを実行し、その結果からターンを続けます。完了していたのがテキストだけならそこでターンが終わるので、続きが欲しいときはcontinueと送って再開します。

非対話モード(-p)では挙動が少し変わります。デフォルトのテキスト出力は最後に完成したテキストブロックをそのまま表示したうえで、このメッセージを追加します。--output-format jsonまたはstream-jsonを使っている場合は、resultフィールドにこのメッセージが報告されます。

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

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

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

このcurlが失敗するなら、原因はClaude Codeより手前にあります。よくある原因は次の3つです。

• インターネット接続そのものがない、またはVPNがapi.anthropic.comをブロックしている
• 社内プロキシが必須なのにHTTPS_PROXYが未設定
• ファイアウォールが必要なホストを許可していない

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だけ失敗する場合は、Claude Codeの手前ではなくランタイムとネットワークの間に原因があることが多いです。

• Linux / WSL: /etc/resolv.confに到達できないネームサーバーが残っていないか。WSLはホストから壊れたリゾルバーをそのまま引き継ぐことがあります
• macOS: 切断・アンインストール済みのVPNクライアントが古いトンネルインターフェースやルーティングルールを残していないか。ifconfigで古いutunインターフェースを確認します
• Docker Desktop: コンテナランタイムが外向き通信を横取りしていないか。一度終了して切り分けます

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

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

20秒(アドバイザー利用中は90秒)というしきい値は、あくまで表示が出るタイミングです。Claude Codeが実際に接続を諦めるまでの上限は別の設定で決まります。

API_TIMEOUT_MSはリクエストごとのタイムアウトで、既定値は600000ミリ秒(10分)です。つまり表示が出てから即座にタイムアウトするわけではなく、遅いネットワークやプロキシ越しの環境ではこの値を引き上げることで、時間のかかる応答を待てるようになります。リトライの粘り自体を変えるCLAUDE_CODE_MAX_RETRIESやCLAUDE_CODE_RETRY_WATCHDOGとは役割が異なり、こちらは1回のリクエストにどこまで待つかを決める設定です。設定の書き方や他の環境変数との組み合わせはClaude Code環境変数リファレンスにまとめています。

よくある質問

アドバイザーを使っているときに20秒で表示が出るのは異常ですか

いいえ。アドバイザーツールを使っている間は、しきい値が20秒ではなく90秒に延びます。v2.1.214より前は20秒のしきい値がアドバイザー相談中にもそのまま適用されるバグがあり、問題が起きていないのに表示が出ることがありました。v2.1.214以降は90秒までが想定内の待ち時間です。

表示が出ている間にCtrl+Cで止めても大丈夫ですか

Ctrl+Cは現在の操作をキャンセルする一般的な手段として案内されています。反応しない場合はターミナルを閉じて再起動しても会話は失われず、同じディレクトリでclaude --resumeすればセッションを再開できます。

Desktop版やWeb版でも同じ表示が出ますか

出ます。CLI・Desktopアプリ・Claude Code on the webはいずれも同じClaude Code本体をラップしているため、このバナーの挙動や表示条件は3つの面で共通です。

「waiting for api response」と「Retrying in Ns · attempt x/y」は何が違いますか

前者はまだ実際のリトライが始まっていない保留中の表示で、リクエスト自体はまだ失敗していません。後者は実際にリトライ試行が進んでいる番号付きのカウントダウンです。表示が切り替わった時点で、ストリームが止まったと判断されてリトライフェーズに移ったことを意味します。

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

はい、20秒(アドバイザー利用中は90秒)というしきい値自体はゲートウェイ経由でも変わりません。違うのは疎通確認の相手先だけで、ANTHROPIC_BASE_URLを設定している場合はゲートウェイのホストに対してcurlを実行します。ただし、アドバイザーツール自体はAnthropic APIを直接使う構成向けの実験的機能で、Amazon Bedrock・Claude Platform on AWS・Google Cloud Agent Platform・Microsoft Foundry経由では利用できません。これらの面では90秒側のしきい値は関係せず、20秒のしきい値だけを見ておけば十分です。ゲートウェイの手前の設定ミスと、その先のAnthropic側の混雑を切り分けるには、まずゲートウェイの応答速度そのものを確認するのが近道です。

まとめ

Waiting for API response · will retry in …は、20秒(アドバイザー利用中は90秒)データが届かないときに出る保留中の表示で、それ自体は失敗ではありません。データが再開するかリトライが成功すれば自動で消え、尽きた場合だけResponse stalled mid-streamのような確定エラーに変わります。たまに出るだけなら無視してよく、毎回のターンで出てエラーに終わるなら、curlでの疎通確認からネットワーク側を切り分けます。待ち時間の上限そのものを伸ばしたいならAPI_TIMEOUT_MS、リトライの粘りを変えたいならCLAUDE_CODE_MAX_RETRIESとCLAUDE_CODE_RETRY_WATCHDOGと、調整する設定が違う点も押さえておくと迷いません。

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