Claude Codeが遅い原因と対処7手順【2026年10月】

Q: モデルを切り替えると遅くなるのはなぜですか？

モデルごとに別のキャッシュを持っているためです。/model で切り替えると、内容がまったく同じでも次のリクエストは会話履歴全体をキャッシュなしで読みます。opusplan 設定はプランモード中がOpus、実行中がSonnetに解決されるので、プランモードの切り替えごとにモデル切替が発生します。セッションの頭でモデルを決めておくのが確実です。

Q: /compact と /rewind はどちらを使うべきですか？

進んだ道筋ごと捨てたいなら /rewind です。巻き戻しはすでにキャッシュ済みの地点まで切り詰めるだけなので、新しい前置きを作り直す圧縮より安く済みます。/compact は、要らなくなった内容を捨ててコンテキストを空けたいときに、タスクの切れ目で自分のタイミングで打つのが公式の推奨です。

Q: 529 Overloaded は自分の利用上限に当たったということですか？

違います。529 はAPI全体が一時的に容量上限にある状態で、あなたの利用上限ではなく、クォータも消費しません。容量はモデルごとに管理されているので、/model で別のモデルに切り替えれば作業を続けられることが多いです。継続する場合は status.claude.com で告知を確認してください。

Q: メモリ使用量が下がりません。調べる方法はありますか？

/compact、再起動、.gitignore への追加、claude --safe-mode を試しても高いままなら、/heapdump を実行します。~/Desktop にヒープスナップショットと診断JSONの2ファイルが書き出され、会話にも要約が表示されます。ただしスナップショット側には会話全文と認証情報を含む全文字列が入るため、公開の場に出してはいけません。報告するときは統計だけを含む -diagnostics.json のみを添付してください。

Claude Codeの遅さは起動・応答待ち・1ターンの長さ・検索の4症状に分かれます。/usage のキャッシュ行から始める切り分けの順番を、公式ドキュメントをもとに7手順で整理しました。

2026年9月20日時点の結論。Claude Codeの「遅い」はひとつの症状ではなく、起動が遅い・応答が始まらない・1ターンが長い・検索が返らないの4つに分かれる。見る場所がそれぞれ違うので、最初にどれなのかを決めると対処が一本に絞れる。実務でいちばん多いのは4つ目ではなく3つ目、つまりプロンプトキャッシュが毎ターン作り直されているケースで、これは /usage の1行で判定できる。

体感の遅さを「重いリポジトリだから仕方ない」で片づけると、直せるものまで直さないまま終わる。Anthropicの公式ドキュメントには、遅さの原因ごとに確認コマンドと設定項目が書かれている。以下はそれを切り分けの順番に並べ直したものだ。

この記事の要点

まず症状を4つに分ける：起動が遅い／応答が始まらない／1ターンが長い／検索が返らない。見る場所が違う。
一次切り分けは2コマンド：セッション内で /doctor、起動すらしないなら shell から claude doctor。カスタマイズが原因かは claude --safe-mode で切り分ける。
最頻の原因はキャッシュの作り直し：/usage の Prompt cache (main) 行でヒット率・ミス回数・いまキャッシュが温かいかが見える（Claude Code v2.1.251以降）。
キャッシュを壊す操作は決まっている：モデル切替、effortの変更、fast modeのオン、MCPサーバーの接続／切断、プラグインの有効化／無効化、ツール全体の拒否、圧縮、画像の蓄積、バージョン更新。
捨てる前に戻す：/compact は新しい前置きを作り直すが、/rewind はすでにキャッシュ済みの地点まで切り戻すので安い。
検索が遅いのはripgrepかWSL：USE_BUILTIN_RIPGREP を 0 にする、プロジェクトを /home/ 側に移す。
API側で待っているだけのこともある：20秒無反応で出る待機バナー、429／529 の扱い、リトライ回数の環境変数。
対象読者：Claude CodeをCLIまたはIDEで日常的に使っている開発者、開発環境の標準化担当、チームリード。
今日やること：/usage を開いて Prompt cache (main) 行のヒット率を1回だけ見る。

手順1｜「遅い」を4つの症状に分けて、見る場所を決める

