AnthropicのClaude Code移行は2週間でBunをZigからRustへ移行したが、難題は速度ではなかった

AnthropicはClaude Codeを使用してBunをZigからRustへ移行し、2週間足らずで約100万行のコードを生成した。AnthropicのClaude Code移行は、マージ前にBunの既存の継続的インテグレーションテストを通過した。それでも、19件のリグレッションがマージ後のコードベースに入り込んだ。

この対比は、生の出力量よりも重要である。Claude Codeは、従来のエンジニアリングチームでは到底かなわない速度でコードを生成した。しかし、このプロジェクトが成功したのは、人間が厳格なルール、独立したレビュアー、機械的な作業キュー、言語に依存しないテストを構築したからにほかならない。

したがって、真の競争はAIエージェント対人間のプログラマーではない。自動コード生成対自動検証である。Anthropicの成果は、生成が安価かつ潤沢になりつつある一方で、信頼できる受け入れ判断が依然としてエンジニアリング上のボトルネックであることを示唆している。

Bunの共同創業者Jarred Sumnerは、Bunが2025年12月にAnthropicへ加わった後、この移行を指揮した。彼はリリース前のClaudeモデルと約50の動的ワークフローを11日間にわたって使用した。その後、Anthropicはこの作業から得た教訓を汎用的な移行プロセスへとまとめた。

この結果は、ソフトウェアエンジニアリングにおける最古の警告の一つ、すなわち可能な限り全面的なリライトを避けるべきだという考えに異議を唱えるものだ。この警告は今なお有効だが、その根拠となるコストモデルは変化した。

AnthropicのClaude Code移行はマシンスケールでBunを書き直した

Anthropicは、かつてエンジニア年単位で測られていたプロジェクトを11日間のエージェントワークフローに圧縮し、Bunの通常開発を1年間凍結することなく完遂した。

BunはJavaScriptおよびTypeScriptのランタイムであり、パッケージマネージャー、テストランナー、バンドラー、Node.js APIとの互換レイヤーも備えている。この広範な対象領域により、言語移行は非常に困難なものとなった。

移植前のBunには、コメントを除いて535,496行のZigコードが含まれていたと、SumnerはRustへのリライトに関する記録で述べている。また、このプロジェクトはJavaScriptCore、SQLite、BoringSSL、複数のネットワーキングライブラリを含むCおよびC++コンポーネントにも依存していた。

従来型のリライトでは、二つの動き続ける標的が生まれていただろう。エンジニアは既存の動作を再現する一方で、本番環境のZig版には引き続き修正や機能追加が行われることになる。

Sumnerは、少人数のチームでは約1年を要しただろうと見積もった。そのようなスケジュールでは、製品開発を遅らせるか、開発者に二つの実装を同時に保守させる必要があった。

そこでSumnerは、構造を維持した移植を選択した。Claudeは、動作変更を最小限に抑えながら既存設計をRustへ変換する。アーキテクチャの整理は、互換性を確立した後に実施できる。

この違いは重要である。Claude Codeは、製品仕様から新しいランタイムを発明したわけではない。Zig実装を実行可能な参照として、BunのTypeScriptテストスイートを外部の判定基準として利用した。

Sumnerはまず、Claudeとともに約3時間をかけて移植ガイドを作成した。完成した文書では、Zigの型、所有権パターン、一般的なイディオムを対応するRustの表現へマッピングした。

別のワークフローでは構造体のフィールドを調査し、Rustのライフタイムを提案した。ライフタイムは参照が有効であり続ける期間を表し、Rustコンパイラが多くの安全でないメモリ関係を拒否できるようにする。

これらの判断は、エージェント内部だけの推論ではなく、共有された成果物となった。すべての変換ワーカーが同じルールを参照でき、レビュアーはそこからの逸脱を指摘できた。

続いてSumnerは、3つのファイルでこの手法をテストした。各ファイルを1つのエージェントが変換し、独立した2つのエージェントがレビューし、別のエージェントが承認された修正を適用した。

この試験運用により、変換パターンが1,448個のZigファイル全体へ広がる前に問題を把握できた。目的は初期コードを保存することではなく、プロセスを改善することだったため、Sumnerは試験出力を破棄した。

