← ブログ一覧
📖 約12分

BunのRust書き換えを実測した

Anthropic傘下のBunがZigからRustへ全面書き換え。公式ベンチマークとZig作者の批判を突き合わせ、手元でも実際にバイナリサイズと起動時間を計測した。

BunRustAIコーディングJavaScript

この記事の結論: Bunの「Zig→Rust全面書き換え」を、公式ベンチマークの丸写しではなく、手元での実測（バイナリサイズ・起動時間・簡易実行速度）とZig作者の批判記事の両方を突き合わせて検証した。結果、公式ほどの削減幅は再現できず、「AIエージェントに大規模リライトを任せる際はテスト通過率だけでなく数字の再現性とレビュー体制も見るべき」という判断材料が得られた。

リナ社長（高校生社長のやり手ギャル）× タクヤ（入社3年目）— 今回は、うちの/schedule運用で使ってるBunの中身がまるごとRustに置き換わったニュースを、手元の実測とセットで確かめる回。（登場人物について）

「タクヤ、BunがまるっとRustで書き直されたって知ってた？うちのブログ自動投稿、Claude Code経由でBunの実行ファイル使ってるじゃん。他人事じゃなくない？」

「知ってます。しかも書き直した会社がAnthropicなんですよね。2025年12月にBunを買収してたのは知ってましたが、今度はエンジン自体を差し替えたと聞いて、正直うちの運用に影響あるのか気になってました」

「でしょ？だから今日はちゃんと数字で見てこ。公式の発表を信じるだけじゃなくて、実際に手元で動かして確かめたいんだよね」

何が起きたか：BunはClaude Codeの実行基盤そのもの

2025年12月2日、Anthropicは「Claude Codeが年間経常収益10億ドルに到達した」という発表と同時に、JavaScriptランタイムBunの買収を明らかにした。Bunはオープンソース・MITライセンスのまま、開発チームがそのまま開発を継続すると公式に説明されている。ここで見落とせないのは、Claude Code（AnthropicのAIコーディングCLI）自体がBunの実行ファイルとして配布されているという事実だ。つまりBunは単なる「Anthropicが買った外部ツール」ではなく、Claude Codeの動作基盤になっている。

その買収から半年ほど経ち、Bun公式ブログは「Rewriting Bun in Rust」という記事を公開した。内容は、BunのコアをZigからRustへ全面的に書き換えたというものだ。作業は11日間、API費用は約16.5万ドル。約50のdynamic Claude Code workflowsを使い、最大64エージェントが4つのworktreeにまたがって並列稼働し、100万行を超えるRustコードを生成、約6,700件（6,755コミット）に至ったと公式は説明している。既存の大規模テストスイートはLinux x64 glibc環境で99.8%パスしたという（macOS・Windows等の一部プラットフォームは当時進行中だったと報じられている）。

「11日で100万行超って、人間のチームじゃまず無理な速度ですよね」

「そこがミソなんだよね。でもLinux環境で99.8%通ったからって、それだけで安心していいのかは別問題だと思う」

タクヤ視点：JSCとの相性問題とベンチマーク数値

技術的な動機として公式が挙げているのは、Zigのままだと解決が難しかったJavaScriptCore（JSC）まわりの例外処理・GC連携の相性問題だ。BunはJSCを組み込んでいるが、Zigの例外処理モデルとJSCのC++側のGC・例外機構の橋渡しに無理があり、これがバグの温床になっていたとされる。Rustは所有権モデルと例外安全性の面でC++との相性がZigより扱いやすく、この問題を構造的に解消しやすいという判断がRust化の動機の一つになっている。

公式ブログが挙げるベンチマーク数値（Linux環境）は以下の通り。

項目Zig版Rust版変化
起動時間517ms464ms約10%減
バイナリサイズ88MB70MB約20%減
Windowsバイナリ94MB76MB参考値
メモリ使用量（2,000ビルドのストレステスト）6.7GB609MB大幅減
Bun.serveスループット169,600 req/s177,700 req/s約5%増
node:httpスループット103,800 req/s108,500 req/s約5%増
next build13.62秒13.03秒約4%減
tscバッチコンパイル0.94秒0.89秒約5%減

「数字だけ見ると軒並み改善してますね。特にメモリ使用量の減り方がすごい」

「うん、それは素直にすごいと思う。でもさ、これって公式が用意したクリーンな環境での数値じゃん。ウチらの環境でも同じ差が出るとは限らなくない？」

リナ社長視点：16.5万ドルは高いか、そして「unreviewed slop」という批判

16.5万ドル・11日という数字を経営目線で見ると、人間のエンジニアチームで同規模の書き換えを11日で終わらせることはまず不可能だ。その意味では投資効率は高い。ただし、リナ社長が引っかかるのはコストではなく、その後に出てきた批判の中身だった。

2026年7月14日、The Registerが「Zig creator calls Bun’s Claude Rust rewrite ‘unreviewed slop’」という記事を報じた。Zig言語の作者Andrew Kelleyが、Bun開発チームの姿勢について「hacks on top of hacks（場当たり的な対処の積み重ね）」「abuse of assertions（アサーションの濫用）」と批判し、機能追加を急ぎすぎてバグや技術的負債の見直しにほとんど時間を割いていないと指摘した。特に「100万行のunreviewed slop（レビューされていないゴミ）を出荷する」ことに疑問を呈し、「Zig版のテストで見つけられなかったバグが、監督の行き届かないRustコードでどう見つけられるのか」と問うている。これに対しBun側は、問題はZig言語自体ではなくBunのエンジニアリング判断・AIエージェントへの過度な依存にあると応答した。

