COBOL、VMware、.NETまで――AWS「45億行に及ぶコード処理」で見えたAIレガシー刷新の現状：「数年→6週間」「8カ月→数日」の事例に学ぶ「4つの知見」

何年もかかっていたレガシーシステムの刷新が、AIによって「6週間」に――。COBOL、VMware、.NETなどのシステムをAIを活用して移行、刷新する1年間の取り組みの成果をAWSが公開した。

[＠IT]

　生成AIやAIコーディングエージェントの普及を背景に、開発工程を効率化する動きが広がっている。長年使われてきた企業のレガシーシステムの移行、刷新においてその実態はどうなのか。

　Amazon Web Services（AWS）は2026年8月12日、AIエージェントを活用してシステム移行とモダナイゼーションを支援する「AWS Transform」の一般提供開始から1年間の成果を公開した。

　AWS Transformは、VMware製品で稼働するシステムの移行や、メインフレーム、Windowsアプリケーションのモダナイゼーションなどの支援を目的に始まったサービス。AWSはシステム移行やモダナイゼーションを効率化できた具体例や、そこから得られた教訓を紹介した。

COBOLからVMware、.NETまで　AIでレガシー刷新はどこまで速くなった？

　AWS Transformの取り組みは当初、以下のようなユースケースを想定して始まった。いずれも、従来は多くの時間や人手を要してきた作業だ。

• VMware製品による仮想環境で稼働するシステムの移行、刷新
• IBMのメインフレーム向けOSで稼働する「COBOL」アプリケーションのモダナイゼーション
• 開発・実行基盤「.NET」で構築されたアプリケーションのアップグレード

　AWSによると、サービス開始からの1年間でAWS Transformを通じて45億行を超えるソースコードを処理し、数十万台の仮想マシン（VM）を移行したという。

　では、移行やモダナイゼーションの作業はどれほど効率化されたのか。上記ユースケースに関する主だった事例が紹介されている。

メインフレーム刷新、「何年も」から6週間に

　ある企業は、25万行に及ぶメインフレームアプリケーションのコード変換とテストを6週間で完了した。従来は同じ作業に何年もかかっていたという。

　本番の大規模システムへの適用も進む。給与計算などの人事サービスを手掛けるADPは、AWS Transformのメインフレーム向け機能などを使って既存システムをモダナイズし、AI開発ツール「Kiro」と組み合わせて新しいソースコードを生成した。AWSによれば、110万の顧客を支えるシステムの刷新を、数年ではなく数週間で進められるようになったという。

5000台のVMwareサーバ、移行計画を10倍高速化

　インフラ移行でも、数千台のサーバの移行計画を数週間ではなく数時間で作成する例が出ている。

　バイオテクノロジー企業のCSLは、数千台のVMware環境のサーバ移行にAWS Transformを利用した。移行対象となるシステムの依存関係などをAIで分析し、移行計画の策定を従来の10倍に高速化したという。

.NETのモダナイゼーション、6〜8カ月から「数日」に

　アプリケーションのモダナイゼーションでも期間短縮の例が出ている。電子署名などを手掛けるSignaturit Groupは、ライセンス管理コンポーネントのモダナイゼーションにAWS Transformを利用。当初6〜8カ月を見込んでいた作業を数日で完了したという。

クラウド移行のコストを60％削減

　こうした期間短縮はコストにも表れている。AWSが顧客による評価をまとめたところ、AWSへの移行によってコンピューティングコストを平均35％、ライセンスコストを45％削減し、クラウド移行全体では60％のコスト削減につながったという。Windowsと.NETのモダナイゼーションでは、ライセンスコストを40％削減し、プロジェクト期間を4分の1に短縮した例もある。

45億行を処理して分かった「4つのこと」

　こうしたAWS Transformの利用を通じて、AIを使ったモダナイゼーションについてAWSは何を学んだのか。同社は数千社の顧客や数十社のパートナーとの取り組みから得た知見を、4つに整理している。

1．ユーザーそれぞれの使い方に合わせる

　当初はアーキテクト向けの専用Webアプリケーションを開発したが、開発者やプラットフォームエンジニアなど、利用者によって普段使うツールは異なる。そこでMCP（Model Context Protocol）サーバを介してAWS Transformの機能を利用できるようにした。「Kiro」の他、「Claude Code」「Cursor」「Codex」などからも利用でき、既存の開発作業にAWS Transformを組み込んだり、新たなワークフローを構築したりできる。

2．現場での開発を広げながら、品質も保つ

　AIによって、専門チームだけでなく、顧客やパートナー、AWSの現場チームもそれぞれの課題に応じた機能を開発しやすくなった。一方、開発に関わる人が増えれば、品質や運用方法にばらつきが生じる可能性もある。そこでAWSは、利用者が独自の機能を組み合わせられる拡張性を持たせながら、共通の基盤上で利用できるようAWS Transformを設計している。

3．モダナイゼーションは「一人ではできない」

　企業のシステム刷新は、開発者だけで完結する作業ではない。アーキテクトが移行後の構成を設計し、開発者が作業を実行し、責任者がレビュー、承認するなど、複数の関係者が参加する。このため技術的な変換だけでなく、作業の引き継ぎや管理、チーム間の連携もボトルネックになる。AWS Transformでは、移行前後の変更を追跡したり、利用者が変わっても一貫した方法で作業したりできる仕組みを備えている。

4．AIに任せ切りにせず、人が介入できるようにする

　AIの利用が広がるにつれ、単にサーバを移行するだけでなく、その過程でモダナイズしたい、メインフレームでは対応言語を増やしたい、Windowsでは変換方法や計画を専門家自身が調整したい、といった要望が出てきた。

　特に複雑なシステムの移行では、AIに全ての判断を任せればいいわけではない。AWSによると、利用者からは必要に応じて人が作業に介入できることや、精度と再現性が重要な処理では、同じ条件なら同じ結果になる決定論的な手法を選べることが求められたという。

「移す」だけではなく、移行と同時にモダナイズ

　こうした知見を基に、AWSはAWS Transformの対象を広げている。

　インフラでは、VMの移行計画を作成するだけでなく、ネットワークの再設計やアプリケーションのコンテナ化、移行後の検証まで自動化。対象もVMwareから「Hyper-V」、ベアメタル、他のクラウドで稼働するサーバへ広げた。

　メインフレームでは、AIエージェントが既存のコードやシステムの動きを分析し、コードに埋め込まれた業務上のルールを抽出する。その上で新しいアプリケーションへの変換を支援する。COBOLに加えて「PL/I」にも対応した。

　Windowsアプリケーションでは、.NETのアップグレードだけでなく、「ASP.NET Web Forms」から「Blazor」へのUI刷新や、「SQL Server」から「Aurora PostgreSQL」へのデータベース移行など、アプリケーション全体を対象とするモダナイゼーションに広げている。

　コードについても、「Java」「Python」「Node.js」などのアップグレードだけでなく、技術的負債そのものを継続的に見つけて解消する方向へ対象を広げた。コードリポジトリを分析し、脆弱（ぜいじゃく）性のあるフレームワークやサポートが終了した依存関係などを洗い出す機能を追加した。

　さらに、ドキュメントやテスト、開発パイプラインなどを調べ、アプリケーションがAIエージェントを活用できる状態にあるかどうかを評価する機能も追加している。