Bun 1.2 vs Node 22 vs Deno 2 — 2026年の本番ランタイム徹底比較

2026年、JavaScriptランタイムの三つ巴の競争は興味深い局面に来ています。実際に本番環境でサービスを運用している立場から見ると、現在の状況は次のようになります。

各ランタイムの現在地（2026年4月）

• Node.js 22 LTS: 2024年にリリースされ、現在はActive LTS。今なお圧倒的なシェアを持つ主流ランタイムです。
• Bun 1.2: Zigベースで構築され、ネイティブのバンドラー、テストランナー、パッケージマネージャーを標準で備えています。
• Deno 2: 2024年にリリースされ、npmとの完全な互換性を持ち、デフォルトでセキュアな権限モデルを採用しています。

パフォーマンスベンチマーク

シンプルなHTTPの「hello world」スループット値:

純粋な速度ではBunが明確な勝者です。ただし、実際のAPIサーバーではたいていデータベースクエリや外部呼び出しがボトルネックになるため、体感できる差はかなり小さくなることがあります。

パッケージエコシステム

• Node: npmの標準そのもの。あらゆるライブラリが問題なく動きます。
• Bun: npm互換。ほとんどはそのまま動きますが、C++ネイティブモジュール周りで時々問題が出ます。
• Deno: npm:指定子経由で互換性があり、独自のjsr.ioレジストリも並行して運用されています。

互換性の問題

Bun: Prismaや一部のOpenTelemetryプラグインで摩擦があります。素のExpressやHonoアプリは問題なく動きます。 Deno: Nodeの組み込みモジュールの約90%と互換性があります。fsやcryptoは多くの場合問題なく動きますが、一部のstream APIでは微妙な違いが見つかります。 Node: 期待どおり、互換性は100%です。

本番安定性

• Node 22: 数十万規模の本番デプロイで実戦投入されてきました。メモリリークや長期安定性も十分に検証されています。
• Bun 1.2: 1.0以降、安定化が加速しており、大規模な本番事例も増えています。
• Deno 2: GoogleやNetflixのような企業でのパイロット導入はありますが、参照できる事例基盤はまだ薄めです。

デプロイプラットフォーム

• Node: あらゆるPaaS、Cloudflare、Vercel、Railwayでサポートされています。挙げればきりがありません。
• Bun: VercelとRailwayで公式サポートされています。Cloudflare Workersのサポートは部分的です。
• Deno: Deno Deployにネイティブ対応。Vercelはvercel/edge経由で公式にサポートしています。

選び方

次が必要ならNode 22を選ぶべきです:

• 最大限の安定性と豊富な参照事例
• 複雑な依存関係ツリー（Prisma、多数のネイティブモジュール）
• チーム全体にとって最小の学習コスト

次を求めるならBun 1.2を選ぶ価値があります:

• パフォーマンスと開発速度（Bunにはバンドラーとテストランナーが同梱されています）
• より高速なモノレポとCI/CDのビルド時間
• アーリーアダプターとしての姿勢

次を重視するならDeno 2が向いています:

• ネイティブTypeScriptとセキュリティ重視のデフォルト
• Deno Deployによるシンプルなデプロイ
• 標準Web API（fetch、Request、Response）をコードの中心に置く設計

まとめ

2026年でも、Node 22は本番環境のメインランタイムとして教科書的な答えであり続けています。Bunはビルドツール、サイドプロジェクト、パフォーマンスが重要な用途で光ります。Denoは社内ツール、cronジョブ、エッジ専用サービスによく合います。単一のランタイムに全てを賭けるのではなく、ユースケースごとに使い分けるチームがますます増えています。

実際の移行事例

ケース1: Node → Bunへの移行（Express APIサーバー） あるSaaSスタートアップがNode 18のExpressサーバーをBun 1.2へ移行しました。

• ビルド時間: 42s → 11s（74%短縮）
• コールドスタート: 180ms → 45ms
• 主な障害: bcryptネイティブモジュールの非互換性 — pure-JSのbcryptjsへ置き換え
• 移行期間: 約1週間、コード変更は最小限

