https://blogs.networld.co.jp/entry/2026/03/10/134754

みなさん、こんにちは。ネットワールドでSA（ソリューションアーキテクト）として活動している後藤です。

みなさん、Azure Arcはお使いでしょうか？　オンプレのWindows ServerなどをAzureの一部として扱うことができる便利ツールで、オンプレのWindows ServerをAzure Monitorで監視したり、Defender for Cloudでセキュリティ評価ができたりする優れものです。

そんなAzure Arcですが、オンプレミスにあるVMware環境もAzure Arcを使ってAzureの一部として組み込める機能をご存じでしょうか？

今回は、ニッチではあるかもしれないけれども便利な機能として「Azure Arc対応VMware vSphere」を紹介したいと思います。

1：最初に注意事項とお願い

本記事は、筆者の知りうる公開情報と実機検証をもとに記述しています。

内容については、正確を期することを心がけていますが、万が一誤った記述があればご指摘いただけると幸いです。

また、Microsoftの公式見解が必要な場合は、Microsoftサポートまでお問い合わせいただけますよう、よろしくお願いします。

2：Azure Arc対応VMware vSphereとは？

Microsoftの公式ドキュメントは以下のものになります。

learn.microsoft.com

簡単に、誤解を恐れずに表現するのであれば、vCenter Serverを中心とするVMware環境をAzure ArcでAzureに接続し、AzureポータルからVMware環境を操作できる仕組みになります。

vCenterとAzureポータルではまるで考え方が違うので、できること、できないことがそこそこあります。それらについては実際のオペレーション画面を含めて次回解説したいと思います。

今回は環境構築編とのことで、どのようにしてオンプレミスのvCenter Serverを中心とするVMware環境をAzure ArcでAzureに接続するのか、また実際の環境構築の手順を解説をしたいと思います。

アーキテクチャー図は前述の公式ドキュメントを参照していただきたいと思いますが、ポイントはVMware環境上に新規で構築する「Azure Arcリソースブリッジ」にあります。

Azure Arcリソースブリッジ（以下ARB）という名前でピンときた方もいらっしゃるかもしれませんが、Microsoftのハイブリッドクラウドソリューションである「Azure Local」でも利用されている「Azureとオンプレミスを接続するブリッジサーバー」のようなものとご認識いただければ。

このARBがAzureポータルでユーザーが行った操作を受け止めて、vCenter Serverなどに転送します。また結果を参照してAzureに返す、という動きをします。

これによりAzureポータルでの指示がオンプレのvCenter Serverで実行されることになり、ユーザーは（Azureポータルから操作できる範囲であれば）vCenter ServerではなくAzureポータルを参照すればよいという形になります。ある意味、セルフサービスポータルとしてAzureポータルが利用できる感じですね（画面1）。

画面1の右のツリーを見ていただくと、様々なvCenterのインベントリを見ることもできることにお気づき頂けるかと思います。

このあたりのオペレーションについては次回以降に紹介するとして、まずはvCenter ServerをAzureに接続する環境構築から始めたいと思います。

3：Azureに接続するVMware環境

今回Azure ArcでAzureに接続するVMware環境には「VMware vSphere 8.0U2」を使用しました。vCenter Serverは8.0.2でVMware ESXiも8.0.2です。

前述のドキュメントにも記載されていますが、現在Azure Arc対応VMware vSphereに対応しているVMware vSphereは、vCenter Server バージョン7系とバージョン8系になり、最新のvCenter Serverであるバージョン9系には対応していません（9.0系はVCF/VVFなので、名称のアレコレはあると思いますが、ここでは見逃してください）。

これらの環境は、インターネットに接続できる環境にしています。

また、VMware環境とは別に作業／管理用のWindows Server 2022を用意しました。

この管理端末はVMware環境上にはなく、管理用のHyper-V上で稼働しています。

基本的にはこの3つの環境で完結します。

というわけで、ざっくり構成図はこんな感じになります。

4：環境構築の手順

環境構築ですが、ざっくりと以下の手順になります。

IPアドレスの準備
通信要件確認
VMware環境のアクセス権
Azure側のRBAC設定／確認
Azureポータルからオンボードスクリプトをダウンロード
管理端末でのオンボードスクリプトの実行
Azureポータルからの確認

では、順に追いかけていきましょう。

5：必要なIPアドレス

Azure Arc対応VMware vSphereの通信要件ですが、最初に押さえておきたいのがARBに割り当てが必要なIPアドレスの数です。

図1にも記述していますし、またオンボード作業の際にも解説しますが、3つのIPアドレスが必要になります。また、2つは連続したアドレスを使用する必要がありますので、あらかじめ準備しましょう。

