⚙️

Bun が 6 日で Rust に書き換わった件

に公開
1件
AI
Rust
Zig
Bun
Anthropic
idea

はじめに

2026年5月14日、JavaScript ランタイム Bun の Zig→Rust 大規模移植 PR が main ブランチにマージされた。約 96 万行のコードを、6 日間で、AI（Claude）が書いた。テストは 99.8% パス、バイナリサイズも縮小されているが、unsafe ブロックは 13,000 箇所を超え、Sumner 本人も「全部破棄する可能性が高い」と発言している。

この一連の動きを追いかけながら、初見で抱いた 5 つの素朴な疑問 を整理した。

まず、何が起きたか

時系列で圧縮するとこうなる。

  • 2026/05/05：Bun 創業者 Jarred Sumner、「Anthropic 内で Zig→Rust の試験ポートを進めている」と公表
  • 2026/05/09：Linux x64 (glibc) で テスト 99.8% パス を本人がアナウンス
  • 2026/05/12：Bun 1.3.14 リリース。Sumner「もしマージされたら、これが最後の Zig 版」と発言
  • 2026/05/14：100 万行超の単一 PR が main にマージ

サイズ感を数字で並べる。

項目 数値
追加された Rust コード 約 96 万行
削除された Zig コード 約 60 万行
工数 6 日（AI ベース）
テスト通過率 99.8%（Linux x64 glibc）
バイナリサイズ削減 3〜8 MB
unsafe ブロック 13,000 箇所超

なお、Bun は Anthropic に買収済み のプロジェクトで、AI コーディングツールとしては Claude（Anthropic 自社製） が使われている。つまりこれは、Anthropic が自社の AI で自社のランタイムを書き換えた という構図でもある。この点は疑問③以降で何度か顔を出す。

公式の詳細ブログは 2026/05/15 時点では未公開。情報は Sumner の X 投稿、PR タイムライン、The Register などの報道に散らばっている。

疑問① 100万行、誰も読んでないやん

率直に言って、これが最初の引っかかりだった。100 万行のコードを 6 日で生成して、誰がレビューしたんだろう。

「読める」物理量の話

仮に 1 秒で 1 行レビューできるとして、100 万行は 約 11.5 日。風呂もトイレも睡眠もなしで、文字通り目で追うだけの速度。実際のレビューでは「読む」「考える」「テストする」「文脈を遡る」が入るので、60 行 / 時間 あたりが現実的という統計もある。それを使うと、100 万行は 約 1.9 年間、フルタイムでレビューし続けてやっと一周 という規模になる。

Bun はこれを 6 日で生成し、5 日で main に入れた。

GitHub も困っている

実際の PR で、Bun リポジトリの Zig 削除 PR が GitHub の自動システムによって "AI slop" フラグを立てられた という小さな事件が起きている。GitHub が「これは AI 生成の低品質コードでは？」と自動的に疑った、ということだ。

つまり AI 自身が、AI 生成コードの大規模な削除を見て怪しんだ という、ややシュールな状況が発生している。

「読めない」を分解する

「誰も読んでない」を分解するとこうなる。

「読む」の意味 100 万行に対して成立する？
各行の文法・意味を目で追う 物理的に不可能
自動テストで挙動を確認 99.8% パス、一定の担保はある
設計意図・抽象を理解する サンプリングなら可能、全部はやれてない
バグの早期発見（traditional code review） 機能していないと思われる

つまり Bun の Rust 移植では、「自動テストが通る」を「レビューが通った」に静かに置き換えている、と読める。これは伝統的なコードレビューの観念とは違う何かだ。

所感：すごいのは AI じゃなくレビュー概念のほう

私が驚いたのは「AI が 96 万行書ける」ことよりも、「人間がコードを読まずにマージできる、と判断したこと」 の方だ。レビューの定義が、コードを読むことから「テストと AI の再生成可能性を信じること」に、静かにスライドしている。

これが Bun だから許される特殊例なのか、これからの標準なのか。私には分からない。 ただ、AI 時代のレビューって何だっけ、という問いは、もう避けて通れないところに来ている気がする。

疑問② 動いてるのに、なぜ書き換える？

Bun は すでに本番で動いている JS ランタイム だ。それを 6 日でゼロから別言語に書き換える、というのは普通の意思決定ではない。なぜ今、これを？

