Claude Code のリソースブラックホール: 11.3MB の単一ファイルから 1.2TB のディスク消費へ

Claude Code のクライアントはリソースライフサイクル管理がない Node.js の単一ファイルアプリケーションです。起動時に 11.3MB のパッケージファイルを解析し、実行時にディスクへ無制限に書き込み、ターミナルを閉じてもプロセスが存続し続けてメモリを消費し、システムがクラッシュするまで続きます。GitHub Issues の実際のユーザー報告とコミュニティのリバース分析に基づき、本稿ではメモリ、CPU、ディスクの3つの側面でのリソース管理欠陥を体系的に整理し、パッケージングアーキテクチャ、ストレージ設計、プロセスライフサイクル管理における構造的問題を明らかにします。これらはエッジケースではなく、2025年8月から2026年4月まで継続的にコミュニティが報告し、stale ロボットに大量にクローズされたシステム的なアーキテクチャ欠陥です。

パッケージングアーキテクチャ: 11.3MB の単一ファイルの代償

Claude Code のコアは cli.js という単一ファイルのパッケージ成果物で、サイズは約 11.3MB です。コミュニティメンバー paultendo が Issue #29481 で詳細な静的分析を行い、複数の深刻なアーキテクチャ問題を明らかにしました。

V8 起動時間: 32% が解析に費やされる

CPU プロファイリングにより compileSourceTextModule が起動フェーズの 31.7% のサンプリング時間を消費していることが分かります。V8 エンジンはこの 11.3MB の単一ファイルを解析するのに約 300ms 必要で、裸の Node.js スクリプトの解析時間はわずか 23ms です。追加の 7.3% が spawnSync 呼び出しに、3.5% がガベージコレクションに費やされています。つまり、ユーザーがコマンドを入力する前に、起動時間の 40%以上 が純粋な解析オーバーヘッドに浪費されています。

全量ロード: 動的 import はたった 20 個

パッケージ全体が起動時に完全に解析・実行され、import() 式はわずか 20 個です。すべての機能に対してコストがかかり、使用しない場合でも無駄になります。以下は本来はオンデマンドでロードされるべきコンポーネントです。

pie title パッケージファイル構成 (約 13.5MB)
    "アプリケーションコアロジック" : 7540
    "AWS Bedrock SDK" : 1100
    "highlight.js (182 種類の言語)" : 1000
    "OpenTelemetry" : 900
    "Google Vertex + gRPC + Protobuf" : 800
    "RxJS" : 300
    "その他 (Ink, Zod, Ajv, Axios 等)" : 1807

エンコーディングアシスタントは Brainfuck、MIPS アセンブリ、Flix、Zephir、Inform7、Lasso など 182 種類の言語をハイライトする必要があり、これ自体がパッケージ戦略の粗さを示しています。約 40 種類の一般的な言語だけに絞れば、約 786KB の解析コストを削減できます。

依存の冗長性: 4 つの HTTP クライアント、3 つのバリデーションライブラリ

異なる SDK がそれぞれ独立した依存を導入しており、パッケージ内に 4 つの HTTP クライアント (Axios、Undici、Got、ネイティブ fetch) と 3 つのバリデーションライブラリ (Zod、Ajv、JSON Schema) が同居しています。Node 18+ 環境ではネイティブ fetch が完全に利用可能で、追加の HTTP クライアントは不要です。

413 件の同期ファイルシステム呼び出し

パッケージ内には existsSync が 196 件、statSync が 109 件、readFileSync が 108 件、mkdirSync が 58 件など、合計 413 件の同期ファイルシステム呼び出しが含まれています。各呼び出しはイベントループをブロックします。多くの呼び出しは existsSync(path) && readFileSync(path) のようなパターンで、try { await readFile(path) } catch {} で 1 回の非同期呼び出しに置き換え可能です。

1087 件の CJS/ESM 互換ラッパー

ESM にバンドルされた各 CommonJS モジュールは __toESM/__commonJS/__require 互換パディングを生成し、合計 1087 件になります。これらのパディングは解析重量を増やすだけでなく、各モジュールに微小なランタイムオーバーヘッドをもたらします。

