Claude Codeの応答が遅い原因と対処｜キャッシュと混雑の見分け

Claude Codeの応答が遅いとき、この記事では確認先を5つに分けます。モデル切替や休憩明けでプロンプトのキャッシュ再構築が行われている、サービスの混雑でAPIが裏で自動リトライしている、通信経路が詰まっている、**effort（推論の深さ）**が高くて考える時間が長い、手元の作業環境（メモリやプラグイン、MCPサーバー）が重い、の5つです。見分ける手がかりは、遅いのが「1回だけ」なのか「毎回」なのか、そしてスピナー（処理中表示）にどんな文言が出ているかです。この記事では、公式ドキュメント（code.claude.com）の記述に沿って、症状ごとの確認コマンドと対処を順に説明します。

Claude Codeの応答が遅いとき、まず何を見れば原因を絞れる？

最初に見るのは、遅くなるタイミングとスピナーの表示です。次の表で、自分の症状に近い行から確認してください。

症状	疑う原因	最初の確認
休憩明けやモデル切替の直後だけ1回遅い	プロンプトキャッシュの作り直し	`/usage` の `Prompt cache (main)` 行
`Retrying in Ns · attempt x/y` が出て待たされる	APIの混雑や一時的なエラーで自動リトライ中	エラーの種類。529ならステータスページ
`Waiting for API response` が毎回出る	通信経路（VPN・プロキシ）	`curl -I https://api.anthropic.com`
返ってくる内容は良いが毎回考える時間が長い	effort が作業に対して高い	`/effort status` で現在のレベルを確認
入力が遅れる、画面が固まる、PCのファンが回る	メモリ・CPU、プラグインやMCPサーバー	`/doctor`、`claude --safe-mode`

応答が遅い原因がどれに当たるか分からない場合は、Claude Code の中で /doctor を実行します。公式のトラブルシューティングによると、/doctor はインストール、設定、拡張機能、コンテキスト使用量を自動でチェックし、確認のうえで適用できる修正を提案します。Claude Code が起動すらしない場合は、シェルから次を実行します。

claude doctor

MCPサーバーの状態は /mcp で確認できます。

休憩明けやモデル切替の直後だけ遅いのはなぜ？

この症状は、プロンプトキャッシュの作り直しで起きる場合があります。

公式ドキュメントによると、Claude Code はメッセージのたびにシステムプロンプトからそれまでの会話までを丸ごと送り直しています。それでも速いのは、APIが前回と同じ先頭部分をキャッシュから再利用しているからです。先頭のどこかが変わると、そこから後ろはすべて計算し直しになり、次の1ターンだけ遅く、高くなります。

どの操作でキャッシュが外れる？

公式が挙げている主な操作は次のとおりです。

/model でのモデル切替（モデルごとにキャッシュが別）
effort の変更（多くのモデル。ただし Opus 5.5、Sonnet 5.5、Haiku 5.5、Fable 5.1 をAPIキーまたはClaudeのサブスクで使う場合は、effortを変えてもキャッシュは保たれる）
fast mode を有効にする
MCPサーバーの接続や削除（ただし対応モデルで既定のツール遅延ロード時は、途中の接続・切断で既存のキャッシュは乱れない）
プラグインの有効化・無効化
会話の圧縮（/compact）
画像の蓄積（古い画像がまとめて外されるたびに1回遅いターンが出る）
Claude Code のアップグレード（アップグレード後に始めた最初の会話は、キャッシュを先頭から作る）

休憩明けの1回目が遅い理由

キャッシュには有効期限（TTL）があり、使い続ける限り延長されますが、間が空きすぎると入力全体を計算し直します。公式はこれを、離席から戻った最初のターンが遅くなる理由として挙げています。メイン会話の既定TTLは次のとおりです。

利用の形	メイン会話の既定TTL
Claudeのサブスク（プランの利用枠内）	1時間
使用クレジット、APIキー、クラウドプロバイダー	5分

サブスクでもプランの上限を超えて使用クレジットを使い始めると、5分に下がります。TTLは promptCacheTtl 設定（または環境変数 CLAUDE_CODE_PROMPT_CACHE_TTL）で 5m か 1h を指定できます（v2.1.242以降）。ただし1時間のTTLはキャッシュ書き込みの単価が高く、作業の間隔が5分を超えない短い作業では割高になると公式は書いています。

キャッシュが原因かどうかを確かめる

