Anthropicによる買収後、BunがRustへ書き換え：月間2,200万ダウンロードが高めるリスク

BunはAnthropicによる買収後、Rustへの書き換えを完了し、月間2,200万件を超えるCLIダウンロードを支える基盤に、AIが生成したコードベースを据えた。

今回の変更は、単なるプログラミング言語の移行をはるかに超えるものだ。Bunによると、Claudeは50万行を超えるZigコードを、およそ100万行のRustコードへ変換する作業を支援した。集中的な移植作業に要した期間は11日間だった。

この速さは大きな注目点だが、本質的なテーマは信頼性にある。現在、BunはClaude Code、OpenCode、Prisma Computeのほか、インフラが予測どおりに動作することを期待する開発者を支えている。今回の書き換えは、コンパイラによる検査、自動レビュー、膨大なテストスイートによって、AI生成のシステムコードを信頼できるものにできるのかを問う試みでもある。

同時に、そこには皮肉な逆転もある。Zigは、1人の開発者がわずか1年でBunの幅広い機能群を構築することを可能にした。しかし、その機能の広がりは後にメモリリーク、解放済みメモリへのアクセス、不具合対応や保守の負担を生み、BunはRustによってそれらを軽減したいと考えている。

Anthropicによる買収後のBunのRust書き換えがリスク構造を変える

Bunが言語を変更したのは、流行の看板を掲げるためではない。繰り返し発生するメモリ障害が、運用上の重荷になっていたためだ。

Bunは、JavaScriptランタイム、パッケージマネージャー、バンドラー、トランスパイラー、テストランナー、さらに多数のNode.js API実装を1つに統合している。その広い守備範囲により、通常なら複数のパッケージが必要な作業を、開発者は1つのツールで処理できる。

一方で、JavaScriptとネイティブコードの間には多くの境界が生まれる。JavaScriptではガベージコレクションが使われ、到達不能になったオブジェクトは自動的に回収される。Bunのネイティブコンポーネントは、それらのオブジェクトと、より低レベルなコードが管理するメモリとの整合性を保たなければならない。

この連携が、継続的なミスの温床となっていた。Bunの開発者であるJarred Sumnerは、解放済みメモリへのアクセスによるクラッシュ、二重解放、範囲外アクセス、競合状態、未解放メモリに関する最近の不具合を列挙している。

解放済みメモリへのアクセスは、ソフトウェアがメモリを解放した後にその領域へアクセスすると発生する。結果はクラッシュから予測不能な挙動、さらにはセキュリティ脆弱性にまで及ぶ可能性がある。

Bun v1.3.14では、圧縮ストリーム、HTTP/2接続、UDPソケット、バッファ、暗号処理、TLSセッション、ファイル監視、CSSパーサーにまたがる問題が修正された。これらは、1つの孤立したミスが形を変えて現れたものではない。

複数の障害は、JavaScriptのコールバックが予期しないタイミングでネイティブ側の状態を変更した際に発生していた。ほかにも、クリーンアップ処理が実行されなかったり、二度実行されたり、メモリ割り当ての失敗後に実行されたりすることが原因となっていた。

Bunはすでに複数の防御策を採用していた。チームは、不正なメモリアクセスを検出する実行時ツールAddressSanitizerに対応させるため、Zigコンパイラにパッチを適用していた。プロジェクトではコミットのたびにこの検査を実行していた。

チームはFuzzilliも継続的に使用していた。Fuzzilliは通常のテストでは見落とされる可能性があるエンジンやランタイムの障害を露呈させるため、通常とは異なるJavaScriptプログラムを生成する。

これらの仕組みは、コードが書かれた後に不具合を発見するものだった。Sumnerが求めたのは、所有権に関するより多くのミスをコンパイル時に拒否できるプログラミングモデルだった。

Rustの所有権システムは、プログラムのどの部分が値を管理しているかを追跡する。借用チェッカーは参照に関する規則を強制し、Dropは値がスコープを外れた際にクリーンアップを自動実行する。

