Claude Codeが遅い原因と対処｜応答が遅い・固まるときの確認手順

「Claude Codeに頼んでから、返事が始まるまでが長い」「最近、途中で止まったように見える」「画面がちらついて操作しづらい」と困っている方も多いのではないでしょうか。

一口に「遅い」といっても、原因はいくつかに分かれます。会話が長くなりすぎている場合もあれば、考える深さの設定が高い場合や、サービス側が混み合っている場合、パソコンやターミナルの描画が追いついていない場合もあります。原因によって直し方がまったく違うので、まず症状から原因を切り分けることが近道です。

この記事では、Claude Codeが遅い・重い・固まるときの原因と対処を、症状の切り分け、会話の長さ、モデルとeffort、読み込む拡張、混雑や通信、パソコンと画面の順に解説します。内容は2026年10月時点の公式ドキュメントをもとにしています。公式ドキュメントには「何％速くなる」といった数値が載っていない対処も多いため、この記事でも効果の大きさは断定せず、公式に書かれている範囲だけを紹介します。使用量を減らす方法は「Claude Codeのトークンを節約する方法」の記事で詳しく扱っているので、ここでは遅さの原因を見つけて直すことに絞ります。

まず、どの遅さかを切り分ける

最初に、どんな遅さなのかを言葉にしてみます。症状が分かれば、見るべき場所が決まります。次の表は、症状ごとに考えられる原因と、この記事で読む節をまとめたものです。

止まっているのか、動いているのかを見る

返事が出てこないとき、本当に止まっているとは限りません。Claude Codeは、作業中のスピナー（待機中を示す表示）の横に、経過時間とトークン数（AIが書いた文字量の目安）を表示することがあります。公式ドキュメントでは、たとえば(10m 27s · ↓ 5.5k tokens)のような表示で、今の依頼でClaudeがここまでに書いた量を表すと説明されています。この数字が増えていれば、止まってはおらず、書いている最中です。

なお、この数字は「Claudeが書いた量」であり、会話の履歴や読み込んだファイルの分は含まれません。出力が始まるまでは表示されず、画面が狭いときも出ません。出力が始まらないまま長く待たされる場合は、会話の長さやキャッシュ切れ、混雑や通信の遅れなどが考えられます。

方向がずれていると気づいたときは、Escキーで止めて、指示を足せます。公式のベストプラクティスでも、道筋がずれたらすぐ止めて修正する方が、長く待ってからやり直すより効率がよいと案内されています。

最初に試す3つ

原因が分からないうちは、次の3つを順に試すと、範囲を絞れます。

1. 「/doctor」を実行するインストールや設定、拡張機能の状態、文脈（会話の記憶の枠）の使われ方を調べて、直せるものは確認のうえで直してくれます。Claude Codeが起動できないときは、ターミナルでclaude doctorを実行します。
2. サービスの状況を確かめる混雑や障害は自分では直せません。公式の状況ページ（status.claude.com）で、問題が出ていないかを見ます。
3. 設定を無効にして試すclaude --safe-modeで起動すると、CLAUDE.md・スキル・プラグイン・フック・MCPサーバーなどを無効にした状態で動きます。これで軽くなるなら、原因は自分で入れた設定や拡張のどれかです。

会話が長いと、1回ごとが重くなる

公式のベストプラクティスは、ほとんどの対策の前提として「Claudeの文脈（会話の記憶の枠）は早く埋まり、埋まるほど性能が落ちる」という点を挙げています。会話に入っているのは、あなたのメッセージだけではありません。Claudeが読んだファイルの中身や、実行したコマンドの出力も、すべて会話に積み上がります。

毎回、会話の全体が送られる

モデルは前回のやりとりを覚えていないため、Claude Codeは依頼のたびに、これまでの会話の全体をあらためて送っています。会話が長くなるほど、1回あたりに処理する量が増えます。使用量の面でも同じ仕組みで、詳しくは「Claude Codeのトークンを節約する方法」で解説しています。

