AWS Transform 本番運用 Vol1 — .NET/メインフレーム/VMwareをAIで近代化

1. モダナイゼーションの課題とAWS Transform全体像

1-1. 技術的負債の現状と放置コスト

企業システムを支えるレガシー資産の多くは、20年から40年以上の稼働歴を持つメインフレーム、Windows Server上の.NET Frameworkアプリケーション、そしてオンプレミスのVMware仮想化基盤です。これらは日々の業務を支えるミッションクリティカルな存在である一方、モダナイゼーションを阻む最大の障壁にもなっています。

技術的負債の放置が招くコストは多岐にわたります。まず、保守担当エンジニアの高齢化と人材市場からの縮退という「人的コスト」があります。COBOLやRPGを書けるエンジニアの確保は年々困難になっており、採用コストの上昇と属人化リスクが経営課題として浮上しています。次に、レガシーシステムはAPIを介した最新クラウドサービスとの連携が難しく、デジタルサービスの新機能追加に数か月を要するケースが後を絶ちません。さらに、ベンダーのサポート終了やパッチ提供停止に伴うセキュリティリスクの増大も深刻な問題です。

脱VMware文脈：Broadcom買収が引き起こしたライセンスコスト急増

2023年のBroadcomによるVMware買収完了後、ライセンス体系の大幅な変更が断行されました。従来の永久ライセンス販売が廃止されサブスクリプション型への強制移行が実施され、さらにCPUコア単位課金への変更が重なり、一部ユーザーは年間コストが数倍規模に膨らむ事態となりました。特に大規模VMware環境を抱える企業では、移行計画の策定が経営レベルの緊急課題となっています。こうした背景から、VMwareワークロードをAWSなどのクラウドへ移行する需要が急拡大しており、移行先環境での再稼働だけでなく、移行と同時にクラウドネイティブなアーキテクチャへ近代化する要望も高まっています。

脱メインフレーム文脈：COBOL保守人材の枯渇と運用コスト増大

金融・保険・公共分野を中心に、メインフレーム上のCOBOLシステムが今なお業務の中核を担っています。COBOL開発者の高齢化が進むなかで、退職による保守体制の崩壊が現実の問題となっています。加えて、メインフレームの運用コストはクラウド環境と比べて高く、I/O処理ごとの課金体系が業務量の増大とともにコスト上昇を招きます。単なるリホストにとどめず、ビジネスロジック自体をクラウドネイティブなJavaや.NETコードとして再生成する「コードモダナイゼーション」の需要が高まっているのはこのためです。

.NET現代化文脈：Windows依存からLinux・クロスプラットフォームへ

Windows Server上の.NET Frameworkは、2015年以降に登場したクロスプラットフォーム版.NETへの移行が業界全体の潮流となっています。.NET Frameworkはバージョン4.8を最後に機能追加が凍結されており、Linux上で動作する最新の.NETランタイムへ移植することで、Amazon ECS FargateやAWS Lambdaといったコンテナ・サーバーレス環境への展開が可能になります。Windows Serverライセンスの削減によるコスト改善と、Azure依存の解消という観点も、移行判断を後押しする要因です。

技術的負債放置の共通パターン

上記3文脈に共通するのは、「変えたいがリスクが高すぎる」という判断の停滞です。モダナイゼーションを先送りにする主な理由として、変換中のサービス停止リスク、テストが整備されていないことによる品質保証の困難さ、チームのスキル不足の3点が挙げられます。AWS Transformはこれらの課題に対して、自動テスト生成・変換計画のシミュレーション・人間のレビュー介在点の最小化という形で対応します。完全なリスクゼロは存在しませんが、従来の手作業アプローチと比べてリスクを定量的に管理できる点が最大の価値です。

また、現代のエンタープライズシステムにおいて、モダナイゼーションは単なる技術的なアップグレードではなく、事業戦略の一部です。競合他社がクラウドネイティブなインフラ上で機能リリースを加速する中、レガシーシステムに縛られた組織は市場への反応速度で不利な立場に置かれます。技術的負債の解消は、エンジニアリングチームの生産性向上だけでなく、プロダクトチームの機能追加速度、さらには顧客体験の改善にも直結します。AWS Transformへの投資は、このビジネス価値を念頭に置いて評価することが重要です。

1-2. AWS Transform の概要と沿革

AWS Transformは、エージェンティックAI（自律的に判断・行動するAIエージェント）を活用して大規模なレガシーコードベースを自動変換するモダナイゼーションサービスです。2025年5月15日に一般提供（GA）が開始されました。

沿革と改称の経緯

AWS Transformの源流は、Amazon Q Developerの一機能として2024年12月のre:Invent 2024でプレビュー発表された「transformation capabilities」にあります。2025年5月に独立したサービスとして改称・GA化され、Webブラウザベースのエクスペリエンスを通じてIDE操作なしに大規模な変換ができるようになりました。IDEプラグインへの依存をなくすことで、既存の開発ツールチェーンに手を加えることなく、クラウドコンソール上で変換ジョブを管理できます。

対応ワークロード3種類

AWS Transformが現在対応するワークロードは以下の3種類です。

• .NET：Windows Server上の.NET Frameworkアプリケーションを、Linux上のクロスプラットフォーム.NETに移植します。依存ライブラリの互換性チェックと自動変換を実施し、移植後のビルド・テスト実行まで自動化します。
• メインフレーム：COBOLなどのレガシー言語で書かれたプログラムを解析・ドキュメント化し、業務ロジックをJavaやマネージドランタイムへ変換します。RefactorとReimagineという2アプローチを提供します。
• VMware：VMware環境のインベントリ分析と依存関係マッピングを自動化し、AWS上への移行計画立案と設定変換を支援します。大量のVMを一括で分析して移行グループを自動提案します。

リージョン展開状況

ワークスペースのホームリージョンとして、米国東部（バージニア北部）、アジアパシフィック（ムンバイ・ソウル・シドニー・東京）、カナダ（中部）、欧州（フランクフルト・ロンドン）が対応しています。東京リージョン（ap-northeast-1）でもワークスペースを作成可能です。ワークスペースはAWSコンソールのAWS Transformサービス画面から作成でき、ワークロードの種類（.NET・メインフレーム・VMware）を選択してから変換ジョブを設定します。1つのワークスペースで複数のリポジトリや複数のワークロードを管理できます。

はじめ方の流れ

AWS Transformを初めて利用する際の一般的な流れは以下の通りです。

1. AWSコンソールにログインし、AWS Transformサービスを開きます。
2. ワークスペースを作成し、変換対象のワークロード種別を選択します。
3. ソースコードリポジトリ（.NETの場合はS3経由、メインフレームの場合は専用エージェント経由）をワークスペースに接続します。
4. 変換設定（ターゲットバージョン、変換オプション等）を行い、変換ジョブを開始します。
5. 変換結果レポートを確認し、自動変換済みコードと手動確認が必要な箇所を整理します。

利用開始時には無料の試用オプションを提供する場合があります。最新の利用条件と料金は公式料金ページをご確認ください。

AWSが公開する実績指標

AWSが公開している実績では、VMware移行において数万台規模のVM移行を支援し、処理済みコード行数は45億行以上、手作業削減時間は169万時間以上に達しています。処理速度は.NETで最大4倍、VMware依存性分析で最大80倍を実現したとされています。料金については公式料金ページをご参照ください。

1-3. エージェンティックAIモダナイゼーションの仕組み

AWS Transformが採用するエージェンティックAIとは、人間が手順を細かく指定しなくても、目標（例：このCOBOLプログラムをJavaに変換する）を与えるだけで、AIが自律的に計画を立て、コードを解析・変換・検証する一連のワークフローを実行する仕組みです。

従来の自動変換ツールとの最大の違いは、コードの意味論的理解です。ルールベースの変換ツールは構文パターンを機械的に置換しますが、AWS Transformのエージェントはビジネスロジックの意図を解析し、変換後のコードが元の振る舞いを保つかどうかを自動テストで確認します。変換の信頼度が低い箇所を特定してレポート化し、開発者のレビューが必要なポイントを明確にした上で変換を完了させます。

ワークフローの大枠は、アセスメント（既存コードの解析・依存関係の把握）、変換（コードの自動生成・書き換え）、検証（ビルド・テスト実行・差分確認）という3段階で構成されています。各段階でAIエージェントが自律的に作業を進め、判断が困難な箇所のみ人間にエスカレーションします。これにより、数十万行規模のコードベースでも、人手による全行レビューを経ずに変換を完了できます。

アセスメント段階

最初のアセスメント段階では、AIエージェントがソースコードリポジトリを解析し、コードの構造・依存関係・複雑度を把握します。.NETの場合はプロジェクトファイル（.csproj）とNuGetパッケージ依存を解析し、Linux非互換の箇所を特定します。メインフレームの場合はCOBOLプログラムのCALL連鎖・COPY句・VSAMアクセスパターンを解析します。VMwareの場合は仮想マシンのOS・CPU・メモリ・ネットワーク依存を分析します。

アセスメント結果は変換推奨レポートとして出力され、「自動変換可能」「手動確認が必要」「変換対象外」の3カテゴリで分類されます。このレポートを基に、変換スコープを確定し、工数を見積もります。

変換段階

変換段階では、エージェントがアセスメント結果を踏まえてコードを書き換えます。単純な構文変換にとどまらず、フレームワーク間のAPIマッピング（例：.NET Framework固有APIをクロスプラットフォーム.NET APIへの置換）、設定ファイルのフォーマット変換、ビルドシステムの移行（例：MSBuildプロジェクトファイルの更新）なども自動的に処理します。変換の途中でビルドエラーが発生した場合、エージェントは自律的にエラーを解析し、修正を試みます。

検証段階

検証段階では、変換後のコードに対してビルドと自動テストを実行します。既存のテストスイートが存在する場合はそれを活用し、変換前後でのテスト合格率を比較します。不合格のテストが発生した場合、エージェントは根本原因を特定し、追加修正するか、開発者向けにレビュー依頼を生成します。変換差分（diff）はプルリクエスト形式でレポートされ、変換前後のコードを並べて確認できます。

1-5. 本記事の読み方と対象読者

本記事は、AWS Transformを本番環境で活用しようとしているインフラ・アーキテクチャ担当者、アプリケーション開発リード、クラウド移行プロジェクトのプロジェクトマネージャーを主な対象としています。以下の読み方を推奨します。

• 全体像を把握したい方：本セクション（§1）と「§2 AWS Transformの基礎とエージェンティックAIワークフロー」を先に読んでください。
• .NET移行を検討中の方：「§3 .NETモダナイゼーション」に直接進んでください。
• メインフレーム近代化を検討中の方：「§4 メインフレーム近代化」を参照してください。
• VMware移行を検討中の方：「§5 VMware移行」から読み始めてください。
• Transform customと組織横断展開を検討中の方：「§6 Transform customとモダナイゼーション運用」を参照してください。
• migrationツール群やQ Developerとの使い分けを知りたい方：「§7 実戦統合パターン」と「§8 詰まりポイント・アンチパターン・まとめ」が参考になります。

前提となるAWS知識としては、IAMの基本、S3の操作、AWSコンソールへのアクセス経験があれば読み進められます。特定ワークロードの詳細については、各セクションの冒頭にその前提知識を記載しています。

1-4. migrationツール群・Q Developerとの棲み分けナビ

AWS Transformのユースケースは「既存のコードベースが大規模すぎて手作業では対応できない」「組織全体のリポジトリに一貫したモダナイゼーションを適用したい」「移行のたびに個別ツールを選定する煩雑さを解消したい」といった状況に最も合致します。次のセクションからは、エージェンティックAIが担うワークフローの詳細と、各ワークロードの変換アプローチを順に解説します。

一方、AWS Transformが適さないケースも理解しておくことが重要です。コードベースが数千行以内で手作業対応が現実的な場合や、変換品質の要件が非常に厳しく人間によるすべての行のレビューが必要な場合は、従来の手作業アプローチの方が適切な場合もあります。また、AWS Transformはモダナイゼーション専用サービスであるため、インフラのリホスト（VM/データベースをそのままクラウドへ移動させるだけ）はMGNやDMSが引き続き担います。

