Claude CodeのCPU使用率が高い・張り付く問題を、GitHub Issueの実例で整理した
Claude Codeがアイドル時でもCPU使用率100%に張り付き、ファンが回り続ける・バッテリーが減る原因を整理。レンダーバッファの肥大化・孤立サブエージェント・LSPクラッシュループなど5パターンをGitHub Issue実例つきで解説し、診断コマンドと対処法をまとめた。
エンジニアのゆとです。
Claude Codeを何もせず放置しているだけなのに、topを叩くとCPU使用率が90〜130%あたりに張り付いている——という経験をした人、たぶん自分だけじゃないと思う。ファンが唸り出す、ノートPCがバッテリー駆動だと目に見えて減りが早くなる、他のアプリの動作までもたつく。プロンプトを打ってすらいないのに、だ。
「claude code cpu 使用率」で検索すると、この症状自体は結構前から報告され続けているのに、日本語でまとまった整理記事はまだ少ない。今回はGitHub Issueに報告されている実例を軸に、何が原因でCPUが高止まりするのか、どう切り分けて、どう対処すればいいのかをまとめた。
まず結論 — アイドル時のCPU高止まりは主に5パターン
先に結論から書く。Claude Codeが「何もしていないのに」CPUを食い続ける症状は、GitHub Issueを追っていくと大きく5つの原因パターンに分かれる。
- ターミナル描画バッファ（
fullStaticOutput）が長時間セッションで肥大化し続ける - 孤立（オーファン）したサブエージェント・子プロセスが積み重なっている
- LSPサーバーがクラッシュ→再起動を繰り返すループに入っている
/hooksメニューの特定画面に開いたまま放置している- 特定バージョンで発生する回帰（リグレッション）バグを踏んでいる
原因によって直し方がまったく違うので、まず自分がどのパターンに近いかを切り分けるところから始めたほうがいい。
「重い・遅い」「フリーズ」「CPU高止まり」は別の症状
本題に入る前に、混同しやすい隣接症状を整理しておく。Claude Code関連の「重い」系トラブルは、実は性質の異なる症状がまとめて語られがちだ。
1つ目は、応答そのものが遅い・的外れになるという劣化症状。これはシステムの空きメモリ・スワップの逼迫が引き金になっていることが多く、実測データをもとに別記事で扱っている。
2つ目は、検索やファイル探索といった特定の操作だけが遅く感じるケース。原因の切り分け方を公式の診断コマンドベースで整理した記事がある。
3つ目は、FATAL ERROR: JavaScript heap out of memoryでセッションごとクラッシュするケース。これはメモリのヒープ上限に達して落ちる話で、今回のCPU高止まりとは別物だ。
今回扱うのは、これらとは違って「プロセスは生きている・クラッシュもしていない・でもCPUを常に食い続けている」というパターンだ。バッテリーが減る、ファンが回り続ける、他のアプリまでもたつく、という形で症状が出る。
まず診断する — 本当にアイドル時にCPUを食っているか確認する
思い込みで対処を始める前に、まず実際の状態を確認する。
# Claude Codeのプロセスとその負荷を確認する（macOS/Linux）
ps aux | grep claude
# リアルタイムで監視する
top -o cpuプロンプトを何も打っていない・ツールも実行していない状態で、claudeまたはclaude --resumeのプロセスが継続的に50%を超えているなら、今回扱う「アイドル時CPU高止まり」に該当する。GitHub Issueに報告されている実例では、こんな数値が出ている。
PID USER %CPU COMMAND
2931058 devin 109.1 claude
3568968 devin 90.9 claude
2915221 devin 63.6 claude同時に、Claude Codeのプロセス数も確認しておく。1つのセッションのつもりが、裏で何十個ものプロセスが生き残っているケースが後述のパターン2に該当する。
ps aux | grep claude | wc -lCPU使用率が高止まりする5パターン
パターン1: ターミナル描画バッファの肥大化
もっとも技術的に踏み込んだ原因分析がされているのがこのパターンだ。Claude Codeのターミナルレンダラーは、これまでの出力をfullStaticOutputという文字列バッファに蓄積していく実装になっている。このバッファは/clearを実行した時以外、自動圧縮（オートコンパクト）でもリセットされない。
毎回の描画サイクルで、この巨大化した文字列に対して+=で追記が行われる。JavaScriptの文字列は immutable（不変）なので、追記のたびに文字列全体がメモリ上でコピーされる。セッションが長くなるほど、1回の描画コストがどんどん重くなっていく。
このパターンの厄介なところは、/clearを打てば直るが、/clearは会話履歴（トークンのコンテキスト）ごと消してしまう点だ。「CPUは直したいが今の文脈は失いたくない」というジレンマが起きる。2026年8月時点では、描画バッファだけを個別にリセットする仕組みは用意されていない。
パターン2: 孤立したサブエージェント・子プロセスの蓄積
サブエージェントや--resumeを多用していると、本来は終了しているはずのプロセスが親から切り離された状態のまま残り続けることがある。GitHub Issueでは、確認したら134個ものオーファンサブエージェントが残っていて、それを一括終了したらCPU使用率が正常値まで戻ったという報告がある。
サブエージェントを並列で走らせるワークフロー（Agent Teamsなど）を多用している人ほど当たりやすい。定期的に自分の環境で生きているプロセス数を数えて、明らかに多い場合は疑ったほうがいい。
パターン3: LSPサーバーのクラッシュループ
Claude CodeはIDE連携のためにLSP（Language Server Protocol）サーバーをバックグラウンドで起動することがある。このLSPサーバー側がクラッシュした際、再起動を試みてまたクラッシュする、というループに入りCPUを食い続けるケースが報告されている。
{"error":"Error: LSP server plugin:rust-analyzer-lsp:rust-analyzer crashed with exit code 1\n at <anonymous> (/$bunfs/root/claude:2142:21472)"}この例ではRust向けのLSPサーバー（rust-analyzer）がクラッシュを繰り返しており、プロンプトを何も打っていない起動直後の時点でCPU使用率が20%を超えていたと報告されている。言語ごとのLSPプラグインを多く有効化している環境ほど、この種のクラッシュループに気づきにくい。
パターン4: /hooksメニュー画面に開いたまま放置
これはかなり具体的な再現条件だが、報告例があるので載せておく。/hooksコマンドでフックの設定画面を開き、Stopイベントを選択した状態のまま画面を閉じずに放置していると、そのセッションだけシングルコアで90%前後のCPUを使い続けるという報告がある。
メインの入力画面に戻るだけで解消するので、心当たりがあればEscで通常のプロンプト画面に戻しておくといい。
パターン5: バージョン特有の回帰（リグレッション）バグ
最後は、特定バージョンでだけ発生する退行バグだ。GitHub Issueでは、あるバージョン（v2.1.27）で--resume関連の不具合が修正された一方、その修正が新たなCPU高止まりを引き起こし、1つ前のバージョン（v2.1.25）にダウングレードしたらCPU問題が消えた、という報告がある。
公式の変更履歴（changelog）でも、Linux環境でアイドルセッションが1コアを100%使い続ける不具合が修正されたことが明記されている。バージョンによって発生条件が変わるタイプの不具合なので、「前のバージョンでは平気だった」という感覚があるなら、まずどちらの方向にずれたか（アップデートで発症したのか、それとも前から発症していたのか）を確認するのが早い。
対処法 — 症状別にまとめる
切り分けができたら、対処は次の順番で試すのが効率がいい。
- まずプロセス数を確認する（
ps aux | grep claude | wc -l）。想定より多いなら、古いプロセスをkillしてから様子を見る - セッションが長時間（数時間以上）続いているなら、
/clearでバッファをリセットする。文脈を失いたくない場合は、事前にCLAUDE.mdや別ファイルに現在の作業内容を要約してから/clearする - IDE連携やLSPプラグインを多く有効化しているなら、いったん該当プラグインを無効化してCPU使用率が下がるか確認する
/hooksなど特定のメニュー画面を開いたままにしていないか確認するclaude updateで最新バージョンに上げる。逆に「アップデート直後から発症した」なら、1つ前のバージョンに戻して様子を見る
# 現在のバージョンを確認
claude --version
# 最新版にアップデート
claude update
# 特定バージョンにダウングレードしたい場合の手順は別記事にまとめているバージョンのダウングレード・固定手順については、こちらで詳しく扱っている。
恒久対策・予防策
その場しのぎだけでなく、再発を防ぐ工夫もいくつか紹介しておく。
- 長時間の連続セッションを避け、区切りのいいタイミングで一度Claude Codeを終了・再起動する運用にする
- サブエージェントやAgent Teamsを多用する場合、定期的に
ps aux | grep claude | wc -lでプロセス数を確認する習慣をつける - 使っていないLSPプラグイン・MCPサーバーは無効化しておく（
claude --safe-modeで一時的に全拡張を無効化して切り分けられる） claude --versionを定期的に確認し、バージョンが古すぎないかチェックする
拡張機能（MCP・hooks・プラグイン）まわりが原因かどうかを切り分ける手順は、公式ドキュメントにもまとまっている。
FAQ
Windows（WSL2）でも同じ現象は起きる？
起きる。GitHub Issueの報告例にもWSL2環境（Ubuntu on WSL2）でのアイドル時CPU高止まりが含まれている。WSL2はWindows側とLinux側でリソース管理が分かれているため、.wslconfig側のCPU・メモリ割り当ても合わせて確認しておくと切り分けが早い。
claude --safe-modeとは？
そのセッション中だけプラグイン・MCPサーバー・hooksをすべて無効化して起動するモードだ。これでCPU使用率が正常に戻るなら、Claude Code本体ではなく拡張機能側に原因があると確定できる。原因の切り分けに使える診断用のオプションとして覚えておくといい。
CPU使用率が高いだけでなく、メモリ使用量も異常に多い場合は？
今回のCPU高止まりとは別の症状で、メモリのヒープ上限に達してクラッシュするケースは原因もパターンも異なる。そちらは別記事で4パターンに分けて整理している。
まとめ
Claude Codeがアイドル時でもCPUを食い続ける症状は、1つの原因に集約されるものではなく、レンダーバッファの肥大化・孤立プロセスの蓄積・LSPのクラッシュループ・特定画面での放置・バージョン固有の回帰と、複数の原因が別々に報告されている。
まずはps auxとtopで本当にアイドル時に高いのかを確認し、プロセス数・セッションの長さ・有効化している拡張機能を順番に疑っていくのが、遠回りに見えて一番早い切り分け方だ。
