Claude CodeがBunをRustに書き換える方法：大規模コード移行の6ステップガイド

はじめに

かつて、大規模なプログラミング言語の移行は、エンジニアリングチームが何年も先送りにしてしまうプロジェクトの一種でした。こうした移行はコストが高く、破壊的で、リスクも大きいものです。企業は2つの実装を同時に維持するために数四半期を費やし、最終的に得られる代替品は元のバージョンと一貫性のない動作をする可能性がありました。

Claude Codeがこの状況を変えています。

Anthropicは最近、AIエージェントを活用した大規模コード移行のプロセスを公開しました。最も注目すべき事例は、Bunの作成者であるJarred Sumner氏がBunの中核をZigからRustに移行したことです。2週間足らずで、Claude Codeのワークフローは100万行以上のコードを生成し、Bunの既存のテストスイートはマージ前に継続的インテグレーションテストに合格しました。

このプロジェクトは、モデルに「BunをRustで書き換えて」と指示して完璧な答えを待つことで完了したわけではありません。ルールブック、依存関係マッピング、機械的キュー、敵対的レビューア、コンパイラ、スモークテスト、動作一貫性チェックなど、慎重に設計されたシステムに依存していました。

核心的な教訓は直接的です。この規模の移行では、開発者は個々のファイルの修正にほとんどの時間を費やすべきではありません。それらのファイルを生成、レビュー、検証するプロセスを改善すべきなのです。

Bunの作成者、AIを使って100万行以上のコードを書き換え

Jarred Sumner氏は当初、BunをZigで構築しました。この言語により、独立した開発者は、大規模なシステム言語エコシステムの複雑さすべてに対処することなく、低レベルの制御とC言語に似たパフォーマンスの両方を得ることができました。

この選択は、Bunの初期の急速な発展に貢献しました。Sumner氏は、オークランドの小さなアパートで、現代のコーディングモデルが存在しない時代に、約1年かけて最初のバージョンを書いたと述べています。

2026年までに、Bunは広く使用されるJavaScriptおよびTypeScriptランタイム、パッケージマネージャー、テストランナー、バンドラーツールとなりました。そのコマンドラインツールは毎月数千万回ダウンロードされ、Claude Codeを含む製品はBunに大きく依存しています。

成長はまた、古いエンジニアリング上のトレードオフを無視できないものにしました。

Bunは、ガベージコレクションを行うJavaScriptエンジンと手動で管理されるネイティブメモリを組み合わせています。Zigでは、開発者は割り当て、クリーンアップ、エラーパス、オブジェクトのライフサイクルについて明示的に推論する必要があります。Bunのチームはサニタイザー、ファジング、セキュリティビルド、メモリリークテストに多大な労力を費やしてきましたが、使用後解放エラー、二重解放、リーク、ライフサイクルエラーは依然として発生していました。

Rustは異なる基盤を提供します。その所有権システム、借用チェッカー、自動クリーンアップにより、多くのランタイムメモリ問題をコンパイル時エラーに変換できます。

歴史的に見れば、この利点だけでは完全な書き換えを正当化するには十分ではありませんでした。Bunには数十万行のZigコードと、膨大なネイティブ統合が含まれています。従来の書き換えでは、小規模なエンジニアリングチームが1年以上を費やし、機能開発やセキュリティ修正の速度を低下させる可能性がありました。

Claude Codeは、完全な機械的移行を実現可能にしました。

ZigからRustへの11日間

Sumner氏は、Claude Fable 5のプレリリース版とClaude Codeの動的ワークフローを使用して移行を実行しました。

主要な作成とレビュー

このプロセスは11日間継続して実行されました。約50の動的ワークフローがさまざまな段階を処理しました。これには以下が含まれます。

• ZigからRustへの移植ガイドの作成
• メモリライフサイクルのマッピング
• .zigファイルの.rsファイルへの変換
• 生成された各ファイルのレビュー
• コンパイラエラーの修正
• 個々のBunコマンドの復元
• 完全なテストスイートの実行
• 生成されたコードのリファクタリングとクリーンアップ

