何が起きたか
Bunは高速なJavaScript/TypeScriptランタイムです。作者のJarred Sumner氏は、その中核をシステム言語Zigから、メモリ安全性を売りにするRustへ書き換えた顛末をブログで公開しました。5月9日に予告してから記事の執筆に手間取り、「書き換えそのものより記事を書くほうが時間がかかった」と振り返っています。
書き換えの動機はメモリ管理でした。バグ一覧の多くが、解放済みメモリへのアクセス（use-after-free）、二重解放（double-free）、エラー経路での「解放し忘れ」だったといいます。これらは安全なRustではコンパイルエラーとして弾かれ、DropによるRAII的な自動クリーンアップが効きます。
注目すべきはZigへの評価です。Sumner氏はバグをZigのせいにせず、「GC（ガベージコレクション）と手動メモリ管理を混在させるのは稀なユースケースで、どの言語もそこを想定して設計していない」「Zigがなければここまで来られなかった」と明言しています。
なぜ成立したか──テストとエージェント
この書き換えの核心は「AIエージェントによる協調エンジニアリング」です。移植の初期はエージェント・ハーネス（自動実行の枠組み）が大部分を自動化し、当初は現在Mythos/Fableとして提供されるモデルの旧版を使った実験に過ぎませんでした。Sumner氏自身も動くとは思っていなかったといいます。
流れを変えたのが、TypeScriptで書かれたBunのテストスイートです。テストが言語非依存の「適合性スイート」として機能したため、Zig版とRust版の挙動を同じ基準で照合できました。数日で高い割合のテストが通り始め、氏の判断は「試す価値がある」から「これはマージする」へ変わりました。
約11日間、氏はワークフローを監視し、出力を手で読み、問題があればClaudeにループ自体を修正させました。100万行超のLLM生成コードをマージできた自信の源は、100万件のアサーションを持つテストスイート、敵対的コードレビュー、そして「コードを手直しするのではなく、コードを生成するプロセス側を直す」という方針でした。
「二度とやるな」の常識が変わる
Sumner氏は、Joel Spolsky氏が2000年4月に書いた古典「Things You Should Never Do, Part I」に触れます。動いているソフトを止めて一から書き直すな、という有名な教訓です。氏は「コーディングエージェントがこの方程式を変える」と位置づけます。従来、Bunのようなプロジェクトにとって言語選択は不可逆な「片道切符」でした。それが揺らぎ始めたわけです。
💼 事業会社視点：これは自社にどう効くか
「動いているコードのフルスクランブル書き換えは禁じ手」という20年来の常識が、エージェント前提で崩れつつある点が最大の示唆です。ただし成立条件は明確です。Bunの成功は、100万件のアサーションを持つ言語非依存のテストスイートが先にあったから成り立ちました。裏を返せば、テストが薄い受託開発の巨大レガシーや、仕様がコードにしか存在しない基幹システムでは、同じ手は再現しません。日本企業のSIer・受託開発が「AIで全面刷新」を売り込む前に、まず投資すべきは移植先の言語選定ではなく、挙動を固定する適合性テストの整備です。SaaS事業者にとっては、E2E・APIレベルの回帰テスト資産が、そのままAI書き換えの担保になり得る戦略資産に変わります。コスト面も直視すべきで、約16万5000ドルはAnthropic社内でトークン課金が実質ゼロだったからこそ許容された規模です。役員は「AIなら安く速い」ではなく、「テスト網とレビュー体制への先行投資が、将来の技術的負債の一括返済オプションを買う」と捉え、テスト資産の棚卸しから着手すべきです。