Bun の Rust 書き換え実験 — Anthropic 買収後に動き出した 70 万行移植の真意

はじめに

2026 年 5 月 5 日、JavaScript ランタイム Bun のリポジトリに「Zig→Rust ポーティングガイド」を含むコミットがマージされ、コミュニティがざわついた。Hacker News では 300 件超のコメントが付き、「Bun is being rewritten to Rust」というスレッドが急上昇。Zig 採用を「速度の象徴」として宣伝してきた Bun が、なぜいま Rust に舵を切ろうとしているのか。本記事では、コミット内容・公式の説明・コミュニティ反応を踏まえて、この決定の背後にある技術的・政治的な構造を整理する。

何が起きたのか — 「Phase A / Phase B」の正体

今回マージされたのは、Zig コードを Rust に翻訳するための AI 駆動ポーティングガイドだ。claude/phase-a-port ブランチで作業されており、対象は 約 770,000 行・1,600 ファイル という Bun のコアロジックの大半に及ぶ。

Bun 作者の Jarred Sumner 氏は Hacker News で、この移植が確定路線ではないことを明言している。

there is no commitment to rewriting, only that I’m curious to see what a working version of this looks like. it’s very possible all of this code gets thrown away.

ガイドが定義するフェーズはシンプルだ。

Phase A: Zig のロジックを Rust の文法で写し取る段階。コンパイルが通らなくてよい。重要なのは挙動の意図と所有権の流れを Rust の語彙に翻訳しきること。
Phase B: クレート単位でコンパイルを通していく段階。型定義・ライフタイム・FFI 境界を整理し、漸進的にビルド可能な状態へ持っていく。

つまり今出回っているのは、本番で動く Rust 版 Bun ではなく「翻訳ドラフト」に過ぎない。それでもこのコミットがニュースになったのは、後述する三つの背景が同時に効いているからだ。

技術的・組織的背景 — 三つの圧力

1. Zig フォーク維持のコスト

Bun チームは独自の Zig フォークを抱えている。並列セマンティック解析と LLVM バックエンドの最適化により、デバッグビルドを 約 4 倍高速化 したフォークだ。これを upstream に投げたが、Zig コアチーム（リード: Andrew Kelley 氏）は「非決定論的挙動を含む」として却下している。

Bun ほどの規模になると、コンパイラの差分を永続的にメンテナンスする負担は無視できない。Zig 自体がベータ言語で破壊的変更が頻繁に入る現状では、フォーク追従コストが直接的な「税金」になる。

2. AI コントリビューション政策の衝突

Zig には issue/PR/コメント全てで AI 由来の貢献を禁止する厳格なポリシー がある。一方、Bun は 2025 年後期に Anthropic に買収されており、社内開発フローは Claude Code を含む AI エージェント前提に組み立てられている。

「Bun が Anthropic 製品である以上、AI 禁止ポリシーの言語にコアを依存し続けるのは戦略的に成立しない」

これは The Register の解説でも繰り返し指摘される論点だ。Phase A のガイド自体が AI による翻訳を前提に書かれていることからも、これが単なる言語選好の問題ではなく 開発ワークフローと言語ガバナンスの非互換 であることが分かる。

3. メモリ安全性「規制化」の波

CISA をはじめとする規制側は、2026 年に入ってから「メモリ安全言語の使用」を best practice ではなく mandate として位置づけ始めた。Zig は手動メモリ管理であり、スタック割り当てメモリへのポインタ返却が C と同様に未定義動作になりうる。500K 行以上の C/C++ コードと FFI でつながる Bun のような巨大ランタイムでは、Rust の所有権モデルが提供する コンパイル時のメモリ安全保証 は無視できない差別化要素になる。

The Register の表現を借りれば、今回の移植は「パフォーマンスの話ではなく、生存戦略（survival）」だ。

エンジニアへの影響 — どう向き合うか

短期的には、現在の Bun（Zig 版）を採用しているプロダクトに即座のインパクトはない。Phase A の翻訳は実験段階で、本番リリースに切り替わるロードマップは公表されていない。Sumner 氏自身が「全コード破棄もありうる」と書いているとおり、Rust 版が安定版に乗るまで最低でも数四半期、現実的には 1〜2 年スパンと見るのが妥当だろう。

中期的に注視したい論点は以下の三つだ。

コンパイル時間の劣化リスク: Zig 採用の主因は速いコンパイルだった。Rust は LLVM 経由でも段違いに遅く、Bun の開発体験（ホットビルド、CI 時間）が悪化すれば運用側にしわ寄せが来る。
FFI 境界の互換性: bun:ffi を使っている Native ライブラリは、Rust 版で ABI/呼び出し規約が変わらない保証がない。プラグイン作者は移行ガイドを早めにウォッチすべき。
ランタイム選定の判断軸: Node.js / Deno / Bun の三択は、これまで「速度（Bun）」「Web 標準準拠（Deno）」「エコシステム（Node）」で語られてきた。Rust 版 Bun が現実になれば、安全性とフォーク負債の文脈が新しい軸として加わる。プロダクト寿命が長い領域ほど、この軸は効いてくる。

短期で乗り換える必要はないが、自社の依存スタックが Bun に深くロックインしている場合は、Phase B の進捗、FFI 互換性ノート、ベンチマーク変動を四半期ごとに確認するワークフローを組んでおくとよい。

まとめ

Bun の Rust 書き換えは、単なる言語選好の話ではない。Zig フォークの保守負債、Anthropic の AI 駆動開発との政策衝突、メモリ安全性の規制圧力 という三つの力が重なった結果として、ほぼ必然的にトリガーされたプロジェクトだ。とはいえ現状は Phase A の翻訳ドラフト段階であり、Sumner 氏が言うとおり破棄の可能性も十分にある。エンジニアとしては、騒ぎに反応するより、Phase B のコンパイル成功率と FFI 互換性ノート を冷静に追うのが正しい立ち位置になるだろう。

今日のその他のニュース

Async Rust never left the MVP state（HN 390pts）: Rust の async が Pin・ライフタイム・tokio/async-std エコシステム断絶という根の深い課題を抱えたまま「MVP 段階」を脱せていない、という強い批判記事。Rust で非同期コードを書く人は読んでおきたい。
Chrome silently installs a 4 GB AI model（HN 872pts）: Chrome が同意なしで Gemini Nano モデル（4GB）を端末にインストール。プライバシー・帯域・ストレージの全方位で議論が炎上中。
AI didn’t delete your database, you did（HN 420pts）: AI 起因のオペミスは結局のところ権限設計の問題、という主張。AI エージェントを本番権限で動かす際のリスク管理に直結する論考。