不要な Node 20 ポリフィル

パッケージには 62 件の Promise パディング (Node 0.12 以降ネイティブサポート)、57 件の Symbol パディング (Node 4 以降ネイティブサポート)、57 件の async 変換ヘルパー (Node 8 以降ネイティブサポート)、および 3 件の AbortController ポリフィル (Node 15 以降ネイティブサポート) が含まれています。これらは旧バージョン Node やブラウザ環境向けにコンパイルされたトランジティブ依存から来ており、ターゲットランタイムでは完全に冗長です。

ripgrep が 6 プラットフォームのバイナリをすべてバンドル: 61MB

ripgrep の 6 プラットフォームバイナリがすべてバンドルされ、合計 61MB になります。対照的に、sharp は optional dependencies を正しく使用し、現在のプラットフォームのバイナリのみをインストールします。これにより、各インストールで約 51MB のディスクスペースが無駄になります。

Ink のレンダリング性能は対話長に比例して劣化

ターミナル UI は Ink (React for Terminal) を使用しています。分析によるとコンポーネントツリーに 6457 件の createElement 呼び出し、578 件の useState フックがありますが、React.memo() ラッパーはたった 11 件で、割合は 1.9% に過ぎません。Ink では状態更新ごとに完全な仮想 DOM の調整が走ります。ストリーミング応答中、到着する各トークンが状態更新をトリガーし、メモ化されていないコンポーネントが不要に再描画されます。対話が長くなるにつれ、レンダリング出力が増大し、再描画ごとにより多くのターミナルコンテンツを diff する必要があります。これは Issue #22265 で報告された「セッションが進むにつれて遅くなる」現象と一致します。

ディスクの食い尽くし: GB から TB への無制限増加

ディスク問題は Claude Code の最も深刻なリソース管理欠陥であり、影響範囲が最も広く、結果が最も重大です。

Windows .node ネイティブモジュールのリーク: 週あたり 20GB

Issue #23095 では、数か月間修正されない問題が記録されています。Claude Code の Windows ネイティブバイナリ (claude.exe) は各セッションでシステムの一時ディレクトリにネイティブ Node.js プラグインファイルを抽出しますが、決してクリーンアップしません。各ファイルは約 6.6MB で、ユーザー SlothKing16 は 4 日間で 2813 ファイル、合計 18GB を蓄積しました。ユーザー kolkov の統計はさらに驚くべきで、約 20GB/週、ヘビーユーザーでは 100GB/週に達します。この問題は 2025 年初頭に報告されてから現在まで続き、ロボットに繰り返し「重複」とマークされてクローズされてきました。

~/.claude ディレクトリ: 3GB+ の管理不在

ユーザー kolkov が Issue #5024 で 8 ヶ月間日常使用したマシンを監査しました:

pie title ~/.claude ディレクトリ使用量 (約 3.1GB)
    "projects/ (セッション履歴)" : 2500
    "debug/ (デバッグログ)" : 303
    "file-history/ (ファイルスナップショット)" : 232
    "history.jsonl (全体履歴)" : 10
    "その他" : 55

主な数字: 最大単一セッション JSONL ファイル 203MB、最大サブエージェント JSONL ファイル 72MB、history.jsonl には 37000 件以上のエントリがあります。すべてのデータはローテーションも圧縮もクリーンアップもされていません。file-history/ のスナップショットは重複除去されず、同一ファイルを 10 回編集すると 10 個の完全コピーが保存されます。debug/ ディレクトリのデバッグログも決して削除されません。

バックグラウンドタスクの出力ファイル: 1.2TB の自己参照無限ループ

Issue #32282 は信じがたい設計欠陥を明らかにしました。Claude Code が複数のバックグラウンドエージェントを起動し、進捗チェック用の bash コマンドを自動実行すると、そのコマンドの出力ファイルが glob でマッチした同一ディレクトリに書き込まれ、自己参照の無限フィードバックループが形成されます:

