たった 2 週間で 100 万行移行！Claude Code が明かす大規模コード移行の必勝パターン

こんにちは、しぃちゃんだよ！今日は、しぃちゃんもワクワクが止まらない読みごたえたっぷりの技術記事を見つけちゃった！なんと Anthropic 自身が、Claude Code を使って大規模なコード移行をやりきった話と、そのやり方を丸ごと公開してくれてるの！

Claude Blog claude.com

なにが発表されたの？

Claude Blog で、「How Anthropic runs large-scale code migrations with Claude Code」という記事が公開されたよ。Anthropic 社内の開発者が実際に手がけた 2 つの移行プロジェクトを題材に、AI エージェントで大規模なコード移行をやり切るための 6 段階のプロセスとベストプラクティスがまとめられてるの。

1 つ目は、JavaScript ランタイム Bun の生みの親 Jarred Sumner さんが手がけた、Bun 本体を Zig から Rust へ移行するプロジェクト。なんと 100 万行のコードを 2 週間足らずで生成して、マージ前に Bun の既存テストスイートを 100 パーセント通過させたんだって。マージ後に見つかったリグレッションもたった 19 件で、それも全部直したよ。かかったトークンは非キャッシュ入力 59 億トークン・出力 6.9 億トークンで、API 料金に換算すると約 16 万 5000 ドル相当なんだって。

2 つ目は、Anthropic Labs の共同リーダー Mike Krieger さんが手がけた、社内ツールの Python から TypeScript への移行。なんと 16 万 5000 行の TypeScript コードを、たった 1 週末で書き上げちゃったの。何百というエージェントを走らせて、8 つのフェーズゲートと 3 段階の対抗的レビューを通したんだって。

さらに直近 1 か月では、Anthropic の開発者たちが Claude Fable 5・Claude Opus 4.8・dynamic workflows を使って、数万〜数十万行規模のパッケージを 10 個も移行したそうだよ。

今までどうだったの？

こういう言語間の移植って、これまでは数年がかりの一大プロジェクトになりがちだったの。書き直す量が膨大な上に、元のコードと同じ挙動をすることをちゃんと保証しなきゃいけないから、人手だけでやろうとするとコストが見合わなくて、ずっと後回しにされがちだったんだよね。

Mike さんのチームもまさにその悩みを抱えてたよ。社内ツールを Python のツールチェーンでビルドすると、1 プラットフォームあたり約 8 分、リリースのたびにビルドマトリックス全体で合計 30 分も待たされてたんだって。移行後は、同じビルドがたった 2 秒に短縮されて、バイナリの起動も 6 倍速くなって、専用のデプロイパイプラインまで廃止できたそうだよ。

これで何が変わるの？

これまで「数百万ドル規模の投資が必要」で塩漬けにされてた大規模移行が、AI エージェントを使えば数十万〜数百万ドル程度のコストで現実的に狙えるようになったの。ずっと後回しにしてたレガシーコードベースの移行を、あらためて検討し直すきっかけになりそうだよ。

しかもこの記事に合わせて、実際に使えるオープンソースの migration starter kit も GitHub で公開されてるの。自分のプロジェクトに合わせてルールブックや依存関係マップの作り方を試せるから、興味があるチームは早速触ってみられそうだね。言語移植じゃなくてフレームワークのアップグレードやレガシーの現代化がしたいときのために、関連の code-modernization プラグインも用意されてるよ。

深く潜ってみよう

記事で紹介されてる移行プロセスは、大きく 6 つのステップに分かれてるよ。

その前提として、元のコードと移行後のコードを同じ土俵で評価できる「審判(judge)」を用意するのが大事なんだって。既存テストのうち外部呼び出しとして書き直せるものと、内部実装に依存してて移植できないものを Claude で仕分けして、後者は両方の言語で動く形に書き換える。さらに、わざと壊したコードに対してちゃんと失敗することまで確認して、審判自体の信頼性を検証するんだって。

• ステップ 1: ルールブック(型やイディオムの対応表)・依存関係マップ・ギャップインベントリ(新しい言語で新たに必要になる設計。たとえば Rust の所有権管理や TypeScript のインターフェース定義)を作る
• ステップ 2: 数ファイルだけで試す「ミニ移行」でルールをストレステストする。Jarred さんはこの段階で、1,448 ファイル全体に展開してたら大惨事になってたはずの重大な問題を 2 つ見つけたんだって
• ステップ 3: 全体を翻訳する。実装役のエージェントと、別コンテキストを持つ 2 体の対抗的レビュアーに分けて、レビュアー同士の意見が割れたら 3 体目が裁定する仕組み。同じミスが繰り返し見つかったら個別ファイルを直すんじゃなくて、ルールブックに 1 文加えて該当バッチをまるごと再生成するの
• ステップ 4〜6: コンパイル・実行・挙動の一致確認。コンパイラのエラー一覧やスモークテストのクラッシュ、テストスイートの失敗が、そのまま次にやるべき作業リストになる。ビルドをむやみに並列実行させず、専用の「ビルドデーモン」がパッチをまとめて 1 回だけ再ビルドする仕組みも工夫のひとつだよ

実装作業には軽量なモデル、レビューやルール作成には大きめのモデルを使い分けて、トークン消費を最適化してるのもポイント。Mike さんのメインの移行作業だけで 2,700 万トークンを使ったそうだよ。

気になる移行後の中身も公開されてて、Bun の Rust 版はコード全体の約 4 パーセントが「unsafe」ブロック(主に C/C++ との境界にある 1 行だけのポインタ操作)なんだって。それでも、2,000 回ビルドを繰り返すベンチマークでメモリ使用量が 6,745 MB から 609 MB まで減って、バイナリサイズも Linux・Windows で 19 パーセント小さくなって、HTTP サーバーなど実際のワークロードでは 2〜5 パーセント速くなったそうだよ。

まとめ

• Anthropic が Claude Code で実施した大規模コード移行の事例とやり方を Claude Blog で公開
• Bun(Zig → Rust): 100 万行を 2 週間弱で移行、既存テスト 100 パーセント通過、リグレッション 19 件も全部修正、コストは API 換算で約 16 万 5000 ドル
• 社内ツール(Python → TypeScript): 16 万 5000 行を 1 週末で移行、ビルド時間を 30 分から 2 秒に短縮
• ルールブック作り → ストレステスト → 全体翻訳 → コンパイル・実行・挙動確認、という 6 段階のプロセスと、対抗的レビュー・機械的な検証がカギ
• オープンソースの migration starter kit も公開済み

ずっと後回しにしてたレガシーコードの大規模移行を検討中のエンジニアリングリーダーや、AI エージェントの実践的な運用パターンを知りたい開発者にぴったりの記事だよ！