Bun 1.4、AIの53万行移植は信頼できるか

2026年8月26日 20:38

「53万行を、11日でRustへ移植」。8月20日にリリースされたJavaScriptランタイム「Bun 1.4」の数字は、それくらい派手です。

ただし、この数字の多くは作った側の自己申告でもあります。だから公式資料を突き合わせて、手元でも測りました。

先に結論を3行で。

・Bun 1.4は、Zigで書かれた53.5万行をClaude Codeが11日間でRustへ移植した初の正式版です
・成立させたのはモデルの賢さより、翻訳ルールの文書化・敵対的レビュー・100万アサーションのテストという仕組みでした
・手元のMacの実測でも起動1.6倍・メモリ4割減を確認。ただし「保守し続けられるか」の審判はこれからです

エンジニア6年目のぼくが、どこまでが確認できた事実で、どこからが未検証なのかを仕分けて整理します。

確認できたこと、できないことの一覧

公式発表の主な主張を、一次ソースと突き合わせて仕分けした結果がこの表です。

・主張｜根拠｜独立した裏付け｜判定
・Zigの53.5万行（1,448ファイル）を11日で移植｜公式ブログとGitHubの公開記録｜リポジトリの言語構成がRust 67%・Zig 0%に変化｜おおむね確認
・ピーク64並列・マージ前時点で約16.5万ドル｜公式ブログ（自己申告）｜なし。API価格換算で実支出ではない｜未検証
・起動・メモリの性能向上｜公式ベンチ＋筆者の手元実測｜方向は手元で再現（後述）｜確認
・品質維持（リグレッション19件・全修正）｜公式開示＋約100万アサーションのテスト｜長期データなし｜部分的に確認
・保守し続けられるか｜まだ実績が存在しない｜なし｜未判定。ここが本題

コミット6,778、最終diff +1,009,272行、テストのスキップ・削除0件、といった数字も公式ブログの記載です。「人手ならコードベースを熟知したエンジニア3人で約1年」も、作者自身の見積もりです。

何が起きたか。53万行の「機械移植」だった

Bunは高速さを売りにするJavaScriptランタイムで、これまでZigという言語で書かれていました。

公式ブログ「Bun 1.4」の冒頭には、こう書いてあります。「And it rewrites Bun from Zig to Rust.」（そしてこのリリースは、BunをZigからRustへ書き換える）。

作者のJarred Sumner氏が手法を公開した別記事「Rewriting Bun in Rust」によると、進め方はこうです。

まずコードを書く前に、ZigのパターンをどうRustに写すかをClaudeと約3時間議論し、その内容をPORTING.mdという翻訳ルール文書に落とす。次に3ファイルだけでワークフローを試し、うまく回ることを確かめてから、同じワークフローを1,448ファイル全部に回していく。

体制が独特でした。実装役1体に対して、敵対的レビュー役を2体以上つける。レビュー役の仕事は「バグと、このコードが動かない理由を見つけること」だけ。

さらに言語非依存のテストスイート（約100万アサーション）が最後の砦になります。何かが壊れたら、コードを手で直すのではなく「コードを生成するプロセスの方を直す」。この原則が徹底されています。

正確に書いておくべきことが2つあります。

1つ、「Bun全体がRustになった」わけではありません。移植されたのはZig部分（約53.5万行）で、全体の約20%を占めるC++や、JavaScriptエンジンのJavaScriptCoreはそのまま残っています。

2つ、これは設計を刷新する書き直しではなく、アーキテクチャを変えない「忠実な移植」です。公式自身が「ZigをRustにトランスパイルしたように見える書き換えをする。慣用的なRustへの整理は1.4出荷後」と明言しています。unsafeブロックがRustコードの約4%に残ることも開示されています。

背景も1つ。BunはAnthropicが2025年12月に買収しており、Jarred氏もAnthropic所属です。移植にはプレリリース版のClaude Fable 5が使われました。この利益相反は公式ブログ自身が冒頭で開示しています。数字を読むときは、この前提ごと読むのがフェアだと思います。

なぜ重要か。「書き直しは最悪の一手」の値段が変わった

ソフトウェア開発には「動いているコードのフルスクラッチ書き直しは、やってはいけない」という古い経験則があります。Jarred氏自身も記事で「Historically, rewrites are a terrible idea.」（歴史的に、書き直しはひどいアイデアだ）と認めたうえで着手しています。