AWS Transformの最も効果的な活用シナリオは、「数万行以上の大規模コードベースを、限られた人手でモダナイゼーションしなければならない」という制約条件が揃ったときです。エージェンティックAIが反復作業の大半を担い、人間のエンジニアはビジネスロジックの確認と品質保証に集中できる体制を作ることができます。

適切な適用判断のためには、変換対象のコードベース規模・テストカバレッジ・チームのスキルセット・ビジネスの緊急度という4つの要素を評価した上で、AWS Transformの適用範囲を決定することを推奨します。

2. AWS Transformの基礎とエージェンティックAIワークフロー

2-1. エージェンティックAIとは何か

エージェンティックAI（Agentic AI）とは、人間が個別の手順を逐一指示しなくても、目標を与えるだけで自律的に計画・実行・検証のサイクルを回すAIワークフローです。AWS Transformは、このエージェンティックAIをモダナイゼーションの中核に据え、大規模なコードベースに対して自律的なコード変換・リファクタリングを行います。

従来のモダナイゼーション手法では、専門家がコードを手動で解析し、変換規則を個別に定義し、移行後の検証も逐一人手で行う必要がありました。数百万行規模のCOBOLコードや、数年にわたって積み上がった.NETの技術的負債を人手で扱うには、膨大なコストと時間が必要です。AWS Transformのエージェンティックアプローチは、この課題を根本から変えます。

エージェンティックAIワークフローの本質は、自律性と反復的改善にあります。AIエージェントは単純な1回の変換で終わるのではなく、変換結果を自己評価し、問題があれば修正しながら品質を高める反復プロセスを取ります。人間は最終承認ステップに集中するだけでよく、大量の単純変換作業から解放されます。

2-2. 基盤技術スタック

AWS Transformのエージェンティックワークフローを支える主要技術を整理します。

大規模言語モデル（LLM）とFoundational Models

AWS Transformの核心には、大規模言語モデル（LLM）が用いられています。コードの意味理解・変換ルールの生成・変換後コードの説明文生成まで、LLMが言語理解の層を担います。Amazonが開発・トレーニングしたFoundational Modelsを活用し、コードの構文だけでなく意味的な等価性を考慮してコードを変換します。

機械学習（ML）による依存関係解析

アプリケーション全体の依存関係グラフを構築するために、機械学習モデルが用いられます。クラス間の呼び出し関係・共有ライブラリへの依存・データフローの解析など、静的解析だけでは捉えにくい動的な依存関係もMLによって推定されます。これにより、移行スコープの見積もり精度が向上します。

グラフニューラルネットワーク（Graph Neural Networks）

特にメインフレームのCOBOLや.NETの大規模コードベースにおいて、プログラム構造をグラフとして表現し、グラフニューラルネットワーク（GNN）で解析します。GNNはプログラムの制御フロー・データフロー・コンポーネント間依存を同時に学習し、変換優先順位や技術的負債のホットスポットを特定します。

Automated Reasoning（自動推論）

変換後のコードが元のコードと意味的に等価であるかを検証するために、自動推論技術が使われます。単純なテストだけでは網羅できないコーナーケースも、形式的な検証手法に基づいて確認されます。特に数値計算・文字列処理・制御フローの複雑な組み合わせに対して有効です。

Comprehensive Codebase Analysis（2026年3月GA）

2026年3月に一般提供（GA）となったComprehensive Codebase Analysisは、コードベース全体のdeep static analysisを行い、以下の成果物を構造化して生成します。

• アーキテクチャ図と依存関係マップ
• 技術的負債の箇所とリスク評価
• コードメトリクス（循環的複雑度・行数・テストカバレッジ推定）
• 参照ドキュメントの自動生成（関数仕様書・モジュール説明）
• 移行計画の草案と優先度付け
• システム構成ダイアグラム

これにより、モダナイゼーション開始前にリスクを可視化し、移行計画の精度を大幅に高めることができます。

2-3. 3ワークロード概観と選択基準

AWS Transformは現在、3つの主要ワークロードを対象としています。それぞれの特徴と選択基準を概観します。

① .NETモダナイゼーション（Windows → Linux クロスプラットフォーム）

Windows専用の.NET Framework（4.x系）で動作するアプリケーションを、クロスプラットフォームの.NET（8.x以降）に移植します。コンテナ化・Linux動作によってWindows Serverライセンスコストを削減し、Fargate・EKS等のAWSコンテナ基盤への展開を容易にします。

選択基準として、.NET Frameworkに依存したWebアプリ・バッチ処理・WCFサービスが中心のシステムで、コンテナ化を目指す場合に適しています。Windows固有のAPI（COM・Windowsレジストリ等）に深く依存する場合は追加の変換コストが発生するため、アセスメントによる事前確認が重要です。

② メインフレーム近代化（COBOL → モダン言語）

IBMやUnisysのメインフレーム上で動作するCOBOL/PL/I等のレガシーコードを解析し、Java・Python等のモダン言語に変換します。2つのパターンがあります。

• Refactor（決定的変換）：COBOLの構造をそのままJava等に機械翻訳し、動作を維持しながらプラットフォーム依存を除去します。
• Reimagine（業務ルール抽出再構築）：COBOLから業務ロジックを抽出し、クラウドネイティブなアーキテクチャで再設計します。

Refactorはリスクを抑えた段階的移行に適します。Reimagineはアーキテクチャを根本から見直し、マイクロサービス化・API化まで視野へ含める場合に選択します。

③ VMware移行（VMware → AWS）

Broadcomによる買収以降のライセンス体系変更を背景に、VMwareワークロードをAWSに移行するニーズが急増しています。AWS Transformは、VMwareワークロードの依存関係解析・移行設計・ネットワーク構成の変換を支援します。vSphere・vCenterベースのオンプレミス仮想化基盤をAWSへ移行する場合に適しています。

ワークロード間の相互関係と選択基準整理

実際のエンタープライズ環境では、3つのワークロードを組み合わせるケースが多くあります。例えば、メインフレームのバックエンドと.NETのフロントエンドを連携させているシステムでは、両方を並行してモダナイゼーションする計画が必要です。AWS Transformは複数ワークロードの依存関係を横断的に解析し、統合的な移行計画を生成します。

2-4. アセスメントフェーズ詳解

アセスメントフェーズは、モダナイゼーションの成否を左右する最重要工程です。ここで精度の高い分析を行えるかどうかが、後続の変換品質に直結します。

アプリケーション発見と依存関係解析

対象コードベースをAWS Transformにインポートし、アプリケーション全体のスキャンを行います。以下の情報が自動的に収集・整理されます。

• ソースコードの行数・ファイル数・モジュール構成
• 外部ライブラリ・フレームワークの依存関係リスト
• データベース接続・テーブル参照の一覧
• サードパーティAPI・外部サービスとの連携点
• 循環依存・技術的負債のホットスポット

これらの情報は、移行の複雑さを定量的に評価するベースになります。大規模なモノリシックアプリケーションを対象にする場合は、事前にComprehensive Codebase Analysisを実施することで分析精度が大幅に向上します。

チャットによる業務目標・制約の指定

AWS TransformはWebベースのチャットインターフェースを通じて、担当者が移行方針を自然言語で指定できる仕組みを提供しています。チャットで指定する内容の例は以下のとおりです。

• モダナイゼーションの目標（コスト削減・コンテナ化・OSS化など）
• タイムラインと優先度（パイロット対象のモジュール選択）
• 制約条件（特定ライブラリの継続使用・特定APIバージョンの維持など）
• 除外対象（手動対応が必要なモジュールの明示）

自然言語での指定を受けてAIエージェントが解釈し、変換方針を自動的に調整します。コード変換の深い専門知識がなくても移行の方向性をコントロールできる点が、従来のツールとの大きな違いです。

移行計画の自動生成

アセスメント結果と指定された目標・制約をもとに、AIエージェントが移行計画のドラフトを自動生成します。生成される計画には以下が含まれます。

• モジュール別の変換難易度評価（Low / Medium / High）
• 推奨変換順序とスプリント計画の提案
• リスク項目と軽減策の提案
• 変換規模・複雑度に応じた参考コスト（料金の詳細はAWS公式料金ページをご参照ください）

2-5. 変換フェーズ詳解

変換フェーズでは、エージェンティックAIが自律的にコードを書き換えます。人間が個別の変換命令を与えるのではなく、AIエージェントが計画に基づいて変換を進め、問題が発生した場合は自己修正します。

自律的なコード変換・リファクタリング

AIエージェントは、アセスメントで生成した依存関係グラフと変換ルールセットを参照しながら、コードを変換します。単純な構文変換だけでなく、フレームワーク間のAPIマッピング（例：.NET FrameworkのWebClientから.NETのHttpClientへの変換）や、プラットフォーム固有処理の代替実装も行われます。

変換プロセスは反復的です。1回の変換で問題が残っている場合、エージェントは自己評価して修正変換を実行します。この反復サイクルにより、人手によるレビューの対象箇所が絞り込まれます。

依存関係処理

外部ライブラリの依存関係は、変換時の大きな課題の一つです。.NETの場合、.NET Frameworkにしか存在しないNuGetパッケージが多数あります。AWS Transformは以下のアプローチで依存関係を処理します。

• 互換性のある代替ライブラリへの自動置換
• 機能が存在しない場合のスタブ実装生成
• 手動対応が必要な依存関係のリストアップ（変換できない箇所を明示）

手動対応が必要な箇所はレポートとして出力され、開発者が個別に対応できるよう整理されます。

自動ユニットテスト生成

変換後コードの品質担保のために、AIエージェントが自動的にユニットテストを生成します。テストは以下の観点で作成されます。

• 主要なビジネスロジックのカバレッジ確保
• 境界値・エラーケースのテストケース
• 変換前後の動作等価性を検証するリグレッションテスト

生成されたテストは、CI/CDパイプラインに組み込んで継続的に実行されることを想定しています。

2-6. 検証フェーズ詳解

変換フェーズで生成されたコードの品質を検証するのが検証フェーズです。AIによる自動検証と人間のレビューを組み合わせたHITL（Human-in-the-Loop）設計が特徴です。

コード・インフラレビュー

変換後のコードは自動的にレビューにかけられます。レビューは以下の観点で行われます。

• コードの構文的正確性（コンパイルエラー・型エラーの不在確認）
• セキュリティ上の懸念点（脆弱なパターンの検出）
• パフォーマンスに影響する実装パターンの指摘
• コーディング規約の遵守確認（Transform customのカスタムルール適用）

HITL（Human-in-the-Loop）承認ステップ

自動変換・自動レビューの後、人間の最終確認ステップがあります。担当者はWebインターフェース上で以下を実施します。

• 変換されたコードの差分確認（変換前後の並列表示）
• 問題のある箇所へのコメント付与と修正指示
• 問題なければ変換結果のapprove
• 必要に応じた手動編集（直接コードを修正することも可能）

このHITLステップを設けることで、AIの自動変換に依存しすぎるリスクを抑えながら、大量の変換作業を効率化できます。

変換サマリ生成

承認完了後、変換全体のサマリが自動生成されます。サマリには以下が含まれます。

• 変換されたファイル数・行数
• 自動変換成功率（変換できた割合）
• 手動対応が必要だった箇所の一覧
• 生成されたテストケース数とカバレッジ推定

このサマリはステークホルダーへの報告資料としても活用できます。

プラットフォーム準備検証

変換後コードが対象プラットフォーム（コンテナ基盤・AWSネイティブサービス等）に対応できているかを確認します。コンテナ化が目標の場合は、Dockerfileやコンテナ設定の生成・検証も含まれます。本番デプロイ前の最終ゲートとして機能します。

2-7. アクセス方法と料金

アクセス方法

AWS Transformへのアクセスは、AWSマネジメントコンソール上のWebチャットインターフェースを通じて行います。コードベースのアップロード・設定・変換の進行管理・レビュー・承認まで、すべてこのインターフェースから操作できます。追加のIDEプラグインが不要で、ブラウザだけで完結する点が特徴です。

料金