ルールが安定すると、4つのワークフローシャードがそれぞれ16個のClaudeインスタンスを実行した。出力のピーク時には、システムは毎分約1,300行を生成したと報告されている。

それでも、生の変換結果は動作しなかった。この点を認めることが、プロジェクトを理解するうえで極めて重要である。

Claudeの最初の仕事は、完全な実装候補を作成することだった。その後、コンパイラ、テスト、敵対的なレビュアーが、その候補を動作するソフトウェアへ変換した。

このプロセスでは6,502件のコミットが生成された。ある時点で、Rustコンパイラは約16,000件のエラーを報告した。Anthropicはこれらの失敗を、実験が失敗した証拠ではなく、処理すべきキューとして扱った。

コンパイルエラーを修正する過程で、両言語間のさらに深い非互換性が明らかになった。Zigの遅延コンパイルでは一部の循環インポートが許容されていたが、Rustのモジュールシステムはこれを拒否した。

エージェントはこれらのエラーを分類し、移行ルールを変更した。その後、影響を受けた単位を体系的に再生成または修復した。

Anthropicの移行に関する記録によると、コードがマージされる前に、Bunの既存テストスイート全体が継続的インテグレーションで合格した。Rustへの移植版は2026年6月にClaude Codeへ組み込まれて出荷された。

マージ後、19件のリグレッションが明らかになった。Anthropicによれば、19件すべてがその後修正された。

これらのリグレッションがあるため、単純な勝利物語として語ることはできない。大規模なテストスイートへの合格は、完全な動作同等性を証明したわけではない。出荷し、本番環境を監視し、見逃されたケースを修復するのに十分な信頼性を確立したのである。

BunがZigを離れる決断をした理由

Claude Codeは移行の障壁を下げたが、それを乗り越えるビジネス上の理由となったのは、繰り返し発生するメモリ不具合だった。

Sumnerは、Bunの安定性問題についてZigを責めないよう慎重に説明している。コーディングモデルが広く利用可能になる前、Zigは彼が1年でBunの初版を構築する助けとなった。

難しさは、Bun特有のワークロードにあった。Bunは、JavaScriptのガベージコレクション対象オブジェクトと、手動で管理されるネイティブメモリ、さらに複数のCまたはC++ライブラリを接続している。

この境界では、所有権に関する難しい問題が生じる。エンジニアは、各割り当てを誰が解放するのか、コールバックがネイティブハンドルより長く存続するか、ガベージコレクション対象の参照が引き続き可視であるかを把握しなければならない。

BunはすでにAddressSanitizer、安全性チェック付きビルド、継続的ファジング、メモリリークテストを使用していた。それでも、リリースノートには解放後使用、二重解放、リーク、競合状態が引き続き記載されていた。

解放後使用は、ソフトウェアがメモリを解放した後にそのメモリへアクセスすると発生する。二重解放は、同じ割り当てを2回解放し、プロセスを破損させる可能性がある。

こうした不具合は、多くの場合、珍しいタイミング経路に潜んでいる。バグが可視化されるには、テストで正しいコールバック順序、例外経路、または状態変化を再現しなければならない。

Rustは、その負担の一部を型システムへ移す。Rustの所有権ルールはどの値がメモリを制御するかを決定し、借用チェッカーは競合する参照や無効な参照をコンパイル時に拒否する。

RustのDrop機構は、値がスコープを外れた際にクリーンアップも実行する。これにより、関連するすべての呼び出し箇所でクリーンアップ文を忘れずに記述することへの依存が減る。

この言語がすべてのメモリリスクを取り除くわけではない。Bunは引き続きネイティブライブラリやJavaScriptCoreと連携するため、一部の操作は完全に安全なRustの範囲内には収まらない。

Anthropicによれば、移植されたRustコードの約4%がunsafeブロックを使用している。Unsafe Rustでは、コンパイラが完全には検証できない操作が許可され、その正しさは再び開発者とレビュアーに委ねられる。

それでも、Sumnerの主張は、RustによってBunがクラッシュ不能になるというものではなかった。Rustによって、より多くの不具合を早期のフィードバックループへ移せるというものだった。

