Bun の Rust 再構築から学ぶ AI の役割

こんにちは、ゲルゲーです。今回は『Pragmatic Engineer』ニュースレターの特別無料号をお届けします。

毎号、私はシニアエンジニアやエンジニアリングリーダーの視点から、ビッグテックとスタートアップの世界を解説しています。今回のテーマは、先週発行された「The Pulse」シリーズの 4 つトピックのうちの一つです。この記事を 7 日前に購読者向けに配信しました。もし転送されたメールをご覧になっている場合は、こちらから購読可能です。

先週サンフランシスコで、JavaScript ランタイム「Bun」の創設者である Jarred Sumner 氏にお会いし、Zig から Rust への書き換えについて詳しく伺いました。しかし当時、移行に使用されていたツール「Fable」が米国の輸出規制により利用できなくなっていたため、Jarred 氏はあまり詳細を明かしたがりませんでした。

image先週、Anthropic の本社で私と Jarred 氏

幸いにも現在は状況が解決し、Fable が世界中で使用可能になりました。また、Jarred 氏はプロジェクトの詳細を記した投稿も公開しています。

移行の議論に入る前に、背景をお伝えします。

Bun は非常に複雑なプロジェクトであり、多くのプロダクションソフトウェアがこの Bun に依存しています。Bun 自体が担っている機能は多岐にわたります：

• JavaScript、TypeScript、CSS のトランスパイル、ミニフィケーション、バンドリング
• テストランナー
• パッケージマネージャー（npm と互換性あり）
• その他、モジュール解決、WebSocket クライアント、Node.js 実装、多数の標準モジュールなど

現在、Bun の月間ダウンロード数は 2,200 万回に達しており、Claude Code や OpenCode といったソフトウェアがこれに依存しています。また、Vercel、Railway、DigitalOcean などのホスティングプロバイダーも、Bun を公式にサポートする体制を整えています。

なぜ書き換えが必要だったのか？

Zig はメモリエラーを完全に防げる言語ではありません。実際、メモリ関連のバグが頻発していました。Jarred氏が Bun の最新バージョンで報告したメモリ関連のバグには、メモリリークやメモリ問題によるクラッシュ、ヒープ外への書き込みなどが含まれています。

これは、Bun チームが Zig コンパイラをパッチ適用してメモリ関連の問題を減らし、エンドツーエンドのメモリリークテストを導入した後の話です。Jarred氏はこう述べています。

「バグ修正リストを見ていると気分が沈み、Bun のクラッシュを心配しながら眠る日々が続いていました。これを Zig のせいにするつもりはありません。Zig を使う他のユーザーには私たちが直面したようなバグは発生していないからです。GC（ガベージコレクション）と手動管理メモリを併用するのは非常に稀なケースであり、言語側がそのために設計されている例もありません。

Bun においては、ガベージコレクションされる値と手動管理される値のライフサイクルを正しく扱うことが、安定性の大きな課題となっていました。主な原因は小さなメモリリークで、まれにクラッシュを引き起こすこともあります。すべてのメモリアロケーションを慎重に見直す必要があります。これらのバイトはどこで解放されるのか？一度だけ確実に解放されるようにどう保証するか？JavaScript の例外処理は適切に行われたか？このガベージコレクションされたポインタは、保守的なスタックスキャナから見える状態にあるか？これはガベージコレクション対象のメモリなのか、手動管理のメモリなのか？」

メモリ安全性を確保しつつ高性能を発揮できる言語へ移行すれば、こうしたバグを排除できます。Rust はまさにその条件を満たす言語の一つです。Jarred 氏は次のように述べています。

「上記のバグリストの大部分は、使用後の解放（use-after-free）、二重解放（double-free）、エラーパスでの解放忘れが原因です。安全な Rust ではこれらはコンパイラのエラーとなり、Drop による RAII 風の自動クリーンアップが行われます。スタイルガイドよりも、コンパイラからのフィードバックループの方がはるかに優れています。」

