Claude Codeのメモリリークで120GB超・OOM Killになる原因と対処法

Claude Codeが120GB超まで膨らみOOM Killされる報告

Claude Codeのプロセスが長時間セッション中に肥大化し、LinuxカーネルのOOM Killer(out-of-memory killer)に強制終了される事例がGitHub issueで報告されています。公式が案内する動作要件は4GB以上のRAMですが、実際の報告では120GB以上まで膨れ上がったケースが複数あります。

発端はissue #4953です。2025年8月1日、Ubuntu 24.04・RAM 128GB・Claude Code v1.0.53の環境で登録されました。インタラクティブモードで30〜60分ほど作業を続けると、claudeプロセスのRSS(実メモリ使用量)が120〜125GB前後まで増え続け、dmesgのログにKilled process ... (claude) ... anon-rss:124857720kBのようなカーネルの強制終了記録が残ります。

復旧しても、症状は再発します。OOM Killで落ちた直後は使用量が約400MBまで下がりますが、セッションを続けるとまた同じペースで増えていきます。報告者はこれを「30〜60分ごとの再起動が必要になり、実用に耐えない」と評価しました。

同じissueには2025年10月から12月にかけても新しい報告が続きました。Mac M1 Max(32GB)で34GB、97GB、107GB、130GB超といった数値が挙がり、環境やOSを問わず同じ症状が観測されています。VS Code拡張ではclaudeプロセスが1つずつ約250MBを使いながら大量に立ち上がる、という別パターンの報告(2025年12月28日)もあり、単一プロセスの肥大化だけが症状ではありません。

コメントに挙がったバージョンを追うと、報告はv1.0.53にとどまりません。「サブエージェントを使い始めたv1.0.70前後から発生している」という報告、v1.0.98で4プロセスが1つあたり2.5GBを使っていたという報告、v2.0.1では安定していたRSSが60秒で7倍に跳ねたという報告、v2.0.27でも同様の急増が確認されたという報告が並びます。バージョンをまたいで似た急増パターンが繰り返し報告されている点が、単発の実装ミスではないことを示唆しています。

メモリリークの原因は1つではない

公式changelogを追うと、「長時間セッションでメモリが増え続ける」という同じ症状に、まったく別のコードパスが関わっていたことが分かります。原因は1つの巨大なバグではなく、性質の異なる複数のリークが積み重なったものです。

大きく4つの系統に分けられます。キャッシュの解放漏れでは、gitルート検出キャッシュやJSONパース用キャッシュ、bashコマンドのプレフィックスキャッシュなどが対象でした。UI・トランスクリプト表示の保持では、フルスクリーン表示が行ごとにツールルックアップの全コピーを抱え続けたり、エージェントビューが送信済みの画像を保持し続けたりします。

サブプロセス・ハンドルの解放漏れも見つかっています。MCP stdioサーバーのstderr出力が1サーバーあたり最大64MBまで蓄積する、LSPサーバーが開いたドキュメントを無期限に保持する、ファイルを原子的に置き換えた後にファイル監視のハンドルが解放されない、といったケースです。バックグラウンド処理・ツール結果の保持では、hookやバックグラウンドタスクの出力、サブエージェントのツール実行結果、WebFetchのキャッシュが本来の生存期間を超えて残り続けます。

同じ「OOM Kill」という症状の裏に、使っている機能によって異なる原因が隠れています。MCPサーバーを多用する環境と、hookを多用する環境では、当てはまる原因も有効な対処も変わってきます。キャッシュ系の解放漏れは会話が長引くほど線形に膨らみやすく、サブプロセスのハンドルリークは接続・再接続の回数に比例して悪化しやすいという違いもあります。

v2.1.50からv2.1.257まで続く修正の系譜

2026年2月から9月にかけて、ほぼ毎月のリリースで具体的なメモリリークの修正が入っています。1回のリリースで5件以上まとめて修正された回もあり、断続的にではなく継続的に手が入ってきたことが分かります。

中でもv2.1.63は突出していて、1回のリリースだけでリスナー・キャッシュ系のリークが11件まとめて修正されました。内訳はブリッジのポーリングループ、MCP OAuthフローの後始末、hooks設定メニューの操作、権限確認の自動承認、bashコマンドのプレフィックスキャッシュ、MCPツール・リソースキャッシュの再接続時、WebSocketの再接続時、gitルート検出キャッシュ、JSONパースキャッシュ、Agent Teamsの会話圧縮後のメッセージ保持、MCPサーバーのフェッチキャッシュです。同じ性質の不具合が複数箇所でまとめて見つかっていたことから、当時はリソース解放の実装が機能ごとにばらついていたと見ることもできます。