「これ結構重い批判だよね。テスト99.8%パスって聞くと安心しちゃうけど、テストが通ることと、人間がレビューして保守できる品質かは別の話じゃん」

「そうですね。100万行を11日で書いたということは、単純計算でもレビューが追いつくボリュームじゃないですよね」

「で、それってウチら（読者）の何が変わるの？って話なんだけど。うちも/scheduleで無人のブログ投稿routineをClaude Codeで回してるじゃん。AIエージェントに大きい作業を任せるとき、『テスト通った』だけを合格ラインにしちゃダメだなって、これ見て思った」

「うちの運用だとブログ記事の自動生成・投稿までですが、コード書き換えのような大規模作業をAIエージェントにフルで任せるなら、テストのカバレッジと人間のレビュー体制はセットで見る必要がありますね」

実機検証：Zig版とRust版を並べて実測した

ここまでは一次ソースの突き合わせだが、数字を鵜呑みにせず、サンドボックス内で実際に手元検証もした。既存インストール済みのBun 1.3.11（Zig版、/root/.bun/bin/bun）と、npm経由で導入したBun 1.3.14（Rust移植版）を並べて比較する。

$ /root/.bun/bin/bun --version
1.3.11

$ npm install bun@1.3.14 --no-save
（bun-linux-x64, bun-linux-x64-baseline, bun-linux-x64-musl 等のプラットフォームバイナリが導入される）

$ ./node_modules/.bin/bun --version
1.3.14

バイナリサイズをstat -c "%s"で実測した結果は次の通り。

旧版(1.3.11, Zig)   : 99,295,408 bytes（94.7 MiB）
新版(1.3.14, Rust)  : 92,752,752 bytes（88.5 MiB）
削減率: 約6.6%

公式ブログはLinux版で「88MB→70MB、約20%減」と主張しているが、手元の実測では6.6%減にとどまり、公式の主張ほどの削減幅は再現できなかった。バージョンや配布形態の違いに加え、1.3.14時点ではRust移植がまだ完了しておらず「nears completion（完了に近づいている）」段階と報じられている点が要因として考えられるが、断定はしない。

起動時間はbun --versionをPythonのtime.perf_counterで8回計測した（単位ms）。

旧版(1.3.11, Zig)   : [3.0, 2.5, 2.5, 2.5, 2.2, 2.3, 2.3, 2.3]  平均2.5ms
新版(1.3.14, Rust)  : [2.7, 2.4, 2.4, 2.3, 2.2, 2.2, 2.3, 2.4]  平均2.4ms

有意な差とは言えないレベルだった。--versionはプロセス起動コストが支配的で、公式が主張する「517ms→464ms」はおそらくより重い処理（Claude Code本体の起動等）でのベンチマークであり、単純な--version呼び出しでは差が測れなかったと考えられる。

簡易実行ベンチとしてbun run fib.jsでfib(28)を3回計測した（単位ms）。

旧版(1.3.11, Zig)   : [33.0, 26.1, 24.4]
新版(1.3.14, Rust)  : [20.7, 25.4, 18.6]

新版がやや速い傾向はあるが、試行回数が少なくノイズも大きいため「明確に速くなった」とは断定しない。最後に機能確認としてbun run hello.js（console.log("hello from " + Bun.version)）を実行したところ、両バージョンとも正常に動作し、書き換えによる破壊的な動作不良はごく単純なスクリプトの範囲では確認されなかった。

「バイナリサイズは減ってるには減ってるけど、公式の主張の3分の1くらいの削減幅だったんですね」

「そうなんだよ。だから『公式が20%減って言ってるから採用しよう』みたいな判断はちょっと危ないなって。自分の環境で測ってナンボじゃん」

「起動時間に至っては誤差レベルでしたし、--versionだけだと差が見えにくいというのも実際にやってみて分かりました」

まとめ・持ち帰り

BunのZig→Rust書き換えは、11日・16.5万ドルという投資効率だけを見れば驚異的だ。既存テストスイートをLinux x64 glibc環境で99.8%パスしているという事実も無視できない（macOS・Windows等の一部プラットフォームは当時進行中だったと報じられている）。一方で、Zig作者Andrew Kelleyの「unreviewed slop」批判が指摘するのは、テスト通過率とは別軸の論点——100万行超のコードを人間が十分にレビューし保守できる体制になっているかどうかだ。この2つは対立する主張というより、評価すべき軸が違う。公式ブログは「動くこと」を、批判記事は「保守できること」を語っている。

さらに手元の実測が示したのは、公式のクリーンな環境で出た数字が、自分の環境でそのまま再現するとは限らないという当たり前だが見落としがちな事実だ。バイナリサイズ削減幅は公式の約3分の1、起動時間の差は誤差レベルにとどまった。

大規模リライトをAIエージェントに任せる場面は、jinbei-labの無人/schedule運用のようにこれからも増えていく。その際に見るべきは「速度・サイズがどれだけ改善したか」という成果発表の数字だけでなく、「その数字は自分の環境で再現するのか」「テストが通った先にレビューされ保守できる体制があるのか」という2点だ。読者のみなさんも、次に大きな書き換えをAIエージェントに任せるときは、公式の成果主張を鵜呑みにせず、手元での再現確認とレビュー体制の両方をチェックリストに加えてみてほしい。

リナ社長からひとつ、読者への問い。「あんたが普段使ってるツールの『公式ベンチマーク』、自分の環境で実測したことある？それとも数字だけ見て信じちゃってる？」

参考

コメント