コンパイラエラーは、コードが実行される前に発生する。AddressSanitizerとファジングには実行が必要であり、本番環境のテレメトリはユーザーが問題に遭遇した後に届く。

この順序が、予防の経済性を変える。コンパイルで拒否される方が、複数のプラットフォームにまたがる稀な実行時障害を診断するより、通常は低コストである。

Bunによれば、バージョン1.4ではバージョン1.3.14で再現可能だった128件の不具合が修正された。これにはメモリリーク、クラッシュ、小規模な互換性問題が含まれていた。

チームは、反復ビルドのベンチマークにおいてメモリ消費量が減少したことも報告した。同じビルドを2,000回実行した場合、移植前には6,745 MBを使用していたが、移植後は609 MBとなった。

Anthropicによれば、新しいバイナリはLinuxとWindowsで19%小さくなった。また、HTTP配信および選定された実環境ワークロード全体で、2%から5%の性能向上があったと報告している。

これらの数値は独立したベンチマークではなく、AnthropicとBunによるものである。外部ユーザーが今後検証できるプロジェクト成果として読むべきだろう。

また、性能向上は当初の約束でもなかった。主な目標は、Bunのロードマップを中断することなく、繰り返し発生する安定性リスクを減らすことだった。

この点で、この移植はAIの速度実演以上に重要な意味を持つ。測定可能なエンジニアリング上の負債を、より多くの所有権エラーを機械的に検出するターゲット言語と結び付けたからだ。

Claude Codeは作業能力を提供した。Rustはより厳格な判定基準を提供した。

突破口はコード生成ではなく、検証ループだった

このプロジェクトが機能したのは、すべての失敗が構造化された入力となり、システムを通じた次の制御された処理へ送られたからである。

大規模言語モデルは、説得力があり、コンパイルも通るが、それでも間違っているコードを生成し得る。Bunの移行には、この問題を直接示す例が含まれていた。

変換されたある関数は、非同期のクローズ処理にネイティブポインタを渡していた。その後、Rustが所有元のボックスを早すぎる段階でドロップしたため、ネイティブライブラリには解放済みメモリが残された。

別の変換では、1970年以前のタイムスタンプが誤って表現されていた。さらに別の変換では、フォールバック式を先行評価していたため、有効なCSSカラー関数の処理中にパニックが発生する可能性があった。

報告によれば、3つの例はいずれもコンパイルに成功した。表面的にはもっともらしく見えるため、特に100万行規模の変更内では、通常の目視レビューは信頼できなかった。

Sumnerは、実装とレビューを分離した。各実装エージェントには、元のZigファイル、移植ルール、専用の作業コンテキストが与えられた。

レビュアーエージェントには、生成された差分が別々のコンテキストで与えられた。コードは誤っていると仮定し、特定の不具合を探すよう指示された。

この分離は、エージェントが自らの以前の推論を擁護することを防ぐための試みだった。各単位を2人のレビュアーが検査し、別のエージェントが意見の相違や修正を処理した。

Anthropicはこれを敵対的レビューと呼んでいる。レビュアーが同じ盲点を共有したり、同じ動作を誤解したりする可能性があるため、これは正しさの証明ではない。

その価値は、役割の分離と反復にある。レビュアーには測定可能な目的が一つあり、実装エージェントには別の目的がある。

また、ワークフローはコンパイラを無差別に使用することも避けた。すべての並列タスク内で完全なRustビルドを実行すると、競合が発生し、計算資源が浪費されるからだ。

代わりに、変換エージェントはルールブックに従ってファイルを書き込んだ。ファンアウトの完了後、集中管理されたコンパイル段階がエラー一覧を生成した。

修正エージェントは、その一覧をクレートとモジュールごとに分割した。オーケストレーションスクリプトが次の完全ビルドを実行するタイミングを制御する一方で、エージェントは対象を絞った修正をコミットした。

コンパイル後、テストも同じ役割を果たした。失敗した各アサーションは、旧動作と新動作に結び付いた具体的なキュー項目となった。

障害が一度だけ現れた場合、エージェントは影響を受けた実装を修正できた。同じパターンが繰り返し現れた場合、チームは上流の変換ルールを変更した。

この手法は、Anthropicの重要な原則に従っている。生成されたコードだけでなく、そのコードを生み出したプロセスを修正するという考え方だ。

