7月17日、Pragmatic Engineerが「The Pulse: What can we learn from Bun's rapid Rust rewrite with AI?」と題した記事を公開した。Pragmatic Engineerは、エンジニアリング組織・ソフトウェア開発の実態を深く掘り下げることで知られるGergely Oroszによるニュースレターであり、「The Pulse」はその定期シリーズのひとつだ。今回の記事では、JavaScriptランタイム「Bun」がAIエージェントを活用してZigからRustへの大規模コードリライトを11日間・16.5万ドル（約2,400万円）で完遂した事例について詳しく紹介されている。
月間2,200万ダウンロードのBunが抱えていた問題
Bunは、JavaScript/TypeScriptのトランスパイル・バンドル・テスト実行・パッケージ管理を一手に担うランタイムだ。月間ダウンロード数は2,200万に達し、Claude CodeやOpenCodeといったツール、VercelやRailway、DigitalOceanといったホスティング事業者が正式サポートしている。
問題の根源はBunの実装言語であるZigにあった。Zigはメモリ安全性を保証しない言語であり、Bunのコードベースではガベージコレクション管理のメモリと手動管理のメモリが混在している。これが継続的なクラッシュやメモリリーク、ヒープ領域外書き込みといったバグの温床となっていた。
Bunの作者Jarred Sumnerはこう述べている：
「バグ修正リストを見るたびに気が滅入り、Bunのクラッシュを心配しながら眠りにつく日々に疲れた。Zigのせいではない——ガベージコレクションと手動メモリ管理を混在させる必要があるソフトウェアは珍しく、どの言語もそのために設計されていない」
対策としてBunチームはZigコンパイラにパッチを当て、Rust由来のスマートポインタをコードベースに追加した。しかし「自前のスマートポインタはRustより使い勝手が悪く、保証も得られない」という限界があった。
なぜRustリライトは「現実的でない」とされてきたか
Rustへのフルリライトは長年「悪手」とされてきた。 理由はシンプルで、時間がかかりすぎるからだ。
Bunのコードベースはコメントを除いて535,496行のZigコード（1,448ファイル）で構成されている。Jarredは「手作業なら、コードベースを深く知る3人のエンジニアで約1年かかる。その間、Node.js互換性の改善もバグ修正もセキュリティ対応も新機能実装も止まる。絶対にやらなかった」と断言している。
典型的なリライトプロジェクトの実態はこうだ：
- 9ヶ月と見積もる
- 9ヶ月後、元のコードベースに新機能が追加されていてまだ6ヶ月残っている
- 15ヶ月後も同じ理由でまだ終わっていない
- 運良くいけば18ヶ月で完了——当初見積もりの2倍以上
それが、AIエージェントツール「Fable」によって状況が一変した。
11日間のリライト：10ステップの全貌
Jarredが実践したプロセスを順に追う。
Step 1: 事前準備（約3時間）
いきなりコードを書かせるのではなく、まずClaudeとZig→Rustのパターンマッピングを3時間かけて議論した。その成果物が600行のPORTING.mdだ。このガイドには「tokio、rayon、async fnは使用禁止」「借用チェッカー対応のためのコード変形は許可する」といった具体的なルールが明記されている。このファイル自体がHacker Newsで話題となり、Zig→Rustポーティングガイドとして注目を集めた。
Step 2: 試験実行と敵対的レビュー
1,448ファイルのうち3ファイルをリライトし、別セッションのClaudeインスタンスに「敵対的レビュー（adversarial review）」——変更を批判的に検証するレビュー——を2回実施して品質を確認した。
Step 3〜5: 64エージェントによる並列実行（約2日）
本番では64のAIエージェントを並列稼働させ、ファイル単位で独立した作業を分担した。各コミットは2つの敵対的レビューを経てからマージされる設計だ。
途中、エージェント同士がgit stashやgit resetを干渉し合うトラブルが発生したが、Claudeにワークフロー自体を修正させて解決した。最終的には4つのワークツリーに分割し、各ツリーで16エージェントを並走させた。
Step 6〜7: コンパイルエラーの修正（約12時間）
リライト完了後、約16,000件のコンパイルエラーが残存した。人間1人では到底捌けない量だが、64エージェントが深夜から午前11時半まで自律的に修正し続けた——Jarredとチームが眠っている間に。
Step 8〜9: テストスイートの通過（約5日）
コンパイルが通った後、大規模なテストスイートを実行・修正してCIを通過させるまでにさらに数日を要した。
Step 10: 完了
全テストが通過し、11日間で535,496行のZigコードが6,500コミットを経てRustに書き換えられた。
コスト：$165,000（約2,400万円）という数字をどう見るか
API価格ベースで計算すると、今回のリライトのコストは16.5万ドル（約2,400万円）に達した。内訳は未キャッシュ入力トークン59億、出力トークン6.9億、キャッシュ済み入力トークン読み取り720億だ。
米国中堅企業のソフトウェアエンジニア1名の年収相当額——と聞くと高く感じる。しかしHashiCorp創業者のMitchell Hashimotoはこう述べている：
「$165,000という額は信じられないほどのお買い得だと思う。その給与水準のエンジニアが11日でClaudeが達成したマイルストーンを実現できる可能性は絶対にない。N人のエンジニアに$165,000を総額で払っても11日では計算が合わない」（Xより）
コストを下げる余地もある。記事では「高度な計画立案には高性能モデルを使い、コーディングやレビュー作業は安価なモデルに任せる」という方法が示唆されている。
同じことを再現するための3条件
Jarredの事例を汎用化するにあたり、記事では3つの前提条件が挙げられている：
- コードベースを深く理解した、高いモチベーションを持つエンジニアの存在
- テストが通れば動作を保証できる、極めて堅牢なテストスイート
- 結果が不確かな状態でトークンコストへの投資を厭わない覚悟
このうち最も重要なのは2番だ。テストスイートの品質がリライトの信頼性をほぼ決定する。逆に言えば、テストが不十分なプロジェクトではこのアプローチは機能しない。
AIによるマイグレーションが現実的な選択肢として浮上してきた——ただし、Bunのように工学的に堅固なプロジェクトに限った話ではある。
詳細はThe Pulse: What can we learn from Bun's rapid Rust rewrite with AI?を参照していただきたい。