AWS Transformの料金は、変換するコードの規模・複雑度・ワークロード種別によって変動します。変換量が少ないパイロット期間と全量変換期間では費用が大きく異なります。固定費として計画するのではなく、変換フェーズごとに見積もることを推奨します。最新の料金情報については、AWSの公式料金ページをご参照ください。

3. .NETモダナイゼーション

3-1. .NET Framework移行の背景と課題

.NET Frameworkは、Microsoftが2002年にリリースしたWindows専用のアプリケーション開発基盤です。長年にわたって多くのエンタープライズアプリケーションを支えてきましたが、近年ではWindows Server専用であることによるコスト負担と、クラウドネイティブへの移行を阻む技術的制約が顕在化しています。

主な課題は次の3点に集約されます。

第一に、Windows Serverライセンスコストです。AWS上でWindows Serverを動かすためには従量課金のライセンス料が発生し、Linuxベースの環境と比較して運用コストが大幅に高くなります。大規模なフリートを持つ組織では、このライセンスコストが年間で相当な金額に積み上がります。

第二に、Linuxコンテナへの移行障壁です。コンテナ化・マイクロサービス化を進めようとしても、Windows Serverコンテナの制約が足かせとなり、ECSやEKSのLinuxノードへの展開が難しくなります。コンテナイメージのサイズ・起動速度・コスト効率の面でも、Linuxコンテナと比較すると不利な状況に置かれます。

第三に、クロスプラットフォーム.NETへの移行コストです。.NET Framework 4.xから.NET 6以降への移植は、APIの非互換・WindowsフォームやWPFの扱い・SQL Server依存など複数の移行障壁が重なるため、手作業での対応には膨大な工数がかかります。数十万行規模のコードベースでは、専任エンジニアが数年をかけても完了しない例も珍しくありません。

AWS Transformの.NETモダナイゼーション機能は、これらの課題をAIエージェントが自律的に分析・変換することで、手作業に比べて最大4倍の速度での移行を実現します。

3-2. アセスメントフェーズ：依存解析とコード評価

移植の第一段階として、AWS Transformはコードベース全体のアセスメントを実施します。このフェーズは変換の成否を左右する重要なステップです。

依存関係グラフの構築

AIエージェントは対象プロジェクトが参照しているNuGetパッケージ・Windows レジストリAPI・COM依存・ファイルシステムパスをすべて特定し、依存関係グラフとして可視化します。この依存マップにより、変換時に影響を受けるコンポーネントの連鎖を事前に把握できます。

プロジェクト種別の自動判定

アセスメントでは、.NET Frameworkのバージョン（3.5以降が対象）・プロジェクトの種別（ASP.NET MVC・Web API・Web Forms・WinForms・WPF等）・データアクセス層（ADO.NET・Entity Framework 6.x・Dapper）を自動判定し、移行難易度をスコアリングします。

スコアリング結果は「変換自動化可能」「一部手動対応が必要」「手動対応必須」の3段階に分類され、変換ジョブを開始する前に工数見積もりを確認できます。

Visual Studio IDE統合

AWS TransformはVisual Studio拡張機能との統合により、開発者がIDEを離れることなくアセスメントと変換ジョブを起動できる開発者ワークフロー統合を提供しています。変換の進捗確認・差分レビュー・承認フローをすべてVisual Studio上またはWebコンソール上で完結できます。

3-3. 変換フェーズ：自動コード書き換えの仕組み

アセスメント完了後、AIエージェントが実際にコードを変換します。

ターゲットフレームワーク書き換え

.NET Frameworkから.NET 8（または.NET 10・LTS）へのターゲットフレームワーク移行を自動で実施します。csprojファイルのTargetFramework属性の書き換えから始まり、SDK形式に変換し、PackageReference形式への移行まで一括処理されます。

廃止API置換

System.Web・HttpContext等の.NET Framework専用APIをASP.NET Core対応APIへ置き換えます。主な置換パターンは以下のとおりです。

• HttpContext.Current → IHttpContextAccessor経由でのDI注入
• System.Web.HttpRequest → Microsoft.AspNetCore.Http.HttpRequest
• Global.asax → Startup.cs・Program.csのミドルウェアパイプライン
• web.config → appsettings.json・環境変数ベースの設定
• MembershipProvider → ASP.NET Core Identityまたは外部IdP連携

Windows固有APIのLinux互換変換

Windows レジストリへのアクセス・P/Invoke呼び出し・Windows権限API等、Linux上で動作しない実装はクロスプラットフォーム互換の実装へ変換されます。

代表的な変換パターンを示します。

変換前（.NET Framework）：

using Microsoft.Win32;

var key = Registry.LocalMachine.OpenSubKey(@"SOFTWARE\MyApp");
var setting = key?.GetValue("ConnectionString")?.ToString();

変換後（.NET 8 / Linux互換）：

using Microsoft.Extensions.Configuration;

var setting = _configuration["ConnectionString"];

Windows レジストリへのアクセスはIConfiguration抽象化を介した環境変数・appsettings.jsonへのアクセスに置き換えられます。これにより、コンテナ環境や12-factor appの原則にも準拠した実装になります。

ASP.NETのコントローラーコードも、ASP.NET CoreのControllerBaseを継承した形式へと変換されます。

// 変換前: System.Web.Mvc を使用
public class HomeController : System.Web.Mvc.Controller
{
 public ActionResult Index()
 {
  return View();
 }
}

// 変換後: Microsoft.AspNetCore.Mvc を使用
public class HomeController : Microsoft.AspNetCore.Mvc.Controller
{
 public IActionResult Index()
 {
  return View();
 }
}

3-4. SQL Server → Aurora PostgreSQLの依存変換

データベース依存の変換もAWS Transformの重要な機能の一つです。

SQL Server固有の構文（T-SQL・ストアドプロシージャ・トリガー等）をAurora PostgreSQL互換の構文へ変換することで、SQL Serverライセンスを排除したフルマネージドのデータベース環境への移行をサポートします。

Entity Framework CoreのDbContextおよびSQL Serverプロバイダーも、Npgsql（PostgreSQLプロバイダー）への自動切り替えを行います。

// 変換前: SQL Server プロバイダー
services.AddDbContext<AppDbContext>(options =>
 options.UseSqlServer(connectionString));

// 変換後: Aurora PostgreSQL (Npgsql) プロバイダー
services.AddDbContext<AppDbContext>(options =>
 options.UseNpgsql(connectionString));

T-SQLのストアドプロシージャについては、PostgreSQL互換のPL/pgSQL形式への変換が自動適用されます。GETDATE()→NOW()・TOP N→LIMIT N・NOLOCKヒントの除去等、SQL方言の差異を吸収する変換が実施されます。

3-5. サポート対象フレームワーク一覧

AWS Transformの.NETモダナイゼーションがサポートする対象フレームワークと種別は以下のとおりです。

3-6. 移行ステップの全体像

AWS Transformを使った.NET移行は、次の3段階で進めます。

ステップ1: アセスメント（依存解析・コード評価）

1. AWS TransformのWebコンソールまたはVisual Studio拡張機能でプロジェクトをアップロードします
2. AIエージェントが依存グラフを構築し、移行難易度と工数の見積もりを生成します
3. アセスメントレポートを確認し、変換対象を確定します

ステップ2: 変換（自動コード書き換え）

1. アセスメント結果をもとに変換ジョブを起動します
2. AIエージェントがコード変換・設定ファイル移行・パッケージ更新を自動実行します
3. 変換差分をコンソール上またはVisual Studio上でレビューし、必要に応じて手動修正を加えます

ステップ3: 検証（テスト・確認）

1. 変換後のコードをCI/CDパイプラインでビルド・テストします
2. 統合テスト・エンドツーエンドテストを実施し、動作を確認します
3. 検証が完了したら、LinuxベースのインフラへデプロイしてWindowsインスタンスを廃止します

3-7. CI/CDパイプライン統合

変換後のコードは、CodeCommit・CodeBuild・CodePipeline等のAWS DevOpsサービスと統合したCI/CDパイプラインへの組み込みを推奨します。変換ジョブ完了後、自動でビルド検証・ユニットテスト実行・Lintチェックが走るパイプラインを構築することで、変換品質を継続的に担保できます。

GitHub ActionsやAzure DevOpsとの連携も可能で、既存のCI/CD基盤を大きく変えることなく変換後のビルドフローを統合できます。パイプライン定義にLinuxベースのビルドエージェントを指定するだけで、変換後の.NETプロジェクトをLinux環境でビルド・テストできます。

# GitHub Actions の例（変換後のビルド検証）
jobs:
  build:
 runs-on: ubuntu-latest
 steps:
- uses: actions/checkout@v4
- uses: actions/setup-dotnet@v3
  with:
 dotnet-version: '8.0.x'
- run: dotnet build --configuration Release
- run: dotnet test --no-build --verbosity normal

3-8. 速度・コスト効果

公式の発表によると、AWS Transformによる.NET移行は手作業と比較して最大4倍の速度で完了します。コスト面では、Windows Serverライセンスを最大40%削減でき、LinuxベースのEC2への移行によりインスタンス運用コストを最大70%削減できます。

これらの数値はあくまでも参考値であり、実際の効果はアプリケーションの規模・複雑性・移行対象のコード品質によって異なります。料金の詳細については、AWS公式料金ページを参照してください。

エンタープライズ規模での移行では、手作業で数千時間を要した変換プロジェクトがAWS Transformの活用により大幅に圧縮された事例が複数報告されています。これは、アセスメントの自動化による見積もり精度の向上と、コード変換の自動化による反復作業の削減によるものです。

4. メインフレーム近代化

メインフレーム近代化は、金融機関・政府機関・大企業にとって長年の課題です。AWS Transformは、COBOL/VSAM/DB2を中心とするレガシー資産をクラウドネイティブ技術へ移行するための包括的な機能を提供しています。

4-1. レガシー資産の解析とドキュメント生成

近代化を急ぐ背景

メインフレームを維持するうえで、複合的なリスクが積み重なっています。

第一にCOBOL保守エンジニアの急減です。米国では2022年時点でCOBOLエンジニアが約20万人在籍している一方、その平均年齢は60歳を超えています。今後10年で大量退職が見込まれており、後継者の確保が困難な状況です。日本でも同様の構造変化が進んでいます。

第二にライセンスおよび保守コストの増大です。メインフレームのMIPSベースのライセンスは、ワークロードの増加に比例してコストが跳ね上がります。クラウドへの移行によって、変動費型の従量課金モデルへ切り替えることが可能になります。

第三に技術負債の蓄積です。数十年にわたって手を加えられてきたCOBOLコードは、業務ロジックが多層化し、テスト・変更・拡張のコストが膨大になっています。新機能のリリースサイクルが数ヶ月単位に及ぶことも珍しくありません。

AWS Transformによるレガシー資産の解析

AWS Transformは、対象となるメインフレーム資産を取り込み、包括的な解析を実施します。

対応するレガシー技術の範囲:

依存関係の可視化:

AWS Transformは、ソースコードを静的解析し、以下の依存グラフを自動生成します。

• プログラム間依存: CALL文・COPY句によるモジュール呼び出し関係をグラフで可視化します。
• データセット依存: 各プログラムが読み書きするVSAMファイル・DBテーブルのマッピングを行います。
• JCLジョブネット: バッチジョブの実行順序・先行後続関係・条件分岐を解析します。
• 画面定義(BMS/MFS): CICSトランザクションに紐づく画面マップを特定します。

この依存グラフは、移行スコープの見積もりやパイロット選定の基礎データとして活用します。

ドキュメントの自動生成:

従来、COBOLシステムはドキュメントが失われているケースが多く、「コードが唯一の仕様書」という状況に陥りがちです。AWS Transformは、コード変換と並行して以下のドキュメントを自動生成します。

• 業務ロジックを自然言語で記述した技術仕様書
• プログラムの処理フローを図示した業務フロー図
• データ項目の定義と変換マッピングを記載したデータ辞書

これらのドキュメントは、テスト設計や変換後システムの引き継ぎ時にも有用です。移行プロジェクトのステークホルダーへの説明資料としても活用できます。

変換プロセスの短縮効果:

従来の手作業による移行では、数十万行のCOBOLを変換するのに数ヶ月から数年を要することがありました。AWS Transformはエージェンティックなワークフローによって解析・変換・ドキュメント生成を自動化し、このプロセスを数分〜数時間単位にまで短縮します。