しかし、Rust への完全書き換えは従来から最悪のアイデアとされてきました。少なくとも以前はそうでした。なぜなら、その所要時間が耐えられないほど長くなってしまうからです。

書き換えには二つの問題があります。一つ目は時間がかかりすぎる点、二つ目はそれ以上に時間がかかりすぎることです。書き換えを経験した開発者なら、事態の推移がどうなるかよく知っているはずです。

まず、どれくらいかかるか適当な推測を立てます。例えば「9 ヶ月」とします。

9 ヶ月後になっても、まだ約 6 ヶ月はかかりそうです。なぜなら、元のコードベースに新機能が追加され、それを新しい実装にも反映させる必要があるからです。

15 ヶ月が経過しても、同じ理由でまだ数ヶ月は残っています。

結局のところ、運が良ければ「機能凍結（feature freeze）」を 2 ヶ月間設けて、書き換えを約 18 ヶ月で完了させます。当初の 9 ヶ月の見積もりが、実際には 2 年以上かかることも珍しくありません。

Jarred 氏は、Bun を Zig で書き換えることをこれに例えています。

「歴史的に見て、書き換えは最悪のアイデアです。コメントを除くと、Bun の Zig 版は 535,496 ラインになります。

別の言語への書き換えには、小規模なエンジニアチームで丸 1 年かかります。」

ユーザーへの影響をゼロにするという選択肢は、現実的ではありません。そこで、安定性問題を解決するためにコードスタイルの強化で対応するのが最善策であり、Bun のコードベースに Rust 由来のス마트 포인터（スマートポインタ）を追加した際の計画でもありました。

しかし正直なところ、私はやりたくなかったのです。独自開発のスマートポインタは Rust よりも使い勝手が劣り、Rust が持つ保証さえ得られないからです。

「それなら、Anthropic の新モデル『Fable』を使って 1 週間かけて Bun を Rust で書き直せるか試してみよう」

Fable による Bun の書き換え

予想通り、Bun の書き換えは「Claude さん、Bun を Rust に書き換えて。間違いゼロで」とプロンプトを入力するだけでは実現しませんでした。Jarred は実際には以下のような手順で進めました。

ステップ 1：準備作業。Jarred によると、これは Claude との 3 時間にわたる集中した議論でした。

「コードを書く前に、Zig のコードベースにあるパターンを Rust にどうマッピングするかについて、Claude と約 3 時間話し合いました。Claude はその議論を『PORTING.md』というドキュメントにまとめ、これが Hacker News で話題になりました（Zig → Rust ポーティングガイド）」

このガイドは 600 行ほどのファイルで、以下のような指示が記載されています。

基本ルール：

• tokio、rayon、hyper、async-trait、futures は使用しない。std::fs、std::net、std::process も禁止。Bun のイベントループとシステムコールは Bun 自身が管理する。（Rust コア/標準ライブラリのスライス、イテレータ、メモリ操作、フォーマット、core::ffi は問題なし。I/O を扱うモジュールのみが禁止対象。）
• async fn（非同期関数）は使わない。すべてコールバックと状態機械で構成し、Zig と同じアプローチとする。

借用チェッカーの制約を回避するためのリシェイプは許可されています。Zig のフローで重複する &mut 参照が発生した場合は、必要なスカラー値（.len() やインデックスなど）をローカル変数にキャプチャし、一旦借用を終了させた上で再借用してください。借用チェッカーの警告を黙らせるために安易に生ポインタ（raw pointers）を使うのは避けてください。

// PORT NOTE: 借用チェッカー対応のためにリシェイプ済みです。Phase B の差分リーダーが混乱しないように注意してください。

これは、Rust に精通した人にとっては意味が通じる一連の指示です。より深く学びたい場合は、Alice Ryhl氏との対談で Rust の基本や、なぜ Rust が他言語と異なるのかについて解説しています。

ステップ 2：試運転と敵対的レビューの実施

全ファイル数 1,448 件中、Claude に 3 ファイルの書き換えを依頼しました。書き換え後、Jarred 氏は Claude が変更を加えたセッションとは別に、Claude を用いた 2 つの独立した「敵対的レビュー」セッションを実施し、結果を検証・批判させました。