安全なRustでは、解放済みメモリへのアクセスや二重解放につながる多くのパターンがコンパイラエラーになる。これにより、ファジング、継続的インテグレーション、本番環境のクラッシュレポートよりも早い段階でフィードバックを得られる。

そのため、BunのRustへの書き換えは、チームが不具合の検出を期待する段階そのものを変える。一部のミスは、バイナリが実行される前の開発段階で阻止されるはずだ。

この移行は、Anthropicが2025年12月3日にBunを買収したことを受けて進められた。Anthropicは、BunがClaude Codeにとって重要なインフラとなっており、Claude Codeは同年11月に大きな収益上の節目に到達したと説明している。

公式のBun買収発表では、このランタイムとAnthropicのコーディング戦略が直接結び付けられている。この関係によって、不安定さがもたらす代償はさらに大きくなる。

Bunによると、そのコマンドラインインターフェースは月間2,200万件を超えるダウンロードを記録している。また、Vercel、Railway、DigitalOceanも、このランタイムを公式にサポートしている。

ダウンロード数は、アクティブな開発者数、本番環境へのデプロイ数、ユニークなマシン数と同じではない。自動ビルドによって、同じパッケージが繰り返しダウンロードされることもある。それでも、この数字はBunが支えなければならない配布範囲の大きさを示している。

最初のRust版は、ニッチな実験の裏側に置かれた単なる新実装ではない。リポジトリ、ビルドシステム、デプロイパイプラインの内部で動作するツール群を支える存在だ。

このため、Anthropicによる買収後のBunのRust書き換えは、2つの約束を検証する試みとなる。Rustは一般的なメモリ関連のミスを防ぎ、Claudeは本来なら現実的ではない移行を経済的に実現可能にするはずだ。

今回の書き換えは、その両方の約束が本番環境での使用に耐えられるかどうかで評価されることになる。

月間2,200万ダウンロードにより、安定性そのものが製品になる

現在のBunの規模では、信頼性はもはや二次的なエンジニアリング目標ではない。開発者がインストールする製品そのものの一部だ。

Bunは、esbuildのJavaScriptおよびTypeScriptトランスパイラーを、SumnerがGoからZigへ1行ずつ移植するプロジェクトとして始まった。彼が初めてZigのコードを書いたのは2021年4月だった。

オリジナル版の構築には約1年を要した。Sumnerは、現代的なコーディングモデルが存在しなかった当時にこの速度を実現できた理由として、Zigのシンプルさと低レベルな制御性を挙げている。

この出自は重要だ。今回の書き換えは、RustとZigのどちらが単純に優れているかを決めるものではない。ZigはBunが異例に幅広い機能群を備えて市場へ到達することを可能にした。

その後Bunが担う責務は増え、ライフタイムの手動管理にかかるコストも高まっていった。そのランタイムには、Safariで使われているエンジンJavaScriptCoreに加え、複数のCおよびC++ライブラリが組み込まれている。

それらの依存関係には、ネットワーク、暗号化、データベース、圧縮の各コンポーネントが含まれる。以前のBunコードベースの約5分の1は、すでにC++で書かれていた。

Rustを採用しても、そうした外部ライブラリが自動的に安全になるわけではない。外部関数インターフェース、すなわちFFI境界は、Rustと、コンパイラがメモリ規則を完全には検証できないコードとを接続する。

ただしRustでは、そうしたやり取りを明示的に指定したunsafeセクションへ集約できる。これにより開発者は、コンパイラによる通常の保証が適用されなくなる箇所を特定できる。

また、Rustは日常的なクリーンアップ処理の一貫性も高める。Zigでは一般的に、リソースを解放する必要がある個々の呼び出し箇所にdeferを付ける。

この明示的なモデルはエンジニアに細かな制御を与える一方、規律ある反復を必要とする。まれにしか通らないエラーパスでは、クリーンアップが抜け落ちたり、誤って二度実行されたりする可能性がある。

RustのDrop機構は、クリーンアップをオブジェクトのライフタイムに結び付ける。Bunによると、この変更はすでにファイルパスとビルドデータに関するリークの修正に役立ったという。