報道と Sumner 発信を読むと、動機は 1 つではなく、少なくとも 3 つが重なっている ことが分かる。

動機 ①：Claude Code が Bun のメモリリークで死んでいた

これが一番直接的な引き金らしい。

何が起きていたか

メモリリークとは、確保したメモリを解放し忘れて、不要なメモリがプロセス内に溜まっていく現象 のこと。長時間動くサーバーやエディタが徐々に重くなる原因のひとつだ。Zig は 手動でメモリ管理する 言語で、allocator.free() を呼び忘れるとリークする。

Bun には 慢性的なメモリリーク問題 があり、Bun の 最大顧客である Claude Code（Anthropic 自社製の AI コーディングツール） のセッションで、メモリ使用量が 14GB、ひどい時は 23GB まで膨らむ 事象が報告されていた。

※「Rust にすればリークは全部消えるのか？」については疑問④で深掘りする。先に結論だけ言うと、消えるのは一部だけ だ。

余談：実は私も同じ問題と戦っていた

正直に書いておく。私の手元でも Claude Code は重かった。Bun プロセスのメモリが膨らみ続け、シェルや MCP サーバーなどの子プロセスもゾンビ化して残る。我慢できなくなって、claude clean という自作シェルコマンド で Claude Code 関連プロセスを毎回全部 kill する運用に落ち着いていた。

つまり、Anthropic が ランタイムごと書き直して解決しようとしていた問題 と、私が claude clean で対症療法していた問題 は、根っこを共有していた ことになる。当事者として書ける記事になってしまった。

構図

Anthropic が 2026 年に Bun を買収したことを思い出すと、構図はこうなる。

  • Anthropic が買収した Bun が、Anthropic の主力 AI コーディングツール Claude Code を不安定にしていた
  • 解決策として、Anthropic の AI（Claude） を使って Bun 自体をメモリ安全な言語（Rust）に書き換えた

dogfooding が極端に効いた、というよりは、自社の問題を自社の AI に自社の手で解かせた、という構図に近い。透明性は高い一方、外部から見ると「Bun の意思決定は今や Anthropic のプロダクト都合と強く結びついている」とも読める。

動機 ②：Rust エコシステムの「contributor pool」

Sumner 本人が繰り返し言及しているのは、Rust = コントリビューター人口が桁違いに大きい という現実的な計算だ。

観点 Zig Rust
言語の安定性 1.0 未発表 1.0 リリース済（2015年〜）
コントリビューター人口 数千人規模 数十万人規模
採用しやすさ（求人で集まる人材） 困難 比較的容易
周辺ツール（lint, fmt, IDE, セキュリティスキャナ） 未成熟 成熟

Sumner は「Rust への移行は raw performance ではなく エコシステム統合のため」と明言している。買収後の Bun は「個人 OSS」から「会社プロダクト」へ性格が変わっており、会社プロダクトとして必要な人を雇える言語に移った、というのが現実的な読み方だ。

動機 ③：Zig コミュニティの「AI コントリビューション禁止」方針

これは見落とされがちだが重要な要素だ。

Zig は公式に 「AI 生成コードによるコントリビューションを受け付けない」 という方針を出している。Bun は Zig のフォーク版を使っていたが、Zig メンテナは「AI 抜きでも Bun の上流マージは歓迎しない」 と表明していた。

つまり Bun は、自分たちの開発スタイル（AI を全面活用）が上流の Zig と相容れない という政治的な袋小路にいた。Rust への移行は、技術判断であると同時に、「AI を堂々と使えるコミュニティ」への移住 でもある。

整理：3 つの動機の重み

並べるとこうなる。

動機 種類 緊急度
① Claude Code のメモリリーク 自社事業の損害 高（即時）
② エコシステム / 採用 中長期の経営判断 中
③ Zig コミュニティとの政治 思想・運営上の摩擦 中

①が「なぜ今やったか」、②③が「なぜ Rust なのか」 を説明している、と読むのが自然だろう。

所感：合理性はあるが、急ぐ必要はあったか

3 つの動機はどれもそれなりに筋が通っている。「無謀に見えてビジネス的には合理的」 という典型例だ。

ただ、①の解決策として「ランタイム全体を別言語に書き換える」は オーバーキル にも見える。リークの根本原因を特定して個別修正する、という選択肢もあったはずだ。それを採らなかったのは、「人力で直し続けるより AI に書き直させる方が速い」 と判断した、ということだろう。