そこで効いてくるのが、キャッシュです。前回までに処理した部分を再利用して、変わった部分だけを新しく処理します。公式ドキュメントでは、キャッシュによって、毎回すべてを処理し直すより速く、安く済むと説明されています。

キャッシュが切れると、最初の1回が遅い

キャッシュは、しばらく使わないと消えます。切れたあとの最初の依頼は、会話の全体を処理し直すため、公式ドキュメントも「席を外したあとの最初の1回は、はっきり遅くなることがある」と説明しています。有効な期間は、使い方によって違います。

APIキーやクラウド経由で使っている場合は、promptCacheTtlという設定、または環境変数CLAUDE_CODE_PROMPT_CACHE_TTLで1hを指定すると、メインの会話のキャッシュを1時間にできます。ただし、公式ドキュメントでは、1時間のキャッシュは書き込みの料金が高くなる点も説明されています。短い作業を連続で行うだけなら、5分のままの方が得な場合もあります。

キャッシュを切ってしまう操作

休憩していなくても、操作によってはキャッシュが使えなくなり、次の1回が遅くなります。公式ドキュメントにある主なものを表にまとめました。

「opusplan」というモデル指定は、計画モードに入るたびにOpusとSonnetが切り替わるため、そのたびにキャッシュが作り直されます。計画と実行で頻繁に行き来する作業では、思ったより遅く感じる場合があります。

会話を短くする

会話が長くなってきたら、次のコマンドで短くします。使い分けは次のとおりです。

公式のベストプラクティスには、同じ問題で2回以上直しても直らないときは、会話に失敗した道筋が積もっているので「/clear」して、学んだことを入れた依頼を書き直した方がよいと書かれています。長く積もった会話より、きれいな会話に良い依頼を書く方が、たいてい良い結果になるという考え方です。

「/compact」は、キャッシュが有効なうちに行えば、読み込みは安く済み、時間のほとんどは要約を書く部分にかかります。一方で、長く休んだあとに実行すると、会話の全体を処理し直すため、重くなります。自動で要約が走るのを待つより、自分で作業の切れ目を選んで行う方が、残してほしい内容を指定できます。

休憩のあとに大きな会話を再開すると、ProやMaxでは、要約してから再開する選択肢が表示されることがあります。前の作業の細かい内容が不要なら、要約からの再開を選ぶと、以降の依頼が軽くなります。

自動の要約が止まるとき

会話が限界に近づくと、Claude Codeは自動で要約します。ところが、巨大なファイルやコマンドの出力が、要約した直後にまた会話を埋めてしまうことがあります。これが数回続くと、Autocompact is thrashing: the context refilled to the limit...というエラーが出て、無駄な呼び出しを避けるために自動の要約を止めます。公式ドキュメントでは、次の順で直すよう案内されています。

1. ファイルを小分けにして読ませるファイル全体ではなく、特定の行の範囲や関数だけを読むように頼みます。
2. 大きな出力を捨てる指示で要約するたとえば/compact keep only the plan and the diffのように、残す内容を絞ります。
3. 大きなファイルの作業をサブエージェントに任せる別の会話の枠で動くので、メインの会話が埋まりません。
4. 前の会話が不要なら「/clear」するそれでも繰り返すときは、「/context」で、最初に読み込む内容の方が大きくないかを確認します。

モデル・effort・fast modeを見直す

返事が始まってから終わるまでが長い場合は、モデルと「考える深さ」の設定を見直します。ここでは、遅さの面から見たポイントだけを紹介します。モデルの種類や選び方の全体像は「Claude Codeのモデル変更方法」の記事にまとめています。

契約プランの既定は高性能なモデル

公式ドキュメントによると、Pro・Max・Team・Enterpriseの契約やAnthropic APIで使う場合、既定のモデルはOpus 5.5です。Opusは、公式の説明では複雑な推論向けのモデルです。簡単な作業が中心なら、より軽いモデルに切り替える選択肢があります。

