はじめに
サーバーワークスの池田です。
Claude Code を複数セッションで日常的に動かしていると、ある日突然マシンが固まる経験をされた方は少なくないはずです。公式のシステム要件には「RAM 4GB+」とだけ書かれていますが、実際にヘビーに使っているとこの数値が現実離れしていることに気付きます。
この記事は 物理RAMとPCスペックの話 に絞ったまとめです。CLAUDE.md やコンテキスト圧縮、永続メモリ（Agentmemory 等の OSS）といった「AI 側のメモリ」の話ではありません。Claude Code を動かすマシン側の RAM、CPU、SSD についての話です。
公式の要件、Anthropic 公式リポジトリの GitHub Issues に上がっているマシン構成別の実例、CHANGELOG に刻まれたメモリ改善の歴史を整理して、用途別に何 GB 必要か を提示します。
なお、本記事で「筆者の体感」「筆者の運用観察」として登場する数値は Apple Silicon の Mac 環境 での観察値です。Windows / Linux では一部の挙動（ゾンビプロセスの残り方、プロセス管理の細部、Electron 系アプリのメモリ収支など）が異なる可能性がある点はご了承ください。
この記事で分かること
- 公式システム要件「4 GB+ RAM」が指す範囲と、明記されていないこと
- 公式が同時に推奨する並列ワークフローと 4 GB の構造的なギャップ
- Anthropic 公式リポジトリの Issue に並ぶ「8 GB → 16 GB → 32 GB → 64 GB → 128 GB」階段状の枯渇報告
- CHANGELOG で追える 14 ヶ月分のメモリ改善史
- 用途別の現実的な推奨スペックと、踏みがちな地雷の回避策
公式システム要件に書かれていること、書かれていないこと
Claude Code 公式ドキュメントの Advanced setup ページ の「System requirements」セクションには、ハードウェア要件として次の1行のみが記載されています。
Hardware: 4 GB+ RAM, x64 or ARM64 processor
注目すべきは、ここに 「最低」と「推奨」の区別がない ことです。「シングルセッション想定の最小起動値なのか」「並列セッションを前提とした快適動作値なのか」も書かれていません。CPU コア数、ディスク容量、想定ワークロード規模への言及も一切ありません。
実際にこの状況は公式リポジトリでも問題として認識されており、Issue #20245 では「最低RAM要件をドキュメントに記載してほしい」という要望が立っています。本記事執筆時点では未対応です。
つまり「4 GB+」は Claude Code バイナリが起動するための下限値 と解釈するのが妥当で、想定ユースケースの説明は公式には存在しません。
公式が推奨する並列ワークフローと 4 GB のギャップ
一方で、Best practices for Claude Code には「Automate and scale」という独立した章があり、複数 Claude セッションを同時に走らせる運用 が公式推奨として明記されています。
具体的に挙げられている手段は次のとおりです。
| 手段 | 概要 | 公式ドキュメント |
|---|---|---|
| Git worktrees | リポジトリを worktree 単位で分離し、別ディレクトリで並列セッション | worktrees |
| デスクトップアプリ | サイドバーから複数セッションを同時管理 | desktop |
| Claude Code on the Web | クラウド側でバックグラウンド実行 | claude-code-on-the-web |
| Agent teams | 複数エージェントによるチーム編成 | agent-teams |
Anthropic の Boris Cherny 氏は Pragmatic Engineer インタビュー で、5並列の Claude Code で1日20〜30 PR を回している運用を公開しています。
社内事例をまとめた公式ブログ How Anthropic teams use Claude Code でも、サブエージェントの並列実行と自律ループが標準的な使い方として紹介されています。
ここに 構造的なダブルスタンダード があります。要件は「4 GB+」と書かれている一方で、推奨ワークフローは「並列セッション × worktrees × subagents」です。
後述するように、この組み合わせを 4 GB で運用することは現実的ではありません。
過去に報告された極端なメモリバグの事例
ここでまず重要なのは、通常運用では発生しないはずの極端なメモリ消費がバグとして繰り返し報告されてきた という事実です。「マシンの RAM が足りない」のではなく、特定のリーク・無限増殖・処理経路の欠陥によって、本来あり得ない量を食ってしまうケースが Anthropic 公式リポジトリの Issue に並んでいます。
代表的なものを並べると、規模感は次のとおりです。
| Issue | 報告内容 |
|---|---|
| #14024 | CLAUDE.md の読み込み時に OOM クラッシュ |
| #11315 | 30 分のうちに RSS が 2 GB → 12 GB に増加、仮想メモリが 129 GB に到達してシステムフリーズ |
| #21378 | WSL2 上で 20 分のうちに 15 GB を消費しスワップスラッシング発生 |
| #34161 | わずか3往復のやり取りで 10〜13 GB に肥大化し OOM Kill |
| #25545 | アイドル状態のまま 22 GB / 19 GB 消費しハングアップ |
| #22427 | Skills を1000個超登録した環境で、30 分で 23 GB 消費 |
| #23442 | v2.1.32 が起動直後に 1 プロセスあたり 11 GB を確保、6 セッションで 60 GB 消費 |
| #4953 | 30〜60 分で 120 GB 超 まで肥大化し OOM Killer に殺される |
これらは「○GB マシンでも足りない」という話ではなく、ほとんどがバグです。本来 CLI ツールが 1 セッションあたり数百 MB〜数 GB で済むはずの処理が、リークや無制限増殖によって桁外れの数値に達したものです。
実際、こうした報告は Anthropic 側に拾われて修正されてきました。後述する CHANGELOG の改善履歴を見ると、ここに挙げた多くのバグに対応する修正が時系列で並んでいます。「128 GB あっても落ちた」事例は、128 GB が足りないのではなく、バグが直るまでの一定期間そういう挙動だった と読むのが正確です。
なお同じ Issue 群には #30094 のように「自分は 32 GB DDR5 で使用率 70% 未満、友人は 8 GB DDR4 ノートで問題なく使えている」という逆パターンも混在します。ワークロード（Skills 数、MCP 構成、worktree 数、セッション継続時間）の差で実効消費は大きく振れます。
Anthropic が14ヶ月で直してきたメモリ改善史
ここからが本記事の中心です。前節で挙げた極端なバグは氷山の一角で、公式 CHANGELOG.md（v0.2.21〜v2.1.153）を全行スキャンすると、メモリ・パフォーマンス関連の改善エントリだけで 200 件以上 が確認できます。期間にすると約 14 ヶ月、平均すると 週 3〜4 件のペースでメモリ・性能関連の修正が積まれている 計算です。
それだけ「埋めるべき穴があった」ということでもあります。
カテゴリ別の改善件数
CHANGELOG から拾えるエントリをカテゴリで分類すると、次のような内訳になります。
| カテゴリ | 件数 | 主な内容 |
|---|---|---|
| リーク修正 | 約38件 | listener / cache / AppState / WASM / Yoga / React Compiler memoCache 等 |
| メモリ削減 | 約36件 | 数十 MB〜100 MB 単位の削減、O(n²) 解消、GB 級暴走の対策 |
| キャッシュ改善 | 約33件 | prompt cache の TTL・無効化・失敗キャッシュ追加 |
| 起動高速化 | 約33件 | 30 ms〜数秒単位の短縮、defer / parallelize |
| パフォーマンス最適化 | 約22件 | 3 倍・12 倍・16 倍・45% など倍速化系 |
| プロセス管理 | 約18件 | dangling / orphan / zombie / EIO / SIGKILL fallback |
| コンテキスト圧縮 | 約17件 | auto-compact の改良、PreCompact フック、circuit breaker |
| WASM / パーサー | 約6件 | tree-sitter / Yoga 廃止、ネイティブモジュール置換 |
| ネイティブ化 | 約6件 | Rust fuzzy finder、bfs / ugrep 埋め込み、ネイティブバイナリ移行 |
これだけの修正が積み重なっているということは、それと同じ数だけ 何らかのリーク・暴走・性能劣化が実環境で発生してきた ということです。CLI ツールでこの規模の改善史を持つプロダクトはあまり例がありません。
象徴的な「大物バグ」の流れ
特に「数 GB〜数十 GB の暴走」「アーキテクチャ起因の構造的問題」レベルのものを抜き出すと、次のような流れが見えます。
| 時期 | バージョン | 内容 |
|---|---|---|
| 2025-12-15 | v2.0.70 | 大規模会話のメモリ使用量を 3 倍効率化 |
| 2026-01-08 | v2.1.2 | tree-sitter のパースツリーが解放されず、WASM メモリが無制限に増加 していた問題を修正 |
| 2026-01-23 | v2.1.19 | ターミナル終了時に Claude Code プロセスが残り続ける問題を EIO 対応 + SIGKILL フォールバックで修正 |
| 2026-02-19 | v2.1.49 | Yoga WASM の線形メモリが縮小しない問題、tree-sitter パーサーを定期リセットする処理を追加 |
| 2026-02-20 | v2.1.50 | LSP 診断データ・TaskOutput・CircularBuffer・shell コマンド実行など 7 種類のリークを一括修正 |
| 2026-02-28 | v2.1.63 | bash プレフィックス・git root・JSON parse・MCP fetch・WebSocket リスナーなど キャッシュ系の無制限リーク群を一斉駆除 |
| 2026-03-04 | v2.1.69 | コミット時の 数 GB スパイク 修正、React Compiler memoCache のリーク、REPL レンダースコープが 1000 ターンで 35 MB 増えるリーク、Yoga WASM の遅延ロードで ベースライン -16 MB |
| 2026-03-11 | v2.1.74 | ストリーミング API バッファが解放されず、Node.js 経路で RSS が無制限増加 していた問題を修正 |
| 2026-03-16 | v2.1.77 | 自動アップデータがバイナリダウンロードを重複させて 数十 GB のメモリを蓄積 する問題を修正 |
| 2026-03-19 | v2.1.80 | 250,000 ファイル規模リポジトリの起動時メモリを 約 80 MB 削減 |
| 2026-03-26 | v2.1.85 | WASM ベースの Yoga レイアウトを 純粋な TypeScript 実装に置換（WASM 依存削減の象徴的転換） |
| 2026-03-31 | v2.1.89 | LSP サーバーがクラッシュ後にゾンビ状態になる問題を修正、 >1 GiB ファイルの Edit で OOM クラッシュする問題を修正 |
| 2026-04-01 | v2.1.90 | SSE トランスポートの処理が O(n²) → O(n) に、SDK の transcript 書き込みも 二乗オーダーを解消 |
| 2026-04-08 | v2.1.97 | MCP HTTP/SSE 接続が 1 時間あたり約 50 MB のリーク |
| 2026-04-17 | v2.1.113 | ネイティブバイナリ起動方式に切替（Node.js 依存削減） |
| 2026-04-21 | v2.1.117 | macOS / Linux ネイティブビルドで Glob・Grep ツールを bfs・ugrep に置換 |
| 2026-04-27 | v2.1.121 | 画像を大量に扱うセッションで RSS が無制限に増える問題、/usage が 約 2 GB リーク する問題を同時修正 |
| 2026-05-06 | v2.1.132 | stdio MCP サーバーが非プロトコル出力を吐くと RSS が 10 GB 超 に膨れる問題を修正 |
| 2026-05-11 | v2.1.139 | HTTP/SSE MCP サーバーが非プロトコルデータをストリームすると無制限増、16 MB/フレームでキャップ |
| 2026-05-27 | v2.1.153 | --resume でセッション履歴が多いマシンで 数 GB を浪費 する問題を修正、Remote Control 有効時のゾンビセッション、Windows VS Code 終了時の MCP オーファン問題も同時修正 |
並べてみると、流れにはいくつかの相が見えます。
2025 年（初期） は自動コンテキスト圧縮の導入や MaxListenersExceededWarning 級の単発リーク修正など、正攻法の基盤整備 が中心でした。
2026 年 1〜2 月 は、長時間セッションで太る系のリーク駆除フェーズです。tree-sitter、Yoga、LSP 診断、CircularBuffer、TaskOutput、agent teams、キャッシュ群と、「長く使い続けたら必ずどこかで漏れる」というパターンを片っ端から潰す 動きが集中しています。
2026 年 3〜4 月 は起動経路の軽量化と構造的な置き換えです。React Compiler 導入、WASM → 純 TypeScript 化、Glob/Grep のネイティブ化、そして v2.1.113 でのネイティブバイナリ移行。Node.js を介して動かしていた経路を OS ネイティブに寄せる方向の修正が連続します。
2026 年 4〜5 月 は MCP・画像・大量セッションといった 極端ケースへのキャップ追加 に重心が移ります。「無制限に増える経路」を見つけては上限を入れる作業が続いており、直近の v2.1.153 でも --resume 時に 数 GB を浪費 する問題が修正されたばかりです。
つまり Claude Code のメモリ問題は 「公式が地雷を踏みながら直してきた歴史」 であり、本記事執筆時点でもまだ走り続けているプロセスです。「4 GB+」という公式要件の数字が動かないまま、実装は「重い使い方をしても破綻しないように」改修され続けている、という構造になっています。
Claude Code 1セッションの実消費を見積もる
推奨スペックを語る前に、まず Claude Code 1セッションが実際にどれくらいメモリを食うのか を見積もる必要があります。
筆者の運用観察では、Claude Code 1 セッションの常時メモリ消費は 通常 200〜300 MB、多めの操作中でも 400〜500 MB に収まることが多いです。これは CLI ツールとして妥当な範囲で、Issue #8968 で報告される「1インスタンスあたり 2.5〜8 GB」のような数字とはだいぶ離れます。
問題は、この 「通常 300〜500 MB」が実運用では倍々ゲームで膨らむ ことです。具体的には次の要因が積み上がります。
| 増加要因 | 影響 |
|---|---|
| ゾンビプロセスの累積 | ターミナル終了後も残るプロセスが容量を掴み続ける |
| Skills の大量登録 | Skills 数に比例してロード時メモリが増える |
| サブエージェントの並列実行 | warm-spare worker が常駐する |
| 長時間セッション | リーク残（CHANGELOG で多数駆除済みだが残存） |
| worktree 並列 | worktree 数ぶん Node プロセスが分裂 |
つまり「セッション数 × 1 セッションあたりの基礎消費」だけで見積もると過小評価になり、実際には 基礎消費の 2〜3 倍 を見ておくのが安全側です。
用途別の現実的な推奨スペック
上記を踏まえて、Ghostty / tmux / cmux などの軽量ターミナルベース運用 を前提に、用途別の RAM 目安を整理します。Claude Code 単体の消費ではなく、周辺ツールを含めた実環境のメモリ収支で考えます。
| 用途 | RAM |
|---|---|
| 単一セッション・小規模リポジトリ | 8 GB |
| 単一セッション・通常開発 | 8〜16 GB |
| 並列 2〜3 セッション | 16 GB |
| 並列 4 セッション以上 | 32 GB あった方が安心 |
筆者の体感では、Ghostty + tmux 環境で 16 GB に 4 セッション並べると結構厳しい です。Activity Monitor で見るとスワップが頻発し始めるラインで、長時間運用するとゾンビと Skills のロードが効いて余裕が消えていきます。並列数を増やすなら、32 GB あった方が安心して回せます。
それでも踏む地雷と回避策
スペックを盛っても、Claude Code の運用上で踏みがちな地雷はいくつか存在します。実体験ベースでなく、Issue や公式ドキュメントで確認できる範囲で整理します。
ゾンビプロセスの蓄積。Issue #11122 や #19393 のように、ターミナル終了後も claude プロセスが残ってリソースを掴むパターンです。v2.1.19 で EIO 対応が入りましたが、プラグインや MCP の組み合わせ次第で再発します。定期的に pkill -f claude で掃除する運用が現実的です。
watch モードのプロセス常駐。Claude Code に npx vitest などを起動させると、watch モードでバックグラウンド常駐し続けます。package.json の scripts で vitest --run を強制する形にしておくと事故が減ります。
MCP サーバーの非プロトコル出力。stdio MCP サーバーが標準出力にログを混ぜると、Claude Code 側でバッファが肥大化して RSS が 10 GB を超える問題が v2.1.132 で修正されました。自作 MCP サーバーを使う場合は、ログは必ず stderr に流す設計にすべきです。
Electron 系エディタとの併用。Electron 系エディタを複数ウィンドウ立ち上げる運用は、各ウィンドウあたり数百 MB〜GB 級の消費が積み上がります。Claude Code を並列セッション動かすヘビーユーザーには、Ghostty / Alacritty / WezTerm 等の軽量ターミナル + tmux / cmux の構成が現実的です。
--resume の大量セッション履歴。Issue #23442 のように、セッション履歴が増えると --resume の起動コストが膨らみます。v2.1.30 と v2.1.153 で改善が入っていますが、不要なセッションは定期的に整理しておくと安定します。
npm 経由インストールからネイティブバイナリへ。v2.1.113 以降はネイティブバイナリ起動方式が主流です。公式 setup ページ はネイティブインストーラを推奨しており、Node.js 依存と自動更新の有無で差が出ます。ヘビーユーザーは早めに移行しておくべきです。
まとめ
公式システム要件の「4 GB+ RAM」は Claude Code バイナリが起動するための最小値 であって、公式が同時に推奨する並列セッション・worktrees・Agent Teams ワークフローを快適に回せる数値ではありません。
Anthropic 公式リポジトリの Issue には、120 GB 超まで肥大化した事例や 10 GB 超の RSS 暴走など、本来 CLI ツールでは発生しないはずの極端なメモリ消費がバグとして繰り返し報告されてきました。多くはバグ起因であり、「○ GB あれば安心」という単純な話ではありません。
一方で、CHANGELOG を 14 ヶ月分追うと、リーク駆除・キャッシュキャップ追加・WASM 廃止・ネイティブバイナリ化など、200 件以上の改善 が積まれてきたことが分かります。週 3〜4 件のペースで穴を塞ぎ続けているプロダクトです。
これから PC を購入する場合、単一セッション中心なら 16 GB、並列セッションを 4 つ以上回すなら 32 GB あった方が安心、というのが筆者運用での目安です。公式ドキュメントが沈黙している領域こそ、CHANGELOG と Issue を一次資料として読む価値があります。