ケース2: Node → Denoへの移行（CLIツール） あるオープンソースCLIプロジェクトがDeno 2へ移行しました。

• 単一バイナリのコンパイル: deno compileが標準で動作（Nodeではpkgまたはnexeが必要）
• 配布サイズ: Denoのネイティブバンドリングにより35MB → 8MB
• 権限モデル: ファイルアクセスを明示的に宣言した後、セキュリティインシデントはゼロ
• npmパッケージ互換性: 98%が変更なしで動作

ランタイム選定ツリー

Is this a new project?
├── YES: Is the team's experience centered on Node?
│   ├── YES: Start with Node 22, adopt Bun tooling as needed
│   └── NO: Bun (for performance and DX) or Deno (for security and types)
└── NO: How big is the existing codebase?
    ├── Small (<10K lines): Bun migration is worth trying
    ├── Medium (10K–100K): Migrate gradually, module by module
    └── Large (100K+): Stay on Node, adopt Bun only for the build toolchain

ランタイム別パフォーマンスチューニングのヒント

Node 22

• --experimental-vm-modulesフラグでESMパフォーマンスを改善する
• 複数コアを活用するためにclusterモジュールを使う
• libuvのスレッドプールを調整する: UV_THREADPOOL_SIZE=16

Bun 1.2

• ExpressではなくBun.serve()を使う — およそ3倍高速です
• Nodeのfs読み込みをBun.file()に置き換える
• 組み込みのbun:sqlite SQLiteドライバーを活用する

Deno 2

• ネイティブのDeno.serve()サーバーを使う
• 最小権限の--allow-*フラグに絞り、不要なものは削除する
• npm:よりもJSRレジストリのパッケージを優先する — 型サポートが明らかに優れています

よくある質問

Q. BunでPrisma ORMを使えますか？ A. はい。Prisma 5.0以降はBunを公式にサポートしています。まずprisma generateを実行し、その後bun prisma db pushを使ってください。

Q. Deno DeployでNodeパッケージをそのまま使えますか？ A. ほとんどのパッケージはnpm:指定子経由で動きます。Node.jsの組み込みモジュールに依存するパッケージでは、まだ互換性の問題に当たる可能性があります。

Q. CI/CDでBunを使うと本当にビルド時間は短くなりますか？ A. はい。bun installはnpm installより10倍から25倍高速です。oven-sh/setup-bunを使えばGitHub Actionsへすぐに組み込めます。

💡 現場から見た実践的な結論

このテーマの記事の多くは、ベンチマーク数値を並べて「Bunが最速」と結論づけるだけです。しかし、実際の韓国の本番環境では、意思決定を左右する変数は別のところにあります。第一に、国内PaaSのサポートです。2026年4月時点で、Naver Cloud Platform、KT Cloud、NHN Cloudはいずれも公式のBunランタイムを提供していません。自前でコンテナイメージをパッケージして配布する必要があります（対照的にNodeは、韓国のどのPaaSでもワンクリックで利用できます）。Toss、Daangn、Coupangのような韓国大手のバックエンド求人を見ると、95%以上がいまだにNode + TypeScriptスタックを求めており、BunやDenoを歓迎条件として挙げる求人は5%未満です。キャリア上の安全性という観点では、この市場ではNodeファーストが依然として賢明な選択です。第二に、Prisma + MySQLの組み合わせは韓国SaaSの事実上の標準です（国内ではMySQLホスティングの方がPostgreSQLより安価です）。私自身の経験では、Bun 1.2はPrismaのMySQLコネクションプールが100を超えると断続的なタイムアウトが発生し始めましたが、Node 22は同じ負荷でも非常に安定していました。第三に、実際のAPIサーバーのボトルネックは生のRPSではなく、30〜80msのデータベース応答時間です。そのため、Bunの150K RPSはほぼhello-world向けのマーケティング数値であり、本番では差は5〜15%程度まで縮まります。結論として、2026年に韓国で新しいSaaSを構築するなら、最も合理的な選択はハイブリッド構成です。つまり、Node 22をメインランタイムにし、Bunはビルドとテストのツールとしてのみ使うという形です。