昨年、決済クライアント向けのフィンテックダッシュボードをローンチする3週間前、シニアデベロッパーのPriyaがロンドンのShoreditch支社にやってきて「APIレイヤーをBunに変更したい」と言った。本能的に反対しそうになった。でも、しなかった。その決定は、Hacker Newsのベンチマークスレッドよりも両方のランタイムについてはるかに多く学ぶ機会をくれた。
2015年からNodeで開発している。Seahawk Mediaでは、WordPress、Next.js、Remix、プレーンなExpress、そしてより変わった多くのものを含む12,000以上のサイトとアプリケーションを本番環境にデプロイした。Bunは2023年半ばに真摯にスタックに加わった。今のところ、適切な意見を持っている。ホットな意見ではなく、意見だ。
実際に学んだことは以下の通りだ。
---
ベンチマークの議論はほぼノイズ
6カ月ごとに、Bunが1秒あたり80,000リクエストを処理し、Nodeが何らかの合成HTTPハローワールドテストで40,000を処理することを示す新しい比較がポストされる。実際のところ、その数字は本当だ。Bunの独自ベンチマークは、特にI/Oバウンドのワークロードで本当に印象的なスループットを示している。
ただ、実は誰も本番環境でhello-worldを実行しない。
実際のORM、Redisクライアント、3層のミドルウェア、JWT検証、ファイルアップロードハンドラを追加した瞬間に、その差は大きく縮まる。フィンテックプロジェクトのためにPostgresインスタンスに対してExpress互換アプリ（Node 22で1つ、Bun 1.1で1つ）を実行し、Bunがp50レイテンシーで約18%勝つのを見た。奇跡的ではなく、意味のある差だ。
スピードが実際に重要になるところ
Bunのパフォーマンスアドバンテージが最も顕著な場所はHTTPスループットではない。起動時間とスクリプト実行だ。Nodeが起動に1.4秒かかる1回限りのデータマイグレーションスクリプトを実行するとき、Bunは180msで完了する。CLIツーリング、ローカル開発スクリプト、スケジュール済みジョブでは、その差がチーム全体の実際の生活の質の向上に複合する。
---
Nodeエコシステムは依然として不公正なアドバンテージ
多くの人がこれを軽く扱うのを見るので、直接的に言いたい。Nodeのnpmエコシステムは15年物だ。Bunはそのほぼすべてと互換性がある、そうだが「ほぼすべて」がその文章で重い重みを持っている。
2024年初頭、クライアントプロジェクトはサーバーサイド画像処理のためにsharpが必要だった。十分にシンプルだ。ただし、私たちが必要とした特定のバージョンには、当時Bunのフリーフォーリンタフェース層が適切に処理しなかったネイティブバインディングがあった。その上で1日間を費やした後、そのサービスを単にNode 20に戻した。ドラマなし、イデオロギーなし、単なるプラグマティズム。
互換性ストーリーはそれ以来大幅に改善されている。ただし、スタックがネイティブNodeアドオン（canvas、argon2、.nodeバインディングのあるもの）に大きく依存している場合、移行にコミットする前に徹底的にテストするべきだ。仮定するな。Bun互換性トラッカーをマイグレーション開始前に確認する。
パッケージ管理は別の話
Bunのパッケージマネージャーは本当にnpmより速く、私は今Nodeプロジェクトでも使っている。400個の依存関係を持つプロジェクトでの「bun install」は私のM2 MacBook Proで約8秒かかる。同じマシンではnpmは47秒かかる。ベンチマークではなく、先週火曜日に「time bun install」と「time npm install」でタイミングを取った私だ。
60%のプロジェクトではBunをパッケージマネージャーとして、Nodeをランタイムとして使っている。両方の長所を兼ね備えている。
---
TypeScript: この点ではBunが明らかに優位
率直に言う。NodeでTypeScriptを実行するには、依然としてビルドステップか ts-node か tsx か、あるいはそのいずれかの組み合わせが必要で、正直に横になりたくなるような設定がいる。Bunは.tsファイルをネイティブに実行でき、設定不要。まったく不要だ。
Seahawk内の内部ツール開発ではこれが革新的だった。TypeScriptスクリプトを書いて、bun script.ts で実行する。終わり。tsconfig.json の複雑な設定もなければ、esm 対 cjs の面倒もない。複数のクライアントプロジェクト横断で高速に出荷するチームにとって、この摩擦軽減は本当に効果的だ。
注意点: Bunは独自のTypeScriptトランスパイラを使い、公式のTypeScriptコンパイラではない。そのため型エラーが実行を止めない。型を削除して実行する。TypeScriptコンパイラに実行時の正確性保証を頼っている場合（本来なら頼るべきではないが、みんなやってる）、この差は理解すべき点だ。
---
本番環境で今実際に実行しているもの
曖昧な一般論は役に立たないので、具体的に話そう。
Node 22上:
- WPGraphQL + Apollo Serverを使うすべてのWordPressヘッドレスバックエンド
- ネイティブバイナリ依存を持つサービス
- 実証済みミドルウェアスタックを備えた長時間実行Express API
- 重いCommonJSモジュールを含むレガシーコードベースに関わるもの
Bun 1.1以上:
- 内部CLIツールと開発スクリプト
- 新しいHonoベースのAPIサービス（HonoはBun上で本当に素晴らしい）
- スケジュール実行されるcronジョブと単発のマイグレーションスクリプト
- Webhookレシーバーと軽量なエッジ隣接サービス
パターンはシンプルだ。グリーンフィールドと内部ツール: Bun。複雑な依存ツリーを持つクライアント向け本番サービス: Node。特定の理由がない限り。
---
SQLiteインシデント（そしてそれが教えてくれたこと）
冒頭で触れた。説明する価値がある。
Bunは組み込みSQLiteドライバを搭載している。高速で、ゼロ依存、本当に役立つ。2023年後半、コンテンツ管理ツールのステージング環境でセッションデータ保存に使った。ロードテスト中に特に激しい一連の同時書き込みが発生した後、データベースファイルが奇妙な状態になった。回復不可能な破損ではないが、僕の時間で午前2時に手動対応が必要な状態でロックされた。
Bunのバグか具体的には、正直確実でない。書き込みパターンが原因かもしれない。だが同じワークロードで、その後テストしたNode + better-sqlite3の設定では再現しなかった。
教訓は「Bun SQLiteは壊れている」ではなく、Bunの組み込みAPI（便利だが）はコミュニティの露出が少ないということだ。午前2時に何か起きたら、Stack Overflowスレッドとギタブ課題がほしい。Nodeは17年分ある。Bunは3年分だ。
---
デプロイメントとツール互換性
このセクションは人々が認めるより重要だ。
Vercel、Railway、Render、Fly.ioはいずれもBunのデプロイに対応するようになりました。特にRailwayは非常にシンプルで、ほぼNodeと同じくらい簡単です。AWS Lambdaはもっと厄介です。カスタムランタイムをパッケージングするか、レイヤーを使う必要があり、複雑性が増します。
Dockerは問題ありません。oven/bunが公式ベースイメージで、よく機能します。私は複数のサービスで使用しています。Nodeの同等イメージと比べて、イメージサイズを気にするなら、より軽量です。
成熟度が低いのはオブザーバビリティレイヤーです。DatadogのNode.js APMエージェント、特定のOpenTelemetryオートインストルメンテーションパッケージ、いくつかのSentry SDK機能はBun上では異なる動作をするか、まったく機能しません。去年の春、Bunサービス上で分散トレースがスパンをドロップしている理由を突き止めるのに約4時間かかりました。結局、非同期コンテキスト伝播の違いが原因でした。NodeのAsyncLocalStorageの動作とBunの実装には微妙な相違があり、トレーシングの際に問題になります。
本番レベルのオブザーバビリティを実行している場合は、Bun本番運用前に、テレメトリスタック全体をテストしてください。本番運用後ではなく。
---
「切り替えるべきか」という質問への率直な意見
クライアントやチームメンバーから質問されるときに使う簡単なフレームワークがあります。
- レガシー依存関係のない新規プロジェクトですか？Bunを真剣に検討してください。
- 主に内部ツールやスクリプトを書いていますか？Bunを使ってください。今すぐに。
- ネイティブアドオンや非常に特定のnpmパッケージが必要ですか？Nodeを使い、まずテストしてください。
- スタートアップ時間やスクリプト実行速度が問題になっていますか？Bunはかなり改善されます。
- AWS Lambdaを使用しているか、Bunネイティブサポートがないプラットフォームを使用していますか？Nodeの方が摩擦が少ないです。
- チームはすでにNodeエコシステムの癖に精通していますか？Bunの違いに関する学習曲線を考慮に入れてください。
いくつか注視する価値のあることがあります。
- BunのWindows対応は劇的に改善されましたが、エッジケースではmacOSとLinuxに遅れています。
bun:testのビルトインランナーは実際に優れていますが、依存しているJestプラグインは機能しない可能性があります。--hotによるホットモジュールリロードは印象的ですが、複雑なモジュールグラフではときどき予測不可能です。
---
FAQ
2026年にBunは本番環境対応していますか？
特定のユースケースについては、確実にそうです。最小限のネイティブ依存関係を持つ新規APIサービスの場合、Bunは本番環境対応で、かなり前からそうです。年単位のNode固有の依存関係を持つ複雑なエンタープライズアプリケーションの場合、「注意点付きで本番環境対応」と言えます。その注意点は致命的ではありませんが、適切な検証が必要です。
既存のNodeプロジェクトをBunに移行すべきですか？
ほぼ確実にいいえ。そのプロジェクトを解決する特定の問題をBunが持っていない限り。移行にはリスクが伴います。Nodeアプリがうまく機能している場合、移行の生産性コストは、新規プロジェクトでBunを使うことと比較してめったに元が取れません。既存クライアントプロジェクトを移行したことはありません。新しいプロジェクトをBunで始めました。
Bunはすべてのワークロードに対してNodeより高速ですか？
いいえ。CPU集約的ワークロードは、結局のところ両方ともV8（Node）またはJavaScriptCore（Bun）を実行するため、最小限の差異を示します。得られるメリットはI/O集約的ワークロード、スタートアップ時間、およびBunのネイティブ実装（HTTPサーバー、ファイルI/O、SQLite）がJavaScript層の同等品を置き換える場合に最も顕著です。計算量の多いサービスでは、大した差は見られません。
Bunで最もよく動作するフレームワークは何ですか？
私が選ぶのはHonoです。軽量で、TypeScript優先で、Bunのようなランタイムを念頭に設計されています。ElysiaJSがもう一つの人気選択肢で、Bunネイティブで、印象的なベンチマーク数値を持ちます。両方を使ったことがあります。Hono本番環境での信頼度が高いのは、コミュニティが大きく、エッジケースがより詳細に文書化されているからです。
BunはやがてNodeを置き換えるのか？
完全に置き換わることはないだろう。共存するはずだ。Nodeはエンタープライズ環境での制度的な勢いが強すぎるし、npmエコシステムが両者を長期にわたって関連性のあるものにしておくだろう。Bunがすでに成し遂げたのは、Nodeに改善を促したことだ。Node 22はNode 18より明らかに高速だ。一部にはこの競争が存在するからだ。これはサーバーサイドのJavaScriptを書く誰もが得をする。
---
選ぶランタイムよりも、その上に書くコードの方が重要だ。しかし間違ったプロジェクトに間違ったランタイムを選ぶと時間を失う。そして時間だけは買い足すことができない。Bunが理にかなうところで使おう。Nodeが信頼を勝ち取ったところを信頼しよう。そして何よりも、両方で bun install を使おう。