メイン会話で最初の応答を受けた後に /usage を実行すると、Session ブロックに Prompt cache (main) 行が出て、キャッシュのヒット率、ミスの回数、いまキャッシュが温まっている（warm）かが分かります（v2.1.251以降）。v2.1.260以降は、原因を特定できた場合に likely cause: tool definitions changed のような直近のミスの推定原因も表示されます。ミスが増えていれば、キャッシュの作り直しが遅さに関わっている可能性があるので、直前にモデルや effort を変えていないかも確認します。

作業途中の作り直しを減らすには

応答が遅いときの公式のヒントは「モデルとeffortはセッションの最初に決め、/compact はタスクの区切りに取っておく」です。

/compact は自動圧縮を待たず、タスクの間に自分で実行する。古いセッションを再開した直後の /compact が最も重い
方向を捨てたいときは /rewind で前のターンに戻る。キャッシュ済みの地点に戻るので作り直しが起きない
続きが不要なら /clear で新しく始める

コンテキストウィンドウの仕組みはコンテキストウィンドウの解説、使用量の見方はトークン使用量の確認方法で扱っています。

「Retrying in」が出て待たされるときは何が起きている？

スピナーに Retrying in Ns · attempt x/y が出ている間、Claude Code は失敗したリクエストを自動で送り直しています。公式によると、一時的な失敗は指数バックオフで最大10回リトライしてからエラーを表示します。体感は「遅い」でも、実際は裏で再送中です。エラーの理由が表示された後、それが529（過負荷）なら、カウントダウンの下にサービス状態の確認先が出ます（Anthropic API なら status.claude.com、他の構成ではメッセージ内のプロバイダーやゲートウェイのホスト）。リトライし切ると API Error: Repeated 529 Overloaded errors になります。

公式の説明では、529は「全ユーザーにまたがってAPIが一時的に容量不足」という意味で、あなたの使用上限ではなく、クォータも消費しません。対処は次の3つです。

status.claude.com（または、メッセージに出ているプロバイダーのステータスページ）で容量に関するお知らせを確認する
数分おいて再試行する
/model で別のモデルに切り替える。容量はモデルごとに管理されている（切替直後の1ターンはキャッシュなしになる）

プランの使用上限による停止は、529の混雑とは別の問題です。仕組みはレート制限の解説を参照してください。

毎回遅い・つながりにくいときは通信経路をどう確かめる？

応答のデータが20秒届かないと、スピナーに Waiting for API response · will retry in … · check your network が出ます。この時点ではまだ失敗ではありませんが、毎回の試行で出るならネットワークの問題として扱うよう公式は案内しています。確認手順は次のとおりです。

Claude Code を動かしているのと同じシェルから、APIのホストに届くかを確認する

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

Windows の PowerShell では、組み込みの Invoke-WebRequest エイリアスを避けるため curl.exe -I https://api.anthropic.com を使います。

社内プロキシの内側にいる場合は、Claude Code を起動する前に HTTPS_PROXY を設定する
VPN 利用中なら、api.anthropic.com が遮断されていないかを確認する
curl は通るのに Claude Code だけ失敗するなら、古い ANTHROPIC_BASE_URL が残っていないかを確認する。設定されているとリクエストはそのアドレスへ送られる

回線やプロキシが遅い環境では、環境変数 API_TIMEOUT_MS（既定 600000ミリ秒）を引き上げられます。

プロキシ、証明書、WSL・Docker環境まで含めた通信エラーの切り分けは、ネットワークエラーの対処で詳しく扱っています。

内容は良いのに毎回考える時間が長いときはどうする？

答えに問題はなく待ち時間だけが長いなら、effort が作業に対して高すぎる可能性があります。公式の説明では、effort は「低いほど単純な作業で速く安く、高いほど複雑な問題で深く推論する」設定です。対応モデルの既定は high ですが、Opus 5.5、Sonnet 5.5、Haiku 5.5 は medium、Opus 4.7 は xhigh です。以前 /effort で高いレベルを保存していると、その値が使われ続けます。

レベル	公式が示す用途
`low`	結果を1つずつ確認しながら進めるやり取り。ブレスト、たたき台、名前の変更のような小さな修正
`medium`	Opus 5.5、Sonnet 5.5、Haiku 5.5 の既定。Opus 5.5 と Sonnet 5.5 では、範囲がはっきりした日常の開発作業向け
`high`	検証が重要な作業や、エッジケースが出やすい既存コードのバグ修正
`max`	難しい問題を任せるとき。公式は考えすぎの傾向があると注意している

