［ビジネスマン向け］AIでレガシーシステムを刷新する前に——Anthropicが示す準備の6ステップ

2026-09-26

はじめに

　Anthropicは2026年9月23日、AIを使ったコードのモダナイゼーション（既存システムの刷新）を、重要システムや規制業界の企業で進めるための準備手順を公開しました。本稿では、目標の定義から承認の流れ、コストの見積もりまで、6つのステップに沿って内容を整理します。

参考記事

タイトル: How to prepare for AI-driven code modernization projects
著者: Jonah Ezekiel、Lexie Tonelli
発行元: Anthropic（Claude Blog）
発行日: 2026年9月23日
URL: https://claude.com/blog/how-to-prepare-for-ai-driven-code-modernization-projects

要点

AIによってコード刷新は数年から数か月に短縮されたが、変更管理や承認など組織側の作業がボトルネックとして残っている
Anthropicは準備作業を、目標定義・合格条件・昇格ポリシー・前提整備・ワークフロー構築・実行の6ステップに分けている
刷新の種類はUplift・Transform・Reimagineの3つで、種類によって検証の方法が異なる
変更の正しさを示す条件は人手を介さず検証できるものにし、レビューの深さは影響範囲とエージェントの確信度で段階分けする
コストは小規模なパイロットでトークン使用量を測り、全体を外挿して見積もることが推奨されている

詳細解説

ボトルネックは「書くこと」から「組織を動かすこと」へ

　この記事は、AnthropicのForward Deployed Engineer（顧客の現場に入って導入を支援するエンジニア）が実際の導入事例から得た知見を共有する「Notes from the Field」シリーズの1本です。

　記事によれば、かつては数年がかりの全社プロジェクトとされたコードのモダナイゼーションが、いまでは数か月、場合によっては数週間で終わるようになりました。一方で、その前後にある組織的な作業はほとんど変わっていません。たとえば重要な銀行システムでは、すべての変更が変更管理・レビュー・承認を経る必要があり、これは規制当局や監査人、事業部門が求める堅牢なプロセスです。

　こうしたプロセスは「人が各変更を書き、人が各差分をレビューする」という前提で作られてきました。エージェントが変更の作成を加速すると、ボトルネックは変更を生み出すことから、組織をその変更に向けて動かすことへ移ります。記事はそのため、刷新そのものの前に行うべき準備を、次の6ステップに整理しています。

目標を定義する: 刷新後のコードが持つべき技術スタックと振る舞いを決める
合格条件（certificate）を作る: 変更が目標に照らして正しいとみなされる条件を決める
昇格ポリシー（promotion policy）を決める: 合格した変更が、生み出されるペースで本番環境に入るための経路を決める
前提条件を整える: 環境、CI/CD（継続的インテグレーション／デリバリー）、レビュー体制、承認をそろえる
エージェントのワークフローを構築・改善する: 刷新を多数の小さな並列サブエージェントの作業に分散する、Claude Codeのカスタム「dynamic workflow」を、目標・合格条件・昇格ポリシーを軸に作る
刷新を実行する: コードベースの小さな区画で端から端まで検証してから規模を広げる

　本稿としては、この構図はAnthropicがAIネイティブな開発ライフサイクルとして提唱した考え方と地続きのものと読めます。コードを書く速度が上がったときに、何がボトルネックになるかを先に見定めておくという発想です。

Step 1: 目標を定義する

　目標は刷新の最終的な姿です。どのような最終形を望むかによって、刷新は次の3種類に分かれます。

種類	内容	選ぶべき場面	目標として定めるもの
Uplift（引き上げ）	同じスタックのままバージョンを上げる（例: C++11→C++20）	スタック自体に問題はないが、サポート切れのランタイム、未修正のセキュリティ問題、更新できない依存関係などでバージョンが遅れている	ランタイムのバージョンとパッケージ群
Transform（変換）	振る舞いを保ったままスタックを移し替える（例: COBOL→Java）	スタックが解決すべき問題で、振る舞いは信頼できる	Upliftに必要なものに加え、新コードが従う言語・フレームワーク・設計上の規約
Reimagine（再構想）	振る舞いの変更を伴い、新しいアーキテクチャでゼロから作り直す	コードと合わせて振る舞いも変える必要がある	Transformに必要なものに加え、新システムの振る舞いを文書化した仕様

