pnpm vs npm vs yarn — 「どれ使えばいい？」をQ&Aで全部答えます【2026年版】
npm・yarn・pnpmどれを選ぶ？フリーランスエンジニアがQ&A形式で徹底回答。2026年の選び方・移行手順・CI/CD設定・初心者向けの結論まで実体験ベースで解説。
※当サイトはアフィリエイトプログラムに参加しています。記事内のリンクから商品を購入すると、当サイトに報酬が支払われることがあります。詳しくはプライバシーポリシーをご覧ください。
「npmでいいじゃん、何が違うの？」
4月に入ってから、この質問を3回もらいました。
フリーランスでReact/Next.jsの案件をやっている中村ソウマです。4月は新規プロジェクトの立ち上げラッシュで、3本のプロジェクトを連続でセットアップしました。3本全部、パッケージマネージャーはpnpmで統一しています。
…2年前までは僕もnpmユーザーでしたが。
「やっぱり標準のnpmが一番安心でしょ」「yarnを長年使ってるから変えたくない」という気持ちはわかります。正直、当時の僕もそうでした。ただ、実際に切り替えてみると「もっと早く変えればよかった」以外の感想が出てこなかった。
というわけで、パッケージマネージャー選びでよくある質問7つをQ&A形式でまとめます。
気になるところだけ読んでOKです。Q1〜Q3が「基本」、Q4〜Q6が「実践」、Q7が「初心者向けまとめ」です。
（書いてたらコーヒー冷めた）
Q1: pnpmとnpm、結局何が違うの？
Q: 「pnpm」と「npm」って機能的には同じじゃないの？わざわざ変える必要ある？
A: やることは同じ（Node.jsパッケージのインストール・管理）です。ただ、仕組みが根本的に違います。この違いが速度とディスク使用量に直結します。
npmの仕組み（コピー型）:
project-a/node_modules/react （実体: 約3MB）
project-b/node_modules/react （実体: 約3MB）
project-c/node_modules/react （実体: 約3MB）
# 計9MB消費pnpmの仕組み（ストア＋シンボリックリンク型）:
~/.pnpm-store/react （実体: 約3MB、ここだけ）
project-a/node_modules/react → シンボリックリンク
project-b/node_modules/react → シンボリックリンク
project-c/node_modules/react → シンボリックリンク
# 計3MB消費（67%削減）グローバルストアに一度だけ保存し、各プロジェクトからはシンボリックリンクで参照します。結果として、プロジェクト数が増えるほど恩恵が大きくなります。
Q2: 2026年に新規プロジェクトを始めるなら何を選ぶ？
Q: 2026年現在、npm・yarn・pnpmのどれを選べばいい？ズバリ教えて
A: 新規プロジェクトならpnpm一択、です。根拠を3つ挙げます。
- 速い: ディスクI/Oが最小限なので、2回目以降のインストールは体感1.5〜2.5倍速（初回キャッシュの有無で変わる）
- 軽い: グローバルストアで共有するため、複数プロジェクト持つほどディスク節約になる（10プロジェクトで試したら40〜70%削減できた、環境によって幅がある）
- 厳格: 後述する「幽霊依存」を防げるため、本番でコケるリスクが減る
「でも既存プロジェクトはnpmだし…」という場合は、Q3で移行の話をします。
パッケージマネージャー別の比較（2026年現在）:
| パッケージマネージャー | 特徴 | おすすめ度 |
|---|---|---|
| pnpm | 速い・軽い・厳格 | ★★★★★ |
| npm | 標準・シンプル | ★★★☆☆ |
| yarn v1 | 安定だが枯れ気味 | ★★☆☆☆ |
| yarn berry (v2+) | PnP採用、独自路線 | ★★★☆☆（用途次第） |
| bun | 激速、オールインワン | ★★★★☆（まだ様子見） |
bunについてはBunとNode.jsを1ヶ月使い比べた報告で詳しく書いているので参考にしてください。
Q3: npm → pnpmの移行、実際どのくらい時間がかかる？
Q: 今まさにnpmを使ってるプロジェクトをpnpmに移行したい。どのくらいかかる？
A: 個人プロジェクトなら30分〜2時間が現実的です。チームプロジェクトはメンバーの調整込みで半日〜1日見ておくといい。
基本の移行手順:
# 1. pnpmをグローバルインストール（初回のみ）
npm install -g pnpm
# 2. 既存のnode_modulesとlock fileを削除
rm -rf node_modules package-lock.json
# 3. pnpmで再インストール
pnpm install
# 4. 以降のコマンドをpnpmに変える
# npm run dev → pnpm dev
# npm install → pnpm install
# npm install react → pnpm add react
# npm install -D typescript → pnpm add -D typescriptほとんどのプロジェクトはこれだけで動きます。pnpm-lock.yamlが自動生成されるので、package-lock.jsonは削除してOKです。
ただし、Q5で話す「詰まりポイント」が1つあるので要注意。
Q4: yarnはもう使わなくていい？
Q: 何年もyarnを使ってきた。もうyarnは”オワコン”なの？
A: yarn v1（Classic）は事実上メンテナンスモードに入っています。新機能の開発が止まっていて、セキュリティ対応だけ継続している状態です。
yarn v2/v3/v4（Berry）は別物で、PnP（Plug’n’Play）という独自方式を採用しています。理念は面白いんですが、既存ツールとの互換性問題が多くて、現場ではあまり普及していない印象です。
ちょっと話逸れるけど——Node.jsのバージョン管理ツールも「どれ使えばいい？」問題があって、nvm vs fnm vs Voltaという構図があります。VoltaはpnpmとGitHubベースのCI/CDとの相性がよくて、プロジェクトごとのバージョン固定がpackage.jsonに書けるので便利です。Node.jsのバージョン管理についてはNode.js入門ガイドでも触れています。
話を戻すと、yarn v1を今から選ぶ理由はないです。既存プロジェクトで使っているなら急いで変える必要はないですが、新規プロジェクトでわざわざyarnを選ぶメリットはほぼありません。
Q5: pnpmで「詰まる」ケースってある？
Q: 正直、pnpmに切り替えて困ったことはない？デメリットも教えて
A: あります。1つだけ「これで2時間弱溶かした」ケースを白状します。
幽霊依存（Phantom Dependency）問題:
pnpmは「package.jsonに宣言されていない依存関係にアクセスできない」仕組みになっています。これが本来はメリット（安全）なんですが、npmからの移行直後に罠になることがある。
具体的には、package.jsonに書いていないのにnode_modulesに入っていたパッケージ（他のパッケージが依存しているもの）を、コードから直接importしていた場合に起こります。
// これがnpmでは動いてたのに、pnpmで動かなくなった
import dayjs from 'dayjs'
// dayjsがpackage.jsonに書かれていない → Error: Cannot find module 'dayjs'npmではnode_modulesがフラット構造なので、依存関係の依存まで全部importできてしまいます。pnpmはこれを厳格にブロックします。
解決策:
# 使っているパッケージをpackage.jsonに明示的に追加するだけ
pnpm add dayjsこれだけです。エラーメッセージを読めばすぐわかるんですが、初見だと「なんで急に動かなくなったの？」となるので気をつけてください。
正直、この問題さえ知っていれば移行は拍子抜けするくらいスムーズです。
Q6: CI/CDでpnpmを設定するときのポイントは？
Q: GitHub ActionsでpnpmをCI/CDに組み込みたい。設定例を教えて
A: 公式がpnpm/action-setupというActionを提供しているので、それを使うのが一番シンプルです。
# .github/workflows/ci.yml
name: CI
on: [push, pull_request]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: pnpm/action-setup@v3
with:
version: 9 # pnpmのバージョンを指定
- uses: actions/setup-node@v4
with:
node-version: '20'
cache: 'pnpm' # pnpmのキャッシュを有効化
- run: pnpm install --frozen-lockfile
- run: pnpm build
- run: pnpm test--frozen-lockfileオプションは「pnpm-lock.yamlが存在しないか内容がpackage.jsonと一致しない場合はエラーで終了する」という挙動です。CIでは必須オプションと思ってください。ローカルで動いたのにCIで落ちる、という原因の多くはlockファイルのずれです。
GitHub Actions全般についてはGitHub Actions入門 2026年版でより詳しく解説しています。
Q7: 初心者は結局どれから始めるべき？
Q: これからプログラミングを学ぶ初心者です。最初からpnpmを使うべき？
A: 最初の1〜2ヶ月はnpmで十分です。
理由はシンプルで、「パッケージマネージャーの違いより先に学ぶべきことがある」から。初心者が最初に当たる壁は「なぜ動かないかわからない」です。この段階でpnpmの独自概念（シンボリックリンク、幽霊依存）まで理解しようとすると、本来の学習が滞ります。
推奨の流れ:
プログラミング学習開始
↓（〜2ヶ月）
npm で十分（基本コマンドに慣れる）
↓（開発に慣れてきたら）
pnpm に移行（コマンドがほぼ同じなので移行コスト低い）npmのコマンドを覚えておけば、pnpmへの移行は「npm → pnpm」に読み替えるだけです。コマンド体系がほぼ同じなので、移行コストはほとんどありません。
独学の進め方全体については独学プログラミングロードマップの記事にまとめています。環境構築の段階でつまずいた経験がある方はぜひ読んでみてください。
まとめ: 3行で答えるなら
- 新規プロジェクト: pnpm一択（速い・軽い・安全）
- 既存プロジェクト（npmから移行）: 30分で完了。詰まるのは幽霊依存だけ
- 初心者: 最初はnpm → 慣れたらpnpmに切り替え
「npm → pnpm」の移行はコマンドを変えるだけで、個人プロジェクトなら30分あれば十分です。チームで採用するときは「幽霊依存のエラーが出たらpnpm add [パッケージ名]するだけ」と事前共有しておくとスムーズです。
TypeScript + Next.jsの環境構築（TailwindCSS込み）でもpnpmを使った設定例を紹介しています。あわせて読んでみてください。
よくある質問
Q: pnpmのインストール方法は？
A: npm install -g pnpmで導入できます。またはcorepack enableしてからcorepack use pnpm@latestでもOKです。Node.js 22以降はcorepackが標準搭載されているので、後者の方が管理がシンプルです。
Q: 「ERR_PNPM_MISMATCHED_LOCKFILE」というエラーが出た
A: pnpm-lock.yamlの内容とpackage.jsonが一致していない場合に出るエラーです。pnpm installを再実行すれば解決します。CIで出た場合は--frozen-lockfileオプションを外してローカルでlockファイルを更新してからコミットしてください。
Q: pnpmはMonorepoでも使える？
A: 使えます。pnpmにはworkspace機能があり、pnpm-workspace.yamlを定義するだけでMonorepo管理ができます。TurborepoやNxとの組み合わせもよく使われる構成です。本文では触れませんでしたが、Monorepoを検討している方は公式ドキュメントの”Workspaces”セクションをチェックしてください。
Q: npmとpnpmは混在して使える？
A: プロジェクト内での混在は推奨しません。package-lock.jsonとpnpm-lock.yamlが両方あると競合します。プロジェクト単位でどちらを使うか統一してください。
Q: pnpmでnode_modulesがなくなるって聞いたけど本当？
A: 正確には「フラットなnode_modulesがなくなる」です。pnpmでもプロジェクト直下にnode_modulesフォルダは存在しますが、中身はシンボリックリンク＋.pnpmフォルダという独自構造になっています。npmと見た目は似ていますが中身が違います。
追記（2026/04/23）: pnpm v9系がリリースされて以降、--frozen-lockfileがCI環境ではデフォルト動作に近づいてきました。またcatalog:機能（モノレポでの依存バージョン一元管理）も安定してきたので、複数パッケージを管理している方はぜひ公式ドキュメントをチェックしてみてください。前回の記事では「MonorepoはBun検討」と書きましたが、pnpm workspacesが十分に使いやすくなった印象です（訂正します）。
プログラミング学習の参考にどうぞ:
