Bunというプロダクトは、もともと言語選定の段階から大胆な決断で知られていました。Jarred Sumner氏がRustではなくZigを選んだことは当時の界隈でも議論を呼びましたし、そのBunがいまRustへの全面書き換えを進めているという事実は、ランタイム開発の現場で何が起きているのかを考えるうえで非常に示唆的です。さらに今回の移植は、Anthropicの大規模言語モデルであるClaudeをエージェントとして活用しているという点でも特異です。本稿はその全体像を、JavaScriptやTypeScriptで日々開発をしている読者の視点に立って整理します。
BunがZigを選んだ背景とランタイム設計
最初に、なぜBunがそもそもZigで書かれていたのかというところから振り返ります。ここを押さえておくと、今回の書き換えが単なる流行りではなく、ランタイム特有の事情を踏まえた判断であることが見えてきます。
- Jarred Sumner氏は2022年の段階で、Rustでは自分の生産性が出にくいと判断してZigを採用したと公表しています
- Zigには
comptimeによるコンパイル時計算、C-ABI互換、明示的なアロケータといった低レベル制御の強みがあります - BunはSafariのJavaScriptエンジンであるJavaScriptCoreと密結合しており、C++/Cの巨大なバインディング層を抱えています
- 2025年12月2日にAnthropicがBunを買収し、MITライセンスを維持したまま開発を継続しています
Node.jsやDenoがV8とTypeScript/C++を組み合わせているのに対し、BunはJavaScriptCoreの内部APIへ深く踏み込むためのグルーコードを大量に必要とします。Zigのcomptimeはその種のコードを表現するうえで強力でしたし、C-ABIに自然に乗れるという特性はFFIを多用するランタイム実装にとって明確な利点でした。AnthropicによるBun買収というオーナーシップの変化は、その上に乗った新しい意思決定の前提となっています。
つまりBunがZigで書かれていたのは「単に新しい言語を試したかった」という話ではなく、JavaScriptCoreと低レベルに付き合うランタイムにとって理にかなった選択だったということです。この前提を踏まえると、それを捨ててまでRustへ向かう理由の重みが見えてきます。
Rustへ移行する動機とAnthropic配下での選択
次に、なぜRustに乗り換えるのかという動機部分です。ここは単純な好みの問題ではなく、プロダクトの安定性とエコシステムの広さに関わる話になっています。
- Sumner氏自身が、メモリリークやクラッシュといった安定性の問題の修正に疲弊したと述べています
- 所有権モデルによってメモリ安全性が言語レベルで担保される点が大きな動機になっています
- Rustの広いエコシステムと整備されたツールチェーンによって、長期的な保守性が見込めます
- AnthropicがClaude Codeの開発を通じて社内にRustの文脈を厚く蓄えていることも追い風になっています
- Zigコミュニティが2026年4月30日ごろにLLM寄稿を全面禁止するAI禁止ポリシーを採用したことで、Bunの並列セマンティック解析やLLVM複数codegenによる4倍高速なデバッグビルドといったフォーク改良を上流へマージする道筋が事実上閉ざされました
JavaScriptやTypeScriptを書いている開発者にとって、ランタイムの安定性は「自分のコードのバグなのか、ランタイムのバグなのか」を切り分ける負荷に直結します。Bunチームが何より安定性に焦点を当てているのは、その意味で利用者にとっても無視できない論点です。さらにAnthropicの傘下で開発するという文脈において、Claudeをコード変換エージェントとして使い倒すうえでRustのほうがエージェントに渡せる前提や型情報が豊富である、という実利も働いていると考えられます。
Zig側のAI禁止ポリシーとの方針対立は、社外要因に見えて実は重要なポイントです。Bunチームは独自フォークの改良を上流へ戻したい立場でしたが、AIエージェントを用いた寄稿が事実上難しくなる中で、自分たちが必要とする言語側の進化を自前でコントロールできるRustへ寄せるという判断は、開発体制全体の整合性として理解できます。
Claudeを使った2フェーズ移行手法
ここからが本記事の中心です。Bunチームは、約1800ファイルというコードベースをClaudeに任せきりにするのではなく、人間とエージェントの役割分担を厳密に設計しています。
- 作業はすべて
claude/phase-a-portというブランチで進められています - Phase Aでは、各
.zigファイルの隣に.rsをコンパイル不要な形でロジック忠実に下書きします - Phase Bでは、クレート単位でコンパイル可能な状態へ整えていきます
docs/PORTING.mdに約300の変換ルールを整備し、Claudeエージェントへの指示書として機能させていますLIFETIMES.tsvでポインタ寿命を機械的に分類してから翻訳させることで、所有権設計の事故を抑え込んでいます// TODO(port):や// PERF(port):といったマーカーと、ポート信頼度トレイラーを必須化して人間レビューを担保しています
具体的な変換ルールはきわめて機械的です。たとえば[]const u8は&[u8]に、anyerror!TはResult<T, bun_core::Error>に、defer x.deinit()はDrop実装に、comptime T: typeはジェネリックとtrait boundの組み合わせに、グローバル可変状態はOnceLock<T>に置換するといった対応関係が定義されています。これによりClaudeは「ロジックは保ったまま、Rust側の語彙に翻訳する」というタスクに集中できる構造になっています。
重要なのは、アーキテクチャ判断は原則として人間が行うとされている点です。Claudeに任せるのは記号的な翻訳と下書きであり、設計判断や難所の解決は人間レビューを通します。フェーズを分け、信頼度を明示し、機械的に判断できる前処理（寿命の分類）を済ませてから翻訳させるというアプローチは、大規模なAI支援移植のひとつの型として見ても完成度が高いです。
ZigからRustへ移す際の技術的難所
Claudeを使った仕組みがあっても、言語そのもののモデルの違いから生じる難所はそのまま残ります。ここではどんなギャップを越えなければならないのかを整理します。
- Zigのアロケータと手動解放を、Rustの所有権と
Dropへ写し替える作業はそのままでは1対1にはなりません - Zigの
comptimeによるコード生成は、Rustではジェネリクスとtrait boundで表現することになりますが、表現力にギャップがあります - JavaScriptCore向けFFIの表面積が大きく、C ABIに依存していた箇所をRust側の安全な境界に落とし込む必要があります
zig buildを前提にした構成から、cargoワークスペースへの再構成が要ります- 独自のI/Oランタイムに合わせるため、
tokioやrayon、hyper、async-trait、さらにはstd::fsやstd::net、std::processといった一般的な依存も使えません - 副次効果として、旧Zigコードに潜んでいた未初期化バッファや整数オーバーフローといった問題が、Rustの借用検査やリント経由で炙り出されています
とくにcomptimeとRustジェネリクスのギャップは見過ごせません。Zigのcomptimeは型を値として扱えるため、ある種のメタプログラミングが手続き的に書けます。Rustでこれを再現するには、トレイト境界やマクロ、場合によっては手作業の特殊化を組み合わせる必要があり、単純な置換では済まない領域です。deferに至っては、Zigではブロックの末尾でデアロケータを呼ぶだけの軽い構文ですが、Rust側では所有者が誰なのかという設計判断と切り離せません。
FFI周りも同様です。JavaScriptCoreはC++のクラス群と内部のC ABIで成り立っており、ZigのC-ABI互換性はここで威力を発揮していました。Rustのextern "C"でも同じことは可能ですが、安全境界をどこに引くか、ハンドルの寿命をどうRustの所有権に持ち込むかは、ひとつずつ設計し直すしかありません。一方で、こうした移し替えの過程で旧来の脆弱な箇所が借用検査に引っ掛かって表面化することは、長期的なメンテナンス性にとって明らかにプラスになっています。
現状の進捗とコミュニティへの影響
最後に、ここまでの取り組みが現時点でどこまで進んでいるのか、そして開発者として何に注目すべきかを整理します。
- 2026年5月4日に作業を開始し、5月7日時点ではほぼ動かない出荷不可能の状態でした
- 5月8日にローカルテスト合格、5月9日にはLinux x64 glibcで99.8%のテスト合格まで到達しています
- 5月11日にはWindows、macOS、Linuxのいずれでもテスト合格水準まで届き、約200のGitHub issueが解消見込みとなっています
- 次期リリースのv1.3.14がZig版の最終バージョンになる可能性があると示唆されています
- Sumner氏自身はHacker News上で、書き換えにコミットしておらず全部捨てる可能性も十分ある、と慎重な姿勢を見せています
- 利用者から見るとAPIは不変でMITライセンスも継続するため、内部言語の選択は基本的に透過的です
JavaScriptやTypeScriptで日常的にBunを使う立場としては、内部実装の言語が何であるかよりも、安定性とリリースサイクルがどう変化するかのほうが重要です。約1800ファイルを1〜2週間で動作水準まで持ち込んでいるスピード感は、AIエージェントを開発プロセスへ組み込んだ場合の現実的な到達点として、ひとつのベンチマーク事例になっていきそうです。
開発者として注目すべきは三つあります。ひとつ目は、docs/PORTING.mdやLIFETIMES.tsvのように、AIに渡すための仕様や前処理データを人間が丁寧に整える設計です。ふたつ目は、フェーズを分け、信頼度を明示し、アーキテクチャ判断を人間に残すという役割分担の設計思想です。三つ目は、ランタイムのような低レベルプロダクトでさえ、メモリ安全性やエコシステムを理由に言語選定が動きうるという事実そのものです。Bunの選択がどう着地するにせよ、この移行プロセスはAI時代の大規模ソフトウェア開発を考えるうえで、追いかけておく価値のある事例だと言えます。