ある社内テストでは、60個のモジュールを含むプロジェクトを同一プロセス内で繰り返しバンドルした。Bunの報告では、v1.3.14はビルドのたびに約3メガバイトのメモリをリークした。

2,000回のビルド後、BunのテストではZig版が6,745メガバイトを消費した。一方、同社によるとRust実装は609メガバイトで横ばいになった。

この比較は、さまざまなワークロードで独立に再現されたものではない。それでも、Bunが排除しようとしている障害の性質を示している。

開発サーバーは、リクエストやファイル更新のたびにコードを再ビルドすることがある。小規模なリークでも、プロセスが数日間動き続ければ深刻な問題になる。

同じ懸念はコーディングエージェントにも当てはまる。Claude Codeは、ファイルの調査、コマンドの実行、リポジトリの変更を行う間に、補助プロセスを繰り返し起動する可能性がある。

ランタイム障害が起きれば、エージェントの処理が中断されたり、中間結果が破損したり、開発者がアプリケーションではなくインフラのデバッグに追われたりする恐れがある。

Bun 1.4が一般公開される前に、Claude CodeはRust移植版へ移行した。Bunによると、6月17日にリリースされたClaude Codeバージョン2.1.181では、新しい実装が使用された。

Bunの本番環境テレメトリーによると、Linuxでの起動時間の中央値は517ミリ秒から464ミリ秒へ短縮された。約10％の改善に相当する。

速度は中心的な目標ではなかった。より重要なのは、大半のユーザーが言語の変更に気付かなかったという点だ。

目に見えないインフラ移行は、多くの場合、成功した移行である。内部で保守性と信頼性が向上しても、アプリケーションの挙動は変わらないことが望ましい。

Prismaは、もう1つの初期本番テストを提供した。同社のサーバーレスデータベースプラットフォームは、Prisma ComputeのパブリックベータでRust書き換え版を使用した。

Prismaによると、以前の実装ではメモリリークが発生し、仮想マシンの一時停止と再開後にコネクションプールを復旧できなかった。同社のエンジニアは、移植版を対象にこれらの状況を再検証した。

Prismaの本番環境での評価によると、新実装はこれらの特定の障害モードに対処できたという。一方でPrismaは、unsafeコードには引き続き監査と人間によるレビューが必要だとも注意を促している。

この組み合わせは、ダウンロード数だけを見るよりも、今回の取り組みの重大性をよく表している。移植によって測定可能な改善は得られたが、本番環境での信頼を確立するには、実証試験に合格するだけでは不十分だ。

Node.jsとDenoもBunの進展による圧力を受けているが、どちらもこの物語の中心的な競争相手ではない。Node.jsは依然として、サーバーサイドJavaScriptにおける互換性の基準である。

Denoはすでに、V8 JavaScriptエンジンの周辺にRustを採用している。そのアーキテクチャは、Rustとネイティブ依存関係を介してJavaScriptランタイムを管理するうえで、参考となる比較対象を提供している。

Bunは、性能に関する主張と幅広いツールキットを維持しながら、Node.jsとの互換性を保たなければならない。クラッシュを減らす一方で挙動の違いを持ち込む書き換えでは、ある信頼性問題を別の問題に置き換えるだけになる。

そのためチームは、直ちに設計を刷新するのではなく、機械的な移植を選んだ。新しいRustコードは、意図的に従来のZigアーキテクチャに似せている。

この判断は、移行中の挙動変化を抑えた。一方で、異なる安全規則を持つ言語へ、従来の前提や低レベルなパターンも持ち込むことになった。

その結果、このプロジェクトをめぐる中心的な緊張関係が生まれている。Bunはより強力な保証を求めてRustを選んだが、互換性を保つための最も安全な移行方法では、当初、相当量のunsafeコードを残すことになった。

Claudeが1年規模の書き換えを11日間の検証ループに短縮

注目すべき仕組みは、単なるコード生成ではなかった。実装、批判、修正、テストを分離した、統制されたループだった。

Bunは、従来型の書き換えであれば、経験豊富なエンジニア3人が約1年間従事する必要があると見積もっていた。その間、機能開発と互換性改善は停滞するか、止まることになる。

