「No Response From API」が繰り返し出る原因と対処 — Claude Code
Claude Code v2.1.181とv2.1.183で「No Response From API」が繰り返し出た原因と、v2.1.185での修正内容、今も出るときの確認手順を扱います。
Claude Codeをv2.1.181かv2.1.183で使っていると、「No Response From API」という表示が30秒おきくらいの頻度で出続けることがありました。GitHub Issue #69358でAnthropic側は、表示メッセージだけの不具合で、実際の利用・課金・リクエスト処理には影響していなかったと説明し、v2.1.185で修正したとしています。
ただし、同じIssueにはv2.1.185以降でも出るという報告が続き、プロキシ経由の中断や、実際にストリームが数十秒止まった事例も混ざっています。画面に出ているのが一時的な待機表示なのか、リトライを使い切った確定エラーなのかで、取るべき手順が変わります。
まず見分ける — 同じ「No response」でも2種類ある
「No response from API」は、現行のClaude Codeでは性質の違う2つの場面で目にします。
待機表示と確定エラーの違い
Waiting for API response
応答ストリームに20秒間データが届かないと、スピナーにWaiting for API response · will retry in …が出ます。まだ失敗していません。カウントダウンは、停止した接続をClaude Codeが打ち切る時点まで進みます。v2.1.184以前のNo response from API · Retrying in …はこの表示の旧文言で、出るまでの時間は10秒でした。
API Error: No response from API
ストリーミング要求に対してレスポンスヘッダーが期限内に届かず、再送も応答なしだったときに、ターンがこのエラーで終わります。メッセージには(waited 3m, then 10m on the retry)のように、各回に待った時間が付きます。
この記事の主題は左側、つまりv2.1.181とv2.1.183で頻発した旧文言の表示です。右側のエラーは、再送すれば通ることが多い反面、プロキシやゲートウェイが応答を最後まで抱え込む環境では繰り返します。対処は後半の節にまとめています。待機表示の一般的な意味と20秒のしきい値は、「Waiting for API response」の意味と対処が扱っています。
v2.1.181とv2.1.183で何が起きたか
Issue #69358は2026年6月18日に起票されました。タイトルは「No Response From API 2.1.181, 2.1.183 (constantly)」で、bug・regression・api:anthropicなどのラベルが付いています。
報告者の症状は、セッションの内容にかかわらず、30秒ほどの間隔でNo Response From APIの表示とリトライのタイマーが出続けるというものでした。使用モデルはOpusで、最後に問題なかったバージョンは2.1.179です。
Issue #69358の時間軸
最後に正常だったバージョン
v2.1.179
2026年6月16日リリース
症状が出たバージョン
v2.1.181 / v2.1.183
6月17日・6月19日リリース
修正が入ったバージョン
v2.1.185
6月20日リリース。Issueは6月21日にクローズ
コメントは27件に達し、Linux(ネイティブインストール)とmacOSの両方、OpusとSonnetの両方で同種の表示が報告されました。GitHubの重複検出botが類似のIssueを3件挙げたものの、報告者はそのままスレッドを続けています。
原因は接続断ではなく表示の不具合だった
6月21日、Anthropicのjsat-antが次の趣旨でクローズしました。表示メッセージだけの不具合であり、実際の利用・課金・リクエスト処理には影響していない。修正はv2.1.185に入っている。v2.1.185以降でも出る場合はバージョンを添えて返信すれば再オープンする、という内容です。
v2.1.185のchangelogには、この表示の変更が次のように載っています。
「応答がない」という断定から「待っている」へ、しかも猶予を倍にしています。通信の仕組みそのものではなく、文言としきい値の調整で対応した形です。
| バージョン | スピナーの文言 | 表示までの無応答時間 | Issueでの状況 |
|---|---|---|---|
| v2.1.179まで | スピナーの文言No response from API · Retrying in … | 表示までの無応答時間10秒 | Issueでの状況最後に正常だったバージョン |
| v2.1.181 | スピナーの文言同上 | 表示までの無応答時間10秒 | Issueでの状況頻発の報告 |
| v2.1.183 | スピナーの文言同上 | 表示までの無応答時間10秒 | Issueでの状況頻発の報告が継続 |
| v2.1.185以降 | スピナーの文言Waiting for API response · will retry in … | 表示までの無応答時間20秒 | Issueでの状況修正版。ただし再報告あり |
v2.1.180とv2.1.184は、changelogにもnpmにもありません。v2.1.182はnpmに公開されていますが、changelogには載っていません。v2.1.181の一つ前に当たるリリースはv2.1.179です。
修正版へ更新する
同じ表示に悩まされているなら、最初にインストール済みのバージョンを確かめます。
claude --versionv2.1.289のClaude Codeでは、出力は次の1行です。
2.1.289 (Claude Code)2.1.181か2.1.183が出た場合は、更新します。claude update --helpの出力はCheck for updates and install if availableで、オプションは-h, --helpだけです。
claude update環境変数のDISABLE_AUTOUPDATERを1にしていると、バックグラウンドの自動更新が止まります。公式の環境変数一覧では、この場合も手動のclaude updateは使えます。手動更新まで塞ぐのはDISABLE_UPDATESで、こちらを設定しているとclaude updateもclaude installもブロックされます。
v2.1.185以降でも出るときの切り分け
Issueはクローズ後も更新が続きました。
- 6月22日: v2.1.185でも出るという報告(頻度は減ったという声と増えたという声に割れた)
- 6月23日: v2.1.186で、Advisorを呼ぶときに毎回出るという報告
- 7月6日・7月17日: それぞれv2.1.201・v2.1.212でも出るという報告
- 9月26日: クローズ後に動きがなかったためスレッドはロック
Advisorについては、公式のエラー解説に対応する記述があります。Advisorの相談中は、長い審査で20秒以上データが流れないことがあるため、バナーが出るまでの時間が20秒でなく90秒になります。この変更はv2.1.214からで、それ以前は相談中も20秒で表示されていました。
どこで止まっているかで、見る場所が分かれます。
v2.1.185以降で出るときの確認順
- 1
バージョンを見る
claude --versionでv2.1.185以降か確認します。v2.1.214より前なら、Advisor相談中の表示は故障ではなく仕様です。 - 2
繰り返す先がどこかを見る
標準の
api.anthropic.comか、ANTHROPIC_BASE_URLで指定したプロキシやゲートウェイかを確かめます。後者なら、疎通をcurl -sS -o /dev/null -w '%{http_code}\n' "$ANTHROPIC_BASE_URL"のようなコマンドで直接見ます。 - 3
大きな文脈でだけ起きるか見る
15万〜50万トークン級のターンでだけ出るなら、後述のプロキシ側の報告と同じ型の可能性があります。
- 4
デバッグログを取って報告する
--debug-fileでログを残し、バージョンと環境を添えて新しいIssueを立てます。ロックされた#69358には返信できません。
プロキシ経由で大きな文脈のターンが中断された報告
カスタムのANTHROPIC_BASE_URL(LiteLLMプロキシ経由でBedrockとAnthropicにつなぐ構成)の利用者は、大きな文脈(約15万〜50万入力トークン)のターンが断続的に中断すると報告しています。プロキシ手前のロードバランサーではHTTP 460(最初の応答バイトより前にクライアントが接続を閉じた)が記録され、target_processing_timeは-1でした。バックエンドは健全で、同じプロキシへのストリーミング検証では、約36万トークンのキャッシュなしでも13〜20秒で最初のバイトが返ったそうです。
この報告者は、v2.1.181のchangelogにある「カスタムANTHROPIC_BASE_URLとFoundryでプロンプトキャッシュが読まれない問題の修正」との関連を推測しています。推測の段階で、原因として確定したものではありません。参考として、ゲートウェイ経由では最初のバイトの期限(ファーストバイト期限)が働かず、応答ヘッダーを待つ時間はAPI_TIMEOUT_MS(既定600000ミリ秒)になる、とネットワーク設定のページに書かれています。
標準エンドポイントでストリームが止まった報告
別の利用者は、プロキシなしのapi.anthropic.com直結(Opus 4.8、1Mコンテキスト、Linux、v2.1.183)で、--debug-fileに次の記録を残しました。
[API:timing] first byte after 2477ms
[WARN] [Stall] stream_idle_partial lastChunkAgeMs=14999 bytesTotal=649 idleDeadlineMs=180000
[WARN] Streaming stall detected: 44.4s gap between events (stall #1)
[WARN] Streaming completed with 1 stall(s), total stall time: 44.4s最初のバイトは2.5秒で届き、649バイトの途中応答を抱えたまま約44秒止まり、その後に再開して完了しています。これは表示の誤りではなく実際の停止です。現行のドキュメントでは、途中で止まったストリームは、完了済みのテキストやツール呼び出しの有無で扱いが変わります。完了ブロックがなければ再試行かエラー終了、あるものを保持している場合はThe response above may be incompleteの通知になります。
確定エラー「API Error: No response from API」の対処
こちらはv2.1.242以降の挙動です(changelogでは2.1.243の項に載っています)。ヘッダーが来ないストリーミング要求は、既定の10分を待たずに期限で打ち切られ、最大1回再送されます。再送も応答がなければ、次のメッセージでターンが終わります。
API Error: No response from API (waited 3m, then 10m on the retry). If a proxy or gateway on your network holds responses until they complete, raise API_TIMEOUT_MS or CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS to wait longer.待ち時間の決まり方は次のとおりです。
- 1回目:
CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MSを1以上に設定していればその値(10秒〜30分に丸められる)。未設定ならバイトレベル監視のタイムアウト(直結の既定は180秒)。どちらも、リクエスト本文32KBごとに1秒が加わる - 再送:
API_TIMEOUT_MSより1秒短い時間。既定では10分弱になり、応答を生成完了まで抱えるプロキシでも待てる - v2.1.261より前: 再送も1回目と同じ期限で、メッセージに待ち時間は出ない
- 例外:
CLAUDE_CODE_RETRY_WATCHDOGを設定すると、再送1回の上限は適用されず、エラー解説ページの「Tune retry behavior」の節にある予算の範囲で再送される - 無効化: 正の
API_TIMEOUT_MSが11秒未満だと、この期限は無効になる
対処は、メッセージを送り直すところから始めます。長い入力ならtry againと打てば元のメッセージが会話に残っています。繰り返すなら、プロキシやゲートウェイが応答を最後まで保持していないかを疑い、API_TIMEOUT_MSを上げます。1回目が毎回期限切れで再送が通るなら、CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MSを上げると1回目の待ちが伸びます。Amazon Bedrockでは再送も1回目と同じ期限なので、こちらの変数も合わせて上げます。
429や529のように、失敗がすでに確定したエラーとは別物です。その切り分けはClaude rate limitエラーの対処にあります。タイムアウト全般の調整は応答が止まったときのタイムアウト調整方法で扱っています。
テレメトリ設定を変えたら止まったという報告
Issueのコメントには、DO_NOT_TRACKを1から0に変えたら表示が止まったという報告が複数あります。公式の環境変数一覧では、DO_NOT_TRACKは標準的な真偽値として読まれ、0ならテレメトリが有効のままになります。つまり、報告されているのは「テレメトリを無効にしている設定を外すと止まった」という操作です。
一方、同一ネットワーク上のmacOSとLinuxの両方で同じ症状が出て、OpusからSonnetに切り替えても改善せず、文脈量とも相関しなかったという利用者もいます。テレメトリを無効にしたままのDISABLE_TELEMETRY=1構成で再現した報告もあるため、設定変更は一部の環境で効いた事例にとどまり、再現性のある回避策とは言えません。
古いバージョンへの固定は応急処置に限る
Issueでは複数の利用者が、DISABLE_AUTOUPDATER=1を設定したうえでv2.1.179を入れ直し、症状が消えたと書いています。公式のセットアップ手順にはバージョン指定のインストール(curl -fsSL https://claude.ai/install.sh | bash -s <バージョン>)があり、実際に効いた回避策でした。
ただし、v2.1.185で表示は変わっているため、今から固定する理由は薄くなりました。固定を続けると、その後の修正も受け取れません。DISABLE_AUTOUPDATERを残したまま古いバージョンに留まっていないかは、確認する価値があります。
まとめ
v2.1.181とv2.1.183で頻発した旧文言の表示は、v2.1.185で文言と20秒のしきい値に変わりました。それでも続くなら、スピナーの待機表示か確定エラーかを先に見分けてください。待機表示ならバージョンと接続先、確定エラーならプロキシの保持時間とAPI_TIMEOUT_MSが、次に見る場所になります。
起動時の認証エラーやMCP接続エラーなど、この表示以外の症状はClaude Codeトラブルシューティングガイドにあります。サーバーから不正な応答が返ったときはAPI returned an empty or malformed responseの原因と対処を参照してください。今回の文言変更を含むリリース全体はClaude Code v2.1.185のリリースノートにあります。