9月26日、Inside AI Newsが「Anthropic Outlines Six-Step Framework for AI-Driven Code Modernization」と題した記事を公開した。Anthropicのフォワードデプロイドエンジニア（顧客先に常駐して支援するエンジニア）が実際の大規模顧客事例をもとに整理した6ステップのフレームワークを、Inside AI Newsが取材・まとめたものだ。AIによるコードモダナイゼーション（レガシーシステムの現代化）を組織として成功させるうえで、エンジニアリング以上に重要な「承認フロー設計」の考え方が詳しく紹介されている。
ボトルネックはAIではなく「組織」にある
このフレームワークで最も重要な知見は、タイトルよりも本文中のこの一文に凝縮されている。
AIエージェントがコード生成を加速すると、ボトルネックは「変更を作ること」から「組織をその変更の周りに動員すること」へ移る。
銀行・保険会社・政府機関では、サポート切れのランタイム上で動く古いシステムと、それを理解できるエンジニアの減少という二重の問題を抱えている。パッチ未適用の脆弱性が一つあるだけで、事業に深刻な影響を与えるインシデントにつながりかねない。にもかかわらず、予算の見積もりが難しく、現状維持の慣性が働く。
このフレームワークはその「組織的慣性」をどう崩すかに多くの紙面を割いている。
6ステップの概要
Anthropicのエンジニアが示した6ステップは以下の通りだ。
- ターゲットを定義する（移行後の目標状態を合意する）
- サーティフィケートを定義する（変更が「正しい」と判断するための条件セットを決める）
- プロモーションポリシーを設定する（変更のレビュー経路と承認フローを事前に文書化する）
- 前提条件を整える（インフラ・QA・セキュリティ等、関連チームとの調整）
- エージェントワークフローを構築する
- モダナイゼーションを実行する
記事の解説は6ステップ全体を均等に扱うのではなく、組織的ボトルネックに直結するステップ2と3の設計思想に重点を置いている。ステップ4〜6は「前提が整って初めて意味を持つ実装フェーズ」として位置づけられており、本稿でもその比重に沿って紹介する。
「サーティフィケート」が実質的な契約になる
ステップ2のサーティフィケートとは、「この変更が正しい」と判定するための条件セット（証明条件の集合）のことだ。重要なのは、すべての条件を人間なしに機械的に検証できるよう設計することだ。エージェントはサーティフィケートを満たすまで反復し、満たせない場合のみ人間にエスカレーションする。
サーティフィケートに含まれうる要素は以下のとおりだ：
- 元のテストスイートの通過
- Claude自身が記述したテスト
- カバレッジ閾値
- パフォーマンスベンチマーク
- フレッシュなコンテキストウィンドウでのClaudeによる独立した敵対的レビュー
- 静的解析スキャン
モダナイゼーションの種類によって何を「正解」と比較するかが異なる。既存動作を維持するアップリフト（言語バージョンアップ等）ならオリジナルのテストスイートが軸になる。トランスフォーム（別スタックへの移行）では元のテストスイートが新環境で動かないため、本番トラフィックのリプレイや差分テスト、本番並行稼働が主役になる。最も難しいのはリイマジン（仕様から再構築）で、比較基準が「既存システム」ではなく「仕様書」になるため客観的な差分が取りにくい。
レガシーシステムはテストカバレッジが薄く、テストが不安定で、テレメトリも少ないことが多い。Anthropicのエンジニアは「サーティフィケートを強固にするのが難しい場合、Claudeを使って不足している証拠を作ること自体が最も有益な作業の一つだ」と述べている。本番並行環境の構築、リプレイハーネスの整備、テストの追加記述がその具体例として挙げられている。
プロモーションポリシーは「トップダウン」で決める
ステップ3のプロモーションポリシーは、変更の影響範囲とエージェントの信頼度に応じてレビューの深さを段階的に定めるものだ。エージェントは人間チームがdiff単位でレビューできる速度をはるかに超えて変更を生成するため、この階層化が不可欠になる。
Anthropicのエンジニアが特に強調しているのが、承認権限の所在を事前に組織上層部から指示しておくことだ。規制環境では、個々の承認者が「自分が署名したバグが本番に出た場合の責任」を恐れて承認を躊躇する。結果として変更が滞る。責任を「承認した個人」ではなく「組織として事前合意したポリシー」に帰属させることで、このボトルネックを解消するという考え方だ。
前提条件の整備・ワークフロー構築・実行（ステップ4〜6）
ステップ4の前提条件の整備では、インフラ・QA・セキュリティといった関連チームとの調整を指す。モダナイゼーション着手前にこれらの体制を整えておかなければ、エージェントが生成した変更を受け入れる側のプロセスが追いつかなくなる。
ステップ5のエージェントワークフローの構築は、ステップ2と3で定義したサーティフィケートおよびプロモーションポリシーをエージェントの動作に組み込む工程だ。条件を満たせない場合のエスカレーションパスや、並行処理時の差し戻しルールもここで実装される。
ステップ6のモダナイゼーションの実行は、前段の設計が整って初めて意味を持つフェーズだ。記事では「ステップ1〜5が正しく設計されていれば、ステップ6は最もリスクの低い工程になる」という考え方が示されている。
コストの目安とモデル使い分け
Anthropicのエンジニアはいくつかの大規模モダナイゼーション事例のコストデータも公開している。コストを左右する主な要因は以下だ：
- 変更が必要なコードに対して読み込みが必要なコードの割合
- サーティフィケートの複雑さ
- テストの新規作成と修復の量
- 並行開発による差し戻しの量
モデルの使い分けについては、機械的・大量処理の変換にはSonnetのような低コストモデルを使い、困難な変換や敵対的レビューにはより高性能なモデルを充てることを推奨している。安価なモデルがサーティフィケートを満たせない場合に上位モデルにエスカレーションする戦略は有効だが、リトライ率はパイロット段階で慎重に分析することが求められる。
成果物はコードだけではない
このフレームワークで生まれる成果物は、モダナイズされたコードベースだけではない。
- 変更の「正しさ」を定義したサーティフィケート
- 変更管理プロセスが受け入れ済みのプロモーションポリシー
- すべての変更に紐づくエージェントトランスクリプトとサーティフィケート証跡
これらを再利用可能な資産として文書化しておくことで、次のアップグレードや書き直しにも即座に適用できるという考え方だ。Anthropicのフォワードデプロイドエンジニアは顧客の最重要システムでこのステップを実際に伴走している。
詳細はAnthropic Outlines Six-Step Framework for AI-Driven Code Modernizationを参照していただきたい。