ステップ 3：作業を 64 個の AI エージェントに分散

Jarred 氏は、各エージェントが互いに干渉せず並列処理できるよう、作業ファイルを分割して割り当てました。

ステップ 4：実行時の問題解消（約 1 日）

実際にこれらを実行しようとした際、エージェント同士が互いの邪魔をしていました。

「Claude に全 1,448 個の .zig ファイルに対してワークフローをループさせようとしたのですが、開始から約 2 分後に、ある Claude がコミット前に git stash を実行し、別の Claude は git stash pop を実行。さらに別のプロセスでは git reset HEAD --hard が走っていました。まるで互いに踏みにじり合っている状態です！

各 Claude を別々のワークツリーに隔離すれば解決するかもしれませんが、Bun の Git リポジトリが巨大すぎるためディスク容量がすぐに不足してしまいます。また、最終的にはすべての変更をまとめてコンパイル・確認する必要があるので、完全に分けるわけにはいきません。」

そこで、Claude にワークフローを編集させました。具体的には、「特定のファイルを一度にコミットしない git コマンド（git stash や git reset など）や cargo コマンドは絶対に実行しない」という指示です。遅いコマンドも一切禁止しました。

すると Claude は再び作業を開始し、実際に機能するようになりました。ただし速度が遅すぎるため、ワークフローを 4 つのシャードに分割しました。それぞれが独立した worktree を持つ構成で、合計 4 つの worktree で、それぞれ 16 台の Claude が並列動作し、ファイルをコミット・プッシュする仕組みです。

ステップ 5：実行して約 2 日間待ちます。並列エージェントたちが動き出し、2 日間で Zig コード 535,496 ラインの書き換えを完了しました。各コミットは、2 つの敵対的なレビュー（adversarial review）を経た後でないと確定されません。

ステップ 7：約 1,600 のコンパイルエラーを修正（約 12 時間）。書き換え自体は完了しましたが、まだ何もコンパイルできません。Jarred は「crate」ごとに Claude にエラー修正を命じました。「crate」とは Rust におけるトップレベルのコンパイル単位のことです。この作業は人間エンジニアにとっては途方もないタスクですが、Claude には問題ありません。

「循環依存関係を解消した結果、約 16,000 のコンパイルエラーが見つかりました。人間 1 人にとっては膨大な数ですが、同時に 64 台の Claude を動かせば決して異常な数ではありません。

並列性を最大化するため、ワークフローは各 crate を順にループします。

• 各 crate に対して cargo check を実行し、出力をファイル単位でグループ化してエラーを保存する
• その crate 内のすべてのコンパイルエラーを修正する
• 変更内容について 2 人の敵対的なレビューアーがチェックする
• 1 名の修正担当者が実際に修正を適用する」

image エージェントが一つずつエラーを修正していく様子を可視化したもの。出典：Anthropic

この移行フェーズで最も楽しかったのは、エージェントたちが深夜から午前 11 時 30 分まで稼働し、Jarred とチームが睡眠をとっている間に自らコンパイラーのバグを修正していた点です。

ステップ 8: ローカルでテストを実行する（約 2 日間）。Bun には大規模なテストスイートが存在します。次の目標は、これらのテストをコンパイルエラーなしで実行できるようにすることでした。

ステップ 9: CI でテストスイートをパスさせる（約 3 日間）。テストが実行可能になり（そして失敗し始めた）段階から、次はテストに合格するようコードを修正しました。これには 2 日かかりました。

ステップ 10: 完了！わずか 11 日で達成。すべてのテストがパスし、Jarred が期待通り動作することを確認した時点で変更をマージしました。計画から完了まで、全体で 11 日間でした。

image リライトの概要：約 55 万行のコードを、6,500 コミット、64 エージェントを使って 11 日間で移植

このプロセスは再現可能でしょうか？