4-2. RefactorとReimagineの2パターン

AWS Transformのメインフレーム近代化は、組織のゴールとリスク許容度に応じて2つの変換パターンを選択できます。

Refactor（決定的変換）

Refactorは、COBOLコードを構造的に等価なJavaコードへ1対1に変換するアプローチです。業務ロジックをそのまま保持しながら、実行基盤をクラウドへ移行します。

変換の対応関係:

Refactorのメリット:

• リスクが最小: 業務ロジックを変換しないため、機能的同等性が確保しやすいです。
• 変換速度が最大: 決定的変換により短期間で移行を完了できます。
• テスト工数の削減: 変換前後の出力比較テスト（Regression Test）が実施しやすく、テストケースを従来資産から再利用できます。
• モノリス構造を維持: マイクロサービスへの分割はせず、まずクラウドへ移行するため、アーキテクチャ変更のリスクを切り離せます。

Refactorのデメリット:

COBOLの構造的な特性（GOTOやグローバルデータ区域など）はそのままJavaコードへ移植されるため、変換後コードの可読性が低下する点には注意が必要です。クラウドネイティブなスケーラビリティや疎結合設計は、後工程でリファクタリングする必要があります。

向いているケース:

• まずメインフレームの廃止とライセンスコスト削減を最優先にしたい場合
• 業務ロジックが複雑で、一度に再設計するリスクを取れない場合
• 数ヶ月以内のアジャイルな移行を求められる場合

Reimagine（業務再構築）

Reimagineは、COBOLコードをそのまま変換するのではなく、リバースエンジニアリングによって業務ルールを抽出し、クラウドネイティブなマイクロサービスとして再構築するアプローチです。

Reimagineのプロセス:

1. 業務ルールの抽出: AWS Transformのエージェンティック解析が、COBOLコード内に埋め込まれた計算ロジック・条件分岐・データ変換ルールを識別します。
2. ドメインモデルの設計: 抽出した業務ルールをもとに、ドメイン駆動設計(DDD)の観点で境界コンテキストを定義します。
3. クラウドネイティブアーキテクチャへの再設計: Amazon ECS・Lambda・API Gatewayなどを組み合わせたマイクロサービス構成を設計します。
4. コード生成と検証: 設計に基づいて新規コードを生成し、業務ルールの等価性を検証します。

Reimagineのメリット:

• クラウドネイティブの設計原則（疎結合・独立デプロイ・自動スケーリング）を最初から取り込めます。
• 技術負債を一掃し、将来の機能追加や変更コストを大幅に削減できます。
• モダンな開発プラクティス（CI/CD・コンテナ・IaC）を自然に適用できます。

Reimagineのデメリット:

業務ロジックの抽出と再設計に伴うリスクが高く、プロジェクト期間も長くなります。暗黙の業務ルール（コメントなし・仕様書なし）の特定が困難で、移行後に差異が発見されるリスクもあります。大規模なテスト設計と検証工数が必要になります。

向いているケース:

• クラウドネイティブへの完全移行を目指しており、移行後の運用改善効果を最大化したい場合
• 業務プロセスの再設計や効率化と合わせて近代化を進めたい場合
• 長期プロジェクトとしてフェーズを分けて取り組める体制がある場合

4-3. 段階的移行のサポート

メインフレームの全資産を一括で移行するのは現実的に困難です。AWS Transformでは、リスクを管理しながら段階的に移行を進める仕組みを提供しています。

パイロットプログラムの選定

最初のステップは、移行対象の全プログラムからパイロットとして試行するプログラムを選定することです。選定基準の例を以下に示します。

• 依存性が少ないプログラム: 他のプログラムやデータセットへの依存が少ないほど、移行スコープが絞りやすくなります。
• バッチ処理が中心のプログラム: オンライントランザクション処理より、バッチ処理の方が移行の検証がシンプルです。
• ビジネスクリティカル度が中程度のプログラム: 障害時の影響が限定的なプログラムから始めることで、リスクを抑えられます。

依存関係の可視化データを活用することで、客観的な選定基準に基づいたパイロット選定が可能です。

リスク評価と移行計画

パイロット移行の結果をもとに、残りのプログラムをリスク評価して移行計画を策定します。

• 高リスク: 暗黙のロジックが多く依存関係の複雑な場合・トランザクション量の多い場合
• 中リスク: ドキュメントが一部存在し、バッチ中心で依存範囲の限定的な場合
• 低リスク: 独立性の高いプログラムで、テストデータも揃っており処理の単純な場合

リスク評価に基づいて移行順序を決め、フェーズごとに段階展開することが推奨されます。

テスト戦略

変換前後の機能的同等性を保証するために、体系的なテスト戦略が必要です。

変換前後の出力比較（Regression Testing）:

AWS Transformは、変換前のメインフレーム側と変換後のAWS側で同一の入力データを投入し、出力結果を比較する差分テストをサポートしています。桁数・小数点・日付フォーマットなど、COBOL特有の計算特性に由来する差異の検出が重要です。

自動テストスイートの生成:

変換プロセスの中で、ユニットテストおよびインテグレーションテストのスケルトンを自動生成します。これにより、テスト設計の初期工数を削減し、テストカバレッジの確保を支援します。

パフォーマンス検証:

メインフレームはバッチ処理の高スループットに最適化されています。移行後のAWS環境でも同等以上のスループットを達成できているか、負荷テストによる検証が不可欠です。

実際の移行で直面する課題と対処

暗黙の業務ロジックの特定:

数十年間改修を続けたCOBOLコードには、設計書にも記述されていない暗黙の業務ルールが埋め込まれている場合があります。AWS Transformのエージェンティック解析はコードパターンから業務ルールを推論しますが、移行担当者による最終確認が必要です。COBOLに精通した業務有識者と連携し、疑義のある箇所を重点的にレビューするプロセスを設けることが重要です。

環境依存コードの処理:

メインフレームに固有の命令（ハードウェア操作・OSサービス呼び出しなど）は、変換後のJava環境では等価な実装を持たないことがあります。このようなコードは変換対象から除外し、AWS側での代替実装（例: SMFログの代替としてCloudWatch Logs、TSO/ISPFの代替としてWebツール）を設計する必要があります。

文字コードとデータ型の変換:

メインフレームはEBCDIC文字コードを使用しており、ASCII/UTF-8への変換でデータの不整合を招く場合があります。特に全角文字・特殊記号・数値のゾーン形式（Zoned Decimal）・パック形式（Packed Decimal）の取り扱いは、変換設計で明示的に定義することが必要です。

5. VMware移行

5-1. VMwareワークロードを取り巻く環境変化

Broadcom買収とライセンス体系の急変

2023年、米Broadcom社がVMware社を買収したことで、VMware製品のライセンス体系は大きく変わりました。
2024年以降、Broadcomは段階的に新たなライセンス体系への移行を推進しており、
既存のVMwareユーザーへの影響が広がっています。

サブスクリプション強制移行

従来の永続ライセンス販売が終了し、年間サブスクリプション契約への移行が求められるようになりました。
これまで一度購入すれば長期にわたって利用できた永続ライセンスモデルが廃止されたことで、
ライセンス料の継続的な支払いが義務付けられる形に変わっています。

バンドル強制による購入単位の変化

個別製品単位での購入が原則廃止され、vSphere・vSAN・vCenterなどを含む
バンドル製品（VMware Cloud Foundation等）での提供へと移行しました。
利用していないコンポーネントも含めて購入せざるを得なくなったことで、
特に中小規模の環境では、不要なライセンス費用の発生ケースが増えています。

コスト増の実態

一部の報告では、Broadcom移行前後でライセンスコストが数倍から数十倍になるケースも確認されています。
コスト変動の大きさは環境規模・製品構成・既存契約内容によって大きく異なります。
自社環境の実際のコスト影響については、Broadcomの正式な見積もりプロセスを通じて確認することをお勧めします。

vSphereサポート期限と保守計画への影響

既存バージョンのvSphereに対するサポート期限が変更されたことで、
アップグレードや保守計画の見直しを迫られる企業が増えています。
サポート期限切れのバージョンを継続利用すると、脆弱性対応や障害サポートを受けられなくなるリスクがあります。
保守計画の立案に際しては、Broadcom公式のサポートライフサイクル情報を必ず確認してください。

移行需要の高まり

このような状況を背景に、VMware環境からAWSへの移行を検討する企業が増加しています。
オンプレミスで運用してきたVMwareワークロードをAWSに移行することで、
ライセンスコストの削減だけでなく、クラウドネイティブなサービスの活用やスケーラビリティの向上も期待できます。

AWS Transformは、こうしたVMware移行の需要に応えるため、
2025年5月にVMwareワークロード移行機能を一般提供（GA）しました。
エージェンティックAIが移行の各工程を自動化することで、大規模なVM群をまとめて効率的に移行できます。

5-2. AWS TransformによるVMware移行機能（2025-05 GA）

機能概要

AWS TransformのVMware移行機能は、オンプレミスのVMware環境で動作している仮想マシン（VM）を
Amazon EC2インスタンスへ移行するプロセスを自動化します。
エージェンティックAIが移行の各工程を担い、手動移行と比べて最大80倍の速度で移行を完了できるとされています
（VMwareワークロードの種類・規模・環境条件によって異なります）。

主な機能は以下のとおりです。

VMwareワークロードのEC2移行

vSphere上で稼働する仮想マシンを、AWS Transformが分析・変換し、EC2インスタンスとして再展開します。
OSイメージの変換、ディスクのマイグレーション、ブートローダーの調整などの工程が自動化されます。

ネットワーク構成の変換

VMware環境で定義されたネットワーク構成（VLANやポートグループなど）を、
AWS上のVPC・サブネット・セキュリティグループなどに変換します。
エージェンティックAIがネットワーク依存関係を解析し、移行後もアプリケーション間通信が
維持されるよう変換マッピングを自動生成します。

大規模移行の自動化

数万台規模のVMを管理している大規模環境においても、AWS Transformの自動化フローにより
移行作業を並列化・効率化できます。
個別のVMを一台ずつ手動で移行する方法と比べ、アセスメント・変換・検証の一連の工程を
一括処理できるため、移行プロジェクト全体の工期短縮に貢献します。

5-3. 移行ステップ詳解

ステップ1: VMware環境のアセスメント

移行の第一歩は、既存VMware環境の全体把握です。
AWS Transformは以下の情報を収集・分析してアセスメントレポートを生成します。

• VM一覧と稼働状況: vCenterに接続し、対象環境内の全VMのリスト・稼働状態・リソース使用状況を取得します
• 依存関係の解析: VM間の通信パターンやアプリケーション依存関係を分析し、
  一緒に移行すべきワークロードグループ（移行波：Migration Wave）を特定します
• スペックの調査: CPU・メモリ・ストレージのスペックと実際の使用率を把握し、
  移行先インスタンスタイプ選定の根拠データとして活用します
• 互換性チェック: vSANやNSXなど高度なVMware機能の利用有無を確認し、
  AWSでの対応方法や追加作業の必要性を事前に洗い出します

アセスメントの結果は可視化レポートとして出力され、
移行計画の策定や関係者向けの説明資料として活用できます。

ステップ2: 移行先EC2インスタンスタイプ選定

アセスメント結果をもとに、各VMに最適なEC2インスタンスタイプを選定します。

CPU・メモリ比率の近いインスタンスファミリーを優先的に候補として提示し、
実際の使用率データを参照してオーバースペックを回避した選定が可能です。
また、移行後のコスト最適化を見据えて、リザーブドインスタンスやSavings Plansの
適用可能性についても、このタイミングで概算を把握しておくことをお勧めします。
なお、インスタンスの料金やSavings Plansの割引率については、公式料金ページを参照してください。

ステップ3: AWS Transformによる自動変換・移行

インスタンスタイプが決まったら、AWS Transformによる自動変換・移行を開始します。

1. エージェンティックAIによる変換計画の生成: TransformがVMイメージの変換手順・ネットワーク構成の
   変換マッピング・移行後の検証シナリオを含む移行計画を自動生成します
2. VMイメージの変換: vSphere上のVMディスク（VMDK形式）をAWS対応形式に変換し、
   EC2用のAMI（Amazon Machine Image）として登録します
3. ネットワーク構成の展開: 変換されたVPC構成・セキュリティグループ・ルーティング設定を
   AWSアカウント上に展開します
4. EC2インスタンスの起動: 生成されたAMIから指定インスタンスタイプのEC2インスタンスを起動し、
   移行後の環境を構築します

ステップ4: 移行後の検証・最適化

移行完了後は、アプリケーションの動作確認と最適化を実施します。

• 動作検証: 移行前と同等のテストシナリオで動作確認を行い、
  機能面・パフォーマンス面に問題がないことを確認します
• パフォーマンスチューニング: EC2インスタンスのCPU・メモリ使用率を継続的に監視し、
  必要に応じてインスタンスタイプの変更やEBSボリュームの最適化を実施します
• コスト最適化: 稼働状況が安定したタイミングで、リザーブドインスタンスや
  Savings Plansへの切り替えを検討します

5-4. 関連サービスとの連携・使い分け

VMware Cloud on AWSからの移行パターン

VMware Cloud on AWS（VMC on AWS）を既に利用している場合は、
オンプレミスから直接移行するケースとは異なる移行パターンが存在します。
VMC on AWSはすでにAWSインフラ上で稼働しているため、
EC2移行の際に物理的なデータ転送を最小化できるケースがあります。
段階的な移行戦略として、まずVMC on AWSに移行したうえで、
その後EC2ネイティブ環境への移行を進めるアプローチも選択肢のひとつです。

AWS MGN（Application Migration Service）との使い分け

VMware移行に際しては、AWS TransformとAWS MGN（Application Migration Service）の
使い分けを理解しておくことが重要です。

シンプルなリホストが目的であればAWS MGNを、
ネットワーク構成の再設計やVMware固有設定の変換が必要な場合はAWS Transformを優先的に検討してください。
両サービスを組み合わせて使うことも可能であり、ワークロードの特性に応じた使い分けをお勧めします。

EC2移行後のコスト最適化

VMwareライセンスコストからの削減効果を最大化するには、
EC2移行後のコスト最適化策を計画的に実施することが重要です。

• リザーブドインスタンス（RI）: 1年または3年の使用コミットにより、
  オンデマンド料金から大幅な割引を受けられます。
  安定稼働が見込めるワークロードに有効です（割引率は公式料金ページを参照してください）
• Savings Plans: リザーブドインスタンスよりも柔軟なコミットメント形式で、
  インスタンスタイプやリージョンを変更しながら割引を享受できます
• AWS Compute Optimizerとの連携: EC2の使用状況を継続的に分析し、
  インスタンスタイプの適正化提案を受けることで、移行後もコストを最適な水準に保てます
• コスト可視化: AWS Cost ExplorerでVMwareライセンス費用との比較分析を行い、
  実際の削減効果を定量的に把握することをお勧めします

5-5. 実績・注意事項・TCO比較の考え方

移行実績

AWS Transformを活用したVMware移行では、数万台規模のVM移行実績が報告されています。
大規模な仮想化環境を持つエンタープライズ企業において、
移行工期の大幅な短縮とライセンスコスト削減を両立した事例が積み重なっています。

ライセンスコスト試算：Broadcom移行前後のTCO比較

移行の意思決定を行う際には、Broadcom移行前後のTCO（総所有コスト）比較が欠かせません。
以下の観点でコストを整理することをお勧めします。

移行前（オンプレミスVMware継続）のコスト要素

• VMwareライセンス費用（Broadcom新体系の年間サブスクリプション）
• ハードウェア調達・保守費用（サーバー・ネットワーク機器）
• データセンター運用費用（電力・冷却・スペース）
• 運用要員コスト（インフラ担当者の工数）

移行後（AWS EC2）のコスト要素

• EC2インスタンス費用（オンデマンドまたはリザーブドインスタンス/Savings Plans）
• EBSストレージ費用
• データ転送費用
• AWSサポート費用（Business/Enterpriseサポートを利用する場合）
• Windowsライセンス（License Includedインスタンスを利用する場合は別途購入不要）

TCO比較の数値は、環境規模・利用ワークロード・リージョン・割引形態によって大きく変わります。
正確なコスト試算はAWS Pricing Calculatorを活用し、
必要に応じてAWSのアーキテクトや担当者へ相談することをお勧めします。

高度なVMware機能の注意事項

以下のVMware高度機能については、AWS移行時に別途対応が必要となる場合があります。
移行計画の初期段階で利用機能を洗い出し、対応方針を決定しておくことが重要です。

vSAN（Virtual SAN）

vSANはVMware独自の分散ストレージ機能です。
EC2移行後はAmazon EBSやAmazon FSx for NetApp ONTAPなどの
AWSネイティブストレージサービスへの置き換えを検討します。
ストレージ性能要件に応じて、io2 BlockExpressなどの高I/Oタイプのボリュームも選択肢となります。

NSX（ネットワーク仮想化）

NSXが提供する高度なマイクロセグメンテーションやL7ファイアウォール機能は、
AWS上ではVPCセキュリティグループ・AWS Network Firewall・AWS Transit Gatewayなどを
組み合わせた設計で代替します。
NSXの設定内容をそのままAWSに持ち込むことはできないため、ネットワーク設計の再検討が必要です。
移行前にNSXのポリシー設計をドキュメント化し、AWSの対応機能への変換マッピングを作成しておくことをお勧めします。

vMotion/DRS（動的リソース割り当て）

VMwareのvMotionによるライブマイグレーション機能は、EC2では直接対応していません。
スケーリングの自動化にはEC2 Auto ScalingグループやAWS Fargateなど、
クラウドネイティブなスケーリング機構への置き換えを検討してください。
これにより、VMware依存の運用から脱却しつつ、より柔軟なスケーリングを実現できます。

これらの高度機能への対応が必要な場合は、AWS Transformの移行計画フェーズで
早期に洗い出し、追加設計の工数を移行スケジュールに組み込むことが重要です。
事前の十分なアセスメントにより、移行後の想定外トラブルを防ぐことができます。

6. Transform customとモダナイゼーション運用

6-1. Transform customによるカスタム変換

Transform customは、2025年12月に一般提供（GA）された機能で、AWS Transformに組織独自の変換ルールを定義・適用できるようにします。標準的な変換パターンに加え、自社固有のコーディング規約・ライブラリ移行ルール・リファクタリングパターンをカスタム変換として設定することで、数百から数千規模のリポジトリへ一貫した変換を自動適用できます。

対応言語

Transform customが対応するカスタム変換の対象言語は以下の通りです。

• Java：Javaバージョンアップグレード（例：Java 8 → Java 21）および任意のカスタム変換パターン。
• Node.js：Node.jsバージョンアップグレードおよびモジュール移行（CommonJS → ESModules等）のカスタム変換。
• Python：Pythonバージョンアップグレード（例：Python 2 → Python 3）および任意のカスタム変換パターン。

これらの言語では、バージョンアップグレードを出発点として、さらに組織独自のAPIや内部ライブラリへの移行ルールも定義できます。

カスタム変換の定義方法

カスタム変換ルールは、以下の3つの入力形式で定義できます。

1. ドキュメント（自然言語）：移行したいルールを日本語・英語などの自然言語で記述します。例として「内部ログライブラリ com.example.Logger をSLF4Jに置き換える」という記述から、Transform customが変換パターンを自動的に学習します。
2. コードサンプル（before/after形式）：変換前のコードと変換後のコードのペアを提示することで、AIがパターンを学習します。同一ルールに対して複数のサンプルを提示するほど変換精度が向上します。
3. 組み合わせ：自然言語とコードサンプルを組み合わせることで、複雑なルールも精度高く定義できます。ドキュメントで意図を説明し、コードサンプルで具体的な変換形式を示すアプローチが実践的です。

スケールと実行時間の削減効果

Transform customは、一度定義したルールを数百から数千のリポジトリに一斉適用できます。従来の手作業による移行では、リポジトリ数に比例して作業量が増大しますが、Transform customでは変換ルールさえ定義すれば追加のリポジトリへの適用コストはほぼゼロです。

AWSの公開情報によると、Transform customの適用により変換実行時間を最大80%削減できるとされています。これは、AIが一度学習したパターンを高速に適用するためです。

学習機能：明示的フィードバックと暗黙シグナル

Transform customは継続的に変換品質を向上させる学習機能を備えています。

• 明示的フィードバック：開発者が変換結果を「承認」または「修正」すると、そのフィードバックが即座にルールの精度向上に反映されます。承認された変換パターンの重みが高まり、修正された変換は次回から避けられるようになります。
• 暗黙シグナル：開発者が変換後のコードを手動で修正した場合、その修正内容を暗黙のフィードバックとして検出します。「AIが変換したコードをこのように直した」という実績が蓄積されることで、次回以降の変換ではその修正済みパターンが適用されます。

このフィードバックループにより、組織の変換基盤は使うほどに精度が向上し、初期設定の段階で完璧な定義が必要ないという設計になっています。

6-2. 組織導入設計とガバナンスフレームワーク

パイロット選定から段階的展開へ

Transform customを組織全体に展開する際は、段階的なロールアウトが推奨されます。以下のロードマップが一般的な導入パターンです。

1. パイロット選定（フェーズ1）：対象リポジトリの中から、規模が中程度で、テストカバレッジが比較的高く、業務への影響が限定的なリポジトリを2〜3件選定します。パイロットでは変換ルールの有効性と変換品質を検証します。
2. ルール精緻化（フェーズ2）：パイロット変換の結果を基に、変換ルールを見直します。コードサンプルを追加したり、自然言語定義を補強したりして、標準変換への到達率を計測します。
3. グループ展開（フェーズ3）：精緻化されたルールを用いて、10〜30リポジトリ規模のグループに展開します。各グループ変換後に品質を確認し、問題があればルールを再調整します。
4. 全体展開（フェーズ4）：グループ展開で品質を確認後、残りの全リポジトリへ一斉適用します。

変換品質管理と承認ゲート設計

大規模展開時の品質管理には、承認ゲートの設計が重要です。各変換ジョブ完了後に以下の確認項目を設けることを推奨します。

未変換箇所（AIがパターンを特定できなかった箇所）は変換レポートに一覧化されます。この箇所は手動対応が必要なため、変換ロードマップに手動作業分の工数を見積もっておくことが重要です。

ガバナンス上の注意点

• 変換ルールのバージョン管理：ルール定義はコードと同様にGitなどでバージョン管理します。誰がいつどのルールを変更したかを追跡できる体制を整えます。
• 本番リリース前の検証環境：変換後のコードは必ず開発・ステージング環境でのE2Eテストを経てから本番リリースします。AIによる変換も100%の正確性を保証するものではないため、人間による最終確認を省略しないことが重要です。
• 変換対象外の明示：業務上の理由やセキュリティ要件により変換対象から除外するリポジトリ・コードは、明示的にスコープ外として定義します。

6-3. コスト管理・監視・可観測性

料金体系の考え方

AWS Transformの料金は対応ワークロードごとに異なり、実際の単価は変動する場合があります。最新の料金は公式料金ページを必ずご確認ください。ここでは、料金を検討する際の考え方を整理します。

コスト試算の主な軸として以下の要素があります。

• 変換対象のコード量またはVM台数：処理するコード行数・ファイル数・VMのvCPU数などが課金の基準となります。
• ワークスペースのリージョン：リージョンごとに単価が異なります。
• Transform customの適用回数：カスタム変換をどれだけのリポジトリに適用するかが追加コストに影響します。

TCO試算の考え方

モダナイゼーションのTCO（総保有コスト）試算では、以下の要素を比較します。

• 現状維持コスト：メインフレーム運用費・COBOLエンジニア採用・維持コスト・VMwareライセンス費の継続コスト。
• モダナイゼーション実行コスト：AWS Transformの利用料金・手動レビュー工数・テスト実行インフラコスト・プロジェクト管理工数。
• モダナイゼーション後の削減効果：クラウドへ移行後の運用コスト削減・ライセンス費削減・新機能追加速度の向上による事業価値。

