こんにちは!SCSKの竹内です。
先日、幕張メッセで開催された「AWS Summit Japan 2026」で、「AIでVMware移行を加速:AWS Transform for VMware(MAM301)」というセッションを聴講しました。
本記事では、セッション内容と自分のこれまでの移行経験を重ねながら、クラウドリフトの進め方をどう考えるかについて整理します。
AWS Transform for VMwareとは
現在、VMwareを取り巻く環境は大きく変化しています。Broadcomによる買収後、VMwareライセンスが3〜10倍に上昇したという報告もあり、VMwareユーザーの74%が代替手段を検討しているとのことです。こうした状況を受けてAWSがリリースしたのが、VMwareからの移行に特化したサービス AWS Transform for VMware です。(以下、AWS Transformと記載します)
AWS Transformは、VMwareワークロードを大規模にモダナイズするための初のエージェンティックAIサービスです。複数のAIエージェントが連携して移行プロセス全体を自律的に推進しつつ、重要な判断ポイントでは人が確認・承認する Human-in-the-Loop の仕組みを取り入れています。
AWSへの移行パスとしては、リロケート・リホスト・コンテナ化・マネージドサービス移行・リファクターといった選択肢がありますが、AWS Transformはそのうちリホスト(EC2へのOS移行)とコンテナへのリプラットフォームに対応しています。
AWS Transformの移行プロセス
AWS Transformが提供する移行プロセスは、以下のステップで構成されています。各ステップでAIエージェントが自律的に動作し、これまで人手と時間がかかっていた作業を大幅に効率化します。
① ディスカバリーとアセスメント
RVToolsなどのインベントリデータをアップロードするだけで、VMwareのサーバー・DB・ネットワーク・依存関係情報を自動取得します。
AIによる効率化ポイント:手動では数週間〜数ヶ月かかるインベントリ収集・依存関係の把握を自動化し、約10分でアセスメントレポートを作成できます。適切なサイジングとAWSインフラコストも自動算出され、PowerPoint・Excel・PDFでダウンロード可能。経営層への報告資料としてもそのまま活用できます。
② 移行計画
ビジネス要件と技術的要件に基づき、依存関係を分析して移行計画を自動作成します。移行ウェーブ(依存関係のあるアプリをグループ化して順次移行するアプローチ)単位で計画が整理されます。
AIによる効率化ポイント:「Wave 1はWordPress、Wave 2はSAP」のようにチャットで指示するだけで、AIエージェントが移行計画を自動作成・修正してくれます。数十〜数百台規模でも膨大な時間をかけずに計画を立てられる点が大きな違いです。
③ ランディングゾーン構築
AWSのベストプラクティスに準拠したマルチアカウント環境を自動構築します。IaC(CloudFormation・AWS CDK・Terraform等)として作成されるため、カスタマイズや手動デプロイも可能です。
AIによる効率化ポイント:AWSのベストプラクティスに沿った環境基盤をAIが自動設計・IaC生成します。承認者の確認・承認後にデプロイ実行されるため、ガバナンスを保ちながら速度も出せます。
④ ネットワーク変換と移行
VMware vSphere NSX、Palo Alto、FortiGateなどのネットワーク構成をAWSネイティブのリソース(VPC・サブネット・セキュリティグループ等)へ変換します。自動デプロイと手動デプロイを選択でき、承認者の承認後にデプロイが実行されます。
AIによる効率化ポイント:VMwareとAWS両方のネットワーク知識を持つ人材確保が難しい中、AIがネットワーク構成の読み取り・変換・IaC生成を自動化します。ファイアウォールルールをセキュリティグループに変換するといった複雑なマッピングも自動で行われます。
⑤ サーバー移行(リホスト)
AWS MGN(Application Migration Service)と連携してサーバー移行を自動化します。ウェーブごとにテスト移行 → 検証 → カットオーバーの反復的移行を実施し、マルチアカウント・マルチリージョン対応、複数ウェーブの並列実行も可能です。
AIによる効率化ポイント:サーバーのCPU・メモリ情報から最適なEC2インスタンスタイプを自動推奨します。また、移行状況をリアルタイムにレポート・可視化することで、ステークホルダーへの承認・報告もスムーズになります。
クラウドリフトでよく遭遇する問題
AWS Transformは非常に強力なツールですが、実際のクラウドリフトではAWS Transformでは対応しきれない個別の問題に遭遇することがあります。AWS Transformはあくまで「オンプレミスのOSをEC2にコピーする」技術であるため、移行前後に別途対応が必要になるケースが出てきます。
私がよく遭遇する問題は、以下のようなものです。
| 問題 | 内容 | AWS Transformでの対応 |
|---|---|---|
| ① ディスク縮小 | 「移行ついでに容量を縮小したい」はよくある要望。しかし移行後に縮小後容量のEBSを作成してアタッチ→データコピーという手順が必要になり、移行”だけ”では終わらない。 | 移行時のディスク容量変更は不可 |
| ② OSが古い | 移行時点で古いOSは、移行のタイミングで最新OSにバージョンアップしたいが、バージョンアップが必要な場合はOS新規構築+アプリ再導入が必要で、「リフト」ではなく「再構築」に近い作業になる。 | 移行時のOS変更・バージョンアップは不可 |
| ③ IP/MACアドレス制約 | ライセンスがMACアドレスに紐付くケースがあるが、オンプレミスのMACアドレスはそもそも移行できない。また、テストデプロイ時のMACアドレス・IPアドレスを本番でも使いたいといったケースがあるが、その場合は手動対応が必要。 | MACアドレス/IPアドレスの個別設定は不可 |
| ④ ホスト名の引き継ぎ | 引き継ぎ自体は可能でも、移行後にDNS変更などの手作業が必要。 | DNS設定は対象外 |
| ⑤ 並行稼働 | 本番環境と並行してテスト環境でテストをしてから、本番移行したいケースは多い。その場合、現行本番に影響を出さないためのNW隔離設計が必要となる。AD参加サーバの場合は、別OSと認識させるためのsysprepも必要。 | オンプレミス同様のNW設計のみ対応可 |
クラウドリフトは「個別移行・一括移行の組み合わせ」で考える
上記のような問題を踏まえると、クラウドリフトは「全台を画一的に同じ方式でやる」べきではなく、個別移行と一括移行を組み合わせて進めることが重要だということが見えてきます。
大量のサーバーを抱える移行プロジェクトでは、2つのアプローチを組み合わせることが現実的です。
- 個別移行:重要度が高く個別事情が多いサーバーに対して、1台1台計画を立てながら移行する
- 一括移行:要件が比較的シンプルなサーバーに対して、ツールを使って一括で効率よく移行する
全台を同じ粒度で丁寧にやると、品質は出せても規模が大きいほど期間・コストが膨らみます。一方で、全部を一括でやろうとすると、個別事情のあるサーバーで必ず詰まります。
言われてみれば当たり前なのですが、大量移行ではこの2つをうまく組み合わせることが必要だと、今回のセッションを通じて理解できました。
レベル分けの基準
では「個別移行」か「一括移行」かを、どう見分けるか。実務的に一番わかりやすい判断基準は、「並行稼働期間が必要かどうか」だと思っています。
- 並行稼働が必要なサーバー:本番と移行先を同時に動かしながらテストする期間が必要。ネットワーク隔離の設計が複雑になり、個別対応が必要になりやすい → 個別移行トラック
- 並行稼働が不要なサーバー:事前検証は特定の数台のみで実施し、残りの台数は一気に切り替える。ディスク縮小やOSの細かな調整は、移行してから対応するでもよい。こういったサーバーこそAWS Transformで一括移行して効率を稼ぐ対象 → 一括移行トラック
「並行稼働が不要=業務影響が小さい or 要件が固定しやすい」というロジックで、一括移行できるかどうかの一次判断ができます。もちろんOSバージョンやライセンス制約、依存関係の複雑さなど他の判断軸もありますが、まず「並行期間が必要か」を確認するだけで、かなりの仕分けが進みます。
おわりに
今回のAWS Summit Japan 2026では、会場全体を通じてAI関連のセッションが非常に多く、基調講演からスペシャルセッション、展示ブースに至るまで、260を超えるセッションの大半がAIエージェント関連という印象を受けました。
AWS Transformもそのひとつとして、「移行をAIで加速する」という方向性を体現したサービスです。効率化のためにAIを活用することは、今後ますます必須の流れになっていくと感じています。
ただ、業務にどのようにAIを活用するかは、様々なアイデアを持って試行錯誤していく必要があるとも思っています。AWS Transformひとつとっても、「全部これで解決」ではなく、ツールの得意領域を正しく理解して使うべき対象に使うことが大切です。移行プロジェクトに関わる立場として、今回得た「メリハリをつけて進める」という発想を、今後の実務に活かしていきたいと思います。
最後までお読みいただき、ありがとうございました。
