「Request timed out」「No response from API」の対処法

更新 2026.10.09
公開 2026.10.09
出典 2件
約10分で読めます

Claude Codeで「Request timed out」や「No response from API」が出た時の意味と対処を、公式のエラー一覧で確認できる範囲で整理。待ち時間の仕組みと、API_TIMEOUT_MSの調整までを解説します。

公的機関・公式資料などの一次情報と照合して作成しています。このサイトについて

Request timed out と No response from API とは

この2つは、どちらも「待ったのに返事が来なかった」エラーですが、待っていた場所が違います。

Request timed out は、API が接続の期限までに応答しなかったことを示します。公式は、高負荷の時間帯や、モデルがとても大きな応答を作っている時に起こりうると説明しています。

No response from API は、もう少し限定された状況です。Claude Code が、ストリーミング（返事を少しずつ受け取る方式）のリクエストを送ったのに、最初の応答（応答ヘッダー）が期限内に返らなかった場合に出ます。この場合、Claude Code は既定で10分かかる通常のタイムアウトを待たず、先に打ち切ります。そして再試行の上限が許す範囲で最大1回だけ送り直し、それも返事がなければ、このメッセージでそのターン（1回のやり取り）を終えます。

サーバーが 500 や 529 を返した場合は529エラーの記事や障害・5xxエラーの確認で扱い、この記事は返事そのものが来ないタイプに絞ります。

基本（待ち時間と再試行の仕組み）

公式のエラー一覧（Error reference）で確認できた内容を整理します（2026年10月に確認）。

項目	公式の記載
Request timed out の意味	API が接続の期限までに応答しなかった
既定のリクエストタイムアウト	10分（API_TIMEOUT_MS の既定値は 600000 ミリ秒）
自動再試行	一時的な失敗を最大10回、間隔を延ばしながら再試行してから表示する
再試行されるもの	応答が流れ始める前に届いた、サーバーエラー、過負荷、リクエストのタイムアウトなど
No response from API の再試行	再試行の上限内で最大1回だけ再送。CLAUDE_CODE_RETRY_WATCHDOG を設定した場合は、この1回の上限は適用されない

No response from API の待ち時間は、初回と再送で別々に決まります。

初回：CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS を1以上に設定していればその値（10秒から30分の範囲に収められます）。未設定の場合は、バイト単位の監視タイマーの時間が使われます。どちらの場合も、リクエスト本文32KBごとに1秒が加算されます。
再送：API_TIMEOUT_MS より1秒短い時間（既定では10分弱）。生成が終わるまで返事を止めるプロキシやゲートウェイでも待てるようにするためです。Amazon Bedrock では、再送も初回と同じ時間です。

この最初のバイトを待つ期限（First-byte deadline）は、ネットワーク設定のページの「Streaming idle watchdogs」に表があり、既定は直接 Anthropic API で180秒、それ以外で300秒です。ただし、ゲートウェイ経由や Google Cloud、Microsoft Foundry では働かず、Amazon Bedrock では設定で有効にした場合だけ働きます。働かない接続では API_TIMEOUT_MS まで待ちます。

どちらの待ち時間も、正の値の API_TIMEOUT_MS より1秒短い時間を超えません。API_TIMEOUT_MS を11秒未満の正の値にすると、この期限は無効になります。

具体例（画面の文言）

Request timed out

Request timed out

接続エラーの節には、次の文言もあります。

Request timed out. Check your internet connection and proxy settings

公式の早見表では、接続への言及がある場合はネットワークの節を見るよう案内されています。接続の切り分けはUnable to connect to API の記事にまとめています。

No response from API

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.

括弧の中は、各試行が何分待ったかです。上の例は公式に載っている文言で、初回3分、再送10分を表します。v2.1.261 より前は、再送の待ち時間が初回と同じで、メッセージに時間も出ませんでした。v2.1.242 より前は、返事のないストリーミングのリクエストに、10分のタイムアウトいっぱいまで待ってから失敗していました。

待っている最中の表示

20秒間データが来ないと、スピナーに次のように出ます。

Waiting for API response · will retry in … · check your network

これはまだ失敗ではありません。カウントダウンは、Claude Code が止まった接続を打ち切る時点までを示します。データが再び流れるか、再試行が成功すれば自然に消えます。

Request timed out と No response from API の実践ステップ

メッセージをそのまま送り直す。公式は、元のメッセージは会話に残っているので、長い入力は貼り直さず「try again」と送ればよいとしています。
文言を確かめる。Request timed out だけか、No response from API か、接続への言及があるかで次が変わります。
繰り返すなら、ネットワークやプロキシの問題として扱う。まず同じシェルから、次のコマンドで API に届くかを確かめます（PowerShell では curl.exe）。

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

