2026年8月に登場したBun 1.4は、ZigからRustへClaude Codeでフルリライトされた初のリリースです。移植の進め方とパフォーマンス改善の要点、そして自チームが移行を判断するためのチェックポイントを実務目線で整理します。

Bun 1.4が示したランタイム進化の全体像

Bun公式のリリースノートによると、Bun 1.4はRustで書かれた最初のバージョンであり、2026年8月に正式リリースされました。今回の更新では2,900件を超えるissueが修正されており、単なるマイナーアップデートではなく基盤そのものを刷新した節目のリリースだと言えます。ランタイムの言語を丸ごと入れ替えながら、これだけの修正を同時に取り込んでいる点が特徴です。

Node.js互換性の向上も見逃せません。Bun 1.4はNode.js v26相当を報告しており、1.3から1.4にかけて新たに1,517件のテストが通過しました。これはBun 1.0以来で最大の互換性向上とされています。実アプリを動かすうえで、この互換性の底上げは移行の障壁を大きく下げる要素です。

モジュール単位でも進捗が見えます。sqlite、events、trace_eventsといったコアモジュールは100%、quicは99%、httpやfsは97%以上に到達しました。標準モジュールの互換がここまで揃うと、実アプリで踏みがちな細かな非互換の落とし穴が減り、移植時の調査コストが下がります。さらにPlaywrightのconnectOverCDPやplaywright.config.ts、Vitestのカバレッジ計測とthreadsおよびforksの両プール、Next.js 16.3のTurbopackとReact Compiler、OpenTelemetryが新たに動作するようになりました。E2EテストからトレーシングまでのツールチェーンがBun上でそのまま動く見込みが立つ点は、開発現場にとって現実的な価値があります。特にCIでのテスト実行やブラウザ自動化を日常的に使うチームほど、この互換性向上の恩恵は大きいはずです。

パフォーマンス改善の実像を数値で読む

Bun公式のリリースノートによると、起動時間はhello.jsの計測でLinuxが10.9msから5.1msへ約2.1倍、Windowsが39.0msから15.5msへ約2.5倍速くなりました。アイドル時のCPU使用量は約5倍低下し、Claude Codeの本番実測ではCPUのp99が24%から10%、p50が5.8%から2.5%へ下がっています。数値の主な項目を下表に整理します。

HTTPサーバのピークメモリは100万リクエスト時にFastifyが48%、Expressが46%、Next.jsが28%削減され、フレームワークによって幅があります。ここで大事なのは、削減率が一律ではないという事実です。同じ改善でも構成やライブラリによって効き方が変わるため、平均値だけを見て過度な期待を持たない姿勢が求められます。正規表現も高速化しており、marked.parse()は80KBのMarkdownで912msから6msへと138倍、isbotは200倍になりました。加えてBun.build()を2000回呼び出すケースでは、メモリが6,745MBから609MBへ改善したリーク修正の例も公表されています。こうした極端な改善はメモリリークが解消された結果であり、あらゆる処理が同じ倍率で速くなるわけではない点に注意が必要です。いずれの数値も公表条件と自環境は異なるため、移行判断前に自分のワークロードで再計測することが前提です。ベンチマークの前提が変われば結果も変わるという当たり前の原則を、こうした派手な数値を見たときこそ思い出したいところです。

ZigからRustへ11日間で移植した舞台裏

移植の背景には二つの理由があります。ひとつはZigがAIコントリビューションを認めないポリシーを持っていたこと、もうひとつは2025年12月にAnthropicがBunを買収したことです。生成AIエージェントを開発の主役に据える方針と、既存言語の制約が噛み合わなかったわけです。

公式の移植詳細によると、作業は2026年5月3日に始まり、5月14日にmainへマージされ、計11日間で完了しました。ピーク時には64個のClaudeが並行して動き、これは4つのワークフローそれぞれに16のClaudeを割り当て、各々を別のworktreeで走らせる構成でした。動的に生成するdynamic workflowsは約50本に及びます。変換差分は約100万行を超え、ピーク時の生成速度は毎分約1,300行、API価格に換算したコストは約16.5万ドルと報告されています。