既存のZigコードベースは、コメントを除いて535,496行あった。手作業による移植では、本番版との差分が継続的に広がる長期ブランチも生まれる。

そこでSumnerは、Claude Fable 5と呼ばれるAnthropicのプレリリースモデルを試した。彼は約3時間をかけ、Zigのパターン、型、ライフタイムをRustへ変換するための規則を策定した。

Claudeはそれらの決定事項を移植ガイドに記録した。さらに、コードベース全体の各フィールドについて想定されるライフタイムを整理した文書も生成された。

チームは、最初からすべてを変換するのではなく、3つのファイルから着手した。各移植は1つのClaudeインスタンスが実装し、別の2つのインスタンスがレビューし、さらに別のインスタンスが修正を適用した。

この役割分担は意図的なものだった。変更を生成したモデルは、自らの推論を肯定する方向へ偏り続ける可能性がある。

レビューを担当するインスタンスには、実装側の完全なコンテキストを与えず、差分だけを渡した。その役割は、誤った挙動やリグレッションを探すことだった。

Sumnerはこれを敵対的レビューと呼んだ。独立したコードレビューに似ているが、参加者はすべて同じモデルファミリーのインスタンスだった。

この作業全体では、約50の動的なClaude Codeワークフローが使われた。ピーク時には4つのワークフローグループが同時に稼働し、それぞれが16のClaudeインスタンスを連携させていた。

つまり、約64のエージェントが同時に作業していたことになる。移植作業では、生成速度がピーク時に毎分約1,300行に達したと報告されている。

プロセスは当初から順調だったわけではない。同じリポジトリで作業するエージェントが、stash操作やハードリセットを含む、互いに競合するGitコマンドを使用した。

Sumnerは指示を変更し、広範なGit操作を禁止した。最終的にシステムは4つの独立したworktreeを使い、各エージェントが特定のファイルをコミットし、ブランチを通じて成果を共有する方式を採用した。

この失敗は、モデルの能力だけで書き換えが実現したわけではないことを示す重要な事例だ。ワークフローには、共有状態や破壊的操作に関する明確な制約が必要だった。

同様の移行を検討するチームにも、同程度に明確な運用ルールが求められる。正しいコードを書けるエージェントでも、リポジトリ、認証情報、ビルドシステム、デプロイツールの扱いを誤れば、作業成果を損なう可能性がある。

この移行では、マージを除いて6,502件のコミットが生成された。一方、Bunによると、11日間の総コミット数は6,778件だった。最終的に取り込まれた差分では、100万行強が追加された。

これらの数字が示すのは活動量であり、品質ではない。小さなコミットは追跡可能性を高める一方、数千件に及ぶ自動コミットは、従来型の人間によるレビュー能力を圧倒しかねない。

Bunは主にコンパイラ、自動レビュアー、既存のテストスイートに依存した。このスイートには、対応プラットフォーム全体で約100万件のアサーションが含まれていた。

マージ前、チームは継続的インテグレーションですべてのテストが完了したと報告した。テストの削除やスキップは一切なかったとしている。

Debianでは、Bunは60,624件のテストで1,386,826回のexpect()呼び出しを記録した。macOSとWindowsでも、それぞれ100万件を超えるアサーションが実行された。

テストスイートがTypeScriptで書かれていたことは、Bunにとって大きな利点だった。テストは、基盤となるランタイムがZigとRustのどちらで実装されているかに依存せず、外部から観測可能な振る舞いを評価できた。

このアーキテクチャにより、機械的な移植を測定可能なものにできた。翻訳された各コンポーネントは、同じ外部テストがすでに期待していた結果を維持する必要があった。

Claudeはコンパイラエラーも作業キューとして処理した。BunはRustコードを約100個のcrateに分割した。crateとは、Rustプロジェクト内で個別にコンパイルされるパッケージである。

ある段階では、cargo checkによって約16,000件のエラーが発生した。ワークフローはこれらの失敗をcrateごとに分類し、エージェントに割り当て、修正をレビューして、このプロセスを繰り返した。