　どの種類で進めるかは、組織内で議論になりやすい点だとされています。本番運用に近い人たちはリスクを抑えるため、振る舞いを固定したままスタックを入れ替えるTransformを望む傾向があります。一方、長くそのコードと付き合ってきたエンジニアは技術的負債の解消を、ほかの事業関係者はこの機会に新しい要件を盛り込むことを望み、Reimagineを支持しがちです。どちらも妥当な立場ですが、この問いを曖昧なままにすると、あとで「この変更は正しいのか」という議論として再燃します。合意形成は初期の摩擦を生みますが、プロジェクト全体は円滑になるという見方です。

　目標を決めるには、まず現行システムの理解が役立ちます。旧コードが実際に何をしているかを抽出して振る舞いの一覧を作ると、どこを変える・捨てるべきかを判断しやすくなり、TransformかReimagineかも決めやすくなります。知られていなかった業務ロジックや例外的なケースが見つかることも多いとされています。

　Claudeは依存関係を洗い出し、誰も作った覚えのないワークフローを文書化することで、この調査の多くを担えます。Anthropicが公開しているcode modernizationプラグインには、次のコマンドが用意されています。

assess: コードベースを評価する
map: 依存関係を可視化する（対話的な依存関係マップを生成できる）
extract-rules: 業務ルールを、根拠となるソースコードの箇所付きで抽出し、エンジニアがレビューできる形にする

　ただし、Claudeによる調査だけではレガシーシステムの振る舞いを完全には捉えきれない場合があります。業務ユーザーや開発者へのインタビュー、社内文書で隙間を埋める必要があり、この文脈の質がのちのワークフローの判断すべてを左右するとされています。Reimagineの場合は、詳細な振る舞い仕様を書き起こし、ユーザー部門と合意する作業が追加で必要です。

　目標の定義と並行して、なぜ刷新に取り組むのかという根拠と目標も確認しておくよう勧められています。記事によれば、刷新は保守・運用コストを下げうるものの、多くのプロジェクトではコスト削減が主な動機ではありませんでした。最も重要な効果はリスクの低減で、「刷新しないリスク」を考えることが判断の助けになります。未修正の脆弱性を抱えたシステムは、事業そのものを危うくするほどのサイバー侵害や障害につながりえます。サポート切れのランタイムや、そのシステムを理解するエンジニアの減少は、そのリスクをさらに高めます。

　Claude Codeのようなエージェント型ツールで期間は短くなりましたが、予算は依然として見積もりにくく、それが腰の重さにつながっています。Anthropicは自社の大規模移行のコストを公開しており、LG CNSなど他社の事例も公開されているため、大まかな基準として使えるとしています。記事は、プロジェクトを始めるうえでの最大の課題は、システムを所有するチームと依存するチームから合意とコミットメントを得ることだと述べています。経営層のレベルで事業上の根拠と目標を設定しておくと、この過程が進めやすくなり、後の合格条件や昇格ポリシーでのリスク判断の拠り所にもなります。変更がどこまでリスクを負ってよいかで意見が分かれたときに、「刷新しないリスク」が釣り合いの重りになるという説明です。

　本稿としては、この「刷新しないリスク」を議論の出発点に置く考え方は、日本企業でよく語られる「2025年の崖」のような文脈とも重なり、経営層に判断を求める際の説明材料として使いやすい枠組みだと考えています。

Step 2: 合格条件（certificate）を定義する

　合格条件は、刷新によるすべての変更が満たすべき条件やテストの集合です。変更が目標に照らして正しいことを示す証拠が、積み重ねで最も強くなる条件を選ぶよう勧められています。

　重要なのは、各条件が人手を介さずに確認できることです。そうすればエージェントのワークフローは、合格条件を満たすまで変更を繰り返し修正するか、満たせない場合に人のレビューへ回すかを自動で判断できます。記事によれば、合格条件は目標によって異なるものの、通常は次のリストから選ばれます。

