Azure Arc-enabled VMware vSphereは、VMware vSphere環境をAzureポータルやAzure APIから管理できるようにするAzure Arcの機能です。重要なのは、VMware VMをAzureへ移行する機能ではなく、オンプレミスのvSphereやAzure VMware Solution（AVS）上のVMを、Azureの管理・監視・セキュリティ・ガバナンスの仕組みに接続する機能だという点です。
2026年6月時点で特に確認すべきポイントは、対応範囲がvCenter Server version 8を前提として整理されていること、Azure Arc resource bridgeが必須になること、そしてVMの電源操作やサイズ変更などの「仮想ハードウェア操作」と、監視・パッチ適用・Defender連携などの「ゲストOS管理」を分けて設計する必要があることです。Microsoft Learnの公式概要では、Azure Arc-enabled VMware vSphereがAzure control planeをVMware vSphereインフラに拡張し、オンプレミスのVMware private cloud、AVS private cloud、Azure全体で一貫した管理体験を提供すると説明されています。(Microsoft Learn)
Azure Arc-enabled VMware vSphereとは
Azure Arc-enabled VMware vSphereは、VMware vCenter ServerとAzureを接続し、vSphere上のリソースをAzure側に投影して管理できるようにするサービスです。
対象になる主なリソースは、VM、テンプレート、ネットワーク、データストア、クラスター、ホスト、リソースプールです。これらをAzure上のリソースとして扱えるようにすることで、管理者はAzureポータルからインベントリを確認し、開発者やアプリケーションチームにはAzure RBACで必要な範囲だけセルフサービス権限を付与できます。公式ドキュメントでは、AzureからVMの作成、サイズ変更、削除、起動、停止、再起動などを実行できることも示されています。(Microsoft Learn)
ただし、仕組みを誤解すると設計を間違えます。Azure Arc-enabled VMware vSphereは、VMware環境をAzure VMに変換するものではありません。実体はあくまでvSphere側に残り、Azureは管理プレーンとして機能します。つまり、vCenter、ネットワーク、ストレージ、権限、監視、パッチ適用の責任分界を整理したうえで導入する必要があります。
何が変わるのか：AzureからVMware環境を扱う範囲が広がる
従来のVMware運用では、vCenterでVMを管理し、監視・セキュリティ・パッチ・権限管理は別々のツールで補う構成が一般的でした。Azure Arc-enabled VMware vSphereを使うと、VMware VMをAzureの管理対象として扱いやすくなります。
| 観点 | 従来の運用 | Azure Arc-enabled VMware vSphere導入後の考え方 |
|---|---|---|
| インベントリ管理 | vCenter中心で確認 | AzureポータルからvSphereリソースを参照 |
| VM操作 | vCenter管理者が操作 | Azure RBACに基づき、AzureポータルやCLI/APIから操作 |
| 開発者セルフサービス | 申請ベースになりやすい | 権限を絞ってVM作成・起動停止などを許可 |
| 監視・セキュリティ | 別ツールとの連携が必要 | Azure Monitor、Defender for Cloud、Sentinelなどと組み合わせやすい |
| パッチ管理 | OSや運用チームごとに分散 | Azure Update Managerなどで統一運用を検討可能 |
| 自動化 | vSphere APIや個別スクリプト中心 | Azure CLI、PowerShell、REST API、SDK、Terraform、Bicep、ARMテンプレートを活用可能 |
実務上の大きな変化は、インフラ管理者だけでなく、開発者やアプリケーションチームもVMware VMのライフサイクル操作に関わりやすくなる点です。公式概要でも、Azure RBACを使って開発者やアプリケーションチームにオンデマンドのVM操作を許可できること、複数のSDKやTerraform、ARM、Bicep、Azure REST API、CLI、PowerShellによる自動化が可能であることが示されています。(Microsoft Learn)
Azure Arc-enabled Serversとの違い
混同しやすいのが、Azure Arc-enabled Serversとの違いです。
Azure Arc-enabled Serversは、ゲストOSレベルでサーバーをAzureに接続する機能です。物理サーバー、仮想マシン、他クラウド上のサーバーなどを対象に、OS内のエージェントを通じて管理します。
一方、Azure Arc-enabled VMware vSphereは、ゲストOSだけでなく、VMware vSphere VMそのもののライフサイクル管理まで対象にします。公式ドキュメントでは、Azure Arc-enabled VMware vSphereはArc-enabled Serversのスーパーセットとして説明されており、VMの作成・読み取り・更新・削除など、仮想マシン単位の操作をAzureから扱える点が違いです。(Microsoft Learn)
判断基準は次の通りです。
| やりたいこと | 選ぶべき機能 |
|---|---|
| OSの監視、ポリシー、パッチ管理だけをしたい | Azure Arc-enabled Servers |
| vSphere上のVM作成、起動停止、サイズ変更までAzureから扱いたい | Azure Arc-enabled VMware vSphere |
| すでにArc-enabled Serversとして接続済みのVMをvCenter管理に紐づけたい | Arc-enabled ServersからvCenterへのリンクを検討 |
| 開発チームにVMware VMのセルフサービス操作を提供したい | Azure Arc-enabled VMware vSphereとAzure RBAC |
最初から全VMにゲスト管理を入れる必要はありません。まずvCenterをArcに接続し、vSphereインベントリをAzureに投影し、必要なVMだけゲスト管理を有効化する進め方が現実的です。
2026年6月時点で確認すべき主な変更点
Microsoft Learnの概要ページでは、Azure Arc-enabled VMware vSphereのサポート対象として「vCenter Server version 8」と「最大9,500 VM」が示されています。GitHub上のドキュメント履歴では、2026年4月30日に対応表現が「vCenter Server versions 7 and 8」から「vCenter Server version 8」へ変更されたことも確認できます。(Microsoft Learn)
この変更は、既存のvSphere 7環境を持つ管理者にとって重要です。過去の手順やブログ記事ではvSphere 7を前提にしている場合がありますが、導入可否の判断では必ず最新の公式サポートマトリックスを確認してください。
vCenter Server 8が前提になる
サポートマトリックスでも、Azure Arc対応VMware vSphereはvCenter Server version 8で動作すると記載されています。さらに、1つのvCenterでサポートされるVM数は最大9,500とされています。(Microsoft Learn)
既存環境で確認すべき項目は次の通りです。
| 確認項目 | 判断基準 |
|---|---|
| vCenterのバージョン | version 8か |
| VM数 | vCenter単位または複数vCenter合計で9,500 VMを超えないか |
| vSphereアカウント | インベントリ読取、対象リソースへのVMデプロイ・更新権限があるか |
| ネットワーク | Azure Arc resource bridgeとAzureエンドポイントの通信が可能か |
| 静的IP | リソースブリッジ用IP、アップグレード用IP、コントロールプレーンIPを確保できるか |
| 運用体制 | 資格情報ローテーション、障害時ログ取得、ヘルス監視を設計しているか |
特にVM数の上限は、PoCでは見落とされがちです。大規模なvCenterを1つだけ持つ企業では、対象範囲を分けられるか、複数vCenterの合計VM数が上限を超えないかを先に確認しましょう。
Azure Arc resource bridgeが必須になる
Azure Arc-enabled VMware vSphereを使うには、vSphere環境にAzure Arc resource bridgeをデプロイする必要があります。resource bridgeは、vCenter ServerとAzureの間で通信するコンポーネントをホストする仮想アプライアンスです。vCenterをAzureに接続すると、vSphereインベントリが自動検出され、vCenter Serverと継続的に同期されます。(Microsoft Learn)
サポートマトリックスでは、resource bridgeの最小要件として8GBメモリ、4 vCPU、インターネットへ直接またはプロキシ経由でアクセスできる外部仮想スイッチが示されています。(Microsoft Learn)
一方、クイックスタートでは、vCenter Server側の前提として、少なくとも3つの空き静的IP、8GB RAMと4 vCPU以上のリソース、200GB以上の空きディスク領域、HAデプロイでは400GBの空きディスク領域などが示されています。(Microsoft Learn)
導入前に、次のような設計メモを作っておくと失敗を減らせます。
| 設計項目 | 事前に決めること |
|---|---|
| resource bridge名 | Azure上で識別しやすい命名規則 |
| カスタムロケーション名 | データセンターや拠点名に合わせる |
| デプロイ先リソースグループ | 運用チームが管理しやすい単位 |
| Azureリージョン | メタデータ保存先とデータ所在地要件 |
| IPアドレス | resource bridge用、アップグレード用、コントロールプレーン用 |
| プロキシ | 明示プロキシ、SSLプロキシ、除外設定 |
| タグ | 拠点、環境、本番・検証、所有チームなど |
影響範囲：誰が何を確認すべきか
Azure Arc-enabled VMware vSphereは、単なる追加機能ではありません。VMware運用、Azure管理、セキュリティ、開発者セルフサービスにまたがるため、関係者ごとに確認点が異なります。
| 対象者 | 主な影響 | 確認すべきポイント |
|---|---|---|
| VMware管理者 | vCenterとAzureの連携、resource bridge運用が追加される | vCenter version 8、権限、ネットワーク、静的IP、データストア容量 |
| Azure管理者 | Azure上にvCenterやVMwareリソースが作成される | リソースグループ、RBAC、タグ、ポリシー、リージョン |
| セキュリティ担当 | Defender、Sentinel、Policy連携の設計が必要 | 監視対象VM、ログ保存先、アラート、最小権限 |
| 開発者・アプリチーム | Azureポータル/APIからVM操作できる可能性がある | 操作可能なリソースプール、ネットワーク、テンプレート、VM操作範囲 |
| 運用担当 | resource bridgeやArc agentの状態監視が必要 | ヘルスアラート、資格情報更新、ログ収集、障害時手順 |
| ライセンス管理者 | Windows ServerやSQL ServerのESU、Software Assurance特典に関係する | 対象VM、AVSかオンプレミスか、課金・特典の条件 |
特に注意すべきなのは、Azure RBACだけを設定しても、実際のVMプロビジョニングに必要なvSphereリソースへの権限がそろっていなければセルフサービスは機能しない点です。公式のセルフサービス設定手順では、VMのプロビジョニングやサイズ変更、ディスク追加、ネットワーク変更、削除を行うには、使用するコンピュート、ネットワーク、ストレージ、VMテンプレートへの権限が必要と説明されています。(Microsoft Learn)
管理者が確認すべき設定ポイント
Azure側の権限を最小権限で設計する
Azure Arc-enabled VMware vSphereには、組み込みロールが用意されています。実務では、管理者用、プロビジョニング用、VM操作用を分けるのが基本です。
サポートマトリックスでは、vCenter Serverのオンボードには「Azure Arc VMware Private Clouds Onboarding」、Arc-enabled VMware vSphereの管理には「Azure Arc VMware Administrator」、VMプロビジョニングやVM操作には「Azure Arc VMware Private Cloud User」や「Azure Arc VMware VM Contributor」が必要最小限のロールとして示されています。(Microsoft Learn)
よくある失敗は、PoC時にOwnerやContributorを広く付与したまま本番へ進めることです。これを避けるには、次のように分けて設計します。
| 用途 | 推奨する考え方 |
|---|---|
| vCenter接続作業 | 限られた管理者にオンボード権限を付与 |
| Arc管理 | resource bridgeやvCenterリソースを管理する運用チームに限定 |
| VM作成 | 対象リソースプール、ネットワーク、データストア、テンプレートに限定 |
| VM操作 | VM単位またはリソースグループ単位で付与 |
| 開発者セルフサービス | Microsoft Entra IDのグループ単位で付与 |
権限設計では「誰がどのVMを作れるか」だけでなく、「どのテンプレートを使えるか」「どのネットワークへ接続できるか」「どのデータストアを使えるか」まで定義しましょう。
vSphereアカウントの権限とローテーションを決める
オンボード時に指定するvSphereアカウントは、Azure Arc対応VMwareがvSphereとやり取りするために使われます。公式ドキュメントでは、このアカウントがresource bridge VM内にローカル保存され、保存時にはKubernetesシークレットとして暗号化されること、資格情報を定期的にローテーションする組織ではAzure Arc対応VMware側の資格情報更新が必要になることが説明されています。(Microsoft Learn)
本番導入では、個人アカウントではなく専用サービスアカウントを使うべきです。さらに、パスワード更新時の作業手順、更新忘れを検知するアラート、緊急時の復旧担当を決めておきましょう。
ネットワークとプロキシを先に通す
Azure Arc resource bridgeは、多数のAzureエンドポイントやMicrosoft Container Registry、Azure Resource Manager、Microsoft Graphなどへの通信が必要です。サポートマトリックスでは、原則として接続はTCP、HTTP接続はHTTPSとSSL/TLS、指定がない限り送信接続であることが示されています。(Microsoft Learn)
企業ネットワークでよく起きる失敗は、PoC用の管理端末だけ通信でき、resource bridge VMやアップグレード用IPからは必要なURLに出られないケースです。オンボード時だけでなく、アップグレードや障害調査のためにも、管理端末、resource bridge VM、コントロールプレーンIPの通信経路を確認してください。
ゲスト管理を有効化する前に確認すること
Azure Arc-enabled VMware vSphereでは、VMの仮想ハードウェア操作とゲストOSベースの管理機能が分かれています。公式概要では、ディスク追加、サイズ変更、削除、電源操作などの仮想ハードウェア操作はゲスト管理を有効にしなくても実行できる一方、ゲストOSベースの機能はArc agentをインストールするゲスト管理によって提供されると説明されています。(Microsoft Learn)
ゲスト管理を有効にすると、Azure Update Manager、Azure Monitor、Microsoft Defender for Cloud、Azure Policy、Azure Automation、Change Tracking and Inventoryなどを利用しやすくなります。Arc agentの大規模インストールに関する公式手順では、エージェント導入がVMの保護、パッチ適用、監視に必要な前提であると説明されています。(Microsoft Learn)
ゲスト管理の前提条件
| 確認項目 | 内容 |
|---|---|
| VMの電源状態 | 対象VMが起動していること |
| VMware Tools | インストール済みかつ実行中であること |
| OS | Azure Connected Machine AgentがサポートするWindowsまたはLinuxであること |
| アーキテクチャ | x86-64が前提。x86やARMベースは対象外 |
| ネットワーク | Arc agentがAzureへ通信できること |
| 権限 | Azure Arc VMware VM Contributorまたは同等のカスタムロール |
| Linux sudo | sudo時に対話プロンプトが出ないようにする必要がある場合がある |
ゲスト管理の導入方法は、Azureポータル、Azure CLIやPowerShellなどのプログラム的な方法、サービスプリンシパル、Configuration Manager、グループポリシー、Ansibleなどのアウトオブバンド方式から選べます。VMware Toolsが入っていないVMでは、Azureポータルからのゲスト管理有効化が使えないため、アウトオブバンド方式を検討します。(Microsoft Learn)
開発者向け：セルフサービス展開で決めるべきルール
開発者やアプリケーションチームにVM操作を任せる場合、自由度を上げすぎると、ネットワーク分離、コスト、セキュリティ、運用品質に影響します。
最初に決めるべきルールは次の5つです。
| ルール | 具体例 |
|---|---|
| 利用可能なテンプレート | Windows Server標準テンプレート、Linux標準テンプレートなど |
| 利用可能なネットワーク | 開発用セグメントのみ、本番ネットワークは不可 |
| 利用可能なリソースプール | チーム別または環境別に分離 |
| VMサイズ変更の範囲 | vCPU・メモリの上限を設定 |
| VM削除の権限 | 開発環境のみ許可、本番は承認制 |
公式のセルフサービス手順では、Azure Arc VMware Private Cloud Userロールを、ユーザーがアクセスすべきリソースプール、クラスター、ホスト、ネットワーク、データストア、テンプレートに割り当て、さらにVMを展開・管理するサブスクリプションまたはリソースグループにはAzure Arc VMware VM Contributorロールを付与する流れが示されています。(Microsoft Learn)
開発者体験を良くするには、Azureポータルで見える名前も重要です。テンプレート名やカスタムロケーション名に「prod」「dev」「tokyo」「osaka」などの意味が分かる語を入れておくと、誤った展開を減らせます。
既存利用者が注意すべき移行ポイント
2023年8月21日より前にAzure Arc-enabled VMware vSphereへオンボードした環境では、新しいバージョンへの切り替えが必要になるケースがあります。公式の移行ページでは、2023年8月21日に大きな変更がロールアウトされ、それ以前にオンボードしたAzure-enabled VMでは、2024年2月27日以降Arc agent付きVMのAzure管理サービス関連操作ができなくなり、2024年4月1日以降は「Remove from Azure」以外の操作ができなくなると説明されています。(Microsoft Learn)
対象になりそうな環境では、次の順番で確認します。
| 手順 | 確認内容 |
|---|---|
| 対象VMの棚卸し | 2023年8月21日以前にオンボードしたVMか |
| ゲスト管理の状態確認 | VM拡張機能やArc agentが入っているか |
| 影響確認 | Azure管理サービス操作やVM操作に制限が出ていないか |
| 削除前の準備 | 必要に応じてVM拡張機能の削除、エージェント切断を計画 |
| 再有効化 | AzureからRemoveした後、同じリソースを再度Enable in Azure |
| 表示確認 | VMリソースがMachine – Azure Arc（VMware）として見えるか |
この作業は、単なる再登録ではありません。監視、ポリシー、Defender、Update Manager、タグ、RBAC、運用手順に影響する可能性があります。実施前に、対象VMの運用時間帯、監視停止の扱い、ロールバック手順を決めてください。
AVS環境で使う場合の注意点
Azure VMware Solution（AVS）private cloudでもAzure Arc-enabled VMware vSphereを利用できます。AVS向けの公式手順では、Arc-enabled Azure VMware Solutionにより、VM、テンプレート、ネットワーク、データストア、クラスター、ホスト、リソースプールの識別と登録、AzureからのVM操作、RBACによる開発者権限付与、Arc-connected machine agentのインストールなどが可能と説明されています。(Microsoft Learn)
ただし、オンプレミスvCenterの手順をそのままAVSに適用しないことが重要です。公式クイックスタートでも、汎用vCenter ServerをAzure Arcへ接続する手順と、AVS private cloud向けの手順は分けて案内されています。(Microsoft Learn)
AVSでは、同じリソースグループの扱い、NSXネットワークセグメント、管理VMからvCenter ServerやNSX Managerへの到達性、AVS特有のESU特典などを確認する必要があります。特にSQL ServerやWindows ServerのExtended Security Updatesを意識する場合、どの方法でArc有効化したかが課金・特典に影響する可能性があるため、AVS公式手順に沿って進めましょう。(Microsoft Learn)
展開時に失敗しやすいポイント
静的IPの不足
Azure Arc resource bridgeでは、静的IPが必要です。クイックスタートでは、vCenter Server側の前提として少なくとも3つの空き静的IPアドレスが必要とされています。さらに、resource bridge VM用、アップグレードシナリオ用、Kubernetesコントロールプレーン用のIP設計が求められます。(Microsoft Learn)
IPが足りない状態でPoCを始めると、オンボード途中で止まったり、将来のアップグレードで詰まったりします。ネットワークチームに依頼する際は、「オンボード時に使うIP」だけでなく「アップグレード時に使うIP」も含めて申請してください。
PowerShell ISEでスクリプトを実行する
Windowsワークステーションでオンボードスクリプトを実行する場合、PowerShell ISEは使わないよう注意が必要です。公式手順では、PowerShell ISEではAzure CLIコマンドからの入力プロンプトが表示されず、スクリプトが停止しているように見える場合があると説明されています。(Microsoft Learn)
実行する場合は、管理者としてPowerShellウィンドウを開き、必要に応じてセッション単位で実行ポリシーをBypassにしてからスクリプトを実行します。
config.yamlを保存し忘れる
オンボード完了後、resource bridgeの構成ファイルを保存し忘れると、後続の管理やアップグレードで困ります。公式手順では、resource bridgeのインストール後にconfig.yamlファイルのコピーを取得しやすい場所に保存しておくことが推奨されています。(Microsoft Learn)
本番では、個人PCではなく、アクセス制御された安全な保管場所に置きましょう。退職者のローカルPCにしかファイルがない、という状態は避けるべきです。
resource bridgeを通常VMのように扱ってしまう
resource bridgeは管理の中核です。通常の業務VMと同じ感覚でバックアップ、リストア、ネットワーク移行を行うと、AzureとvCenterの接続に影響する可能性があります。公式の運用保守ドキュメントでは、resource bridgeのバックアップと復元はサポートされず、接続性に影響すること、ネットワーク移行もサポートされないことが説明されています。(Microsoft Learn)
管理者は、resource bridgeに削除ロックを設定し、Azure Service HealthやResource Healthでヘルスアラートを設定しておくとよいでしょう。公式ドキュメントでも、resource bridgeの削除ロックやヘルスアラートの設定がベストプラクティスとして紹介されています。(Microsoft Learn)
セキュリティ・監視・パッチ管理で活用できること
Azure Arc-enabled VMware vSphereの価値は、AzureポータルからVMを起動停止できることだけではありません。ゲスト管理を有効化すると、Azureの運用サービスをVMware VMにも適用しやすくなります。
公式概要では、Azure Connected Machine Agentを大規模にインストールすることで、Azure machine configuration、Microsoft Defender for Endpoint、Microsoft Defender for Cloud、Microsoft Sentinel、Azure Automation、Azure Update Manager、VM insights、Azure Monitor Agent、Log Analytics workspaceなどを活用できることが説明されています。(Microsoft Learn)
実務では、いきなり全機能を有効化するのではなく、次の順序で進めると管理しやすくなります。
| フェーズ | やること | 成果 |
|---|---|---|
| PoC | 少数VMでvCenter接続とAzure上の表示確認 | 基本構成の妥当性を確認 |
| 管理基盤 | resource bridgeの監視、ロック、ログ収集手順を整備 | 運用継続性を確保 |
| ゲスト管理 | 重要度の低いVMからArc agent導入 | 監視・パッチ管理の効果を確認 |
| セキュリティ | Defender for Cloud、Sentinel、Policy連携を検討 | セキュリティ運用を統合 |
| セルフサービス | 開発環境向けにRBACとテンプレートを公開 | 申請待ちを減らし、展開を標準化 |
ポイントは、本番VMから始めないことです。まず開発・検証環境で、通信、権限、テンプレート、ログ、パッチ適用、アラートの挙動を確認しましょう。
管理者向け導入チェックリスト
| 分類 | チェック項目 | 完了の目安 |
|---|---|---|
| サポート | vCenter Server version 8である | 公式サポート条件と一致 |
| 規模 | vCenterまたは複数vCenter合計で9,500 VM以下 | 上限超過なし |
| Azure | サブスクリプション、リソースグループ、リージョンを決定 | 命名規則とタグも決定 |
| 権限 | オンボード用、管理用、VM操作用のRBACを分離 | Owner常用を避ける |
| vSphere | 専用サービスアカウントを用意 | 必要権限とローテーション手順あり |
| ネットワーク | 必要URL、プロキシ、DNS、NTP、443通信を確認 | 管理端末とresource bridge両方で疎通 |
| IP | resource bridge、アップグレード、コントロールプレーン用IPを確保 | 静的IPを予約済み |
| 容量 | CPU、メモリ、データストア容量を確保 | HA要件も確認 |
| 運用 | config.yaml、kubeconfigの保管場所を決定 | アクセス制御済み |
| 監視 | resource bridgeのヘルスアラートを設定 | 障害時通知先を決定 |
| セキュリティ | Defender、Policy、Sentinel、Update Managerの適用範囲を決定 | 段階導入の対象VMを決定 |
| 移行 | 2023年8月21日以前のオンボードVMを棚卸し | 必要なら新バージョンへ切替 |
このチェックリストを満たせない場合、技術的に接続できても本番運用でつまずく可能性があります。特にネットワーク、権限、resource bridge運用は、導入後に直すよりも事前に固める方が安全です。
まとめ：まずは「接続」ではなく「運用設計」から始める
Azure Arc-enabled VMware vSphereは、VMware vSphere環境をAzureの管理プレーンに接続し、VM管理、セルフサービス、監視、セキュリティ、パッチ管理を一貫した形に近づけるための機能です。
2026年6月時点での実務上の確認ポイントは、vCenter Server version 8、最大9,500 VM、Azure Arc resource bridgeの要件、ゲスト管理の前提条件、Azure RBACによる最小権限設計です。既存利用者は、2023年8月21日以前にオンボードしたVMがないかも確認してください。
次に取るべき行動は、いきなり本番導入することではありません。まずvCenterのバージョンとVM数を確認し、resource bridge用のネットワーク・IP・容量を整理し、PoC対象のVMとリソースグループを決めましょう。そのうえで、開発環境からゲスト管理、監視、パッチ、RBACの動作を検証すると、Azure Arc-enabled VMware vSphereを安全に展開できます。
コメント