# pnpm対Yarn：CIにはどちらのパッケージマネージャーか？

> CIにおけるpnpm対Yarn：インストール速度、ディスク使用量、厳格さ、monorepoサポート。どちらのNodeパッケージマネージャーがpipelineを高速で信頼できるものに保つか。

Source: https://latchkey.dev/ja/learn/tool-comparisons/pnpm-vs-yarn  
Updated: 2026-08-20

どちらもnpmの現代的な代替ですが、pnpmとYarnはディスク、厳格さ、workspaceで異なるトレードオフを行います。

pnpmはコンテンツアドレス方式のストアとシンボリックリンクされたnode_modulesを使います。Yarn（Classicまたは新しいBerry）は高速なインストール、workspace、そしてオプションのPlug'n'Playを提供します。CIではその差がディスク使用量とcacheの挙動に現れます。

## Comparison

|  | pnpm | Yarn |
| --- | --- | --- |
| node_modulesのレイアウト | シンボリックリンクされたコンテンツアドレスストア | フラット（Classic）またはPnP（Berry） |
| ディスク使用量 | 低い（共有ストア） | 高め（Classic）、低い（PnP） |
| 厳格さ | 厳格（ファントム依存なし） | 緩い（Classic）、厳格（PnP） |
| CIインストール | pnpm i --frozen-lockfile | yarn install --immutable |
| monorepo workspace | 強力 | 強力 |
| ツールとの互換性 | 高い | 高い (classic)、低い (PnP) |
| CIでのlockfileの挙動 | CIでは自動的にfrozen | Berryでは `--immutable` |
| Corepack | 対応、Node 26で標準 | 対応、Node 26で標準 |

## CIにおいて

pnpmはディスクとウォームストアのインストール速度で勝る傾向があり、その厳格な解決はファントム依存のバグが本番に到達する前に捕捉します。Yarn BerryのPnPも非常に高速でスリムになり得ますが、PnPは一部のパッケージが想定していない形でモジュール解決を変えるため、依存ツリーをテストしましょう。Yarn Classicは、すでに使っているなら最も摩擦の少ないドロップインです。

- A package that imports a transitive dependency it never declared works under Yarn classic and fails under pnpm.
- That failure is correct: the import was always a latent bug and Yarn hoisting was hiding it.
- It is also the single most common reason a Yarn-to-pnpm migration is more work than expected, so budget for it rather than being surprised.
- Yarn PnP is strict in the same way, so migrating Yarn classic to Yarn PnP surfaces exactly the same class of breakage.

> If a migration produces a burst of "cannot find module" errors for packages you never imported directly, that is this, and the fix is to declare them rather than to loosen the resolver.

## storeをcacheする

pnpmではstoreディレクトリ（pnpm store path）をpnpm-lock.yamlをキーにcacheします。YarnではYarnのcacheフォルダをyarn.lockをキーにcacheします。storeをcacheすることは、ツールの選択そのものよりもwall-clock時間にとって重要です。

- pnpm switches to frozen-lockfile mode automatically when it detects CI, so you do not need to pass the flag.
- Since pnpm 11 an install fails outright if the lockfile was written by a newer pnpm major version, rather than silently rewriting it. That is a correctness improvement and also a new way for CI to go red after a colleague upgrades locally.
- pnpm documents that caching the store makes installation faster in most scenarios but is not required and not guaranteed to help, so measure rather than assume.

```.github/workflows/ci.yml
- name: Install pnpm and Node.js
  uses: pnpm/setup@v2.0.0
  with:
    runtime: node@${{ matrix.node-version }}
    cache: true      # caches the pnpm store between runs

- run: pnpm install   # frozen-lockfile is automatic in CI
```

> Pin the package manager version through Corepack, standard in Node 26. Most "works locally, fails in CI" lockfile incidents are a version skew between a developer machine and the runner, and pinning removes the whole category.

## Yarn PnP: 得るものと手放すもの

Plug and Playはこの比較で最も興味深い発想であり、トレードオフが最も鋭いものでもあります。`node_modules` をなくすことは、インストールで最も遅い部分、つまり何万もの小さなファイルを書き出す処理をなくすことです。

- 得るもの: より速いインストール、はるかに少ないディスク使用量、そしてphantom dependencyを遮断する厳密な解決。
- 代償: ディスク上の `node_modules` を走査するツールはPnPへの対応が必要です。これはいまだにバンドラ、エディタ、デバッグ用ツールのロングテールで問題になります。
- 実務上の帰結として、PnPはツールチェーンを完全に掌握しているコードベースには強く適合し、掌握していない広いplugin面を持つコードベースには適しません。

> Yarn Berryは `nodeLinker: node-modules` モードでも動作でき、Berryの機能を保ちながら通常の `node_modules` を書き出します。Yarnの更新を止めている理由がPnPの互換性だけなら、これが逃げ道です。

## Monorepo

どちらも成熟したworkspace実装を持ち、実際の意思決定の大半はここで起きます。

- pnpmの `--filter` は、名前、パス、あるいはgit refに対する変更でパッケージを選べます。これは「このPRが触れたものだけをビルドする」に直接対応します。
- pnpmのcatalogを使うと依存バージョンを一度宣言してすべてのworkspaceパッケージから参照でき、バージョンのずれを直すPRという一群を丸ごとなくせます。
- pnpmの厳密さはmonorepoでこそ最も価値があります。パッケージ間の意図しないimportは、まさに防ごうとしている結合そのものだからです。
- Yarnのworkspaceは長く確立され、よく理解されており、既存のYarn monorepoにとって今も十分に良い選択です。