元のテストスイートがすべて通る
刷新中にClaudeが書いたテストがすべて通る
テストカバレッジが合意した基準を満たす
性能ベンチマークが合意した範囲内に収まる
それぞれ新しいコンテキストウィンドウで行う、Claudeによる独立した敵対的レビューで、阻害要因となる問題が見つからない
UIの場合、Claudeのコンピューター操作（computer use）による確認でリグレッション（既存機能の退行）が見つからない
同じ入力（実データ、記録データ、Claudeが生成したデータのいずれか）に対して、現行版と新版が同じ出力を返す
永続化された状態や通信フォーマットが、現行版と新版の間で相互に変換しても崩れない（ラウンドトリップする）
ステージング環境で合意した期間運用し、エラー率・レイテンシ・アラートにリグレッションがない
静的解析とセキュリティスキャンで新たな指摘がない
コンパイル型の言語では、ビルドが警告なく通り、型チェックも通る

　合格条件は、変更をレビューし本番に昇格させる人たちと一緒に書くよう勧められています。コードベースに依存している開発者、ユーザー部門、事業責任者を、合格条件とワークフローを設計している段階から巻き込むことが大切だとされています。彼らの専門知識が測るべき内容を形づくり、早い段階での関与が、変更がレビューに届いたときの納得感につながるためです。完成した合格条件の良し悪しを確かめるには、「その証拠だけでマージしてよいと彼らが思えるか」を問うのが良い方法で、自分たちの基準がそこに反映されていると感じてもらえれば、Step 3の昇格ポリシーを軽くできます。

　何と比べて、どう確認するかは刷新の種類によって変わります。

Uplift: 比較対象は元のコードベースで、元のテストスイートを合格条件の中心に据えられる
Transform: 比較対象は同じく元のコードベースだが、元のテストスイートは新しいスタックではほとんど動かない。代わりに本番トラフィックのリプレイ、新旧の差分テスト、本番と並行稼働させる環境（prod-parallel）が主な役割を担う
Reimagine: 合格条件は振る舞い仕様に基づく。最も難しいケースで、仕様は既存システムほど客観的な比較対象ではないため、モデルの判断に頼る部分が大きく、結果もばらつきやすい。仕様から書いたテスト、各変更を仕様と照合するClaudeの独立した敵対的レビュー、旧システムの振る舞いを引き継ぐ部分の差分チェックに頼ることになる。仕様の不足はまずここで表面化するため、仕様が明確になるにつれて合格条件を見直す前提で臨む

　古いシステムはテストカバレッジが薄かったり、結果が安定しないテストがあったり、テレメトリ（稼働状況の計測データ）が乏しかったりすることが多いとされています。合格条件の定義には、こうした不足を特定する作業も含まれます。強い合格条件を支えにくい場合は、本番並行環境の構築、リプレイ用の仕組みづくり、テストの追加など、足りない証拠をClaudeで作ることがこの段階で最も有用な作業の1つだとされています。

　本稿としては、「AIの書いたコードを信頼できるか」という漠然とした問いを、「どの証拠がそろえば人が安心してマージできるか」という具体的な問いに置き換えている点が、このステップの核心だと受け止めています。

Step 3: 昇格ポリシー（promotion policy）を決める

　エージェントは、人のチームが差分を1つずつレビューできる速度をはるかに超えて変更を生み出します。昇格ポリシーは、変更ごとに人がどこまで深くレビューするかを段階的に定めたレビュー経路で、事前に文書化して合意しておく点が特徴です。これにより、刷新を許容できる期間内に終えられるようにします。

　合格条件と同様に、このステップもレビュー担当者と一緒に進め、できる限り既存の変更管理プロセスに組み込むよう勧められています。詳細は組織やリスクの考え方によって異なりますが、どこでも通用するルールとして次の4つが挙げられています。

影響範囲とエージェントの確信度で変更を段階分けする: 組織独自の変更区分やリスク分類があればそれを使う。クリティカルな経路には人による完全なレビューを残す
繰り返し出るフラグは根本で直す: 人のレビューに回された変更を時系列でグループ化・分析し、同種のフラグが繰り返し出る場合は、1件ずつレビューするのではなくワークフローや合格条件の側で原因を直す
出力形式をレビュー担当者と設計する: どの情報と形式ならレビューが最も速いか、どの兆候が確信を高めるかを合意する。Step 5の初期サンプル出力を早めにレビューしてもらう
SME（領域専門家）の時間を効果的に配分する: SMEがすべての差分を読むことはないが、その判断は最も希少な資源である。大きな差分をかき分けずに、最もリスクの高い段階の変更と、その中でフラグが付いたエージェントの判断へ直接たどり着けるようにする。そうすれば少ない専門家の時間で、最もリスクの高い変更をカバーできる

