Bun が Zig から Rust へ、しかも11日で
JavaScript ランタイムの Bun が、535,496 行の Zig コードを Rust に書き換え直した、というニュースが飛び込んできました。作業に費やした期間はわずか11日、コミット数は6,500、走らせたAIエージェントは64体という規格外の数字です。
私が驚いたのは、これが「AIでコードを書く」という話ではなく、「AIで言語移行そのものを短期決戦する」という別の次元の話だったところです。The Pragmatic Engineer に載った Bun 作者 Jarred Sumner の記録をもとに、整理してお伝えします。
なぜ書き換えたのか
Bun は月間2,200万ダウンロード、Claude Code や OpenCode も依存する重要なランタイムです。書き換えの動機は派手なものではなく、「メモリ関連のバグに悩まされ続けていた」という切実な事情でした。
Jarred さんは Zig そのものに罪はないと明言しています。GC と手動メモリ管理を混ぜて使うケースが Bun 特有で、バグが生まれやすかったという説明です。use-after-free、double-free、エラーパスでの free 忘れ ― これらは Safe Rust なら Drop と RAII でコンパイルエラーになる。その自然な帰結として Rust が選ばれました。
535,000行の書き換えを人手でやれば優秀なエンジニア3人で1年。その間は互換もセキュリティ修正も止まる。現実的な選択肢は「事実上バグと付き合い続けること」だった、と Jarred さんは書いています。
64体のエージェントをどう指揮したのか
ここがいちばん興味深いところです。Fable に「Rust に書き換えて」と投げるだけでは当然うまくいかず、事前準備と分業設計が緻密に組まれていました。
まず3時間かけて Claude と対話し、Zig のパターンを Rust にどうマッピングするかをまとめた600行の PORTING.md を作成。tokio や rayon を使わない、独自イベントループを維持する、借用検査を回避するために raw pointer に逃げない ― こうした方針を最初に固めたおかげで、翻訳が「Bun らしい Rust」に収束したのだと思います。
数ファイルで試験、別セッションの Claude 2体で相互レビュー。方針が固まったら64体で並列書き換え。途中で git stash や git reset を打ち合うトラブルが起きたので「git は特定ファイルのコミット以外は禁止」というルールを差し込み、worktree 4つに各16体という構成に落ち着いたそうです。
書き換え本体は約2日。その後、循環依存の解消で発生した約16,000件のコンパイルエラーを crate 単位で並列に潰します。cargo check の出力をファイル別にまとめ、書き換え役1体+レビュー役2体で回す設計で、深夜0時から午前11時半までエージェントがエラーを潰していたそうです。テストとCI通過で計5日、締めて11日でした。
$165,000 という値札をどう見るか
コストは API 料金換算で $165,000。内訳は非キャッシュ入力トークン59億、出力トークン6.9億、キャッシュ入力読み込み720億で、米国のミドルティア企業のエンジニア年収に相当します。
同じ $165K を人件費に置き換えても11日で同じ成果は出せない、というのが実務家の共通見解でした。1年止まる場合の互換対応の遅れや既存バグを抱え続けるコストまで含めれば、$165K は移行判断の閾値をぐっと下げる価格帯だと思うんですよね。
私たちにとっての学び
この事例が示したのは、AIによる大規模言語移行は条件が揃えば11日単位で走らせられる、という現実です。ただ条件は緩くありません。コードベースを深く理解した動機の強いエンジニアがいること、テストスイートが堅牢で「通れば動く」と言い切れること、そしてトークン費用を投資として飲み込む覚悟。この3つが揃わないと、同じ真似はまだ難しいと思います。
一方で、これまで「割に合わない」と諦められてきたリライトが机上検討の俎上に乗るようになった、というのは大きな変化です。時間が取れないと諦めていたプロジェクトを抱えている方は、この11日という数字を頭の片隅に置いておいて損はないんじゃないでしょうか。
元記事: https://blog.pragmaticengineer.com/the-pulse-what-can-we-learn-from-buns-rapid-rust-rewrite-with-ai/