Amazon Web Services ブログ
1 年間の経験。45 億行のコード。160 万時間の節約。そして私たちが学んだこと。
この記事は、”One year. 4.5 billion lines of code. 1.6 million hours saved. Here’s what we learned.” を翻訳したものです。
1 年前、私たちは AWS Transform を立ち上げました。その使命は、ただ 1 つです。それは、世界のインフラストラクチャとアプリケーションをモダナイズすることです。
AWS Transform の一般提供開始から 12 ヶ月が経過した今、これまでに 45 億行を超えるコードが処理され、数十万台のサーバーが移行され、160 万時間を超えるお客様を節約できたこと、そして移行、モダナイゼーション、そしてこの作業が待った無しの状態である理由がわかりました。
モダナイゼーションが何故これまで以上に重要なのか
企業は今でもインフラストラクチャのかなりの部分をオンプレミスで運用しています。世界のソフトウェアの大部分は 20 年以上前のものです。今でも給与計算を行っています。まだ請求処理が行われています。お客様のビジネスが日常的に依存しているシステムが引き続き稼働しています。そして今、経営陣は、その上にエージェンティック AI を組み込むことを望んでいます。15 年間手が入っていないメインフレームでは、エージェンティック AI ワークロードを実行することはできません。退職したエンジニアが開発した継ぎ接ぎだらけの .NET Framework アプリケーションに AI エージェントを投下することはできません。皆さんが先送りし続けているモダナイゼーションが、今や CEO が前四半期に発表した AI 戦略とあなたとの間に立ちはだかっているのです。
その一方で、技術的負債はどんどん膨れ上がっています。米国だけでも、技術的負債は年間 1.52 兆ドルに上ると見積もられており、AI コーディングエージェントは、その山を小さくするのではなく、むしろ大きくしています。彼らは現在出荷されているコードを生成しますが、明日の標準には従わないでしょう。企業リーダーからのシグナルは、「モダナイズすべき」から「モダナイズしなくてはならない」に変わりました。しかし、モダナイゼーションは技術的に難しく、ビジネスが複雑になり、そして重要なのは、モダナイゼーションは決して終わらないということです。今日のモダナイゼーションは明日の遺産です。だからこそ、モダナイゼーションはプロジェクトではなく、継続的なプロセスでなければならないのです。
これが AWS Transform を構築した理由です。
お客様が実際に求めたこと
アーキテクチャではありません。フレームワークではありません。他のツールでもありません。
彼らが求めたのは「スピード」という結果でした。精度。継続性。彼らは行き詰まったものを終わらせたかったのです。彼らのプロジェクトのいくつかは何年も手つかずのまま放置されていました。AWS では 20 年間にわたり、数十万件に上るプロジェクトでお客様を支援し、移行ツールを自社で構築してきました。何がうまくいくのか、規模を拡大するには何が必要か、どこにギャップがあるのかはわかっていました。
これが 1 年前、AWS Transform が誕生した経緯です。私たちは学んだことのすべてを数十個の専門的な AI エージェントにまとめ、エージェント型のワークフローで結び付けました。これらのエージェントは、ゴール駆動型のオーケストレーションを使用して end-to-end の自動化を実行しています。ディスカバリー、計画、トランスフォーメーション、テストはすべて相互に関連しています。共同作業者間のシームレスな引き継ぎ。ステージ間でコンテキストが失われることはありません。20 年にわたる移行の専門知識を AI 支援サービスとして提供し、イテレーションを重ねるごとに改善されていきます。
この取り組みは、3 つのユースケース (VMware インフラストラクチャーの移行、IBM z/OS COBOL アプリケーションのモダナイゼーション、.NET のアップグレード) を立ち上げることから始めました。これらのワークロードは、お客様がモダンなワークロードを実行するのを嘗て妨げており、現在はエージェント型のワークロードの実行を妨げているからです。re:Invent 2025 では、広範に技術的負債を削減するべく、あらゆるコード、言語、API、フレームワークのアップグレードに合わせて独自のカスタムトランスフォームを定義できる機能を追加しました。
12 ヶ月で何が起こったか
AWS Transform の利用を通じて、45 億行を超えるコードを処理し、数十万台の VM を移行しました。
速度の違いは小さくはありません。25 万行のメインフレームアプリケーション全体のトランスフォーメーションとテストを 6 週間で完了したお客様がいらっしゃいます。以前は、同じ作業に何年もかかっていました。現在、数千台のサーバーを数週間ではなく数時間で移行することを計画しているインフラストラクチャーチームも居ます。これらのお客様による評価では、AWS に移行することでコンピューティングが平均 35%、ライセンスが 45% 節約され、クラウドに移行することでコストを 60% 削減できることが一貫して明らかになっています。Windows と .NET のモダナイゼーションにより、ライセンスコストが 40% 削減され、プロジェクトのスケジュールが 4 倍短縮されたケースもあります。
これらの数字の背景にある顧客リストには、より大きな物語があります。CSL 社は、数千台のサーバの移行を数日で計画しました。これは、以前のアプローチの 10 倍のスピードです。ADP 社は Transform のメインフレームとカスタム機能を使用して複雑なメインフレームをモダナイズし、Kiro と連携して新しいコードの構築を完了しました。現在、110 万のクライアントに対応できるようになり、その成果は数年ではなく数週間で完了しています。Signaturit Group は、Windows .NET から Linux への移行期間を 6~8 ヶ月から数日間に短縮しました。Air Canada は Node.js ランタイムを数日でアップグレードし、90% の効率化と 80% のコスト削減を実現しました。その後、Transform を社内標準にしました。また、何千ものお客様を対象に、過去からの技術的負債を修復するのではなく、将来のためのイノベーションに投資することで、すでに 810 人年分に相当する開発者の工数を節約しています。
しかし、最も強いシグナルは、どの指標にもありません。5 人中 4 人の顧客が AWS ツールに戻ってきて、より多くのプロジェクトを行っているということです。現在、約半数が複数のトランスフォーメーション機能を利用しています。顧客は価値を見出さない限りツールに戻りません。
パートナーと ISV は複合的な効果を生み出します。30 を超えるパートナー組織が Transform をベースにソリューションとデリバリープラクティスを構築しています。ISV も Transform と統合して事業を拡大しています。Wavicle 社は、AWS Transform による BI モダナイゼーションを AWS Marketplace を通じて提供することを発表しました。AWS のフィールドエンジニアは、お客様が直面するパターンに応じてトランスフォームを行っています。つい先週、あるフィールドメンバーが規制対象の顧客のニーズをサポートするためにインフラのアセスメントを拡大しました。
私たちが学んだ 4 つのことと、それがロードマップをどのように進化させたか

