Azure CLIでAzure Application GatewayバックエンドプールにVMを追加する方法（Virtual machine相当をNICで実現）

Azure Application Gateway のバックエンドプールに VM を追加したいのに、Azure CLI では IP アドレス登録しかできない…という悩みはよくあります。本記事では、ポータルの「ターゲットの種類（targetType）= Virtual machine」と同じ状態を Azure CLI で実現する手順を、仕組みから具体的なコマンドまでまとめて解説します。

結論：CLIで「VM名」を追加するのではなく、NICのIP構成をバックエンドプールへ関連付ける

最初に結論です。Azure Application Gateway のバックエンドプールは、リクエストの転送先を「VM名」で持つのではなく、IP アドレス / FQDN、またはNIC の IP 構成（IP configuration）として保持します。そのため、Azure Portal で「ターゲットの種類 = Virtual machine」を選んだ場合も、内部的には「VMそのもの」ではなくそのVMに紐づく NIC の IP 設定（backendIpConfigurations）がバックエンドプールへ紐づいているだけです。

つまり、CLIで同じ状態を作りたい場合は、Application Gateway 側のアドレスプールに VM を“追加”するのではなく、VM の NIC 側から、対象のバックエンドプールへ参加させるのが最短ルートです。

なぜ「–add VirtualMachine …」が失敗するのか

「ポータルでは Virtual machine を選べるのに、CLI で --add VirtualMachine が通らない」という現象は、実はとても自然です。バックエンドプールの更新で扱える主なプロパティは、少なくとも以下のようなものに限られます。

backendAddresses：IP アドレスや FQDN を直接登録する
backendIpConfigurations：NIC の IP 構成（リソースID）を参照して登録する

そのため、VirtualMachine のようなプロパティを追加しようとすると「そんなプロパティは存在しない」というエラーになります（ポータルの targetType は UI 上の選択肢であって、バックエンドプールに VirtualMachine というプロパティが追加されるわけではありません）。

バックエンドプールの「ターゲットの種類」と、実体の対応表

ポータルの表示と、実際にバックエンドプールが保持しているものを対応させると、理解が一気に楽になります。

ポータルのターゲットの種類	内部的な実体（保持している参照）	CLIでの実現方法	向いているケース
IP address / FQDN	backendAddresses（IP/FQDN の文字列）	`az network application-gateway address-pool update --add backendAddresses ...` または `--servers`	オンプレ/他クラウド/外部機器など、Azureリソースに紐づかないバックエンド
Virtual machine	backendIpConfigurations（NIC の IP 構成 ID）	`az network nic ip-config address-pool add` で NIC 側に紐付け	Azure VM を確実にターゲットとして扱いたい（IP変更の影響を減らしたい）
Virtual machine scale set	VMSS のネットワーク構成経由でバックエンドに紐付く	VMSS 作成・更新時の関連付け（構成により手順が変わる）	スケールアウト/インを前提に、同一構成のバックエンドを増減させたい
App Service	App Service の参照（構成により）	ポータル/ARM/Bicep 等で構成	PaaS をバックエンドにしたい

IPアドレスでバックエンドを登録する方法（backendAddresses）

質問のとおり、IP アドレス指定での登録は CLI でも問題なく可能です。バックエンドが固定IPだったり、Azure外のターゲットだったりする場合は、こちらがシンプルです。

IPアドレスを追加する

az network application-gateway address-pool update \
  -g <appgw-resource-group> \
  --gateway-name <appgw-name> \
  -n <backend-pool-name> \
  --add backendAddresses ipAddress=<10.x.x.x>

CLI の例では ipAddress キーが使われます（環境によっては ip_address で通るケースもありますが、公式例に合わせるなら ipAddress を推奨します）。

複数のバックエンドをまとめて上書きする（–servers）

az network application-gateway address-pool update \
  -g <appgw-resource-group> \
  --gateway-name <appgw-name> \
  -n <backend-pool-name> \
  --servers 10.0.0.4 10.0.0.5 10.0.0.6

--servers は「バックエンドサーバーの IP または DNS 名のリスト」を受け取り、結果としては IP/FQDN ターゲットとして扱われます。ポータルでいう「Virtual machine」ターゲットにはなりません。

IPアドレスを削除する（インデックス指定）

既存の要素を削除する場合は、backendAddresses の配列インデックスを指定します。まずは現在の登録状況を確認します。

az network application-gateway address-pool show \
  -g <appgw-resource-group> \
  --gateway-name <appgw-name> \
  -n <backend-pool-name> \
  --query "backendAddresses[].ipAddress" -o table

次に、削除したいインデックス（例：0）を指定して削除します。

az network application-gateway address-pool update \
  -g <appgw-resource-group> \
  --gateway-name <appgw-name> \
  -n <backend-pool-name> \
  --remove backendAddresses 0

ポータルの「Virtual machine」と同じ状態をCLIで作る方法（NICベース）

ここからが本題です。targetType = Virtual machine を CLI で再現したいなら、やるべきことは一つです。

対象VMの NIC の IP 構成（ip-config）に対して、「この Application Gateway のバックエンドプールに所属する」と関連付ける