ピークスループット時には、ワークフローは毎分約1300行のコードを生成しました。生成された各コードユニットは、2つの独立した敵対的レビューアによるチェックを受け、その後、修正者が確認された変更を適用しました。

最終的なプルリクエストは、2000を超える変更ファイルに100万行以上のコードを追加しました。

マージ前、Bunの既存のテストスイートはCIで合格しました。マージ後には19の回帰問題が発生しましたが、Anthropicはこれらがすべてその後修正されたと報告しています。Rust移植版は、2026年6月にClaude Codeとともにリリースされました。

この結果は、最初に生成された100万行のコードが正しかったことを証明するものではありません。Sumner氏は、初期の翻訳出力は実行できなかったと明言しています。成功の鍵はフィードバックシステムにあり、実行できない出力を、コンパイルされ、テストされ、動作に互換性のあるコードへと段階的に変換しました。

移行コストは約16万5000ドル（API価格ベース）

Bunの移行では、おおよそ以下のものが消費されました。

• 59億のキャッシュされていない入力トークン
• 6億9000万の出力トークン
• API価格で約16万5000ドル

これは少なくない金額ですが、伝統的に複数のフルタイムエンジニアが数年かけて行う移行コストよりははるかに低いものです。

Anthropicの試算では、これまでの100万行規模の移行には4年を要し、約300万〜400万ドルのエンジニアリングリソースがかかっていた可能性があります。AIはビジネスロジックを変えました。移行がそのコストを正当化するために存亡の危機を必要としなくなったからです。

持続的なメモリエラー、老朽化した言語エコシステム、高コストなビルドプロセス、または繰り返し発生するメンテナンスのボトルネックは、現在では移行の評価に値する十分な理由となり得ます。

ただし、比較には注意が必要です。トークンコストはプロジェクトの総コストではありません。チームは、人手による計画、インフラストラクチャ、テスト、コードレビュー、セキュリティ作業、マージ後のメンテナンスも必要とします。

BunがZigからRustに移行した理由

この移行は、主に信頼性の向上を目的としており、未加工の速度のためではありません。

BunはZigでもすでに優れたパフォーマンスを発揮していました。問題は、手動で管理されるネイティブメモリとガベージコレクションを行うJavaScriptランタイムを安全に調整する方法にありました。

一般的な障害のカテゴリは以下の通りです。

• 使用後解放エラー
• 二重解放エラー
• 例外的なパスでのメモリリーク
• 再入可能なコールバックによる無効なポインタ
• スキップされたクリーンアップコード
• 一貫して実施することが難しいライフサイクルの仮定

安全なRustでは、これらのエラーの多くはコンパイルできません。値は明確な所有権を持ち、リソースのクリーンアップはオブジェクトのライフサイクルにバインドされ、コンパイラはプログラムの実行前に参照をチェックします。

この移行の目標は、Bunの既存のアーキテクチャ、データ構造、動作、パフォーマンスを保持することでした。これは意図的に、完全な再設計ではなく、機械的移植に近いものとなっています。

この判断は極めて重要です。システムを再設計すると同時に言語を変更すると、動作の比較が非常に困難になります。

2つ目の事例：16万5000行のPythonコードをTypeScriptに

Jarred Sumner氏だけが、Claude Codeを使用して大規模な移行を行ったAnthropicのエンジニアではありません。

Anthropic Labsの共同責任者でありInstagramの共同創設者であるMike Krieger氏は、週末のうちに内部のPythonコードベースを約16万5000行のTypeScriptコードに移行しました。

主要な移行プロセスでは、約2700万トークンを消費し、以下が含まれていました。

• 数百のインテリジェントエージェント
• 8つのフェーズゲート
• 3ラウンドの敵対的レビュー
• 最終的な一貫性チェック
• Pythonバージョンとのコマンドごとの出力比較
• AIが生成したエンドツーエンドテスト

元のツールは単一のバイナリファイルとして提供される必要がありました。Pythonツールチェーンを使用すると、プラットフォームごとのコンパイルに約8分かかり、完全なビルドマトリックスによりリリースごとに約30分の遅延が発生していました。

TypeScriptへの移行後：

