「100万行コード移行は4年がかり」はもう昔話 Claude Codeで「2週間」に縮める6ステップ／ベストプラクティス：JavaScriptランタイム「Bun」のコードベースをZigからRustに移行（1/3 ページ）

Anthropicは、本番コードベースを別の言語に移植する大規模なコード移行プロジェクトをどのように実施しているかを解説したブログ記事を公開した。

[＠IT]

　Anthropicは2026年7月16日（米国時間）、本番コードベースを別の言語に移植する大規模なコード移行プロジェクトについて解説したブログ記事を公開した。同社の開発者がAIコーディングエージェント「Claude Code」を用いて最近成功させたプロジェクトの事例を交えてステップ・バイ・ステップのプロセスを紹介している。

　こうしたコード移行はつい最近まで、数年がかりの取り組みだった。だが、Anthropicの開発者は2026年6月に、「Claude Fable 5」「Claude Opus 4.8」、Claude Codeとその「動的ワークフロー」機能を使い、数万〜数十万行規模の10のコードパッケージを移行した。

　Anthropicは、これらの移行プロジェクトから得た教訓を基に採用している6段階のステップと、これらの教訓から一般化したベストプラクティスを示している。それらの核心となる洞察は、「コードを修正するのではなく、コードを生み出したプロセス（ループ）を修正する」というものだ。

　これらの解説では、10のコード移行プロジェクトのうち、以下の2つの事例を随時取り上げている。

コード移行の期間を4年短くできた理由

代表的な移行事例：Bun

　Anthropicのテクニカルスタッフメンバー、ジャレッド・サムナー氏は、Claude Codeを使ってJavaScriptランタイムの「Bun」のコードベースを「Zig」から「Rust」に移行した。同氏は、Anthropicが最近買収したBun社の共同創業者だ。この移行プロジェクトでは、2週間足らずで約100万行のコードが生成され、マージ前にBunのテストスイートが100％、CI（継続的インテグレーション）で合格した。

　マージ後に19件の回帰バグが発生したが、全て修正された。Rust版Bunは2026年6月にClaude Codeに組み込まれた。

サムナー氏による100万行のプルリクエスト（提供：Anthropic）

代表的な移行事例：Anthropic社内ツール

　Anthropic Labsの共同リーダーを務めるマイク・クリーガー氏は、2026年6月のある週末に、「Python」のコードベースを16万5000行の「TypeScript」に移行した。このプロジェクトでは数百のエージェントが使用され、8つのフェーズゲートが設けられ、3回の敵対的レビューを経て、最後に全コマンドの出力を元のPython版と比較する整合性チェックが行われた。

100万コード移行の期間を4年分、短縮

　コード移行は、より小さく、より速く、より安全なシステムをもたらす。その一方で、従来は膨大な時間とコストがかかる、リスクの高い巨大プロジェクトだった。新旧の2つのコードベースを何年も並行維持しても、結局、90％程度の一致に到達することしかできない恐れがあった。だが、今では工数が大幅に低減しており、最悪の場合でも、ブランチを削除してやり直せば済む。

　コストも大きく下がった。100万行規模の移行に、4年がかりで300万〜400万ドル（4億7747万7000〜6億3661万2000円《1ドル＝159円換算、以下同》）を投じる必要はもうない。

　ただし、依然として一定のコストがかかる。Bunの移行では、キャッシュされていない入力トークン59億、出力トークン6億9000万が消費され、これはAPI料金換算で約16万5000ドル（2626万円）に相当した。クリーガー氏の移行プロジェクトでも、移植の主要部分で2700万トークンが使用された。

　それでも、こうしたコストは、以前と比べれば格段に低い。それに見合う移行のビジネスメリットは、もはや「存続に関わる問題の解決」ではない。例えば、「メモリバグの修正が何度も繰り返されている」「慢性的なボトルネックが1つある」といった程度の問題でも、それを解決することは、移行の正当な理由となり得る。

コンパイルの所要時間を約2秒に

　クリーガー氏のプロジェクトでは、コンパイル時間の改善が移行の狙いだった。同氏のチームが担当するツールのバイナリをPythonのツールチェーンでビルドすると、1プラットフォーム当たり約8分かかり、リリースごとにビルドマトリックス全体で30分の待ち時間が発生していた。

　移行後は、同じコンパイルの所要時間は約2秒となり、バイナリの起動は6倍高速になり、チームは専用のデプロイ（展開）パイプラインも廃止できた。

コード移行の時間、労力、コストの大幅な削減の理由

　こうしたコード移行の時間、労力、コストの大幅な削減は、Claude Fable 5やClaude Opus 4.8といった高度なモデルを活用することで可能になっている。Anthropicは、大規模なコード移行は以下の理由から、これらの高度なモデルが効果を発揮するユースケースになっていると説明している。

• 作業をファイルなど数千のアイテムにわたって並列化できる
• 旧コードがモデルにとって明確で包括的な仕様書になる
• テストスイートが「組み込みの判定システム」となり、エージェントが何日でも検証を繰り返せる
• コンパイルエラーやテストの失敗がそのまま次のタスクになり、キューが自動的に生成される
• レビュワーが全ての発見事項について、その根拠であるルールを明記するので、ルール違反がキューの項目になる。エージェントがエッジケースに遭遇した場合、その修正が共有ルールになるので、逸脱が入り込む余地がない

コード移行プロジェクトの前提条件：信頼できる「判定システム」を用意する

　Anthropicは、コード移行プロジェクトの前提条件として、確固たる基準に基づく「判定システム」（※）を確立することを挙げる。これがなければ、終了条件も成功の尺度も定まらないからだ。

※Anthropicは、「judge」（ジャッジ、審判）と呼んでいる。

　この判定システムは、元のコードと移行先のコードを同等の条件で評価できなければならない。元の言語で書かれたテストスイートは、移行先のコードには存在しない内部関数に依存していることが多い。

　この判定システムを構築するポイントはAnthropicによると、以下の通り。

• Claudeを使って、「どのテストが外部呼び出しとして表現可能か」「どのテストが移行できない内部関数に依存しているか」を特定する。
• 外部呼び出しとして表現できるテストを、元のコードと移行先のコードの両方で実行可能なアサーションに変換する。敵対的エージェントを用いて、書き換えられたテストによってアサーションの信頼性が低下していないことを検証する。
• 判定システムを元のコードに対して実行し、合格することを確認する。次に、意図的に破損させたコードに対して実行し、失敗することを確認する。

　サムナー氏は、ZigでもRustでもないTypeScriptで書かれた大規模なテストスイートを再利用できた。それがなかったクリーガー氏は、7つの実用的なシナリオから成るパリティ（検査）ハーネスを構築し、動作の変化を全て修正すべきバグとして扱った。

コード移行プロセスの全体像（提供：Anthropic）