公式ドキュメントには、モデルごとの応答速度を比べた数値は載っていません。「Haikuは高速で効率がよい」という説明と、「Sonnetはコストが低い」という説明があるだけです。体感での違いは、使っている作業や混み具合によっても変わるので、簡単な作業でモデルを下げて試し、違いを自分の目で確かめるのが確実です。

「/model」を開いてEnterキーで選ぶと、新しい会話の既定として保存され、「s」キーで選ぶと、いまの会話だけに適用されます。まずは「s」で試すと、元に戻す手間がありません。

考える深さ（effort）を下げる

effortは、Claudeがどれだけ深く考えてから答えるかの設定です。公式ドキュメントによると、レベルはlow・medium・high・xhigh・maxがあり（モデルによって選べる段階は異なります）、既定は次のとおりです。

• Opus 5.5・Sonnet 5.5・Haiku 5.5：medium
• Opus 4.7：xhigh
• そのほかの、effortに対応するモデル：high

公式ドキュメントでは、effortを下げると、簡単な作業では速く、安く済むと説明されています。一方で、複雑な作業では質が下がる可能性があるとも書かれています。設定のしかたは次のとおりです。

プロンプトにultrathinkと書くと、その1回だけ深く考えさせられます。反対に、いつもは低めにしておいて、難しい場面だけ上げる使い方もできます。

fast modeは、同じモデルを速く動かす設定

「fast mode」は、Opusを高速な構成で動かす設定です。公式ドキュメントでは、品質は同じまま、最大で2.5倍速くなる代わりに、トークンあたりの料金が高くなると説明されています。別のモデルではなく、同じOpusの設定を変えるだけです。「/fast」でオン・オフを切り替え、オンの間は入力欄の横に↯の印が出ます。

公式ドキュメントでは、fast modeとeffortは「どちらも応答の速さに関わるが、別の仕組み」と整理されています。fast modeは品質を保ったまま遅延を下げる設定、effortを下げる方は考える時間を減らす設定で、簡単な作業では、両方を組み合わせて最大の速さにできるとも説明されています。

思考そのものをオフにできるか

「思考をオフにして軽くする」方法もありますが、公式ドキュメントによると、Opus 5.5・Sonnet 5.5・Haiku 5.5・Fableのモデルでは、思考をオフにできません。これらのモデルでは、effortで調整します。思考の量を固定の上限で抑えるMAX_THINKING_TOKENSも、自動で配分するタイプのモデルでは効きません。「/effort」が選べるモデルは、まずeffortで調整すると考えてください。

読み込む設定や拡張を減らす

始めたときからずっと重い場合は、最初に読み込んでいるものが多すぎる可能性があります。Claude Codeは、最初のメッセージを送る前から、CLAUDE.md、スキルの説明、MCPサーバーのツール名などを読み込んでいます。これは毎回の依頼に付いてくる固定の荷物で、大きいほど、すべての依頼が重くなります。

「/context」で、何が場所を取っているか見る

まず「/context」を実行します。公式ドキュメントによると、システムのプロンプト、システムのツール、MCPのツール、サブエージェント、メモリのファイル、スキル、会話のメッセージというカテゴリごとに、文脈の使われ方が表示されます。何が大きいのかを見てから対策を選ぶと、無駄な作業をせずに済みます。

見直す対象と、確認に使うコマンドは次のとおりです。

CLAUDE.mdを短く保つ方法や、スキルに移す考え方は、「Claude Codeのトークンを節約する方法」と「CLAUDE.mdとは？」の記事で詳しく扱っています。

MCPサーバーは、起動と待ち時間に注意する

MCPサーバーは、外部のサービスとつなぐための仕組みです。公式ドキュメントでは、MCPサーバーはバックグラウンドで接続され、まだ接続中のサーバーのツールが必要になると、Claudeがその接続を待つと説明されています。遅さに関わる点は次のとおりです。