• コンパイル時間は約2秒に短縮
• バイナリの起動速度は約6倍に向上
• 独立したデプロイパイプラインを廃止可能に

Krieger氏は、既存の包括的なクロス言語テストスイートに依存していませんでした。代わりに、Claude Codeが

7つの実シナリオをカバーする一貫性テストフレームワークを作成し、新旧の実装の出力結果を比較しました。

Claudeはさらにエンドツーエンドのテストを設計し、4夜連続でそれらを実行し、失敗ケースを修正した後、このプロセスを繰り返しました。これにより、元のシナリオでは予期されていなかった微妙な動作の違いが明らかになりました。

なぜ大規模コード移行はAIエージェントに適しているのか

大規模移行が困難に感じられるのは、膨大な反復的変更が伴うからです。しかし、まさにその特徴こそが、エージェントワークフローに適している理由です。

作業の並列化が可能

大規模コードベースは通常、ファイル、パッケージ、クレート、モジュール、依存関係グループに分割できます。独立したエージェントが、互いに依存しないユニットを同時に処理できます。

依存関係グラフが、どのユニットを並行して進められるか、どのユニットが待機する必要があるかを決定します。

既存コードが仕様となる

元の実装には、必要な動作、エッジケース、データ構造、統合の詳細がすでに含まれています。

モデルは製品機能を創造する必要はなく、そのタスクは新しい言語やフレームワークで既存のシステムを保持することです。

テストが客観的な判断基準を提供する

エージェントが自身の出力を機械的に評価できる場合、その効果は向上します。

コンパイラ、テストスイート、出力差分比較、ベンチマーク、一貫性テストフレームワークは、システムに具体的なシグナルを提供します。エージェントは人間が毎回の中間試行を評価することなく、継続的に改善できます。

タスクキューが自動生成される

コンパイルエラーが次のタスクになり、失敗したテストが次のタスクになり、プログラムのクラッシュも次のタスクになります。

これにより、大規模移行タスクは、繰り返し縮小可能なキューに変換されます。

繰り返しの失敗がルール改善を促進する

レビューアが複数のファイルで同じ問題を発見した場合、最善の解決策は各ファイルを手動で個別に修正することではありません。

ルールブックを更新し、影響を受けるバッチを再生成するべきです。これにより、後続の作業で同じエラーが再発するのを防げます。

中核原則：個々のファイルではなく、プロセスを修正する

Anthropicのプロセスで最も重要な考え方は、生成されたコードをシステム出力の産物と見なすことです。

200の翻訳済みファイルに同じ所有権エラーが含まれていると仮定します。これらのファイルを手動で修正すれば目に見えるエラーは解決できるかもしれませんが、ワークフローが再び同じエラーを生み出す可能性があります。

より効果的な方法は次のとおりです：

1. 繰り返し失敗するパターンを特定する。
2. どの移行ルールが原因かを特定する。
3. ルールブックを更新する。
4. 影響を受けるファイルのみを再生成する。
5. レビューと検証のサイクルを再実行する。

コードが改善されるのは、生産プロセスが最適化されたからです。

これは通常のソフトウェアエンジニアリングと似ています。繰り返し発生する生産上の欠陥は、テスト、型ルール、静的チェック、プロセスの改善を促すべきであり、単に別の孤立したパッチを当てるだけでは不十分です。

前提条件：信頼できる評価メカニズムの構築

大規模移行を始める前に、チームが新しい実装の正しさをどのように証明するかを定義する必要があります。

評価メカニズムがなければ、信頼できる完了条件を決定できません。

評価メカニズムは、同等の条件下で元の実装とターゲット実装を評価しなければなりません。既存のテストは、プライベート関数や特定言語の内部機構に依存している場合があり、これらは移植中に消滅します。

Anthropicは3つの準備作業を推奨します：

1. 既存テストを分類する。 公開動作をテストするものと、内部実装に依存するものを分ける。
2. 移植可能なようにテストを書き直す。 外部から観察可能な動作を、両方のシステムで実行可能なアサーションに変換する。
3. 評価メカニズムを検証する。 元の実装がテストに合格することを確認し、その後意図的にプログラムを破壊して評価メカニズムが機能しなくなることを確認する。

