先に要点
- pnpm(`performant npm`)は npm / yarn の代替パッケージマネージャ。` ハードリンクで依存パッケージを共通ストアから貼る` 仕組みで、ディスク使用量を大幅に節約し、インストールも速い。
- `flat な node_modules を作らない` 厳格な依存解決 が特徴で、`使ってないはずのパッケージが require できてしまう npm / yarn の暗黙ホイスト問題` を構造的に解決する。
- Workspaces によるモノレポ対応が標準。複数アプリ・複数ライブラリを1リポジトリで管理する案件で、Turborepo / Nx と組み合わせる事実上の標準。
- 導入コストは低い。`npm` を 「pnpm」に置き換えるだけで多くの場合動く。個人開発でも、ディスク節約と速度のメリットだけで十分採用候補になる。
pnpm って何が違うの？ npm でも yarn でもなくて、わざわざ pnpm を選ぶ意味は？ 「モノレポなら pnpm って言われたけど、なぜ？」 ── Node.js のエコシステムで 「第三のパッケージマネージャ」として、近年急速にデファクト化が進んでいるのが pnpm です。
ざっくり言うと、pnpm は 同じ依存パッケージを毎回コピーするのは無駄、ハードリンクで共有しよう という発想を基本にした、ディスクとインストール時間を節約する Node 向けパッケージマネージャ です。
それだけだとマイナーな最適化に聞こえますが、厳格な依存解決とモノレポ標準対応という設計判断によって、「現代的な Node プロジェクトのデファクト」に近い位置を占めるようになっています。
この記事では、2026年5月時点の pnpm の状況をベースに、何が違うのか・npm / yarn との比較・モノレポでの使い方・採用判断軸 を、「npm / yarn は知っているけど pnpm は触ったことがない」レベルから順に整理します。
pnpm が解決した問題
pnpm を理解する一番の近道は、「npm / yarn のままだと何が困るのか」を押さえることです。
①ディスクが膨らむ
10個プロジェクトがあれば、ほぼ同じ依存が10個コピーされて 10倍のディスクを使う。`プロジェクトごとに `node_modules「 が数百MB」が積み上がる。
② インストールが遅い
毎回ダウンロード + 展開 + コピー。CI でも同じ依存を何度も入れ直す。毎日数時間がインストール待ちで消える 規模のチームもざらにある。
③ flat な node_modules の罠
npm / yarn は依存を 「フラットに巻き上げ(hoist)」するため、「package.json に書いていないパッケージも require できてしまう」状態が起きる。「動いてしまうから直さない」ことが、後で互換性事故を生む。
④ モノレポ対応の弱さ
npm の workspaces はあるが機能不足。yarn workspaces もあるが挙動の癖がある。「複数アプリ + 共通ライブラリ」を1リポジトリで扱うとき、運用が辛くなりやすい。
pnpm は ハードリンクで共通ストアを使う という仕組みでディスクと速度を解決し、「厳格な依存解決」 + 「workspaces」で残りの問題も同時に解決 しました。
1個の道具で複数の困りごとを片付けられるのが、pnpm のシェアが急速に伸びた本質的な理由です。
pnpm の中身 — どうやって速く・軽くしているか
「ハードリンクって何？」を含めて、仕組みを順に押さえます。
グローバルストア
マシン全体で1ヶ所だけ 「~/.local/share/pnpm/store」のようなストアを持ち、ダウンロード済みパッケージはそこに保管される。
ハードリンクで配置
各プロジェクトの 「node_modules」には、「グローバルストアの実体ファイルへのハードリンク」だけが置かれる。複数プロジェクトで同じバージョンを使えば、ディスク上の実体は1つだけ。
非フラットな node_modules
npm / yarn と違って、依存ツリーをそのまま再現する形でディレクトリを切る。「偶然 require できる」を防げる。
速度の理由
① ダウンロードはストアにキャッシュ済み、② 展開もハードリンクなのでコピー不要、③ 並列処理の最適化、の3点で 「2回目以降のインストール」が圧倒的に速い。
要点は 同じ実体を共有しつつ、依存関係はプロジェクトごとに正しく独立させる という、相反しそうな2つを両立させた設計判断にあります。
npm / yarn との比較
3つを並べると違いが立体的に見えます。
| 軸 | npm | yarn (Classic / Berry) | pnpm |
|---|---|---|---|
| ストレージ方式 | プロジェクトごとにコピー | プロジェクトごとにコピー(PnP モード除く) | グローバルストア + ハードリンク |
| node_modules 構造 | フラット(ホイスト) | フラット(ホイスト) | 非フラット(厳格) |
| 未宣言依存への厳格さ | 緩い(require できてしまう) | 緩い | 厳格(エラーにできる) |
| ロックファイル | `package-lock.json` | `yarn.lock` | `pnpm-lock.yaml` |
| Workspaces | あり(機能はそこそこ) | あり(古めの設計) | あり(現代的、CLI が整っている) |
| 速度感(中規模、CI 含む) | 普通 | 普通〜やや速い | 速い |
| シェアの傾向(2026) | 標準として依然強い | 横ばい〜減少 | 上昇基調、特に新規 / モノレポで多い |
要点を一言で言うと、 新しく作るならまず pnpm を検討、既存で動いていれば無理に変えなくていい という感覚です。
特に モノレポ・CI 高速化・ディスク使用量削減 の3つは pnpm が明確に強く、「プロジェクトが大きくなるほど効いてくる」性質があります。
基本コマンド対応表
「npm でこれをやっていた」が pnpm でどうなるかを並べます。
| 用途 | npm | pnpm |
|---|---|---|
| インストール | `npm install` | `pnpm install`(別名 `pnpm i`) |
| 厳密インストール(lockfile固定) | `npm ci` | `pnpm install --frozen-lockfile` |
| 依存追加 | `npm install lodash` | `pnpm add lodash` |
| 開発依存追加 | `npm install -D vitest` | `pnpm add -D vitest` |
| スクリプト実行 | `npm run dev` | `pnpm dev`(`run` は省略可) |
| 一時実行 | `npx create-vite` | `pnpm dlx create-vite` |
| 更新 | `npm update` | `pnpm update` |
| 削除 | `npm uninstall lodash` | `pnpm remove lodash` |
「置き換えるだけ」に近いので、学習コストはほぼゼロです。
CI スクリプトを書き換える、package.json の 「packageManager」フィールドを揃える、くらいの作業で導入できます。
Workspaces とモノレポ運用
pnpm の存在感が大きいのは、 モノレポ運用で扱いやすい workspaces を標準で持っているからです。
リポジトリのルートに 「pnpm-workspace.yaml」を置き、
packages:
- "apps/*"
- "packages/*"
と書くだけで、apps/web 「packages/ui」のような構成を1つの pnpm 管理下に入れられます。
パッケージ間参照
`apps/web/package.json` で 「"@myorg/ui": "workspace:*"」と書けば、「packages/ui」のローカル版が自動でリンクされる。
一括操作
「pnpm -r build」で全パッケージのビルド、「pnpm --filter web dev」で特定アプリだけ起動。Turborepo / Nx と組み合わせる前提でも素直に動く。
依存衝突の少なさ
厳格な依存解決のおかげで、「このパッケージは見えるはず / 見えないはず」が明確。モノレポで起きがちな 「相手の依存が偶然見えている」バグを構造的に防げる。
「Turborepo / Nx を使いたい」が一旦の目標なら、「下回りのパッケージマネージャは pnpm を選んでおく」のが最近の標準的な選択です。 Vercel が AI 時代に勢いを伸ばしている流れ でも、Turborepo + pnpm + Next.js モノレポ、という組み合わせが事実上のデファクト構成になりつつあります。
採用時の注意点
良いことばかりではなく、現場で踏みやすい注意点もあります。
①一部の古い依存と相性が悪い
「非フラットな node_modules」を期待していない古いビルドツールやネイティブ系で、「勝手にフラットだと仮定したコード」が動かない場合がある。「pnpm shamefully-hoist」のような救済オプションもあるが、本質的には 「古い設計の依存を引きずっているサイン」。
② Windows のリンク制約
ハードリンク / シンボリックリンクの権限が絡む環境で稀に問題が出る。WSL や開発者モードで運用するのが安定。
③ チームでの混在
「一部の人だけ npm を使っている」 状態だと、lockfile が混在して事故が起きる。` `packageManager: pnpm@x.y.z`」を 「package.json」に書いて統一 するのが安全。
④ ロックファイルの差分が大きい
「pnpm-lock.yaml」 は変化に応じて差分が大きく見えることがある。レビュー時に 「lockfile の差分は基本そのまま信用する」とルールを決めておくと、レビューコストが下がる。
特に ① の 「古い依存と非フラット node_modules の相性」 は、移行直後に最も遭遇しやすい問題です。 そこさえ越えれば、以降はディスクと CI の節約効果を素直に享受できます。
どんなときに pnpm を選ぶか
採用判断の目安をまとめます。
| 状況 | pnpm の有効度 | 備考 |
|---|---|---|
| 新規 Next.js / Vite プロジェクト | ◎ | 最初から pnpm でほぼ問題ない |
| モノレポ(複数アプリ + 共通ライブラリ) | ◎ | Turborepo / Nx の事実上の前提 |
| 個人プロジェクトを多数持っている | ○ | ディスク節約効果が大きい |
| 既存 npm プロジェクト | ○ | 軽く検証してから乗り換えればOK |
| 古めの依存に強く依存する案件 | △ | shamefully-hoist などで対応するか、現状維持 |
| チームの誰も Node を触っていない | × | そもそも前提が違うので関係ない |
「大規模 / モノレポ / CI 時間が惜しい」ほど、効果がはっきり目に見えます。 逆に 個人の小さなスクリプト でも、「複数プロジェクトを横断するときのディスク節約」だけで十分に意味があり、新規プロジェクトはとりあえず pnpm にしておく、というシンプルな運用が現実的です。
AI 時代の pnpm
AI 時代の開発でも pnpm の価値は変わらない、というよりむしろ強化される面があります。
短いフィードバックループ
AI に指示してコードが出る、依存を追加する、ビルドする、というサイクルを回すと、「インストール待ち」はそのままサイクル時間に効いてくる。「数十秒の差」が積み重なる時代の道具として有利。
複数試行のしやすさ
AI で 「別の構成も試したい」というときに、新プロジェクトを次々作って捨てる運用がしやすい。ディスクが膨らまないので、「試して捨てる」ことに心理的な抵抗が減る。
CI 時間 × AI コスト
AI でテストや CI を自動化していくと、CI の実行回数が増える。pnpm + キャッシュで CI を短縮することは、AI 時代のコスト最適化に直結 する。
モノレポ採用が増える
AI 周辺はパッケージが小さく多数になりがち。「AI SDK + UI + ジョブワーカー」を1リポジトリでまとめる構成が増え、「モノレポに強い pnpm」のシェアは今後さらに伸びる方向。
地味な道具ですが、「触る回数が多い / 試行回数が増える」時代の足回りとして、pnpm の効きどころは増えています。 Bun と並んで、「新しい Node エコシステム」を支える代表的なツールの1つ、というポジションが見えてきています。
pnpm に関するよくある質問
Q. npm から pnpm に移行する手順は？
A. 1) 「pnpm」をインストール、2) 既存の 「package-lock.json」 / 「yarn.lock」を削除、3) 「pnpm install」を実行、4) CI スクリプトを 「pnpm install」に置き換え、5) 「package.json」の 「packageManager」フィールドを 「pnpm@x.y.z」に設定、で完了です。多くの場合これだけで動きます。
Q. yarn から pnpm に移ることは多いですか？
A. はい、増えています。yarn Classic はメンテモード、yarn Berry(v2+)は採用ハードルが残る一方、pnpm は npm 互換性を保ちつつモダンな機能を持つため、「yarn からの自然な移行先」として選ばれるケースが多いです。
Q. ロックファイルは Git に入れるべきですか？
A. 入れるべきです。「pnpm-lock.yaml」は 本番との挙動の同一性を保証する重要なファイル。「commit に含めるかどうか」で迷う場合は、「必ず含める」に固定しておくのが安全です。
Q. モノレポではなく単一プロジェクトでも使うメリットはありますか？
A. あります。「インストールが速い」 「ディスクが小さい」 「厳格な依存解決」だけで十分に価値があります。「単に npm のままでもいいが、変えたら困らない」レベルの低リスク変更です。
Q. pnpm dlx と npx の違いは何ですか？
A. pnpm dlx」が pnpm 流の `一時実行コマンドです。挙動は npx に近く、「一時的にパッケージをダウンロードしてコマンドを実行する」ものです。「npx create-next-app」 → 「pnpm dlx create-next-app」のように対応します。
Q. Bun と pnpm はどちらを使うべきですか？
A. レイヤーが違うので、同時に使えます。Bun はランタイム + ツール群、pnpm はパッケージマネージャです。「Node + pnpm」 と 「Bun + bun install」 のどちらかに揃える運用が一般的で、「本番が Node なら pnpm」 「Bun に寄せるなら bun install」 と分けるとシンプルです。
Q. CI のキャッシュはどう設定すべきですか？
A. 「 ~/.local/share/pnpm/store」のグローバルストアと、node_modulesの両方をキャッシュするのが基本です。GitHub Actions では 「setup-node」 + 「cache」アクションで簡単に組めます。「pnpm install --frozen-lockfile」を CI で使い、ロックファイルとの一致を厳密に保つのが定石です。
参考リンク
- pnpm: 公式サイト
- pnpm: Workspaces
- pnpm: CLI Commands
- pnpm: Motivation
- Turborepo: 公式
- Nx: 公式
- Node.js: 公式