pnpm 12: Rustへの移行と圧倒的なパフォーマンス向上
pnpmは、2026年9月上旬にリリースされたバージョン12で、そのコア部分をTypeScriptとNode.jsからRustへと全面的に書き換えました。この大胆な変更の主な目的は、起動時間とファイルシステム操作のオーバーヘッドを削減し、パフォーマンスを劇的に向上させることにあります。
既存のワークフローを維持しながら、大幅な性能向上を実現した点が、今回のpnpm 12の最大の注目点です。
公式ベンチマークによると、ファイル数の多いテストフィクスチャのクリーンインストールでは、これまでの8.2秒からRust版では5秒へと短縮されました。さらに、キャッシュ、ロックファイル、node_modulesがすでに存在する状態での再インストールでは、472ミリ秒からわずか15ミリ秒へと劇的な改善を見せています（出典）。
独立したテストでもその効果は裏付けられています。Socketの報告によれば、Vercelの21プロジェクトからなるTurborepoワークスペース（1,670パッケージを含む）では、6つのシナリオでインストール時間が中央値で64.4%から90.5%削減されたとのことです（出典）。ただし、Corepackアーティファクトのサイズが大きくなったため、初回起動時には11.1%の遅延が見られたものの、キャッシュ起動は74.7%改善しました。
| シナリオ | pnpm 11 (旧実装) | pnpm 12 (Rust) | 改善率（再インストール） |
|---|---|---|---|
| クリーンインストール | 8.2秒 | 5秒 | - |
| キャッシュあり再インストール | 472ミリ秒 | 15ミリ秒 | 約97% |
これはかなりの衝撃的なニュースですね。特にCI/CD環境でのビルド時間を短縮できるのは、開発者にとって大きなメリットになるのではないでしょうか。Rustのパフォーマンスの高さは知っていましたが、ここまで劇的に変わるとは正直驚きです。
既存ワークフローへの影響と新機能
pnpm 12は、その内部構造を刷新したにもかかわらず、既存のpnpm 11のコマンド、フラグ、設定、ロックファイル形式、そしてnode_modulesレイアウトを意図的に維持しています。これにより、開発者は学習コストをほとんどかけずに新しいバージョンへ移行できる設計となっています。
アップグレードは移行のように感じるべきではない、とメンテナーは述べています（出典）。
ただし、いくつかのCI環境を破壊する可能性のある変更点も存在します。
pnpm install --resolution-onlyが削除され、pnpm peers checkに置き換えられました。- GitHub、GitLab、BitbucketでホストされているGit依存関係は、標準のHTTPS URLを介して解決されるようになります。プライベートなSSHアクセスを使用する場合は、Git URLの書き換えを設定する必要があります。
- Linux環境では、ハードリンクをリフレリンクよりも優先して試行するよう変更されました。
pnpm-workspace.yaml内の未知のキーは、これまで黙って無視されていましたが、今後は報告されるようになります。
また、pnpm 12ではいくつかの新機能も導入されています。
- プロジェクト認識型グローバルバイナリ: グローバルにインストールされたNode.js、Deno、Bunが、現在のプロジェクトでピン留めされたランタイムに従うことができます。
- パッケージマネージャーのプロビジョニング: pnpm自体がnpm、Yarn、Bunをプロビジョニングできるようになりました。Gitホストされた依存関係によって要求されるパッケージマネージャーも含まれます。
- 決定論的なサイクルハンドリング: バイト単位で同一のロックファイルを生成し、サイクルが多いワークスペースではピア解決が2〜3倍高速化され、メモリ使用量も約25%削減されます（出典）。
個人的には、pnpm peers check の導入や、pnpm-workspace.yaml の厳格化は、プロジェクトの健全性を保つ上で歓迎すべき変更だと感じます。特に大規模なモノレポを扱っている開発者の方には恩恵が大きいのではないでしょうか。
コミュニティの反応と今後の展望
pnpm 12のリリースに対するコミュニティの反応は、ネイティブツールのパフォーマンスとそのトレードオフに焦点が当たっています。フロントエンドエンジニアのDennis Morello氏は、このリリースを「メジャーバージョン番号を冠したパフォーマンスリリース」と表現し、目に見えるワークフローは引き続き馴染み深いものであると強調しています（出典）。
元npm CLIメンテナーのDarcy Clarke氏は、パッケージマネージャーをJavaScriptに留めておくことで、共通の内部ロジックの改善が容易になると主張しましたが、pnpmのメンテナーZoltan Kochan氏は「ESMに移行するよりもRustでpnpmを書き換える方が速かった」と答えています（出典）。
HackerNewsでは、npmが自分にとって「退屈だが十分」であるという意見も出ましたが、それに対してnpmのセキュリティモデルの懸念や、pnpmがより良い代替手段であるという反論も多く見られました。特に「npmはデフォルトで依存関係のライフサイクルスクリプトを実行する」という点や、「npmが他のパッケージマネージャーと比較して最悪」という厳しい意見もありました。
| パッケージマネージャー | 特徴 |
|---|---|
| pnpm | コンテンツアドレス型ストア、厳格な依存関係レイアウト、ネイティブバイナリ |
| npm | デフォルト、ライフサイクルスクリプトの自動実行（セキュリティ懸念） |
| Yarn | - |
| Bun | 独自のベンチマークで高速、しかしpnpmのベンチマークからは除外 |
pnpmは、コンテンツアドレス型ストア、厳格な依存関係レイアウト、そして今回のネイティブバイナリ化によって、npm、Yarn、Bunとの差別化をさらに図っています。Bunは独自のベンチマークでは依然として高速な結果を出していますが、pnpmのベンチマークからはBunとYarnが除外されたようです。これは興味深い動きですね。
競争が激化しているパッケージマネージャー界隈で、pnpmが独自の道を切り開こうとしている姿勢が伺えます。クラウド上のCI/CDでも利用が増えそうだと感じました。
インストール方法と互換性ガイドの確認
pnpm 12は、現時点では以下のコマンドでインストールできます。
pnpm self-update next-12
現在のnpmタグはまだpnpm 11を指しており、Homebrew、winget、Scoop、Chocolateyといった主要なパッケージマネージャーでは、リリース時点ではバージョン12は提供されていませんでした（出典）。公式のインストールガイドには、npmおよびスタンドアロンスクリプトオプションも提供されており、Node.jsなしでのインストールも可能です。
移行は限定的であるとされていますが、チームで利用する場合はpnpmの互換性ガイド（compatibility guide）を確認することを強く推奨します。特にCI環境での変更は、予期せぬビルド失敗につながる可能性があるため、事前の確認が不可欠です。