issue #4953が報告されたv1.0.53は、この一覧より前のバージョン体系です。個々の修正が同issueの再現条件を直接解消したという確認は取れていませんが、症状として報告されていた「長時間セッションでの際限のない増加」に該当する原因は、この7か月ほどの間だけでも表の12リリースにわたって個別に特定・修正されています。

自分の症状の原因を切り分ける

原因が複数系統に分かれているため、まず「どの機能を使っているときに悪化するか」を絞り込むのが近道です。公式のトラブルシューティングガイドは、高CPU・高メモリの症状に対して/compactをこまめに使う、大きなタスクの区切りでClaude Codeを再起動する、巨大なビルドディレクトリを.gitignoreに入れる、--safe-modeでプラグイン・MCPサーバー・hookが原因かを確かめる、という4点をまず挙げています。ここから先は、症状のパターン別にさらに系統を絞り込みます。

/heapdumpはメモリ使用量が高止まりしたときの診断コマンドです。~/Desktop(Linuxでデスクトップフォルダが無い場合はホームディレクトリ)に、JSヒープのスナップショット(.heapsnapshot)と内訳を示す診断用JSON(-diagnostics.json)の2ファイルを書き出します。コマンドメニューの候補には出てこないため、/heapdumpと全文入力する必要があります。

使い方の詳細は/heapdumpでメモリ使用量の高さを診断するにまとめています。CLAUDE.mdやhooks、MCPサーバーなど自分で積んだカスタマイズが原因かどうかを切り分けたい場合は、全カスタマイズを無効化して起動するclaude --safe-modeが使えます。

claude --safe-mode

safe modeで症状が消えれば、原因はカスタマイズ側にある可能性が高いと分かります。手順の詳細と--bareとの違いはClaude Code safe modeで「壊れた」設定を1コマンドで切り分けるで扱っています。MCP・hooks・skills・auto memoryなどをまとめて止めて確かめたいだけなら、環境変数CLAUDE_CODE_SIMPLEを使う方法もあります。

CLAUDE_CODE_SIMPLE=1 claude

暫定的な回避策として、長時間セッションを続ける場合はps aux | grep claudeでRSSを定期的に確認し、増加が続くようなら区切りの良いところで一度セッションを終了して再起動する運用が挙げられます。なお、Bash・PowerShellが実行するコマンド側がメモリを使い切っている場合はここまでの原因とは別で、CLAUDE_CODE_TOOL_MEMORY_LIMITでBash・PowerShellのメモリを制限するで扱うcgroup上限が対処になります。インストール直後に「Installation was killed」で止まる場合も別の話で、Installation was killedエラーの原因と対処にまとめています。

それでも新しいリークが見つかり続ける理由

7か月ほどの間、ほぼ毎月のリリースで個別修正が入ってもなお、新しいメモリリークの修正がリリースノートに載り続けています。これは対応が後手に回っているというより、長時間の対話セッションという実行モデル自体が抱える構造的な難しさを反映しています。

Claude Codeは、セッションが続く限りキャッシュ・トランスクリプト・サブプロセスのハンドルを抱え続ける設計です。会話が数時間、数日と続くほど、想定していなかった保持先が新たに見つかる可能性は消えません。個別のパッチだけに頼らず、/heapdumpでの定点観測や長時間セッションの定期的な区切りを運用に組み込んでおく方が現実的です。

/heapdumpが出す要約は、使用量の大半がJSヒープ(スナップショットで追える範囲)にあるか、ネイティブメモリ(追えない範囲)にあるかを示します。ネイティブメモリが大半という結果が出た場合はスナップショットでは中身を特定できないため、その場合は要約に含まれるリーク兆候の数値を添えて報告する経路が用意されています。

まとめ

Claude Codeの「120GB超・OOM Kill」問題は、2025年8月に報告された単一のissueに閉じた話ではなく、キャッシュ・UI表示・サブプロセス・バックグラウンド処理という複数系統にまたがる継続的な課題です。v2.1.50からv2.1.257まで、7か月ほどの間に12回のリリースで具体的なメモリリークが個別に修正されてきました。

症状が出ている場合は、まず最新版への更新を確認し、claude mcp listや--safe-modeでMCP・hooks・カスタマイズ由来かどうかを切り分け、原因が絞れなければ/heapdumpでスナップショットを取るのが現実的な手順です。長時間セッションを運用に組み込むチームでは、区切りの良いところでの再起動を前提にしておくと、突然のOOM Killによる作業ロスを避けやすくなります。