9月23日、Anthropicが「How to prepare for AI-driven code modernization projects」と題した記事を公開した。この記事では、AIエージェントを活用したレガシーコードのモダナイゼーションプロジェクトを成功させるための6ステップの準備プロセスについて詳しく紹介されている。
かつて「数年がかりの全社プロジェクト」として見積もられていたコードモダナイゼーションが、AIエージェントの登場によって数週間〜数ヶ月で完了できるようになった。しかし、変更ごとの変更管理・レビュー・承認プロセスは以前と変わらない。Anthropicのフォワードデプロイドエンジニア（Forward Deployed Engineer：顧客の現場に入り込んで技術支援を行うチーム）が、実際のエンタープライズ案件から得た知見として、プロジェクト開始前に企業が整備すべき6つのステップを公開した。
3種類のモダナイゼーションを最初に定義する
記事が最も強調するのは、「何をゴールとするか」を最初に明確化せよという点だ。ゴールの定義を曖昧にしたまま進めると、「この変更は正しいのか？」という議論が後から繰り返し浮上する。
モダナイゼーションは以下の3種類に分類される。
| 種別 | 内容 | 選択する場面 |
|---|---|---|
| Uplift | 同一スタックのバージョンアップ（例：C++11→C++20） | ランタイムのEOL、未パッチの脆弱性 |
| Transform | スタック変換・振る舞いは維持（例：COBOL→Java） | スタック自体が問題で、振る舞いは信頼できる |
| Reimagine | 新アーキテクチャへのグリーンフィールド再構築、振る舞いも変更 | コードと同時に仕様変更が必要 |
現場（プロダクションを持つチーム）はリスクを抑えるためTransformを望み、コードベースに長く付き合ってきたエンジニアや事業部門はReimagineを望む傾向がある。いずれの立場も合理的だが、この合意を先送りにするほど後の工程が詰まる。
ゴール定義の補助として、Claudeのコードモダナイゼーション向けツールのassess・map・extract-rulesコマンドを使うと、Claudeが依存関係をマッピングし、誰も覚えていないビジネスロジックを発掘・文書化できる。ただし、Claudeの自動探索だけでは捉えきれない振る舞いもあるため、業務ユーザーや開発者へのインタビュー、内部ドキュメントで補完することが推奨されている。
「証明書（Certificate）」の設計がプロジェクト全体の品質を左右する
6ステップの中で最も実践的な示唆が多いのがステップ2：Certificateの定義だ。
Certificateとは、「変更がターゲット状態として正しい」と見なすための条件セットである。エージェントがループで反復できるよう、各条件は人間の介入なしにチェック可能でなければならない。
代表的な条件として以下が挙げられている。
- 元のテストスイートがパスする
- モダナイゼーション中にClaudeが書いたテストがすべてパスする
- テストカバレッジが合意した閾値を満たす
- パフォーマンスベンチマークが許容範囲に収まる
- Claudeによる独立した敵対的レビュー（新規コンテキストウィンドウ）でブロッキング問題が出ない
- 本番同等のステージング環境での一定期間の稼働でエラー率・レイテンシ・アラートに回帰がない
- 静的解析・セキュリティスキャンで新規の指摘がない
重要な指針として記事が強調しているのは、「変更をレビューしてプロモートする人たちと一緒にCertificateを書け」という点だ。開発者・ユーザーグループ・事業リードが自分たちの基準をCertificateに反映できていれば、後の承認プロセスが軽くなる。
承認フロー（Promotion Policy）とリスクの事前合意
エージェントは人間チームがdiffをレビューできる速度をはるかに超えて変更を生成する。Promotion Policy（段階的なレビューパス）を事前に書き下ろし合意しておくことで、モダナイゼーションを現実的な期間内に完了できる。
実運用上のポイントとして以下が挙げられている。
- 変更を「影響範囲」と「エージェントの確度」でティアリングし、クリティカルパスは引き続き人間がフルレビューする
- 繰り返し出てくるフラグは個別レビューではなく、エージェントワークフロー・Certificateの修正で根本解決する
- SME（Subject Matter Expert）の時間は最もリスクの高い変更に集中させる
規制環境下では、承認者個人がリスクを抱えることへの抵抗が強い。記事はこの点について、「Promotion Policyは組織のトップから指示を出すべきで、本番に到達したバグの責任は承認者個人に帰属するのではなく共有される、という合意を事前に取り付けることが重要」と述べている。
ステップ4：前提条件の整備
ステップ4では、モダナイゼーション作業を実際に開始する前に環境・体制・権限の面を整えることを求めている。具体的には以下のような項目が対象となる。
- CI/CDパイプラインの整備：エージェントが生成した変更を自動でビルド・テスト・デプロイできる環境を用意する。既存パイプラインがモダナイゼーション規模の変更量に耐えられるか検証が必要だ
- レビュー体制の確立：Promotion Policyで定義したティアに応じたレビュアーのアサイン。誰がどのティアの変更を承認できるかを明文化する
- 各種承認の取得：セキュリティ・コンプライアンス・法務・インフラなど、モダナイゼーションチームの外にある複数の部門からの事前承認が必要になる。記事はこれを「プロジェクト開始後に取りに行くのでは遅い」と明示しており、立ち上げフェーズで並行して進めることを推奨している
この段階は純粋な技術作業ではなく、社内調整の色が強い。関係部門が多いほど時間がかかるため、早期から担当者を巻き込んでおくことが重要だ。
ステップ5：エージェントワークフローの構築と精緻化
ステップ5では、実際にAIエージェントを動かすワークフローの設計と反復的な改善を行う。記事はClaude Codeのダイナミックワークフローの活用を前提としており、コードベースを小さなパーティションに分割して並列サブエージェントに処理させる構成を推奨している。
具体的な設計指針として以下が挙げられている。
- コードベース全体を一括処理するのではなく、依存関係の境界に沿って分割する
- 各パーティションをサブエージェントが独立して処理し、Certificateの条件をクリアしたものから順次Promotion Policyに乗せる
- 初期のワークフロー実行結果を受けて、Certificate条件の閾値やパーティション分割の粒度を調整する「精緻化」のサイクルを回す
記事はこのステップを一度設定して終わりではなく、小規模な実行→結果の観察→ワークフローの修正を繰り返す反復プロセスとして位置づけている。
ステップ6：本番運用とスケールアウト
ステップ6は本番投入フェーズだが、記事が強調するのは「コードベース全体に一気に適用しない」という原則だ。まずコードベースの小さな一部でエンドツーエンドの動作を確認し、問題がないことを確かめてからスケールアウトする。
この段階で確認すべき点として以下が挙げられている。
- ステージング環境で問題なかった変更が本番環境でも期待通りに振る舞うか
- Certificate条件では捉えられなかった問題が本番トラフィックで顕在化しないか
- 小規模適用で得られたフィードバックをもとに、ワークフローやCertificate条件をさらに調整する
記事はこのフェーズを「最終段階」ではなく、ステップ5との往復が続くフィードバックループとして描いている。問題が見つかれば即座にワークフローを修正し、再度スモールスタートで検証する姿勢が求められる。
モダナイゼーションの最大の障壁は技術ではなく組織
記事全体を通じて一貫しているメッセージは、「エージェントが変更を生成するスピードは解決した。ボトルネックは今や、組織をその変更に動員することにある」という認識だ。
「やらない場合のリスク」——未パッチの脆弱性によるサイバー侵害、システムを理解できるエンジニアの減少——をビジネスケースの中心に置くことが、社内コンセンサス形成の現実的な手段として紹介されている。
詳細はHow to prepare for AI-driven code modernization projectsを参照していただきたい。
