npm キャッシュと古い node_modules フォルダーが Mac の容量を圧迫している場合、まず共有 npm キャッシュとプロジェクトローカルの依存関係を分けて考えましょう。キャッシュをクリアする前に内容を確認し、再インストールの準備ができているか、そのプロジェクトをもう必要としない場合にのみ、古い node_modules フォルダーを削除してください。
この区別が重要なのは、npm cache と node_modules が異なる問題を解決しているからです。それぞれクリーンアップの影響も異なります。
一方は再利用可能なパッケージキャッシュです。もう一方はプロジェクトが実際に実行に使用する依存ツリーです。これらをひとつの破棄可能なまとまりとして扱うと、開発者は手っ取り早く容量を回復したあと、間違った環境を再構築する羽目になります。
基本ルール: 共有キャッシュは容量回復のためにクリア。node_modules はプロジェクトレベルの再構築コストが許容できる場合にのみ削除。
簡潔な回答
- 本当の問題が
~/.npmなのか、プロジェクト単位のnode_modulesなのか、その両方なのかを確認する。 - キャッシュの完全消去に飛びつく前に
npm cache verifyを実行する。 npm cache clean --forceは、ディスク容量の回復が再ダウンロードのコストに見合う場合にのみ使用する。node_modulesは、安全に再インストールできるプロジェクトか、もうアクティブに使用していないプロジェクトでのみ削除する。- アクティブなワークスペースに手を付ける前に、古いリポジトリ、アーカイブ済みのブランチ、放棄されたデモを確認する。
- npm が問題の一部にすぎない場合、フォルダーサイズだけでなく、エコシステム単位で開発者ストレージを確認する。
node_modules はサイズの圧迫度が似ていても、同じクリーンアップ判断ではありません。
Mac で npm キャッシュと node_modules が急速に増大する理由
JavaScript 開発者のマシンが単一のプロジェクトだけで容量不足になることはめったにありません。本当のパターンは蓄積です。
複数のアプリ、ブランチ、プロトタイプ、クライアントリポジトリにわたってパッケージをインストールします。npm は再インストールのたびにすべてを最初から取得しなくて済むよう、再利用可能なキャッシュを保持します。各プロジェクトも独自のローカル依存ツリーを node_modules に保持します。
つまり、ディスクの増大は同時に2つの方向から起こり得ます：
- 新しいパッケージやバージョンをインストールするたびに拡大し続ける共有 npm キャッシュ
- それぞれ独自の
node_modulesツリーを持つ複数のプロジェクトフォルダー - 古いリポジトリ間での重複またはほぼ重複する依存関係
- 技術的には破棄可能でも再構築コストがかかるネイティブモジュールやツールチェインパッケージ
- アーカイブも削除もクリーンな再インストールもされなかった古いプロジェクト
結果はおなじみです：1つのリポジトリならまだし、10個のリポジトリでコストがかさみ、1年間の通常業務が気づかないうちにストレージ問題に変わります。
npm キャッシュ vs node_modules：違いは何か？
これが最も重要な区別です。
npm の公式ドキュメントによると、キャッシュファイルは Posix システムではデフォルトで ~/.npm に配置され、ローカルインストールは現在のパッケージルート下の ./node_modules に入ります。npm はまずパッケージをキャッシュにロードし、その後それを必要とするプロジェクトの node_modules に展開します。
| 項目 | Mac での一般的な場所 | 目的 | デフォルトで安全？ | 主なクリーンアップの影響 |
|---|---|---|---|---|
| npm キャッシュ | ~/.npm | npm が使用する共有パッケージダウンロードキャッシュ | ディスク容量の回復が目的であれば通常は安全 | 今後のインストールでパッケージの再ダウンロードが必要になる可能性 |
| node_modules | project-root/node_modules | 特定プロジェクトのインストール済み依存ツリー | 状況による | プロジェクトの再インストール、リビルド、または再リンクが必要 |
だからこそ「npm が容量を圧迫している」というだけでは対応を判断できません。圧迫の原因が共有キャッシュなのか、古いプロジェクトのインストールなのか、その両方なのかを知る必要があります。
npm 公式ドキュメントから読み取れること
npm キャッシュはキャッシュとして設計されており、プロジェクトの実行用依存ツリーではありません。npm はキャッシュを後から再取得可能なものとして明示的に文書化しています。
node_modules は異なります。このフォルダーにはプロジェクトのパッケージ、実行ファイル、ローカル依存グラフが実際に存在します。これを削除するということは、単なるキャッシュクリアではなく、プロジェクトが現在使用しているインストール済み依存関係を削除することを意味します。
Mac で npm キャッシュを削除しても安全ですか？
通常は安全ですが、理由が重要です。
npm の公式ドキュメントでは、キャッシュは整合性が検証されており、クリアは基本的にディスク容量の回復が目的の場合にのみ必要だと述べています。これは重要な位置づけの違いです。npm キャッシュは貴重な状態として扱うべきではありませんが、存在するというだけで日常的にワイプする必要もありません。
安全な考え方は次のとおりです：
- Mac の空き容量が厳しい場合、キャッシュのクリーンアップは合理的なトレードオフになります
- インストールが正常に機能している場合、キャッシュのワイプは不要なことが多いです
- キャッシュをクリアした場合、後のインストールでパッケージが再ダウンロードされると想定してください
- まずキャッシュの状態を確認したいだけなら、
npm cache verifyを使用します
より良い最初の一歩：クリアの前に検証する
npm は npm cache verify を既存キャッシュ内容のオフライン検証ステップとして文書化しています。そのため、容量を回復する前のリスクの低い確認として、これがより良い最初のコマンドです。
npm cache verify具体的にディスク容量を解放したい場合、npm のドキュメントに記載されたクリーンアップコマンドは次のとおりです：
npm cache clean --force--force フラグは設計上必須です。npm はキャッシュのクリアを日常的なメンテナンスではなく、意図的なディスク容量の決定として扱います。
Mac で node_modules を削除しても安全ですか？
状況によりますが、ここでは文脈がはるかに重要になります。
node_modules を削除すると、そのプロジェクトのローカル依存ツリーが失われます。プロジェクトがアクティブな場合、即座に影響が現れます：スクリプトがパッケージを見つけられなくなり、ローカルバイナリが node_modules/.bin から消え、次回のインストールやビルドに想定以上の時間がかかります。
だからといって、絶対に削除してはいけないというわけではありません。意図的に削除すべきだということです。
node_modules の削除に適したケース：
- もうアクティブに実行していない古いプロジェクト
- 後で再構築できる古いデモやプロトタイプ
- これからクリーンに再インストールする予定のリポジトリ
- 信頼できるロックファイルがあり、再インストールが予期され許容されるプロジェクト
摩擦が大きいケース：
- 期限やデモ、リリースビルドを控えたアクティブな作業リポジトリ
- 再構築に時間がかかるネイティブモジュールを含むプロジェクト
- 数ヶ月触っておらず、迅速に復元する方法を覚えていないワークスペース
- クリーンな依存関係の管理ができていない、または期待されるロックファイルがないリポジトリ
プロジェクトクリーンアップのルール: node_modules の削除は無害なキャッシュ整理ではなく、ワークスペースのリセットです。
古い node_modules フォルダーがこれほど負荷になる理由
1つのプロジェクトなら管理可能です。本当の無駄は、それが多数あることから生じます。
古いリポジトリはそれぞれ、完全な依存ツリー、パッケージマネージャーのメタデータ、オプションのネイティブパッケージ、フレームワークのツールチェイン、バージョン固有の成果物を保持できます。だからこそ開発者は npm が問題だと思いがちですが、実際には引退したリポジトリに散らばる忘れられた node_modules フォルダーの山の方が大きな原因であることが多いのです。
npm キャッシュを手動でクリアする方法
手動で行う場合は、範囲を絞り、明示的に操作しましょう。
1. アクティブなキャッシュディレクトリを確認する
以前に npm 設定を変更した場合、キャッシュがデフォルトの場所にない可能性があります。まず npm に確認しましょう：
npm config get cache2. 削除する前にキャッシュを検証する
まずドキュメントに記載された検証ステップを使用します：
npm cache verify3. 実際に容量が必要な場合のみキャッシュをクリアする
ディスク容量の回復が後の再ダウンロードに見合う場合：
npm cache clean --force4. 必要に応じてサイズを再確認する
キャッシュパスがわかれば、サイズを直接確認できます：
du -sh "$(npm config get cache)"これがより安全な手順です。場所の確認、検証、クリーンアップを別々の判断として分けているからです。
何かを削除する前に古い node_modules フォルダーを見つける方法
通常、これはより価値の高いクリーンアップ作業です。
まず、アクティブにビルドしていないプロジェクトから始めましょう。Finder で文脈なく一番大きなフォルダーを探すよりも、こちらが重要です。
次のような確認順序を使用しましょう：
- メインのプロジェクトディレクトリ内の
node_modulesフォルダーを検索する。 - どのリポジトリが古いか、アーカイブ済みか、再インストールが容易かを確認する。
- そのプロジェクトが今週ローカルで動かす必要があるかどうかを確認する。
- 再構築のコストが理解できる
node_modulesフォルダーのみを削除する。
ターミナルを使った確認を行いたい場合、何かを削除する前にフォルダーの実際の場所を表示するコマンドを使用しましょう：
find ~/Projects -type d -name node_modules -prune -print
find ~/Projects -type d -name node_modules -prune -exec du -sh {} +これでも手動ですが、巨大な作業フォルダーに感情的に反応するよりは良いアプローチです。
プロジェクトの node_modules を削除する前に確認すべきこと
- そのリポジトリはまだアクティブか？
- 期待通りのロックファイルがあるか？
- 再インストールを遅くするネイティブモジュールやコード生成ステップがあるか？
- プロジェクトは気軽に扰乱したくないモノレポやワークスペース設定の一部か？
node_modulesだけを削除するより、引退したプロジェクト全体をアーカイブまたは削除する方が良いクリーンアップではないか？
多くの場合、最も効果的なクリーンアップは「どこでも依存関係をワイプする」ことではなく、「もう必要ない古いプロジェクトを削除する」ことです。
yarn、pnpm、bun のキャッシュについては？
この部分は npm とは別に考えましょう。
プロジェクトが別のパッケージマネージャーを使用している場合、npm コマンドがそのまま適用できると仮定せず、そのパッケージマネージャー独自のクリーンアップモデルを使用してください。
Yarn
最新の Yarn は yarn cache clean を共有キャッシュファイルを削除するコマンドとして文書化しています。また、より広範なクリーンアップスコープとして --mirror と --all も提供しています。
yarn cache cleanpnpm
pnpm は npm のキャッシュパターンではなくストアモデルを使用します。pnpm の公式ドキュメントでは、pnpm store prune はストアから参照されていないパッケージを削除し、必要に応じて今後のインストールで削除されたパッケージを再ダウンロードできると説明しています。
pnpm store pruneBun
Bun はデフォルトで ~/.bun/install/cache にグローバルパッケージキャッシュを保持すると文書化しています。また、ダウンロード後もパッケージは node_modules にコピーされると記載されているため、フォルダーサイズだけで見ると、Bun も同じ「キャッシュ＋プロジェクトインストール」の混乱を引き起こす可能性があります。
重要なのは、すべてのコマンドを暗記することではありません。ストレージモデルを混同しないことです。npm キャッシュ、Yarn キャッシュ、pnpm ストア、Bun キャッシュは関連する問題ですが、同じものではありません。
エコシステム単位で確認する方が開発者クリーンアップが安全な理由
node_modules は Mac における開発者ストレージ問題の唯一の原因になることはめったにありません。通常は Xcode データ、シミュレーターストレージ、Docker イメージ、ビルドキャッシュ、ログ、その他のツールチェイン固有のパスと隣り合っています。
通常のファイルブラウザーはフォルダーが大きいことを示せますが、それが次のどれかは教えてくれません：
- 再構築可能な npm キャッシュ
- アクティブなワークスペースの依存ツリー
- pnpm ストア
- Docker キャッシュ
- プロジェクト近くにたまたま存在する別のエコシステム
だからこそ、開発者クリーンアップはエコシステムを認識したワークフローで行う方が効果的です。
実際の状況が「npm に加えて Docker、古い Xcode データ、古いリポジトリが多すぎる」というものであれば、フォルダーを一つずつ追跡するより、このようなより広範な確認優先モデルの方が役立ちます。
まとめ
npm キャッシュと node_modules が Mac の容量を圧迫している場合、同じクリーンアップ対象として扱わないでください。
共有キャッシュには npm cache verify を使用し、容量回復が実際の目的である場合に npm cache clean --force を実行します。古い node_modules フォルダーはプロジェクトごとに確認し、再インストールのコストを理解した上でのみ削除してください。
これがより安全なアプローチです：キャッシュとワークスペースの状態を分け、アクティブなプロジェクトの前に古いプロジェクトを確認し、開発者クリーンアップを盲目的なフォルダー削除ではなくエコシステムの文脈に結びつけましょう。
よくある質問
Mac における npm キャッシュとは何ですか？
npm キャッシュは、npm が Mac 上に保持するパッケージのダウンロードキャッシュです。キャッシュ設定を変更していない限り、通常は ~/.npm に格納されています。node_modules に保存されるプロジェクトの依存関係とは別物です。
Mac で npm キャッシュを削除しても安全ですか？
ディスク容量の回復が目的であれば、通常は安全です。npm の公式ドキュメントでもキャッシュは再構築可能と位置づけられており、容量の回復が本当の目的である場合にのみクリアを推奨しています。今後のインストールでパッケージを再ダウンロードできるからです。
Mac で node_modules を削除しても安全ですか？
状況によります。node_modules を削除すると、そのプロジェクトのインストール済み依存関係がすべて失われます。再インストールの準備ができている場合か、プロジェクトが古くて再構築のコストを気にしなくてよい場合にのみ実行してください。
古い node_modules フォルダーがこれほど容量を消費するのはなぜですか？
各プロジェクトは独自の依存ツリー、ビルド関連パッケージ、ネイティブモジュール、バージョン固有の成果物を保持できます。多くのリポジトリにわたって、この重複したローカルインストールのフットプリントが急速に蓄積されていきます。
npm キャッシュと node_modules の違いは何ですか？
npm キャッシュは npm の共有ダウンロードキャッシュであり、node_modules はアプリが実際に実行時に使用するプロジェクトローカルの依存関係フォルダーです。前者は再利用可能なキャッシュ、後者は特定プロジェクトのインストール済み依存ツリーです。