Bunが100万行をZig→Rustへ書き換えマージ — AIが6,755コミットを完遂、Bun v1.3.14が最後のZig版に

はじめに

2026年5月14日、JavaScript ランタイム Bun のメインリポジトリに、PR #30412 「Rewrite Bun in Rust」がマージされた。コミット数は6,755、移植されたコードは100万行を超え、Linux x64 glibc 上で既存テストスイートの99.8%がパスしている。これまで Zig で書かれてきた Bun のコア実装が Rust へ全面置き換わる、JS ランタイム界隈における2026年最大級の方針転換である。本記事ではこのマージの規模・技術的動機・AI エージェントが果たした役割、そして実務エンジニアが何を判断材料にすべきかを整理する。

何が起きたか — PR #30412 の規模

マージされた claude/phase-a-p... ブランチは、Bun のコア実装を Zig から Rust へ機械的に移植したものだ。数字で見ると規模感が伝わる。

6,755コミット / 100万行以上 が単一PRに含まれる
削除された Zig コードは約60万行
テストパス率99.8%（Linux x64 glibc、リリース時点）
バイナリサイズが3～8MB 縮小
ベンチマーク結果は「neutral or faster」（中立～高速化）

Bun 1.3.14 は「最後の Zig 版」として位置づけられ、以降のリリースは Rust 実装が本流となる。bun upgrade --canary で先行版を試せる段階にあり、最適化と整理作業が本番版前に進行中だ。

注目すべきは移植のスピードである。Bun 作者の Jarred Sumner は、コアチームが「we haven’t been typing code ourselves for many months」と述べており、ブランチの大部分は Anthropic の Claude エージェントが生成している。100万行クラスの移植が数ヶ月で完遂された前例は乏しく、AI 主導の大規模リファクタリングのリアルなショーケースとなった。

なぜ Zig から Rust へ？ — 3つの動機

技術的動機は単純な「Rust の方が速いから」ではない。Sumner と Bun チームが繰り返し挙げているのは、以下の3点である。

1. メモリ安全性と安定性の限界

Sumner は移行の動機を「I am so tired of worrying about memory leaks and crashes and stability issues.」と表現した。Zig の手動メモリ管理は、Bun のような数百万行規模・複雑な非同期処理を抱えるランタイムでは、メモリリークや解放後利用バグの検出コストが累積していた。Rust の所有権モデルとボローチェッカーは、これらをコンパイル時に強制できる。今回の移植中にも既知のメモリリーク・不安定テストが副次的に修正されており、ツールチェーン側の安全網が実装規模に対して十分機能している証左となる。

2. Zig フォーク維持の技術的負債

Bun は近年、独自フォークの Zig を使用しており、並列コード生成によりデバッグビルドを4倍高速化していた。だがこの改善はアップストリーム Zig にマージされず、Bun チームはコンパイラレベルで自前メンテを抱え続けていた。「アップストリームに戻せない改善」はコンパイラ層の技術的負債であり、ランタイム本体の開発に注力するうえでの重しになっていた。Rust 移行はこの負担そのものを消去する。

3. AI 開発ワークフローと Zig コミュニティの不一致

Zig コミュニティは公式に「no-AI contribution policy」を掲げており、AI 生成コードの貢献を受け付けない。Anthropic 傘下となった Bun チームの開発スタイルは AI エージェント主導であり、両者の方針は構造的に折り合わない。Rust エコシステムは AI 補助コーディングに対して中立～歓迎的な姿勢であり、ツールチェーン側の制約をワークフローに合わせて選び直す判断が下された形だ。

技術的背景 — 「同じアーキテクチャを別言語へ」

PR の説明では、移植は「essentially the same architecture, same data structures」を維持するアプローチが取られた。具体的には以下の特徴が引き継がれている。

サードパーティ依存を最小化する Bun の方針は維持
非 async Rust（async/await 抽象に依存しない）でランタイムを構築
JavaScriptCore（JSC）バインディングや FFI 境界はそのまま

