535,496行を11日で「別の言語」に移す──Bunの全面書き換えが見せた、コーディングエージェントの新しい使いどころと後味

JavaScript/TypeScriptランタイム「Bun」の作者 Jarred Sumner 氏が、Bunの中身を Zig から Rust へ全面的に書き換えたことを公開しました。53万行規模のコードベースを、複数のコーディングエージェントを並走させて11日間で移し替えたという内容です。単なる高速化の話ではなく、「言語の乗り換え」という重い作業を、エージェントがどこまで担えるのかを示す事例として注目を集めています。同時に、レビューのあり方をめぐる批判も出ており、両面を整理します。

公開された数字が示す規模

作者が公開したブログによると、書き換えの規模と条件は次のとおりです。人手で進めれば1年がかりとも見積もられた作業を、11日に圧縮したと説明しています。

移行後の実測では、実行速度が2〜5%向上し、バイナリは約20%小さくなり、開発サーバー再ビルド時の計測可能なメモリリークが解消したとしています。

なぜ「速くする」ではなく「言語を替える」だったのか

書き換えの動機は性能ではなく、バグの根を断つことにありました。Bunは、ガベージコレクション（GC）で自動的にメモリを解放するJavaScriptと、手動でメモリを管理するZigを同居させています。作者は、この組み合わせが「解放済みメモリへのアクセス（use-after-free）」「二重解放」「エラー処理の境目でのメモリリーク」といった不具合を繰り返し生む温床になっていたと説明します。GCと手動管理の混在は言語設計が想定しづらい領域で、Rustの所有権モデルでこの層を作り直す判断をした、という筋書きです。

開発現場にとって何が変わるか

この事例が示すのは、「言語間の全面移植」という、これまで数か月〜1年規模で見積もられてきた作業の時間感覚が動きうる、ということです。ポイントは、エージェントに丸投げして終わりではない点にあります。

• 並列化と分割：多数のエージェントを作業ツリーごとに分け、動的ワークフローで束ねることで速度を出している。1体を賢くするより、多数を段取りよく走らせる設計が効いている。
• テストが移植の可否を握る：140万超のアサーションが「移し替えても壊れていない」ことを判定する土台になっている。厚いテスト資産があるコードほど、こうした移植の現実味が増す。
• コストは見える化される：約16万5,000ドルという値札は、人件費1年分との比較で語られている。速さと引き換えのAPI課金を、事前に見積もる前提が要る。

裏を返せば、テストが薄い・仕様が曖昧なコードベースでは、同じ手法をそのまま持ち込むのは難しいという線引きにもなります。

「テストが通れば十分」と言えるのか

一方で、この進め方には批判も出ています。Zigの作者 Andrew Kelley 氏は、100万行規模のコードを人手のレビューを通さずに出す姿勢を疑問視し、「Zigのコードのバグは捕まえきれないテスト群が、機械が生成した100万行のバグなら捕まえられるというのか」という趣旨の指摘をしています。テストが原コードのバグを取りこぼしていたのなら、その同じテストで生成コードの安全性をどこまで保証できるのか、という論点です。

これは「AIが書いたコードを誰がいつ検証するのか」という、生成AI時代の開発全体に通じる問いでもあります。速度とコスト削減は明確な利点ですが、レビュー工程を省いた大量生成には、こうした懸念も指摘されている、という温度で受け止めるのが妥当でしょう。テストの網羅性、段階的な移行、監査可能なログといった安全弁をどう設計するかが、同じ手法を自社で試す際の分かれ目になりそうです。

参照: Rewriting Bun in Rust（Bun 公式ブログ） ／ Zig creator calls Bun's Claude Rust rewrite 'unreviewed slop'（The Register） ／ Rewriting Bun in Rust（Simon Willison） ／ Bun Rewrites 535K Lines of Zig to Rust in 11 Days Using Claude（Developers Digest）