このコンパイルループにより、途方もなく見える移行作業が、範囲の明確なタスクへと変換された。各エラーは、エージェントが対処できる局所的なフィードバックを提供した。

このアプローチが特に有効だったのは、Rustのコンパイラが所有権や型に関する多くの失敗を正確に説明するためだ。コンパイラはゲートであると同時に、構造化された指示の供給源にもなった。

マージまでに、このプロセスはキャッシュされていない入力トークンを59億、出力トークンを6億9,000万消費した。さらに、キャッシュ済みの入力トークンを720億読み込んだ。

Bunは、API料金に基づく総額を約165,000ドルと見積もった。この金額には、元のコードベース、テスト、人間の専門知識、移行後の保守など、組織が負担するすべてのコストが含まれているわけではない。

したがって、3人のエンジニアが1年間作業する場合との比較は、あくまで大まかな目安であり、完全なものではない。ClaudeがBunのアーキテクチャ、互換性対応、テスト資産をゼロから生み出したわけではない。

Claudeは、長年にわたって蓄積されたエンジニアリング上の文脈を活用した。移行の速さは、その文脈がエージェントによる読み取りと検証が可能な形式で用意されていたことに依存していた。

この違いは、ほかのチームにとって重要だ。成熟したテストスイートと明確に定義された振る舞いがあれば、自動移行は現実的な選択肢になり得る。

テストが不十分なシステムには、それに相当する判定基準がない。エージェントはコンパイル可能なコードを生成しても、ユーザーが依存する振る舞いを気づかないまま変更してしまう可能性がある。

エンジニアリングチームには、エージェントの判断を説明する永続的な記録も必要だ。検索可能なナレッジベースがあれば、移行ルール、レビューで得られた知見、オーナーシップに関する前提を、個々のコンテキストウィンドウを超えて保存できる。

Bunプロジェクトでは、移植ドキュメント、ライフタイムマップ、コミット履歴、テストによってこれを実現した。これらの成果物は、単なる管理上の付加物ではなかった。

高速なコード生成をそもそもレビュー可能にしたのは、これらを組み合わせたシステムだった。

Bunが依然としてunsafeコードを使用する以上、Rustだけでは安全性を保証できない

今回の書き換えによって複数のリスクは軽減されるが、それだけでBunが自動的にメモリ安全になったとみなすことはできない。

Bunの機械的な変換では、低レベルのポインタ操作や、CおよびC++ライブラリとの広範な連携が維持された。こうした領域では、Rustのunsafeキーワードが必要になることが多い。

unsafeブロックでは、borrow checkerが検証できない操作が許可される。必要な規則を守る責任は、プログラマーが手動で負わなければならない。

これは、すべてのunsafeブロックに欠陥があるという意味ではない。主要なRustシステムでも、効率的な抽象化の実装や、オペレーティングシステムおよびネイティブライブラリとの接続にunsafeコードが使われている。

ただし、Rustが提供する最も重要な保証は、こうした境界がどのように設計、文書化、監査されるかに左右される。

Sumnerによると、当初はBunのRustコードの約4％がunsafeブロック内にあった。約78万行のRustコードのうち、およそ27,000行がunsafeだったという。

また、それらのブロックの78％は1行だけだったとも述べている。その多くは、C++ポインタやネイティブライブラリへの単一の呼び出しを扱っていた。

この説明には意味があるものの、ブロックの短さは正しさの証明にはならない。unsafeなポインタ変換が1つあるだけでも、ほかのsafeコードに影響を及ぼすライフタイムエラーが生じる可能性がある。

5月14日には、公開されたメモリ安全性の問題によって、この懸念が実証された。報告では、safe関数がスライスのライフタイムを消去し、ダングリング参照を許してしまうことが示された。

Rustプログラムの未定義動作を検出するために使われるインタープリタのMiriが、この例を検出した。未定義動作とは、言語仕様上、結果に信頼できる制約が一切ない状態を意味する。

Bunの自動化されたコントリビューターは問題を再現し、同様のライフタイム上の欠陥も特定した。提案された修正では、影響を受ける関数をunsafeとして指定し、そのライフタイム要件を文書化した。