既知の障害を検出できないテストスイートは、有効な移行評価メカニズムとして使用できません。

Bunには顕著な利点があります：そのテストスイートの大部分がZigではなくTypeScriptで書かれているため、同じテストでRust実装をテストできます。

この利点がないプロジェクトでは、ピアテストツールを使用して、2つのバージョン間の実際の入力と出力を比較できます。

Anthropicの6ステップコード移行フレームワーク

Anthropicはこれらのプロジェクトでの経験を、以下の6ステッププロセスにまとめました。

[画像はAnthropicが提案する6ステップコード移行フレームワークを示しています。最初のステップはマップとルールの作成で、ルールブック作成者、依存関係マッパー、ギャップ在庫などが含まれます。2番目のステップはルールのストレステストで、デュアルトランスレーター、差分チェッカーなどがあります。3番目のステップはすべての翻訳で、実装者、レビューアなどが含まれます。4番目のステップはコンパイルで、ビルド調査、並列修正者などがあります。5番目のステップは実行で、スモークテスト、修正者などが含まれます。6番目のステップは動作の一致で、ビルドデーモン、修正者などがあります。下部には共有ドキュメント、実行インフラなどもリストされています。この図は、上記のAnthropic6ステップコード移行フレームワークを可視化したものです。]

ステップ1：ルールブック、依存関係グラフ、ギャップインベントリの作成

第1フェーズでは、後続のすべてのエージェントが従う共有ドキュメントを作成します。

ルールブックの構築

ルールブックは、ソース言語の概念をターゲット言語にどのようにマッピングするかを定義します。

構造を保持する移行の場合、ルールブックには以下が含まれます：

• 型マッピング
• エラーハンドリング

ルールの規約

• 命名規則
• メモリと所有権のルール
• 標準ライブラリの置換仕様
• 並行処理パターン
• ファイルとモジュールのレイアウト
• 外部関数インターフェースルール
• 人間によるレビューが必要なパターン

リファクタリング設計では、ルールブックはアーキテクチャ文書に近くなります。

Jarred SumnerはClaudeとの対話と人間によるレビューを通じて、Bunの移植ガイドを作成しました。最終的な成果物は数百行に及びます。

依存関係マッピングの作成

リポジトリは依存関係の順序に従って分割する必要があります。

決定論的スクリプトは、インポート、マニフェスト、ビルドファイル、シンボル関係を検査することで依存関係マッピングを生成できます。この結果は、オーケストレーターがどのファイルを独立して変換できるか、どのファイルを連携して処理する必要があるかを判断するのに役立ちます。

ギャップリストの作成

ソース言語とターゲット言語では異なるルールに従います。

ZigからRustへの移行では、メモリ所有権が主なギャップです。PythonからTypeScriptへの移行では、暗黙的なオブジェクト形態とインターフェースを明示的な契約に変換する必要があります。

ギャップリストは、単純な翻訳だけでは解決できない部分を記録します。具体的には以下を含みます：

• ソース言語の隠れた前提
• ターゲット言語で欠落している抽象化
• 明示化が必要なランタイム動作
• サポートされていないライブラリ
• プラットフォーム固有のコード
• 安全でない境界
• 再設計や人間による判断が必要な領域

ルールブックはギャップリストより先に作成する必要があります。なぜなら、ギャップリストは通常のルールでは処理できない内容に部分的に依存するからです。

ステップ2：ルールのストレステスト

数千のファイルをすぐに翻訳しないでください。

まず、複雑で代表的な少数のファイルを選んで、小規模で1回限りの試運転を行います。目的は、ルールの欠陥がリポジトリ全体に広がる前に露呈させることです。

Bunの試運転では：

1. 最初のエージェントがルールブックに基づいて3つのファイルを翻訳します。
2. 別のエージェントがシニアRustエンジニアの視点で同じファイルを翻訳します。
3. エージェントが差分を比較して確認します。
4. レビュー担当者が欠落または誤った移行ルールをマークします。
5. 翻訳ファイルは破棄されます。

このフェーズの成果物は、最適化されたルールブックであり、本番コードではありません。

