JavaScriptのランタイムやPackage Managerについて【Bun】

2026年10月9日

JavaScriptのランタイムの種類は？

JavaScriptのランタイムは、大きく「ブラウザ」と「サーバー／ローカル実行環境」に分けられます。

サーバー・ローカル向けランタイム

• Node.js：最も普及しているランタイムで、V8エンジンを使用しています。npmのエコシステムが非常に大きく、実務での標準的な選択肢です。
• Deno：Node.jsの作者Ryan Dahlが開発しました。TypeScriptを標準でサポートし、デフォルトで権限を制限するセキュアな設計です。npmパッケージにも対応しています。
• Bun：JavaScriptCore（Safariのエンジン）をベースにしており、Zigで書かれています。起動と実行の速さが特徴です。パッケージマネージャ、バンドラ、テストランナーも内蔵しています。

ブラウザ（JSエンジン）

• V8：ChromeとEdgeで使われています。
• SpiderMonkey：Firefoxで使われています。
• JavaScriptCore：Safariで使われています。

エッジ・サーバーレス向け

• Cloudflare Workers（workerd）、Vercel Edge Runtime、Deno Deployなどがあります。V8 isolateをベースにした軽量な実行環境です。

迷ったら、実績とエコシステムの大きさでNode.js、TypeScript中心でモダンに書きたいならDeno、速度や開発体験を重視するならBun、という選び方が一般的です。

Package Managerとはなにか？

パッケージマネージャとは、プログラムで使う外部のライブラリ（パッケージ）を、取ってきて・入れて・管理してくれるツールのことです。

スマホの「アプリストア」に例えるとイメージしやすいです。アプリストアは、アプリを探す・インストールする・アップデートする・削除する、という作業をまとめて引き受けてくれます。パッケージマネージャは、それをプログラム用のライブラリに対して行うものです。

主な役割

• インストール：npm install axios のような1行のコマンドで、ライブラリをダウンロードしてプロジェクトに組み込みます。
• 依存関係の解決：あるライブラリが別のライブラリを必要とする場合、それも自動で芋づる式に入れてくれます。手作業でやると非常に大変な部分です。
• バージョン管理：「このライブラリはバージョン2.x系を使う」といった指定を記録し、バージョンの食い違いによる不具合を防ぎます。
• 環境の再現：使っているパッケージの一覧（package.json やロックファイル）を共有すれば、他の人やサーバーでもコマンド1つで同じ環境を作れます。
• 更新・削除：ライブラリのアップデートやアンインストールも簡単にできます。

JavaScript以外にもある

パッケージマネージャはJavaScript特有のものではなく、多くの言語や環境にあります。

• Python：pip
• Ruby：gem / Bundler
• Rust：Cargo
• PHP：Composer
• OS向け：Homebrew（macOS）、apt（Ubuntu）など

JavaScript向けのパッケージマネージャは？

整理すると次のようになります。

• 専用のパッケージマネージャ：npm、Yarn、pnpm
• ランタイムに内蔵されているもの：Bun（bun install）、Deno（deno add など）

Bunは「ランタイム」であると同時に、パッケージマネージャ・バンドラ・テストランナーも兼ねたオールインワンのツールです。そのため、純粋なパッケージマネージャの一覧では外されることもあります。ただ、bun install はNode.jsのプロジェクトでもnpmの代わりに使えるので、実質的には主要なパッケージマネージャの4つ目と考えて問題ありません。

現在よく名前が挙がるのは、npm・Yarn・pnpm・Bunの4つです。

npmレジストリ（registry.npmjs.org）とは？

npm・Yarn・pnpm・Bunのどれを使っても、デフォルトでは同じnpmレジストリ（registry.npmjs.org）からパッケージを取ってきます。、どのツールでも同じパッケージを使えて、エコシステムが1つにまとまっているわけです。

設定で別のレジストリを使うことも可能です。また、npmレジストリ以外の新しい選択肢もあります。

普通に使う分にはどのツールでもnpmレジストリ1か所です。必要に応じて社内用や別のレジストリを追加できる、という理解で問題ありません。

npmレジストリ1か所なら複数のツールがある理由は？

レジストリ（倉庫）は1つでも、「どうやって取ってきて、手元にどう置くか」というやり方がツールごとに違うからです。

例えるなら、同じ問屋から仕入れるとしても、配送のスピードや倉庫での並べ方、在庫の管理方法には工夫の余地がある、という状態です。