この判断が正しかったかどうかは、これから半年〜1年で答えが出る。 私としては「合理性は分かる、ただし健全性は別物」というところで止めておきたい。

疑問③ パフォーマンス落ちないのか？

ランタイム全体を別言語に書き換えたら、普通は 速度が落ちないか心配する はず。Bun の場合はどうなのか。

Sumner 本人の発言

Sumner は「performance is neutral or faster（性能は同等か速くなる）」と発言している。ただし、2026/05/15 時点で具体的なベンチマーク数値は未公開。公式ブログでの詳細発表が予告されている段階だ。

つまり、「現時点で性能は落ちていないと本人は言っている、ただし第三者の独立検証はまだ存在しない」 というのが正確な状況。

なぜそんなに変わらないと言えるのか？

実は Bun の速さの大半は、Zig/Rust という言語選択ではなく、アーキテクチャ的な決定 から来ている。これが今回の移植で重要な前提になる。

Bun が速い理由 移植で変わる？
JavaScriptCore を採用（V8 ではなく） 変わらない
libuv なしの内蔵 HTTP サーバー 変わらない
統合ネイティブバンドラ 変わらない
データ構造・アルゴリズム 同じ設計を Rust に移植

つまり「JS の実行速度」「HTTP throughput」のような ユーザーが体感するメトリクス は、ランタイムの実装言語を変えても 構造的にほぼ動かないはず、というのが理屈だ。

補足：JavaScriptCore とは何者か

JavaScriptCore（JSC）は C++ で書かれた JS エンジン。Apple 製で、Safari に積まれている。Bun は Zig 時代も Rust 時代も「JSC を呼び出すホスト言語」というポジションで、JS の高速実行は JSC の手柄。つまり Bun の「JS が速い」は Zig や Rust の手柄ではなく、JSC を選んだという建築的決定の手柄だ。

コンパイル時間

Sumner によると、コンパイル時間は次のような関係になっている。

  • Bun の custom Zig compiler を使った場合 → Rust 版は Zig 版と同等
  • 上流の Zig compiler を使った場合 → Rust 版の方が速く コンパイルされる

「ビルドが激遅になる」というネガティブインパクトは、現時点では報告されていない。

独立検証はまだ存在しない

ここまでの主張は すべて Sumner 自身か Anthropic 由来。第三者による「Rust Bun vs Zig Bun」の差分ベンチマークは、2026/05/15 時点では公開されていない。

dev.to などに早期ベンチマーク記事はあるが、それらは 「Bun vs Node」の比較 であり、「Rust Bun vs Zig Bun の差分検証」ではない。両者を混同しないよう注意が必要だ。

所感：性能はもう論点じゃない

性能観点で言えば、「Rust にしたから速くなる」という売り方は弱い。Sumner 自身もそう売っていない（エコシステム判断だと明言している）。「同等のパフォーマンスを、より管理しやすいコードベースで」 が今回の Rust 移植の現実的な spin だ。

これ、フロント勢に翻訳すると 「React vs Vue は性能差ではなく開発体験で選ぶ」 という議論と構造が似ている。性能の最大化は別レイヤー（JSC 等）でやる、ランタイム本体は開発しやすさで選ぶ、というレイヤー分けが綺麗に出ている例とも読める。

性能は 落ちていない が、性能のために Rust にしたわけでもない。論点はもうそこにない、というのが疑問③の暫定回答だ。

疑問④ そんなに一気に変えてバグ大丈夫？

ここが、たぶん 一番ヒリヒリする論点 だ。

Sumner 本人の保険発言

まず重要な事実として、Sumner 自身が「全部破棄の可能性が高い」と発言している。Phase A と呼ばれる現在の段階は 「intent capture」、つまり 「とりあえずコンパイル通らなくてもいいから意図を Rust で表現する」フェーズ と位置付けられている。

つまり、main にマージはされたが「これで確定」ではない、というのが Sumner 本人の認識だ。これは作者なりの保険であり、同時に 「現時点での品質保証は限定的」というシグナル でもある。

unsafe 13,044 という数字の重み

公開された情報によると、Rust 版 Bun には unsafe ブロックが 13,044 個 存在する。比較のために、libuv の Rust 互換実装である UV（同程度の役割のライブラリ）は約 73 個。約 178 倍 だ。

これに対して、Theo Browne（t3.gg）の評価が刺さる。

