「AIで数週間に短縮」のはずが進まない コードモダナイゼーション、真のボトルネックと6ステップ：最大の効果はコスト削減ではない

Anthropicは、AI駆動の大規模なコードモダナイゼーションプロジェクトに向けた準備の進め方をまとめたブログ記事を公開した。

[＠IT]

　Anthropicは2026年9月23日（米国時間）、AI駆動の大規模なコードモダナイゼーションプロジェクトに向けた準備の進め方をまとめたブログ記事を公開した。顧客プロジェクト事例から得たベストプラクティスを交えて解説している。

ボトルネックは組織のリソース動員

　かつては数年がかりだったコードモダナイゼーションが、今では数カ月、あるいは数週間で完了できるようになった。だが、組織がそのために行う作業は、多くの場合変わっていない。例えば、銀行の重要システムに対する変更は全て、変更管理、レビュー、承認を経なければならない。

　こうしたプロセスは、人間がコードを変更し、差分をレビューすることを前提としている。だが、AIエージェントがコーディングのスピードを加速させると、ボトルネックはコーディングから、その検証、修正、展開などに関わる組織のリソース動員に移る。

　Anthropicは、コードモダナイゼーションの前に必要な準備を、以下の6つのステップで説明している。

1. ターゲットを定義する
   モダナイズ後のコードに求められる技術スタックと、その動作
2. 「承認基準」を作成する
   モダナイズ後のコードにおける変更がターゲット定義に合致していると見なされる条件
3. 「プロモーションポリシー」を策定する：承認された変更を本番環境に反映させる経路
4. 前提条件を整える
   環境、CI/CD（継続的インテグレーション／継続的デリバリー）、レビュー体制、承認プロセス
5. エージェント型ワークフローを構築、改良する
   「Claude Code」のカスタム動的ワークフロー機能によって並列サブエージェントにモダナイゼーション作業を分担させる。カスタム動的ワークフローは、ターゲット、承認基準、プロモーションポリシーを軸として構築される
6. モダナイゼーション
   コードベースのごく一部でワークフローをエンドツーエンドで検証し、その上でスケールさせる

ステップ1：ターゲットを定義

　ターゲットとは、モダナイゼーションで目指す最終状態だ。以下の3つのいずれかのタイプに分類される。

タイプ	概要	どのような場合に選択すべきか	ターゲット
アップリフト（強化）	同一スタックでバージョンアップする（C++11 → C++20など）	スタック自体に問題はないが、バージョンが古くなっている場合（サポートが終了したランタイム、未修正のセキュリティ問題、アップグレードできなくなった依存関係など）	新しいランタイムのバージョンとパッケージのセット
トランスフォーム（変革）	既存の動作を維持したまま、別のスタックで書き換える（COBOL → Javaなど）	解決すべき問題がスタックにあるが、既存システムの動作は信頼できる場合	アップリフトに必要な全ての要素に加え、新しいコードが準拠しなければならない言語、フレームワーク、アーキテクチャ規約
リイマジン（再構築）	新しいアーキテクチャでゼロから再構築し、動作も変更する	コードとともに動作も変更する必要がある場合	トランスフォームに必要な全ての要素に加え、新システムの動作仕様書
モダナイゼーションの3タイプ

　どのタイプを選ぶかは、しばしば議論になる。本番環境に最も近い担当者は、リスクを抑えるために動作を維持するトランスフォームを選ぶ傾向がある。一方、長年コードベースに携わってきたエンジニアや、ビジネス部門のステークホルダーは、技術的負債の解消や要件の追加を伴うリイマジンを望むことがある。早期に合意しておくことが、後の段階で個別の変更をめぐる議論の防止につながる。

　現行システムの把握は、コードモダナイゼーションの良い第一歩になる。どの部分を変更し、どの部分を廃止すべきかが分かり、未知のビジネスロジックが見つかることも多いからだ。Anthropicは、こうした調査の多くは「Claude」に任せることができ、足りない部分は業務ユーザーや開発者へのインタビューで補えるとしている。

　例えば、Claude Codeのコードモダナイゼーションプラグインが備える「assess」「map」「extract-rules」といったコマンドは、ソースコードの該当箇所を示しながらビジネスルールを抽出し、エンジニアがレビューできるようにする。

コードモダナイゼーションプラグインによるインタラクティブな依存関係マップの例（提供：Anthropic）

　組織は、コードモダナイゼーションプロジェクトに取り組む意義も明確にしておく必要がある。Anthropicの経験では、最も重要な効果はコスト削減ではなく、リスクの低減であることが多い。例えば、未修正の脆弱（ぜいじゃく）性は、事業そのものを危うくするほどのセキュリティ侵害やシステム停止を招きかねない。