3つの連続したIPアドレスである必要はなさそうですが、3つの連続したIPアドレスですと安心です。本環境は図1の通り連続した3つのIPアドレス（192.168.100.47-192.168.100.49）を用意しました。

また管理端末からオンボード作業等を行うため、この管理端末のIPアドレスからも後述する通信が発生します。この端末のIPアドレスも意識したほうが良いかと思います。本環境では「192.168.100.61」を採番しています。

そのほかはvCenterやESXiホストのIPアドレス、DNSのIPアドレス等々になりますが、この辺りは既存環境があると思うので、それらのIPアドレスや名前解決ができるかをご確認ください。

6：通信要件

次に実際の通信対向ですが、大まかに分けて以下のものになります。

ARBおよび管理端末からインターネット（Azure）への接続（送信接続要件）
ARBおよび管理端末から内部リソース（DNSとか）への通信
ARBからvCenter Serverへの通信

最初のARBおよび管理端末からのインターネット（Azure）への接続ですが、前述した通り送信接続要件であり、すべてアウトバウンドの通信になります。

また、HTTPSによる通信のみとなり、特別な通信ポートを使用することはありません（唯一の例外としてはDNSの53/UDPですね。インターネット上のDNSを参照させる場合ですが）。

通信先（URL）については、以下のドキュメントにまとまっていますのでご一読ください。

learn.microsoft.com

上記のドキュメントの中でも触れられていますが、「プロキシURL許可リスト」という表現がありますので、プロキシにも対応しています。オンボード作業中にプロキシ指定が可能となっていますので、後ほど紹介します。

次のARBや管理端末からの内部リソースへのアクセスですが、ARBはコンテナで実装されているため、Kubernetes（以下K8s）で利用される通信ポートへの送受信が発生します。この辺りは上記のドキュメント内で「受信接続の要件」として送信元/送信先を踏まえてまとまっていますので、ご確認ください。

アンカーリンク付きのURLはこちらになります。

learn.microsoft.com

インターネットには出ない内部通信のみなので特に問題はないと思いますが、個別に仮想スイッチでACLを仕掛けたい場合や、内部通信もすべてFirewallを通す設計になっている場合は、こちらの受信要件に従ってポートを開けてください。

本記事の環境では、そのあたりの通信制限は一切行っていません。

最後のARBからvCenter Serverへの通信についても上記ドキュメントに書いてありますが、vCenter ServerのFQDNに対して443/TCPで接続するだけなので、特段の問題はないと思います。

注意していただきたいのが、「受信接続の要件」の項で「さらに、VMware VSphere には以下が必要です。」の文言があり、6つの項目（執筆（2026/03上旬）時点）が記載があります。

その表の最初はvCenter ServerのURLに対して443/TCPのアクセスがある、と書いてあるのですけども、それ以降の5つのうち1つが「ARBからのインターネット接続要件」、のこりの4つが「管理端末からのインターネット接続要件」になっています。

このURLは「ファイアウォール/プロキシ URL 許可リスト」に含まれないものもあるので、この辺りも注意深くチェックしてください。

7：VMware環境のアクセス権

ARBからvCenter Serverを操作するためのアカウントを設定することになります。

このアカウントには以下のドキュメントに示されたvCenter Serverの権限が必要になります。

learn.microsoft.com

アカウントパスワードの変更などの資格情報のメンテナンスにも対応していますので、パスワード変更ポリシーが存在する組織での運用も考慮されています。

使用するアカウントに対して、適切な権限を割り当ててください。

今回の検証では、超手抜きでAdministratorアカウントを使用しています。本番運用では厳禁だと思いますので、マネしないでください。

8：Azure側のRBAC設定／確認

Azure側の権限もこちらのドキュメントに書いてあります。

learn.microsoft.com

例に漏れず、上記日本語ドキュメントと実際のAzureポータルでの表示が一致しないので、参考までに対応表を記載しますが、ポータル側で改善されると役に立たないので、参考程度でお願いします。

日本語ドキュメント表記	ポータル英語表記	ポータル日本語表記
Azure Arc VMware プライベートクラウドのオンボード	Azure Arc VMware Private Clouds Onboarding	Azure Arc VMware Private Clouds Onboarding
Azure Arc VMware 管理者	Azure Arc VMware Administrator	Azure Arc VMware 管理者ロール
Azure Arc VMware プライベートクラウドユーザー	Azure Arc VMware Private Cloud User	Azure Arc VMware プライベートクラウドユーザー
Azure Arc VMware VM 共同作成者	Azure Arc VMware VM Contributor	Azure Arc VMware VM 共同作成者
表1：ドキュメント/ポータル日英表記対応表

