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

[＠IT]

ステップ4〜6：コンパイル、実行、動作の照合

ステップ4〜6の概要（提供：Anthropic）

　ステップ4〜6では、同じループアーキテクチャを共有しており、人的判断の必要性が徐々に減っていく。

　ステップ4（コンパイル）は、コンパイルの規模や難易度によっては、エージェントが全く実行しない場合もある。サムナー氏は、ワークスペース全体に対してコンパイラを1回呼び出すオーケストレータスクリプトを使ってこれを実行した。その後、フィクサーエージェントが、敵対的レビューと並行してエラーリストを処理した。エラーリストの確認は、調整が必要な体系的な問題の発見に役立つ。

　ステップ5（実行）では、スモークテストで発生するクラッシュが、エラーリストと同様の情報源となる。ループの修正は、問題を分類することであり、ここでは、根本原因ごとに原因をグループ化し、敵対的サブエージェントにレビューさせる。

　最後のステップ6では、ファイルをシャーディングし、前提条件を整える段階で作ったテストスイートを実行して、2つのコードベースにおけるプログラムの動作を比較する。フィクサーエージェントが失敗したテストを検証し、敵対的レビュワーがその修正内容を確認する。

　こうしてフィクサーがパッチを作成すると、ビルドデーモンがそれらをバッチ処理し、再ビルドを1回行い、影響を受けたテストを再実行して、結果をフィードバックする。

　同じ失敗が多数のテストで繰り返される場合は、修正は上流へと移行する。バグの原因となったルールを修正し、そのルールに関わるファイルだけを再生成する。

　移行可能なテストスイートを持たないチームには、クリーガー氏のアプローチが参考になる。同氏はClaudeに、新しいコードベースと元のPythonコードベースの両方を対象に、7つの実用的なシナリオを実行して結果を比較するスクリプトを作成させた。失敗した各シナリオには専用の修正エージェントが割り当てられ、7つ全てが合格するまで、このループが繰り返された。

　その後、クリーガー氏はさらに一歩踏み込み、Claudeに独自のエンドツーエンドテストスイートを設計させ、夜間に自律的に実行させた。Claudeが不具合を修正し、4晩連続で再実行した結果、シナリオテストで予測できなかったささいな不具合も解消された。

　既存のテストスイートを継承できない場合は、元のコードベースを基準として、Claudeに作成させる手法があるということだ。

コード移行における6つのベストプラクティス

　Anthropicは、どのプロジェクトにも有効なベストプラクティスとして以下を挙げている。

1．このガイドをむやみに踏襲せず、プロジェクトに着手する前にClaudeを使って、個々の移行を計画する。

2．個別のコードの失敗に固執せず、全体的なパターンに注目する。個々の修正は、フィクサーエージェントのループ処理に任せる。

3．レビューは敵対的に、検証は機械的に行う。敵対的なレビューはタスクの長期実行を可能にし、多くの場合、トークンの消費に見合う価値がある。スクリプト（コンパイラ、diff、テストスイートなど）を判定システムとして活用する。

4．最大のモデルをあらゆる場面で使うのは禁物だ。トークンの消費はループに集中するので、ループは慎重に設計する必要がある。小規模モデルは、大量の実装ファンアウトをうまく処理できる。最大のモデルはレビュワーとして、あるいは他のエージェントが従うルールの記述に使用すべきだ。

5．人的リソースを初期段階で集中投入する。ルールブックの作成とストレステストが最も時間を要するからだ。それ以降の作業は、主にキューの処理に過ぎない。

6．作業キューを機械的で再開可能なものにする。「完了」とは「出力ファイルがディスク上に存在すること」と定義すべきだ。

　Anthropicは開発者に、これまで放置し続けてきたコードベースを選び、その移行がどのようなものになるかをClaudeに尋ねてみることを勧めて、ブログ記事を締めくくっている。なお、記事で解説した6つのステップを一般化したテンプレートとして、「Claude Code Migration Kit」というスターターキットもGitHubで公開している。