Bun が Zig から Rust へ — 100万行を一晩でマージした書き換えPRの裏側
はじめに
2026年5月、JavaScript ランタイム Bun が Zig 製コアベースを Rust に書き換える巨大 PR (oven-sh/bun#30412) をマージしました。Reddit r/programming で 562 ポイントを獲得し、Node.js / Deno を含めた JavaScript ランタイム勢力図に大きな波紋を広げています。本記事ではマージされた書き換えの中身と、なぜ Anthropic 傘下の Bun チームがこのタイミングで言語ごと作り直すという賭けに出たのか、その判断の構造をひも解きます。
マージされたものの全貌 — 100万行が「ほぼ等価」で着地
PR の見出しは単純に Rewrite Bun in Rust、作者は創業者の Jarred Sumner 本人です。マージされたコードは canary チャネル (bun upgrade --canary) で即日利用可能になっており、v1.3.14 が「最後の Zig 版」として残されました。
注目すべきは「等価書き換え」を貫いた設計判断です。Sumner 自身がコメントで「同じアーキテクチャ、同じデータ構造、サードパーティライブラリへの依存も最小限のまま」と明言しており、async Rust も導入していません。つまりエコシステム上のメリットを取りに行きながら、ランタイムの内部構造は意図的に Zig 時代のままに保たれています。
テストの通過率は Linux x64 glibc で 99.8% に達し、既存テストスイートを通したうえで、いくつかのメモリリークや flaky テストが副次的に解消されたとされています。バイナリサイズは 3〜8 MB 削減、ベンチマークは「ニュートラルからやや速い」レンジ。性能ではなく耐久性のための書き換えであることがここから読み取れます。
タイムスケールも異例で、The Register は「成功テストの公表からわずか数日で 100万行超の Rust コードが一つのコミットでマージされた」と報じています。これは AI コーディングを前提にしたチームでなければ現実的でない速度です。
なぜ Zig をやめたのか — 3つの構造的理由
1. メモリ安全性に費やしてきたデバッグコストの清算
Sumner は PR コメントで「use-after-free / double-free / エラーパスでの解放忘れ」が常態化していたと吐露しています。Zig は明示的なアロケーション設計を強制する一方で、所有権を言語側で保証する仕組みがありません。Bun のように高頻度で C++（JavaScriptCore）と Zig をまたぐコードでは、これらが膨大な開発・デバッグ時間を奪っていたわけです。Rust の借用チェッカは多くを「コンパイルエラーに変換」できる、というのが Bun チームの計算です。
ただし Sumner はリークすべてが消えるとは言っていません。JS 境界をまたいで保持される参照 や 長く保持しすぎたハンドル に起因するリークはコンパイル時には検出できず、ここは依然として運用で潰す領域として残ります。
2. Zig の no-AI ポリシーとの構造的不一致
Bun チームは「もう何ヶ月も自分たちでコードをタイプしていない」と公言しています。Anthropic が Bun を買収した経緯もあり、Claude を中心とした AI 駆動開発がチームの実装スタイルそのものです。
一方の Zig は厳格な「AI 生成コードを upstream に取らない」ポリシーを採用しており、Bun が自前で改良した Zig フォーク（並列コード生成で debug ビルド 4 倍高速化など）の改善を本家に還元できない状況が続いていました。AI ポリシーとエコシステム上の整合性が取れない限り、Bun が独自フォークの保守コストを背負い続ける構図が変わらない、というのが背景にあります。
3. エコシステム規模・人材プール・周辺ツールの厚み
Rust に移ることで、依存できるクレート、メモリ安全性ツール、雇用候補のエンジニア数がすべて桁違いに増えます。Zig はまだ 1.0 にも到達していない若い言語で、商業プロダクトのコアに据え続けるには周辺ツール（プロファイラ、サンドボックス、サニタイザ連携）が痩せていました。Bun が Anthropic の事業として持続するなら、契約上・サポート上の標準的な言語にコアを乗せ直しておく価値は大きいわけです。
エンジニアへの影響 — 何が変わり、何が変わらないか
実務目線で押さえるポイントは次の3つです。
1. 既存 API の互換性は維持される
99.8% のテストパス率と「同じアーキテクチャ・同じデータ構造」という設計判断から、bun install / bun test / bun build 等の挙動が大きく変わる予定はありません。アプリケーション側で書き換える必要はなく、基本的に canary を踏んでみて壊れなければそのまま使い続けられる移行になります。
2. ネイティブ拡張の作法は今後変わりうる
コアが Rust になったことで、bun:ffi や Node-API 互換層、将来的なネイティブモジュール提供方法は中長期的に Rust 側の仕組み（napi-rs 等のエコシステム）に寄っていく可能性があります。Zig 製のネイティブ統合に独自実装で対応していた人は、今後のリリースノートを追う価値があります。
3. JavaScript ランタイム市場の競争軸が「言語選定」から「AI 駆動の改修速度」へ Node.js（C++）、Deno（Rust + V8）、Bun（Rust + JavaScriptCore）と、コア言語は揃って Rust 寄りに収斂しつつあります。これからの差別化は「Rust か否か」ではなく、「いかに速く反復できるか」「契約用途に耐える長期保守体制をどう作るか」に移ります。Bun が AI 駆動開発を前提に 100 万行を数日でマージできたという事実は、競合にとって相当のプレッシャーです。
まとめ
- Bun は Zig から Rust への全面書き換え PR をマージし、canary で配布開始。バージョン
1.3.14が Zig 版の最終リリース - 動機は (a) メモリ安全性のコスト清算、(b) Zig の no-AI ポリシーとの不整合、(c) Rust エコシステムへの統合の 3 軸
- テストパス率 99.8%、バイナリサイズは 3〜8 MB 削減、性能はニュートラル〜微増。互換性を最優先した「等価書き換え」
Bun の事例は、AI コーディング前提のチームが言語選定の意思決定で何を重視するかを示す、最初のはっきりした事例になりました。今後、AI ポリシーの厳しい言語・エコシステムは、商業プロダクトの基盤としては敬遠される流れになる可能性があります。