　これらのルールの多くは、SMEの時間をプロジェクトの初期に前倒しで使う形になっています。彼らのフィードバックが、本格的な刷新の前に合格条件とワークフローを調整します。サンプルへの承認は、確信度の高い変更について軽いレビュー経路を採る根拠にもなります。記事は、これがレビューを最後に行う従来型の進め方とは逆のパターンだと指摘しています。

　昇格ポリシーには、速度とレビューの深さのどこに刷新を位置づけるかも反映させます。ランタイムのサポート終了のような動かせない期限に追われる刷新では、人のレビューを軽くし、変更ごとにより多くのリスクを受け入れることを明示的に合意した、速いポリシーが必要です。期間に余裕があれば、より深いレビューとゆっくりした切り替えを選べます。関係者のリスク許容度や制約によって落としどころは変わるため、作業開始前に確定させておく価値があるとされています。

　規制環境では、どの変更であれ人のレビューを軽くすることには強い抵抗が生じがちです。個々の承認者は悪い変更のリスクを背負うためにためらい、一方で経営層は老朽化したシステムという、より大きなリスクを背負っています。記事は、昇格ポリシーの方針は組織のトップから示すのが最善で、事前に合意しておくことで、本番に到達したバグの責任を承認者個人に負わせず共有できるとしています。そのうえで、すべては実際の証拠として通用するほど詳細な合格条件と、Claudeがどのように変更に至ったかを理解して信頼できるレビュー担当者があってこそ成り立つと付け加えています。

　承認者個人の責任とされがちな判断を、組織として事前に引き受ける設計にしている点は、技術よりも組織論の色合いが濃いところで、日本の大企業や金融機関で導入を進める際にも参考になる視点だと思います。

Step 4: 前提条件を整える

　このステップの多くは、刷新チーム以外のチームを通じて進みます。ホスト環境はプラットフォーム・インフラ部門、テスト体制はQAやリリースエンジニアリング部門、承認はセキュリティ・コンプライアンス部門といった具合です。各チームには独自のバックログや承認プロセスがあるため、要件が見えた時点で、Step 1〜3の途中であっても早めに相談を始めるよう勧められています。記事では、前提条件が次のように整理されています。

環境

ワークフローを実行する専用のリモートホスト（コードベースや関連情報源にClaudeがアクセスできる状態）
合格条件が求めるテスト実行能力
合格条件を強化するもの（本番テレメトリ、本番並行環境、リプレイ用の本番データなど）

コードベースとCI/CD

ビルド・コンパイルログ、import分析、実行時トレースに基づく依存関係マップ（プラグインのmapコマンドは良い出発点だが、コードベースの規模や古さによっては、より多くの事前作業が必要になる）
目標定義の一部として、依存関係やパッケージの扱いを計画しておく
必要に応じて、CI/CDに追加できる互換性チェック
稼働中のコードをその場で刷新する場合は、合意済みのコードフリーズ方針
現役の開発者に向けた、コードフリーズや新たな互換性要件についての周知計画

チームとレビュー

コードベースに依存する他チームから、合格条件への承認や昇格ポリシーに基づくレビューなど、どう関わるかについての合意を得て、レビュー担当者の時間を確保しておく

セキュリティとコンプライアンス

ソースコードを扱うことが承認された、Claude Codeのモデル利用経路
ワークフローへの最小権限の付与（刷新用ブランチへの書き込みのみ、本番の認証情報は持たせない）
刷新用ブランチからの機密情報（シークレット）や個人情報（PII）の除去・マスキング
すべての変更を追跡可能にし、プルリクエストをエージェントの作業記録（トランスクリプト）と合格条件の証拠に紐づける
新しい依存関係に対するライセンスと脆弱性のチェック

　本稿としては、このチェックリストは刷新プロジェクトに限らず、エージェントに本番に近いコードを触らせる際の最低限の備えとしても読めると考えています。

Step 5: エージェントのワークフローを構築・改善する

　ここでようやく、Claude Codeで刷新用のカスタムdynamic workflow（作業を多数のサブエージェントに動的に分散させる仕組み）を作ります。Anthropicは、code modernizationプラグインから始め、ワークフローが必要としうるものすべてをファイルシステム上かMCP（Model Context Protocol：AIと外部ツールをつなぐ標準規格）経由でClaudeが参照できる場所に置くことを勧めています。対象は、目標、合格条件、昇格ポリシー、コードベース、ドキュメント、合格条件が求めるデータソースやツールなどで、この記事自体を文脈としてClaudeに渡してもよいとされています。これがプロジェクトの中心的な知識基盤になります。

