Bun が Zig から Rust に書き直された本当の理由 — Anthropic 買収・Zig の AI 禁止・Claude による 6 日 96 万行ポート

2026 年 5 月 14 日、Bun のメインリポジトリに 1 件の PR がマージされた。番号は #30412、タイトルは「Rewrite Bun in Rust」。変更ファイル 2,188、追加 100 万行超、削除 4,024 行という規模で、ブランチ名は claude/phase-a-port¹。Bun 創設者 Jarred Sumner は PR 説明文で「memory safety のためのコンパイラ支援が手に入った」と動機を述べた¹。

しかしこの PR を「Rust の方が安全だから書き直しました」で終わらせると、本質を見誤る。Anthropic による Bun 買収 (2025 年 12 月)、Zig の LLM 寄稿禁止ポリシー、Claude が大規模言語間ポートの実用域に到達したこと、この 3 つの構造的圧力が同時に交差した結果として PR #30412 は存在する。本記事は公式説明の裏側にあるその力学を読み解く。

PR #30412 が示す「事実」

裏側に進む前に、公式情報を確定させる。憶測との境界を引くためだ。

規模

• マージ日: 2026-05-14
• 変更ファイル: 2,188
• 追加: 1,009,257 行 / 削除: 4,024 行
• コミット数: 6,755 (報道ベース)²
• ブランチ名: claude/phase-a-port¹

ブランチ名に claude が含まれている事実は記憶しておきたい。後で意味を持つ。

性能

• Linux x64 glibc で既存テストの 99.8% パス¹
• バイナリサイズ -3〜8MB¹
• ベンチマーク: 中立から高速¹

「全プラットフォームで既存テスト通過、メモリリークと flaky テストもいくつか修正」が PR 説明文の中核だ¹。性能は劇的改善ではなく「中立から高速」と慎重な言い回しになっている。

公式メッセージ

PR 説明文には 3 つの強調点がある¹。

1. アーキテクチャとデータ構造は largely the same (大きく変えていない)
2. 3rd party ライブラリは依然として少ない
3. async Rust は使わない

つまり「Zig 版のホモロジーを保った Rust 版」であり、idiomatic Rust への作り直しではない。Sumner の動機表現は「コンパイラ支援によるメモリバグ検出ツールが手に入った。これが何年もチームの開発・デバッグ時間を奪ってきた」¹。

ここまでが公式情報。なぜこれが起きたのかは、別の階層にある。

第一の圧力 — Anthropic による Bun 買収

2025 年 12 月 2 日、Anthropic は Bun および開発チームを買収した³。この事実が PR #30412 の出発点になる。

自社 AI を自社プロダクトへ

Anthropic は Claude Code を含む Claude シリーズを開発する企業であり、Bun を傘下に持つことで「自社 AI を自社プロダクト開発に投入する」整合性が一気に強化された。Sumner は The Register に対して次のように述べている。

this is already the status quo; we haven’t been typing code ourselves for many months now²

「これはすでに現状で、ウチらはもう何ヶ月もコードを自分でタイプしていない」という発言は、買収後すぐに開発体制が AI 主導へ移行していたことを示唆する。Rust ポートの「6 日」は突然の試みではなく、すでに稼働している AI 主導開発の延長線上にあった。

言語選定基準のシフト

買収によって何が変わったか。言語選定の基準が「人間が書きやすい」から「AI が安全に書ける」へ重みづけが移った点だ。Zig はチームが愛着を持って選んだ言語だが、AI が大量に生成するコードに対するコンパイラの守りは Rust の方が強い。借用検査と所有権による所有移転、ライフタイムによる use-after-free 検出、Drop による deterministic 解放が compile time に効く。AI 生成コードに対するガードレールとして Rust の型システムは Zig より明確に厚い。

組織の構造が変わると、最適な言語も変わる。これが第一の圧力である。

第二の圧力 — Zig の LLM 寄稿禁止

Zig コミュニティは LLM 生成コードの寄稿を upstream で受け入れない方針を表明している。The Register の取材に対し Zig 側は「AI の側面を抜きにしても歓迎しない」と回答した²。

Bun の Zig fork 問題

Bun は debug compile time を 4 倍改善するパッチなどを Zig に対して持っており、これらは upstream できないため独自 fork を維持する状況にあった (報道ベース)⁴。AI 主導開発を本格化させた Anthropic 配下の Bun にとって、この fork コストは加速度的に膨らむ予測になる。

問題はパッチの量ではなく governance の構造的衝突だ。人間が type しない開発体制と、AI 寄稿を受け入れない言語コミュニティ。両者は構造的に両立しない。Bun が Zig fork を続けるほど upstream との乖離は深まり、コミュニティの恩恵 (security fix / コンパイラ改善 / 周辺ツール) を受ける口は狭くなる。

v1.3.14 が「最後の Zig 版」

Sumner は「これが Zig 最後のバージョンになる」と述べ、v1.3.14 リリースを Zig コードベースの最終版と位置づけた²。技術スペックではなく governance 互換性によって言語選定が決まった事例として、PR #30412 はテックヒストリの教材になる。

第三の圧力 — Claude が大規模ポートの実用域に

ブランチ名 claude/phase-a-port の存在が、第三の圧力の核心だ。Phase A という命名は、Claude が担当した工程が複数フェーズの最初のものであることを示唆する。Sumner も PR 説明文で「クリーンアップ作業は一連の follow-up PR で行う」と明言している¹。

「6 日」の表向きと実態

