Claude Codeが遅いと感じたら見る場所——公式ドキュメントの対処法を「原因の階層」で整理した

Home / Blog / Claude Codeが遅いと感じたら見る場所——公式ドキュメントの対処法を「原因の階層」で整理した

Claude Codeの応答が遅い・重いと感じたときの切り分け方を解説。/compact・--safe-mode・/heapdumpなど公式の診断コマンドと、WSL特有の検索遅延、コミュニティで報告されている実運用の落とし穴までまとめた。

エンジニアのゆとです。

「Claude Code 遅い」というキーワードでの検索が地味に多い。実際に自分の観測範囲でも、Xやコミュニティで「今日のClaude Code、なんか鈍くない？」という話題は定期的に流れてくる。

厄介なのは、「遅い」の中に原因の全く違う複数の症状が混ざっていることだ。API応答自体が遅いのか、手元のマシンが重いのか、検索が遅いのか——これを切り分けずに「メモリを増やす」「再起動する」を順番に試していくと、時間だけ溶けて終わる。この記事は公式ドキュメントの診断手順を軸に、原因を階層ごとに整理した。

結論 — まず「どこが遅いか」を切り分ける

「遅い」と感じたら、まず次の4つのどれに当てはまるか考えてみてほしい。

応答そのものが遅い（入力してから返ってくるまでの時間） → コンテキストサイズ・モデル・API側の要因
操作全体が重い（CPU/メモリ使用率が高い、他のアプリも重くなる） → ローカルリソース不足、プラグイン/MCP/hookの負荷
検索・ファイル探索が遅い（@file補完やSearchツールが遅い） → ripgrepの不備、WSLのファイルシステム越えアクセス
ネットワーク越しの通信が遅い → プロキシ・回線・地理的距離

公式ドキュメントは主に1〜3をカバーしている。順番に見ていく。

code.claude.com

Troubleshooting - Claude Code Docs 高CPU/メモリ使用、フリーズ、auto-compactの暴走、検索の不具合など、実行中のパフォーマンス・安定性問題をまとめた公式ページ。

原因1: コンテキストが肥大化している

セッションを長く続けていると、会話履歴やファイル読み込みの蓄積でコンテキストウィンドウが埋まっていき、それに比例して応答が重くなる。これが「遅い」の最も一般的な原因だ。

対処は/compactでコンテキストを要約・圧縮すること。

/compact

Not enough messages to compact.と返ってくることがあるが、これは会話のターン数が少なすぎて要約できないという意味で、大きな1回のペーストだけでコンテキストが埋まった場合にも起こり得る。

さらに、コンテキストが圧縮直後にまた即座に埋まってしまう「auto-compact thrashing（自動圧縮の暴走）」という症状もある。Autocompact is thrashing: the context refilled to the limit...というメッセージが出たら、無駄なAPI呼び出しを避けるためにClaude Code側がリトライを止めているサインだ。この場合は次のいずれかで対処する。

巨大なファイルを一括で読ませず、範囲を指定して部分的に読ませる
/compactにフォーカスを指定する（例: /compact keep only the plan and the diff）
巨大なファイルの処理はサブエージェントに切り出して、別のコンテキストウィンドウで処理させる
不要な会話が残っているなら/clearで仕切り直す

逆に「auto-compactがそもそも発動しない」という症状に心当たりがあるなら、暴走ではなく別の原因の可能性が高い。auto-compactが動かない・止まる原因を症状別に整理した記事にサードパーティAPI経由のケースなどをまとめている。

1Mトークンコンテキストを使っている場合でも、「使える」ことと「使い切っても快適」なことは別問題だ。3層管理での運用に分けたほうが結果的に速い。

原因2: プラグイン・MCP・hookが裏で負荷をかけている

Claude Code自体ではなく、拡張機能側が原因で重くなっているケースもある。これを切り分けるための公式コマンドが--safe-modeだ。

claude --safe-mode

このモードでは、そのセッション中プラグイン・MCPサーバー・hookをすべて無効化した状態で起動する。これで体感速度が改善するなら、原因はどれかの拡張にある。特定するには設定のデバッグガイドの手順で1つずつ切り分けていく。

MCPサーバーを大量に接続していると、それだけでレスポンス生成のたびに余分なオーバーヘッドがかかる。使っていないMCPサーバーは/mcpで状態を確認し、思い切って外すのも効果がある。

Apr 13, 2026 Claude Code × MCP で個人開発を自動化した実践構成と月額コストの話Claude CodeとMCPを組み合わせた個人開発の自動化構成を公開。Filesystem・GitHub・Brave Search・自作MCPの実践的な設定、月額コストの実績、PromptCachingによる節約テクニック、MCPが合う場面・合わない場面の整理。読む →

それでも高CPU・高メモリが続く場合は、メモリの中身を実際に見る手段も用意されている。

/heapdump

このコマンドは~/Desktop（Linuxでデスクトップフォルダがない場合はホームディレクトリ）に、JSヒープのスナップショットと診断用JSONファイルの2つを書き出す。ヒープスナップショットには会話内容や認証情報がそのまま含まれるので、公開のIssueに添付しないよう公式ドキュメントでも明確に警告されている。GitHubに報告する場合は、統計情報だけが入った-diagnostics.jsonの方だけを添付するのが安全だ。