flowchart LR
    A["bash: for f in tasks/*.output; tail -5 $f"] --> B["出力を書き込む tasks/task-A.output"]
    B --> C["glob が task-A.output 自身にマッチ"]
    C --> D["tail -5 が自身の出力を読み取る"]
    D --> E["自身に追記"]
    E --> C

複数のユーザーが同様の問題を報告しています: 1.2TB、460GB、303GB、235GB、480GB、36GB。この issue のコメント者は関連する open issue を 70 件集計し、15 グループに分類しました。上位 2 グループだけで約 9.5TB のディスク消費が報告されています。書き込み速度は 425MB/s に達し、18 分間続き、ディスクが枯渇するまで続きました。

カスケード障害: ディスクが満杯になった後の不可逆クラッシュ

Issue #24207 はディスクが満杯になった後の災害的連鎖反応を記述しています:

flowchart TD
    A["ディスク容量 = 0"] --> B[".claude.json の書き込み失敗"]
    B --> C["ゼロ長ファイルが生成"]
    C --> D["無効な JSON として読み取られる"]
    D --> E["すべてのプロジェクト設定が上書き"]
    E --> F["OAuth/API トークンが破損"]
    F --> G["再認証が必要"]
    G --> H["すべての実行中エージェント/セッションが停止"]
    H --> I["ディスク空きが回復しても復旧不可"]

警告もなく、優雅な降格もなく、復旧パスもありません。ユーザーはすべてのプロセスを手動で終了し、ディスク領域を手動で解放し、設定を手動で復元し、再認証し、すべての設定を再構成しなければなりません。

同時書き込み: ロックなし、トランザクションなし、調整なし

~/.claude/ ディレクトリ内の唯一のロックファイルは .update.lock（5 バイト）です。その他すべてのファイル書き込みには保護がありません。複数の Claude Code プロセスが同時に実行されると（エージェント + サブエージェントは通常の使用シナリオ）、共有ファイルへの書き込みに全く調整が取られません:

Windows では状況がさらに悪化します。原子的書き込みの回避策（先に .tmp に書き込み、rename()）が Windows では失敗し、対象ファイルが他プロセスにロックされていると rename() が EPERM を返し、原子性が完全に失われます。

メモリと CPU: 13GB RSS からカーネルパニックへ

Windows の極端なメモリ消費

Issue #24840 は Windows での極端なケースを記録しています。RSS が 13.21GB、仮想メモリコミットが 47.17GB で、マシンの総メモリは 42.56GB しかありません。ページフォルトは 375 万回に達し、継続的なディスク I/O が行われています。実行時間 347 秒のうち、ユーザーモード CPU 時間はわずか 35 秒で、約 90% が I/O とスワップ待ちに費やされています。その結果、他のアプリケーション（例: Opera ブラウザ）は全く応答しなくなります。

macOS カーネルパニック

Issue #39253 はさらに深刻な結果を報告しています。MacBook Pro M3 Pro（18GB RAM）で複数の Claude Code インスタンスを実行すると macOS がカーネルパニックを起こします。2 種類のパニックが観測されました：Jetsam OOM キル（メモリ圧迫で macOS が重要な watchdogd プロセスを殺す）と watchdog タイムアウト（watchdogd がシステムリソース飢餓で 90+ 秒間ハートビートを送れない）。システムは警告なしに直接再起動し、エラーダイアログも保存された作業も表示されません。

プロセスの孤児化: ターミナルを閉じても存続

Issue #44507（2026 年 4 月、数日前）は基本的なライフサイクル管理欠陥を報告しています。ターミナルウィンドウを閉じても Claude Code プロセスが存続し続けます。孤立したプロセスは 21 日間で 35.4GB RSS、CPU 使用率 95.5% を消費しました。原因はメイン CLI エントリーポイントに process.stdin.on("end") ハンドラがなく、55 以上の setInterval タイマー（ポーリング、テレメトリ、ステータスバー更新など）が Node.js イベントループを無限に生存させていることです。V8 ヒープは制限なく増大し、アイドル GC 圧力もなく、--max-old-space-size の制限も、自己終了ウォッチドッグもありません。