Stork.AI の報道によれば、Rust リライトは 6 日間で既存テストの 99.8% パスを達成した³。一方 Hacker News では sesm が次のように指摘している。

rewrite took 1 week, I wonder how much time went into preparing this file with very detailed instructions on mapping Zig to Rust idioms⁵

「リライト自体は 1 週間だが、Zig→Rust のイディオム変換を指示する詳細ファイルを準備するのにどれだけ時間がかかったか想像がつかない」。Sumner 自身も HN で「ドキュメント執筆と rewrite どちらが時間かかった?」と聞かれて「almost (ほぼ同等)」と答えている⁵。

つまり「6 日」はコード生成フェーズの実時間であり、変換ガイド作成・反復実験・compile error の修正ループ・テスト検証を含めれば数ヶ月オーダーの工数が前段にある。AI が一晩で 1M 行を吐いた、という物語ではない。

ホモロジー戦略

logicprog は HN で次のように要約している。

the port maintains structural homology to enable future safe refactoring rather than attempting immediate idiomatic Rust⁵

idiomatic Rust にいきなり翻訳するのではなく、Zig の構造をそのまま Rust に写像する。バグもそのまま持ち込む代わりに、Rust の compile error と test failure を一度だけ集中砲火で潰す。idiomatic 化は post-port の課題として後回しにする。これが大規模 AI ポートを 6 日に押し込めた設計判断の核心だ。

つまり実用条件は次の 3 点に集約される。

1. 包括的テストスイート (回帰検出の信頼性)
2. ホモロジー戦略 (idiomatic より忠実翻訳を優先)
3. 事前準備の工数 (変換ガイド・反復・修正ループ)

影 — 10,428 unsafe blocks が示す限界

公式動機は memory safety だ。しかし PR #30412 マージ後の Rust コードベースには大量の unsafe ブロックが存在する。Hacker News コメンターの gm678 は実測値として 10,428 unsafe blocks across 736 files を報告している⁵。

byteiota は別のメトリクスとして「13,000+ unsafe blocks across 681,000 lines」を報じ、同じく Rust 製の uv (350,000 行 / 73 unsafe blocks) と比較している⁶。実測 10,428 と報道 13,000+ には幅があるが、行あたり unsafe 密度が uv の 100 倍以上であることは確実だ。

unsafe の発生源

byteiota は主な発生箇所として 2 つを挙げる⁶。

1. JavaScriptCore (JSC) との FFI 境界呼び出し
2. Zig 設計から温存された global mutable state (Rust の所有権モデルにきれいに乗らない)

JSC との FFI は Bun のアーキテクチャの根幹であり、ここを safe にするには Bun のコア設計を再検討する必要がある。global mutable state も同様で、ホモロジー戦略を選んだ時点で温存される宿命にあった。

「memory safety はゴールでなく出発点」

PR 説明文の動機表現を額面通り受けると「memory safety を達成した」と読みたくなるが、unsafe 密度の現実を見れば memory safety は到達点ではなく出発点だ。Rust の compile time チェックが効く部分はクリーンになったが、unsafe ブロックの 1 万件超は人間の audit 対象として残る。Sumner が PR 説明文で「optimization 残」「cleanup 残」と明言したのも、この後続コストを示している¹。

採用判断と AI コーディングへの含意

PR #30412 を「Rust になって速く・安全になった」で評価して採用判断を変えるのは早計だ。

canary を本番に入れる前に

Sumner は試用方法として bun upgrade --canary を案内し、optimization と cleanup が残っていることを明言した¹。本番投入前に確認すべきは次の 3 点に絞られる。

1. 自分のワークロードでベンチマーク結果が「中立から高速」のどちら寄りか実測
2. JSC FFI 境界 (Worker / native addon / FFI) を多用する場合は memory leak の長時間負荷試験
3. follow-up PR がリリースされる前提で、stable まで何回バージョンを跨ぐか確認

「Rust になったから即採用」ではない。「Zig 版より stable まで時間がかかる可能性がある」と読むのが妥当だ。

AI コーディング検討者への 3 教訓

PR #30412 は AI 主導大規模ポートの test case として読める。導入を検討するチームへの教訓は以下に集約される。

• 包括的テストが前提: テストスイートが弱いと AI ポートは vibe porting (統計的には動くが理解の浅い翻訳) に陥る⁵
• ホモロジー戦略: 一度に idiomatic 化を狙わず、構造を保って翻訳し refactor を分離する
• 後続コストの計上: ドキュメント執筆と rewrite が同等工数 (Sumner 証言)、unsafe 削減と最適化はマージ後の長期作業

タイムラインで見ると、買収 (2025-12)・Zig 政策 (2026 年春)・PR open (2026-05-08)・merge (2026-05-14) は 6 ヶ月の窓に圧縮されている。3 つの圧力が同時に揃った結果としての必然性が時系列でも見える。

まとめ

Bun の Rust リライトは単一の技術選定ではない。Anthropic 買収による組織変化、Zig コミュニティの governance 摩擦、Claude が実用域に達した技術タイミング。この 3 つが 6 ヶ月の窓に同時集約した結果として PR #30412 は存在する。同じ条件 (自社 AI 保有 + governance 摩擦 + LLM 実用域) が揃えば、類似の動きは他プロジェクトでも起こりうる。

「Rust に書き直されたから安全になった」という表層の物語ではなく、3 圧力の交差として PR #30412 を読むこと。これが採用判断と AI コーディング検討の双方に効く読解の更新だと考える。

参考文献