「No Response From API」が繰り返し出る原因と対処 — Claude Code

Claude Codeをv2.1.181かv2.1.183で使っていると、「No Response From API」という表示が30秒おきくらいの頻度で出続けることがあります。結論から言うと、これは通信が実際に切れているサインではなく、v2.1.185で修正された表示上の不具合です。GitHub Issueでは、実際の利用・課金・リクエスト処理には影響していなかったとAnthropic側が説明しています。

とはいえ、報告されたコメントを読むと、環境によっては表示だけでなく実際にストリームが数十秒詰まる事例も混ざっており、単純な表示上の勘違いだけでは説明しきれない部分も残っています。本稿はv2.1.181/183で起きたこの表示バグ(Issue #69358)に絞ります。Waiting for API response表示が20秒の保留を経てどう出るか、一般的な意味と切り分けは「Waiting for API response」の意味と対処にまとめています。

「No Response From API」がv2.1.181とv2.1.183で繰り返し出た

この症状はGitHub 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で、2.1.181にアップデートしてから発生したとされています。

コメント欄には20件以上の反応が付き、macOS・Linuxの両方、ネイティブインストールとVS Code拡張の両方で再現するとの報告が続きました。GitHubの重複検出botは類似タイトルのIssueを3件挙げましたが、報告者はいずれも「重複ではない」と回答しており、当時すでに複数の利用者が同時期に同種の表示に遭遇していたことがうかがえます。

原因は接続断ではなく表示の不具合だった

この表示が示していた文言は、無応答が10秒続いた時点で出るNo Response from API · Retrying in …でした。「応答がない」という文言のせいで、実際には接続が生きていて再送を待っているだけの場面でも、障害が起きているように見えてしまいます。

Issueは2026年6月21日、Anthropicのjsat-antによって次のように説明されてクローズされました。表示メッセージだけの不具合であり、実際の利用・課金・リクエスト処理には影響していなかった、修正はv2.1.185で完了している、というものです。v2.1.185以降でも同じ症状が出る場合は、バージョンを添えて再度報告するよう案内されています。

v2.1.185の公式changelogには、この表示に関する変更が次のように記録されています。

文言を「応答がない」から「応答を待っている」に変え、表示までの猶予も倍にすることで、一時的な遅延を障害のように見せない設計に変わっています。この文言変更自体が、今回の表示バグに対するAnthropic側の対応だったことになります。

影響を受けたバージョンと表示条件の早見表

v2.1.185で文言としきい値の両方が変わりました。

v2.1.180、v2.1.182、v2.1.184は欠番で、実在するリリースには含まれていません。v2.1.181の一つ前は番号上v2.1.180に見えますが、実在するのはv2.1.179です。

今すぐ確認すること — バージョンを見て更新する

同じ表示に悩まされている場合、まず確認するのはインストール済みのバージョンです。

claude --version

2.1.181または2.1.183が表示された場合は、修正済みのバージョンへ更新します。

claude update

DISABLE_AUTOUPDATERを1に設定していると、バックグラウンドの自動更新チェックが止まり、2.1.181や2.1.183のまま留まり続けることがあります。この場合も手動のclaude updateは引き続き実行でき、それで修正済みバージョンへ上げられます。

v2.1.185以降でも出るなら切り分ける順番

問題になるのは、v2.1.185以降でもWaiting for API responseが毎回のターンで出て、しかも最終的に接続エラーで終わるケースです。Waiting for API response表示自体の一般的な意味・20秒しきい値・リトライ後に確定エラーへ変わる条件は前掲の記事に譲り、ここではIssue #69358で報告されたv2.1.181/183固有の2パターンだけを扱います。

Issueのコメントには、環境によって症状の出方が違うという興味深い報告も残っています。カスタムのANTHROPIC_BASE_URL(LiteLLMプロキシ経由でBedrock/Anthropicにつなぐ構成)を使っている利用者からは、別の症状が報告されています。大きな文脈(15万〜50万トークン)のターンで、クライアント側が最初の1バイトが届く前に接続を切ってしまうHTTP 460です。この報告者は、v2.1.181のchangelogにある「カスタムANTHROPIC_BASE_URLでのプロンプトキャッシュ不発を修正」という項目と関連がありそうだと推測しています。

一方、標準のapi.anthropic.comに直接つないでいた別の利用者は、--debug-fileで別のログを確認しています。最初の1バイトは2.5秒ほどで届くのに、そこから40秒ほどストリームが止まり、その後に再開して完了するという内容です。こちらはプロキシを挟まない環境でも起きていた別の症状です。

この2つの報告を踏まえると、疑う順番は次のようになります。

1. claude --versionでv2.1.185以降になっているか確認する
2. カスタムのANTHROPIC_BASE_URLを使っている場合は、curl -sS -o /dev/null -w '%{http_code}\n' "$ANTHROPIC_BASE_URL"のようなコマンドでそのホストへの疎通を直接確認する(標準のapi.anthropic.comではなく、実際に使っているプロキシ先を確認する)
3. 大きな文脈(数十万トークン級)のターンでだけ起きるかを確認する
4. それでも解消しない場合は、症状(バージョン・環境・--debug-fileのログ)を添えてIssueへ報告する

なお、この一連の表示を、使用量上限に達したときの429やAnthropic側が混雑している529 Overloadedと混同しないことも大切です。あちらはすでに失敗が確定したエラーで、対処もまったく別になります。この切り分けはClaude rate limitエラーの対処にまとめています。

テレメトリ関連の設定との相関を指摘する声もある

Issueのコメントには、DO_NOT_TRACKを1から0に変えたら表示が止まったという報告も複数残っています。実際に効いたと述べた利用者は3人ほどおり、偶然の一致だけでは片付けにくい広がりです。

ただし、これを再現性のある回避策として扱うには材料が足りません。同じスレッドでは、同一ネットワーク上のmacOSとLinuxの両方のホストで同じ症状が出て、Opus・Sonnetのどちらに切り替えても改善せず、セッションの文脈量とも相関しなかったと報告した利用者もいます。テレメトリ設定との関係には触れられておらず、DO_NOT_TRACKの変更が効いたという報告と、変えなくても改善しなかったという報告が同じスレッドに併存している状態です。テレメトリ設定を変えることが解決策だと言い切ることはできず、あくまで一部の環境で効いたという報告に留めておくのが正確です。

ダウングレードは応急処置であって恒久対応ではない

Issueのコメントには、DISABLE_AUTOUPDATER=1を設定したうえでv2.1.179のバイナリを個別インストールし、症状が消えたと報告する利用者が複数いました。当時としては実際に効く回避策だったのは確かです。

ただし、これは今から採る対処としては勧められません。v2.1.185で表示バグそのものが直っている以上、古いバージョンに固定し続けると、その後のバージョンで入った他の修正や機能を受け取れなくなります。今から同じ表示に遭遇した場合は、古いバージョンへ戻すのではなく、最新版へ更新するのが最短の対処です。

DISABLE_AUTOUPDATERを設定したまま放置していないかどうかも、あわせて確認しておく価値があります。この設定が残っていると、自動更新が働かず古いバージョンに留まり続けます(手動のclaude updateは引き続き使えます)。

「応答がない」という文言は、生きている接続を障害に見せていた

エラー文言の言葉選びそのものが、利用者の体感を左右しました。実際の通信は生きていて、単に応答を待っているだけの状態でも、「応答がない」という文言は障害を疑わせるには十分でした。

Anthropic側の対応も、通信の仕組みそのものを変えるのではなく、文言と表示タイミングの調整だけで終わっています。技術的な根本原因(なぜ一部の環境でストリームが数十秒詰まるのか)は、少なくともこのIssueの範囲では明確にされていません。表示上の誤解を解くことと、実際の遅延そのものをなくすことは、別の課題として残っていると見てよさそうです。

まとめ

v2.1.181とv2.1.183で頻発した「No Response From API」の表示は、v2.1.185で修正済みの表示バグでした。実際の利用・課金・リクエスト処理には影響しておらず、claude updateで修正済みバージョンに上げれば解消します。v2.1.185以降で同じような表示が続く場合は、バージョン確認・カスタムエンドポイントの疎通確認・大きな文脈でのみ起きるかの3点を順に切り分けるのが近道です。

起動時の認証エラーやMCP接続エラーなど、この表示以外の症状はClaude Codeトラブルシューティングガイドにまとめています。Waiting for API response表示そのものの詳しい挙動は「Waiting for API response」の意味と対処で扱っています。表示までの猶予秒数や、リトライ後に確定エラーへ変わる条件もそちらで確認できます。今回の文言・タイミング変更の全体はClaude Code v2.1.185のリリースノートで確認できます。