リファクタリング移行の場合、同等のテストは、対抗レビューアが設計文書を攻撃し、その後1回限りのエンドツーエンド実行を行うことです。

ステップ3：完全翻訳

ルールが試運転で検証されると、リポジトリは並列キューで処理できます。

典型的なユニット構成は次のとおりです：

• 1人の実装者
• 2人の独立した対抗レビューア
• 1人の修正者
• 機械的キュー
• 共有ルールブック
• 共有ギャップリスト

キューは中断からの再開をサポートする必要があります。ファイルをチェックするか、成果物を記録することで（個々のエージェントの記憶に依存せずに）作業の完了状態を判断できるようにする必要があります。

エージェントは未完了の作業を常に一貫してマークする必要があります。例：

TODO(移植): この部分が安全に翻訳できない理由を説明する

各ユニットに最も高価なモデルを使用する必要はありません。低スペックのモデルは大量の翻訳を処理し、強力なモデルはレビューア、アーキテクチャ決定、ルール修正に取っておくことができます。

ステップ4：コンパイル

初めての完全ビルドでは、コンパイラエラーを構造化された作業キューに変換します。

ビルドコストに応じて、コンパイラは各エージェントループ内で実行することも、別のオーケストレーターを介して実行することもできます。

Bunプロジェクトの場合、ワークスペース全体のコンパイルコストが高いため、ファイル翻訳中にClaudeエージェントが自由にcargoコマンドを実行することはありません。代わりに以下のプロセスが取られます：

1. オーケストレーターがコンパイラを実行する。
2. エラーメッセージが共有リストに書き込まれる。
3. モジュールまたは根本原因ごとにリストが分類される。
4. 修正エージェントが各エラーグループを並行して処理する。
5. レビューアが修正結果をチェックする。
6. オーケストレーターがプロジェクトを再ビルドする。

これにより、数十のエージェントが同時に同じ高コストなビルドを開始するのを防ぎます。

システム的なコンパイラエラーはルールを更新すべきです。例えば、ターゲット言語が、元のコンパイラが遅延ロードで許容していた循環依存を拒否する場合があります。これは、単なる孤立したファイルエラーの集合ではなく、プロセスレベルの問題です。

ステップ5：プログラムの実行

コンパイルが成功したことは、ターゲット言語がコードを受け入れたことを証明するだけです。

次のフェーズでは、基本的な実行とスモークテストを通じて、クラッシュ、初期化失敗、リソース不足、無効な前提、統合障害を発見します。

失敗ケースは引き続き原因別に分類する必要があります。

もし40個のスモークテストが同じ誤った初期化パターンで失敗した場合、40個の独立した修正を割り当てるのではなく、移行ルールを修正し、影響を受けるコードを再生成すべきです。

ステップ6：元の動作との一致

最終关門は動作の一致性です。

両方のコードベースでポータブルなテストスイート、一致検証ツール、出力比較、関連ベンチマークを同時に実行します。

各失敗ケースに対して：

1. 修正エージェントに失敗の証拠と2つの実装案を提供する。
2. 修正エージェントに動作の差異を特定するよう要求する。
3. 対立するレビュアーが修正案をチェックする。
4. 単一のビルドフローでコストの高いビルドをバッチ処理する。
5. 影響を受けるテストを再実行する。
6. 繰り返し発生する失敗をルール変更に格上げする。

元のコードベースは、プロジェクトが明示的に動作変更を意図しない限り、常に事実上の基準です。

テストスイートがなくてもこのステップをスキップすることはできません。チームはClaudeを活用して、実際のシナリオに基づいた外部一致検証ツールを作成し、意図的に壊した動作で検証ツールの有効性を確認できます。

Anthropic移行ツールキット クイックスタート

Anthropicは、移行プロセスに基づく汎用プロンプト、テンプレート、スクリプトを含む公開スターターキットをリリースしました。

このリポジトリは参考資料であり、完全にホストされた移行製品ではありません。そのプロンプトはリファクタリング用のテンプレートであり、Bunプロジェクトの正確なプロセス記録ではありません。

1. Claude Codeのインストール

