Anthropic流コード移行6ステップ：Bunの百万行を2週間でZigからRustへ
- 本番環境で動くコードベースをまるごと別言語で書き換えるには、業界相場で4年、300～400万ドルかかり、途中で頓挫するリスクも高いとされます。Anthropicの社員はこの1か月で10個のコードパッケージを移行しました。Bunでは100万行を2週間足らずで移行し、マージ前の既存テストはすべてグリーンでした
- この手法の核心は一つです。コードではなく、そのコードを生み出す本番プロセス（ループ）を直す。同じミスが数十のファイルで繰り返されるなら、ルールブックに一文を加え、該当箇所をまとめて作り直します。ファイルを1つずつ手直しするのではありません
- 着手前に必ず「判定役」を作ります。既存テストから新旧両方で実行できるものを選び、アサーションとして書き直します。さらに、わざと壊したコードで検証します。壊れたコードを検知できなければ、判定役とは呼べません。これがなければ「いつ移行が終わったか」を判定できません
- 実装の細部はそのまま拝借できる。作業キューは毎回ディスクから再計算するので中断しても続行可能。実装は小型モデル、評価は大型モデルが担当。2つの評価は互いに独立したコンテキストを持ち、意見が割れたら3体目のAgentが裁定する。訳せない箇所は統一して
// TODO(port)を打って後回しにする - コストと成果はいずれも数字で示されています。Bunの移行では未キャッシュ入力トークン59億＋出力トークン6.9億を使い、API価格換算で約16.5万ドルです。Mike Krieger のプロジェクトでは、移行後にビルド時間が8分から約2秒へ短縮され、プログラムの起動が6倍速くなり、デプロイパイプラインを丸ごと1本廃止しました
1か月で10個のコードパッケージを移行
100万行のコードを別言語に書き換え、2週間で完了、マージ前の既存テスト一式はCIで全部グリーンだった。
これはAnthropic公式アカウントのClaudeDevsが発表した実務記事で、この1か月で社内がClaude Codeを使ってどうコード移行を行ったか、本番環境で動くコードベースを丸ごと別言語に移した経緯を語っています。テンプレートごと全部さらけ出して誰でも真似できるようにしたもので、使われたのはClaude Fable 5、Claude Opus 4.8、Claude Codeのdynamic workflowsです。
この1か月間で、Anthropicの開発者は10個のコードパッケージの移行を完了しました。規模は数万行から数十万行までさまざま。記事では、そのうちの2件だけが詳しく紹介されています。
Bunの移行を手がけたのはJarred Sumner、Bunの共同創業者で、現在はAnthropicのテクニカルスタッフです。Python側を手がけたのはMike Krieger、Instagramの共同創業者で、現在はAnthropic Labsの共同責任者です。
以前はなぜ誰も手を出さなかったのか
Jarredが当初Zigを選んだ理由は、CレベルのパフォーマンスとシンプルさをJarredの言葉を借りれば、オークランドの狭いアパートで、大規模言語モデルすらまだない時代に、たった1人でBunを1年かけて書き上げる前提として両立できたからです。シンプルさには代償があり、その代償はずっとそこにありました。Bunのコマンドラインツールは現在月間ダウンロード数が1000万を超え、Claude Code内部でも大量に使われています。
ほんの前四半期まで、その代償はロードマップを凍結し、いくつもの四半期にまたがるプロジェクトにリソースを賭けるほどの理由にはなっていませんでした。
- 4年サイクル、300～400万ドルのエンジニアリングリソース
- 期間中はロードマップ凍結
- 2つのコードベースを何四半期、あるいは何年も並行維持
- 最悪の結果は90%の類似度止まりで、着手前より厄介になる
- 数万～数十万ドル規模、それでも本物のコストではある
- 最悪の結果はブランチを削除してやり直すだけ
- 着手理由に「移行しないと立ち行かない」はもう不要
- changelogに1年放置されたメモリバグの修正パッチ、あるいは長年のボトルネックがあれば十分
Mikeのプロジェクトはまさにボトルネックに背中を押されて始まりました。彼のチームが手がける内部ツールは単一実行ファイルにパッケージしてユーザーに配布する必要があり、Pythonのツールチェーンはプラットフォームごとにビルドで約8分かかっていました。ビルドマトリクス全体を回すと、リリースのたびに30分待つ羽目になっていました。TypeScriptへの移行後、同じビルドが約2秒に短縮され、実行ファイルの起動は6倍速くなり、チームは独立したデプロイパイプラインを丸ごと退役させました。
同じミスが繰り返されたら、ルールを直す
記事全体でいちばん価値のある一文はこれです。
The core insight is that you don't fix the code. You fix the process (loop) that produced the code.核心となる認識は、コードを直すのではなく、そのコードを生み出したプロセス（ループ）を直すということだ · ClaudeDevs
これを具体的な行動に落とすとこうなります。評価Agentが数十のファイルで同じミスを繰り返し検出したなら、手を伸ばす先はそれらのファイルではありません。ルールブックに一文加え、影響を受けたそのバッチをまとめて再生成する。ルールブックはプロセス全体を通じて分厚くなる一方で、コードが手作業でパッチを当てられてルールブックに合わせられることは一切ありません。