この対応は、プロジェクトが具体的な報告を迅速に処理できることを示した。同時に、コンパイルと既存のテストスイートだけでは、無効な抽象化をすべて防げなかったことも示している。

この隔たりは、書き換えに対する最も強い懐疑論を裏付ける。自動テストがZigのメモリエラーを見逃したのであれば、同じテストによって大規模なRust移植の健全性を証明することもできない。

Rustはコンパイラによる強制力を加えるが、unsafe領域では責任が再びエンジニアに戻る。機械的な変換によって、元のポインタ管理規律がそのままunsafe領域内に引き継がれる可能性もある。

Zigの作者Andrew Kelleyは、最も厳しい公的批判を提示した。Kelleyは書き換えに対する見解の中で、Bunの問題はZigの失敗ではなく、エンジニアリング手法と蓄積された技術的負債を反映したものだと主張した。

Kelleyはさらに、モデルが生成した膨大なコードに対して、十分な人間の精査が行われたのか疑問を呈した。批判の一部は個人攻撃的な内容となり、技術的な論点から注意をそらす結果になった。

それでも、その技術的な問いは有効だ。インフラストラクチャをAI生成の書き換えに委ねる前に、どの程度の独立したレビューが必要なのか。

Bunによると、すべての行は別々の2つのClaudeインスタンスからレビューを受けた。しかし、モデルによるレビューは、独立した人間の判断と同等ではない。

同じモデルのインスタンスは、盲点、学習パターン、誤った前提を共有している可能性がある。コンテキストウィンドウを分ければアンカリングは減らせるが、真に独立した専門知識が生まれるわけではない。

自動レビュアーは、マージ前にもっともらしい複数のバグを発見した。その1つは、リソースを二重に解放してしまう非同期のclose操作に関するものだった。

別のバグでは負のタイムスタンプを誤って処理していた。さらに別のバグでは、特定のCSSカラー式を解析する際にpanicを引き起こす、即時評価型のRustメソッドが使われていた。

これらの例は、敵対的レビューが実質的な価値をもたらしたことを示している。しかし、すべてのレビューエージェントが揃って見逃した欠陥がどれほどあるかは明らかにしていない。

議論を、AI生成コードを受け入れるか拒絶するかという二者択一にしてはならない。より有益なのは、保証のあり方を問うことだ。

チームはすでに、コンパイラ、静的解析ツール、fuzzer、形式モデル、自動テストシステムを信頼している。コーディングエージェントも、最終的な権威になることなく、その仕組みに加わることができる。

Prismaの姿勢は、現実的な中間地点を示している。同社は公開ベータ版にこの移植を導入し、既知の障害シナリオで改善が見られたと報告した。

同時にPrismaは、unsafeコードには監査が必要であり、変換されたコードにはレビューが必要だと述べている。また、Rustらしくないセクションを、人間が理解できる単位へリファクタリングすることを推奨した。

Bunも同様の方針を掲げている。最初の目標は振る舞いの維持であり、その後、unsafeの使用を減らし、よりRustらしいコードへ段階的に移行するという。

この順序には合理性があるものの、安全性向上の効果の一部は先送りされる。unsafe領域が縮小するまでは、この移行は継続中のエンジニアリングプログラムであり続ける。

この議論はメモリ安全性だけにとどまらない。ランタイムは、誤ったモジュール解決、非互換なAPI、ネットワーク動作、性能低下、オペレーティングシステム間の微妙な差異によっても障害を起こし得る。

Rustは論理エラーを防げない。100万件のアサーションを備えたテストスイートでも、流通しているすべてのJavaScriptパッケージについて正しい振る舞いを証明できるわけではない。

したがってBunには、外部ワークロード、独立監査、fuzzing、長期間の本番運用が必要だ。それぞれが、内部検証だけでは得られない証拠を提供する。

Anthropicによる買収後に行われたBunのRust書き換えは、現在も検証が続く有望な移行として捉えるべきだ。完全な安全性の成功、あるいは自動化の失敗と断定するのは、現時点で得られている証拠を超えた評価になる。