"They aren't really writing Rust. They are writing C++ with Rust syntax."
（彼らが書いているのは本当の意味で Rust ではない。Rust の文法で C++ を書いているのだ）

これは技術的にも妥当な指摘で、Rust の安全性保証の大半は unsafe の外側でしか効かない。13,044 箇所で「コンパイラ、お前のチェックいらない」と言ってる状態、ということになる。「Zig だった部分の安全性問題が、unsafe Rust という形に移動しただけ」 という読み方も成り立つ。

Rust にしてもメモリリークは消えない（疑問②の伏線回収）

疑問②で「Rust にすれば全部のリークが消えるわけではない」と予告した部分の答え合わせ。

Rust が 構造的に防いでくれる のは、次の 3 つに限られる。

防げる 防げない
use-after-free メモリリーク全般
double-free Rc の循環参照
データ競合 長寿命キャッシュ
バッファオーバーフロー（一部） 「使ってないけど参照を持ち続ける」状態

Rust 公式も 「メモリリークは safe Rust でも起きうる」と明言 している（Box::leak() というわざと漏らす API すら存在する）。Sumner 本人も The Register に「Rust がすべてのリークを捕捉するわけではない」と認めるコメントを残している。

つまり、Bun のリーク問題が 「解放忘れタイプ」 だったなら Rust 移行で大きく改善するが、「長寿命参照タイプ」 だったなら言語を変えても残る。「Zig で起きやすかったタイプのリーク」を Rust が構造的に防ぐ、というのが正しい解像度だ。

Charlie Marsh（Ruff/uv の作者）の問い

これに関連して、Charlie Marsh（Astral CEO、Ruff / uv の作者）が極めて鋭い疑問を投げかけている。

"One fear I have… are you trading 200 known issues for an unknown number of unknown issues?"
（ひとつ怖いのは、200 個の既知の問題を、未知個の未知の問題に交換しているのではないか、ということだ）

これが疑問④の核心だ。

Zig 版 Bun には 既知のバグが大量にあった（だからリーク問題が起きていた）。だが、既知の問題には対策できる。報告されたバグを潰せばいい。

Rust 版 Bun では、それらの既知バグの一部は消えるかもしれない。だが、AI が 6 日で生成した 96 万行には、誰も検出していないバグが何個入っているか分からない。テスト 99.8% パスは「既存のテストが通る」という意味であって、「新規バグがない」という意味ではない。

テストカバレッジが完璧でない限り、99.8% パスは「分からないことが分からない」状態を解消しない。

所感：意図的に「分からない」へ踏み込んでいる

「バグ大丈夫？」への私の暫定回答は、「分からない、というより意図的に分からない状態に踏み込んでいる」 だ。

  • Sumner は「破棄の可能性高い」と保険を掛けている
  • unsafe 13k で Rust の安全性メリットを半分捨てている
  • 既知バグを未知バグに交換している可能性がある

これらは どれも個別には合理的な判断 で、全体としては大きな賭け に見える。速いほうへの賭け、というより、「速くやるしかないところまで来てた」という賭け、というほうが近いかもしれない。

少なくとも、「Rust だから安全になりました」という単純な物語ではない ことは確かだ。

疑問⑤ ちゃんと動くか、どう検証した？

「テスト 99.8% パス」が独り歩きしているが、この数字が何を意味して、何を意味しないか を整理する。

検証されたのは何か

公開されている検証情報を並べるとこうなる。

検証項目 内容
Linux x64 (glibc) 既存テスト 99.8% パス
他プラットフォーム（macOS / Windows / ARM） 「全プラットフォームで通る」と Sumner 発言、ただし 具体的数値の独立公表は限定的
ベンチマーク 「neutral or faster」発言、詳細は公式ブログ待ち
長時間運用 / 本番負荷 Anthropic 社内の Claude Code dogfooding

要するに、公式に "99.8%" と数字が出ているのは Linux x64 glibc のテストパス率だけ。それ以外は 発言ベース か 内部運用 に拠っている。

テストが担保するもの／しないもの

ここが地味に大事。

テストが担保する テストが担保しない
書かれているテストケースが通る挙動 テストが書かれていない挙動
既知の入力に対する既知の出力 競合状態（race condition）
同期的・短時間の正しさ 長時間運用時のメモリ漸減
単一プロセスの正しさ プラットフォーム間の細かな差異
「壊れた」を検出 「微妙に違う」を検出（性能、メモリプロファイル）

