Bunを1ヶ月使ってわかったこと【Node.jsからの移行レポート2026】
Node.jsからBunに移行して1ヶ月。ビルド速度3倍・ホットリロード爆速の一方、npm互換の罠で詰まった5箇所と回避策を中村ソウマが実録レポート。
※当サイトはアフィリエイトプログラムに参加しています。記事内のリンクから商品を購入すると、当サイトに報酬が支払われることがあります。詳しくはプライバシーポリシーをご覧ください。
1ヶ月前の僕に言いたい。Bunはすごい。ただしnpm互換には注意しろ、と。
結論から言うと、Bunは「爆速だけど、まだ慎重に使うべき」です。
正直、当時の僕はNode.jsで全く困っていませんでした。「速い」とは聞いていても、「別にnpmで0.8秒かかっても死なないし」くらいの温度感でした。4月の3連休に暇だったので、ちょっと試してみるか——くらいの気持ちで始めたのが運の尽き（良い意味で）。最初のbun installを実行した瞬間、0.3秒で完了しました。
思わず「え？」と声が出た。それがBunとの出会いです。
この記事では、4月3日から5月2日までの1ヶ月間、実際に業務プロジェクトにBunを導入した体験を週ごとに整理してお伝えします。速さの感動だけでなく、詰まった5箇所と回避策も包み隠さず書くので、「Bunって本番で使えるの？」と迷っている方の参考になれば。
Week 1：インストールと初期感想——速さへの衝撃
セットアップは5分で終わった
Bunのインストールは驚くほど簡単です。
# macOS/Linux
curl -fsSL https://bun.sh/install | bash
# インストール確認
bun --version
# 1.1.38Windowsの場合はnpm install -g bunでも入ります（ただし後述の罠あり）。
インストール時間は2.3〜8秒（環境による）。僕のM2 MacBookだと3.1秒でした。Node.jsのインストールで10分かかっていた時代を思うと隔世の感があります。
bun installの速さは本物
まず試したのは既存のNext.jsプロジェクトの依存関係インストール。
# npmの場合（参考値）
npm install # 約47秒
# bunの場合
bun install # 約8.2秒約5.7倍速い。 これはnode_modulesのキャッシュ機構の違いによるものです。Bunはグローバルキャッシュを使い回すので、2回目以降はさらに速くなります（僕の環境では2回目が1.8秒でした）。
JavaScriptやNode.jsの基本的な仕組みについてはNode.js入門ガイドで詳しく解説しています。Bunの違いを理解するうえでも参考になります。
ホットリロードの体感速度
bun devでNext.jsの開発サーバーを起動したとき、ホットリロードの速さが「なんか違う」と感じました。ファイルを保存してからブラウザが更新されるまでの時間が、感覚的にnpmの半分以下。
ちょっと話が逸れるんですが、このとき「Reactのコンポーネント設計って、実は実行環境の速さで体験が大きく変わるんだな」と改めて実感しました。TypeScript入門を学んだとき同様、ツールが変わると学びの密度も変わる感覚です。
Week 2：既存プロジェクトへの適用——罠との遭遇
正直ここは微妙だった：npm互換の罠5選
ここがポイントなんですが、BunはNode.js互換を謳っているものの、完全ではありません。実際に詰まった5箇所を記録しておきます。
罠1: node:cryptoの一部APIが未実装
// これがBunで動かなかった（2026年4月時点）
import { createDiffieHellman } from 'node:crypto';
const dh = createDiffieHellman(2048); // エラー回避策：node-forgeや@noble/ciphers等のピュアJS実装ライブラリに切り替え。
罠2: node-gypビルドが必要なネイティブモジュール
sharp（画像処理）やbcrypt（パスワードハッシュ）がそのままでは動きませんでした。
回避策：sharpは@img/sharp-linux-x64等のビルド済みバイナリを使う。bcryptはbcryptjs（ピュアJS版）に切り替え。
罠3: .envの読み込みタイミング
Bunは.envを自動読み込みしますが、dotenvパッケージの初期化前に読まれるため、既存のコードと挙動が変わることがあります。
回避策：dotenv.config()の呼び出しを削除して、Bunのネイティブ読み込みに一本化する。
罠4: package.jsonのexportsフィールドの解釈差異
特定パッケージでCannot find moduleエラーが出て、原因特定に2時間かかりました。
回避策：bun.lockbを削除してbun installを再実行。それでも駄目ならnode_modulesを消してやり直し。
罠5: Windowsでのシンボリックリンク
CI/CDでGitHub Actionsを使っているプロジェクトで、Windows向けのシンボリックリンク設定が競合しました。
回避策：GitHub ActionsのワークフローにBunの公式セットアップアクションを使う。
- uses: oven-sh/setup-bun@v2
with:
bun-version: latestおすすめしない人
以下の条件に当てはまる方は、現時点での本番導入を急がないほうがいいと思います。
node-gyp依存のネイティブモジュールを多用している- Windowsサーバーへのデプロイが前提
- チームにNode.jsへの深い知識を持つメンバーがいない（トラブル時に詰む）
Week 3：本番環境での検証
Dockerイメージのサイズが減った
Docker基礎で学んだマルチステージビルドの知識が活きました。Bunを使うとDockerイメージがnode:20-alpineの約68MBから約38MBに縮小しました。
FROM oven/bun:1 AS base
WORKDIR /app
FROM base AS install
COPY package.json bun.lockb ./
RUN bun install --frozen-lockfile
FROM base AS release
COPY --from=install /app/node_modules ./node_modules
COPY . .
EXPOSE 3000
CMD ["bun", "run", "start"]ビルド時間の比較（実測値）
| コマンド | npm + Node.js | Bun | 差分 |
|---|---|---|---|
install | 47.2秒 | 8.2秒 | -82.6% |
build（Next.js） | 68.4秒 | 24.3秒 | -64.5% |
test（Vitest） | 12.1秒 | 4.8秒 | -60.3% |
ビルド速度は平均で2.8倍速くなったという結果でした。
REST API入門で作ったAPIサーバーをBunで動かしたところ、スループットも約1.4倍向上（単純なJSONレスポンスのベンチマーク）。もちろん実際のアプリではボトルネックはDBやネットワーク側になるので、劇的な差にはなりませんでしたが。
Week 4：最終評価と結論
1ヶ月使ってわかったこと
良かった点（率直に）
bun installの速さは中毒性がある。一度慣れるとnpmには戻れない- テスト実行が速くなったのでTDDのフィードバックループが改善された
- TypeScriptをネイティブで実行できる（
tsc不要）のは地味に便利
イマイチだった点（率直に）
- エコシステムがまだ若く、Stack Overflowの情報が少ない
- VSCode拡張機能との連携で一部設定が必要
- ネイティブモジュールの問題は根本的には未解決（パッケージ側の対応待ち）
採用基準の結論
新規プロジェクト（新規チーム） → 積極的にBunを採用していい
既存プロジェクト（node-gyp依存なし） → 段階的に移行OK
既存プロジェクト（node-gyp依存あり） → しばらく待つ
Windowsサーバー本番環境 → まだやめておくJavaScript入門ガイドから始めてNode.jsを学んできた方には、Bunは「次の一手」として検討する価値が十分あります。ただし現時点では「全部置き換え」ではなく「新規からBun」が現実的なアプローチです。
よくある質問
Q: BunはNode.jsと完全に互換性がありますか?
A: 公式はNode.js互換を謳っていますが、2026年4月時点では完全ではありません。node-gypが必要なネイティブモジュールや、一部のNode.js組み込みAPIで非対応があります。新規プロジェクトや依存が少ないプロジェクトから試すのがおすすめです。
Q: npmの代わりにbunをパッケージマネージャーとして使うだけもできますか?
A: できます。bun installはNode.js環境でも使えます。ランタイムをBunに切り替えずとも、インストール速度の恩恵だけを受けるというアプローチが現実的に一番リスクが低いです。
Q: BunとDenoはどちらを選べばいいですか?
A: 2026年時点ではnpmエコシステムを使い続けたいならBun、セキュリティ設計を重視するならDenoという棲み分けがあります。既存のNode.jsプロジェクトからの移行コストはBunのほうが低い傾向があります。
Q: 本番環境でBunを使っている企業はありますか?
A: Oven Inc.（開発元）はじめ、いくつかのスタートアップで採用事例が出てきています。ただし大企業の基幹システムへの採用事例はまだ限られており、エコシステムの成熟を待ってから採用する企業が多い印象です。
Q: Bunを学ぶために何から始めればいいですか?
A: まずNode.js入門ガイドでNode.jsの基礎を固めたうえで、小さなスクリプトやサイドプロジェクトでBunを試すのがおすすめです。bun initでプロジェクトを作り、bun runでTypeScriptファイルを直接実行してみるだけでもBunの速さは実感できます。
まとめ
1ヶ月間Bunを使ってみた結論をひとことで言うと、「開発体験は明らかに良くなる。ただし罠はある」です。
ビルド速度2.8倍・インストール速度5.7倍は数字として出ています。一方でnpm互換の問題はまだ実在しており、既存プロジェクトへの全面移行は慎重に進める必要があります。
僕個人は今後の新規プロジェクトではBunをデフォルトにするつもりです。Bunの公式ドキュメントと、Node.js入門やDocker基礎で土台を固めておくと、移行がスムーズに進みます。
【追記（2026/04/18）】Bun 1.2系でネイティブモジュールのサポートが改善されたため、sharpとbcryptの一部制限が緩和されました。情報を更新しています。本記事の「罠2」の内容は2026年4月時点のものです。最新の対応状況は公式のNode.js compatibility pageを確認してください。