一度限りのパッチは、1つのファイルを改善する。ルールの変更は、同じ誤った前提のもとで作成されたすべてのファイルを修正できる。

Anthropicは、プロンプト、テンプレート、キュースクリプト、安全設定を含む汎用的な移行キットを公開しています。このキットは実現可能性の評価から始まり、移行を見送ることも妥当な結果として認められています。

その6つのステージでは、マッピング、ルール作成、ストレステスト、変換、コンパイル、実行、動作比較を扱います。各ゲートには、機械的に判定できる終了条件が求められます。

このアプローチは、対話型プログラミングというより製造ラインに似ています。エージェントは専門化され、共有成果物がポリシーを伝達し、自動チェックが不良な出力を排除します。

このパターンは、Anthropicが移行をAIエージェントに特に適した作業と考える理由も説明しています。

第一に、ソースコード自体が望ましい動作の多くをすでに記述しています。エージェントは、不完全な要件からまったく新しいプロダクトを推測する必要がありません。

第二に、依存関係をマッピングすれば、多くのファイルを個別に変換できます。これにより、すべてのエージェントにリポジトリ全体を理解させることなく並列作業が可能になります。

第三に、コンパイラとテストが客観的なフィードバックを提供します。エージェントは、局所的な判断のたびに人間へ評価を求めることなく、ループを繰り返せます。

第四に、失敗そのものがバックログを作ります。コンパイラエラー、クラッシュ、出力の差異が次のタスクを明確にします。

Anthropicの動的ワークフローは、このモデルを静的なサブエージェント一覧の先へと拡張します。Claudeはオーケストレーションスクリプトを作成し、並列ワーカーを起動し、その結果を検査して、ワークフローを修正できます。

この自律性は処理能力の上限を引き上げます。同時に、権限、分離、再開可能な状態の重要性も高めます。

Sumnerは早い段階でその危険に直面しました。並列エージェントが、互いの作業を上書きしかねないコマンドを含む、競合するGit操作を実行し始めたのです。

彼はワークフローを修正し、広範なGitコマンドを禁止しました。エージェントは特定のファイルをコミットできる一方、オーケストレーターが移行全体の状態を管理しました。

この出来事は、洗練されたデモよりも示唆に富んでいます。エージェントの失敗は、必ずしも誤ったコードとして現れるとは限りません。連携、リポジトリの状態、あるいは実行を監査するために必要な証拠を損なうこともあります。

したがって、エンジニアリング上の優位性は、制約された自律性から生まれます。運用上の境界が明示されているからこそ、システムはより多くの作業を実行できます。

すべてのテストに合格しても19件のリグレッションが残った

Bunのマージ後のバグは、テスト完了がリリースの基準であって、同等性を数学的に保証するものではないことを示しています。

Anthropicの目玉となる成果は決定的に聞こえます。マージ前に、Bunの既存テストスイートの100%が合格したというものです。しかし、その後に発生した19件のリグレッションは、この割合では測定できないものを明らかにしています。

テストスイートが網羅するのは、作成者が予測してコード化した動作です。あらゆる環境、タイミングシーケンス、統合、ユーザーワークロードが自動的に表現されるわけではありません。

言語移行では、隠れた特性も変化します。目に見える出力が一致していても、メモリ割り当てのタイミング、デストラクタの実行順序、スレッドスケジューリング、外部関数との境界が異なる可能性があります。

Bunは、極めて有益な設計上の選択による恩恵を受けました。主要なテストスイートがZigではなくTypeScriptで記述されていたため、同じ外部インターフェースを介してどちらのランタイムもテストできたのです。

多くのレガシーシステムには、そのような独立性がありません。テストが非公開関数を呼び出したり、内部データ構造を検査したり、言語固有のモック動作に依存したりしています。

そのようなテストを新しい言語へ移すと、元の契約を維持するのではなく、実装を再現してしまう危険があります。その結果、誤った移植が誤ったテストと一致してしまう可能性があります。

Anthropicは、テストを移植可能なグループと実装依存のグループに分けることを推奨しています。チームは両方のバージョンに対して移植可能なテストを実行し、意図的に壊したビルドが失敗することを確認すべきです。

