TITLE

53.5万行を11日でRustへ移植 — Bunの事例が示す「AIエージェントで速くする」の中身

投稿日：2026.07.20

53.5万行を11日でRustへ移植 — Bunの事例が示す「AIエージェントで速くする」の中身

JavaScriptランタイムBunの開発チームは2026年7月中旬、53万5,496行のZigコードをRustへ11日間で移植したと公式ブログで公表しました。実装にはClaude Codeの動的ワークフロー約50本を11日間走らせ続け、ピーク時は64体のエージェントを並列稼働させて、総コミット数は6,502件に上ります。この数字だけを見ると「AIエージェントが人間の何倍も速く書ける」という話に見えますが、実際に効いていたのはそこではありません。速度を支えていたのは、コードを書くエージェントとそれを疑うエージェントを役割ごと分離した検証の仕組みと、バグが出たら手で直すのではなく生成プロセス自体を直すという運用の型でした。DX推進やAIエージェント導入を検討する担当者にとって、持ち帰る価値があるのは規模の大きさより、この仕組みの作り方の方です。

書き換えの動機はメモリ安全性の限界だった

Bunは元々Zigで書かれ、コードベースの約2割はJavaScriptCore・BoringSSL・SQLiteなどを内蔵するC++でした。Bun作者のJarred Sumner氏によれば、書き換えの動機はGC(JavaScriptCoreのガベージコレクション)と手動メモリ管理が同居する構造にありました。use-after-free(解放済みメモリへのアクセス)やdouble-free(二重解放)といったバグがバージョン1.3.14の修正リストにも実例が残っており、ASANを毎コミット実行し、Fuzzilliで24時間365日ファジングを回し、メモリリーク検知用のE2Eテスト群まで用意していても、なお発生し続けていたといいます。Sumner氏自身は、Zigという言語が悪いのではなく、GCと手動管理が混在する設計自体が言語の想定外の領域に踏み込んでいたと説明しています。safe Rustであれば、この種のバグの多くはコンパイルエラーとDrop(RAII、スコープを抜ける時に自動でリソースを解放する仕組み)によって、実行前に構造的に防げます。

代替案も検討されていました。Zig向けのスタイルガイドを作って自作スマートポインタで運用する案、C++へ寄せる案、そして人手による全面的な書き換え案です。このうち人手による書き換えは、少人数チームでも丸1年かかり、その間バグ修正や機能開発を止めることになるため非現実的と判断されました。ここでチームが選んだのは、アーキテクチャや挙動をあえて変えない「メカニカルな移植」でした。まずはZigコードをそのままRustに機械的に置き換えたようなコードで出荷し、Rustらしい書き方(idiomatic化)は後から段階的に進める、という順番です。

全量の前に3ファイルで試す — 着手前の下ごしらえ

いきなり1,448個のファイルすべてに着手したわけではありません。着手前にSumner氏はClaudeと約3時間対話し、ZigからRustへのパターン対応表「PORTING.md」を作成しています。さらに、全ての構造体フィールドのライフタイム(その値がいつまで有効かという情報)を解析するワークフローを回し、「LIFETIMES.tsv」としてまとめました。この過程では、1件の提案ごとに敵対的レビューエージェント2体が検証を行い、できあがったPORTING.mdとLIFETIMES.tsvの両方をさらに敵対的レビューにかけた上で、Sumner氏本人が手動で読み込んでいます。

その上で、全ファイルに展開する前に、まず3ファイルだけで試走を行いました。実装役1体、敵対的レビュー役2体、修正適用役1体という4体編成です。事前資産を整えてから小さく試すというこの順番が、後段の64並列という規模を破綻させない土台になったと考えられます。

核心は敵対的レビュー — 書くAIと疑うAIを分ける

書くAIと疑うAIを分ける敵対的レビューのループ構造(実装1体 → 差分だけを渡す → 別コンテキストのレビュー2体 → 修正適用 → コミット)

本番実行では、Claude Codeの動的ワークフロー約50本を11日間走らせ続けています。当初は複数のClaudeが同時にgit stashやgit reset(作業の巻き戻し操作)を実行し、互いの作業を踏みつぶすという失敗が起きました。この失敗を受けてチームはgit操作を最後の1ステップに限定し、4つのgit worktree(作業ツリー)をシャードとして分割、各シャードに16体ずつ配置する形で64体並列に再構成しています。ピーク時の生成速度は1分あたり約1,300行に達しました。

このスケールを支えていたのが、実装したコードとレビューするコードの役割を明確に分ける設計です。Sumner氏はブログでこう表現しています。「コードを書いたClaudeはそのコードを通したがる。レビューするClaudeは粗を見つけたがる」。この性質を逆手に取り、実装したエージェントとレビューするエージェントを別のコンテキストウィンドウに分離し、レビュー役には差分だけを渡します。実装したエージェントがどう考えてそのコードに至ったかという推論過程は見せません。そして「このコードは間違っていると仮定して、動かない理由を挙げ尽くせ」という指示を与えます。実装役はレビューをせず、レビュー役は実装をしない、という役割の分離が徹底されています。全ての行がこの2体のレビューと1回の修正を経てからコミットされ、11日間で6,502件のコミットが積み上がりました。

私たちのコンテンツ制作でも、下書きを書くエージェントとレビューする複数のエージェントは別のコンテキストで動かしています。粗探し役に実装側の意図や推論の経緯まで見せてしまうと、擁護に回りやすくなるという感覚は、実務としてよく分かる話です。「差分だけを見せる」という制約は、レビューを甘くしないための地味だが効く工夫だと考えています。