この操作を行うと、ポータルで Virtual machine を選んで追加した時と同じ「NIC参照」の状態になります。

全体の流れ

Application Gateway のバックエンドプール（address-pool）の リソースID を取得する
VM に紐づく NIC 名と IP 構成名（ipconfig）を取得する
az network nic ip-config address-pool add で関連付ける
必要なら remove で解除し、バックエンドヘルスで疎通確認する

バックエンドプールのリソースIDを取得する

まずは Application Gateway 側で、対象バックエンドプールの ID を取得します。

az network application-gateway address-pool show \
  -g <appgw-resource-group> \
  --gateway-name <appgw-name> \
  -n <backend-pool-name> \
  --query "id" -o tsv

VMからNIC名を取得する

次に、VM に紐づく NIC を取得します。VM が複数 NIC を持っている場合は、どの NIC をバックエンドにしたいか（アプリが待ち受けているIPがどの NIC か）を意識して選んでください。

az vm show \
  -g <vm-resource-group> \
  -n <vm-name> \
  --query "networkProfile.networkInterfaces[].id" -o tsv

出力がリソースIDなので、シェルで NIC 名だけ抜く場合は以下のようにします。

NIC_ID=$(az vm show -g <vm-resource-group> -n <vm-name> \
  --query "networkProfile.networkInterfaces[0].id" -o tsv)
NIC_NAME=$(basename "$NIC_ID")
echo "$NIC_NAME"

NICのIP構成名（ip-config-name）を取得する

NIC の中には ipconfig1 のような IP 構成が入っています（複数の IP 構成を持つこともあります）。名前を確認します。

az network nic ip-config list \
  -g <vm-resource-group> \
  --nic-name <nic-name> \
  --query "[].name" -o table

NICをバックエンドプールへ追加する（Virtual machine 相当）

いよいよ関連付けです。ポイントは、更新対象は Application Gateway ではなく NICであることです。

az network nic ip-config address-pool add \
  --resource-group <vm-resource-group> \
  --nic-name <nic-name> \
  --ip-config-name <ip-config-name> \
  --address-pool <backend-pool-resource-id>

--address-pool には「バックエンドプールの名前」または「リソースID」を渡せますが、実務では ID を渡す方が確実です（別リソースグループ構成でもブレません）。また、CLI では状況により --gateway-name を補助的に指定できることもあります。

削除（解除）する場合

バックエンドから外す場合も NIC 側を操作します。

az network nic ip-config address-pool remove \
  --resource-group <vm-resource-group> \
  --nic-name <nic-name> \
  --ip-config-name <ip-config-name> \
  --address-pool <backend-pool-resource-id>

実務向け：必要情報を自動取得して追加するサンプル（Bash）

コピペで流れが掴めるように、変数を使った例も載せます（AppGW と VM のリソースグループが同一/別でも動く形を意識しています）。

AG_RG="<appgw-resource-group>"
AG_NAME="<appgw-name>"
POOL_NAME="<backend-pool-name>"

VM_RG=""
VM_NAME=""

# 1) バックエンドプールID取得

POOL_ID=$(az network application-gateway address-pool show 
-g "$AG_RG" --gateway-name "$AG_NAME" -n "$POOL_NAME" 
--query "id" -o tsv)

# 2) VMからNIC名を取得（最初のNICを採用）

NIC_ID=$(az vm show -g "$VM_RG" -n "$VM_NAME" 
--query "networkProfile.networkInterfaces[0].id" -o tsv)
NIC_NAME=$(basename "$NIC_ID")

# 3) NICのIP構成名を取得（先頭を採用）

IPCONFIG_NAME=$(az network nic ip-config list -g "$VM_RG" --nic-name "$NIC_NAME" 
--query "[0].name" -o tsv)

# 4) NICをバックエンドプールへ関連付け（Virtual machine 相当）

az network nic ip-config address-pool add 
-g "$VM_RG" --nic-name "$NIC_NAME" -n "$IPCONFIG_NAME" 
--address-pool "$POOL_ID"

echo "Added: $VM_NAME ($NIC_NAME/$IPCONFIG_NAME) => $POOL_NAME"

反映確認：バックエンドヘルスを確認する

「追加はできたが疎通しない」「ポータル表示が想定と違う」などの切り分けには、バックエンドヘルスが有効です。

az network application-gateway show-backend-health \
  -g <appgw-resource-group> \
  -n <appgw-name> -o jsonc

IP登録とNIC登録、どちらを選ぶべきか

同じ“VMへ転送する”でも、IP 直指定と NIC 参照では運用性が変わります。迷ったときの判断材料を表にまとめます。

観点	IPアドレス指定（backendAddresses）	NIC指定（backendIpConfigurations / Virtual machine相当）
設定の簡単さ	簡単（IPを足すだけ）	少し手順が多い（NIC/IP構成を特定する）
IP変更への強さ	弱い（IPが変わるとメンテ必須）	強い（参照がNIC側なので運用が安定しやすい）
Azureリソースとの整合	「外部サーバ」扱いになりやすい	ポータルでも「Virtual machine」扱いになりやすい
おすすめシーン	外部機器/オンプレ/固定IPが確実なバックエンド	Azure VM を素直にバックエンドにしたい、IaC/自動化したい