「Claude Codeが遅い」と言うとき、実際には次の4つのどれかを指していることがほとんどだ。原因のレイヤーが違うので、まずどれなのかを決める。

4症状と、それぞれ最初に見る場所

症状	具体的に起きていること	最初に見る場所
起動が遅い	`claude` を叩いてからプロンプトが出るまで待つ	shell から `claude doctor`
応答が始まらない	送信したのにスピナーが回り続ける	待機バナーとリトライ表示
1ターンが長い	応答は返るが毎回もたつく	`/usage` のキャッシュ行
検索が返らない	ファイル検索や `@file` が見つけてくれない	`claude doctor` のSearch行

1回の調査では1症状だけを追う

この4つは互いに独立している。たとえばキャッシュのヒット率が落ちていても検索の速さには影響しないし、逆にripgrepが動いていなくてもAPIの応答時間は変わらない。混ぜて調べると「あれもこれも怪しい」で止まるので、1回の調査では1症状だけを追う。

なお、Anthropicの公式トラブルシューティングは「どこで詰まっているか」でページを分けている。インストール・PATH・TLS・ログイン系は別ページ、設定やフックやMCPが効いていない系はさらに別ページで、このページが扱うのは高CPU・高メモリ・応答の遅さ・ハング・検索の問題だと明記されている。自分の症状がどのページの管轄かを先に決めるのが、公式が想定している使い方だ。

手順2｜`/doctor` と `--safe-mode` で環境側をまず潰す

症状が決まったら、次は「Claude Code本体の外側」を疑う。ここで使うコマンドは2つだけだ。

/doctorから/mcp、claude --safe-mode、/heapdumpへと進む環境側の確認手順を左から右に並べた図 — 環境側を潰す確認コマンドの順番

`/doctor` と `claude doctor` の使い分け

セッションの中で /doctor を実行すると、インストール状態・設定・拡張機能・コンテキスト使用量を自動でチェックし、適用できる修正を提案してくれる。提案は確認したうえで適用される仕組みなので、勝手に環境が書き換わることはない。

claude がそもそも起動しない場合は、セッション内のスラッシュコマンドが使えない。このときは shell から claude doctor を実行する。MCPサーバーの状態だけを見たいなら /mcp が専用の確認口になる。

カスタマイズが原因かどうかは `--safe-mode` で決める

プラグイン、MCPサーバー、フックのどれかが重さの原因になっていることがある。切り分けは claude --safe-mode での再起動だ。このフラグはそのセッションのカスタマイズをすべて無効化する。ここでCPUやメモリの使用量が落ちるなら、原因はカスタマイズ側にあると確定できるので、あとは1つずつ戻して犯人を特定すればいい。

公式のトラブルシューティングは、高CPU・高メモリの対処として次の順番を挙げている。/compact をこまめに使ってコンテキストを減らす、大きなタスクの合間にClaude Codeを閉じて再起動する、大きなビルド用ディレクトリを .gitignore に入れる、そして claude --safe-mode で犯人を探す。

それでもメモリが高いままなら `/heapdump`

上記をやってもメモリ使用量が高いままの場合、/heapdump を実行すると2つのファイルが ~/Desktop に書き出される。JavaScriptヒープのスナップショット（<session-id>.heapsnapshot）と、メモリの内訳（<session-id>-diagnostics.json）だ。このコマンドはコマンドメニューには表示されないので、自分で全文を打ち込む必要がある。LinuxでDesktopフォルダがない環境ではホームディレクトリに書かれる。

ここで注意が要る。.heapsnapshot にはプロセス内の全文字列、つまり会話の全文と認証情報が含まれる。公開のIssueに添付したり共有したりしてはいけない。Anthropicに報告する場合は、統計情報だけを持ち会話内容も認証情報も含まない -diagnostics.json の方だけを添付する、と公式が明示している。

手順3｜プロンプトキャッシュのヒット率を見る

1ターンが長いタイプの遅さは、ほぼここで説明がつく。Claude Codeは毎ターン、システムプロンプト・プロジェクトコンテキスト・これまでの全会話を毎回APIに送り直している。モデルはリクエスト間で何も覚えていないからだ。そのうち「前回と同じ先頭部分」を再処理せずに済ませる仕組みがプロンプトキャッシュで、ここが効いているかどうかで1ターンの体感速度が変わる。

cache_creation_input_tokensが高い状態とcache_read_input_tokensが高い状態を左右に並べて比べた図 — 書き込みが多い状態と読み出しが多い状態

判定は `/usage` の1行でできる

公式のプロンプトキャッシュ解説によれば、Claude Code v2.1.251以降、/usage のSessionブロックに Prompt cache (main) という行が追加された。ここにそのセッションのヒット率、ミス回数、そしていまキャッシュが温かいかどうかが出る。v2.1.260以降は、直近のミスについて原因を特定できた場合に likely cause: tool definitions changed のような推定原因も併記される。

ステータスラインからも同じ数値が読める。APIはレスポンスごとに2つのトークン数を返していて、意味はプロンプトキャッシュの仕様のとおりだ。

フィールド	意味
`cache_creation_input_tokens`	そのターンでキャッシュに書き込まれたトークン。キャッシュ書き込みの料金で課金される
`cache_read_input_tokens`	そのターンでキャッシュから読み出されたトークン。標準の入力料金のおよそ10%で課金される

読み出しが書き込みより大きい状態が続いていれば、キャッシュは正常に効いている。書き込みが毎ターン高いままなら、前置き（プレフィックス）のどこかが毎回変わっている。

なぜ「どこか1か所」で全部が無効になるのか

キャッシュの照合はリクエストの先頭からの完全一致で行われる。ファイル単位やセグメント単位のキャッシュは存在しないので、前置きのどこか1か所が変わると、そこから後ろが全部再計算になる。

Claude Codeはこれを踏まえて、変わりにくいものが先に来るようリクエストを並べている。

レイヤー	中身	変わるタイミング
システムプロンプト	中核の指示、ツール定義	読み込まれているツール定義の集合が変わったとき
プロジェクトコンテキスト	CLAUDE.md、auto memory、スコープなしのrules	セッション開始時、`/clear` または `/compact` の後
会話	あなたのメッセージ、Claudeの応答、ツール結果	毎ターン

会話レイヤーの変化はシステムプロンプトとプロジェクトコンテキストのキャッシュを壊さない。逆に、システムプロンプトが変わると後ろが全部別の前置きになるので、すべてが無効化される。トークン使用量の読み方そのものはトークン使用量の確認とキャッシュ節約で詳しく扱っている。

手順4｜キャッシュを毎ターン壊している操作をやめる

前置きを壊す操作は公式ドキュメントに列挙されている。どれも「やった直後の1ターンだけ遅くて高い」という形で現れ、その後は新しい前置きがキャッシュされる。問題は、これを無自覚に何度も繰り返している場合だ。

モデル切替やeffort変更などキャッシュを壊す6つの操作が、いずれも会話履歴全体のノーヒットに行き着くことを示した図 — 前置きを壊す操作は同じ結果に行き着く

キャッシュを無効化する操作

モデルの切り替え：モデルごとに別のキャッシュを持つ。/model で切り替えると、内容が同一でも会話履歴全体がノーヒットで読み直される。opusplan 設定はプランモード中はOpus、実行中はSonnetに解決されるため、プランモードを切り替えるたびにモデル切替が発生する。
effort（思考量）の変更：多くのモデルでは各effortレベルが別キャッシュを持つ。ただしFable 5.1をAPIキーまたはClaudeサブスクリプションで使っている場合は、既定でキャッシュが維持される（v2.1.260以降）。
fast modeのオン：リクエストヘッダーがキャッシュキーの一部なので、オンにして最初のリクエストが全文読み直しになる。コストは会話あたり1回だけで、セッション開始時にオンにするほど安い。
MCPサーバーの接続／切断：ツール定義がシステムプロンプト層にあるため。ただしツールサーチが有効な既定構成では、ツール定義が前置きに載らないので影響しない。
プラグインの有効化／無効化、ツール名そのものの拒否（Bash のようなベア名をdenyに入れる）。
圧縮（/compact）、画像の蓄積、Claude Code本体のバージョン更新。