一般的に、大規模レガシー環境でのモダナイゼーションは、従来の手作業アプローチと比較してAWS Transformを活用することで工数削減・期間短縮による間接コスト削減が期待できます。ただし具体的なROIは組織の状況により大きく異なるため、AWSの担当者や技術パートナーとの試算を推奨します。

CloudWatch統合による変換進捗トラッキング

AWS TransformはAmazon CloudWatchとネイティブに統合されており、変換ジョブの進捗と結果をモニタリングできます。

利用可能な主なメトリクス・ログは以下の通りです。

• 変換ジョブのステータス：ジョブの開始・完了・エラーイベントがCloudWatch Logsに記録されます。ジョブ完了時の通知にはAmazon EventBridgeとSNSを組み合わせることで、Slack等への通知自動化が可能です。
• 変換率メトリクス：変換対象コードのうち自動変換に成功した割合がメトリクスとして取得できます。時系列で追跡することで、ルール改善の効果を可視化できます。
• エラーログ：変換に失敗したファイルやビルドエラーの詳細がログに記録されます。失敗の原因分析に活用します。

運用ダッシュボードの設計

複数のリポジトリや長期にわたるモダナイゼーションプロジェクトでは、CloudWatch Dashboardを活用した進捗管理が有効です。推奨するダッシュボード構成要素を以下に示します。

このダッシュボードをプロジェクトの週次レビューに活用することで、モダナイゼーションの遅延や品質低下を早期に検知できます。管理者・ステークホルダーへの進捗報告にも活用できます。

CloudWatch Alarmによる異常検知

変換ジョブが連続して失敗する場合や、変換率が目標値を大きく下回る場合は、CloudWatch Alarmを設定してSNS経由でSlack・PagerDutyなどへ通知することを推奨します。以下のアラーム設定例を参考にしてください。

• 変換ジョブ失敗率アラーム：同一リポジトリの変換ジョブが3回連続で失敗した場合に通知。ルール定義の見直しや手動介入のトリガーとして活用します。
• 変換完了タイムアウトアラーム：変換ジョブが予想時間を超過した場合に通知。大規模コードベースで変換がスタックしていないかを監視します。

6-4. セキュリティとアクセス制御

IAMロールによる権限設計

AWS TransformはAWSサービスであるため、IAMによる細粒度のアクセス制御が適用されます。ワークスペースの作成・管理・変換ジョブの実行にはそれぞれ異なる権限が必要です。最小権限の原則に従い、以下の役割別にIAMポリシーを分けることを推奨します。

• ワークスペース管理者：ワークスペースの作成・削除・設定変更を行う担当者向けの権限。
• 変換実行者：変換ジョブの開始・監視・レポートを閲覧する担当者向けの権限。
• レポート閲覧者：変換結果のレポートと進捗ダッシュボードのみ閲覧できる管理職・監査担当者向けの権限。

ソースコードの取り扱いとデータ保護

AWS Transformは変換処理のためにソースコードをAWSのインフラへアップロードします。コードが機密情報を含む場合は、以下の点を確認してください。

• 変換時のデータ転送はTLSで暗号化されます。
• ワークスペースのデータはAWS KMSによって暗号化できます。カスタムKMSキーの使用も可能です。
• ソースコードのリポジトリはAWSリージョン内に保持されます。クロスリージョンのデータ転送が懸念される場合はワークスペースリージョンの選定を慎重に行います。

コンプライアンス要件（例：金融系のFISC安全対策基準、医療系のHIPAAに相当する国内規制）がある場合は、AWSコンプライアンスプログラムの対応状況とAWS Transformのサービス仕様を事前に確認してから導入判断を行うことを推奨します。

継続的なモダナイゼーション文化の醸成

Transform customをはじめとするAWS Transformの機能は、単発のプロジェクトツールではなく、継続的なモダナイゼーション基盤として位置づけることが重要です。定期的なレポートレビュー・フィードバックの蓄積・ルール定義の更新というサイクルを組織の開発プロセスに組み込むことで、技術的負債の解消と新たな負債の発生抑制の両方を実現できます。モダナイゼーションを文化として定着させた組織では、エンジニアがコードの品質維持に主体的に関与し、変換品質の向上がチーム全体の関心事になります。料金の最新情報は公式料金ページで定期的に確認し、コスト最適化の観点からも継続的なモニタリングを推奨します。

なお、AWS Transformは継続的に機能が拡充されているサービスです。新しい対応言語やワークロードが随時追加されるため、AWS公式ブログやドキュメントの更新情報を定期的に確認することを推奨します。Transform customのルール精度向上や、新たな統合オプション（CI/CDパイプラインとの連携など）についても、公式情報を参照して最新の活用方法を把握してください。料金の詳細は変動する場合があるため、常に公式料金ページを参照した上で予算計画を立てることを強くお勧めします。AWS Transformを組織のモダナイゼーション戦略の柱として位置づけることで、技術的負債の解消・開発速度の向上・インフラコストの削減という三重の効果が期待できます。

Transform customの適切な運用は、短期的な変換プロジェクトの成功にとどまらず、長期的なコード品質の向上と組織のモダナイゼーション能力の蓄積につながります。組織固有の変換ルールをナレッジとして蓄積し続けることで、将来の新たなモダナイゼーション要件にも迅速に対応できる基盤が整います。次のセクション（§7）では、migrationツール群やAmazon Q Developerと組み合わせた実戦統合パターンを解説します。

7. 実戦統合パターン

7-1. アセスメント主導のモダナイゼーション戦略

モダナイゼーションを成功させるには、個別アプリケーションの変換を個別に判断するのではなく、ポートフォリオ全体を俯瞰したアセスメント主導の戦略が重要です。AWS Transformはこのポートフォリオアセスメントを支援する包括的な機能を提供しています。

ポートフォリオアセスメントのアプローチ

大規模なモダナイゼーションプロジェクトでは、まず全アプリケーションポートフォリオをスキャンし、移行優先度・難易度・コスト削減ポテンシャルを数値化します。AWS Transformのcomprehensive codebase analysis（2026年3月 GA）は、このポートフォリオ全体のアーキテクチャ可視化と技術的負債スコアリングを一括して実施できます。

技術的負債スコアリングでは、コードの複雑度・依存関係の密度・テストカバレッジ・廃止APIへの依存度を分析し、各アプリケーションの移行優先度マトリクスを生成します。優先度が高く、難易度の低いアプリケーションから着手することで、初期の成功事例（クイックウィン）を積み重ねながら組織の移行ケイパビリティを高めていくアプローチが有効です。

優先度マトリクスの活用例

7-2. 複数ワークロード統合パターン

エンタープライズの現場では、.NETアプリケーション・COBOLメインフレーム・VMwareワークロードが同一の業務プロセスに関与していることが珍しくありません。AWS Transformはこれら3種のワークロードを統合的に扱い、段階的な移行を支援します。

フェーズ1: アセスメントの統合

まず、.NET・メインフレーム・VMwareのすべてのワークロードを一括アセスメントし、依存関係マップを作成します。ワークロード間のデータ連携・API呼び出し・共有ストレージを特定することで、どのアプリケーションをどの順序で移行するかの移行シーケンス設計が可能になります。

フェーズ2: 段階的変換の実施

依存関係の末端にあるサービス（他のシステムから呼び出されていないもの）から順に変換を進めます。例えば、.NETバックエンドAPIに依存するフロントエンドより先に、APIサービス自体の変換を完了させるアプローチをとります。

VMwareワークロードについては、まずリフト＆シフト（VMware Cloud on AWSなどを活用）でAWS環境に移行し、稼働確認後にコンテナ化・マイクロサービス化の段階を踏むことで、ビジネス継続性を担保しながらモダナイゼーションを進めます。

メインフレームについては、COBOLをRefactor（Javaへの変換）またはReimagine（ビジネスルールを抽出してクラウドネイティブに再実装）の2つのアプローチのうち、業務への影響を最小化する方を選択します。

フェーズ3: 統合検証

各ワークロードの変換が完了した後、統合テストを実施します。変換前後でのAPIレスポンス一致・データ整合性・パフォーマンス基準を検証し、すべてクリアしたことを確認してから本番切り替えを行います。

ワークロード別変換ロードマップ例

7-3. migration・Q Developerとの使い分けE2E

AWS Transformの最大の差別化ポイントは、既存のAWS移行ツール群・Amazon Q Developerとの役割分担の明確化にあります。

移行前: AWS Transform（大規模コード変換・リアーキテクト）

AWS Transformが担うのは、組織規模での大規模なコード変換とリアーキテクトです。数十〜数千のリポジトリを横断した一括変換・フレームワーク移行・言語変換・データベース移行のような、個別の開発者が手作業で対応するには工数がかかりすぎる変換を自動化します。

移行後: migrationツール群（インフラリフト・データ転送）

コードの変換が完了した後、実際のインフラ移行・データ転送フェーズはmigrationツール群が担います。

• AWS MGN（Application Migration Service）: サーバーのリホスト（リフト＆シフト）
• AWS DMS（Database Migration Service）: データベースの実データ移行
• AWS DataSync: ファイルストレージの同期・転送
• AWS Snow Family: 大規模データのオフライン転送
• AWS SCT（Schema Conversion Tool）: データベーススキーマとSQL変換

これらのツールはコード変換とは独立して動作するため、AWS Transformによる変換完了後に順次適用します。両者を並行して進める場合は、コード変換と実データ移行の依存関係を明確にしたうえで実行計画を立てることが重要です。

継続開発: Q Developer（日常的なコーディング支援・小規模変換）

本番移行が完了した後の継続的な開発フェーズでは、Amazon Q Developerが開発者の日常的なコーディング支援を担います。

• IDE（Visual Studio Code・JetBrains・Visual Studio）上のインラインコード補完
• 個別ファイル・関数レベルの小規模なコード変換・リファクタリング
• コードレビュー・セキュリティスキャン・テスト生成
• Amazon Q Developer Agentによる機能実装タスクの自動化

AWS Transformが「移行前の大規模一括変換」を担うのに対し、Q Developerは「移行後の継続的な開発生産性向上」を担います。この役割分担を明確にすることで、両ツールの投資対効果を最大化できます。

E2Eタイムラインのイメージ

[フェーズ1: アセスメント]
├── AWS Transform: ポートフォリオ全体スキャン・優先度付け
└── DMS/SCT: DBスキーマ調査

[フェーズ2: コード変換]
├── AWS Transform: .NET/COBOL/VMware変換ジョブ実行
└── Transform custom: 組織ルール適用

[フェーズ3: インフラ移行]
├── AWS MGN: サーバーリホスト
├── AWS DMS: 実データ移行
└── DataSync: ファイル転送

[フェーズ4: 継続運用]
└── Q Developer: 日常開発支援・小規模変換

7-4. エンタープライズ統合設計

大規模なモダナイゼーションプロジェクトでは、技術的な変換だけでなく、ガバナンスと承認フロー・変換品質管理の仕組みが不可欠です。

ガバナンスと承認フローの設計

変換ジョブの実行・変換差分のレビュー・本番適用の承認を分離した三権分立型の承認フローを設計します。AWS IAMのロールベースアクセス制御を活用し、変換実行権限・レビュー権限・承認権限をそれぞれ独立したロールに割り当てます。

変換差分はGitブランチとして管理し、GitOpsワークフロー上でプルリクエストレビューとCIテストをパスした変換のみを本番マージするフローを標準化します。

変換品質管理の仕組み

変換品質を担保するために、以下の品質ゲートを導入します。

1. 静的解析: 変換後コードのLintチェック・コンパイルエラーゼロを自動検証
2. ユニットテスト: 変換前のテストスイートをそのまま変換後コードに適用し、テストパス率を計測
3. 統合テスト: 変換前後のAPIレスポンス・データ整合性を自動比較
4. パフォーマンステスト: レイテンシ・スループット・リソース使用量の変換前後比較

これらのゲートをCI/CDパイプラインに組み込むことで、変換の品質を定量的に管理できます。

7-5. Well-Architectedフレームワーク適用

AWS Transformによるモダナイゼーション完了後のアーキテクチャを、AWS Well-Architectedフレームワークの柱で評価します。