今年、数千のお客様と数十のパートナーと協力してきた結果、私たちのアプローチとロードマップは、次の 4 つの重要な洞察から導き出されました。
1. ユーザーが作業しているところで会うこと。まず、プログラムマネージャーやアーキテクト向けの専用ウェブアプリを開発しました。しかし、アーキテクトはダッシュボードの中で生きています。開発者とプラットフォームエンジニアは IDE と CLI で生活しています。パートナーはそれぞれ独自の配信環境に住んでいます。誰もが、誰かが中断したところから再開したいと思っています。私たちの答えは、「ユーザーが作業しているところで出会う」という選択へのこだわりを引き継いでいます。
現在、MCP サーバーを介して、エージェントにバンドルされていないアクセスを提供しています。この MCP サーバーは、Kiro powers や Claude Code、Cursor、Codex などのエージェントプラグインなど、新しいアクセスサーフェスを強化します。顧客やパートナーは、これらを既存のワークフローにさらに簡単に統合したり、エージェントを召喚して新しいワークフローを構築したりできます。CLI を使用すると、コードのモダナイゼーションパターンを繰り返し実行できます。すべてのサーフェスは同じコンテキストを共有し、再入力や進行状況の損失はありません。
2. ガードレール付きのフェデレーテッド開発。私たちのチームは、お客様からのフィードバックを取り入れてあらゆるトランスフォームを構築しています。そして、それを何千人ものプラクティショナーに送り、彼らは私たちが計画していなかった場所にそれを導入します。AWS のフィールドチームはお客様と協力して、問題をその場で解決します。パートナーは独自の視点をもたらします。AI はチームのイノベーションのハードルを下げました。フェデレーテッドモデルはクローズドモデルよりも速く合成されます。しかし、品質と運用の一貫性を保ちながらこの機能を活用することは容易ではありません。だからこそ、お客様、パートナー、ISV、そして当社のフィールドチームがパーソナライズして独自の特製ソースを追加できるように、私たちは初日からコンポーザビリティを備えた Transform を設計に組み込んでいます。
本日※、エージェントビルダーツールキットを Kiro powers として提供を開始しました。これにより、AgentCore でエージェントを構築して Transform に組み込むことがさらに簡単になります。このコンポーザビリティサービスでは、カスタムエージェントを構築し、それらを AWS Transform 内の機能と組み合わせることができます。
(※) 訳注: 本ブログ(原文)の公開日である 2026/05/14
3. エンタープライズモダナイゼーションはマルチプレイヤーです。エンタープライズポートフォリオのモダナイゼーションは、開発者が単独で行う作業ではありません。アーキテクトが目標状態を定義します。開発者が実行します。リーダーはレビューと承認を行います。パートナーは大規模に提供します。ボトルネックは、オーケストレーション、ガバナンス、そして社内のセキュリティ境界内のチーム間のコラボレーション能力です。だからこそ、私たちはまず、ソースからターゲットまでの完全なトレーサビリティ、実行するユーザーに依存しない一貫性、既存の IT システムへのコネクターなど、Transform を共同のエンタープライズ基盤として構築しました。
そして本日、新しい S3 コネクタを追加し、IAM ロールをサポートする権限を拡張し、human-in-the-loop とのやりとりを複数の領域に拡大しようとしています。ユーザーはチーム全体でジョブサマリーを見ることができ、次のステップをどの面からでも簡単に通知できます。
4. 聞いて、作って、出荷して、繰り返す。お客様が初期のユースケースで Transform を使い始めたとき、私たちは彼らが必要としている新しい機能について学びました。移行を行う際には、サーバーを移動するだけではなく、その過程でモダナイズしたいと考えていました。メインフレームでは、顧客は新しいコードを生成するために、言語を増やし、コーディングエージェントとの統合を強化したいと考えていました。Windows ワークロードをモダナイズする際、専門家はトランスフォーメーションの実行方法やプランの編集方法をより細かく制御したいと考えていました。また、お客様は当初の出荷目的以外にも、他の種類の技術的負債を是正したいと考えていました。全体的に見て、お客様はより複雑な移行に取り組むにつれて、反復による制御を強化し、精度と再現性が必要な場合に決定論的アプローチを使用するオプションを求めていました。
本日、私たちは、お客様が Transform でできることをさらに深める機能をすべてのユースケースに導入しています。移行については、VM のコンテナ化やネットワークの再構築など、移行中にお客様がモダナイズできるようになりました。メインフレームのモダナイゼーションでは、PL/I への拡張と Kiro や Claude などのコーディングエージェントとの統合も提供しています。双方向性を高めるため、専門家によるガイダンスと自律的な変革を組み合わせる機能により、Windows のモダナイゼーション機能を強化しました。さらに、組織全体で大規模な技術的負債を是正できる新しいカスタムトランスフォームが数十種類追加されました。
さらに詳しく: 各ユースケースがどのように進化しているか
インフラの移行については、引き続き計画と実施を強化します。あらゆる形式のインベントリをアップロードし、ビジネスコンテキストを追加し、仮説シナリオを検討して、最適化された TCO を数分で算出できます。そして、技術的な制約とビジネス上の制約の両方を考慮して、数千台のサーバーにわたる移行ウェーブを数時間で計画できます。ネットワークやセキュリティ設定を移動すると、プロジェクトが脱線することが多いことがわかりました。オンプレミスネットワークを AWS と同等のネットワークに移行する機能を提供していますが、今回、VPC の最適化、CIDR の適切なサイジング、セキュリティグループの強化、命名の修正など、ネットワークを再構築するための拡張を行っています。これにより、数週間にわたる手作業によるレビューなしにネットワークの移行準備が整います。安全なターゲット環境のプロビジョニングを簡単にするために、ランディングゾーンを自動的に作成して AWS Control Tower と統合するようになりました。また、VMware 以外にも Hyper-V、ベアメタル、クラウドベースのサーバーをサポートするようになりました。モダナイズを希望するお客様は、アプリケーションをコンテナ化して ECS または EKS に移行できます。また、従来の移行ツールである MGN を、プロジェクト指向のアプローチで AWS Transform から手軽に使用できるようにしました。移行後は、構成、検証、コンプライアンスの実施を自動化できるため、何日にもわたる手動のランブックから移行を確定的で繰り返し可能なイベントに変えることができます。また、複数のターゲットアカウントにまたがる、あらゆる商用 AWS リージョンと GovCloud に移行できます。また、発見からデプロイ、移行後の検証まで、すべてのステップが統合され、コンテキストが共有されます。
メインフレームアプリケーションのモダナイゼーションでは、パイプライン全体でパフォーマンスを向上させ続けました。ファクト生成エージェントは、コード、ランタイムの動作、ビジネスルール、データリネージを分析して詳細な実行グラフを構築し、レガシーコードの意図をビジネスルールとして抽出し、トランスフォーメーション後のコードのすべての機能を元のルールにマッピングして、これまで数ヶ月または数年停滞していたプロジェクトを数週間で完了させます。決定論的分析と AI 駆動の生成を組み合わせることで、これまでベンチマークした中で最も正確で幅広い結果が得られます。私たちは IBM COBOL、VSAM、IMS、Db2 から始め、現在は PL/I にまで拡大しています。PL/I は金融サービス、保険、公共部門で一般的な言語であり、ポインター演算と動的ストレージ割り当てのために歴史的にモダナイゼーションが困難でした。同じ reimagine パターンを使用して、Transform は PL/I ビジネスロジックを構文に依存しない仕様に抽出し、Kiro がインタラクティブに引き継ぎます。開発者は、モダナイズされたアプリケーションがクラウドネイティブなイベント駆動型パターンにデプロイされるまで、生成されたサービス仕様のレビュー、アーキテクチャに関する意思決定の改良、コードとインフラストラクチャの反復など、会話形式でエンジニアリングを進めます。
Windows アプリケーションのモダナイゼーションは、.NET のアップグレードにとどまりません。エンタープライズ Windows 環境は単なるコードではありません。コード、データベース、アプリケーションの依存関係が絡み合っています。Transform はこれを自律的に処理します。複雑さを評価し、作業を段階的に実行し、トランスフォーメーションを end-to-end で実行します。しかし、アーキテクトが意思決定の指導 (トランスフォーメーションプランの調整、特定の選択肢の上書き、最も複雑な変更の完成) を望む複雑なプロジェクトも見てきました。今では、自律的な流れを断つことなく、いつでも介入し、一歩下がることができます。また、ASP.NET ウェブフォームから Blazor への UI のモダナイゼーションや SQL Server から Aurora PostgreSQL への移行など、フルスタックのモダナイゼーション機能も拡張してきました。拡張されたデータベースモダナイゼーション機能は現在ベータ版で、スキーマ、ストアドプロシージャ、アプリケーションデータアクセスコードなど、スタック内のすべてのオブジェクトをまとめて変換します。始めるのは簡単です。仮想ソースを使用すれば、本番環境データベースへの直接アクセスを待つ必要がなくなります。このワークフローは反復型です。つまり、ある程度の労力で評価を受け、データベース管理者がレビューして承認し、Transform が実行します。構文検証、セマンティック等価性、合成データによる機能検証という 3 段階の検証により、本番データが移動する前に正確性が確認されます。
コードのモダナイゼーションについては、企業規模で技術的負債をなくすというビジョンに向けて拡大しています。フレームワークの老朽化、EOL (end-of-life) を迎える SDK、依存関係の積み重なりなど、技術的負債は加速しています。また、エージェントが新しいコードを作成するスピードがかつてないほど速くなっているため、顧客は 1 回限りのプロジェクトで可能になるよりも迅速に行動する必要があります。彼らは私たちの既存の Java、Python、Node.js、SDK のアップグレードを使用してきており、お客様の要望により、私たちは何十もの新しいパターンに引き込まれました。現在、Vue.js アップグレード、Scala/Glue アップグレード、Spring Boot アップデート、Log4j から SLF4J、Angular から React へ、Angular から Flutter へ、Progress 4GL から Java へ、PHP リプラットフォームへ、ColdFusion から React/Java へ、Datadog から CloudWatch Monitors へ、JBoss から Spring Boot へ、すぐに使えるトランスフォームを出荷しています。これらはすべて、個々の専門家の手腕に頼ることなく、組織全体やリポジトリ全体に適用できます。そして今、私たちは 3 つの新しいコード評価機能を導入しています。技術的負債の評価は、お客様の優先順位付けに役立ちます。コードリポジトリを指定するだけで、フレームワークの脆弱性、サポート終了後の依存関係、修正すべき重要度など、ポートフォリオレベルの完全な分析が数分で得られます。エージェント対応状況評価では、ドキュメント、パイプライン、テストの完全性をチェックすることで、アプリケーションが実際にどの程度エージェント対応状態にあるかがわかります。モダナイゼーション評価は、クラウドネイティブの成熟へのステップを理解し、AWS ベストプラクティスへの道筋を特定するのに役立ちます。これらの新機能を強化するために、基盤となるエージェントを再設計し、最大 2 倍のパフォーマンスを実現しました。
これから進む道
私たちの使命は、世界のレガシーソフトウェアとインフラストラクチャを継続的にモダナイズすることです。あるワークロードが次に引き込まれます。ある顧客が VM を移行し、トランスフォーメーションが必要な Windows アプリケーションを発見してモダナイズし、コードベースにフレームワークの負債が蓄積されていることに気付きます。このサイクルは決して終わりません。歩調を合わせているサービスは、学習を止めることはありません。
2026 年末までに私たちが実現したい目標はシンプルです。エージェンティックになりたいすべての企業が、専用のプログラムや複数年にわたるロードマップなしで、継続的に Transform を使用してインフラストラクチャとポートフォリオを使える状態できるようにすることです。
モダナイゼーションはプロジェクトではなくバックグラウンドプロセスになります。1 つのワークロードから始めます。サービスはコンテキストを引き継ぎます。次に何をモダナイズするかはあなた次第です。
PS: 5 社の顧客のうち 4 社はすでに事業を拡大しています。次はあなたの番です。