npm・yarn・pnpm は、どれも JavaScript（Node.js）のプロジェクトで使うライブラリを取ってきて、管理する道具（パッケージマネージャー）です。npm は Node.js の標準のパッケージマネージャーで、Yarn と pnpm は npm の代わりに使える道具です。Node.js 公式は、Yarn と pnpm を「代わりの道具」として紹介するだけで、どれかを勧めてはいません。
この記事は、Node.js のプロジェクトを始めたばかりで、README に pnpm install や yarn と書いてあって戸惑っている初心者に向けて、3つの違い、入れ方、README と違う道具で入れたときに起きること、サプライチェーン攻撃への備えを説明します。版は2026年10月3日時点のもので、npm 12.2.0・pnpm 12.8.1・Yarn 4.18.1 です。コマンドの出力例は、macOS・Node.js 24.21.0 で、版を添えた道具を使って取ったものです。
- npm・yarn・pnpm とは何か（どれも Node.js のパッケージマネージャーで、npm が標準、Yarn と pnpm は代わりの道具）
- 3つの違い（lock ファイル・コマンドの対応・版による既定の違い）を、版つきの表で
- 入れ方と切り替え方（Node.js の版による違いと、Corepack のいま）
- README と違う道具で入れてしまったときに、3つの道具で何が起きるか
- サプライチェーン攻撃への備え（インストールスクリプトと、公開からの待ち）
\\ 3丁目オーナー開発アプリ！コンテンツ随時更新中 //
\\ これからITフリーランス //
\\ 3丁目オーナー開発アプリ！コンテンツ随時更新中 //
\\ これからITフリーランス //
npm・yarn・pnpm とは？何をする道具？
Node.js 公式の説明では、npm は Node.js の標準のパッケージマネージャーです。Yarn と pnpm は npm の代わりになる道具で、公式は「こちらも見てみてください」と紹介しています。
パッケージマネージャーがすることは、プロジェクトの依存を取ってきて、更新し、管理することです。依存とは、アプリが動くために要る、できあがったコードの部品（ライブラリなど）のことです。package.json があるプロジェクトで npm install を流すと、要るものが node_modules フォルダに入ります。
npm・yarn・pnpm の違いは？
まず、3つの道具が自分の公式の文書で書いている特徴を、道具ごとに並べます。Yarn には 1 系（Classic）と 2 以降（Modern）があり、公式は Classic から Modern への移行を勧めているので、4 系と 1 系を分けました。npm は、Node.js 24・26 に入っているのが 11 系で、最新が 12 です。11 系と 12 で既定が変わったところは、あとの「サプライチェーン攻撃への備え」の節で表にします。
| 道具（版） | lock ファイル | node_modules の作り方（既定） | 公式が書いている特徴 |
|---|---|---|---|
| npm（11 系・12） | package-lock.json | hoisted（重ならないものを上の階にまとめる。npm 12 の文書の既定） | Node.js の標準のパッケージマネージャーで、Node.js と一緒に入る |
| pnpm 12 | pnpm-lock.yaml | 直接の依存だけを node_modules の直下にシンボリックリンクで置く | Rust で書き直された安定版。単体の実行ファイルで、入れた後は Node.js が無くても動く |
| Yarn 4（Modern） | yarn.lock | Plug'n'Play（node_modules を作らず、.pnp.cjs というファイルに依存の場所を書く） | 「プロジェクトマネージャーも兼ねるパッケージマネージャー」。ワークスペース（1つのリポジトリに複数のパッケージ）を軸に作った最初のパッケージマネージャー、と公式は書いている |
| Yarn 1 系（Classic） | yarn.lock | 全部を node_modules の直下に引き上げる（pnpm 公式の説明） | npm の yarn パッケージとして今も配られている。最新は 1.22.22（2024年3月9日） |
出典: pnpm 公式（なぜ pnpm か）・pnpm 12 の変更点・pnpm 公式（インストール）・Yarn 公式のトップ・Yarn 公式（PnP）・Yarn 公式（FAQ）
設定の書き場所と node_modules の違い
設定の書き場所も道具で違います。pnpm は設定を pnpm-workspace.yaml に書き、.npmrc から読むのは認証とレジストリの設定だけです。Yarn の Modern は .yarnrc.yml に書き、.npmrc と .yarnrc は読みません。npm の設定を .npmrc に書く例は、あとの「サプライチェーン攻撃への備え」の節に出てきます。
node_modules の作り方も違います。pnpm 公式は、npm や Yarn Classic では全部が直下に引き上げられるので、プロジェクトに書いていない依存までコードから使えてしまう、と説明しています。pnpm は既定で、直接の依存だけを直下に置きます。シンボリックリンクと相性の悪い道具があるときは、nodeLinker を hoisted にすると、npm に似た node_modules になります。Yarn 4 も nodeLinker で pnp・pnpm・node-modules から選べて、node-modules なら Yarn Classic や npm と同じ node_modules ができます。
npm にも、書いていない依存（phantom dependencies）を見つけるための linked という作り方があります。npm 12 の設定の文書は、パッケージの作者に、開発中に --install-strategy=linked を使い、書いていない依存を公開の前に見つけるよう勧めています。
よく使うコマンドの対応
「入れる」「足す」「走らせる」の操作を、3つの道具で並べます。Yarn は 4 系のコマンドです。
| やりたいこと | npm | pnpm | Yarn 4 |
|---|---|---|---|
| 全部入れる | npm install | pnpm install（別名 pnpm i） | yarn（yarn install と同じ） |
| 1つ足す | npm install <名前> | pnpm add <名前> | yarn add <名前> |
| 開発用に足す | npm install -D <名前>（--save-dev） | pnpm add -D <名前> | yarn add -D <名前>（--dev） |
| スクリプトを走らせる | npm run <名前> | pnpm <名前>（pnpm run <名前> も同じ） | yarn <名前>（yarn run <名前> も同じ） |
| 入れずに一度だけ走らせる | npx | pnx（pnpm dlx・pnpx と同じ） | yarn dlx |
| CI 用（lock ファイルどおりに入れ、合わなければ失敗） | npm ci | pnpm install --frozen-lockfile（CI では lock ファイルがあれば既定で有効）、または pnpm ci（v11.0.0 から） | yarn install --immutable（CI では既定で有効） |
Yarn 1 系では、CI 用は yarn install --frozen-lockfile です。Yarn 4 にも --frozen-lockfile は別名として残っていますが、いずれ消える、と Yarn 公式は書いています。pnpm 公式にも npm との対応表があり、npm run <cmd> は pnpm <cmd>、npx <pkg> は pnx <pkg> と書かれています。
同じ操作を3通りで並べたコードは、React＆TypeScript入門のパッケージ構成の記事の「ビルドとExport方法」にも出てきます。
出典: pnpm 公式（CLI の対応表）・Yarn 公式（使い方）・Yarn 公式（install）・Yarn 公式（移行ガイド）・Node.js 公式（npm の紹介）
速さを表に入れなかった理由
速さの行は入れていません。pnpm 公式のベンチマークのページは、比べているのが npm と pnpm だけで、Yarn は入っていません。数字はデプロイのたびに作り直され、同じ pnpm 公式でも、トップページとベンチマークのページで数字が違います。Yarn 公式は、「Yarn は他より速い？」という問いに「Shrug」（肩をすくめる）と答え、速さは相対的で一時的な状態であり、長く残るのは、進め方・ロードマップ・中核の価値観だ、と書いています。
npm・yarn・pnpm はどうやって入れる？切り替える？
入れ方は道具ごとに違い、Node.js の版によっても、最初から入っているものが変わります。2026年10月時点の事情を、Node.js の版、道具ごと、Corepack（コアパック）の順に説明します。
Node.js の版で、入っているものが違う
npm は Node.js と一緒に入ります。ただし、Node.js に入っている npm は、最新の 12 ではありません。Node.js の配布情報（2026年10月3日時点）では、次のとおりです。
| Node.js の版 | 同梱の npm | 同梱の Corepack |
|---|---|---|
| 26（26.10.0） | 11.19.1 | 入っていない |
| 24（24.21.0、LTS） | 11.19.0 | 入っている（0.36.0） |
| 22（22.23.3、LTS） | 10.9.9 | 25.0.0 の手前まで配られているので、入っている |
出典: Node.js の配布情報（index.json）・Corepack の README
npm 12 が対応する Node.js は、22.22.2 以上の 22 系、24.15.0 以上の 24 系、26 以上です（npm 12.0.0 の CHANGELOG）。入っているかどうかは node -v と npm -v で確かめられ、npm だけを最新にするなら npm install -g npm です（npm の公式文書）。
LTS（長期サポート版）の予定は、Node.js リリース作業部会の予定表によると、24 が2025年10月28日から LTS で、2028年4月30日までです。26 は2026年10月28日に LTS になる予定です。
Node.js と npm を入れる方法について、npm の公式文書は、nvm のような Node のバージョン管理ツールで入れるよう強く勧めています。インストーラーは勧めていません。インストーラーで入れると、npm のパッケージをグローバルに動かすときに、権限のエラーが出ることがあるためです。バージョン管理ツールは、macOS・Linux では nvm と n、Windows では nodist と nvm-windows が挙がっています。インストーラーを使うなら、「LTS」と書かれた版を入れるよう書かれています。
出典: npm 12.0.0 の CHANGELOG・Node.js リリース作業部会の予定表
pnpm を入れる
pnpm 12 の公式の入れ方は、次のスクリプトです。ただし Windows では、スクリプトで入れると Windows Defender が実行ファイルを止めることがあるため、pnpm 公式は npm で入れるのを勧めています。
# macOS・Linux（wget でも可）
curl -fsSL https://get.pnpm.io/install.sh | sh -
# Windows（PowerShell）
Invoke-WebRequest https://get.pnpm.io/install.ps1 -UseBasicParsing | Invoke-Expressionnpm が入っているなら、npx get-pnpm でも入れられます。このインストーラーを走らせるには Node.js 22.13 以上が要り、入れたあとの pnpm を動かすのには要りません（pnpm 公式のインストールのページ）。
pnpm 12 は単体の実行ファイルで、macOS（arm64・x64）、Windows（x64・arm64）、Linux などに対応しています。更新は pnpm self-update で、pnpm 11.10.0 以上からなら、12 へ直接上げられます。
出典: pnpm 公式（インストール）
Yarn を入れる
Yarn（4 系）の公式の入れ方は、まず Corepack を入れて（npm install -g corepack）、新しいプロジェクトなら、次に yarn init -2 を実行する手順です。更新は、yarn set version stable のあとに yarn install を流します。
Yarn 公式は、npm install -g yarn で入れるのを勧めていません。依存を固定するのと同じように、パッケージマネージャー自体の版も固定すべきだから、というのが理由です。npm の yarn パッケージは 1 系（Classic）のままで、新しい Yarn は2019年から npm の yarn という名前では配られていません（4 系は @yarnpkg/cli-dist という名前で出ています）。
出典: Yarn 公式（インストール）・Yarn 公式（Corepack）
Corepack のいま
Corepack は、Node.js のプロジェクトと、そのプロジェクトで使うはずのパッケージマネージャーをつなぐ道具です。Yarn・npm・pnpm を、自分で入れなくても使えるようにします。プロジェクトの package.json の packageManager 欄で、使う道具と版を決めます。書けるのは yarn・npm・pnpm で、版は必須です。ハッシュは任意ですが、Corepack の README はセキュリティ上、強く勧めています。corepack enable を流すと、yarn と pnpm のコマンドが使えるようになります。npm のコマンドは、頼まない限り作られません。
この Corepack への立場が、2026年10月時点では、そろっていません。
| 誰が | Corepack について |
|---|---|
| Yarn 公式 | 実験的とされているが、Yarn と pnpm の両方にとって望ましい入れ方 |
| pnpm 12 公式 | インストールのページに Corepack の節が無い（pnpm 10 のページには「Using Corepack」の節があり、corepack enable pnpm を載せていた） |
| Node.js | 「実験的（Stability: 1）」。25.0.0（2025年10月15日）から配っていない。使いたい人は npm install -g corepack で入れる |
出典: Yarn 公式（Corepack）・pnpm 公式（インストール）・Node.js の文書（Corepack）・Node.js 25.0.0 のリリースノート
つまり、Node.js 24 までなら、同梱の Corepack で corepack enable が使えます。Node.js 25 以降は、先に npm install -g corepack で Corepack を入れます。Node.js 26 は2026年10月28日に LTS になる予定で、26.10.0 の配布物には Corepack が入っていません。Node.js のダウンロードページには、corepack enable pnpm と corepack enable yarn の手順が載っています。Corepack の README は、npm で Corepack を手で入れる前に、グローバルに入れた Yarn と pnpm を消す（npm uninstall -g yarn pnpm。npm は残す）よう書いています。
なお、Yarn 公式の Corepack のページには、Corepack が Node.js に同梱されることについて、いまの Node.js の扱い（25.0.0 から配らない）と合わない説明が残っています。この記事は、同梱については Node.js 側の文書に従っています。
README と違う道具で入れてしまったら？
README に pnpm install と書いてあるのに npm install を流す、といった取り違えで何が起きるかは、道具の組み合わせで違います。止まる組み合わせと、止まらない組み合わせがあります。ここでは、macOS・Node.js 24.21.0 での出力を、道具の版を添えて3つ並べます。出力は、要る行だけを抜いています。
プロジェクトが使う道具の見分け方
プロジェクトが使う道具は、package.json の packageManager 欄、devEngines 欄、lock ファイルの名前で決まっています。pnpm 12.8.1 の pnpm init が作る package.json には、次の欄が入ります（抜粋）。
"devEngines": {
"packageManager": {
"name": "pnpm",
"version": "12.8.1",
"onFail": "download"
}
},
"packageManager": "[email protected]",
"type": "module"packageManager 欄は、前の節の Corepack が読む欄です。devEngines 欄は、npm の文書によると、そのコードを触る人が同じ道具をそろえるための欄で、npm は install・ci・run の前に確かめます。lock ファイルは、package-lock.json なら npm、pnpm-lock.yaml なら pnpm、yarn.lock なら Yarn の道具が作るものです。
取り違えたときの3つの結果
| 組み合わせ | 結果 |
|---|---|
devEngines 欄に pnpm が書かれたプロジェクト（pnpm 12.8.1 の pnpm init が書く）に、npm 11.19.0 の npm install | EBADDEVENGINES で止まる。package-lock.json はできない |
package-lock.json だけがある npm のプロジェクトに、pnpm 12.8.1 の pnpm install | 止まらない。警告も出ず、pnpm-lock.yaml ができて、lock ファイルが2つ並ぶ |
packageManager が [email protected] のプロジェクトに、Corepack 0.36.0 の corepack pnpm install | 止まる。このプロジェクトは yarn を使う、と Corepack が知らせる |
1つ目は、npm が止める場合です。 上の package.json のプロジェクトで、npm 11.19.0 の npm install を流したときの出力です。止めているのは devEngines 欄で、npm の文書は、この欄を install・ci・run の前に確かめる、と書いています。
npm error code EBADDEVENGINES
npm error EBADDEVENGINES Invalid name "pnpm" does not match "npm" for "packageManager"
npm error EBADDEVENGINES current: { name: 'npm', version: '11.19.0' },
npm error EBADDEVENGINES required: { name: 'pnpm', version: '12.8.1', onFail: 'download' }current が流した道具（npm 11.19.0）、required が package.json に書かれた道具（pnpm 12.8.1）です。npx -y [email protected] add … と、npx 経由で pnpm を動かしても、同じ EBADDEVENGINES で止まります。
2つ目は、pnpm が止めない場合です。 package-lock.json だけがある npm のプロジェクトで、pnpm 12.8.1 の pnpm install を流したときの出力です。
Packages: +1
dependencies:
+ is-number 7.0.0
Done in 66ms using pnpm v12.8.1エラーも警告も出ません。pnpm-lock.yaml（と node_modules）ができて、元からある package-lock.json と lock ファイルが2つ並びます。
3つ目は、Corepack が止める場合です。 package.json に "packageManager": "[email protected]" だけを書いたプロジェクトで、Corepack 0.36.0 を使って corepack pnpm install を流したときの出力です（corepack enable はせず、corepack <道具> と直接呼んでいます）。
This project is configured to use yarn because …/package.json has a "packageManager" field「…」は、package.json の置き場所を省いたものです。Corepack の README によると、プロジェクトが別の道具に決まっているとき、Corepack は正しい道具でもう一度流すよう求めます。入れたものが壊れるのを防ぐためです。
プロジェクトの packageManager 欄と同じ道具なら、Corepack はその版を取ってきて動かします。packageManager が [email protected] のプロジェクトで、Node.js 24.21.0 に同梱の Corepack 0.36.0 の corepack pnpm --version を流したときの出力は、次のとおりです。
Downloading the pnpm 12.8.1 binary for darwin-arm64...
12.8.1npm の文書には、npm install は package-lock.json か yarn.lock があれば、それに沿って依存を入れる、と書かれています。両方あるときは package-lock.json が先です。
止まる組み合わせも、止まらない組み合わせもあります。流す前に、package.json の欄と lock ファイルの名前を見て、プロジェクトが決めている道具を確かめておくと、取り違えに気づきやすくなります。
どれを使う？（公式に書かれていること）
この記事で見た Node.js・npm・Yarn・pnpm の公式の文書には、初心者に「この場面ではこれ」と1つを勧める文は見つかりませんでした（2026年10月時点）。公式が書いていることは、次のとおりです。
- Node.js 公式は、どれかを勧めてはいません。 npm を標準のパッケージマネージャーとして紹介し、Yarn と pnpm は npm の「代わりの道具」として、こちらも見てみてください、と紹介するだけです
- すでにあるプロジェクトでは、プロジェクトが道具を決めています。
packageManager欄・devEngines欄・lock ファイルの名前で分かります。違う道具で入れると、Corepack は正しい道具でやり直すよう求め、npm はdevEnginesの欄で止めます。ただし、止まらない組み合わせもあります（前の節） - 新しく始めるときは、各公式が自分の特徴として挙げていることが手がかりになります。 npm は Node.js と一緒に入ります。pnpm は、同じ版の依存をディスクに1つだけ置くことと、宣言していない依存を使えない node_modules にすることを挙げています。Yarn は、ワークスペースを軸に作られたことと、プロジェクトマネージャーも兼ねることを挙げています
- Yarn を選ぶなら、Modern（2 以降）が公式の勧めです。 Yarn 公式は、Classic（1 系）から Modern への移行を勧めています
- 3つを同じ条件で比べた公式の速さの数字は、見つかりませんでした（2026年10月時点）。 pnpm 公式は速さを特徴に挙げ、ベンチマークで npm と比べていますが、Yarn は入っていません。Yarn 公式は、「Yarn は他より速い？」に「Shrug」と答えています
出典: Node.js 公式（npm の紹介）・pnpm 公式（なぜ pnpm か）・Yarn 公式のトップ・Yarn 公式（FAQ）
サプライチェーン攻撃への備え
サプライチェーン攻撃とは、ここでは、npm のパッケージに悪いコードが混ぜられ、そのパッケージを入れた環境で動いてしまう攻撃を指します。2025年と2026年に npm で起きたことと、3つの道具の備えを説明します。
何が起きたか
2025年9月23日に、米国の CISA（サイバーセキュリティを担当する政府機関）が注意喚起を出しました。「Shai-Hulud」という名前で知られる、自分で広がるワームが、npm の 500 を超えるパッケージを乗っ取った、という内容です。CISA によると、ワームは入り込んだ環境で認証情報（GitHub の個人トークンや、AWS・GCP・Azure の API キー）を探して持ち出し、乗っ取った開発者として npm にログインして、ほかのパッケージにコードを入れて公開し、広がりました。GitHub は、乗っ取った開発者のアカウントから、人気のパッケージに悪意のある post-install スクリプトを入れて広がった、と説明しています。
CISA の勧めには、依存を見直すこと、2025年9月16日より前に出た安全な版に固定すること、開発者の認証情報をすぐ取り替えること、すべての開発者のアカウント（とくに GitHub と npm）にフィッシングに強い多要素認証を必須にすることが入っています。被害の確かめには、package-lock.json や yarn.lock を見るよう勧めています。
2026年4月20日には、CISA が別の注意喚起を出しました。2026年3月31日に、axios の 1.14.1 と 0.30.4 に、悪意のある依存 [email protected] が入り、遠隔操作のトロイの木馬などを落としてきた、という内容です。axios とは何かは、fetch と axios の違いの記事で説明しています。CISA の勧めには、乗っ取られた版が入っていたら、安全だと分かっている状態に戻すこと（1.14.0 か 0.30.3 に下げて node_modules/plain-crypto-js/ を消す）、さらされたかもしれない認証情報を取り替えること、そして .npmrc に次の2行を設定することが入っています。
ignore-scripts=true
min-release-age=7ignore-scripts=true は、npm install のときにスクリプトが走るのを止める設定です（CISA の説明）。npm の文書によると、npm start・npm test・npm run などで名指ししたスクリプトは走りますが、その前後の pre・post のスクリプトは走らなくなります。自分のプロジェクトで pre・post のスクリプトを使っているなら、動きが変わることに気をつけます。min-release-age=7 は、公開から7日以上たったパッケージだけを入れる設定です。
乗っ取られた版は、2026年10月3日時点の registry からは消えています。axios の 1.14.1 と 0.30.4 は取れません（E404）。公開の記録は残っていて、2026年3月31日の 00:21:58 UTC と 01:00:57 UTC です。plain-crypto-js は、説明が "security holding package" の 0.0.1-security.0 だけが残っています。axios の latest は 1.20.0 です。
出典: CISA（2025年9月23日の注意喚起）・GitHub（npm をより安全にする計画）・CISA（2026年4月20日の axios の注意喚起）
3つの道具の既定
CISA が勧めた「インストールスクリプトを止める」と「公開から日が浅い版を入れない」について、3つの道具の2026年10月時点の既定は、次のとおりです。インストールスクリプトは、npm 12・pnpm 10 以降・Yarn 4.14 以降で、既定で止まります。Node.js 24 に入っている npm 11 では、警告を出したうえで走ります。公開からの待ちは、pnpm と Yarn が既定で1日で、npm は既定では無効です。ただし pnpm は、既定のままだと「ゆるい」設定で、求める範囲に1日たった版が無いときは待たずに入れます。自分で minimumReleaseAge を書くと、入れずに止まるようになります（pnpm の設定の説明）。
| npm 11.19.0（Node.js 24 に同梱） | npm 12.2.0 | pnpm 12.8.1 | Yarn 4.18.1 | |
|---|---|---|---|---|
| 依存のインストールスクリプト | 走る（警告が出るだけ。11.16.0 から） | 既定で止まる | 既定で止まる（pnpm 10 から） | 既定で走らせない（4.14.0 から） |
| 公開からの待ちの設定 | min-release-age（単位は日） | min-release-age（単位は日） | minimumReleaseAge（単位は分） | npmMinimalAgeGate（1d・1w・3h のような文字） |
| 待ちの既定 | 無効（null） | 無効（null） | 1440 分（1 日）。pnpm 11 から。既定のままはゆるい（範囲に1日たった版が無いと待たずに入れる）。自分で書くと止まる | 1d（1 日）。4.15.0 から |
npm の待ちの設定は、npm 11.10.0（2026年2月11日）で入りました。npm 11 では、許していない依存のスクリプトも、警告を出したうえで走ります（npm 11 の文書。警告をエラーに変える strict-allow-scripts は既定で false）。npm 12.0.0（2026年7月8日）では、git の依存と URL の依存も既定で入れなくなりました（allow-git と allow-remote が none。npm 11.19.0 の既定は all）。
よくある質問
lock ファイル（package-lock.json など）は Git に入れる？
入れます。npm・Yarn・pnpm の3つとも、公式の文書が lock ファイルをリポジトリに入れるよう書いています。lock ファイルは、できあがった依存の木を正確に書き残し、次に入れたときも同じ木を作れるようにするファイルです（npm の package-lock.json の説明・Yarn の Q&A・pnpm のサプライチェーンの対策）。名前は、npm が package-lock.json、pnpm が pnpm-lock.yaml、Yarn が yarn.lock です。
npm ci と npm install の違いは？
npm 公式によると、npm ci は CI（自動のテストや組み立て）など向けのコマンドで、npm install と次の点が違います（npm ci の説明）。
package-lock.jsonが無いと使えないpackage.jsonと lock ファイルが合わないと、lock ファイルを書き換えずにエラーで止まる- パッケージを1つずつ足すことはできない
node_modulesがあれば、先に消してから入れるpackage.jsonと lock ファイルを書き換えない
pnpm なら pnpm install --frozen-lockfile、Yarn 4 なら yarn install --immutable が、lock ファイルどおりに入れて、合わなければ失敗する書き方です（CI では、Yarn は既定で有効、pnpm は lock ファイルがあれば既定で有効）。
同じプロジェクトで npm と yarn（pnpm）を混ぜてよい？
プロジェクトが決めた道具に合わせます。npm の文書によると、devEngines 欄は、そのコードを触る人が同じ道具をそろえるための欄です。Corepack も、プロジェクトが別の道具に決まっていると、入れたものが壊れるのを防ぐために、正しい道具でやり直すよう求めます。逆に、pnpm 12.8.1 は、npm のプロジェクトで pnpm install を流しても警告を出さずに pnpm-lock.yaml を作り、lock ファイルが2つ並びました。違う道具で入れたときに起きることは、上の「README と違う道具で入れてしまったら？」にまとめました。
Corepack とは？ corepack enable は要る？
Corepack は、Node.js のプロジェクトと、そのプロジェクトで使うはずのパッケージマネージャーをつなぐ道具です。Yarn や pnpm を自分で入れずに使えます（Corepack の README）。Node.js 24 までの同梱の Corepack で yarn や pnpm のコマンドを使うには、corepack enable を流します。Yarn 公式の入れ方（npm install -g corepack のあと、新しいプロジェクトで yarn init -2）には、enable の段はありません。
Corepack が Node.js に同梱されているのは 24 系までで、Node.js 25.0.0（2025年10月15日）から配られなくなりました。Node.js 25 以降で使うなら、先に npm install -g corepack で入れます。Yarn 公式は Corepack を勧めていますが、pnpm 12 の公式のインストールのページには Corepack の節がありません（上の「Corepack のいま」）。
npm にも pnpm の minimumReleaseAge のような設定はある？
あります。npm の min-release-age は、公開から何日たった版だけを入れるかの設定で、単位は日、既定は無効です（npm 11.10.0 から）。npm 公式の例は、外のパッケージは7日待ち、自分の組織のものはすぐ入れる、という次の書き方です（npm の設定の説明）。
min-release-age=7
min-release-age-exclude[]=@myorg/*
min-release-age-exclude[]=my-internal-pkgnpm 公式は注意も書いています。この待ちのせいで、npm audit fix が直った版を入れられないときは、脆弱性のある版のまま警告して、0 以外の終了コードで終わります。
まとめ
- npm・yarn・pnpm は、どれも Node.js のパッケージを入れて管理する道具。npm は Node.js と一緒に入る
- lock ファイルの名前が違う（
package-lock.json・yarn.lock・pnpm-lock.yaml）。lock ファイルは Git に入れる、と3つの公式が書いている - すでにあるプロジェクトでは、
packageManager欄と lock ファイルを見て、同じ道具を使う - Corepack は Node.js 24 まで同梱。25 からは配られないので、使うなら
npm install -g corepackで入れる - サプライチェーン攻撃への備えとして、依存のインストールスクリプトは npm 12・pnpm 10 以降・Yarn 4.14 以降で既定で止まる（Node.js 24 に入っている npm 11 では、警告を出したうえで走る）。公開からの待ちは pnpm と Yarn が既定で1日（pnpm は自分で書かないとゆるい）、npm は既定では無効（
min-release-ageで設定する）
参考資料
- Node.js 公式: An introduction to the npm package manager
- npm Docs: package-lock.json
- npm Docs: npm-ci
- npm Docs: config（min-release-age）
- pnpm 公式: Motivation
- pnpm 公式: Installation
- pnpm 公式: Dependency Resolution Settings（minimumReleaseAge）
- Yarn 公式
- Yarn 公式: Corepack
- Corepack の README（GitHub）
- Node.js 25.0.0 のリリース
- CISA: Widespread Supply Chain Compromise Impacting npm Ecosystem（2025年9月23日）
- CISA: Supply Chain Compromise Impacts Axios Node Package Manager（2026年4月20日）
- GitHub: Our plan for a more secure npm supply chain
※この記事は、公式の資料をもとに AI（Claude）で下書きし、2026年10月3日時点の公式の資料と照らして確かめてから公開しています。誤りに気づいたらお問い合わせからお知らせください。