オペレーショナルエクセレンス

モダナイゼーション後のアプリケーションは、Infrastructure as Code（CloudFormation・CDK）でのデプロイ自動化・CloudWatch Logsを使った一元的なログ管理・X-Rayによる分散トレーシングを標準装備します。変換完了時をコードの近代化だけでなく、可観測性の整備タイミングとして活用することを推奨します。

セキュリティ

.NET Frameworkから.NETへの移行を機に、認証基盤をCognito・IAM Roles Anywhereに統一し、シークレット管理をSecrets Managerに集約します。SQL Server→Aurora移行時に、データ暗号化（KMS）の標準化も合わせて実施することで、セキュリティの一貫性が向上します。

信頼性

モダナイゼーション後のアーキテクチャでは、マルチAZ配置・Auto Scaling・Circuit Breakerパターンを適用し、単一障害点を排除します。Windows Server固有の制約が解消されることで、これらの信頼性パターンを素直に適用できるようになります。

パフォーマンス効率

LinuxベースのコンテナへのデプロイとGravitonインスタンスの活用により、同等ワークロードに対するコンピューティングコストをさらに削減できます。Linux上での.NETランタイムは、Windows Server環境と比較してスループット向上が見込まれます。

コスト最適化

変換後はWindowsライセンスコストがゼロになるため、EC2のリザーブドインスタンスやSavings PlansをLinuxベースで最適化します。Aurora PostgreSQLへの移行によるSQL Serverライセンス削減と合わせると、データ層・コンピューティング層の両方でコスト効率が向上します。

7-6. ROIと成果測定

モダナイゼーションの効果を定量化するために、以下の指標を移行前後で計測します。

代表的な成果指標

AWS Transformを活用した組織では、手作業1,690,000時間相当の変換作業の自動化実績が報告されています。これは、数十名のエンジニアが数年にわたり取り組んでいた変換プロジェクトに相当するスケールです。

コスト削減の定量化

これらの数値は参考値であり、実際の削減効果はアプリケーションの特性・インフラ構成・既存のライセンス契約内容によって異なります。詳細な見積もりはAWS公式料金ページおよびAWSのモダナイゼーション評価サービスを参照してください。

ROI測定のフレームワーク

移行コスト（変換工数・テスト工数・移行期間中の並行稼働コスト）と移行効果（ライセンス削減・インフラコスト削減・開発生産性向上・障害対応工数削減）を比較したTCO（総所有コスト）分析を移行前に実施します。この分析結果をビジネスケースとして経営層に提示することが、大規模モダナイゼーションプロジェクトの承認を得るうえで重要なステップとなります。

移行後の継続的な効果測定

モダナイゼーション完了後も、以下のKPIを定期的に計測して効果を可視化することを推奨します。

• デプロイ頻度（変換前後での比較）
• リードタイム（コード変更から本番デプロイまでの時間）
• 障害復旧時間（MTTR）の変化
• インフラコスト（月次・四半期での実績確認）
• 開発者体験スコア（チームサーベイ）

これらの指標を継続的に追跡することで、モダナイゼーション投資のビジネス価値を定量的に示し続けることができます。技術的なKPIだけでなく、開発チームの生産性向上や障害対応工数の削減といった人的側面の改善効果も合わせて記録しておくことで、組織全体でのモダナイゼーション文化の醸成につながります。

8. 詰まりポイント・アンチパターン・まとめ

8-1. 詰まりポイント

AWS Transformの実運用で多くのチームが直面する詰まりポイントを7個取り上げます。

詰まりポイント1：Comprehensive Codebase Analysisの実行タイムアウト

数百万行規模のコードベースをスキャンするとき、解析処理がタイムアウトして途中で止まることがあります。原因として多いのは、シンボリックリンクや循環参照を多数含むディレクトリ構成、不要なビルドアーティファクト（binフォルダ・Debugフォルダ等）をスキャン対象に含めてしまっていることです。対策として、スキャン対象からビルド成果物・サードパーティライブラリのソースをあらかじめ除外するファイルリストを作成し、段階的にスキャン範囲を絞ることが有効です。まず小規模なパイロットモジュールでアセスメントを完了させてから、全体に展開する進め方を推奨します。

詰まりポイント2：Windows固有APIへの依存が自動変換できない

Microsoft.Win32.Registry・System.Runtime.InteropServices・COMオートメーション等のWindows固有APIを使用しているコードは、.NET（クロスプラットフォーム版）への自動変換に対応しておらず、手動対応が必要なリストとして出力されます。このリストが大量になると、優先順位を付けられずプロジェクトの停滞を招くことがあります。解決策として、Windows固有APIを使用している箇所を「Windowsでしか動かさない」「将来削除予定」「代替API実装が必要」の3カテゴリに分類し、それぞれの対応戦略を明確にしてからプロジェクト計画に織り込みます。

詰まりポイント3：COBOLのCOMPUTATIONAL型データの変換精度問題

メインフレームCOBOLのCOMPUTATIONAL・PACKED-DECIMAL等の独自データ型は、Javaへの変換時に数値精度の差異を引き起こすことがあります。特に金融・保険系の業務システムでは、小数点以下の桁丸め処理の差異が致命的なバグにつながります。変換後に必ず数値計算処理を中心とした回帰テストを実施し、変換前後の計算結果を突き合わせる検証ステップを計画に組み込んでください。自動ユニットテストだけでは不足する場合、本番データのサンプルを使ったシャドウランを行うことを推奨します。

詰まりポイント4：依存関係グラフが循環参照で正しく解析されない

長期間メンテナンスされてきたコードベースでは、モジュール間の循環参照が蓄積していることがあります。このような構造があると依存関係グラフの構築が不完全になり、変換順序の決定に問題が発生します。まずリファクタリングで循環参照を解消してからAWS Transformを適用することを推奨しますが、短期間で解消できない場合は循環する部分をひとまとまりの変換単位として扱い、まとめて変換する戦略を取ることも有効です。

詰まりポイント5：自動生成ユニットテストのカバレッジが期待より低い

AWS Transformが自動生成するユニットテストは、主要なパス（ハッピーパス）を中心にカバレッジを確保しますが、業務固有のコーナーケース・例外処理・特殊な入力値に対するテストは不足することがあります。自動生成されたテストをベースラインとして活用しながら、業務を熟知したエンジニアが追加テストを補完する体制を組むことが重要です。自動生成テストを「完全なテストスイート」として扱う誤解が品質問題につながるため、テスト計画の段階から明示的に補完作業を織り込んでください。

詰まりポイント6：VMwareワークロードのストレージ依存が移行を複雑化する

VMwareのディスクイメージ（VMDKフォーマット）に直接依存した設定や、VMware固有の共有ストレージ（vSAN・NFS共有）を使っているワークロードは、そのままAWSに移行できません。これらの依存関係を事前に洗い出し、Storage Gatewayへの移行やEBS/EFSへの切り替え計画を立てる必要があります。アセスメントでストレージ依存を明示的にスコープに入れ、計画段階で解決策を設計することが重要です。

詰まりポイント7：HITL承認フローのチームへの展開に時間がかかる

HITL（Human-in-the-Loop）の承認ステップは、コードを読んで判断できる開発者がレビューを担当する必要があります。レビュー担当者が変換対象のコードベースを熟知していない場合、何が変わったのかを理解するまでに時間がかかり、承認フローが停滞します。対策として、変換前後のコード差分を担当者と事前に共有し、キャッチアップ時間を確保すること、レビューのチェックポイントをドキュメント化して属人化を防ぐことが有効です。大規模変換では変換バッチを小さく区切り、一度のレビュー量を管理可能なサイズに抑えることを推奨します。

詰まりポイント8：変換後コードのログ・監視が変換前と互換性がない

レガシーシステムでは、独自のログライブラリや固有のログ形式を使っているケースがあります。.NETやJavaへの変換後、ログの形式・出力先・ログレベル定義が変わります。これにより、既存の監視ツールやアラートルールが使えなくなります。変換前に既存の監視ダッシュボード・アラート設定を文書化し、変換後のコードに合わせてCloudWatch Logs/X-Rayの設定を再設計する計画を立ててください。監視の断絶は本番切り替え後に障害を見逃すリスクに直結します。

詰まりポイント9：マルチリージョン・マルチAZ対応が変換後に未考慮となる

レガシーシステムは単一サーバーや単一データセンターでの動作を前提に設計されており、変換後のコードもその前提を引き継ぐことがあります。AWSへの移行後にマルチAZ・マルチリージョン構成を採用しようとしたとき、変換後コードのステートフルな設計（ローカルファイルへの書き込み・インメモリセッション等）が障害となり、水平スケールや冗長構成を正しく機能させられません。変換計画にはコードのステートレス化（セッション管理のElastiCache化・一時ファイルのS3保存等）を明示的に含めてください。

8-2. アンチパターンと正解

AWS Transformを導入したプロジェクトで繰り返し観察されたアンチパターンと、その正解を5件まとめます。

アンチパターン1：アセスメント省略で全量変換に突入する

「変換ツールがあるなら、とにかく変換してみれば問題が分かる」という考えで、アセスメントをスキップして全コードベースを変換対象に設定してしまうケースがあります。この進め方では、変換不可能な依存関係の問題が変換フェーズ途中で発覚し、手戻りが発生してプロジェクトが停滞します。

正解：必ずアセスメントフェーズを実施し、変換難易度（Low/Medium/High）の分布を把握してから変換スコープを決定します。難易度Highのコンポーネントは個別の対応計画を立ててから変換対象に含めます。最初に難易度Lowのモジュールでパイロット変換を完了させ、プロセスに慣れてから全量展開する段階的なアプローチを取ってください。

アンチパターン2：自動変換後のテストを省略する

「AIが変換したのだから動作は保証されている」と考えて、変換後のテスト実施を省略またはごく簡単な確認だけで済ませるケースがあります。自動変換でも数値精度の差異や、プラットフォーム依存の挙動の違いは発生します。本番デプロイ後に問題が発覚した場合の影響は甚大です。

正解：自動変換後には必ず段階的なテストを実施します。ユニットテスト（自動生成 + 補完）→インテグレーションテスト→本番同等データを使ったシャドウランの順番でテストレベルを上げていき、各レベルで問題がないことを確認してから本番移行します。テスト計画はプロジェクト開始時点で策定してください。

アンチパターン3：Windows固有依存を「後で対応」として先送りする

アセスメントでWindows固有APIへの依存が多数検出されたとき、「変換優先、手動対応は後でまとめてやる」として先送りするパターンがあります。変換完了後に大量の手動対応タスクが残ると、それだけでプロジェクト期間が2倍以上になることがあります。

正解：アセスメント結果で検出された手動対応箇所を、変換フェーズの開始前に優先度・対応方針・工数を全件見積もります。工数見積もりができないものは専門家に評価を依頼し、変換フェーズと並行して手動対応タスクを進める計画を立ててください。先送りすると必ずクリティカルパスになります。

アンチパターン4：全エンジニアを変換プロセスのレビューから外す

「AIが自動で全部やってくれるから、エンジニアはほかの開発に集中させよう」として、HITL承認フローから既存エンジニアを外すことがあります。このアプローチでは変換後コードへの組織的な理解が失われ、変換完了後のメンテナンス体制が壊れます。

正解：HITL承認フローには必ず変換対象コードを熟知したエンジニアを参加させます。レビューには時間がかかりますが、この過程で変換後コードへの理解と所有意識がチームに形成されます。モダナイゼーションの目的は「コードを変換すること」ではなく「チームが運用できるシステムに変えること」であることを忘れないでください。

アンチパターン5：変換後の組織・プロセス改革を後回しにする

技術的な変換は完了したにもかかわらず、デプロイプロセス・テスト体制・オンコール運用などが変換前のまま据え置かれることがあります。コンテナ化されたアプリケーションをEC2と同じようにデプロイしていては、モダナイゼーションの恩恵を享受できません。

正解：AWS Transformによるコード変換と並行して、CI/CDパイプラインの構築・コンテナオーケストレーションの習得・観測可能性（CloudWatch/X-Ray）の導入を計画します。技術変換が完了するタイミングに合わせて、運用プロセスも切り替えられるよう準備を同時進行させることが、真のモダナイゼーション実現の鍵です。