100% CPU フリーズ

Issue #27415 は TaskStop が引き起こす 100% CPU フリーズを報告しています。原因は Bun ランタイム内の posix_spawn の制御不能ループです。Issue #26224 は大量のプロンプト処理時に Claude Code が 5〜20 分間ハングする問題を報告しています。

フラットファイルアーキテクチャの体系的失敗

割り当ててクリーニングしない: すべての issue に共通するパターン

コミュニティメンバー kolkov は複数の issue で繰り返し指摘しています。すべての問題の根本原因は同じです：

この .node リークは単なるバグではなく、繰り返し現れるアーキテクチャパターンの症状です。Claude Code はリソースを割り当ててもクリーニングしません。

2025 年から 2026 年にかけて、問題は .claude.json の単一ファイル膨張から JSONL ファイルの分散膨張へと進化しましたが、根本的なアーキテクチャは変わっていません：フラットファイル、ロックなし、トランザクションなし、クリーンアップなし、圧縮なし。

SQLite とローカルデーモン: コミュニティの代替案

コミュニティはフラットファイルストレージの代替として SQLite の使用を何度も提案しています。SQLite データベースはすべての問題を同時に解決できます：WAL モードは同時読み取りと単一書き込みの原子性を提供し、トランザクションはセッション書き込みの全体性を保証し、組み込み圧縮、TTL クリーンアップ、コンテンツ重複除去、クロスプラットフォームの一貫性を提供します。

別の提案はローカルデーモン（LSP サーバーや Docker のアーキテクチャに似た）を導入し、すべての Claude Code プロセスが IPC で通信し、ストレージバックエンドを変更せずに調整を提供することです。

コミュニティのリバースエンジニアリングと stale ロボットの比較

コミュニティメンバー gebeer のコメントは現状を的確に要約しています：

詳細な分析をありがとう。これはメンテナーがずっと前にやるべきことだった。

kolkov はさらに指摘しています：

皮肉なことに、コミュニティは実質的に彼らのデバッグを代行している——リバースエンジニアリングでコードを混乱させ、エラーパスを追跡し、コードスニペット付きの修正案を提示する——しかし回答は 60 日後にすべてをクローズする stale-issue ロボットです。

同種ツールのリソース管理比較

GitHub Copilot は VS Code 拡張として実行され、拡張ホストのメモリ制限とライフサイクル管理の制約を受けます。Cursor は VS Code のフォークで、同様のリソース管理フレームワークを継承しています。両者のストレージは SQLite などのデータベースを使用し、同時実行とトランザクションを自然にサポートします。Claude Code は独立プロセス＋フラットファイルという選択をしましたが、独立プロセスに期待されるリソース管理責任（メモリ上限、ディスククオータ、プロセスウォッチドッグ、優雅な終了）を実装していません。実際の挙動はプロトタイプデモに過ぎず、プロダクション環境向けツールとは言えません。

モデル能力とエンジニアリング品質のパラドックス

11.3MB の単一ファイルパッケージ、413 件の同期ファイルシステム呼び出し、1087 件の CJS/ESM 互換ラッパー、リソースクリーニングなし、同時実行制御なし、ディスク容量監視なし——これらはエッジケースではなく、システム的なアーキテクチャ欠陥です。2025 年 8 月の Issue #5024 から 2026 年 4 月の Issue #44507 まで、コミュニティは同様の問題を継続的に報告し、詳細な分析と修正提案を提供していますが、多くの issue は「not planned」とマークされ、stale ロボットに自動クローズされています。AI コーディングツールでありながら、そのコード品質はコミュニティが監査・修正しなければならないというのは、深く考えるべきパラドックスです。

もし Claude Code を使用しているなら、定期的に ~/.claude ディレクトリのサイズをチェックし、.node ファイルの一時ディレクトリをクリーンアップし、ターミナルを閉じる前に Ctrl+C で正しく終了することを推奨します。ディスク容量が突然消失した場合、原因を探す手がかりはこれで少なくとも分かります。

• ←前へ
• 次へ→