Bun 1.2 ランタイム移行ガイド — Node.js との実運用ベンチマーク比較と互換性チェックリスト

Bun 1.2 は、Node.js 互換性と純粋なパフォーマンスの両面で、かなり完成度の高いところまで到達しています。Node ベースのプロジェクトを Bun に移行するための実践的なチェックリストを紹介します。

なぜ Bun なのか？

• 速度: HTTP サーバーで RPS が 2 倍、ファイル I/O で 3 倍
• オールインワン: Bundler、テストランナー、パッケージマネージャーを内蔵
• ネイティブ TypeScript: 別途コンパイル手順が不要
• メモリ効率: Node より約 30% 少ない

インストールと初期切り替え

# Install Bun
curl -fsSL https://bun.sh/install | bash

# In an existing Node project
bun install  # Uses your existing package.json, generates bun.lockb
bun run dev  # Replaces npm run dev
bun test     # Replaces jest/vitest (native test runner)

互換性チェック

そのまま動作するもの

• Express / Fastify / Hono / Koa
• Prisma 5+（最近のバージョンは Bun を公式にサポート）
• Zod / ts-pattern / effect-ts
• dotenv / nodemon（Bun 組み込みの --hot で nodemon を置き換え可能）

注意が必要なもの

• ネイティブモジュール: node-gyp ベースの一部モジュールはビルドに失敗する可能性があります
• cluster module: Bun では Bun.spawn に置き換えます
• worker_threads: 部分的にサポートされています — 複雑なケースは検証してください

サポートされていないもの

• 一部の OpenTelemetry プラグイン（自動計装）
• 特定の Node 内部 API（v8、perf_hooks の一部）

移行手順

Step 1: CI で Node と並行して Bun を実行する

# .github/workflows/test.yml
- uses: oven-sh/setup-bun@v1
- run: bun install
- run: bun test

Node を主要ランタイムとして維持しつつ、Bun のテストスイートを並行実行して、互換性の問題を早期に洗い出します。

Step 2: ローカル開発環境を切り替える

ローカルでは bun run dev を使います。本番環境は当面 Node のままにします。

Step 3: ステージングに Bun をデプロイする

Docker イメージを oven/bun:1.2 に差し替えます。実トラフィックのサンプルに対して監視します。

Step 4: 本番を切り替える

メモリ、CPU、エラー率を確認したうえで、切り替えを完了します。

Node vs Bun: 実運用ベンチマーク

私の API サーバー事例（Express → Hono+Bun）

Monorepo ビルド

本番デプロイ用チェックリスト

• [ ] すべての依存関係が Bun 上で問題なくビルドされ、import できる
• [ ] テストスイートが 100% 成功する（Bun テストランナー、または既存の vitest 構成）
• [ ] メモリリークテスト（24 時間の負荷実行）
• [ ] OpenTelemetry/APM 連携の検証済み
• [ ] Docker イメージが正常にビルドされ、デプロイできる
• [ ] ロールバック計画が用意されている（Node へ即時フォールバック）

💡 実運用からの知見

多くのブログは「Bun は Node より 3 倍高速」というマーケティング文句を引用していますが、実際には体感できる差はワークロードに大きく左右されます。私が運用している Cloudflare Pages + Next.js 15 のプロジェクト（月間ページビュー約 50,000）では、GitHub Actions の Ubuntu runner 上で npm install が平均 47 秒かかっていましたが、bun install に切り替えると 8〜11 秒まで短縮され、CI 時間を約 76% 削減できました。とはいえ、韓国の開発者がよく使うネイティブモジュール — puppeteer、sharp、bcrypt — は、2026 年 5 月時点でも Bun 1.2 でビルド失敗に遭遇することがかなりあります。そのため、スタックに画像処理やクローリングパイプラインが含まれる場合は、Node LTS を並行稼働させる方が安全です。もう一つの落とし穴は、韓国のクラウド事業者（NHN Cloud、NCP、KT Cloud）のコンテナベースイメージが、公式の oven/bun イメージをミラーしていないことが多い点です。そのため、韓国リージョンから Dockerfile で直接 FROM oven/bun:1.2 を pull すると、平均で 40〜60 秒のレイテンシが追加されます。社内の Harbor レジストリに事前キャッシュしておくことをおすすめします。最終的な決め手になりやすいのは、たいていコストです。Vercel や Netlify のようなビルド時間課金プランを使っているチームでは、Bun への切り替え後に月間ビルドコストが 20〜30% 下がったという報告がよくあり、純粋なパフォーマンスだけよりも、インフラコストの観点が移行判断を後押しする強い要因になることが多いです。

まとめ

Bun 1.2 は、シンプルな API サーバー、CLI ツール、CI/CD スクリプトで即効性のある改善を得られる程度には安定しています。一方で、複雑なネイティブモジュールに依存する環境や、エンタープライズ級の APM が必要な環境では、まだ Node LTS の方が安全です。新規プロジェクトなら Bun を選び、既存プロジェクトでは段階的な移行をおすすめします。