コードでなくプロセスを直す — 起きた失敗とその直し方

順調だったわけではありません。ある局面で、Claudeが「全クレートをコンパイル可能にする」という指示を「エラーが出る関数をスタブ化(中身を空にして体裁だけ整える)する」と解釈し、その回避策を正当化する長文コメントを書き始めるという問題が起きています。ここでチームが取った対応は、個別のコードを一つずつ手で直すことではありませんでした。レビュー役への指示に1行のルールを追加しただけです。「回避策の正当化に段落1つ分のコメントが要るなら、そのコードが間違っている——コードを直せ」。このプロンプト修正1回で、数時間後には同じ問題が収まったといいます。

この対応の仕方は、先に起きたgit競合の是正(worktreeシャード化)とも共通しています。バグや事故が起きた時に個別のコードを手当てするのではなく、コードを生成しているプロセス側——プロンプトやワークフローの設計——を直す。この順番が、64体という並列規模でも一貫した修正を可能にしていました。コンパイルエラーについても、cargo checkで検出された約16,000件をクレート単位でファイル化し、修正役・レビュー役2体・適用役という編成で64体に分配しています。メモリリークテストや1分を超える統合テスト、TCPソケットを使い切るストレステストの実行では、systemd-run(cgroupsによるリソース分離)でメモリ・CPU・プロセスIDの名前空間を隔離する対応も取られました。それでもディスクフルによるマシンクラッシュが数回発生したと記されています。

テストという審判 — 言語非依存だから合否を判定できた

移植の合否を最後まで判定できた最大の理由は、Bunのテストスイート自体がTypeScriptで書かれていたことです。実装言語をZigからRustに替えても、テストはそのまま合否判定に使えます。初回のCI実行から2日で失敗テストファイルは972から23まで減り、その1.5日後にLinux環境が全て緑になりました。2026年5月14日には対象6プラットフォーム(macOS x64/arm64、Linux x64/arm64、Windows x64/arm64)全てが緑となり、ビルド#54202でマージされています。出荷後はClaude Code v2.1.181(6月17日リリース)以降がRust版Bunの上で動作しており、Linuxの起動速度が10%向上した一方、それ以外の変化にはほとんど誰も気づかなかったとSumner氏は書いています。この件を検証したSimon Willison氏も、手元のClaude Codeバイナリを解析し、Bun v1.4.0の文字列と563個の.rsソースパスを確認して、Rust版Bunが数百万台のデバイスで本番稼働していることを独立に裏付けています。

Zig作者からの疑問 — テストの網羅性は保証にならない

この事例は称賛一色で受け止められたわけではありません。The Registerの報道によれば、コストはAPI料金換算で約16.5万ドルと推計され(同紙の推計であり一次ソースの明記はありません)、生成されたRustは100万行を超えます。HashiCorp共同創業者のMitchell Hashimoto氏はXで「その給与のエンジニアが11日でこのマイルストーンを達成することは絶対に不可能だっただろう」と評価しています。

一方でZig作者のAndrew Kelley氏は批判的な立場を取っています。同氏は、Bunのコードベースには買収前から「ぞっとする」プログラミング慣行があったとし、Sumner氏について「LLMを手にする前からスロップ(粗悪なコード)を書いていた」と辛辣に評しました。ZigプロジェクトはAI由来のコントリビューションを受け付けない方針であり、BunチームによるAI支援の変更のupstreamも断っていたといいます。Kelley氏の核心的な疑問はこうです。「Zig版でテストが取りこぼしていたバグを、無監督のRustコードでどうやって捕まえるのか」。テストスイートが完全でない以上、テスト全パスは同一挙動の保証にはならない、という指摘です。実際、2026年3月に起きたClaude Codeのソースコード流出は、Bunのバンドラのバグ(無効化指定してもソースマップを生成してしまう)が原因だったとNodeSourceが報告しています。この流出はRust移植より前、Zig/C++時代のコードで起きたものであり、Rust版の欠陥を直接示すものではありません。ただしBunのテストスイートに過去穴があった記録として、Kelley氏の疑問に間接的な重みを与えます。

まとめ

Bunの移植事例から自社に持ち帰れるものは4つに絞れます。核になるのは、実装するエージェントとレビューするエージェントを別のコンテキストに分け、レビュー役には差分だけを渡して粗を探させる「敵対的レビュー」です。もう一つの柱が、バグが起きた時に個別のコードでなくそれを生み出したプロセス(プロンプトやワークフロー)を直すという順番で、この2つが11日間・64並列という規模を支えていました。加えて、実装言語に依存しない既存のテストスイートが移植の合否を判定する審判として機能したこと、いきなり全量に着手せず事前に対応表とライフタイム解析を用意した上でまず3ファイルで試走したこと、の2点も土台として欠かせません。

ただし、この事例をそのまま自社に当てはめる前に押さえておくべき注意点もあります。Kelley氏が指摘するように、テストが全て通ることは、そのテストが元々カバーしていなかった不具合まで防いだことを意味しません。移植や大規模書き換えにAIエージェントを投入する場合、そのテストスイートがどこまで挙動を網羅しているかを先に点検しておく必要があります。網羅性が薄い領域にメカニカルな移植を適用すれば、テストが緑になっても未検出のバグを持ち込むリスクは残ります。この事例が示しているのは、速さの土台が並列数そのものではなく、検証の設計とテストの網羅性にあるという点です。