macOSまたはLinuxシステムの場合：

curl -fsSL https://claude.ai/install.sh | bash

Windows PowerShellシステムの場合：

irm https://claude.ai/install.ps1 | iex

リモートインストールスクリプトを実行する前に、スクリプトの内容と所属組織のセキュリティポリシーを確認してください。

2. 移行ツールキットのクローン

移行対象のリポジトリ内で実行：

git clone https://github.com/anthropics/code-migration-kit-with-claude-code.git ./migration-kit

3. 移行スキルの追加

このオプションステップでは、移行スキルをローカルのClaude Codeスキルディレクトリにコピーします：

cp -r migration-kit/skill ~/.claude/skills/code-migration

説明に従って、インストールされたSKILL.md内のツールキットパスを更新します。

リポジトリ。

4. 実現可能性評価の実行

まず、ツールキットの読み取り専用の実現可能性プロンプトを使用します：

prompts/00-feasibility.md

結果は3つの質問に答える必要があります：

• このプロジェクトは移行すべきか？
• 移行は構造を維持するのか、それとも再設計するのか？
• 元の実装とターゲットの実装を公平に評価できるか？

「移行しない」も有効な結果です。

5. 評価ツールとセーフティルールの準備

翻訳を開始する前に：

• 言語間評価ツールを構築または検証する。
• 推奨されるClaude設定をターゲットリポジトリにコピーする。
• 適切な場合、破壊的またはコストの高いコマンドを禁止する。
• ソースリポジトリに復元可能なバックアップがあることを確認する。
• 隔離されたブランチ、制御されたワークツリー、最小権限の認証情報を使用する。

その後、大規模な翻訳に直接飛び込むのではなく、移行プロンプトを順番に実行します。

Bunの初期試行で発生した問題

Bunの移行は当初から順調ではありませんでした。

多くのエージェントが1つのリポジトリで作業を開始すると、そのGit操作が互いに干渉し合いました。あるエージェントがgit stashを実行し、別のエージェントがgit stash popを使用し、さらに別のエージェントがワークツリーをリセットしました。

Sumnerは、エージェントが破壊的なGitコマンドを自由に実行できないようにワークフローを変更しました。その後、作業を4つのワークフローシャードに分割し、各シャードが独立したワークツリーを使用し、それぞれが複数のエージェントを調整するようにしました。

この例は、重要なポイントを浮き彫りにしています。エージェントの権限はワークフローの設計と一致していなければなりません。

広範なシェルアクセス権を持つコーディングエージェントは、以下の可能性があります：

• 作業を削除または上書きする
• 未コミットの変更をリセットする
• コストの高いビルドを繰り返しトリガーする
• 無関係なファイルを変更する
• コマンドやログを通じて機密情報を漏洩する
• 他のエージェントを妨害する

オーケストレーションレイヤーは、コマンドを制限し、ファイルの所有権を定義し、コストの高い操作をシリアル化し、復旧を容易にする必要があります。

AI支援コード移行のベストプラクティス

Anthropicが公開した教訓は、いくつかの実用的なルールにまとめられます。

汎用ガイドラインを盲目的に従わない

各コードベースには、異なるビルドシステム、テストカバレッジ、ランタイム動作、デプロイ制約、リスク許容度があります。

6ステップのフレームワークを出発点として、その後Claudeに実際のリポジトリに基づいて調整させます。

個々の失敗ではなくパターンに注目する

修正エージェントは個々の失敗に対処できます。人間の注意力は、繰り返し発生するパターン、欠落しているルール、安全でない前提、アーキテクチャ上の問題を特定する際に、より価値が高まります。

レビューを対立的に行う

実装エージェントが自身の唯一のレビュアーであってはなりません。

レビュアーには独立したコンテキストを提供し、生成されたコードは間違っていると仮定するよう伝えます。彼らのタスクは、コードが失敗する理由、逸脱する理由、ルールブックに違反する理由を見つけ出すことです。

検証を機械化する

コンパイラ、テスト、リンター、出力差分、ベンチマーク、決定論的スクリプトを評価ツールとして使用します。

主観的な「正しく見える」レビューでは、数百万行の変更を安全に検証できません。