これは Rust 移植としては保守的な選択で、tokio などのエコシステムへ全面依存せずにランタイム自身の制御フローと並行性モデルを保っている。結果として、ベンチマークが「neutral or faster」に収まったのは、アーキテクチャ移植のため過剰な抽象化を持ち込まなかったことが大きい。

一方で、Rust の所有権とライフタイム制約はそのまま適用されるため、Zig 時代のホットパスや低レベルポインタ操作はリファクタが入っている。バイナリサイズが3～8MB 縮むのは、Rust の単方向リンカと LLVM 最適化、および移植過程での重複コード削減が寄与している。

ただし、99.8%のテストパス率は裏返せば0.2%は未対応ということでもある。Linux x64 glibc 以外のターゲット（macOS、Windows、musl）での挙動、ネイティブアドオン互換、エッジケースのパフォーマンスは、今後のマイナーリリースで詰めていく必要がある。本番採用の判断は、自分のワークロードを canary 版で計測してから下すのが安全だ。

エンジニアへの影響 — 何を判断材料にするか

実務観点では、以下を押さえておきたい。

Bun を既に使っているチームへ: 1.3.14 は明示的に「最後の Zig 版」とされている。今後のセキュリティ修正や新機能（HTTP/3 などを含む）は Rust 実装に乗る。CI で bun upgrade --canary を回し、Rust 実装でのテスト結果を観察するフェーズに入れる時期だ。特にネイティブアドオン・FFI を多用しているコードは早めに動作確認したい。

Node.js / Deno を主軸にしているチームへ: Bun の選択肢としての位置づけは強化された。メモリ安全性が言語レベルで保証されたランタイムは、長期運用のサーバ用途で評価軸が上がる。ただし「Rust だから速い・安定」ではなく、Rust だから今後の改善が積み上げやすいという観点で見るのが妥当だ。

マネジメント/技術選定の視点: 今回最も重要な示唆は、100万行規模の移植がAI 主導で数ヶ月で完遂しうるという実例ができたことだ。リファクタや言語移行を「コスト面で諦めていた既存資産」がある場合、見積もりの前提が変わりつつある。同時に、AI 生成コードを大規模に取り込むには、テストスイートの網羅性が品質保証の最終防衛線となることも明確になった。Bun が99.8%という数字を強気に出せるのは、長年蓄積したテストスイートがあるからこそである。

まとめ

Bun の PR #30412 がマージされ、コア実装が Zig から Rust へ全面移行した（6,755コミット / 100万行超）
動機はメモリ安全性、Zig フォーク維持コスト、AI 開発ワークフローとの整合性の3点
移植は Anthropic の Claude エージェントが主導し、テスト99.8%パス・バイナリ3～8MB 縮小を達成
Bun 1.3.14 は最後の Zig 版。canary で Rust 実装の検証を始めるタイミングに入った
技術選定の観点では「AI 主導の大規模移植は現実的選択肢になった」ことが今回最大の示唆である

JavaScript ランタイムを巡る競争は、言語選定・AI 活用・コミュニティ運営という三方向の制約をどう折り畳むかの段階に入った。Bun がここで切った舵は、他のランタイム・大規模 OSS にも参照される試金石になっていくはずだ。

今日のその他のニュース

Cloudflare Workflows v2 が50,000同時実行へ拡張 — コントロールプレーンを再設計し、4,500から50,000へ大幅スケール。大規模ワークフローエンジン設計のケーススタディとして読み応えあり。

Firebase AI Logic が Gemini Dev API と Vertex AI を単一SDKで提供 — Flutter からの Gemini 活用が一段と簡素化。Firestore × Gemini 3.1 統合により推論は40%高速化されたとされ、モバイル AI 機能の組み込みコストが下がっている。

Kubernetes 1.36 GKE Rapid channel + Mutating Admission Policies GA — CEL 式によるリソース変更が Webhook の代替として正式に使えるように。Webhook ベースの管理コードを削減できる可能性がある。