よくあるつまずきとトラブルシューティング

追加できたのに 502 / Unhealthy になる

バックエンドプールへの関連付け自体は成功していても、ヘルスプローブが失敗していると Application Gateway は転送しません。以下の観点を優先して確認してください。

NSG：Application Gateway のサブネットから、バックエンドVMの待受ポート（例：80/443/8080）に到達できるか
OS/ミドルウェア：VM側で本当に待ち受けているか（ローカルで curl http://localhost:80/ など）
プローブ設定：パス（/health など）、ホスト名、プロトコル（HTTP/HTTPS）、SNI/証明書要件が合っているか

VMが複数NIC/複数IP構成を持っていて、どれを追加すべきか分からない

バックエンドにしたいのは「アプリが待ち受けている IP」です。VM の NIC/ ipconfig を列挙して、どのプライベートIPが対象かを先に特定すると事故が減ります。

# NIC のIP構成とIPアドレスを一覧で見る
az network nic show -g <vm-resource-group> -n <nic-name> \
  --query "ipConfigurations[].{name:name, privateIP:privateIPAddress}" -o table

「VMとして登録したい」のに、そもそもVM名で指定できないの？

できません。Application Gateway のルーティングは VM 名ではなく IP/FQDN ベースであり、ポータルで Virtual machine を選ぶ場合も実際に選択肢として出てくるのは「VMに紐づく NIC」です。したがって、CLI でも VM 名を直接渡して“VM登録”するのではなく、NIC 参照として登録するのが正しいアプローチです。

まとめ：Azure CLIでtargetType=Virtual machine相当を実現する最短手順

Azure Application Gateway のバックエンドプールは「VM名」を保持しない。基本は IP/FQDN または NIC の IP 構成参照。
ポータルの「ターゲットの種類 = Virtual machine」は、内部的に NIC の IP 構成（backendIpConfigurations）を関連付けている。
CLI で同じ状態を作るなら、NIC 側から az network nic ip-config address-pool add を実行する。
IPアドレス直指定（backendAddresses）は簡単だが、運用要件（IP変更耐性など）によっては NIC 参照の方が安定しやすい。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Azure CLIでAzure Application GatewayバックエンドプールにVMを追加する方法（Virtual machine相当をNICで実現）

結論：CLIで「VM名」を追加するのではなく、NICのIP構成をバックエンドプールへ関連付ける

なぜ「–add VirtualMachine …」が失敗するのか

バックエンドプールの「ターゲットの種類」と、実体の対応表

IPアドレスでバックエンドを登録する方法（backendAddresses）

IPアドレスを追加する

複数のバックエンドをまとめて上書きする（–servers）

IPアドレスを削除する（インデックス指定）

ポータルの「Virtual machine」と同じ状態をCLIで作る方法（NICベース）

全体の流れ

バックエンドプールのリソースIDを取得する

VMからNIC名を取得する

NICのIP構成名（ip-config-name）を取得する

NICをバックエンドプールへ追加する（Virtual machine 相当）

削除（解除）する場合

実務向け：必要情報を自動取得して追加するサンプル（Bash）

反映確認：バックエンドヘルスを確認する

IP登録とNIC登録、どちらを選ぶべきか

よくあるつまずきとトラブルシューティング

追加できたのに 502 / Unhealthy になる

VMが複数NIC/複数IP構成を持っていて、どれを追加すべきか分からない

「VMとして登録したい」のに、そもそもVM名で指定できないの？

まとめ：Azure CLIでtargetType=Virtual machine相当を実現する最短手順

この記事を書いた人

コメント

コメントするコメントをキャンセル

Azure CLIでAzure Application GatewayバックエンドプールにVMを追加する方法（Virtual machine相当をNICで実現）

結論：CLIで「VM名」を追加するのではなく、NICのIP構成をバックエンドプールへ関連付ける

なぜ「–add VirtualMachine …」が失敗するのか

バックエンドプールの「ターゲットの種類」と、実体の対応表

IPアドレスでバックエンドを登録する方法（backendAddresses）

IPアドレスを追加する

複数のバックエンドをまとめて上書きする（–servers）

IPアドレスを削除する（インデックス指定）

ポータルの「Virtual machine」と同じ状態をCLIで作る方法（NICベース）

全体の流れ

バックエンドプールのリソースIDを取得する

VMからNIC名を取得する

NICのIP構成名（ip-config-name）を取得する

NICをバックエンドプールへ追加する（Virtual machine 相当）

削除（解除）する場合

実務向け：必要情報を自動取得して追加するサンプル（Bash）

反映確認：バックエンドヘルスを確認する

IP登録とNIC登録、どちらを選ぶべきか

よくあるつまずきとトラブルシューティング

追加できたのに 502 / Unhealthy になる

VMが複数NIC/複数IP構成を持っていて、どれを追加すべきか分からない

「VMとして登録したい」のに、そもそもVM名で指定できないの？

まとめ：Azure CLIでtargetType=Virtual machine相当を実現する最短手順

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル