⏱ 読了目安: 約7分
- 事実と背景:Bunが53.5万行のZigコードをRustへ4ヶ月で完全移植し、長年のメモリリークや128個のバグを解消した。
- 技術的変革:Claude 64インスタンスを並行稼働させ、実装・レビュー・修正を自律的に行うマルチエージェント体制でリライトを完遂。
- 現場への影響:Bun v1.4.0ではビルド時のメモリ肥大化が6.7GBから609MBへ激減し、安定した高速ランタイムを利用可能に。
メモリリークの悪夢とRustへの決断
開発現場で誰もが一度は直面する「メモリリークの悪夢」。深夜のオンコールで、じわじわとメモリを食いつぶすプロセスを監視し、再起動スクリプトで急場をしのぐ……そんなスパゲッティコードのツケを払わされる経験は、エンジニアなら誰しも身に覚えがあるはずだ。高速ランタイムとして彗星のごとく現れた「Bun」もまた、その例外ではなかった。
創設者のJarred Sumner氏が明かした動機は、極めて生々しい。バグの大部分が「use-after-free(解放後メモリ参照)」「double-free(二重解放)」、そしてエラーパスにおける「メモリ解放の忘れ」だったという。Zigは優れたシステムプログラミング言語だが、C言語に近いマニュアルメモリ管理を要求するため、開発者の「スタイルガイド」や規律に依存せざるを得ない。これに対し、Rustはコンパイラ(ボローチェッカー)とRAII(Resource Acquisition Is Initialization)による自動クリーンアップ(Dropトレイト)という強力なセーフティネットを提供する。「コンパイラエラーは、スタイルガイドよりも優れたフィードバックループである」というSumner氏の言葉には、私も深く同意せざるを得ない。
しかし、535,496行ものZigコードをRustに書き換えるという決断は、通常であれば「自殺行為」に近い。歴史的に見ても、コードベースの完全な書き換え(リライト)は、バグ修正や新機能開発の凍結を伴い、少人数の優秀なエンジニアチームであっても最低1年はかかる大仕事だ。そこでSumner氏が目をつけたのが、2025年12月にBunを買収したAnthropic社の最新AIモデル「Claude Fable 5」(プレリリース版)を活用した、前代未聞の「AI駆動型リライト」だった。
64台のClaudeが回す自律開発ループ
このプロジェクトの真の驚異は、単にAIにコードを翻訳させたことではなく、人間が設計した「自律型マルチエージェント・パイプライン」のアーキテクチャにある。
開発の現場で、マージリクエスト(MR)のレビューがボトルネックになり、デプロイが遅延するデッドロック状態を経験したことはないだろうか。Sumner氏はこの問題を、徹底した役割分離と並行処理によって解決した。具体的には、4つのワークスペースシャードにそれぞれ16のエージェントを配置し、計64のClaudeインスタンスを並行稼働させるという、極めてスケーラブルな分散システムを構築したのだ。
このパイプラインの核となるのが、「実装者はレビューせず、レビュアーは実装しない(The implementer doesn’t review. The reviewer doesn’t implement.)」という厳格なルールだ。まず、ZigからRustへの型やパターンのマッピングを定義した「PORTING.md」と、すべての構造体フィールドのライフタイムを記述した「LIFETIMES.tsv」という設計図を人間が用意する。実装エージェント(Implementer)がこの設計図を元にZigファイルをRustコードに翻訳し、隔離されたコンテキストウィンドウを持つ2つの対立的なレビューエージェント(Reviewer)が、ファイル差分(diff)のみを監視してバグや挙動の乖離を徹底的に暴き出す。指摘された問題は、修正エージェント(Fixer)が即座に修正する仕組みだ。
この自律ループにより、システムはピーク時に「毎分約1,300行のコード生成」「毎時最大695コミット」という、人間のエンジニアでは到底不可能な超高速デプロイサイクルを回し続けた。最終的に100万行を超えるテストアサーションをパスさせるために費やされたAPIコストは、165,000ドル(約2,400万円)。内訳は、未キャッシュの入力トークン59億、出力トークン6.9億、キャッシュされた入力読み取り720億トークンに達する。エンジニア3人が1年間フルコミットする人件費や機会損失を考えれば、このコストは破格の安さと言えるだろう。
劇的改善と「AIスロップ」への懸念
こうして誕生した「Bun v1.4.0」は、2026年8月にリリースされ、驚異的な実証数値を叩き出した。従来のZig版(v1.3.14)で開発者を悩ませていた128個の長年のバグが一掃されただけでなく、懸案だったメモリ管理において劇的な改善が見られた。
| 比較項目 | 移行前 (Zig版 v1.3.14) | 移行後 (Rust版 v1.4.0) |
|---|---|---|
| コード行数 | 535,496行 | 1,000,000行以上 (AI生成含む) |
| 既知のバグ数 | 128個の未解決バグあり | 128個のバグを解消 |
| 連続ビルド時のメモリ使用量 (2,000回実行) | 6.7 GB 以上 (メモリリークにより肥大化) | 609 MB (一定値で安定) |
| HTTPスループット | 基準値 | 2% 〜 5% 向上 |
インプロセスでのバンドルテストにおいて、Bun.build()を2,000回連続で実行した際、従来のZig版ではメモリ使用量が6.7GBを超えて無限ループのように肥大化し続けたのに対し、Rust版はわずか609MBで完全にプラトー(高止まり)し、安定した。さらに、HTTPスループットも2%から5%向上するという、システムプログラミング言語の移行としては大成功の部類に入る結果を残した。
しかし、この「AIによる100万行の超高速リライト」に対し、冷や水を浴びせた人物がいる。Zigの創始者であるAndrew Kelley氏だ。彼は「My Thoughts on the Bun Rust Rewrite」と題した痛烈な批判記事を公開し、このアプローチの欺瞞を突いた。
Kelley氏の主張は極めて論理的だ。「バグを避けるためにスタイルガイドか言語機能のどちらかを選ばなければならないという二分法は誤りだ。バグを排除する唯一の方法は、エンジニアリングリソースをそこに真摯に投入することである」と彼は説く。さらに、最も鋭い指摘はテストスイートに関する矛盾だ。「100万行の未レビューコードを出荷する根拠として『テストスイートが優秀だからすべてをキャッチできる』と言うなら、なぜ元のZigコードにはあれほど多くのバグが残っていたのか?テストスイートがZigのバグを防げなかったのに、AIが生成した100万行の『スロップ(ゴミコード)』のバグは防げると信じるのは、論理的な破綻ではないか」と。
実際、機械的な移植によって、ZigとRustの構文の類似性に起因する19個の極めて微妙なセマンティックデグレ(挙動の先祖返り)が発生していた。Bunチームは、Claude Code Securityによる11回に及ぶセキュリティレビューや、24時間365日のカバレッジガイド付きファジング(Fuzzing)をパーサーにかけ、15件のプルリクエストを経てようやく実用に耐えうる品質に仕上げたのが実態なのだ。
100万行のAIコードと我々の処方箋
ユーザーの「vitaminCPP」氏が指摘するように、100万行以上のAI生成コードをメインラインにマージしたBunは、今後のソフトウェアエンジニアリングにおける「巨大なカナリア(炭鉱のカナリア)」となるだろう。AIが生成したコードベースは、果たして人間が今後5年、10年とメンテナンスしていけるものなのか。それとも、ブラックボックス化したスパゲッティコードの山となり、技術負債のデッドロックを引き起こすのか。
我々シニアエンジニアが直面しているのは、「コードを書く」という行為の価値が急速にゼロに近づいているという現実だ。16.5万ドルと強力なプロンプト、そして厳密なパイプライン設計さえあれば、50万行のシステムコードが4ヶ月で別言語に生まれ変わる。しかし、そのコードの「正しさ」を保証し、アーキテクチャの整合性を保ち、AIが引き起こした微細なセマンティックバグをファジングやセキュリティレビューで炙り出すのは、依然として人間の高度なエンジニアリング能力に依存している。
明日から我々が取るべき処方箋は明確だ。単に「コードを書く手」としてのスキルを磨く時代は終わった。これからのエンジニアに求められるのは、AIエージェント群をオーケストレートする「システムアーキテクト」としての視点であり、AIが生成したコードの挙動を厳密に検証するための「テスト駆動開発(TDD)」や「カバレッジ分析」「ファジング」といった検証技術のマスターである。
最後に、我々自身に問いかけたい。あなたのチームのテストスイートは、明日AIが生成する10万行のコードを迎え撃つ準備ができているだろうか?そして、あなたは「AIが書いた100万行のコード」の責任を、プロフェッショナルとして引き受ける覚悟があるだろうか?


コメント