最後の手順は重要です。常に合格するテストは、誤った確信を生むため、テストがないよりも悪質です。

社内のPythonからTypeScriptへの移行では、Anthropic Labsの共同責任者Mike Kriegerには、完全に移植可能なテストスイートがなかったと報じられています。彼のチームは、7つの実際の利用シナリオを中心に同等性検証ハーネスを構築しました。

このハーネスは、PythonのオリジナルとTypeScriptの置き換え版に対してコマンドを実行し、その出力を比較しました。動作上の差異はすべてバグとして扱われました。

Kriegerの移行では、週末の間に165,000行のTypeScriptが生成されました。Anthropicによると、数百のエージェント、8つのフェーズゲート、3回の敵対的レビューが用いられました。

チームは、完成した試行を2回破棄しています。実行のたびにワークフローの弱点が明らかになり、次の試行でルールと検証プロセスを改善できました。

3回目の実行で、移植版は同等性チェックに合格しました。その後Claudeは追加のエンドツーエンドテストを生成し、4晩にわたって失敗を修正したと報じられています。

この事例は、Bunと同じ教訓を強調しています。悪い実行を破棄するコストが低ければ、高速な生成が有用になります。

従来の書き直しでは、数カ月にわたって埋没費用が積み上がります。初期のアーキテクチャ上の選択が誤りだったと判明しても、チームは再開をためらいます。

エージェント型移行では、ルールを変更した後に大部分を再生成できます。ブランチは使い捨てになり、検証済みのプロセスが永続的な資産になります。

とはいえ、再生成は無料ではありません。Anthropicは、動的ワークフローが通常のClaude Codeセッションよりも大幅に多くのトークンを消費する可能性があると警告しています。

また、チームには、受け入れ基準を設計し、ワークフローを監視し、システム全体の失敗を解釈し、動作上の変更を許容できるか判断する経験豊富なエンジニアが必要です。

Bunにおける4%のunsafeコードは、引き続き注意深く検証されるべきです。unsafeブロックはネイティブ境界で必要になる場合がありますが、まさにそこではRustの最も強力なコンパイラ保証が及びません。

機械的な移植は、過去から引き継いだ複雑性をそのまま維持する可能性もあります。Sumnerは、アーキテクチャを再設計すればリスクが増すため、意図的に行単位の変換を選択しました。

この選択は同等性の達成を早めましたが、自動的にRustらしい実装を生み出したわけではありません。Bunは、バージョン1.4のリリース後にunsafeの使用を減らし、実装をリファクタリングする予定です。

長期にわたる検証サイクルの間に、移行元と移行先のバージョンが乖離する可能性もあります。2週間の移行ならこの問題を抑えられますが、活発なリポジトリでは、その期間内でも大幅な変更が生じる可能性があります。

セキュリティレビューには、別の課題があります。テストが確認するのは観測された動作ですが、セキュリティ分析では悪意ある入力や予期しない状態の組み合わせを考慮しなければなりません。

したがって、公開された証拠が裏付ける結論は、「Claudeはあらゆるコードベースを書き直せる」という主張よりも限定的です。強力な仕様、並列化可能な作業、客観的な動作チェックを備えた移行を裏付けています。

文書化されていない要件、脆弱なテスト、ハードウェア依存のタイミングを持つプロジェクトは、より困難な道をたどります。エージェントの速度にかかわらず、欠けている仕様を作ることが主要なプロジェクトになります。

同様の取り組みを検討するチームは、まず判定システムを改善すべきです。技術的な意思決定を検索可能な形で集めれば、それらのルールの背景にある文脈を維持するのに役立ちます。

たとえば、エンジニアリング知識ベースは、設計ノート、移行ポリシー、テスト証拠を結び付けられます。この記録は、数百のエージェントが数千のコミットを生成する場合に特に有用になります。

中心的なリスクは、もはや単にAIが悪いコードを書くことではありません。組織が大量の出力と成功したテストを、完全な理解と取り違えることです。

エンジニアリングチームが次に注視すべきこと

次の段階は、持続的な本番品質、unsafe領域の縮小、そしてAnthropicの極めて有利な環境以外での移行成功によって評価されます。