Bunの書き換えが成功したかどうかを決める3つのシグナル

次の段階は11日間の移植ほど劇的ではないが、この書き換えが模範となるか、警告となるかを決定する。

第1のシグナルは、一般的な本番環境におけるBun 1.4の挙動だ。Bun v1.3.14が最後のZig版であり、v1.4ではRust実装が導入された。

チームは、より広範に導入された後のクラッシュ報告、メモリ消費量、互換性のリグレッション、ロールバックを注視すべきだ。リリースが成功したと言えるには、新たな種類の動作上のバグを生むことなく、メモリ障害を減らす必要がある。

Claude CodeとPrismaによる初期導入は、Bunの主張を補強している。しかし、パッケージの組み合わせ、オペレーティングシステム、ネイティブモジュール、ワークロードパターンの全容を網羅しているわけではない。

広範な利用が進めば、Bunの内部テストスイートでは到達しなかったコードパスが明らかになる。複数のリリースサイクルにわたって安定した結果が続けば、ローンチ時のベンチマークよりも強い証拠となる。

第2のシグナルは、BunにおけるunsafeなRust領域の規模と設計だ。FFIを多用するランタイムではunsafeコードを完全に排除できないため、単純な件数だけでは文脈が不足する。

より重要なのは、unsafe操作が小さく、文書化されたインターフェースの背後に集約されているかどうかだ。各インターフェースでは、呼び出し側が守るべきライフタイム、エイリアシング、所有権、スレッド安全性に関する前提を明示する必要がある。

独立監査は、この取り組みをさらに強化する。公開されたMiriの検出結果、sanitizerの結果、fuzzingの成果についても、回帰テストを伴う明確な修正が提示されるべきだ。

Bunが性能と互換性を維持しながらunsafeの使用を減らせれば、書き換えの安全性に関する主張は強まる。safeインターフェース内でライフタイム障害が繰り返されれば、その主張は弱まるだろう。

第3のシグナルは、別の成熟したプロジェクトがBunの移行手法を再現できるかどうかだ。Bunには、広範なテスト、1人の主要アーキテクト、リリース前モデルを利用できる所有者という、極めて有利な出発条件が揃っていた。

2度目の移行を成功と呼ぶには、高速なコード生成以上の成果を示す必要がある。人間によるレビュー、欠陥の発見、運用上の管理、リリース後の保守についても文書化されなければならない。

同様の成果が繰り返されれば、長年にわたる書き換えコストが障壁となっているプロジェクトにとって、AI支援による言語移行が一般的な選択肢になる可能性がある。

一方、Bunの事例が孤立した実証にとどまるなら、そこから得られる教訓の範囲はより限定的になる。この成果の重要性は変わらないものの、ソフトウェア開発全般というより、Bunのテスト基盤の優秀さを示すものとなるだろう。

より大きな争点は、RustとZigの優劣ではない。機械生成がもたらす速度と、基盤ソフトウェアを信頼するために必要な証拠とのせめぎ合いである。

Bunはこの競争を、試験的な小規模プロジェクトから、月間ダウンロード数が2,200万件を超えるランタイムへと引き上げた。Anthropicはさらに、世間の議論が決着する前に、その成果をClaude Codeへ組み込んだ。

この判断により、Bunは貴重な本番環境からのフィードバックを得られる。同時にAnthropicには、自社のコーディングエージェントが生成したものを継続的に保守できると証明する責任が生じる。

開発者はリスクの高い移行に踏み切る前に、リリースノート、未解決の安全性に関する報告、独立した導入事例の結果を注視すべきだ。また、現実的な負荷条件の下で、自らが利用する依存関係をテストする必要もある。

Anthropicによる買収後に行われたBunのRustへの書き換えは、AI支援による移植が、これまで実質的に不可能とされてきた規模の壁を越え得ることを、すでに示している。

残る疑問は、検証プロセスが生成プロセスの速度に追随できるかどうかだ。Bun 1.4の実環境でのパフォーマンス、安全性を保証できないコードに対する監査、そして同じ手法に挑む次の大規模プロジェクトの動向を注視する必要がある。