書き直しが危険とされてきた理由は、期間が読めず、その間に既存機能が壊れ、注ぎ込んだ工数が回収できないからでした。

今回の事例が示したのは、ここからは事実と意見を分けて書きます。

事実として公表されたのはコスト構造の変化です。作者見積もりの「3人で約1年」に対し、実績として申告されたのが「11日」でした。約16.5万ドルという数字もマージ前時点のAPI価格換算で、監督した人間の工数や失敗した試行を含まないため実費とは呼べませんが、それでも期間の縮み方は際立っています。

そして移植後のBunはNode.js互換テストを1,517件追加で通し、Playwrightやvitestが動くようになりました。

しかもClaude Code自体がBunの単一バイナリで配布されているので、Rust版Bunは正式リリース前から数ヶ月、Claude Codeの実行基盤として動いていたわけです。リリース初日から本番相当の負荷実績があった、とも言えます。

意見としては、これは「AIがすごい」話ではなく「検証を仕組みにできたチームは、書き直しの博打を工学に変えられる」話だと読んでいます。翻訳ルールの文書化、敵対的レビュー、言語非依存のテスト。どれもAIがなくても価値がある工学的な布石で、AIはその上で初めて64並列で走れた。順序が逆ではないんですよね。

逆に言えば「AI生成コードをマージできる条件」は、この事例でかなり具体化できます。①挙動を言語非依存のテストで固定できる ②実装役と壊す役を分離できる ③問題が出たらコードでなく生成プロセスを直せる ④長期の保守性を別途追跡し続ける。Bunがやったのは、この4条件を先に揃えることでした。

手元のMacで測ってみた

公式の数字が派手なので、自分の環境で方向が再現するかだけ確かめました。Zig版の最終バージョン1.3.14と、Rust版1.4.0を同じMacで比較しています。

起動時間（console.log 1行のスクリプト、10回の中央値）:

・ランタイム｜起動時間
・Bun 1.3.14（Zig版）｜7.9ms
・Bun 1.4.0（Rust版）｜4.8ms
・Node.js 24.15｜21.1ms

HTTPサーバのメモリ（Bun.serveの最小構成に1,020リクエスト後のRSS）:

・ランタイム｜メモリ使用量
・Bun 1.3.14（Zig版）｜29MB
・Bun 1.4.0（Rust版）｜17MB

起動は約1.6倍、メモリは約4割減。公式の「Linux起動2倍・HTTPサーバのメモリ13〜48%減」と方向が一致しました。

計測条件も書いておきます。2026年8月25日、Apple M4のMac（メモリ24GB、macOS 26.5）で、Zig版はGitHubリリースの1.3.14バイナリ、Rust版は公式インストーラの1.4.0を使用しました。

起動はプロセス起動込みのcold startを各10回測った中央値（ばらつきは±0.5ms程度）、メモリはBun.serve最小構成で1,020リクエスト処理後のRSSをpsコマンドで1回計測した値です。

Node.jsは手元の24.15で、公式ブログの比較対象（Node.js 26）より古い系列です。

断っておくと、これは最小構成の簡易計測で、厳密なベンチマークではありません。実際、独立の検証者Zahin Afsar氏が7月にDocker同一環境で測ったとき（対象はRust版canaryとZig版1.3、5回平均）は、速度はほぼ同等・メモリ5%前後の減にとどまりました。本人の言葉では「勝ちは勝ち、ただし地味な勝ちだ」。

ワークロードによって差の出方はかなり違います。自分のアプリで測るのがいちばんです。

賛否の対立軸は「AIか人か」ではない

Hacker Newsの議論を追うと、対立軸は「AI賛成か反対か」ではなく、もっと具体的な3点に集約されていました。

レビューなしマージの是非。 Zigの作者Andrew Kelley氏は、まずRust化以前からのBunのコードベース慣行を「ハックの上のハック」と痛烈に評しました。そのうえで「100万行のレビューなしコードを出荷する論拠は、テストスイートが全部捕まえるから十分、というものだ」と、人間が読まずにマージする判断そのものに疑問を突きつけています。

日本語圏の受け止めも同じ場所を突いています。Zennのあさひ氏は移植発表直後の2026年5月に「『すごい』と『怖い』が半々だ」と書き、驚いたのは技術でなく「人間がコードを読まずにマージできる、と判断したこと」の方だと指摘しました。