　通常、このプロジェクトの主な課題は、システムを所有するチームと、それに依存するチームのコミットメントを得ることだ。経営層レベルでビジネスケース（投資対効果検討書）について合意し、プロジェクト目標を設定すれば、これが容易になる他、ステップ2（承認基準の作成）、ステップ3（プロモーションポリシーの策定）にも役立つ。

ステップ2：承認基準を作成

　承認基準とは、モダナイズ後のコードにおける全ての変更が満たすべき条件の集合だ。変更がターゲット定義に合致していることを示す累積的な証拠が最も強くなるように選定する必要がある。各条件は、人間が介在せずに検証できるものにする。そうすれば、自動ワークフローによって変更が合格するまで反復で処理したり、条件を満たせない場合に人間のレビューに回したりできる。

　承認基準に何を盛り込むかはターゲットによって左右されるが、通常は、以下のリストから選定される。

• 元のテストスイートと、モダナイゼーション過程でClaudeが作成したテストが全て合格する
• テストカバレッジとパフォーマンスが、合意された範囲を満たす
• Claudeによる独立した敵対的レビューで重大な問題が見つからない
• ユーザーインタフェースにおいて、Claudeによるコンピュータ操作で回帰が発生しない
• 現行バージョンとターゲットバージョンが、同じ入力から同じ出力を生成する
• 永続化された状態と通信フォーマットが、現行バージョンとターゲットバージョン間で正常に往復する
• ステージング環境でエラー率、レイテンシ（遅延）、アラートに回帰が発生しない
• 静的解析とセキュリティスキャンで新たな問題が見つからない
• コンパイル対象の場合、ビルドにエラーがなく、型チェックを通過する

　Anthropicは、承認基準の設計を、モダナイズ後のコードにおける変更をレビューして本番環境に移行させる担当者と共同で行うことを勧めている。設計段階において、既存コードを現在使用している開発者、ユーザーグループ、ビジネスリーダーの意見を取り入れる重要性も強調している。

　これらのコード変更がターゲット定義に合致しているかどうかのチェックを、承認基準に基づいて、何に照らしてどのように行うかは、モダナイゼーションのタイプによって異なるとしている。

• アップリフト
  既存のテストスイートが承認基準の中核となり得る。これを基に、変更と既存システムのコードベースを比較し、整合性をチェックする
• トランスフォーム
  変更と既存システムのコードベースを比較し、整合性をチェックするが、既存のテストスイートが新しいスタックで動作することはまずない。本番トラフィックのリプレー、新旧間の差分テスト、本番環境と並行したデプロイ（展開）などによってチェックを行う
• リイマジン
  承認基準は、動作仕様書に基づいて作成される。動作仕様書を基に作成されたテストや、Claudeによる独立した敵対的レビュー、新システムが旧システムの動作を維持しているかどうかの差分チェックを組み合わせて、変更をチェックする

　レガシーシステムは、テストカバレッジが低く、テストが不安定で、テレメトリーも乏しいことが多い。Anthropicは、強固な承認基準の維持が難しい場合の有効な対策として、Claudeを用いて、本番環境と並行する環境の立ち上げや、リプレーハーネスの構築、テストの追加作成を挙げている。

ステップ3：プロモーションポリシーを策定

　AIエージェントは、人間が差分を一つずつレビューできるペースをはるかに上回る速さで変更を生成する。

　そこでAnthropicは、モダナイズ後のコードにおける変更を人間が効率的かつ効果的にレビューできるように、レビュー担当者と協力してプロモーションポリシーを策定し、組織の変更管理プロセスに可能な限り組み込むことを勧めている。

　プロモーションポリシーとは、「各変更を人間がどこまで深くレビューするか」を定めた段階的なレビュー経路だ。その主なルールは以下の通り。

• 影響範囲とエージェントの信頼度によって変更を階層化し、クリティカルパスには、人間による完全なレビューを残す
• 同じ種類のフラグが繰り返し発生する場合は、一件ずつレビューするのではなく、エージェントのワークフローや承認基準自体で原因を修正する
• 出力形式をレビュー担当者とともに設計し、レビューの迅速化につなげる
• 対象領域の専門家（SME）の時間を効果的に割り当て、最もリスクの高い変更のレビューを直接担当できるようにする

　これらのルールにより、SMEのリソースをプロジェクトの早い段階に重点的に投入する。SMEによる早期のフィードバックは、承認基準とワークフローの調整に生かされ、サンプルに対する承認は、信頼度の高い変更のレビューを簡略化する根拠になる。

変更が生成されてから本番環境に反映されるまでの経路（提供：Anthropic）

　プロモーションポリシーは、スピードとレビューの深さのバランスも考慮して策定すべきだ。例えば、ランタイムのサポート終了のような厳格な期限から逆算してスケジュールが設定されたコードモダナイゼーションプロジェクトでは、人的レビューの負担を緩和し、変更ごとのリスクの増大を受け入れるという明確な合意が必要になる。