翻訳正解率50％はちょっと改善していただきたいですね……。

環境構築では最低限リソースグループに対して「Azure Arc VMware Private Clouds Onboarding」があれば問題ない「はず」なんですが、執筆時点（2026/03初旬）では、権限不足でデプロイが失敗します（画面2）。

リソースグループに対してデプロイユーザーに共同作成者のロールを割り当てるとデプロイ成功するので、権限不足で間違いなし。

エラーを見ていると「Microsoft.ResourceConnector/appliances/listkeys/action」の権限がない、という感じなので、とりあえずカスタムロールを作成して（画面3）、リソースグループに対してデプロイユーザーに割り当てました。

したがって、執筆時点ではリソースグループでデプロイユーザーに対して、以下の2つのロールを割り当てています。

Azure Arc VMware Private Clouds Onboarding
Arc Resource Bridge ListKeys（カスタムロール）

デプロイユーザーで環境の管理を行う場合には「Azure Arc VMware 管理者ロール」も割り当てる必要があります。

こちらのRBACが設定されたアカウントは、ARBをデプロイする際に指定する必要があります。次の作業でのAzure ポータルアクセスにも使用できます。

9：Azureポータルからオンボードスクリプトをダウンロード

ここまで準備ができたら、ここから先は実作業になります。

まずはAzureポータル上で諸々の設定を行って、ARBをデプロイするためのスクリプトを生成／ダウンロードします。Azureポータルにサインインするユーザーは、権限を持ったユーザーになりますが、手順の中でリソースプロバイダー（Microsoft.ResourceConnectorとMicrosoft.ConnectedVMwarevSphere）の登録を行う関係で、「初回だけ」サブスクリプションにも権限があるユーザーで実施すると幸せになれるかもしれません。

リソースプロバイダーは1回だけ登録すればOKなので、2回目以降は最小権限ユーザーで問題ないです。

まずはAzure Arcのページに行き、左ツリーから「サポートされている環境」→「VMware vCenter」を選択し、右ペインで「追加」をクリックします（画面4）。

「AzureへのvCenterの接続」という画面でARBを新規作成するか、それとも既存のARBを追加するかの2択になりますので、ここでは「リソースブリッジの新規作成」にチェックを入れて「次へ」をクリックします（画面5）。

次のページでは、ARBを作成するサブスクリプションやリソースグループの指定になります。この辺りの設定は、Azure上でみえるリソースでありオンプレ環境は関係ない設定ですね。名前などを入力し終わったら「次へ」をクリックします（画面6）。

適切なタグを設定して「次へ」をクリック（画面7）。

サブスクリプションに対して、適切なリソースプロバイダーが登録されていない場合は、この画面で登録できます（当然権限があれば、ですが）。

前述の通りリソースプロバイダーの登録権限があるユーザーであれば「登録」をクリックします（画面8）。

登録が完了すると、自動作成されたオンボードスクリプトが表示されます。こちらのオンボードスクリプトをオンプレミスの管理端末で実行することになりますので、「スクリプトをダウンロードする」ボタンをクリックしてPowerShellスクリプトを保存します（画面9）。

見ていただくとわかる通り、オンボードスクリプトはWindowsだけではなく、Linuxでも実行できます。適切なプラットフォーム（今回はWindows端末ですが）で使用可能なスクリプトをダウンロードしてください。

Azureポータルでの作業は以上になりますので、「閉じる」ボタンをクリックしてください。

10：管理端末でのオンボードスクリプトの実行

項番9でダウンロードしたPowerShellスクリプトを管理端末の適切なフォルダにコピーします。今回は管理端末の「C:\temp」にコピーしました。

オンボードスクリプトが実施する作業として、Azure CLIの追加インストール（インストールされていなければ）などもあるので、管理者権限での実行が安心です。

ではPowerShellで実行してみましょう。オプション不要で「resource-bridge-onbording-script.ps1」を実行します（画面10）。

実行直後にスクリプト実行端末である管理端末が、インターネットに接続する際にプロキシを経由する必要があるかを聞いてきます。プロキシは必要ないので、今回は「n」で応答します。

必要なモジュールなどが自動ダウンロードされて管理端末にインストールされます。

しばらくするとAzureへのサインインが必要か確認されるので「y」（必要）で応答し、デバイスコードによるサインインを実施します（画面11）。この時サインインするユーザーは、項番8で確認した必要な権限をもったEntra IDユーザーになります。

サブスクリプションの選択画面が表示されますので、適切なサブスクリプションを選択します（画面12）。

サブスクリプションの選択が完了すると、オンボード作業が開始されます。