ツールごとに違うポイント

• インストールの速さ：ダウンロードを並列で行う、キャッシュをうまく使う、などの工夫で差が出ます。
• ディスクの使い方：npmはプロジェクトごとに node_modules へパッケージを丸ごとコピーします。pnpmはPC内の1か所に保存してリンクで共有するので、容量を大きく節約できます。
• node_modules の構造：npmは依存関係を平らに並べるため、宣言していないパッケージも使えてしまう問題があります。pnpmはこれを厳格に防ぎます。Yarn Berryは node_modules 自体を使わない方式です。
• ロックファイル：バージョンを固定する方法や、その信頼性に違いがあります。
• モノレポへの対応：複数のパッケージを1つのリポジトリで管理する機能の使いやすさに差があります。

歴史的な経緯

1. 2016年ごろのnpmは、遅い・インストールのたびに結果が変わることがある、といった問題を抱えていました。
2. そこでMetaがYarnを作り、高速化やロックファイルの仕組みを導入しました。
3. npm側もYarnを参考に改良を重ね、ロックファイルなどを取り入れました。
4. その後、ディスク効率を追求したpnpmや、速さを極めたBunが登場しました。

つまり、ツール同士の競争によってnpm自身も含めて全体が改善されてきたという流れです。

なぜ1つに統一されないのか

• それぞれに得意分野があり、プロジェクトの規模や要件によって最適なツールが違います。
• 既存のプロジェクトがすでに使っているツールを、わざわざ変える理由が少ないです。
• レジストリが共通なので、どのツールを選んでも使えるパッケージは同じです。そのため、乗り換えたり併存したりしやすいのです。

レジストリが共通だからこそ、ツール側は自由に工夫を競い合える、という関係になっています。

ロックファイルとは？

ロックファイルとは、実際にインストールされたパッケージの正確なバージョンを、依存関係も含めてすべて記録したファイルです。

なぜ必要なのか

package.json では、バージョンを「幅」で指定するのが一般的です。たとえば “react": “^18.2.0" と書くと、「18.2.0以上で、19未満なら何でもよい」という意味になります。

この状態だと、次のような問題が起きます。

今日インストールすると 18.2.0 が入る
半年後に別の人がインストールすると 18.3.1 が入る

このように、同じ package.json でも、インストールする時期や人によって中身が変わってしまうのです。その結果、「自分の環境では動くのに、他の人の環境や本番サーバーでは動かない」という事態が起こります。さらに、依存パッケージの依存パッケージ……と奥まで含めると、数百〜数千個のパッケージのバージョンがずれる可能性があります。

ロックファイルの役割

ロックファイルは、「このとき実際に入ったのは、react 18.2.0、そのreactが使う○○は1.4.2……」と、すべてを固定（ロック）して記録します。これがあれば、誰が・いつ・どこでインストールしても、まったく同じ構成を再現できます。

ツールごとのファイル名

• npm：package-lock.json
• Yarn：yarn.lock
• pnpm：pnpm-lock.yaml
• Bun：bun.lock（古いバージョンではバイナリ形式の bun.lockb でした）

扱い方の基本

• Gitにコミットする：チームや本番環境で同じ構成を共有するために必須です。
• 手で編集しない：パッケージマネージャが自動で生成・更新するものです。
• ツールを混ぜない：Bunを使うなら bun.lock だけにして、package-lock.json などは置かないようにしましょう。

package.json が「こういうパッケージが欲しい」という注文書だとすると、ロックファイルは「実際にこれを届けました」という納品書のようなものです。

package.jsonはどのパッケージマネージャでも共通の仕組みです。基本は共通ですが、細かいところではツール独自の書き方や項目があります。

package.json以外は共通ではない

• ロックファイル：package-lock.json、bun.lock など、ツールごとに別々です。
• 設定ファイル：npmは .npmrc、Yarnは .yarnrc.yml、Bunは bunfig.toml と、ツールごとに異なります。ただし、Bunやpnpmは .npmrc もある程度読み込めます。

今後の新規開発はBun一択でOK？

主要な4つの中では、Bunが一番新しいです。おおよその登場順は次のとおりです。

• npm：2010年ごろ
• Yarn：2016年
• pnpm：2017年ごろ
• Bun：2022年に公開され、2023年に正式版（1.0）が出ました

ただし、「最新＝もっとも使いやすい」とは限りません。何を重視するかで評価が変わります。

Bunの強み