異なる役割に異なるモデルを使用する

容量の大きい翻訳タスクは、より小規模または安価なモデルに任せることができます。最も強力なモデルは、ルール作成、アーキテクチャ、あいまいな失敗、レビューを担当すべきです。

早期に人間を投入する

最も価値の高い人間の作業は、大規模な生成が始まる前に行うべきです：

ビジネスケースの定義

• レビュー機構の構築
• ルールブックの作成
• 依存関係のマッピング
• パイロットプロジェクトの監査
• 権限と境界の設定

これらの基本部分が確実に安定したら、残りの作業の大部分は機械化されたキューイングタスクになります。

キューを復元可能に保つ

実行に数日を要する移行タスクは、クラッシュ、再起動、モデル障害、インフラストラクチャの中断などの予期せぬ事態に耐えられる必要があります。

完了状態は、単一の長い会話セッションではなく、ディスク上の永続化されたアーティファクト、コミット記録、テスト結果、キュー状態に基づいて判断されるべきです。

Bun移行後の成果

Anthropicは、Rustベースで記述されたBunのコードが本番環境で使用されていると報告しています。

この移行により、すべてのトレードオフが解消されたわけではありません。約4%のRustコードは依然としてunsafeブロック内に存在し、主にCおよびC++境界での小さなポインタ操作に集中しています。

ただし、新しい実装により顕著な改善が見られました：

• 検出可能なメモリリークの問題が修正された
• ある繰り返しビルドのベンチマークで、メモリ使用量が6,745 MBから609 MBに削減された
• LinuxおよびWindowsプラットフォームで、バイナリファイルサイズが19%縮小された
• 言語間の最適化により、特定のワークロードでパフォーマンスが約2%から5%向上した

これらの成果は、移行の意義を十分に示しています。目標は、AIによって作成された大量のコードを生成することではなく、元の動作を維持しながら、より安全で、よりコンパクトで、より保守しやすいシステムを構築することです。

AI移行が適しているシナリオ

以下の条件が満たされる場合、大規模な移行にはエージェントワークフローが適しています：

• 元のコードベースが完全な仕様として使用できる
• 動作を外部からチェックできる
• テストまたは同等のシナリオを作成できる
• 作業を繰り返し実行可能なユニットに分割できる
• ターゲット言語に明らかな利点がある
• 組織が大規模な実験的ブランチを許容できる
• 人間の専門家がアーキテクチャと境界ケースをレビューできる
• ツール環境を制限および監査できる

一方、以下の状況では適さない可能性があります：

• 元の動作を十分に理解していない
• 正確性を検証できない
• プロジェクトが移行と完全な製品再設計を混同している
• 規制上の承認にすべての変更に対する人間の検証が必要
• コードに安全に公開できない機密情報やシステムが含まれている
• AI生成コードのマージ後、チームに所有権がない

百万行のコードを高速に生成できることは、移行計画が当然妥当であることを意味しません。

よくある質問

Claude Codeは本当にBunをZigから移行したのですか？

Rust に書き換えたのか？

はい。Jarred Sumner 氏は、Claude Code の動的ワークフローとプレリリース版の Claude モデルを活用し、Bun のコアを Zig から Rust に移行しました。このプロセスでは、2 週間足らずで 100 万行以上のコードが生成され、その後、コンパイル、テスト、レビュー、マージ後の修正が行われました。

Bun の移行にはどれだけのコストがかかったのか？

Anthropic の報告によると、約 59 億の未キャッシュ入力トークンと 6 億 9000 万の出力トークンが消費されました。API 価格に基づくと、モデルコストは約 16 万 5000 ドルと推定され、人件費やインフラコストは含まれていません。

移行マージ前にすべてのテストに合格したのか？

Anthropic によると、マージ前には、Bun の既存テストスイートが CI で合格していました。マージ後には 19 の回帰問題が発見されましたが、これらは後にすべて修正されました。

Bun はなぜ Zig から Rust に移行したのか？