最初はAzureに接続するvCenter Serverの情報、すなわちvCenter ServerのFQDNとvCenter ServerのユーザーID／パスワードを入力します（画面13）。

ここでは横着してvCenter Serverのadministratorを指定していますが、運用環境では適切な権限のユーザーを指定してください。

問題がなければ確認は「y」で応答します。

指定したvCenter Serverに接続ができると、ARBをデプロイするESXiホスト（もしくはクラスター）やデータストアなどを選択する手順になりますので、適切な選択肢を応答してください。最後のネットワークの選択では、通信要件が満たせるネットワークの選択が必要になります（画面14）。

続いてARBのIPアドレスの設定になります（画面15）。

設定する項目は以下の通りです。（）内は今回の設定値になります。

ARBが接続するネットワークのサブネット（192.168.100.0/24）
デフォルトゲートウェイ（192.168.100.250）
DNSサーバー（192.168.100.4）
ARBのIPアドレスの連続枠のスタートアドレス（192.168.100.47）
ARBのIPアドレスの連続枠のエンドアドレス（192.168.100.48）
ARBのコントロールプレーンのIPアドレス（192.168.100.49）

「ARBのIPアドレスの連続枠」は項番5で紹介した通り、2つ以上の連続したIPアドレスである必要があります。「ARBのコントロールプレーンのIPアドレス」は連続している必要はないですが、IPアドレスはおおよそにして枠で取得すると思うので連続したレンジになるかもしれませんね。

そして最後にARBがインターネットと通信するときにプロキシを使用するかの設定になりますので、今回は「n」で応答します（画面16）。

以上で設定の入力が完了し、ARBのデプロイが開始されます。必要なコンポーネントのダウンロードが開始されますので、それなりに時間がかかりますのでお待ちください。

なお、途中で「Legal Notice（法律通知）」が表示されますので一応目を通しておいたほうが良いかと思います。（図17）。特に応答も必要ないので、気が付かない人も多いかもしれませんが、一応。

そのまま待機して、プロンプトが返ってくると作業完了になります（画面18）。

11：Azureポータルからの確認

作業完了後のAzureポータルの状況を見てみましょう。

なお、確認を行うためには「Azure Arc VMware 管理者ロール」のロールが割り当てられたユーザーである必要があります。

Azure Arcのページを見てみると、接続されているvCenter Serverとして、今回オンボードしたvCenter Serverが表示されています。表示名は項番9で設定したリソース名ですね（画面19）。

リソースを開くと、vCenter Serverの情報を確認することができます（画面20）。vCenter ServerのFQDNなどを確認することができます。

左ツリーの「設定」を開くと、当該vCenter Serverのリソースを確認することができ、画面1で紹介したように仮想マシンやvCenter上のリソースプール、ネットワーク、データストアなどを見ることができます。ここから先のオペレーション方法については、次回紹介したいと思います。

12：作業完了後のvCenter Serverと管理端末

オンボードスクリプトを実行した後のvCenter Serverですが、仮想マシンとテンプレートが1つずつ追加されています（画面21）。

4vCPU／16GBの仮想マシンができていますが、これがARBです。

IPアドレスは連続枠のアドレス帯の最初のアドレスになっています。アップデートがかかると仮想マシンが差し替えられるので、2つ目のアドレスに変わるはずです。再度アップデートがかかると元のアドレスに戻る、という感じですね。

この仮想マシン上にコンテナが存在しており、そのコンテナでARBが動いています。

したがって、この仮想マシンやコンテナで何かしらの障害がおこると、Azureとの接続が切断されますので注意してください。

ARBはコンテナで実装されていると紹介しましたが、ではそのコンテナに何かしらの障害が起きたときには、どのようにアクセスすればよいでしょうか？

オンボードスクリプトを実行したときには、仮想マシンやコンテナのアカウント情報は設定しなかったはずです。

実はオンボードスクリプトを置いたフォルダ（今回の場合、管理端末のc:\temp）にいろいろとファイルが作成されており、実行ログの他に「kubeconfig」ファイルが作成されています（画面22）。

このファイルにARBが稼働しているk8sクラスタに接続するための情報が格納されています。普段は触ることがないと思いますが、問題発生の際にAzureサポートの指示でARBのログを回収する際に必要になりますので、絶対に無くさないようにしてください。

13：最後に

Azure Arc対応VMware vSphereを利用するための環境構築を行いました。

比較的簡単に環境が構築できることがお分かりいただけたかと思います。

次回は、実際にAzureポータルからオンプレのVMware環境上に仮想マシンを作ったり、仮想マシンを操作してみたりと、ユーザーオペレーションを見ていきたいと思います。