逆に、壊さない操作

リポジトリのファイル編集、セッション途中のCLAUDE.md編集、パーミッションモードの変更、出力スタイルの変更、スキルやコマンドの実行、/recap、/rewind はキャッシュを維持する。CLAUDE.mdの編集がキャッシュを壊さないのは、その変更が /clear・/compact・再起動まで実行中のセッションに届かないからでもある。CLAUDE.mdの設計そのものはコンテキストの新ルールとCLAUDE.md実践で扱っている。

実務上の結論

公式のTipは明快で、「モデルとeffortはセッションの頭で決め、/compact は作業の切れ目まで取っておく。タスクの途中で変更を減らすほどヒット率は上がる」とある。モデル切替は操作としては無料に見えるが、その後の1ターンが遅くなるという形でコストを払っている。

キャッシュの寿命は5分か1時間

キャッシュは無操作が続くと期限切れになる。公式の仕様ではTTLは5分と1時間の2種類があり、Claude Codeはリクエストごとに決めている。既定値は課金形態で変わる。

リクエストの種類	Claudeサブスクリプション（プラン内利用）	従量クレジット・APIキー・クラウドプロバイダー
メインの会話	1時間	5分
それ以外（サブエージェント、ワークフロー、圧縮など）	5分（サーバー側制御の一部ヘルパーのみ1時間）	5分

「昼休みから戻った最初の1ターンだけ遅い」はこれが原因だ。APIキーやクラウドプロバイダー経由で使っていて、離席をはさむ働き方なら、promptCacheTtl 設定または CLAUDE_CODE_PROMPT_CACHE_TTL 環境変数に 1h を指定する手がある（どちらもv2.1.242以降）。サブエージェント側は subagentPromptCacheTtl または CLAUDE_CODE_SUBAGENT_PROMPT_CACHE_TTL で別に指定する。

もうひとつ知っておくと事故が減るのが、キャッシュの有効範囲だ。Claude Codeのキャッシュは実質「1台のマシンの1ディレクトリ」に閉じている。会話が作業ディレクトリ・プラットフォーム・シェル・OSバージョンを持ち回るためで、同じリポジトリのworktree同士でも別のディレクトリなので互いのキャッシュを読まない。worktreeを増やすほど温まるまでの時間が増える、という形で効いてくる。

手順5｜コンテキスト肥大への対処は `/compact` より先に `/rewind` を考える

コンテキストが膨らむと、送るトークンが増えて1ターンが長くなる。ここで反射的に /compact を打つ人が多いが、順番を変えたほうが速いことがある。

大きなファイルがコンテキストを満タンに戻して自動圧縮が空転するループと、サブエージェントと/clearという2つの抜け道を示した図 — 自動圧縮が空転するループと、そこから抜ける2つの出口

`/compact` が高いのは「冷えたとき」

圧縮は会話履歴を要約で置き換える。要約を作るために、Claude Codeは同じシステムプロンプト・ツール・履歴に要約指示を足した別リクエストを送る。キャッシュが温かい間はこのリクエストが前置きをキャッシュから読むので、コンテキストの見た目のサイズほどは高くつかず、時間の大半は要約の生成に使われる。

問題はキャッシュの寿命を超えて放置したあとだ。読めるキャッシュが残っていないので、要約リクエストが履歴全体を未キャッシュの入力として処理し直す。古いセッションを再開したときの /compact がいちばん高いのはこの理由による。なお、圧縮後のターンは短い要約だけでキャッシュを作り直すので、そこは遅い部分ではない。

捨てたいのではなく戻りたいなら `/rewind`

進んだ道筋ごと捨てたい場合は、/compact ではなく /rewind で前のターンに戻すほうが安い。巻き戻しはすでにキャッシュ済みの前置きまで切り詰める操作なので、圧縮のように新しい前置きを作り直さない。/compact の手順そのものは/compactで長時間開発を回す5手順にまとめてある。

`Autocompact is thrashing` が出たとき

自動圧縮が成功した直後に、大きなファイルやツール出力がコンテキストを何度も満タンに戻すと、Autocompact is thrashing: the context refilled to the limit... というエラーで自動圧縮が止まる。進んでいないループにAPI呼び出しを浪費しないための安全装置だ。公式が挙げている復旧手順は4つある。

大きなファイルは全体ではなく、行範囲や関数など小さい単位で読ませる。
捨てたい大出力を外す指定つきで圧縮する（例：/compact keep only the plan and the diff）。
大きなファイルを扱う作業をサブエージェントに移し、別のコンテキストウィンドウで動かす。
それ以前の会話が不要なら /clear する。

なお /compact が Not enough messages to compact. を返すこともある。これは要約するには会話のターン数が少なすぎるという意味で、大きな貼り付け1回でコンテキストが埋まった場合にはコンテキストが満杯でも発生する。

手順6｜検索と読み取りを軽くする

検索が返ってこない・@file が見つけてくれないタイプの遅さは、APIともキャッシュとも無関係だ。原因は同梱のripgrepかファイルシステムにある。

gitignore、permissions.deny、code intelligenceの3層で読む量を減らす構成と各層の具体例を示した図 — 読む量を減らす3層と、それぞれの具体例

ripgrepが動いていないケース

検索ツール、@file メンション、カスタムエージェント、カスタムスキルがファイルを見つけられない場合、同梱のripgrepバイナリが環境で動いていない可能性がある。公式の対処は、OS標準のパッケージでripgrepを入れ、Claude Codeにそちらを使わせることだ。

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

settings.json の env ブロックに書くか、シェルの環境変数として設定する。切り替わったかどうかは shell で claude doctor を実行し、Search行が OK (bundled) ではなくシステム側ripgrepのパスを表示しているかで確認できる。

WSLで結果が少ないケース

WSLでファイルシステムをまたいで作業しているとディスク読み取りのペナルティがあり、検索結果が期待より少なく返ることがある。やっかいなのは、この状態でも claude doctor のSearchは OK と表示される点だ。対処は3つで、検索を具体的に絞る、プロジェクトをWindows側（/mnt/c/）ではなくLinuxファイルシステム側（/home/）に置く、あるいはWSLを経由せずWindowsネイティブでClaude Codeを動かす。

そもそも読む量を減らす

大きなリポジトリでは、定義や参照を探すだけで大量のファイル読み取りとgrepが発生する。公式のモノレポ向けガイドは3層で減らすことを勧めている。

.gitignore：Claudeの内容検索は既定で .gitignore を尊重するので、node_modules/・dist/・build/ のように既に書かれているパスは追加設定なしで検索結果から外れる。
permissions.deny の Read ルール：ベンダーSDKや生成済みコードのようにリポジトリにコミットされているものは、denyルールで開けなくする。

{
  "permissions": {
    "deny": [
      "Read(./**/dist/**/*)",
      "Read(./**/build/**/*)",
      "Read(./**/*.generated.*)",
      "Read(./**/vendor/**/*)"
    ]
  }
}

パターンの末尾が /** ではなく /**/* になっているのは、ディレクトリの中身は覆うがディレクトリ自体は覆わないようにするためだ。こうしておくと ls dist や cd build は通る。

code intelligenceプラグイン：言語サーバーに繋いで定義ジャンプや参照検索をさせると、ツリーを舐めずに済む。TypeScript向けなら /plugin install typescript-lsp@claude-plugins-official をセッション内で実行する。公式マーケットプレイスにはPython、Go、Rustなどもある。言語サーバーのバイナリが各開発者のマシンに必要な点と、インストールにGitHubへのネットワーク到達性が要る点は事前に押さえておく。

手順7｜API側で待っているだけのときの読み方

送信したのに応答が始まらないとき、手元の設定をいじっても意味がないことがある。Claude Codeは待ち状態と再送状態を画面に出しているので、それを読む。

20秒の無反応から待機バナー、リトライ表示、529 Overloadedまでの流れと、/modelでの切り替えを示した図 — 無反応から容量エラーまでに画面へ出るもの

20秒の待機バナー

Error referenceによれば、リクエストが処理中のままレスポンスストリームに20秒間データが来ないと、Waiting for API response · will retry in … · check your network というバナーが出る。この時点ではまだ失敗していない。カウントダウンは、Claude Codeが止まった接続を中断するまでの時間を示している。データが再開するか再送が成功すればバナーは自動的に消える。毎回出るようならネットワーク側の問題として扱う。v2.1.185より前はこのバナーが10秒で出ていたので、古い記憶のまま「今日は妙に出ない」と感じる場合はここが変わっている。Claudeがadvisorに相談している間だけは、しきい値が20秒ではなく90秒になる（v2.1.214以降）。

リトライ表示の読み方

再送中はスピナーに Retrying in Ns · attempt x/y のカウントダウンが出る。ラベルは、すぐ手を打てる失敗（ネットワーク断、TLSハンドシェイク失敗、レート制限）なら1回目から具体的な理由を表示し、それ以外は最初 API error と出る。v2.1.198以降は3回目の試行から具体的な理由に切り替わる。

再送回数は環境変数で調整できる。

環境変数	既定	効果
`CLAUDE_CODE_MAX_RETRIES`	10	再送の試行回数。v2.1.186以降は15が上限。スクリプトで失敗を早く出したいときは下げる
`CLAUDE_CODE_RETRY_WATCHDOG`	未設定	`1` にするとCIなど無人セッションで `429`・`529` の容量エラーを無期限に再送する

`429` と `529` は別物として扱う

529 Overloaded はAPI全体が一時的に容量上限にある状態で、あなたの利用上限ではなく、クォータも消費しない。公式が案内している対処は、status.claude.com（またはメッセージに出ているプロバイダーのステータスページ）で容量に関する告知を確認する、数分おいて再試行する、そして /model で別のモデルに切り替える、の3つだ。容量はモデルごとに管理されているので、切り替えは有効な回避になる。特定モデルの負荷が高いときは、Claude Code自身が Opus is experiencing high load, please use /model to switch to Sonnet のように切り替えを促してくる。

一方 429 は利用上限側の話が混ざる。一時的なスロットルであれば再送の対象だが、ゲートウェイの支出上限による 429 はスロットルではないので再送されない。

再送されない失敗もある

TLS証明書の検証失敗は再送されない。TLSを検査するプロキシ、NODE_EXTRA_CA_CERTS のバンドル未設定、期限切れ証明書などが該当し、証明書の設定をすぐ直せるように1回目で報告される仕様になっている。「待っていればそのうち通る」が起きないカテゴリなので、この表示が出たらネットワーク設定の側を見る。

CPU・メモリと端末描画が原因のとき

最後に、モデルともAPIとも関係なく「画面が重い」ケースを挙げておく。原因が端末側にあるので、設定1つで直ることが多い。以下はいずれも公式トラブルシューティングに記載がある。

端末側の設定で直るもの

文字が箱や崩れた字形になる：VS Code、Cursor、Devin Desktopの統合ターミナルで起きる場合、端末のGPUレンダラーが原因の可能性が高い。セッション内で /terminal-setup を実行すると terminal.integrated.gpuAcceleration を "off" に設定してくれる。
ホイールが1行ずつしか動かない：フルスクリーン描画ではClaude Codeが自前でスクロールしている。/scroll-speed で1ノッチあたりの行数を上げて保存するか、CLAUDE_CODE_SCROLL_SPEED 環境変数を設定する。端末側のスクロールバックに戻したいなら /tui default でクラシックな描画に切り替える。
巨大な表でもたつく：200行を超えるMarkdown表は先頭200行だけを描画し、… N more rows not shown と表示する。表示が切られるだけで会話の中には全行が残っており、/copy は全行をコピーする。v2.1.208より前は全行を描画していたため、巨大な表を含むセッションの再開で固まることがあった。
固まって反応しない：まず Ctrl+C で現在の操作の取り消しを試す。それでも駄目なら端末を閉じて再起動してよい。再起動しても会話は失われないので、同じディレクトリで claude --resume から再開できる。

想定の切り分け例｜「最近ずっと遅い」をキャッシュミスまで絞る（実測値ではありません）

ここまでの手順を1本の流れにすると、たとえば次のようになる。以下は手順の並びを示すための想定であり、特定の環境での計測結果ではない。各ステップで見る表示は公式のプロンプトキャッシュ解説とトラブルシューティングに準拠している。

想定の手順（読むだけで3まで進む）

「最近ずっと遅い」という訴えを、手順1の表で「1ターンが長い」に分類する。
/usage を開き、Prompt cache (main) 行のミス回数が積み上がっていることを確認する。
v2.1.260以降なら推定原因の表示を読む。tool definitions changed 系であれば、MCPサーバーが落ちて再接続しているか、プラグインを途中で切り替えている。
claude --safe-mode で再起動し、症状が消えるかを見る。消えればカスタマイズ側が原因と確定する。
原因のMCPサーバーを常時接続にするか、その日は外す。モデルとeffortはセッションの頭で固定する。

この順番の利点は、3までが読むだけで終わることだ。設定を変えるのは4以降で、しかも --safe-mode は元の設定に手を加えない。

今日やる3つ

/usage を開いて Prompt cache (main) 行を1回見る。ヒット率が低ければ、次のセッションからモデルとeffortを頭で固定する。
shell で claude doctor を実行し、Search行が OK (bundled) かシステム側のパスかを確認する。検索に不満があるならここを疑う。
.claude/settings.json に生成物・ベンダーコードの Read denyルールを1組追加する。読む量が減れば、キャッシュもコンテキストも同時に軽くなる。

3つとも設定と確認だけで終わる。順番は「測る → 環境を確かめる → 読む量を減らす」で、逆にすると何が効いたのか分からなくなる。

よくある質問

Claude Codeの返信が遅いのはなぜですか？

原因は4系統あります。起動が遅い（インストール・環境側）、応答が始まらない（ネットワークまたはAPIの容量）、1ターンが長い（プロンプトキャッシュのミスとコンテキスト量）、検索が返らない（ripgrepまたはファイルシステム）です。いちばん多いのは3つ目で、モデルやeffortをセッション途中で切り替えたり、MCPサーバーが接続と切断を繰り返したりすると、毎ターン会話履歴全体が読み直されます。/usage の Prompt cache (main) 行で判定できます（Claude Code v2.1.251以降）。

モデルを切り替えると遅くなるのはなぜですか？

モデルごとに別のキャッシュを持っているためです。/model で切り替えると、内容がまったく同じでも次のリクエストは会話履歴全体をキャッシュなしで読みます。opusplan 設定はプランモード中がOpus、実行中がSonnetに解決されるので、プランモードの切り替えごとにモデル切替が発生します。セッションの頭でモデルを決めておくのが確実です。

`Autocompact is thrashing` と出て止まりました。どうしますか？

自動圧縮そのものは成功していて、直後に大きなファイルやツール出力がコンテキストを何度も満タンに戻した状態です。進まないループでAPI呼び出しを浪費しないためにClaude Codeが再試行をやめています。大きなファイルは行範囲や関数単位で読ませる、/compact keep only the plan and the diff のように残すものを指定して圧縮する、その作業をサブエージェントに移す、不要なら /clear する、のいずれかで復旧します。

`/compact` と `/rewind` はどちらを使うべきですか？

進んだ道筋ごと捨てたいなら /rewind です。巻き戻しはすでにキャッシュ済みの地点まで切り詰めるだけなので、新しい前置きを作り直す圧縮より安く済みます。/compact は、要らなくなった内容を捨ててコンテキストを空けたいときに、タスクの切れ目で自分のタイミングで打つのが公式の推奨です。

検索がファイルを見つけてくれません。

同梱のripgrepが動いていない可能性があります。OSのパッケージでripgrepを入れ、settings.json の env ブロックまたはシェル環境で USE_BUILTIN_RIPGREP を 0 に設定してください。切り替わったかは claude doctor のSearch行が OK (bundled) ではなくシステム側のパスを表示しているかで確認します。WSLでファイルシステムをまたいでいる場合は、Search行が OK のままでも結果が少なくなることがあり、このときはプロジェクトを /home/ 側に置くのが対処になります。

`529 Overloaded` は自分の利用上限に当たったということですか？

違います。529 はAPI全体が一時的に容量上限にある状態で、あなたの利用上限ではなく、クォータも消費しません。容量はモデルごとに管理されているので、/model で別のモデルに切り替えれば作業を続けられることが多いです。継続する場合は status.claude.com で告知を確認してください。

昼休みのあと最初の1ターンだけ遅いのは異常ですか？

仕様どおりの挙動です。キャッシュは無操作が続くと期限切れになり、次のリクエストで入力全体を計算し直して張り直します。TTLは5分と1時間があり、Claudeサブスクリプションのプラン内利用ではメインの会話が1時間、APIキーやクラウドプロバイダー経由では5分が既定です。離席をはさむ使い方なら、promptCacheTtl 設定または CLAUDE_CODE_PROMPT_CACHE_TTL 環境変数に 1h を指定する選択肢があります（v2.1.242以降）。

メモリ使用量が下がりません。調べる方法はありますか？

/compact、再起動、.gitignore への追加、claude --safe-mode を試しても高いままなら、/heapdump を実行します。~/Desktop にヒープスナップショットと診断JSONの2ファイルが書き出され、会話にも要約が表示されます。ただしスナップショット側には会話全文と認証情報を含む全文字列が入るため、公開の場に出してはいけません。報告するときは統計だけを含む -diagnostics.json のみを添付してください。

運営元 Uravation よりこの事例を自社の業務で試す場合のテーマ選定・評価・本番移行の確認項目を、無料のチェックリストにまとめています。 Claude Code業務自動化PoCチェックリストを受け取る（無料）

参考・出典

Anthropic「Troubleshooting」（2026年9月20日閲覧。症状別のページ振り分け、/doctor と claude doctor、claude --safe-mode、/heapdump の出力先と取り扱い、200行を超える表の描画とv2.1.208以前の挙動、Autocompact is thrashing の復旧4手順、Not enough messages to compact.、Ctrl+C と claude --resume、/terminal-setup とGPUアクセラレーション、/scroll-speed と CLAUDE_CODE_SCROLL_SPEED、/tui default、USE_BUILTIN_RIPGREP とSearch行の読み方、WSLでの検索劣化）
Anthropic「How Claude Code uses prompt caching」（2026年9月20日閲覧。前置き完全一致の仕組み、3レイヤーの構成表、キャッシュを無効化する操作と維持する操作、opusplan とモデル切替、/compact が温かい場合と冷えた場合のコスト差、/rewind との比較、TTL既定値の表と promptCacheTtl／subagentPromptCacheTtl（v2.1.242以降）、キャッシュのマシン・ディレクトリ単位のスコープ、cache_creation_input_tokens／cache_read_input_tokens、/usage の Prompt cache (main) 行がv2.1.251以降、推定原因表示がv2.1.260以降）
Anthropic「Error reference」（2026年9月20日閲覧。20秒の待機バナーとv2.1.185以前の10秒、advisor時の90秒しきい値、Retrying in Ns · attempt x/y の表示とv2.1.198以降の理由表示、CLAUDE_CODE_MAX_RETRIES の既定10とv2.1.186以降の上限15、CLAUDE_CODE_RETRY_WATCHDOG、529 Overloaded がクォータを消費しないこと、/model 切り替えの案内、TLS証明書失敗を再送しない扱い）
Anthropic「Set up Claude Code in a monorepo or large codebase」（2026年9月20日閲覧。内容検索が既定で .gitignore を尊重すること、permissions.deny の Read ルールと /**/* パターンの理由、code intelligenceプラグインと /plugin install typescript-lsp@claude-plugins-official、言語サーバーのバイナリとネットワーク要件）
Anthropic「Prompt caching」（2026年9月20日閲覧。プロンプトキャッシュの前置き照合の基礎、5分TTLと1時間TTLの料金差）
Anthropic「Claude Status」（2026年9月20日閲覧。529 が続く場合に容量関連の告知を確認する先）
GitHub「anthropics/claude-code Issues」（2026年9月20日閲覧。同じ症状の報告が既に出ていないかを確認する先。手元の設定で直らない遅さは、ここで既知の不具合かどうかを確かめてから報告する）