モダナイゼーションの現実的な壁
Windowsベースのレガシーシステムをモダナイズする際、大きく3つの層を処理する必要があります。
プレゼンテーション層のASP.NET Web Forms、アプリケーション層の.NET Framework、データベース層のSQL Server。これらを個別に変換し、さらに相互の依存関係を維持しながら統合するのは、経験豊富なエンジニアでも相当な工数がかかります。
AWSの公式発表によると、組織平均として開発チームは技術的負債対応に月額時間の30%を費やしているとのこと。新規機能開発に充てるべきリソースが、レガシーシステムの保守に消えていく状況は多くの現場で見られます。
AWS Transformは、この問題に対してAIエージェントを投入することで解決を図ろうとしています。最大5倍のモダナイゼーション加速、最大70%の運用コスト削減という数字が発表されていますが、実際の技術的な仕組みはどうなっているのでしょうか。
エージェント型AIの構成
AWS Transformは、Amazon Bedrockの大規模言語モデル（LLM）をベースにしたドメイン特化型エージェントを採用しています。Anthropic ClaudeやAmazon Novaなどのモデルを活用し、SQL Server、.NET Framework、Entity Framework、ASP.NET Web Formsに関する専門知識を内部的に保有しています。
マルチエージェントシステムとして設計されており、役割ごとにエージェントが分かれています。
.NET Application Agentは、.NET Frameworkアプリケーションの分析・変換を担当します。抽象構文木（AST）解析や依存関係グラフを用いてコードを解析します。
Database Agentは、SQL Serverスキーマやストアドプロシージャの変換を担当します。データベースオブジェクトの解析とスキーママッピングを行います。
Dependency Agentは、クロスレイヤーの依存関係検出と解決を担当します。グラフ理論ベースの依存関係解析を用いて、アプリケーションとデータベース間の関連性を自動で把握します。
Deployment Agentは、Infrastructure as Code（IaC）の生成とデプロイメントを担当します。CloudFormationテンプレートを自動生成します。
波ベースの変換戦略
複数のデータベースと関連アプリケーションを変換する際、AWS Transformは「波（Wave）」という単位で段階的に処理を進めます。
各波の実行手順は以下の通りです。まずSQL Serverスキーマを変換し、テーブル、ビュー、インデックス、制約、ストアドプロシージャをPostgreSQL互換形式に変換します。次にAWS DMSを利用してSQL ServerからAurora PostgreSQLへデータ移行を行います。その後、Entity Framework、ADO.NET設定、接続文字列、埋め込みSQLを自動更新する.NETコード変換を実施。最後にAmazon EC2（Linux）またはAmazon ECS環境へのデプロイメントを実行します。
波の順序は、依存関係グラフに基づいてトポロジカルソートで決定されます。上流の依存関係が常に下流より先に変換され、互いに依存していないノード群は同一波で並列処理されます。
SQL ServerからPostgreSQLへの変換精度
技術者として気になるのは、実際にどこまで自動変換できるのかという点です。
サポートされるSQL Serverオブジェクトは幅広く、テーブルは1:1マッピング、ビューはSQL構文変換、インデックスは構文変換と名前生成、制約は大部分サポート、ストアドプロシージャはPostgreSQL関数への変換、トリガーはPL/pgSQL準拠形式への変換が行われます。
T-SQL固有の構文からPL/pgSQLへの変換も自動化されています。DECLARE文の処理、カーソルループのFOR...IN...LOOPへの変換、BEGIN...CATCHブロックのBEGIN...EXCEPTION...ENDへの変換など、主要なパターンに対応しています。
ただし、完全自動変換が難しいケースもあります。MERGE文はPostgreSQLでネイティブサポートされていないため、INSERT ON CONFLICT構文やUPDATE FROM DML、カーソルベースの手続き型実装に変換されます。GOTO文はBEGIN...ENDやLOOP...END LOOPに変換されます。
クロスデータベース通信（異種DBリンク）は限定的なサポートで、dblink拡張またはアプリケーションロジックでの対応が必要です。パーティション上への外部キー参照は非サポートで、制約削除とアプリケーション側での実装が必要になります。
Case-Insensitive文字列比較も別途対応が必要で、CITEXT型への変換やアプリケーション確認が必須です。
Entity Frameworkとの連携
データベース側の変換だけでなく、.NETアプリケーション側のデータアクセスコードも自動更新されます。
対応するEntity Frameworkバージョンは、EF 6.3〜6.5およびEF Core 1.0〜8.0（.NET 10まで対応）です。
自動更新対象としては、DbContext構成（SQL Server固有設定をPostgreSQLプロバイダに変更）、LINQクエリ（SQL Server特定のSQL生成をPostgreSQL互換SQLに変換）、接続文字列（Server=形式をHost=形式に変換）、マイグレーションファイル（PostgreSQL型システムに更新）が含まれます。
ASP.NET Web FormsからBlazorへの変換
2025年12月のリリースで追加された機能として、ASP.NET Web FormsからBlazor（ASP.NET Core）への自動UI変換があります。
変換対象は、ページコンポーネント（.aspx → .razor）、カスタムコントロール（.ascx → .razor）、マスターページ（.master → layout.razor）、設定ファイル（Web.config → appsettings.json）、アプリケーション初期化（Global.asax → Program.cs）です。
実装方式はServer-side Blazorコンポーネントとして実装されます（WebAssemblyではなく）。Web FormsのステートフルなモデルをBlazorのコンポーネントモデルに変換する際、イベントハンドラの署名変更やデータバインディング構文の変更など、細かい調整が必要になる部分もあります。
実績と現実的な効果
公式発表ではAir Canada、Experian、QAD、Teamfront、Thomson Reuters、Veriskなどの顧客が利用しているとされています。
Thomson Reutersの事例では、単一アプリケーションの変換期間が数ヶ月から2週間スプリントに短縮（約4倍の加速）、月次150万行のコード変換、運用コスト30%削減（Windows→Linux移行）、技術的負債50%削減という結果が報告されています。
QADの事例では、800Kの行コードを2週間で変換、月次18万行以上の自動変換を実現したとのことです。
ただし、これらは大規模な導入を行った先進的な顧客のケースであり、すべてのプロジェクトで同様の効果が得られるわけではない点には注意が必要です。
制限事項と対応リージョン
現時点での制限事項を整理しておきます。
対応リージョンは、2025年12月時点でUS East（N. Virginia）でのフルスタックWindows モダナイゼーション一般提供が開始されており、他リージョンへは将来的なサポートが予定されています（詳細な時間軸は未公表）。
対応SQL Serverバージョンは2008 R2〜2022（Express、Standard、Enterprise版）で、SQLServerはAWS Transformと同一リージョンのAmazon RDSまたはAmazon EC2上でホストされている必要があります。
.NET Framework 3.1以上を使っている場合、フルスタック直接対応は非対応で、まずAWS Transform for .NETで.NET 6以降にポートし、その後フルスタックWindows モダナイゼーションを適用する2段階のアプローチが必要です。
所感
AWS Transformに関して、自分なりに評価してみます。
強みとしては、3層（プレゼンテーション、アプリケーション、データベース）を統合的に変換できる点が挙げられます。個別ツールを組み合わせて手動で変換する従来のアプローチと比べ、依存関係の管理が格段に楽になります。波ベースの段階的変換と自動テスト生成も、大規模プロジェクトでのリスク軽減に効果的でしょう。
課題としては、完全自動化が難しいケース（MERGE文、GOTO、クロスDB通信など）への対応が必要な点があります。「Next Steps Markdown」として手動対応が必要な箇所はレポートされますが、複雑なビジネスロジックを含むストアドプロシージャは人間の判断が必要になるケースが多いと思われます。
また、リージョン制限がある点も気になります。日本リージョンでの提供時期は未定であり、クロスリージョンでの利用にはデータ転送のオーバーヘッドが発生します。
AWS Transformは万能ではありませんが、レガシーモダナイゼーションの「重い腰を上げる」きっかけとしては有効なツールになりそうです。特に、同質のアプリケーションが多数存在する環境では、学習効果によって変換精度が向上していく設計になっているため、初期投資に見合うリターンが期待できるでしょう。