• 速い：インストール速度は4つの中でもトップクラスです。
• オールインワン：ランタイム・パッケージマネージャ・バンドラ・テストランナーが1つにまとまっていて、ツールをあれこれ組み合わせる手間が減ります。
• TypeScriptをそのまま実行できるなど、設定が少なくて済みます。

Bunの弱み・注意点

• 互換性：Node.jsとの互換性はかなり高いものの、一部のパッケージやNode.jsの機能でうまく動かないケースがまだあります。
• 歴史が浅い：トラブル時に検索しても情報がnpmより少なく、解決に時間がかかることがあります。
• 周辺環境の対応：ホスティングサービスやCI、社内ツールなどが、Node.js＋npm前提で作られていることも多いです。

目的別のおすすめ

• 学習中・初心者：npmがおすすめです。Node.jsに付属していて情報が圧倒的に多く、困ったときに調べやすいです。
• 個人開発や新規プロジェクトで、速さや手軽さを重視する場合：Bunは有力な選択肢です。
• チーム開発や大規模・モノレポ：pnpmが実績と効率のバランスがよいです。
• 既存プロジェクト：今使っているツールをそのまま使うのが基本です。

まとめると、Bunは速くてモダン、試す価値は大いにあるツールです。一方で「安定性や情報量」ではnpmやpnpmに分があります。これから学ぶ段階なら、まずnpmで基本を押さえ、慣れてきたらBunやpnpmを試してみる、という順番が無理がなくおすすめです。

新規開発ならBunは有力な選択肢です。ただ、「一択」と決める前に、次の点だけ確認しておくと安心です。

• デプロイ先がBunに対応しているか：使う予定のホスティングやサーバーレス環境で、Bunがそのまま動くかを確認しましょう。Node.jsしか前提にしていないサービスもあります。
• 使いたい主要ライブラリが動くか：フレームワークやDBドライバなど、核になるパッケージをBunで実際に軽く動かしてみてください。ネイティブモジュールを使うパッケージは特に注意が必要です。
• チームで開発するか：メンバーがBunに慣れていない場合、トラブル時の対応コストがかかります。

この3点で問題がなければ、Bunで進めて大丈夫です。

また、万一どこかで詰まっても、パッケージマネージャだけBunを使い、実行はNode.jsにする、あるいはnpmやpnpmに戻す、といった切り替えは比較的簡単です。レジストリが共通で、package.json もそのまま使えるからです。

「まずBunで始めて、問題があれば部分的に切り替える」という気持ちで進めるのが、現実的でよいと思います。

Bun 1.4は大型アップデート

Bun 1.4からRust実装へ切り替わった。これからBunで始めるなら、最初からv1.4系を使うのがよいでしょう。現在の最新の安定版はBun v1.4.2です。v1.4.2は2026年9月5日に公開され、GitHub上で「Latest」として表示されています。

2026年8月20日にBun 1.4が出ました。

• Rustへの書き換え：Bun 1.4ではBun本体がZigからRustで書き直されました。最初の回答で「Zigで書かれている」と説明しましたが、これは1.3系までの話で、現在はRust製です。訂正します。
• Node.js互換性：Node.jsのテストスイートから1,517件のテストが新たに通るようになり、Bun 1.0以来の大きな前進になりました。
• 性能：アイドル時のCPU使用量が5分の1、メモリ使用量が最大35%削減、Linuxでの起動が50%高速化しています。
• 破壊的変更あり：Vercelは、Bun 1.4にはいくつかの破壊的変更があるため、アップグレードは明示的なオプトインにしており、事前に変更点の確認を促しています。

その後のv1.4.1（2026年9月4日）では202件の不具合が修正され、Bun.serveでのHTTP/2対応やbun install –offlineなどが追加されました。

今後の傾向（推測を含みます）

1.4.1と1.4.2の内容を見ると、Rust書き換え後の不具合修正と安定化が当面の中心になりそうです。次のパッチ版も、回帰バグの修正やNode.js互換性の改善が主になる可能性が高いと考えられます。

新規開発への影響

これからBunで始めるなら、最初からv1.4系を使うのがよいでしょう。1.3系から移行する手間がなく、Rust化による性能向上の恩恵も受けられます。ただし、大きな書き換えの直後なので、使うライブラリの動作確認は前回お伝えしたとおり念入りに行ってください。

なお、Bunは現在Anthropicの一部になっています。AnthropicはClaudeの開発元です。