　ここまで整っていれば、ワークフローの構築自体は簡単な部分だとされています。必要に応じてSMEにClaudeの作業をレビューしてもらい、コードベース固有のスキルや抽出したルールは、後続の工程がそれに依存する前に確認します。その後、コードベースの小さな部分に適用して改善を重ね、SMEには生成された変更、エージェントの作業過程、合格条件を満たした証拠をレビューしてもらいます。

　問題が見つかったときは、個々の変更ではなくワークフローを直すよう勧められています。目指すのは、規模を広げたときに変更がほぼすべての箇所で合格条件を満たし、レビュー担当者が昇格ポリシーのもとで安心してマージできるという確信です。

Step 6: 刷新を実行する

　まずコードベースの小さな部分で、昇格ポリシーに沿ったレビューと本番への反映まで含めて、刷新を端から端まで完了させます。うまくいかない点は修正コストが低いうちに直し、確信が持てるまで繰り返してから、コードベース全体へ広げます。

　TransformとReimagineは、既存システムと並行して新しいシステムを作り、完成時に切り替える進め方になります。一方、Upliftには、開発を続けながら稼働中のコードベースをその場で刷新するという2つ目の選択肢があります。システムを止められない場合や、コードの変更が速すぎて刷新用の別コピーを最新に保つのが難しい場合によく選ばれる方法です。記事によれば、この場合にうまくいったのは次の進め方です。

コードベースを、依存関係の末端（リーフ）から内側に向かって論理的な区画に分ける
区画を1つずつフリーズして刷新する
刷新済みの区画を新しいコミットが元に戻せないよう、CI/CDでゲートを設ける

コストについての注意点

　記事によれば、こうした刷新にトークンでどれくらいかかるかはよく質問されるものの、案件ごとに異なります。主なコスト要因は次の4つです。

コードベースのうち、読むだけの部分と変更する部分の割合
合格条件の複雑さ（規制環境では、変更を書くことよりも検証の方が大きな割合を占めることが多い）
合格条件が求める新規テストの作成やテスト修正の量
実行中に他チームが周辺でマージすることで生じる調整（リコンシリエーション）作業の量

　コードベースの小さな部分で刷新を完了させる際にトークン使用量を測り、それをもとに残りを外挿するよう勧められています。稼働中のコードベースでの調整作業のように、パイロットで見えなかった要素は未知数として扱います。こうすることで、刷新全体のコストの下限を見積もれます。

　パイロットの計測は、コスト面でワークフローをどこから最適化すべきかも示します。最もトークンを消費した部分を特定して効率化を考え、計算負荷の高い検証は安価なチェックを通過した後にだけ実行されるよう後段に回します。また、合格条件で完全に確認できる機械的で大量の作業にはコストと能力のバランスが取れたSonnetのようなモデルを使い、難しい変換や正しさを検証する敵対的レビューには、より賢いモデルを残すことが勧められています。

　安価なモデルが合格条件を満たせなかったときに高価なモデルへ切り替える方法もありますが、安価なモデルで何度も試すと高価なモデル1回より高くつくことがあるため、パイロット中にやり直し率を注意深く分析するよう求めています。ワークフローとパイロットのデータの両方をClaudeに渡せば、この分析の多くを一緒に行えるとされています。

　本稿としては、この「安いモデルの失敗の繰り返しが高くつく」という指摘は、単価だけでなく完了までの総額でコストを見るという考え方に立つもので、刷新のような大規模案件ではその差がさらに大きくなると考えられます。

刷新の先に残るもの

　記事は、刷新済みのコードベースは成果物の1つにすぎないと結んでいます。ほかにも、それを生み出したワークフロー、何を正しいとみなすかを文書化した合格条件、変更管理プロセスで承認済みの昇格ポリシー、反映されたすべての変更の証跡が残ります。これらを再利用可能なプレイブックとして体系化しておけば、次のアップグレードや書き換えの際にすでに型ができている状態になるという提案です。

　なお、AnthropicのForward Deployed Engineerは、顧客の最重要システムでこれらのステップを一緒に進めているとして、相談窓口も案内されています。