• ツールの定義は、既定では後回しにされる：最初に読み込まれるのはツール名だけで、詳しい内容は使うときに読まれます。最初に読み込まれる量は抑えられています。それでも、使わないサーバーは「/mcp」で無効にしておくのが基本です。
• 起動の待ち時間：サーバーの起動にかかる時間の上限は、環境変数MCP_TIMEOUTで指定できます（公式ドキュメントの例は、MCP_TIMEOUT=10000 claudeで10秒）。
• 長く動く呼び出し：メインの会話で、MCPのツール呼び出しが2分を超えると、バックグラウンドの作業に移り、Claudeは別の作業を続けられます。進み具合は「/tasks」で見られます。
• 出力が大きいとき：MCPツールの出力が1万トークンを超えると警告が出ます。出力の上限は、既定で2万5千トークンです。

どのMCPサーバーが原因かが分からないときは、次の「切り分け」の手順で、設定を無効にした状態と比べます。

設定を無効にして、原因を切り分ける

フックやプラグイン、MCPサーバー、CLAUDE.mdのどれが遅さの原因なのかは、見ただけでは分かりません。公式ドキュメントでは、まずclaude --safe-modeで起動して比べる方法が案内されています。セーフモードでは、次のものが無効になります。

1. セーフモードで起動するターミナルでclaude --safe-modeを実行し、遅かった作業と同じことを試します。
2. 変わらないか、軽くなるかを見る軽くなるなら、原因は自分で入れた設定や拡張のどれかです。変わらないなら、会話の長さ、モデル、混雑、パソコン側を疑います。
3. 候補を1つずつ戻す「/mcp」「/hooks」「/plugin」で、無効にしたものを1つずつ有効にして、どれで重くなるかを確かめます。
4. それでも分からないとき新しい空のフォルダで、設定フォルダを別の場所に指定して起動する方法も、公式ドキュメントに載っています（CLAUDE_CONFIG_DIRと--setting-sources userを使う）。

会社から配られた設定（管理設定）のうち、フックや設定の方針は、セーフモードでも適用されたままです（管理設定のプラグイン・スキル・CLAUDE.md・MCPサーバーは無効になります）。会社のパソコンで遅い場合は、情報システムの担当者に、管理設定の中身を確認してもらいましょう。

混雑・通信・タイムアウト

自分の側を見直しても改善しないときは、サービス側の混雑や、通信の遅れが原因かもしれません。公式のエラー一覧には、遅さに関わる表示が整理されています。

529 Overloaded（混み合っている）

API Error: Repeated 529 Overloaded errorsと表示される場合は、APIが一時的に容量いっぱいになっている状態です。公式ドキュメントでは、次のように説明されています。

• 使用量の上限とは別で、あなたの使用量には数えられない
• Claude Codeが自動で、最大10回まで、間隔を空けながら再試行する（回数はCLAUDE_CODE_MAX_RETRIESで変えられる）
• 再試行中は「Retrying in Ns · attempt x/y」と表示される

対処は、公式の状況ページ（status.claude.com）を確認し、数分待ってからやり直すことです。容量はモデルごとに管理されているため、「/model」で別のモデルに切り替えると進む場合があるとも書かれています。たとえば、Opusが混んでいるときにSonnetに切り替える、という使い方です。ただし、切り替えるとキャッシュが使えなくなる点は、先ほどの表のとおりです。

5xx（サーバー側の一時的な不具合）

API Error: 500 Internal server errorのような表示は、サーバー側で起きた予期しない不具合です。公式ドキュメントでは、依頼の内容や設定、アカウントのせいではなく、たいてい一時的とされています。状況ページを確認し、1分ほど待ってから、「try again」のように短く送り直せば、長い依頼を貼り直す必要はありません。長く続いて、状況ページにも障害の掲載がないときは、「/feedback」で報告します。

Request timed out・No response from API

応答が期限までに返らないときに出る表示です。公式ドキュメントによると、リクエストの期限の初期値は10分（API_TIMEOUT_MS、600000）です。混み合っているときや、非常に大きな出力を作っているときに起きることがあります。

通信が遅いネットワークやプロキシ（社内の中継サーバー）を通している場合は、期限を延ばせます。設定ファイル（~/.claude/settings.json）のenvに書く例が、公式ドキュメントに載っています。

{ "env": { "API_TIMEOUT_MS": "1200000" } }

ストリーミングの依頼では、最初の応答が一定時間来ないと中断して、1回だけ再試行する仕組みもあります。API Error: No response from APIと表示されたときです。プロキシが応答をまとめて返す構成の場合は、API_TIMEOUT_MSを延ばします。

通信が原因のとき

「Waiting for API response · will retry in … · check your network」と表示されることがあります。公式ドキュメントでは、20秒間、データが届かないときに出る表示で、まだ失敗とは確定していない状態です。毎回この表示が出る場合は、通信の問題として扱うよう案内されています。

• 社内ネットワークやVPN、プロキシを通している場合は、別の回線（スマートフォンのテザリングなど）で試して、違いを確かめる
• 通信を中継する仕組みがあるときは、情報システムの担当者に、Anthropicへの通信が遮断・遅延していないかを確認してもらう

コマンドの実行が長いとき

テストやビルドなど、Claudeが実行するコマンドそのものが長い場合もあります。公式ドキュメントによると、コマンドの待ち時間の既定は2分（BASH_DEFAULT_TIMEOUT_MS）、Claudeが指定できる上限は10分（BASH_MAX_TIMEOUT_MS）です。コマンドが長いのは、Claude Codeの遅さではなく、実行している処理の遅さです。まずそのコマンドを、自分のターミナルで単独で実行して、どれだけかかるかを確かめます。

パソコン・画面側が重いとき

返事そのものは来ているのに、画面が重い、ちらつく、固まるという場合は、パソコンやターミナル側の問題です。公式ドキュメントの「Performance and stability」の内容を中心に、症状別に紹介します。

CPUやメモリの使用量が高いとき

Claude Codeは、大きなコードベースを扱うと、多くのリソースを使うことがあります。公式ドキュメントでは、次の4つが案内されています。

1. 「/compact」を定期的に実行する会話を要約して小さくします。「Not enough messages to compact.」と出る場合は、会話のやりとりが少なすぎて要約できない状態です。大きなものを1回貼り付けて枠を埋めた場合にも起こります。
2. 大きな作業の合間に、再起動するClaude Codeを閉じて、開き直します。
3. ビルドの出力フォルダを.gitignoreに入れる大量のファイルが対象になるのを避けます。
4. claude --safe-modeで起動して比べるプラグイン・MCPサーバー・フックのどれかが原因かを切り分けます。

セッションのメモリ（ヒープ）が2.5GBを超えると、メモリ使用量が危険な水準であるという警告が出ます。公式ドキュメントでは、Claude Codeを再起動して、claude --continueで会話を新しいプロセスで再開すると、メモリを解放できると案内されています。

それでもメモリが減らないときは、「/heapdump」を実行します。メモリの内訳を、デスクトップにファイルとして書き出す診断用のコマンドで、コマンドメニューには表示されないため、全体を入力します。

固まって反応しないとき

反応がなくなったら、まずCtrl+Cで、いまの操作を取り消してみます。それでも反応がなければ、ターミナルを閉じて、開き直します。公式ドキュメントによると、再起動しても会話は失われません。同じフォルダでclaude --resumeを実行すると、続きから再開できます。

フルスクリーン表示に切り替える

画面のちらつきや、スクロール位置が飛ぶ症状には、「フルスクリーン表示」が有効な場合があります。公式ドキュメントでは、ちらつきをなくし、長い会話でもメモリの使用量を一定に保つ描画方式と説明されています。見えているメッセージだけを描くため、ターミナルへ送るデータが減ります。

• 切り替え：会話の中で/tui fullscreenを実行します。会話は保たれたまま、再起動して切り替わります。
• 戻す：/tui defaultで、従来の表示に戻ります。/tuiだけを実行すると、いまどちらかが表示されます。
• 効果が出やすい環境：VS Codeの統合ターミナル、tmux、iTerm2など、描画の処理が追いつかないターミナルです。
• 注意：研究プレビューの機能で、マウスの操作がClaude Codeに取り込まれるため、ターミナル標準のコピー操作が変わります。

