ホーム / チュートリアル / Claude Code が重い・検索が効かないときの対処

Claude Code が重い・検索が効かないときの対処

Claude Code エンジニアリング 7分で読めます

Claude Code を使っていて、CPU やメモリの使用量が跳ね上がる、応答が返ってこない、Search がファイルを見つけられない。こうした「起動はしているのに調子が悪い」類の問題は、公式ドキュメントの Troubleshooting ページに切り分けの手順がまとまっています。本記事はその内容を日本語で解説します。

なお、インストールできない・ログインできないといった起動前の問題は別のページの担当です。この記事が扱うのは、Claude Code が動いている状態での性能・安定性・検索の問題だけです。

まず /doctor を実行する

症状の見当がつかないときは、まず Claude Code の中で /doctor を実行します。インストール状態・設定・拡張機能・コンテキストの使用量を自動で点検し、適用できる修正があれば確認のうえ提案してくれます。

# Claude Code のセッション内で実行する
/doctor

claude がそもそも起動しない場合は、セッション内のスラッシュコマンドは使えません。シェルから claude doctor を実行してください。

# Claude Code が起動しないときはシェルから
claude doctor

MCP サーバーの状態だけを見たいときは /mcp を実行します。

症状から担当ページを切り分ける目安は次のとおりです。

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

Claude Code はたいていの開発環境で動くように作られていますが、大きなコードベースを扱うとリソースを多く使うことがあります。次の順に試します。

  1. /compact をこまめに実行してコンテキストを小さくする。Not enough messages to compact. が返る場合は、要約するだけのやり取りがまだ無いという意味です。1回の大きな貼り付けでコンテキストが埋まったときは、コンテキストが満杯でもこの表示になります
  2. 大きな作業の区切りで Claude Code を終了して起動し直す
  3. 大きなビルド用ディレクトリを .gitignore に追加する
  4. claude --safe-mode で起動し直して、プラグイン・MCP サーバー・フックのどれかが原因かを確かめる。このモードはそのセッションのカスタマイズをすべて無効にします。使用量が下がったなら、どれが原因かを設定のデバッグ手順で絞り込みます

ここまでやってもメモリ使用量が高いままなら、/heapdump を実行します。~/Desktop に2つのファイルが書き出されます。JavaScript のヒープスナップショット <session-id>.heapsnapshot と、メモリの内訳 <session-id>-diagnostics.json です。Linux で Desktop フォルダが無い場合はホームディレクトリに書かれます。

このコマンドはコマンドメニューに出てこないので、名前を最後まで入力してください。

# メモリの内訳とヒープスナップショットを書き出す
/heapdump

注意: .heapsnapshot にはプロセス内のすべての文字列が入ります。会話の全文や資格情報も含まれます。公開の Issue に添付したり共有したりしないでください。

コマンドは会話にも要約を表示します。RSS（実メモリ使用量）、JS ヒープ、ArrayBuffer、内訳不明のネイティブメモリに加えて、メモリ増加率が高い・開いているハンドルが異常に多いといった漏れの兆候が出ます。要約には、メモリの大半が JS ヒープ側（スナップショットに写る）なのか、ネイティブ側（写らない）なのかも書かれます。

出力の使い道は2つです。

要約が「大半はネイティブメモリ」と言っている場合、スナップショットには写りません。その場合は要約に出た漏れの兆候を報告に含めてください。

自動コンパクトが thrashing で止まるとき

Autocompact is thrashing: the context refilled to the limit... というエラーで自動コンパクトが止まることがあります。これは、自動コンパクト自体は成功したのに、直後のファイル読み込みやツール出力がコンテキストを何度も上限まで埋め戻した、という状態です。進んでいないループに API 呼び出しを費やさないよう、Claude Code は再試行をやめます。

復帰の手順は次の4つです。

  1. 大きすぎるファイルを丸ごとではなく小さく分けて読むよう Claude に指示する。行範囲や関数を指定します
  2. 大きな出力を落とす方向を指定して /compact を実行する。たとえば /compact keep only the plan and the diff のように書きます
  3. 大きなファイルを扱う作業をサブエージェントに移し、別のコンテキストウィンドウで動かす
  4. それ以前の会話がもう不要なら /clear を実行する
# 残すものを指定してコンパクトする
/compact keep only the plan and the diff

4つのうち、根本的に効くのは1と3です。2と4はその場を片付ける手当てなので、同じ大きなファイルをまた読ませると再発します。

応答が止まる・表示が崩れるとき

ここでは、固まる・表示が崩れる・スクロールが遅いといった対話中の問題をまとめます。

応答が止まる・固まる

  1. Ctrl+C を押して現在の操作の取り消しを試みる
  2. それでも反応しない場合は、ターミナルを閉じて起動し直す

再起動しても会話は失われません。同じディレクトリで claude --resume を実行すれば、そのセッションを再開できます。

# 同じディレクトリでセッションを再開する
claude --resume

エディタ内蔵ターミナルで文字が崩れる

VS Code・Cursor・Devin Desktop の内蔵ターミナルで、文字が四角や滲みや別のグリフになる場合、原因はターミナルの GPU レンダラーである可能性が高いです。Claude Code 内で /terminal-setup を実行すると terminal.integrated.gpuAcceleration が "off" に設定されます。エディタの設定で手動で変えてウィンドウを再読み込みしても構いません。

大きな表が途中で切れる

200行を超える Markdown の表は、先頭200行のあとに … N more rows not shown が出ます。制限されているのは表示だけで、表そのものは会話の中に残っており、/copy は全行をコピーします。ターミナルで読むには大きすぎる表は、ファイルに書き出すよう Claude に頼むほうが早いです。

ホイールが1行ずつしか動かない

フルスクリーン描画では、Claude Code がターミナルに任せず自分で会話をスクロールします。1ノッチあたりの行数を増やしたいときは /scroll-speed を実行して保存するか、CLAUDE_CODE_SCROLL_SPEED 環境変数を設定します。ただし JetBrains IDE のターミナルでは Claude Code が独自のスクロール処理を当てるため、どちらも効きません。

速度を変えずに速く動かしたいだけなら、PgUp と PgDn で半画面ずつスクロールできます。スクロールをターミナル本来のスクロールバックに戻したい場合は /tui default で従来の描画に切り替えます。

SSH 越しにコピーがローカルのクリップボードに届かない

Claude Code がリモートのマシンで動いているとき、手元のマシンのクリップボードツールを実行できません。tmux の外では、フルスクリーン描画でテキストを選択したり /copy を実行したりすると、Claude Code は OSC 52 エスケープシーケンスとしてターミナルへ送ります。クリップボードに入れるかどうかはターミナル側の判断です。/copy は届いたかどうかに関わらず Copied to clipboard と報告します。

OSC 52 を扱わないターミナルもあります。iTerm2 は Settings > General > Selection > Applications in terminal may access clipboard を有効にするまで無視し、macOS の Terminal.app は対応していません。

回避策は2つです。ターミナル本来の選択キー（Terminal.app は Fn、iTerm2 は Option）を押しながらドラッグして通常のショートカットでコピーするか、リモート側で CLAUDE_CODE_DISABLE_MOUSE=1 を設定してセッション全体の選択をターミナルに任せます。

サンドボックス内で pbcopy が失敗する

サンドボックスが有効なとき、pbcopy・xclip・wl-copy といったクリップボードのユーティリティは、サンドボックス内の Bash コマンドからシステムのクリップボードに届かないことがあります。Claude がテキストを渡してもクリップボードは変わりません。

Claude の出力をクリップボードに入れたいだけなら、応答として内容を表示させてから /copy を実行します。/copy はサンドボックス内のコマンドではなく Claude Code のプロセス自身から書き込むため、サンドボックスに止められません。コピーした内容をファイルにも書いてパスを表示するので、SSH 越しなどでクリップボードへの書き込みが届かないときの逃げ道にもなります。

パイプしたコマンドから直接クリップボードへ届かせたい場合は、pbcopy *・wl-copy *・xclip * を設定の excludedCommands に追加して、サンドボックスの外で実行させます。

Search がファイルを見つけられないとき

Search ツール・@file でのファイル指定・カスタムエージェント・カスタムスキルがファイルを見つけられない場合、同梱の ripgrep バイナリが環境で動いていない可能性があります。プラットフォームの ripgrep パッケージを入れて、Claude Code にそちらを使わせます。

# macOS
brew install ripgrep

# Ubuntu / Debian
sudo apt install ripgrep

# Alpine（community リポジトリにあります）
apk add ripgrep

# Arch
pacman -S ripgrep

# Windows
winget install BurntSushi.ripgrep.MSVC

そのうえで USE_BUILTIN_RIPGREP を 0 にします。シェルの環境変数でも、settings.json の env ブロックでも構いません。

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

切り替わったかどうかは、ターミナルで claude doctor を実行して確かめます。Search の行が OK (bundled) ではなく、システム側の ripgrep のパスを表示していれば成功です。

WSL で検索結果が少ない・遅い

WSL でファイルシステムをまたいで作業していると、ディスク読み込みの性能低下によって、期待より少ない件数しかヒットしないことがあります。検索自体は動きますが、ネイティブのファイルシステムより結果が少なくなります。この場合 claude doctor は Search を OK と表示するので、表示だけでは気づけません。

対処は3つあります。

  1. 検索を具体的にする: ディレクトリやファイル種別を指定して対象ファイル数を減らします。「auth-service パッケージの中で JWT 検証のロジックを探して」「JS ファイルの中で md5 ハッシュを使っている箇所を探して」のように書きます
  2. プロジェクトを Linux 側に移す: 可能なら /mnt/c/ ではなく /home/ 配下に置きます
  3. Windows ネイティブで動かす: WSL 経由をやめて Windows 上で直接 Claude Code を動かすほうが、ファイルシステムの性能は上がります

ここまでで解決しない場合は、/doctor と /mcp で状態を確認したうえで、/feedback コマンドで Anthropic に直接報告できます。既知の問題かどうかは GitHub リポジトリの Issue でも確認できます。

関連記事: /compact でコンテキストを管理する / サブエージェントを使う

本記事は Anthropic 公式ドキュメント「Troubleshooting」に基づく非公式の日本語解説です（確認日 2026-09-15）。仕様や手順は更新される場合があるため、実際の対処の前に公式ドキュメントをご確認ください。

関連チュートリアル / 次に読む

Claude Code の /compact でコンテキストを管理する Claude Code のサブエージェント活用法 Claude Codeの設定と権限を管理する Claude Code のサンドボックス環境を選ぶ
← チュートリアル一覧へ戻る カテゴリで探す