Microsoft Azureの「About Azure Migrate – Azure Migrate」を確認するうえで最初に押さえるべき結論は、Azure Migrateを単なるVM移行ツールとして扱わず、検出・評価・計画・移行実行をつなぐ移行ハブとして設計し直す必要があるという点です。2026年5月19日に更新された公式ページでは、Azure Migrateがサーバー、データベース、Webアプリ、仮想デスクトップ、大容量データ移行を支援するサービスとして整理され、Azure Copilot migration agentやアプリケーション単位の計画がより重要な文脈として示されています。(Microsoft Learn)
特に管理者や開発者は、既存環境の棚卸し、Azure readiness評価、コスト見積もり、RBAC、アプライアンスまたはCollectorの選定、アプリケーション単位での依存関係確認を見直すべきです。移行前の確認が甘いと、移行対象の抜け漏れ、過大なAzure VMサイズ、不要なOwner権限の付与、テスト移行不足による本番停止といった問題につながります。
Azure Migrateは何をするサービスか
Azure Migrateは、オンプレミス環境などからAzureへ移行する際に、移行すべきか判断する、移行計画を作る、実際に移行するという流れを支援するサービスです。公式ページでは、ワークロードの検出、Azureへの対応可否、Azure上でのホスティングコスト、最小限のダウンタイムとリスクでの移行を支援すると説明されています。(Microsoft Learn)
実務では、Azure Migrateを次の3段階で捉えると分かりやすくなります。
| フェーズ | 目的 | 管理者・開発者が確認すること |
|---|---|---|
| Decide | 移行対象を把握する | サーバー、DB、Webアプリ、依存関係、利用率、サポート期限を棚卸しする |
| Plan | Azure上の構成を決める | Azure VM、Azure SQL、App Service、AKS、Azure VMware Solutionなどの候補を比較する |
| Execute | 移行を実行する | レプリケーション、テスト移行、切り替え、移行後の監視を行う |
ここで重要なのは、Azure Migrateの評価結果を「そのまま本番設計」として使わないことです。評価結果は移行判断の材料であり、最終的な設計では業務重要度、停止許容時間、バックアップ方針、セキュリティ要件、運用体制を加味する必要があります。
2026年5月更新で押さえるべき実務上のポイント
2026年5月19日更新の公式ページでは、Azure Migrateの概要として、統合された移行プラットフォーム、Azure Copilot migration agent、Decide・Plan・Executeの流れ、統合ツールが整理されています。加えて、直近の「What’s new」では2026年5月の更新として、検出済みワークロードを論理的なアプリケーショングループとして扱う自動検出機能がPublic previewとして示されています。(Microsoft Learn)
実務で特に影響が大きいのは次の点です。
| 確認ポイント | 内容 | 実務への影響 |
|---|---|---|
| アプリケーション単位の移行計画 | サーバー単体ではなく、複数サーバーやDB、Webアプリをアプリケーションとして扱う | 業務システム単位で影響範囲を見積もりやすくなる |
| Azure Copilot migration agent | Azure Migrateのデータを使って移行計画を対話的に分析するPreview機能 | 計画支援には使えるが、移行実行はAzure Migrateポータル側で行う |
| Azure Migrate Classicの制約 | Classic experienceではアプリケーションビューやクロスワークロードビューをサポートしない | 既存プロジェクトでは新しいビューが使えるか確認が必要 |
| 組み込みRBACロール | Azure Migrate Owner、Decide and Plan Expert、Execute Expertで権限を分離できる | サブスクリプション全体にOwnerやContributorを広く付与する運用を避けやすい |
| ReportsやBusiness case | TCO、ROI、セキュリティ、移行波などをレポート化できる | 経営層や予算承認向けの説明資料を作りやすい |
Azure Copilot migration agentは、移行戦略、検出インベントリ、ビジネスケース、Azure readiness、ランディングゾーン構成の検討を支援します。ただし、公式情報では「移行計画と分析を支援するが、移行実行は行わない」と明記されています。実行前の判断材料として使い、実際のレプリケーションや移行はAzure Migrateポータルで管理するのが安全です。(Microsoft Learn)
対象者別の影響範囲
Azure Migrateの更新は、インフラ担当者だけでなく、アプリケーション開発者、DBA、セキュリティ担当、予算管理者にも影響します。移行は「サーバーをAzure VMへ移す作業」ではなく、アプリケーション、データ、ネットワーク、ID、コストをまとめて再設計する作業だからです。
| 対象者 | 確認すべきこと | 具体例 |
|---|---|---|
| Azure管理者 | RBAC、サブスクリプション、リソースグループ、リージョン | Azure Migrate用リソースグループを分け、最小権限で割り当てる |
| インフラ担当 | VMware、Hyper-V、物理サーバー、他クラウドVMの検出方式 | ApplianceかCollectorか、ネットワーク接続が可能かを判断する |
| 開発者 | Webアプリ、DB、ランタイム、依存関係 | App ServiceやAKSへ移せるか、接続文字列や外部API依存を確認する |
| DBA | SQL Server、PostgreSQL、MongoDBなどの評価 | Azure SQL、Azure VM上のSQL Server、Azure Database系サービスの候補を比較する |
| セキュリティ担当 | 権限、サポート切れOS、脆弱性、セキュリティレポート | 移行前にリスクの高いOSやソフトウェアを把握する |
| 経営・PMO | TCO、ROI、移行波、停止リスク | Business caseやReportsで段階移行の根拠を作る |
既存のAzure Migrateプロジェクトを利用している場合は、すぐに移行処理が止まるという話ではありません。ただし、アプリケーション単位の評価、タグ、Reports、Copilotのような新しい機能を使うなら、現在のプロジェクト、検出方式、権限、データ収集状況を確認してから適用するべきです。
アプリケーション単位の計画で注意すべきこと
2026年5月の更新で注目したいのは、アプリケーションの自動検出です。公式の「What’s new」では、Collector、Appliance、CSV importで検出されたワークロードを、サーバー命名規則、推定環境、サーバーロールなどからアプリケーションとしてグループ化すると説明されています。一方、詳細ページのCurrent limitationsでは、自動検出は現時点でCollectorベースのインベントリのみ対応とされており、Private endpoint connectivityで構成されたプロジェクトではCSV importによるアプリケーション定義が未サポートとされています。(Microsoft Learn)
このため、本番移行計画では次のように扱うのが安全です。
| 判断項目 | 推奨対応 |
|---|---|
| 自動検出されたアプリケーション | そのまま採用せず、業務担当者・開発者・運用担当でレビューする |
| 信頼度が低いグループ | 命名規則、通信依存、DB接続、Webアプリ構成を確認して手動修正する |
| 共有DBや共通基盤 | 1つのアプリだけに紐づけず、複数アプリからの依存を明示する |
| Private endpoint利用環境 | CSV importや自動検出の制限を事前に確認する |
| 削除対象のアプリケーション | AssessmentやMigration Waveに含まれていないか確認してから削除する |
特に失敗しやすいのは、サーバー名だけでアプリケーション境界を判断するケースです。例えば、app01、db01、batch01のような命名なら推測しやすい一方、歴史的に名前が変わっていないサーバーや、複数システムで共有されるDBは誤ってグループ化される可能性があります。自動検出は初期整理には便利ですが、最終的な移行単位は業務影響を理解している人が確認する必要があります。
RBACと権限は最初に設計する
Azure Migrateでは、移行フェーズに応じた組み込みロールが用意されています。公式情報では、Azure Migrate Owner、Azure Migrate Decide and Plan Expert、Azure Migrate Execute Expertの3つが説明されており、広いOwnerまたはContributor権限を安易に付与するより、最小権限の原則に沿った割り当てが推奨されています。(Microsoft Learn)
| ロール | 主な用途 | 向いている担当者 |
|---|---|---|
| Azure Migrate Owner | プロジェクト作成、検出、評価、移行実行、Azure Migrate関連ロール割り当て | 移行全体の管理者 |
| Azure Migrate Decide and Plan Expert | 検出、インベントリ管理、依存関係確認、ビジネスケース、評価レポート作成 | アセスメント担当、計画担当 |
| Azure Migrate Execute Expert | レプリケーション、テスト移行、移行実行、進捗監視 | 移行実行担当 |
注意点として、Azure MigrateアプライアンスやASRレプリケーションアプライアンスを登録するユーザーには、Microsoft Entra IDレベルで追加のApplication Developerロールが必要とされています。ロールを割り当てたのにアプライアンス登録で失敗する場合は、Azure RBACだけでなくEntra ID側の権限も確認してください。(Microsoft Learn)
また、サポートマトリックスでは、アプライアンス登録時にMicrosoft.OffAzure、Microsoft.Migrate、Microsoft.KeyVaultのリソースプロバイダー登録が行われること、登録にはサブスクリプションへのContributorまたはOwnerアクセスが必要と説明されています。組み込みロールだけで完結しない操作があるため、初期セットアップ時は権限要件をタスクごとに確認することが重要です。(Microsoft Learn)
ApplianceとCollectorは環境条件で選ぶ
Azure Migrateの検出では、Azure Migrate applianceとAzure Migrate Collectorの使い分けが重要です。Applianceは継続的な検出・評価やVMwareのエージェントレス移行などで使われ、CollectorはAzureへの直接接続が難しい環境でもローカルでスキャンしてインベントリをアップロードできる方式として説明されています。(Microsoft Learn)
| 選定基準 | Applianceが向くケース | Collectorが向くケース |
|---|---|---|
| Azure接続 | 継続的にAzureへ接続できる | 制限ネットワーク、承認に時間がかかる環境 |
| データ更新 | 継続的なメタデータ・性能収集をしたい | スナップショット的に棚卸ししたい |
| VMware移行 | エージェントレス移行まで見据える | まず現状把握やビジネスケース作成を急ぎたい |
| 運用負荷 | 常時稼働するアプライアンスを管理できる | 一時的な収集サーバーで済ませたい |
| 制限事項 | ネットワーク、ポート、認証情報の準備が必要 | 最新Collectorの利用、ZIPアップロード、対応範囲の確認が必要 |
Collectorを使う場合、Windows Server 2019、2022、2025のサーバー、IISロール、16GB RAM、8vCPU、約80GBのディスクなどの要件が示されています。また、VMware環境ではvCenterやESXiへのTCP 443、WindowsのWinRM、LinuxのSSH、SQLインスタンスへの接続など、収集対象に応じた通信要件があります。(Microsoft Learn)
移行前に確認すべき設定チェックリスト
Azure Migrateを導入する前に、次の項目を確認しておくと手戻りを減らせます。
| 確認項目 | 見るべきポイント | 失敗しやすい例 |
|---|---|---|
| サブスクリプションとリージョン | プロジェクトのgeography、メタデータ保存場所 | データ所在地要件を確認せずにプロジェクトを作る |
| RBAC | Azure Migrate用ロール、Entra ID権限 | 全員にContributorを付与してしまう |
| リソースプロバイダー | Microsoft.OffAzure、Microsoft.Migrate、Microsoft.KeyVault | 初期登録で権限不足になる |
| 検出方式 | Appliance、Collector、CSV import | ネットワーク制限のある環境でAppliance前提にして詰まる |
| 認証情報 | vCenter、Windows、Linux、SQL、DB権限 | ゲストOSやDBの資格情報が不足し、依存関係やDB検出が欠ける |
| タグ | 環境、部門、重要度、移行方針 | 評価スコープを絞れず、不要なサーバーまで見積もる |
| アプリケーション定義 | 自動検出、手動追加、CSV import | 共有DBやバッチサーバーを見落とす |
| Business case | 性能データ収集後に作成する | 検出直後に作成し、利用率に基づく見積もり精度が落ちる |
Azure MigrateのBusiness caseでは、オンプレミスとAzureのTCO、年次キャッシュフロー、Azure Hybrid Benefit、ESU、Microsoft Defender for CloudやAzure Monitorなどによる節約、サステナビリティの観点を含めた分析ができます。公式情報では、Business case作成前に少なくとも1日待ち、性能とリソース利用率データを収集することが推奨されています。(Microsoft Learn)
開発者が確認すべき移行・展開上の注意点
開発者がAzure Migrateを見るときは、「サーバーが移行できるか」だけでなく、「アプリケーションとしてAzure上で運用できるか」を確認する必要があります。
具体的には、次の観点を確認してください。
| 観点 | 確認内容 |
|---|---|
| ランタイム | .NET、Java、PHP、Tomcat、IISなどのバージョンとサポート状況 |
| 接続情報 | DB接続文字列、外部API、ファイル共有、認証基盤 |
| 状態管理 | セッション、ローカルディスク、キャッシュ、バッチ処理 |
| 移行先候補 | Azure VM、App Service、AKS、Azure SQL、Azure Database系サービス |
| 可用性 | 冗長化、バックアップ、監視、障害時の切り戻し |
| セキュリティ | シークレット管理、証明書、最小権限、脆弱性対応 |
Azure Migrateでは、アプリケーション評価やクロスワークロード評価を作成し、関連する複数ワークロードをまとめて評価できます。評価では、推奨される移行先、代替ターゲット、readiness、right-sizing、月次コストなどを確認できます。(Microsoft Learn)
この機能を活用すると、例えば「IIS上のWebアプリはApp Service候補、DBはAzure SQL候補、周辺バッチはAzure VM候補」といった分割判断がしやすくなります。反対に、すべてをAzure VMへリフト＆シフトすると、移行は速くても運用コストや将来のモダナイズ余地を見落とす可能性があります。
プレビュー機能は本番前に扱いを決める
Azure Migrateには、Public previewとして提供される機能が含まれます。Azure Copilot migration agent、Reports、アプリケーション自動検出、MongoDB assessmentsなど、移行計画を高度化する機能は便利ですが、本番プロジェクトで使う場合はPreviewであることを前提に、利用範囲を明確にしてください。(Microsoft Learn)
プレビュー機能を使うときの判断基準は次の通りです。
| 用途 | 使いやすい場面 | 慎重に扱う場面 |
|---|---|---|
| Copilot migration agent | 評価結果の要約、移行戦略の比較、経営層向け説明の下書き | 本番移行手順やリスク判断を自動回答だけで決める |
| Reports | TCO、ROI、セキュリティ、移行波の整理 | 数値を予算確定値として扱う |
| 自動アプリケーション検出 | 初期のグルーピング、棚卸しのたたき台 | 業務影響範囲をレビューせずに移行波へ入れる |
| MongoDB assessment | Azure DocumentDBなどの候補検討 | 互換性検証や性能検証を省略する |
移行計画で重要なのは、Azure Migrateの結果を「意思決定の材料」として使うことです。評価結果、Copilotの提案、Reportsの数値は、設計レビュー、PoC、テスト移行、運用設計と組み合わせて判断してください。
次に取るべき行動
Azure Migrateをこれから使う場合は、まず移行対象をサーバー単位ではなく、アプリケーション単位で整理してください。そのうえで、Azure Migrateプロジェクトを作成し、RBAC、geography、検出方式、認証情報、タグ設計を決めます。
既存プロジェクトがある場合は、次の順番で確認すると効率的です。
| 順番 | 実施内容 |
|---|---|
| 1 | Azure Migrateプロジェクトの権限を確認し、不要なOwnerやContributorを減らす |
| 2 | ApplianceまたはCollectorが最新で、必要な通信と認証情報が揃っているか確認する |
| 3 | 検出インベントリの欠損、失敗、未分類ワークロードを修正する |
| 4 | タグとアプリケーショングループを整備し、業務単位で評価できる状態にする |
| 5 | Business case、Assessment、Reportsを作成し、コストと移行候補を比較する |
| 6 | テスト移行で性能、接続、監視、バックアップ、切り戻しを確認する |
| 7 | 移行波を作り、重要度の低いワークロードから段階的に移行する |
Azure Migrateの2026年5月更新は、Azure移行を「個別サーバーの移設」から「アプリケーションとビジネス価値を軸にした移行計画」へ進めるための重要なサインです。まずはインベントリ、権限、検出方式、アプリケーション定義を見直し、評価結果をもとに小さな移行波から検証を始めてください。
コメント