環境によっては、最初からフルスクリーン表示になっています。「入力欄が動かず、画面の下に固定されている」なら、フルスクリーン表示が有効です。

文字が崩れる、古い表示が残る

画面の崩れは、描画の問題で、遅さとは別の対処になります。

非常に大きな表（200行を超えるMarkdownの表）は、最初の200行だけが画面に表示されます。全体が必要なときは、Claudeに「ファイルに書き出して」と頼むと、読みやすくなります。

WSLで、検索が遅い・件数が少ない

Windows上のWSL（WindowsでLinuxを動かす仕組み）でClaude Codeを使うと、ファイルの検索が遅くなったり、見つかる件数が少なくなったりすることがあります。公式ドキュメントでは、WSLでWindows側のファイルシステムをまたいでアクセスすると、読み込みの性能が落ちるためと説明されています。claude doctorの検索の項目は「OK」と表示されるため、気づきにくい点に注意が必要です。

Globツール（ファイルを探す機能）の待ち時間は、既定で20秒、WSLでは60秒です（CLAUDE_CODE_GLOB_TIMEOUT_SECONDS）。検索が見つからない原因が、同梱の検索ツール（ripgrep）が動かないことの場合は、パソコンにripgrepを入れて、USE_BUILTIN_RIPGREPを0にする方法が案内されています。Windowsではwinget install BurntSushi.ripgrep.MSVCで入れられます。

順番に試す手順

ここまでの内容を、実際に遅いと感じたときに試す順番にまとめます。上から順に、手間が小さく、効果が大きそうなものを並べています。

1. 動いているかを見るスピナーの横の経過時間とトークン数が増えていれば、書いている最中です。出力が始まらないなら、待つか、Escで止めて送り直します。
2. 「Retrying」などの表示を読む529や5xx、タイムアウトの表示なら、状況ページを確認して、待つか、別のモデルに切り替えます。
3. 会話の長さを見直す別の作業に移るなら「/clear」、続けるなら作業の切れ目で「/compact」します。同じ指摘を2回しても直らないなら、「/clear」して依頼を書き直します。
4. モデルとeffortを、作業に合わせる簡単な作業は低いeffortやSonnet・Haikuで試します。会話の途中では切り替えないようにします。
5. 「/context」で最初の読み込みを見る大きいものを、CLAUDE.md、スキル、MCPの順に見直します。
6. セーフモードで比べる軽くなるなら、拡張を1つずつ戻して、原因を特定します。
7. パソコン側を見るメモリ警告が出ているなら再開、画面の崩れならフルスクリーン表示や描画の設定、WSLなら保存場所を見直します。

それでも直らないときは、「/feedback」で、症状を公式に報告できます。公式のGitHubのリポジトリで、既知の問題を確かめる方法もあります。

相談を受けたときに、確認すること

社内で「Claude Codeが遅い」と相談されたとき、いきなり設定を触る前に、次の情報をそろえると、原因の絞り込みが速くなります。

バージョンによる違いの例として、公式ドキュメントには、v2.1.208より前は、非常に大きな表を含む会話を再開すると、描画し直しで止まることがあったと書かれています。バージョンを確かめておくと、公式のドキュメントの記述と照らし合わせやすくなります。更新の方法は「Claude Codeのアップデート方法」の記事で解説しています。

よくある質問

まとめ

遅さの原因は、設定の積み重ねや、使っているネットワーク、パソコンの環境にまたがることが多く、1人で調べると時間がかかります。数値で「何％速くなる」と示されていない対処が多いため、変更を1つずつ試して、効果を確かめながら進めることが大切です。

INTERCREATE JAPANでは、Claude CodeやCodexを社内で使い続けるための、環境の整備や使い方のルールづくりをお手伝いしています。社内で動きが重い、使い方が人によってばらつく、といった場合にご相談ください。