/effort を引数なしで実行するとスライダーが開き、レベル名を付ければ直接設定、/effort auto で保存値を解除できます。起動時の --effort フラグはそのセッションだけに効きます。多くのモデルでは effort の変更でキャッシュが外れるため、セッションの最初に決めておきます。モデルそのものの選び方はモデルの違いと使い分けを参照してください。

画面が固まる・PCが重いときはローカルで何を確認する？

入力が遅れる、表示が固まるといった症状は、手元の環境が原因のことがあります。固まったら Ctrl+C でキャンセルを試み、反応しなければターミナルを閉じて再起動します。会話の状態は失われず、同じディレクトリで次を実行すれば再開できます。

claude --resume

CPUやメモリの使用量が高いときの公式の手順は次のとおりです。

/compact を定期的に実行してコンテキストを小さくする
大きなタスクの合間に Claude Code を終了して起動し直す
大きなビルドディレクトリを .gitignore に追加することを検討する
claude --safe-mode で起動し直し、プラグイン、MCPサーバー、フックが原因かどうかを確かめる

ヒープメモリが2.5GBを超えると警告が出るので、その場合は再起動して claude --continue で新しいプロセスに会話を引き継ぎます。手順4の safe mode は、そのセッションのカスタマイズをすべて無効にして起動します。

claude --safe-mode

safe mode で遅さが消えれば、無効にした項目のどれかが原因です。/mcp でサーバーの接続状態を、/context でコンテキストに載っている内容をカテゴリ別に確認して絞り込みます。MCPの設定方法はMCPの設定ガイド、プラグインの扱いはプラグインの解説にまとめています。

WSL では、プロジェクトを Windows 側（/mnt/c/）ではなく Linux 側（/home/）に置くよう公式は勧めています。ファイルシステムをまたぐとディスク読み取りが遅くなるためです。

fast modeやプランの変更で応答は速くなる？

参照した公式ドキュメントで、応答を速くする手段として書かれているのは fast mode です。fast mode は Opus を最大2.5倍速くする設定で、トークン単価は高くなります。モデルは同じ Opus なので品質は変わりません。

/fast で切り替える。有効中はプロンプトの横に ↯ が出る
対応モデルは Opus 5.5、Opus 5、Opus 4.8。Sonnet や Haiku などでは使えない
Pro、Max、Team、Enterprise のサブスクでは、fast mode は使用クレジットでのみ利用でき、サブスクの利用枠には含まれない。Team と Enterprise は、組織の Owner が先に有効化する必要がある
会話の途中で初めて有効にすると、それまでの会話全体を非キャッシュの fast mode 単価で処理するため、セッションの最初に有効にするのが安い

一方、プランを上げると応答そのものが速くなるかは、この記事で参照した範囲の公式ドキュメントでは確認できませんでした。プランごとの違いは料金プランの比較で整理しています。

確認しても遅いままなら、どこに報告する？

原因が見つからない場合は、Claude Code の中で /feedback を実行して Anthropic に直接報告するか、GitHub の anthropics/claude-code リポジトリで既知の問題を確認します。遅くなるタイミング、スピナーの文言、/usage の Prompt cache (main) 行を添えると伝わりやすくなります。

なお、紹介した表示の一部にはバージョン条件があり、fast mode はリサーチプレビューのため機能や料金が変わりうると公式に明記されています。表示が記事と違う場合は、公式ドキュメントで対象バージョンを確認し、必要に応じて Claude Code を更新してください。

遅さを繰り返さないためにセッションをどう運用する？

公式の記述から、作業途中の遅さを減らすセッション運用をまとめます。

モデルと effort はセッションの最初に決め、作業の途中で変えない
/compact はタスクの区切りで自分から実行し、方向転換には /rewind、続きが不要なら /clear を使う
遅く感じたら、まず /usage の Prompt cache (main) 行とスピナーの文言を見て、キャッシュ・混雑・通信・ローカルのどれかを切り分ける

こうしたセッションの区切り方や指示の整理は、型として身につけておくと毎回迷わずに済みます。月額1,980円から参加できる学習コミュニティ「AI駆動ラボ」（lab.no-wave.jp）では、コンテキスト管理やセッション設計の型を、自分の手を動かしながら練習できます。