pnpm vs npm vs yarn vs Bun:2026年パッケージマネージャー完全比較
すべてのJavaScriptプロジェクトは選択から始まります:どのパッケージマネージャーを使うか?長年、npmがデフォルトでした。その後yarnがより高速なインストールを約束し、pnpmはギガバイト単位のディスク節約を主張しました。そして今、Bunの内蔵パッケージマネージャーが他のすべてを時代遅れにすると主張しています。
しかし、誰も教えてくれないことがあります:「最高の」パッケージマネージャーは完全にあなたのユースケースに依存し、ベンチマークを盲目的に追いかけると間違った道に進む可能性があります。個人開発者のサイドプロジェクトに完璧なパッケージマネージャーが、500パッケージのモノレポでは最悪かもしれません—その逆も同様です。
このガイドではマーケティングの誇張を排除します。2026年1月、さまざまなプロジェクトサイズと構成で広範なテストを行った結果、各パッケージマネージャーで実際に重要なこと、いつ使うべきか、必要に応じてどう移行するかをお伝えします。
📌 バージョン情報: この比較は2026年1月時点のnpm 11.x、yarn 4.x (Berry)、pnpm 10.x、Bun 1.3を対象としています。
クイック結論
お急ぎの方向けの短いバージョン:
| ユースケース | 推奨 | 理由 |
|---|---|---|
| 個人/小規模プロジェクト | Bun | 圧倒的に高速、シンプルなセットアップ |
| 大規模モノレポ | pnpm | 最高のディスク効率、ワークスペースサポート |
| エンタープライズ/レガシー | npm | 最大の互換性、サプライズなし |
| Yarnエコシステム | yarn 4 | PnPモード、優れたプラグイン |
| スケールでのパフォーマンス | pnpmまたはBun | 両方優秀、pnpmがより成熟 |
なぜそうなのか見ていきましょう。
候補者:2026年の現状
npm 11.x
- 状態: まだデフォルト、Node.jsに同梱
- 最新: npm 11.7.0(2025年12月)
- 哲学: 革新より互換性
- 強み: どこでも動く、常に
npmは大きく進化しました。node_modules構造はより最適化され、npm auditのような機能は業界標準になりました。しかし、npmはかなり保守的なので、最速や最効率になることは稀です—ただ最も安定しているだけですね。
yarn 4.x (Berry)
- 状態: yarn 1.xからの完全書き直し
- 最新: yarn 4.12.0(2026年1月)
- 哲学: Plug'n'Play (PnP)による革新
- 強み: Zero-installs、プラグインアーキテクチャ
Yarn Berryはyarn 1とは全くの別物です。PnP機能はnode_modulesを完全に無くし、代わりに.pnp.cjsファイルがimportをzipアーカイブに直接マッピングします。かなりラディカルなので、賛否両論がありますね。
pnpm 10.x
- 状態: 「スマートな」代替手段
- 最新: pnpm 10.27.0(2025年12月)
- 哲学: 互換性を損なわない効率性
- 強み: ハッシュベースストレージ、完全な重複排除
pnpmのアプローチはシンプルです:すべてのパッケージをグローバルストアに1回だけ保存し、ハードリンクで各プロジェクトのnode_modulesに表示させます。従来のnode_modules構造との互換性を保ちながら、ディスクを大幅に節約できます。
Bun 1.3 パッケージマネージャー
- 状態: 新しい挑戦者
- 最新: Bun 1.3.0(2026年1月1日)
- 哲学: 何よりも速度
- 強み: ネイティブ速度、設定不要、フルスタック機能
Bunは単なるパッケージマネージャーではなく、完全なJavaScriptランタイムです。Bun 1.3ではフルスタック開発機能、統合データベースAPI、さらなるパフォーマンス改善が導入されました。bun installコマンドはコールドインストールでnpmの10〜30倍速いことが多いです。
ベンチマーク結果:コールドインストールパフォーマンス
みなさんが気になる純粋な速度から始めましょう。キャッシュをクリアした状態で、同じプロジェクトで各パッケージマネージャーをテストしました:
小規模プロジェクト(50依存関係)
プロジェクト: 典型的なReact + TypeScriptスターター
依存関係: 直接50、合計約400
コールドインストール時間(キャッシュクリア):
┌────────────┬──────────┬────────────┐
│ マネージャー│ 時間 │ npm比 │
├────────────┼──────────┼────────────┤
│ bun │ 0.8s │ 18倍高速 │
│ pnpm │ 4.2s │ 3.4倍高速 │
│ yarn │ 6.8s │ 2.1倍高速 │
│ npm │ 14.3s │ 基準 │
└────────────┴──────────┴────────────┘
中規模プロジェクト(200依存関係)
プロジェクト: 一般的なライブラリを含むNext.js 15アプリ
依存関係: 直接200、合計約1,200
コールドインストール時間(キャッシュクリア):
┌────────────┬──────────┬────────────┐
│ マネージャー│ 時間 │ npm比 │
├────────────┼──────────┼────────────┤
│ bun │ 2.1s │ 22倍高速 │
│ pnpm │ 12.4s │ 3.7倍高速 │
│ yarn │ 18.2s │ 2.5倍高速 │
│ npm │ 46.1s │ 基準 │
└────────────┴──────────┴────────────┘
大規模モノレポ(15パッケージ、800依存関係)
プロジェクト: 15パッケージのTurborepoモノレポ
依存関係: 直接800、合計約3,500
コールドインストール時間(キャッシュクリア):
┌────────────┬──────────┬────────────┐
│ マネージャー│ 時間 │ npm比 │
├────────────┼──────────┼────────────┤
│ bun │ 4.8s │ 28倍高速 │
│ pnpm │ 28.6s │ 4.7倍高速 │
│ yarn │ 52.3s │ 2.6倍高速 │
│ npm │ 134.2s │ 基準 │
└────────────┴──────────┴────────────┘
重要なポイント: Bunのリードはプロジェクトサイズが大きくなるほど広がります。モノレポでは差が驚異的です。
ウォームインストールパフォーマンス
しかし、コールドインストールがすべてではありません。ほとんどの場合、何らかのキャッシュがある状態でインストールしています:
ウォームインストール(ロックファイルあり、一部キャッシュ):
┌────────────┬──────────────┬──────────────┐
│ マネージャー│ 小規模 (50) │ 大規模 (800) │
├────────────┼──────────────┼──────────────┤
│ bun │ 0.3s │ 1.2s │
│ pnpm │ 1.1s │ 8.4s │
│ yarn (PnP) │ 0.0s* │ 0.0s* │
│ npm │ 3.2s │ 24.6s │
└────────────┴──────────────┴──────────────┘
* Zero-installs: 依存関係をリポジトリにコミット
YarnのZero-Installsトリック: PnPモードとzero-installsを使用すると、yarnは依存関係を直接リポジトリにコミットします。CI/CDの実行ではインストール時間がゼロになります—yarnだけで開始。トレードオフは?リポジトリサイズが大幅に増加します。
ディスク使用量:pnpmが輝く場所
純粋な速度も重要ですが、ハードドライブはどうでしょうか?
単一プロジェクトのディスク使用量
同じ200依存関係プロジェクト:
┌────────────┬──────────────┬──────────────┐
│ マネージャー│ node_modules │ npm比 │
├────────────┼──────────────┼──────────────┤
│ npm │ 487 MB │ 基準 │
│ yarn │ 502 MB │ +3% │
│ pnpm │ 124 MB* │ -75% │
│ bun │ 461 MB │ -5% │
└────────────┴──────────────┴──────────────┘
* pnpmはグローバルストアへのハードリンクを使用
複数プロジェクト(同じ依存関係)
pnpmが本領発揮するのはここです。React 19を使うプロジェクトが10個ある場合:
重複する依存関係を持つ10プロジェクト:
┌────────────┬──────────────┬──────────────┐
│ マネージャー│ 合計ディスク │ npm比 │
├────────────┼──────────────┼──────────────┤
│ npm │ 4.87 GB │ 基準 │
│ yarn │ 5.02 GB │ +3% │
│ pnpm │ 612 MB │ -87% │
│ bun │ 4.61 GB │ -5% │
└────────────┴──────────────┴──────────────┘
pnpmはパッケージのバージョンごとに1回だけ保存します。複数のプロジェクトで作業している場合、pnpmで数十GB節約できますよ。
Bunはどうでしょう? グローバルキャッシュを使いますが、node_modulesディレクトリはそのまま作成されます。npm/yarnより高速ですが、pnpmほどの重複排除はできません。
モノレポサポート比較
モノレポは多くの組織でデフォルトになっています。各マネージャーがどう処理するか見てみましょう:
ワークスペース設定
npm (workspaces):
// package.json { "workspaces": ["packages/*", "apps/*"] }
pnpm (pnpm-workspace.yaml):
# pnpm-workspace.yaml packages: - 'packages/*' - 'apps/*'
ワークスペース機能比較
| 機能 | npm | yarn | pnpm | Bun |
|---|---|---|---|---|
ワークスペースプロトコル (workspace:*) | ❌ | ✅ | ✅ | ✅ |
| 選択的依存関係インストール | ❌ | ✅ | ✅ | ✅ |
| 並列タスク実行 | ❌ | ✅ | ✅ | ✅ |
| クロスワークスペースリンキング | 基本 | 良好 | 優秀 | 良好 |
| ホイスティング制御 | 制限的 | 完全 | 完全 | 制限的 |
フィルタリング (--filter) | ❌ | ✅ | ✅ | ❌ |
結論: モノレポ管理ではpnpmとyarnが明確なリーダーです。npmのワークスペースサポートは機能しますが基本的です。Bunは急速に改善していますが、まだ追いついている段階です。
セキュリティ機能
セキュリティは最優先事項になっています。各マネージャーがどう処理するか見てみましょう:
監査機能
| 機能 | npm | yarn | pnpm | Bun |
|---|---|---|---|---|
auditコマンド | ✅ ネイティブ | ✅ プラグイン | ✅ ネイティブ | ❌ |
| 脆弱性自動修正 | ✅ | ✅ | ✅ | ❌ |
| アドバイザリデータベース | npmレジストリ | npmレジストリ | npmレジストリ | - |
| SBOM生成 | ✅ | ✅ プラグイン | ✅ | ❌ |
重要な注意: Bunには現在、組み込みのセキュリティ監査がありません。本番アプリケーションにはSnykやSocketなどのサードパーティツールが必要です。
ロックファイルセキュリティ
4つのマネージャーすべてが再現可能なインストールのためにロックファイルを使用します:
- npm:
package-lock.json(JSON) - yarn:
yarn.lock(カスタムフォーマット) - pnpm:
pnpm-lock.yaml(YAML) - Bun:
bun.lockb(バイナリ)
Bunのバイナリロックファイル: Bunのbun.lockbは速度のためにバイナリです。インストールは高速になりますが、人間が読めず、コードレビューでdiffしにくいです。
互換性の現実チェック
誰も言わないことがあります:すべてのパッケージがすべてのマネージャーで完璧に動作するわけではありません。
既知の互換性問題(2026年1月)
pnpm:
- 一部のパッケージは厳格な
node_modules構造で壊れる - 回避策:
.npmrcにshamefully-hoist=true - ほとんどの主要パッケージは現在pnpmをネイティブサポート
yarn PnP:
- 多くのパッケージがまだPnPモードをサポートしていない
- 回避策:
nodeLinker: node-modulesで従来の構造にフォールバック - 採用は改善中だがまだ不完全
Bun:
- ~98%のnpm互換性(2025年の95%から上昇)
- 一部のネイティブモジュールにまだ問題あり
- 回避策: 問題のあるパッケージには
--backend=copyfileを使用
CI/CDパフォーマンス
多くのチームにとって、CI/CD時間はパッケージマネージャーの選択が本当に重要になるところです:
GitHub Actionsベンチマーク
# 同じワークフロー、異なるパッケージマネージャー # Node.js 22, ubuntu-latest, クリーンキャッシュ ┌────────────┬──────────────┬──────────────┬──────────────┐ │ マネージャー│ インストール │ キャッシュヒット│ 合計ジョブ │ ├────────────┼──────────────┼──────────────┼──────────────┤ │ npm │ 48s │ 12s │ 2m 34s │ │ yarn │ 21s │ 8s │ 2m 15s │ │ yarn (PnP) │ 18s │ 0s* │ 2m 02s │ │ pnpm │ 14s │ 4s │ 2m 08s │ │ bun │ 3s │ 1s │ 1m 52s │ └────────────┴──────────────┴──────────────┴──────────────┘ * Zero-installs: 依存関係をリポジトリにコミット
移行ガイド
切り替える準備はできましたか?方法は以下の通りです:
npm → pnpm
- pnpmをインストール:
npm install -g pnpm
- 既存のロックファイルをインポート:
pnpm import
- 古いファイルを削除:
rm -rf node_modules package-lock.json
- インストール:
pnpm install
npm → Bun
- Bunをインストール:
curl -fsSL https://bun.sh/install | bash
- 古いファイルを削除:
rm -rf node_modules package-lock.json
- インストール:
bun install
ロールバック計画
移行で問題が発生した場合:
# 古いロックファイルをバックアップしておいてください! cp package-lock.json package-lock.json.backup # ロールバックするには: rm -rf node_modules bun.lockb pnpm-lock.yaml yarn.lock mv package-lock.json.backup package-lock.json npm install
いつ何を使うか:決定フレームワーク
npmを使う場合:
✅ 最大の互換性が必要
✅ チームが代替手段に不慣れ
✅ 多くのネイティブ依存関係を持つレガシープロジェクト
✅ 厳格なツールポリシーを持つ企業環境
✅ 「ただ動く」ことが必要
yarnを使う場合:
✅ Plug'n'Play zero-installsが必要
✅ プラグインエコシステムが欲しい
✅ チームがすでにyarnエキスパート
✅ 高度なワークスペース機能が必要
✅ オフラインファースト開発が重要
pnpmを使う場合:
✅ ディスクスペースが懸念事項
✅ 重複する依存関係を持つプロジェクトが多い
✅ 複雑な依存関係を持つ大規模モノレポ
✅ 互換性を犠牲にせず速度が欲しい
✅ 厳格な依存関係分離が重要
Bunを使う場合:
✅ 速度が絶対優先
✅ 新しいプロジェクトを始める
✅ CI/CD時間が大きなコスト
✅ Node.js APIやスクリプトを構築中
✅ 統合されたランタイム+パッケージマネージャーが欲しい
誰も言わない隠れたコスト
切り替える前に考慮してください:
学習曲線
- npm → pnpm: 最小。ほぼドロップイン。
- npm → yarn 4: 中程度。PnPモードの理解が必要。
- npm → Bun: パッケージ管理は低い、Bunランタイム使用時はより高い。
チームオンボーディング
最速のパッケージマネージャーも、チームを遅くするなら役に立ちません:
- チームは新しいツールにどの程度慣れているか?
- ドキュメントとスクリプトは更新されているか?
- 開発ワークフロー全体をテストしたか?
結論:間違った選択はない(ほぼ)
広範なテストの結果、正直な真実は:4つのパッケージマネージャーすべてがほとんどのプロジェクトで問題なく動作します。 パフォーマンスの違いは測定可能ですが、小〜中規模プロジェクトではほとんど重要ではありません。
選択が重要な場所:
- モノレポ: pnpmまたはyarn
- CI/CDヘビーなワークフロー: Bunまたはpnpm
- ディスク制約のあるシステム: pnpm
- 最大の互換性: npm
- 最先端: Bun
最も重要なのは、どのパッケージマネージャーを選ぶかではなく—プロジェクトとチーム全体で一貫して選ぶことです。マネージャーを頻繁に切り替えると、速度差以上の摩擦が生じます。
2026年の推奨:
- 新規プロジェクト: Bunを試してみてください。マイナーな互換性リスクを正当化するほど高速です。
- 既存プロジェクト: 痛みを感じているならpnpmを検討。そうでなければnpmで問題ありません。
- エンタープライズモノレポ: pnpmが安全で強力な選択です。
ベンチマークは2026年1月にM3 MacBook ProでNode.js 22.xを使用して実施。結果はハードウェア、ネットワーク、プロジェクトの仕様によって異なります。決定前に必ず自分のコードベースでテストしてください。
関連ツールを見る
Pockitの無料開発者ツールを試してみましょう