遅いネットワークやプロキシが原因なら、API_TIMEOUT_MS を大きくする。単位はミリ秒です。たとえば20分なら 1200000 になります。
プロキシやゲートウェイが、生成が終わるまで返事を止めておく環境なら、No response from API の再送が待てるよう API_TIMEOUT_MS を上げる。Amazon Bedrock では、CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS も上げます。
初回は何度もタイムアウトし、再送では成功する場合は、CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS を上げ、初回の待ち時間を延ばす。
環境変数は、シェルで設定するか、設定ファイル（settings）の env ブロックに書きます。設定の場所はsettings.json の記事を参照してください。
改善しない場合は、公式の Report an error の案内に沿って、Claude Code の中で /feedback を実行して報告します。

Request timed out と No response from API の注意点

待ち時間を延ばしても根本の解決にならない場合があります。ネットワークやプロキシに問題があれば、そちらが先です。
非ストリーミングのリクエストでは、生成に時間のかかる応答は再送のたびにタイムアウトすると公式は書いています。CLAUDE_CODE_NONSTREAMING_TIMEOUT_RETRIES を 0 などの小さな値にすると早く失敗にできます（v2.1.285 以降）。
CLAUDE_CODE_RETRY_WATCHDOG は、公式では CI のような無人のセッション向けの設定として説明されています。
応答ヘッダーが届いた後に止まった場合は、このエラーではなく停止したストリームの規則に従い、状況に応じて再試行されるか、「応答が途中で止まる」系の表示になります（別記事）。

Request timed out と No response from API でよくあるミス

毎回、長い入力を貼り直す。「try again」で足りると公式は案内しています。
タイムアウトの値を、秒のつもりで設定する。API_TIMEOUT_MS はミリ秒で、10分は 600000 です。正の値で11秒未満にすると、No response from API の期限が無効になります。
5xx 系のエラーと混同する。返事が来ないことと、サーバーがエラーを返したことは、見る場所が違います。

Request timed out と No response from API のチェックリスト

画面の文言が Request timed out か No response from API かを確認したか。
同じメッセージを一度送り直したか（try again）。
同じシェルから curl で API に届くか確認したか。
社内プロキシやゲートウェイを通っているか把握しているか。
API_TIMEOUT_MS をミリ秒で設定したか（11秒未満にしていないか）。
Bedrock を使う場合、CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS も検討したか。
Claude Code のバージョンを確認したか。

Request timed out と No response from API のFAQ（よくある質問）

Q. 何分待てばタイムアウトになりますか。
A. 既定のリクエストタイムアウトは10分です（2026年10月に確認）。ただし No response from API では、最初の応答を待つ期限が別にあり、直接 Anthropic API の場合の既定は180秒に、リクエスト本文の大きさに応じた時間が加わります。

Q. 会社のプロキシ経由だと必ず出ます。
A. 公式は、生成が終わるまで返事を止めるプロキシやゲートウェイがある場合に API_TIMEOUT_MS を上げるよう案内しています。プロキシ側の設定の変更は、社内のネットワーク担当部門にご相談ください。

Q. 障害が起きているかは、どこで確認しますか。
A. status.claude.com を確認するよう、500 や 529 の項と Report an error の項で案内されています。Request timed out 自体の項には、確認先の記載はありませんでした。

筆者の見解（Request timed out と No response from API）

私見では、このエラーで初心者がいちばんつまずくのは、「待ち時間を延ばせば直る」と考えて、最初に API_TIMEOUT_MS を大きくしてしまうことだと考えます。待ち時間は直す道具ではなく、どこで止まっているかを知る手がかりとして読むほうが早道です。No response from API のメッセージには、初回と再送がそれぞれ何分待ったかが出ます。まずこの数字を書き留め、初回だけ失敗して再送で通るのか、両方とも返事がないのかを見分けるのが先だと考えます。前者なら初回の期限の調整、後者ならネットワークやプロキシの確認と、次の一手が決まります。また、スピナーに Waiting for API response が出た段階はまだ失敗ではないので、慌てて中断を繰り返すより、一度結果を見届けたほうが得られる情報は多いはずです。

やってはいけないと考えるのは、単位を確かめずに値を書き換えることと、再試行を無制限にする設定を対話の利用に持ち込むことです。前者は期限そのものを無効にしかねず、後者は見えるべき失敗を隠してしまいます。変えた設定は記録し、改善しなければ元に戻す、というのが筆者の考えです。

Request timed out と No response from API の関連項目

出典（一次情報）

本記事は一般的な情報の提供を目的としています。Claude Code の料金・利用上限・機能・エラーメッセージ・コマンドは頻繁に更新されるため、最新の内容は Anthropic の公式ドキュメントとお使いのバージョンで必ずご確認ください。契約・請求・セキュリティに関する判断は、公式サポートや社内の担当部門にご相談ください。「筆者の見解」は一つの考え方です。