8-3. まとめ

本記事では、AWS Transformのエージェンティックアプローチによるモダナイゼーションを詳しく解説しました。

AWS Transformが実現するものは、単なるコード変換ツールの提供ではありません。大規模言語モデル・グラフニューラルネットワーク・自動推論・Comprehensive Codebase Analysisといった先進技術を組み合わせたエージェンティックAIワークフローによって、専門家チームでなければ数年かかっていたモダナイゼーション作業を大幅に加速・自動化します。

実際の活用においては、アセスメント→変換→検証の3段階を丁寧に踏むことが重要です。アセスメントをスキップして変換に突入すると手戻りが発生し、せっかくのAI活用の恩恵が薄れます。Comprehensive Codebase Analysisを活用して変換前に徹底的にリスクを可視化し、パイロット変換で学習を積んでから全量展開する段階的アプローチが成功の鍵です。

また、エージェンティックAIの自律性を最大限に活かすためには、HITL承認フローを適切に運用してAIの判断を人間がチェックする体制を維持することが不可欠です。AIへの過信は変換後の品質問題につながります。変換後のテスト・レビューに既存エンジニアを積極的に巻き込み、組織としての変換後コードへの理解と所有意識を形成してください。

.NETモダナイゼーション・メインフレーム近代化・VMware移行の3つのワークロードに対してAWS Transformを活用することで、Windowsライセンスコスト削減・COBOLレガシーからの脱却・VMwareコスト問題の解消という、エンタープライズが長年頭を抱えてきた課題を体系的に解決する道が開けています。

モダナイゼーションは一度完了すれば終わりではなく、その後の継続的な運用改善・CI/CD整備・観測可能性の向上につながる出発点です。AWS Transformによる変換完了を機に、DevOpsプラクティスの導入や開発生産性の向上も合わせて推進することで、クラウドネイティブな組織への転換を加速させてください。

本記事で学んだこと・次のアクション

本記事の内容を実践に移すための次のアクションを整理します。

• 今すぐできること：AWSマネジメントコンソールからAWS Transformにアクセスし、小規模なモジュール（数千行規模）でComprehensive Codebase Analysisを試してみてください。アセスメント結果から変換難易度の感触を掴むことが最初の一歩です。
• プロジェクト計画段階でやること：本記事のチェックリスト（8-4節）を使ってプロジェクト開始前の準備状況を確認し、不足しているものを洗い出してください。チーム体制・ガバナンス・技術的前提条件の3つをそろえてから変換フェーズに進むことが成功の条件です。
• 変換後のステップ：変換が完了したら、Amazon Q DeveloperによるIDEサポートを活用して変換後コードの品質をさらに高め、AWS DevOps CI/CDパイプラインと組み合わせた継続的デリバリー体制を整備してください。

AWS Transformの詳細なドキュメント・料金・サポートオプションについては、AWS公式サイトをご参照ください。また、移行計画の立案段階から専門的な支援が必要な場合は、AWSのプロフェッショナルサービスやAWSパートナーへの相談も選択肢の一つです。

本シリーズの次回以降では、AWS Transformによる変換後のコンテナ基盤（ECS/EKS）上での実運用・CI/CDパイプライン整備・運用観測可能性の確立について詳しく取り上げます。モダナイゼーション後の継続的な改善サイクルを回すための具体的な手法については、関連記事（DevOps CI/CD Vol3・コンテナ本番運用 Vol1）も合わせてご覧ください。

大規模レガシーシステムのモダナイゼーションは、技術的な変換だけでなく、組織・プロセス・文化の変革を伴う複合的なプロジェクトです。AWS Transformはその複雑さを大幅に軽減するツールとして機能しますが、プロジェクトの成否は最終的に「人・チーム・計画」の質によって決まります。本記事がその計画立案の参考になれば幸いです。

AWS Transformに関する最新のアップデートや新機能については、AWSのWhat’s Newページおよび公式ブログで定期的に情報が発信されています。エージェンティックAIのモダナイゼーション領域は急速に進化しており、本記事公開後にも新機能の追加があります。実際の利用前に最新のサービス仕様を必ずご確認ください。

8-4. モダナイゼーション開始前チェックリスト

AWS Transformを使ったモダナイゼーションを開始する前に、以下のチェックリストを確認してください。プロジェクトの失敗原因の多くはこれらの準備不足に起因します。

アセスメント準備チェック

• [ ] 変換対象コードベースの全量をバージョン管理（Gitまたは同等）に入れてあるか
• [ ] ビルドアーティファクト・サードパーティライブラリのソースをスキャン対象から除外できるか
• [ ] モダナイゼーションの目標（コンテナ化・OSS化・プラットフォーム移行など）を経営層と合意できているか
• [ ] 変換後のターゲットプラットフォーム（ECS/EKS/Lambda等）を決定してあるか
• [ ] タイムラインと予算の上限をプロジェクトスポンサーと合意してあるか

技術的前提条件チェック

• [ ] 変換対象コードがコンパイル・ビルドできる状態にあるか（壊れたビルドは変換品質を低下させる）
• [ ] 既存のユニットテスト・インテグレーションテストが存在するか（自動変換後のベースラインとして使用）
• [ ] Windows固有API・プラットフォーム固有依存のリストを事前に作成してあるか
• [ ] 変換対象に含まれる外部サービス・APIの仕様ドキュメントが入手可能か
• [ ] データベーススキーマと移行計画が定義されているか（コードだけでなくDBも考慮）

チーム体制チェック

• [ ] HITL承認フローを担当できる、対象コードを熟知したエンジニアが確保できているか
• [ ] 変換後コードのレビュー・補完テスト作成を担当するエンジニアのアサインが完了しているか
• [ ] モダナイゼーション完了後の運用を担当するチームが決定しているか
• [ ] AWS Transformの使い方について担当チームへのトレーニング計画があるか

ガバナンス・コンプライアンスチェック

• [ ] 変換対象コードのライセンス条件（商用・OSSの混在）を確認してあるか
• [ ] セキュリティ要件（変換後コードのセキュリティレビュー・脆弱性スキャン）を定義してあるか
• [ ] 規制要件がある業種（金融・医療等）の場合、変換後コードの規制適合検証計画を立ててあるか
• [ ] 本番移行判断の承認フロー（誰が最終GOを出すか）を定義してあるか

本番移行直前チェック

• [ ] ステージング環境でのユニットテスト・インテグレーションテストがすべて通過しているか
• [ ] パフォーマンスベンチマーク（変換前後の比較）を実施して許容範囲内か確認したか
• [ ] セキュリティスキャン（SAST/DAST/依存ライブラリ脆弱性）を実施して問題が解消されているか
• [ ] ロールバック手順を文書化してあり、担当チームが実施できるか確認したか
• [ ] 本番切り替え後のモニタリング体制（アラート・オンコール担当）を整備したか
• [ ] ステークホルダーへの本番移行完了の通知・報告ルートを確認してあるか
• [ ] 変換完了後の廃止予定リソース（旧Windows Server等）のコスト停止計画を立ててあるか

8-5. よくある質問（FAQ）

AWS Transformの導入検討時によく寄せられる質問をQ&A形式でまとめます。

Q1：自動変換率（変換成功率）はどのくらいですか？

変換成功率はコードベースの特性に大きく依存します。Windows固有APIへの依存が少なく、標準的な.NETパターンで書かれたコードは高い自動変換率を示す傾向があります。一方、レガシーなCOMオブジェクト・カスタムWindowsサービス・プラットフォーム固有の最適化が多いコードは自動変換率が下がります。Comprehensive Codebase Analysisのアセスメント結果に変換難易度分布が示されるため、それをもとに全体の自動変換率を推定してください。

Q2：変換に失敗したコンポーネントはどうなりますか？

自動変換できなかった箇所は変換スキップとして記録され、手動対応が必要なリストとして出力されます。変換できなかった部分は元のコードのまま残り、開発者が手動で対応します。AWS Transformは「変換できなかった箇所を隠す」のではなく「明示的にリストアップする」設計になっており、この透明性によって手動対応のスコープを正確に把握できます。

Q3：変換中のシステムを本番運用し続けることはできますか？

変換プロジェクトは通常、本番システムを稼働させたまま並行して実施されます。変換したコードをステージング環境でテスト・検証し、段階的に本番切り替えを行うブルーグリーン方式やカナリアデプロイを活用することで、本番への影響を最小化しながら移行できます。AWS Transformの変換作業は既存の本番コードベースを直接変更するものではなく、変換後コードは別途管理されます。

Q4：メインフレームのCOBOLから変換したJavaコードのパフォーマンスはどうなりますか？

Refactor（機械翻訳的変換）で生成されたJavaコードは、COBOLの構造を忠実に反映するためJavaらしいコードとは言えないことがあります。パフォーマンスは変換対象の処理特性によります。バッチ処理系はCOBOL時代と同等以上の性能を出す傾向があります。オンライントランザクション系はAPIゲートウェイ経由となるためレイテンシが変化します。変換後のパフォーマンスベンチマークは本番移行前に必ず実施してください。

Q5：AWS Transformと Amazon Q Developer、AWS Migration Hubはどう使い分けますか？

• AWS Transform：大規模コードベースの自動変換・アセスメント・検証の一連のモダナイゼーションワークフロー。.NET/COBOL/VMwareワークロードが対象。
• Amazon Q Developer：個々の開発者がIDEやCLI上でコード補完・レビュー・テスト生成の支援を受けるためのAI開発支援ツール。AWS Transformが完了した後の継続開発を支援。
• AWS Migration Hub：移行プロジェクト全体の進捗管理・可視化ダッシュボード。AWS Transformの変換ステータスもMigration Hubで一元管理できる。

Q6：変換後コードのCIパイプラインはどのように組めばよいですか？

変換後コードはモダンな.NETやJavaとして扱えるため、標準的なCI/CDツール（AWS CodePipeline / CodeBuild / GitHub Actions等）をそのまま活用できます。AWS Transformが自動生成したユニットテストをCIパイプラインの最初の検証ステップとして組み込み、その後インテグレーションテスト・セキュリティスキャン（Amazon Inspector）・コンテナイメージビルドとECRへのプッシュという流れを構成するのが一般的なパターンです。

Q7：小規模なチーム（5人未満）でもAWS Transformを活用できますか？

小規模チームでもAWS Transformは活用できますが、成功のポイントはスコープを絞ることです。全コードベースを一度に変換しようとせず、価値が高く変換難易度の低いモジュールを最初に選定して変換することを推奨します。HITL承認フローの担当者が限られる場合は、変換バッチのサイズを小さく設定して一度のレビュー量を管理可能に保ちます。小規模チームの場合、AWSのプロフェッショナルサービスやパートナー企業の支援を組み合わせてプロジェクトを進めるケースも多くあります。

Q8：既存のモダナイゼーション作業がすでに一部進んでいる場合、途中からAWS Transformを導入できますか？

はい、可能です。AWS Transformは対象コードベースをスキャンして変換するため、すでに一部モダナイゼーションが完了しているコードはスコープから外し、残りの未変換部分に絞って適用できます。Comprehensive Codebase Analysisで現在の変換状況を可視化し、どこから始めるかを再設計した上で導入するアプローチが有効です。すでに.NET 6以降に移行済みのコンポーネントはそのまま活用し、.NET Framework 4.xが残っているコンポーネントをAWS Transformで変換するという組み合わせは典型的な活用パターンです。

Q9：変換後コードのセキュリティはどのように確保しますか？

AWS Transformによる変換後コードのセキュリティ確保には、複数の層のアプローチを組み合わせます。変換時には自動レビューでセキュリティ上の懸念パターンが検出されますが、これだけでは不十分です。変換後コードに対してAmazon Inspectorによる静的解析・SAST（Static Application Security Testing）ツールによるスキャン・実行時の動的解析（DAST）を組み合わせることで、網羅的なセキュリティ検証を実現します。また、変換前に脆弱性が含まれていたライブラリも変換後に引き継がれることがあるため、依存ライブラリの脆弱性スキャンも並行して実施してください。

8-6. 関連記事