原因3: 検索が遅い（WSL環境特有の落とし穴）

@fileメンションやSearchツール、カスタムSkillが遅い、あるいは見つかるはずのファイルが見つからない場合、まず疑うべきはバンドルされているripgrepバイナリが自分の環境で正しく動いていないケースだ。claude doctorを実行して、Searchの行がOK (bundled)ではなく、システム側のripgrepパスを指しているか確認するとよい。

システムのripgrepを別途インストールして使わせることもできる。

# Ubuntu/Debian
sudo apt install ripgrep

# macOS
brew install ripgrep

インストール後、設定で切り替える。

{
  "env": {
    "USE_BUILTIN_RIPGREP": "0"
  }
}

もう1つ、WSL（Windows Subsystem for Linux）を使っている場合特有の問題がある。プロジェクトがWindows側のファイルシステム（/mnt/c/配下）に置かれていると、WSLからのディスク読み取りにペナルティがかかり、検索結果が本来より少なく返ってくることがある。claude doctorではSearchが正常（OK）と表示されるため、気づきにくい落とし穴だ。

対処法は3つ。

検索範囲を絞った具体的な指示を出す（例:「auth-serviceパッケージ内のJWT検証ロジックを検索して」）
プロジェクトをWindows側（/mnt/c/）ではなく、Linux側のファイルシステム（/home/配下）に移す
WSL経由ではなくWindowsネイティブ版のClaude Codeを使う

WSL固有の挙動については、Windows環境全体の比較記事でも詳しく触れている。

May 31, 2026 Claude Code Windows完全ガイド 2026 — WSL・Git Bash・PowerShell徹底比較Claude CodeをWindowsで使う3つの方法（WSL/Git Bash/PowerShell）を徹底解説。インストール手順・パフォーマンス比較・トラブルシュート・各環境の使い分けを2026年最新情報で網羅。読む →

原因4: フリーズと「遅い」の違い

ここまでは「遅いが動いている」状態の話だった。完全に無反応になった場合はまた別の切り分けが必要になる。Ctrl+Cでキャンセルを試し、それでも反応がなければターミナルを閉じてclaude --resumeで同じディレクトリからセッションを再開すれば会話は失われない。

頻繁にフリーズや幻聴のような挙動が起きる場合は、単なる「遅さ」ではなくメモリ・スワップの実測データに基づいた別の切り分けが必要になるので、そちらの記事も参考にしてほしい。

Jul 1, 2026 Claude Codeが突然バグる本当の理由を、実測データで特定したClaude Codeがフリーズ・幻聴・生ログ吐き出しを起こす原因を実測データで解剖。空きメモリ103MB・スワップ2700万回の計測結果、コンテキスト自己中毒（self-poisoning）の仕組み、前兆3段階サイン、セッション引き継ぎ手順まで。読む →

コミュニティで報告されている運用上の要因

公式ドキュメントには載っていないが、実運用のレポートとしてよく見かける要因もいくつか触れておく。あくまで個別事例であり、全員に当てはまるわけではない前提で読んでほしい。

effortを常時highにしない。深く考えさせるほど生成トークン数が増え、体感速度は落ちる。詰まったときだけ引き上げる運用のほうがバランスがいい
サブエージェントが毎回同じWeb検索を叩く設計になっていないか確認する。動的に情報を取りに行く設計は、静的な情報として一度保存してCLAUDE.mdや参照ファイルから読ませる設計に比べて、速度・トークン消費の両面で不利になりやすい
常駐系のプラグインやバックグラウンドプロセスが裏で落ちている。特定のプラグインを使っている環境で「数分おきに裏方のプロセスが静かに終了していた」という報告もあり、これは--safe-modeでの切り分けで見つけやすい

effortレベルの使い分けについては、Effort Level完全ガイドにまとめてある。

FAQ

昨日まで速かったのに、今日だけ急に遅い

セッション固有の問題ではなく、Anthropic側のサービス状態が理由のこともある。まずステータスページを確認し、大規模な障害情報が出ていないか見るのが早い。過去にも529エラーなど、サービス側の過負荷でレスポンスが遅延・失敗するケースが報告されている。

`/compact`しても速くならない

コンテキストサイズが原因ではない可能性が高い。--safe-modeでMCP・プラグイン・hookを切り分けるか、検索が絡む操作ならripgrepの設定を確認する、という順番で見ていくのが早い。

VS Code拡張機能だと特に遅い気がする

統合ターミナル経由での実行はエディタ本体のリソースを共有するため、単体のターミナルアプリより重くなりやすい。恒常的に重いと感じるなら、単体のターミナル（Kitty・iTerm2・WezTermなど）からclaudeコマンドで直接起動する運用と比較してみるとよい。

まとめ

「遅い」は原因が1つに定まらない言葉だ。コンテキストの肥大化なのか、拡張機能の負荷なのか、検索の設定不備なのか、それともサービス側の問題なのか——公式ドキュメントに用意されている/compact・--safe-mode・/heapdump・claude doctorは、いずれもこの切り分けのための道具として設計されている。

闇雲に再起動やアンインストールを試す前に、まずどの階層で遅いのかを特定するところから始めたほうが、結果的に早く解決する。