最初の指標は、今後数回のリリースにおけるBunの本番運用実績です。重要な数字は、生成された行数でも、1時間あたりの最大コミット数でもありません。

Rustビルドを採用するユーザーが増えた後、開発者はリグレッション数、クラッシュレポート、メモリ欠陥、互換性障害を注視すべきです。

これらの指標がZig版の基準を下回り続ければ、Anthropicの主張はより強固になります。新たな障害が変換されたコード周辺に集中するなら、マージ前の検証プロセスにはさらなる修正が必要です。

第二の指標は、unsafe Rustの割合と位置です。報告された4%から減少すれば、機械的な移植をよりRustらしい実装へ成熟させられることが示されます。

位置は割合と同じくらい重要です。監査済みのCインターフェース周辺に限定された小さなunsafe境界と、コアランタイムコンポーネント全体に分散したunsafeロジックでは、リスクが異なります。

Bunの公開リポジトリにより、外部のRust開発者もこれらの判断を検証できます。独立したベンチマークとバグレポートは、Anthropic自身の測定を超える証拠を提供するでしょう。

第三の指標は、他の組織がこの手法を再現できるかどうかです。Bunには、独立したTypeScriptテストスイート、高度な技術力を持つ創業者、Anthropicの最新モデルへの直接アクセスがありました。

より広い範囲で説得力のある成果を示すには、文書が不十分で、内部テスト、複数の所有者、規制またはセキュリティ要件を抱えるレガシーシステムが必要です。

Anthropicの第二の事例であるPythonからTypeScriptへの移植は、その方向へ進んでいます。しかし、それは依然としてツールを開発した企業自身が説明する社内プロジェクトです。

同社によると、開発者は7月16日の発表前の1カ月間に10個のパッケージを移行しました。これらのプロジェクトの規模は、数万行から数十万行に及びました。

より詳細なケーススタディでは、チームが試行を断念する頻度、人間が費やす時間、自動レビューをすり抜ける欠陥が明らかになるはずです。

競合するコーディングエージェントも、長時間実行され、再開可能なワークフローへの対応を迫られるでしょう。価値あるタスクが相互依存する数千の単位にまたがる場合、単一ファイルの補完の重要性は低下します。

プロダクト間の競争は、ますますオーケストレーション、権限、評価、復旧を中心に展開するようになります。モデルの知能は引き続き必要ですが、それだけでは運用上の規律をもたらしません。

エンジニアリングリーダーは、移行を自動的なモダナイゼーション戦略として扱うべきではありません。Anthropic自身の初期プロセスも、そもそも書き直すべきかを問うところから始まります。

移植の成功は動作を維持します。より良いアーキテクチャ、より明確なプロダクト要件、運用上の複雑性の軽減を保証するものではありません。

最も有力な候補には、具体的な技術的負債と、それを解決するターゲットプラットフォームがあります。また、両方の実装を公平に評価できる外部テストも備えています。

Bunはこれらの条件を満たしていました。手動のメモリ管理が繰り返し安定性対応を必要とする一因となっていた一方、Rustはより多くの所有権チェックをコンパイル時に移しました。

そしてClaude Codeは、かつては非現実的だった移行を、ロードマップを中断せずに試せるほど高速にしました。AIの出力だけではなく、この組み合わせが成果を生み出したのです。

Anthropic Claude Codeによる移行は、エンジニアリングチームが現実的に問える問題を変えました。言語全体の移植は、もはや複数年にわたるコミットメントとして始める必要はありません。

明示的なゲートと使い捨て可能なブランチを備えた、範囲を限定した実験として始められます。失敗は、放棄された書き直しではなく、より良いルールを生み出せます。

しかし、立証責任が消えたわけではありません。「エージェントはコードを生成できるか？」から「組織は誤ったコードを確実に排除する判定システムを構築できるか？」へ移ったのです。

チームは数百のエージェントを起動する前に、この問いを検証すべきです。制約されたコンポーネントを1つ選び、観測可能な同等性を定義し、意図的に判定システムを破ってください。

システムがそれらの失敗を検出できれば、より大規模な移行にも説得力が生まれます。検出できなければ、コード生成の高速化は、不確実性をより大きな規模で生み出すだけです。