Bun 1.4は2026年8月20日に公開された、ZigではなくRustで書かれた初の安定版です。GitHubのタグを引くと、v1.3.14の src 配下は .zig が1,290ファイルで .rs はゼロ、v1.4.0では .rs が1,512ファイルで .zig はゼロと入れ替わっています。同時にNode.js v26.3.0のテストが1,517件新規通過し、起動もLinuxで10.9ミリ秒から5.1ミリ秒へ縮みました。この記事では、その数値がどんな前提で測られたのか、1.3系から上げてよい案件の線をどこに引くかを整理します。
まとめ｜Bun 1.4で最初に決まる二つの判断
1.4への移行判断は、次の2点でほぼ決まります。
1点目は戻り先をどこに固定するか。1.3.14は2026年5月13日公開の最後のZig実装版で、1.4.0とは実装言語もバイナリも別物です。bun upgrade 任せのまま上げると戻し先が曖昧になります。CIとDockerfileで版を明示指定し、ロールバック手順を書いてから上げてください。
2点目はnpmから何を外すか。1.4は sharp や node-pty の領域を Bun.Image・Bun.Terminal として取り込み、依存15個ぶんを内蔵に置き換えました。ただし外した箇所はNode.jsへ戻せません。寄せる範囲は、ランタイムを戻す可能性とセットで決める話です。
Bun 1.4の実体｜Zig 53万行のRust移植と据え置かれた領域
Bunがどのエンジンで動き、なぜV8ベースという説明が誤りなのかはBunランタイムとは？JavaScriptCoreで動く仕組みとNode.jsとの実行差・版の固定方法、インストール手順と基本コマンドはBunとは？インストール（brew・curl）から使い方・コマンドまで解説で扱っています。ここでは1.4で入れ替わった点だけを見ます。
安定版タグのソースツリーで確認するZig 1,290からRust 1,512への交代
実装言語の判定は、READMEやGitHubの言語統計を見ると誤ります。どちらも既定ブランチしか映さないためです。確実なのは配布版のタグを直接引く方法で、git/trees APIを recursive で叩けば決着します。
| タグ | 公開日 | src配下の.zig | src配下の.rs |
|---|---|---|---|
| bun-v1.3.14 | 2026年5月13日 | 1,290ファイル | 0ファイル |
| bun-v1.4.0 | 2026年8月20日 | 0ファイル | 1,512ファイル |
2026年8月24日時点の実測が上表です。つまりいま bun upgrade で入る安定版は、Rustでビルドされたバイナリ。3か月以上リリース間隔が空いたのは、入れ替えが終わるまで安定版を出さなかったためでした。
移植の実行条件｜11日間・6,502コミット・約16万5,000ドルの内訳
公式ブログ「Rewriting Bun in Rust」によれば、コメントを除いた535,496行のZigコードを2026年5月3日から14日の11日間で移植し、コミット数は6,502。作業は4つのワークツリーに分かれ、Claude Codeのインスタンスが最大64並列で走りました。トークンは非キャッシュ入力5.9B・出力690M・キャッシュ読み出し72Bで、API価格換算およそ165,000ドルです。
数字より効くのは検証の置き方です。テストはDebian 13 x64で60,624件、macOS 14 arm64で58,850件、Windows 2019 x64で57,337件を、スキップ・削除ゼロでマージ前に通しています。レビューは実装1に対し敵対的レビュア2以上という体制。移植の妥当性を疑うなら、生成量よりこの検証条件を見るほうが早いはずです。
Rust化されなかった約2割のC++とJavaScriptCoreという据え置き
全部がRustになったわけではありません。公式ブログはコードのおよそ20%がC++だと明記しており、JavaScriptCore・uWebSockets・usockets・lshpack・lsquic・BoringSSL・SQLite は埋め込まれたままです。エンジンが変わっていない以上、JavaScriptの実行意味論は1.3系から動いていません。
メモリ安全性の言い切りも避けられています。unsafe ブロックはRustコードのおよそ4%（約780,000行中の約27,000行）で、うち78%は1行。移植はアーキテクチャを変えない機械的な置き換えで、コンパイラが検出できる範囲が広がった、と読むのが実態に近いところです。
Bun 1.4の実測値｜起動・メモリ・アイドルCPUの改善幅
公称値はいずれも計測条件つきで出ています。前提を落とすと、自案件で再現しなかったときに原因を追えません。
起動時間5.1ミリ秒・Windows 15.5ミリ秒という公称値の読み方
起動時間はLinuxで10.9ミリ秒から5.1ミリ秒へ、Windowsで39.0ミリ秒から15.5ミリ秒へ短縮されました。Windows側の伸びが大きく、公称でおよそ2.5倍。ディスク使用量も93.9MBから84.8MBへ17%減っています。
ただしこの計測はhello world相当の最小スクリプトです。実案件では依存の読み込みとトランスパイルが支配的になり、短縮幅はそのまま出ません。Node.js側にもnode_compile_cacheとは？Node.js起動を約45%短縮するコンパイルキャッシュの設定と実測で扱ったコンパイルキャッシュがあり、先に入れればランタイムを替えずに差が縮まります。起動時間だけを理由にした乗り換えは割に合いません。
HTTPサーバのメモリ13〜48%減とアイドルCPU5分の1の前提条件
HTTPサーバのメモリ使用量は、ワークロード次第で13%から48%の削減と幅を持って公表されています。上限の48%だけを取ると期待値がずれるため、下限で見積もるのが安全です。アイドル時のCPU使用率は5分の1とされますが、これもhello worldの常駐プロセスでの測定値。
効くのは常時起動のプロセスを多数並べる構成で、1ノードのプロセス数が多いコンテナ環境ではアイドル分が集約効果になります。リクエストが常時飽和している構成なら、ここは寄与しません。
バイナリ約2割減とバンドル時リーク6,745MBから609MBへの変化
最も差が大きいのはメモリリークの挙動です。2,000回のバンドル処理で、v1.3.14が6,745MBをリークしたのに対し v1.4.0 は609MB。90%以上の削減で、ここが移植の主目的でした。
一方、素の実行速度の伸びは控えめです。全体で2〜5%、HTTPスループットで2.8〜4.8%。バイナリサイズはLinuxとWindowsでおよそ20%減りました。Rust化で速くなったのではなく、長時間動かしたときに劣化しにくくなったと読むのが実態に沿います。短命なプロセスを繰り返すCI用途では体感差が出ません。
Node.js互換の実測範囲｜3,743件通過でも残る未実装の輪郭
互換性の数値は伸びましたが、通過数だけで採用可否を決めると途中で詰まります。通っていない側を先に見てください。
v26.3.0のテスト1,517件追加と1.2.0からの通過数の伸び方
Bunは自前のCIでNode.jsのテストスイートを毎コミット走らせています。対象はNode.js v26.3.0で、1.4.0では1,517件が新規通過。累計はv1.2.0時点の1,450件から3,743件へ伸び、1.0以降で最大の幅になりました。
互換先であるNode.js 26本体の変更点、Temporal APIの既定有効化やLTS移行の日程はNode.js 26の新機能・変更点とLTSスケジュール総まとめにまとめてあります。Bun側の互換は追いつく形で進むため、追われる側の仕様変更を先に把握しておくと差の出どころが読めます。
node:cluster・node:tls・node:v8の部分実装が残す移行時の穴
公式ドキュメントはモジュール単位で未実装箇所を明示しています。移行前に確認すべき代表格が次の並びです。
node:cluster：実装済みだが実戦投入での検証が足りないと明記。HTTPの負荷分散はLinuxに限定されるnode:tls：pskCallback とOCSPステープリングが不足。セッション再開はプロセスをまたげないnode:v8：queryObjects、startCpuProfile、startHeapProfile、Serializer などが不足node:perf_hooks：gc・dns・resource のエントリを出さず、eventLoopUtilization は常にゼロを返すnode:async_hooks：AsyncLocalStorage は動くが、createHook と executionAsyncId はスタブ
実務でいちばん効くのは node:perf_hooks と node:v8 です。APMエージェントやヒーププロファイラはここに触れるものが多く、監視が入らないまま本番へ出る事故につながります。node:cluster でマルチプロセスを組んでいる場合も、Linux以外では負荷分散が働きません。なお node:http2 はNode側テストの94%が通っており、穴は浅い部類です。
互換テストの通過数を採用可否へ直結させないための検証手順の置き方
通過数はNode.jsのテストが通ることしか保証せず、自分の依存ツリーが動くことは保証しません。検証は次の順で置くと手戻りが小さく収まります。
- package.json の依存からネイティブアドオン（node-gyp・prebuild 系）を抽出して一覧化する
- APM・プロファイラ・デバッガが
node:v8やnode:inspectorに触れていないか確認する - テストはまずNode.js側のランナーで通してから、Bunのランナーへ切り替える
- 本番と同じ並列数で30分以上の連続稼働を行い、RSSの推移だけを見る
- 1.3.14を明示指定したイメージをビルドし、切り戻しにかかる時間を実測する
飛ばされやすいのは4番目です。1.4の主な改善はリーク挙動のため、短時間のスモークテストでは差も不具合も出ません。
Bun 1.4の新規内蔵API｜npm依存を減らせる範囲と減らせない範囲
1.4では15個の依存が内蔵に置き換わりました。ただし内蔵APIに寄せた部分はNode.jsへ戻せません。この非対称を意識して選んでください。
Bun.Imageでsharp、Bun.Terminalでnode-ptyを外せる条件
Bun.Image はJPEG・PNG・WebP・GIF・BMPのデコードとリサイズ、回転、エンコードを扱い、macOSとWindowsではHEIC・AVIF・TIFFにも対応します。ICCプロファイルも保持。公式の計測ではデコードからエンコードまでの一連で sharp 比1.38倍です。Alpineベースのイメージで sharp のビルドに詰まっていた構成なら効きます。
Bun.Terminal は疑似端末をネイティブに持ち、node-pty を置き換えます。Linux・macOS・Windowsで動作し、Bun.spawn の terminal オプションで列数と行数を指定する形。ブラウザにターミナルUIを出す社内ツールなら、Windows向けのビルド手順がまるごと消えます。ただし外した時点で、そのコードはNode.jsで動かなくなります。
Bun.cronとBun.markdownで消える運用スクリプトと残る依存
Bun.cron はOSレベルのスケジュールジョブを登録するAPIで、標準の5フィールド記法に加えて曜日名、@daily、タイムゾーン指定を受け付けます。関数として渡せば、システムのcronを使わずプロセス内で回す形も選べる。小規模な定期処理のためにcron基盤を別立てしていた構成なら、そこが要らなくなります。
Bun.markdown はHTML文字列・React要素・コールバックの3モードを持ち、GFMの表・打ち消し線・タスクリスト・自動リンクに対応します。敵対的な入力でも線形時間で解析すると明記されている点は、ユーザー投稿を通す場面で効く。.md をそのままimportできるため、パーサ依存が1つ減ります。
実験段階のHTTP/3対応と本番投入を止める構成の線引き
1.4では Bun.serve() がHTTP/2とHTTP/3に対応しました。ただしHTTP/3側は実験扱いで、公式ブログは http3: true を本番へ出すなと明示しています。検証環境までに留める判断で問題ありません。
Bun.WebView も同じ位置づけで、macOSはシステムのWebKit、LinuxとWindowsはインストール済みのChrome・Chromium・EdgeをCDP経由で操作します。スクリーンショットのBlob取得までは動くものの、実験的な改善として扱われている段階。納品物の常時稼働部分には、まだ枯れた選択肢を残すほうが安全です。
bun installのグローバル仮想ストア｜隔離リンカ導入の可否
1.4のインストール高速化は、リンカの方式変更が本体です。npm比で初回15倍、ウォームキャッシュのフレッシュチェックアウトで30倍という数値ですが、比較対象はT3スタックのNext.jsアプリ（直接依存25・総パッケージ約220）という具体構成。
linker設定の切り替え方とconfigVersionによる既定値の差
グローバル仮想ストアはopt-inで、bun install --linker isolated か bunfig.toml の [install] に linker = "isolated" を書いて有効にします。パッケージをコピーせずシンボリックリンクで解決する方式で、1,400パッケージ構成のウォームキャッシュ時に従来比7倍という計測値。
既定値がロックファイルの configVersion に依存する点は見落としやすい箇所です。configVersion 1 のワークスペースは隔離、同 1 の非ワークスペースはホイスト、1.3.2より前の configVersion 0 はホイストのまま。上げただけでは配置が変わらないため、切り替えるなら明示指定してください。
ファントム依存の遮断と引き換えに壊れる既存ツールの見分け方と対処
隔離インストールは node_modules/.bun/[email protected]/node_modules/package/ という二層構造を作り、トップレベルにはシンボリックリンクだけを置きます。宣言していない依存をimportできなくなるため、ファントム依存が実行時ではなくインストール直後に出ます。
代償として、フラットな node_modules を前提にするパッケージ、Node.jsの解決規則に従わない実行時import、node_modules を直接走査するツールが動かなくなります。配置方式の違いと移行判断の軸はvltとは？npm互換パッケージマネージャの1.0到達点と移行判断を実装者向けに解説で整理済み。切り替えるならビルドツールとリンタを先に単体で走らせ、解決エラーを見るのが最短です。
Windowsの260文字制限がライフサイクル実行で顕在化する場面
二層構造はパスを深くします。公式ドキュメントはWindowsでパス長が260文字を超えうる点に触れており、Bun自体は長いパスを扱えるものの、ライフサイクルスクリプトが作業ディレクトリとして受け取る場面で影響が出るとのこと。
Windows上のCIでpostinstallを走らせる構成では、ここが最初の詰まりどころ。リポジトリを浅い場所へ置くか、Windows側のロングパスを有効にする対処が要ります。Linuxコンテナでのビルドなら無関係です。
受託開発でBun 1.4を採用する条件と見送るべき四つの構成
ここからは判断です。1.4はBunを試す価値が出た版ですが、受託案件の実行基盤に選べるかは別の話になります。
1.3系から1.4へ上げる前に固定しておく版とロールバック経路
最初にやることは bun upgrade の禁止です。DockerfileとCIの双方で bun-v1.4.0 を明示指定し、1.3.14を指定したイメージも併せて残してください。実装言語が変わった直後の版で、既知のリグレッション19件は修正済みとはいえ、未知の差分が出ない保証はありません。
切り戻しの検証は、戻せるかではなく何分で戻せるかを測る作業です。configVersion が絡むと、1.3.14へ戻した際に配置まで変わる場合があります。一度通しておかないと障害時に判断が鈍ります。
採用してよい案件の条件｜内製での運用と単一バイナリ配布との相性
採用してよいのは、次の3条件が揃う案件です。運用を発注側が内製で持ち、ランタイムの版を自分たちで上げ下げできること。依存にネイティブアドオンが無いか、差し替えが利くこと。監視がHTTPメトリクスとログで足り、V8内部に触れるプロファイラを前提にしていないこと。
この条件下では、単一バイナリで配布できる利点が効きます。ランタイム・パッケージマネージャ・テストランナー・バンドラが1つの実行ファイルに入るため、CIイメージの構成要素が減る。bun build --compile でアセットを埋め込めば node:fs 経由でそのまま読めるので、社内ツールの配布は明確に楽になります。
見送る四構成｜V8依存APM・native addon・長期保守・監査要件
逆に、以下の4パターンでは1.4でも採用しません。
ひとつ、V8の内部インターフェースに接続するAPMを運用へ組み込んでいる案件。node:v8 の不足と node:perf_hooks のゼロ返しで監視が機能しません。ふたつ、ビルド済みバイナリのネイティブアドオンに依存し、差し替えが困難な案件。みっつ、5年規模の長期保守を請ける案件です。LTSという名称のチャネルが公式に無く、どの版をいつまで直すかの約束が取れません。
よっつ、金融や公共のように第三者監査でランタイムの供給体制を問われる案件。実装言語の全面切り替えから日が浅く、監査対応の材料が揃いません。これらに当たるならNode.js 26のLTSラインで組むほうが総コストは下がります。実行基盤の選定と運用設計を外部に相談するなら、業務用・Webアプリ開発で扱う受託の範囲を見てください。
よくある質問
実装者から出やすい質問に、一次情報へ沿って答えます。
Bun 1.4はいつリリースされましたか？
GitHubのリリース情報では、bun-v1.4.0 の公開日時は2026年8月20日（協定世界時14時07分）です。直前の安定版 bun-v1.3.14 は2026年5月13日公開で、その間に安定版は出ていません。3か月以上の空白は、Rustへの移植と検証に充てられていました。2026年8月24日時点で、npmレジストリの最新版も1.4.0です。
Bun 1.4はNode.jsの完全な代替になりますか？
なりません。Node.js v26.3.0のテスト通過数は3,743件まで伸びましたが、node:v8 や node:perf_hooks、node:tls には未実装の項目が残ります。node:cluster は公式に「実戦投入での検証が足りない」と書かれ、HTTPの負荷分散もLinux限定。置き換えの可否は、通過数ではなく自分の依存が触れているモジュールで判定してください。
Bun 1.3から1.4へ上げると壊れるものはありますか？
公式に破壊的変更の告知は出ておらず、移植で生じた既知のリグレッション19件も公開前に修正済みとされています。ただし実装言語が入れ替わった直後の版で、JavaScriptCoreは据え置きでもバイナリ構成は別物。1.3.14を明示指定したイメージを残し、本番と同じ並列数で連続稼働させてRSSの推移を見てから切り替えてください。
Rust移植でBunは本当に速くなったのですか？
実行速度の伸びは全体で2〜5%、HTTPスループットで2.8〜4.8%と控えめです。差が大きいのはメモリ挙動で、2,000回のバンドル処理でのリーク量は6,745MBから609MBへ減りました。起動時間はLinuxで10.9ミリ秒から5.1ミリ秒ですが、これはhello world相当の値。長時間稼働での劣化が減った版と捉えるのが実態に近いところです。
Bun 1.4のグローバル仮想ストアは既定で有効ですか？
opt-inです。bun install --linker isolated か bunfig.toml の [install] で linker = "isolated" を指定して有効にします。既定値はロックファイルの configVersion に依存し、configVersion 1 のワークスペースは隔離、非ワークスペースはホイスト、1.3.2より前の configVersion 0 はホイストのまま。1.4へ上げただけでは配置方式が変わりません。
関連記事
- Bunランタイムとは？JavaScriptCoreで動く仕組みとNode.jsとの実行差・版の固定方法：エンジン系統と版の固定手順
- Bunとは？インストール（brew・curl）から使い方・コマンドまで解説：導入手順と基本コマンドの一覧
- Node.js 26の新機能・変更点とLTSスケジュール総まとめ：互換先の本体側の変更点
- vltとは？npm互換パッケージマネージャの1.0到達点と移行判断を実装者向けに解説：配置方式と移行判断の比較軸