主な目的は、メモリ安全性の向上と、繰り返し発生するライフサイクル問題の解決です。具体的には、解放後使用（use-after-free）、二重解放、メモリリークなどの問題への対応です。Rust の所有権と型システムは、これらの問題の多くをコンパイル時に捕捉できます。

Claude Code は任意のコードベースを自動的に移行できるのか？

いいえ。移行を成功させるには、厳格な評価者、明確なルール、依存関係分析、制御された権限、再現可能なキュー、敵対的レビュー、人間による監視が必要です。そもそも移行すべきでないプロジェクトもあります。

敵対的コードレビューとは何か？

敵対的レビューアーは、独立した環境で生成された変更を受け取り、変更を承認するのではなく欠陥の発見を責務とします。実装者とレビューアーの役割が分離されているため、作成者が自身の出力を擁護するリスクが軽減されます。

既存のテストスイートは必要か？

理想的には、特に実装言語とは独立してパブリックな動作をテストできる場合は、既存のテストスイートが整備されていることが望ましいです。これがない場合、チームは新旧システム間の実際のシナリオと出力の差異を検証するためのフレームワークを構築できます。

Anthropic の移行キットが、Bun が使用した完全なワークフローなのか？

いいえ。Anthropic はこのリポジトリを、汎用化されリファクタリングされたスターターキットと説明しています。実際の Bun 移行では、長大なプロジェクトルールブックやカスタム動的ワークフローなど、より具体的な構成要素が使用されました。

関連ツール

• Claude Code：Anthropic のインテリジェントコーディングツール。リポジトリ、端末、テスト、開発ワークフロー管理向け。
• Bun：JavaScript および TypeScript のランタイム、パッケージマネージャー、バンドラー、テストランナー。
• Rust：パフォーマンス、型安全性、メモリ安全性に重点を置いたシステムプログラミング言語。
• Zig：明示的な制御と簡潔な言語セマンティクスを重視する低レベルプログラミング言語。
• GitHub：Bun 移行のプルリクエストや Anthropic 移行キットを管理するためのソース管理・コラボレーションプラットフォーム。
• Claude Code モダナイゼーションプラグイン：レガシーシステムの評価とモダナイゼーションのための Anthropic 公式プラグイン。

関連リンク

• Anthropic 大規模コード移行ガイド：公式の 6 ステッププロセスと 2 つの移行ケーススタディ。
• Bun を Rust で書き換え：Jarred Sumner 氏によるアーキテクチャ、ワークフロー、レビュー、失敗、結果の詳細な記録。
• Bun Rust 書き換えプルリクエスト：大規模な Zig から Rust への移行を含む、マージ済みプルリクエスト。
• Claude Code 移行キット：言語移行のための公式プロンプト、テンプレート、スクリプト、リファレンスワークフロー。
• Claude Code ドキュメント：公式のインストール、設定、セキュリティ、ワークフロードキュメント。
• コードモダナイゼーションプラグイン：レガシーシステムの評価と変革のための公式 Claude Code プラグイン。
• 動作等価性テスト。
• Rust 公式ガイド：Rust の所有権、借用、型、並行性、アプリケーション開発を網羅した公式ドキュメント。

まとめ

Claude Code が Bun の移行を成功させたのは、100 万行の完璧な書き換えを一度に生成したからではありません。プロジェクト成功の鍵は、チームがモデルを中心に、ルールブック、依存関係マッピング、未対応項目リスト、パイロットプロジェクト、並列翻訳キュー、敵対的レビュー、コンパイラループ、スモークテスト、動作一貫性チェックといった、厳格なプロダクションシステムを構築した点にあります。

同様の手法により、Anthropic は週末で大規模な Python コードベースを TypeScript に移行しました。これら 2 つのケースでは、生の生成速度よりも客観的な検証がはるかに重要でした。

AI は大規模移行のコストと期間を大幅に削減できますが、それはプロセスが中断・復旧可能で、権限が制御され、繰り返し発生する欠陥が生成コードのルールを継続的に改善できる場合に限ります。

真のブレークスルーは、AI が 100 万行のコードを書けることではなく、入念に設計されたループが、新しいシステムの動作が古いシステムと完全に一致するまで、コードを繰り返し生成し、疑問視し、テストし、修正できることです。