　Anthropcは、これまでのプロジェクトの経験から、いずれにしても、プロモーションポリシーに関する指示は、組織のトップから出されるのが最善だと指摘する。本番環境に到達したバグの責任が、変更を承認した個人に押し付けられるのではなく、組織内で共有されるように、事前に合意しておくことが望ましいとも述べている。

ステップ4：前提条件を整える

　このステップの多くは、プラットフォーム、品質保証（QA）、セキュリティなど、モダナイゼーションプロジェクト以外のチームを介して行われる。各チームには固有のバックログや承認プロセスがあるので、早い段階で話し合いを始めるべきだ。整えるべき主な前提条件には以下のようなものがある。

• 環境
1. ワークフローを実行するための専用リモートホスト（Claudeがコードベースや関連ソースにアクセスできる）
2. 承認基準で要求されるテスト実行能力
3. 本番環境のテレメトリー、本番環境と並行する環境、リプレー用本番データ
• コードベースとCI/CD
1. コードベースの依存関係マップ（ビルドおよびコンパイルログ、インポート分析、実行時トレースに基づく）
2. 必要に応じてCI/CDに追加できる互換性チェック
3. 現行コードをそのままモダナイズする場合、合意済みのコードフリーズ方針
• チームとレビュー
1. コードベースに依存する他チームからの、参加方法に関する合意
• セキュリティとコンプライアンス
1. ソースコード用に承認されたClaude Codeのモデルアクセス経路
2. エージェント型ワークフローに対する最小権限アクセス
3. モダナイゼーションブランチからのシークレットおよびPII（個人を特定できる情報）の削除またはマスキング
4. 全ての変更を追跡可能にし、プルリクエストをエージェントのトランスクリプトおよび承認基準の証拠にリンクさせる
5. 新しい依存関係のライセンスと脆弱性チェック

ステップ5：エージェント型ワークフローを構築、改良

　Anthropicは、Claude Codeを使って、コードベースをモダナイズするためのカスタム動的ワークフローを作成することを推奨している。

　そのためには、まずClaude Codeのコードモダナイゼーションプラグインによってワークフローに必要な要素を、Claudeがアクセス可能なファイルシステムまたはMCP（Model Context Protocol）上に配置する。その中にはターゲット、承認基準、プロモーションポリシー、コードベース、ドキュメントや、承認基準に必要なデータソースやツールが含まれる。

　これらを配置すれば、モダナイゼーションワークフローは容易に作成できる。作成したワークフローは、コードベースの小さな部分に適用して改良する。その際にSMEに、生成された変更内容、エージェントの処理、および「承認基準の要件が満たされた」という証拠をレビューしてもらうとよい。問題が見つかった場合は、個々の変更ではなく、ワークフロー自体を修正すべきだ。

ステップ6：モダナイゼーション

　パイロットとしてコードベースの小さな部分を対象に、プロモーションポリシーを通じてコード変更のレビューと反映を含め、モダナイゼーションをエンドツーエンドで完了させる。修正コストが低いうちに問題を解消し、確信が持てるまでこのプロセスを繰り返した後で、コードベース全体に拡大する。

　トランスフォーム型と、リイマジン型のモダナイゼーションでは、既存システムと並行してターゲット環境を構築し、完了後に切り替える。一方、アップリフト型では、稼働中のコードベースを直接モダナイズすることも可能だ。

コストの見積もりと抑制

　Anthropicは、モダナイゼーションの主なコスト要因として、コードベースのうち読み込む部分と変更する部分の量、承認基準の複雑さ、承認基準が要求する新規テストの作成量や既存テストの修正量、モダナイゼーションプロジェクト中に他チームが行うマージに伴う調整作業の量を挙げている。

　パイロット時のトークン使用量を測定し、それを基に全体のコスト下限を見積もることを推奨している。パイロット時の測定結果は、どのワークフロー部分が多くのトークンを消費しているかを知る手掛かりにもなる。こうした部分は効率化する余地がある。

　Anthropicは、モデルの使い分け方法も提案している。承認基準に基づく大量の機械的な検証作業には、「Claude Sonnet」のように機能とコストのバランスが取れたモデルを使い、高度な変換や敵対的レビューにはより高度なモデルを割り当てるというものだ。ただし、安価なモデルで何度も試行を繰り返すと、高価なモデルを1回実行するよりもコストがかさむ場合もあると注意を促している。

次のプロジェクトに生かせる資産

　Anthropicは、モダナイズされたコードベースは成果の一つに過ぎないと指摘する。ワークフロー、承認基準、プロモーションポリシー、実装された変更の証拠履歴といった成果も、再利用可能なプレーブックとして体系化し、次のアップグレードや書き換えに備えるべきだと述べている。