保守性の先行き。 HNで印象的だったのは、rich_sashaというユーザーの、賛否どちらでもないコメントです。「本当の試金石はこの先の保守性だ。スパゲッティがClaudeにとって読めるなら問題ないのかもしれないし、ハックの上にハックが積もる最悪のコードになるかもしれない」。これは誰にもまだ答えがありません。
検証の自己申告性。 64並列も11日も16.5万ドルも、Bunチームの自己申告です。第三者の独立検証はまだ薄く、「本番で動かした報告が出てこない」という指摘もありました。リリース翌日にステージング9サービスでCPU約50%減・メモリ約60%減を報告した企業（Scrydon）も出ていますが、これも各社の自己申告の域は出ていません。

ちなみにKelley氏の批判に対して、Jarred氏は感情的な反論ではなくファジング導入PRと修正PR5件のリンクで応じました。この応酬自体が「主張は一次資料で殴り合う」文化の見本みたいで、個人的にはいちばん好きなシーンです。

ぼく自身、AIに文章や検証を任せる仕組みを毎日回していて、この記事の一次ソース突き合わせもその仕組みの上でやっています。だから正直、この事例はひとごとではありません。

実感として、AIの成果物の品質は、モデルの賢さより検証の仕組みで決まります。今回の分水嶺も「AIを使ったか」ではなく「敵対的レビューとテストを仕組みにしたか」だったと見ています。そして2番の保守性の問いだけは、時間しか答えを持っていない。Bun 1.4は結論ではなく、審判の開始日です。

今日からできること3つ

試す。 インストールは1行です（既存環境を汚したくない人はバイナリを直接ダウンロードでも動きます）。手元のプロジェクトで bun test や bunx が動くか見るだけでも、互換性の現在地がわかります。

測る。 乗り換え判断は他人のベンチマークではなく、自分のアプリの起動時間とメモリで。ぼくの簡易計測スクリプト程度でも方向は見えます。

盗む。 これがいちばん価値があると思っていて、大規模リファクタの前に「翻訳ルール文書」を書く、実装役と別に「壊す役」を立てる、テストを言語非依存の資産として整備する。この3つはAIを使わない開発でもそのまま効きます。

おわりに

トレンドの一次ソースを検証して、手元で測って書く。この形式の記事を続けています。Bun 1.4は速度より「半年後の保守性」が本題だと思っているので、リリースの継続性や不具合の推移を追って続報も書くつもりです。フォローしてもらえると、次の検証と続報がすぐ届きます。

コメントで聞かせてください。あなたなら、AIが書いた53万行を自分のプロダクトにマージできますか。できる派・できない派のひとことでも十分です。できる派の人は「どの条件が揃えば」も添えてもらえるとうれしいです。

参考リンク（一次ソース）

Bun 1.4（公式リリースブログ・2026-08-20）:
https://bun.com/blog/bun-v1.4

Rewriting Bun in Rust（Jarred Sumner氏による手法公開・2026-07-08）:
https://bun.com/blog/bun-in-rust

AnthropicによるBun買収の公式発表（2025-12）:
https://www.anthropic.com/news/anthropic-acquires-bun-as-claude-code-reaches-usd1b-milestone

Andrew Kelley氏（Zig作者）の批判記事（2026-07-09）:
https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.html

Hacker News「Bun 1.4」スレッド:
https://news.ycombinator.com/item?id=49374797

Hacker News「Bun 1.4 Rust rewrite is not looking good?」スレッド（保守性コメントの出所）:
https://news.ycombinator.com/item?id=49357401

Jarred Sumner氏によるHN上の反論コメント（修正PRリンク付き）:
https://news.ycombinator.com/item?id=48845652

Zahin Afsar氏の独立ベンチマーク:
https://zahinafsar.com/blog/bun-canary-vs-stable-benchmark

Scrydon社のステージング実測レポート（2026-08-21）:
https://scrydon.com/insights/2026/08/21/bun-1-4-at-scrydon/

Zennの解説記事（日本語圏の受け止めの例・2026-05-15）:
https://zenn.dev/ashunar0/articles/55a669c10e6a8d

※本文中の性能数値は公式ブログおよび上記一次ソースからの転記、または筆者の手元実測です。手元実測はApple Silicon Mac・最小構成での簡易計測であり、環境により結果は異なります。