99.8% という数字は、「Zig 時代に書かれたテストスイートを Rust 版が通せる」 ということ。これは 「Rust 版は Zig 版とほぼ同じ挙動をする」 の証明にはなるが、「Rust 版に新規バグがない」の証明にはならない。

特に メモリリーク はテストで捕まえにくい。長時間動かして初めて滲み出る タイプの問題だからだ。皮肉なことに、Bun の Rust 化の動機がまさにこれ だった。

Phase A は「intent capture」段階

ここで疑問④の Sumner 発言を別の角度で見直す。

Phase A は 「コンパイル通らなくてもいいから、まず Zig の意図を Rust で表現する」 フェーズと位置付けられている。コンパイルを通すこと、ましてや厳密な検証を済ませることは、Phase A の目的ではない。

つまり今 main にあるコードは、「Phase A の暫定的なスナップショット」 であり、「Phase B でちゃんと検証するからね」という前提つきの仮配置 に近い。

Anthropic の dogfooding が事実上の本番検証

ここで Anthropic 買収が再び効いてくる。

Claude Code は Bun で動いている。Anthropic 社内では Claude Code が 毎日数百万ユーザーの手で動かされている。これは事実上、テストでは絶対に捕まえられないタイプの問題を炙り出す巨大な本番検証 になっている。

ただし、これには 2 つの注意点がある。

  • Claude Code 用途に特化したパスしか潰せない — Bun の他の使い方（バンドラ、HTTP サーバー、CLI 等）の検証は別途必要
  • Anthropic 内のフィードバックループは外から見えにくい — 「内部では動いてる」を信じるしかない部分が残る

Charlie Marsh の "trading 200 known issues for unknown unknowns" が、検証の文脈で再び響く。外部から検証されていないコードは、内部でどれだけ動いていても "unknown unknowns" のまま だ。

所感：99.8% は数字としては立派、意味としては限定的

「ちゃんと検証したのか？」という問いに、「数字としては検証した、意味としては検証はこれから」 と答えるのが正直なところだ。

  • 99.8% は 「Zig 版との挙動互換性」 の指標であって、「品質保証」 ではない
  • 真の検証は マルチプラットフォーム / コミュニティでの長期使用 / 第三者ベンチマーク で行われる
  • Phase A が「intent capture」で「Phase B で書き直す可能性」を含む以上、今の Rust 版で本番採用判断するのは時期尚早

つまり、「Bun を使っている人は、もうしばらく Zig 版 1.3.14 で様子を見るのが合理的」 という解釈もできる。これは技術判断の話で、Bun を批判しているわけではない。新しいコードはまず誰かが踏み抜いてからが本番、というだけのことだ。

残された問い

5 つの疑問を追いかけたが、答えは出ていない。記事を閉じる前に、持ち帰りたい問い を 4 つ並べておく。

  1. AI 生成コードの「レビュー」って、これから何を意味するんだろう？
    人間がコードを読まずに、テストと AI の再生成可能性を信じるレビュー、それが当たり前になるのか。
  2. 「既知のバグを大量に抱える安定版」と「未知のバグを抱える書き直し版」、どちらが信頼できるか？
    Charlie Marsh の "200 known issues vs unknown unknowns" は、AI 大規模生成時代の中心的な問いだと思う。
  3. これは Bun の特例なのか、新しい標準なのか？
    Anthropic という巨大スポンサー、Claude という強力な AI、Bun という比較的若いコードベース。3 つの条件が重なって初めて可能になった話 とも見える。
  4. オープンソースが「単一企業の都合」で大改造される時、コミュニティはどう関わるのか？
    Bun は OSS だが、今回の意思決定はほぼ Anthropic 単独で行われた。OSS の意思決定モデルが揺らいでいる ように見える。

私の暫定的な気持ちは、「すごい」と「怖い」が半々 だ。AI で 96 万行を 6 日で書けてしまう時代の入り口に立っている、ということは認めざるを得ない。一方で、それを本番ブランチに入れる判断は、誰でも真似していい話ではない とも思う。

私はもう少しだけ、自分でコードを見つめる生活を続けたいと思う。

参考リンク

Discussion

standard softwarestandard software

もうプッチ神父のスタンドによって世の中が目まぐるしく変わろうとしている、、、

という気分になってきました。

1