規模の大きさに対して品質を保つ鍵となったのが、事前に用意したルールブックです。ZigからRustへの変換パターンを対応表にしたPORTING.mdと、構造体フィールドのライフタイムを定義したLIFETIMES.tsvを先に整備し、エージェントが従うべき指針を明文化しました。移植パターンとメモリ安全の境界を最初に決めておく設計判断が、大量並列の生成を破綻させないための土台になっています。ルールを後から足すのではなく、走り出す前に共通の判断基準を文書化しておくことで、64個のエージェントが同じ方針でコードを書き進められた点は、大規模な自動化を設計するうえで示唆に富みます。

生成AIエージェントで大規模書き換えを進める勘所

この移植から学べる実務的な勘所は、レビューとテストの設計にあります。実装を担うエージェント1体に対して、敵対的にバグを探すadversarial reviewerを2体以上配置し、レビュー担当はdiffだけを参照する分割コンテキストで動かしました。実装の意図に引きずられず、動かない理由を能動的に探させる仕組みです。

安全網となったのは言語非依存のテストスイートです。100万を超えるassertionを持ち、スキップや削除をゼロで通し切ることを条件にしました。リライトの正しさを言語に依存しない形で担保できたため、大規模な書き換えでも挙動の変化を検知できます。cargo checkでは約16,000件のエラーが出ましたが、これをフェーズに分割して順に解消する現実的な進め方が取られました。

人間のレビューも省かれていません。Jarred Sumner氏がPORTING.mdとLIFETIMES.tsvを手動で確認し、テスト実行を手で検証し、マージ前にローカルで動作を確かめています。さらに注意すべきは技術的負債です。Rustコードの約4%がunsafeブロック内にあり、unsafeキーワードは約13,000に達します。これをパーサのファジング約1,000億回とリリース後の11ラウンドのセキュリティレビューで抑え込む発想が採られました。生成AIによる大規模移植では、速度だけでなく安全性の負債をどう管理するかが等しく重要だと分かります。

ここから自チームへ持ち帰れる教訓を整理すると、三つの柱が見えてきます。第一に、レビューを実装から切り離し、diffだけを見る敵対的な視点を複数用意することです。第二に、言語やフレームワークに依存しないテストを厚く保ち、それを移植前後で一切崩さずに通し切ることです。第三に、生成物を鵜呑みにせず、要所を人間が手で確認しローカルで検証する工程を必ず挟むことです。エージェントの生成速度が上がるほど、この三つの安全弁が果たす役割は相対的に大きくなります。速さだけを追い、検証を薄くしたまま規模を広げると、unsafeのような負債が静かに積み上がり、後から回収するコストが跳ね上がりかねません。

Bun 1.4移行を判断するためのチェックポイント

移行を検討する際は、まず安定性の読み方を押さえたいところです。公式は全6プラットフォームでCIがグリーンになり、既知の回帰19件はすべて修正済みだと報告しています。とはいえ自プロジェクトが安全に動くかは別問題なので、依存しているNode関連モジュールが互換の対象に含まれているかを先に確認することが出発点になります。

進め方としては、テストカバレッジを整えたうえで、小さなワークロードから段階的に移すのが堅実です。前述のとおりパフォーマンス値は公表条件と異なるため、自環境のベンチマークで検証してから本格導入を判断してください。あわせて評価軸に加えたいのがデプロイ面のメリットです。バイナリサイズはWindowsで19%、Linuxで20%削減されており、配布や起動のコストにも効いてきます。これらの観点を組み合わせ、互換性と性能と運用の三つを自分たちのワークロードで確かめることが、後悔しない移行判断につながります。

最後に、今回のBun 1.4は単一プロダクトのバージョンアップにとどまらない示唆を含んでいます。生成AIエージェントを大量に並列運用し、事前のルールブックと敵対的レビューと厚いテストで品質を担保しながら、11日間でランタイム基盤をまるごと別言語へ移すという離れ業が現実に成立したからです。同時に、約4%のunsafeコードという安全性の負債や、公表ベンチと自環境の差といった留意点も明確に残っています。裏を返せば、生成AIによる大規模移植は魔法ではなく、テストと人間レビューという地道な仕組みがあってこそ機能するということです。この両面を冷静に見極めたうえで、自分たちのプロジェクトにどう取り入れるかを検討していくのが賢明な向き合い方だと言えます。