API 利用料を含めると、この書き換えにはなんと 165,000 ドルもの費用がかかりました。Fable の API 価格体系によると、キャッシュ未ヒットの入力トークンが 59 億個、出力トークンが 6.9 億個、そしてキャッシュされた入力トークンの読み込みが 720 億回に達しています。Anthropic は API トークンを販売して収益を得ているため、同社にとっての書き換えコストはさらに低くなります。しかしそれでも膨大な金額です。これは米国のミドルティア企業におけるソフトウェアエンジニアの年収と同等の額になります。

では、もし人間がこれだけの作業を 1 年かけて行えたでしょうか？おそらく不可能でしょう。Mitchell Hashimoto も同様の見解を示しています。

「コストについてですが、Fable の API 利用料で 165,000 ドル（未確認）という価格は驚くほどお得だと思います。その程度の給与のエンジニアが、Claude が 11 日間で達成したマイルストーンを成し遂げることは絶対にあり得ません。たとえ N 人のエンジニアに合計 165,000 ドルの報酬を支払って 11 日間働かせたとしても、コスト対効果は合いません。

ただし、これは私の持論を再確認させる結果でもあります。特に Fable は、明確な報酬関数を持つ困難で集中度の高いタスクにおいて極めて優秀です。最近もその点についてツイートしています。」

もし AI によって、以前なら検討すらされなかったような書き換えや移行が可能になるならどうでしょうか？Jarred も認めるように、AI を使わずに Bun を Rust で書き換えるというアイデアは非現実的でした。

「手作業で行うなら、コードベースの全体像を理解したエンジニア 3 人が約 1 年を要するでしょう。その間、Node.js の互換性向上やバグ・セキュリティ対策の新機能実装は不可能です。決して実現しなかったはずです。現実的な選択肢は、何もせずこの投稿で挙げたバグと永遠に格闘し続けることでした。」

数ヶ月から数年を要する書き換えや移行が、こうしたプロジェクトが実現しない理由の多くです。コストの問題はひとまず脇に置き、こう考えてみてください。「AI が 1 年かかる書き換えを 1 週間に短縮できるなら、実行しますか？」

答えが「もちろんやる」という場合、Bun の移行事例がそのための青写真として既に存在します。ただし、記事には明記されていないいくつかの注意点があります。

• コードベースに精通し、非常に意欲的なエンジニアが必要であること
• 極めて堅牢なテストスイートが存在すること。これでテストが通れば、動作していることを確信できる状態であること
• 結果がどうなるか分からないまま、トークン消費への多額の投資をいとわない覚悟があること

公平に言えば、3 つ目の条件が最も脆弱な点です。なぜなら、コード移行のような「地味な作業」において LLM はすでに高い能力を発揮することが分かっているからです。堅牢なテストスイート（2 番目）と、細部まで手直しできる意欲的なエンジニア（1 番目）さえ揃っていれば、成功する可能性は極めて高いと言えます。

残るは、実際にどれほどのコストがかかるかという点です。おそらく 16.5 万ドルには達しないでしょう。プロジェクトをシンプルに設計したり、モデルの利用方法を工夫することで、さらにコストを抑えることも可能です。例えば、高レベルの計画策定には最も高価なモデルを使い、コーディングやレビューといったタスクには安価なモデルを活用するといった使い分けが有効です。

AI を活用した移行は確実に加速していますが、それは Bun のようにプロジェクト自体が十分に設計・構築されている場合にのみ成立します。

この抜粋が含まれる『The Pulse』の最新号をぜひご一読ください。あるいは、本日発行された最新の『The Pulse』もチェックしてみてください。本号では以下のトピックを取り上げています。

• Grok の CLI がローカルファイルをすべてクラウドへアップロードし、その挙動が露見した件
• 新たなトレンド：コードレビューの負荷が急増することへの懸念
• エンタープライズ開発者らは AI ラボの企業向け価格設定に不満を抱いているのか？そしてそれは重要なのか？
• Linux の生みの親であるリヌス・トーバルズ氏：AI は「明らかに有用」だと語る

最新号はこちらで読むことができます