## 既存のYarnリポジトリを移行すべきか?

1. Yarn classicで問題なく動いているなら、正直な答えはたいてい「いいえ」です。移行コストは実在し、見返りの大半はCIのminuteとディスクです。
2. monorepo全体でphantom dependencyのバグやバージョンのずれに悩まされているなら、pnpmの厳密さとcatalogが原因そのものに対処するので、移行する価値があります。
3. 新しいmonorepoを始めるなら、pnpmのworkspaceとcatalogが今日いちばん摩擦の少ない道です。
4. Yarn BerryのPnPで動いているなら、そのままにしてください。すでに厳密な解決とディスク効率を得ており、pnpmへの移行は横滑りになります。
5. 何を選ぶにせよ、Corepackで固定し、runnerとすべての開発マシンが一致するようにしてください。

## Decide with your own numbers, not a feature table

Feature comparisons age badly and rarely decide anything, because both tools in a mature category can do the job. What differs is how each behaves on your repository, and that takes one afternoon to measure.

```Terminal
# time a cold install with each candidate, cache cleared
hyperfine --prepare "rm -rf node_modules" --warmup 1 \
  "<tool-a> install" "<tool-b> install"

# and the thing CI actually pays for: a cold run with no local cache
docker run --rm -v "$(pwd):/w" -w /w node:22 sh -c "<tool> install"
```

> Measure the cold path. Warm local benchmarks favour whichever tool you already have cached, which is exactly the condition a CI runner never has.

## What actually changes when you switch

- Lockfile format. A switch is a one-way door for anyone still on the old tool until everyone migrates, so plan it as a single coordinated change.
- Resolution strictness. Tools differ on whether an undeclared transitive import works, and the stricter one will surface latent bugs as new failures.
- CI cache configuration. The cache path and key differ per tool; carrying over the old ones silently disables caching.
- Everyone on the team and every runner must move together. Pin the version so they cannot drift.

## 結論

低ディスクと厳格な解決を望むなら：pnpm。高速なドロップイン、あるいはPnPのzero-installモデルを望み、すでにYarnを使っているなら：Yarn。どちらでもlockfileをコミットし、storeをcacheしましょう。

## FAQ

### pnpmはYarnより速いですか?

ストアが温まっている開発マシンでは、たいていはい。パッケージがコピーではなく、共有のcontent-addressableなストアからハードリンクされるためです。コールドなCI runnerではストアが空から始まるので、実行間でストアをcacheしない限り優位はほぼ消えます。

### なぜpnpmはディスクを節約するのですか?

各パッケージバージョンのコピーをグローバルなcontent-addressableストアに1つだけ保持し、プロジェクトからそこへリンクするからです。依存ツリー全体を各プロジェクトにコピーしません。1台に多数のプロジェクトがあると、その差はギガバイト単位に積み上がります。

### Yarnからpnpmに切り替えるとなぜコードが壊れるのですか?

ほぼ必ずphantom dependencyです。Yarn classicは `node_modules` を平坦化するため、宣言していないものをパッケージがimportできてしまいます。pnpmは平坦でない厳密な構成を作るので、そのimportは失敗します。この失敗は正しく、直し方は解決を緩めることではなく、欠けている依存を宣言することです。

### CIでpnpmに --frozen-lockfile は必要ですか?

いいえ。pnpmはCI環境を検出すると自動的にfrozen-lockfileモードに切り替わります。pnpm 11以降は、lockfileがより新しいpnpmメジャーで書かれていた場合、黙って書き換えるのではなく明確に失敗します。

### GitHub Actionsでpnpmのストアをcacheすべきですか?

たいていはい。公式の `pnpm/setup` actionは `cache: true` でそれを行います。pnpmはこれが多くの場面でインストールを速くすると文書化していますが、必須ではなく効果が保証されるわけでもないので、自分のインストール時間を両方の設定で測ってください。

### Yarn PnPは使う価値がありますか?

ツールチェーンを掌握しているなら価値があります。`node_modules` をなくすことで、より速いインストール、はるかに少ないディスク、厳密な解決が得られます。代償は、ディスク上の `node_modules` を前提とするものはPnP対応が必要で、これがいまだにロングテールの一部でつまずくことです。Yarnの `nodeLinker: node-modules` が中間の道です。

### monorepoにはpnpmとYarnのどちらですか?

どちらも成熟したworkspaceを持ちます。新規のmonorepoではpnpmに分があります。`--filter` がgit refに対する変更でパッケージを選べ、catalogがパッケージ横断で依存バージョンを集約し、厳密な解決がパッケージ間の意図しないimportを防ぎます。問題なく動いている既存のYarn workspaceは、解決すべき問題ではありません。

### CIが自分のマシンと同じパッケージマネージャのバージョンを使うようにするには?

Node 26で標準となったCorepackを使い、`package.json` の `packageManager` フィールドにバージョンを宣言してください。開発マシンとrunnerのバージョンのずれは、lockfile関連のCI失敗のほとんどの原因であり、固定することでその分類ごとなくなります。

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt