Azure Monitor Agent Network Configurationを確認する目的は、「Azure Monitor Agentがどの経路でAzure Monitorへ接続するか」を明確にし、ファイアウォール、プロキシ、DCR、DCE、Private Linkを正しくそろえることです。結論から言えば、管理者はまず通信経路を「直接接続」「プロキシ経由」「Log Analyticsゲートウェイ経由」「Private Link経由」のどれにするか決め、その後にサービス タグ、許可エンドポイント、VMSSやAzure Arcの展開方法を確認する必要があります。
2026年5月更新の公式情報では、Azure Monitor Agentが直接プロキシ、Log Analyticsゲートウェイ、Private Linkを使った接続をサポートすること、ネットワーク分離を有効にするための設定、VMSSやAzure Arc対応サーバーでのプロキシ設定例が整理されています。特に、Private Link利用時のDCE要件、HTTPS検査の無効化、VMSSの手動アップグレードポリシー、Log Analyticsエージェントからの移行中の二重取り込みに注意が必要です。(Microsoft Learn)
Azure Monitor Agent Network Configurationで最初に決めるべきこと
Azure Monitor Agent Network Configurationで最初に決めるべきなのは、エージェントからAzure Monitorへの通信経路です。ここを曖昧にしたままDCRやファイアウォールを設定すると、「エージェントは入っているのにログが来ない」「VMSSの一部だけ収集できない」「Private Link化したはずなのにパブリック経路が残る」といったトラブルにつながります。
| 通信方式 | 向いている環境 | 主な確認ポイント |
|---|---|---|
| 直接接続 | VMからAzure Monitorの公開エンドポイントへアウトバウンド通信できる環境 | サービス タグ、ファイアウォールの許可先、HTTPS検査の無効化 |
| プロキシ経由 | 社内プロキシや境界プロキシを必ず通す環境 | proxy.mode、プロキシ認証、資格情報の保護、Linux版エージェントのバージョン |
| Log Analyticsゲートウェイ経由 | 複数のサーバー通信をゲートウェイに集約したい環境 | ゲートウェイの許可リスト、DCR取得用エンドポイント、サービス再起動 |
| Private Link経由 | インターネット露出を抑え、閉域に近い構成にしたい環境 | DCE、Azure Monitor Private Link Scope、DCRとの関連付け |
重要なのは、方式を混在させる場合でも「どのVM群がどの経路を使うのか」をリソース グループ、サブスクリプション、リージョン、ワークロード単位で分けて管理することです。特に運用中の環境では、先に一覧表を作り、VM、VMSS、Azure Arc対応サーバー、Log Analyticsワークスペース、DCR、DCE、Private Linkの関係を見える化してから設定を変更してください。
2026年5月更新で確認すべき主な変更点
今回の公式情報は、単に「通信先の一覧」を示すだけでなく、展開・移行・運用時に間違えやすいポイントを実務寄りに補強している点が重要です。GitHub上のMicrosoftDocs履歴では、2026年5月12日のコミットでAzure Monitor Agentのネットワーク構成ページに対して、VMSS向けサンプルや既定値へ戻す手順などの修正・追加が行われています。Microsoft Learn上の表示では、該当ページの最終更新日は2026年5月13日です。(GitHub)
管理者が特に確認すべきポイントは次のとおりです。
| 確認項目 | 実務上の意味 |
|---|---|
| VMSS向けのPowerShell設定例が整理された | VMSSモデルへ拡張機能設定を入れた後、既存インスタンスへ反映する必要があるか確認しやすくなった |
| プロキシ構成を既定値へ戻す例が明確化された | 誤ったプロキシ設定を解除する際に、空の設定 {} を使う場面を判断しやすくなった |
| Azure Arc対応サーバーの設定例が補正された | Arc対応サーバーではVM向けコマンドと混同しないことが重要になった |
| VMSSの手動アップグレードポリシーへの注意が明記された | モデルだけ更新しても既存インスタンスへ反映されないケースを防ぎやすくなった |
| Private Link利用時のDCE要件が明確に示されている | すべてのDCRでDCEを使う必要がある構成を見落としにくくなった |
ここで注意したいのは、「新しい接続先がすべて追加された」と短絡的に理解しないことです。今回の更新は、ネットワーク構成の選択肢、サンプル、注意点をより運用しやすい形に整理したものとして捉えるのが安全です。
影響を受ける管理者・開発者
Azure Monitor Agentのネットワーク構成は、監視担当者だけの問題ではありません。ネットワーク、セキュリティ、Azure基盤、アプリケーション運用の複数チームに影響します。
ネットワーク管理者は、NSG、Azure Firewall、ユーザー定義ルート、プロキシ、Private Linkの設計を確認する必要があります。公式情報では、VMの仮想ネットワークでAzureMonitorとAzureResourceManagerのサービス タグが必要であり、サービス タグはNSG、Azure Firewall、ユーザー定義ルートでアクセス制御に使えるとされています。(Microsoft Learn)
セキュリティ管理者は、HTTPS検査を無効にする必要がある点を見落とさないでください。Azure Monitor Agent向けのエンドポイントはポート443のアウトバウンド通信ですが、公式情報ではすべてのエンドポイントでHTTPS検査を無効にするよう明記されています。(Microsoft Learn)
Azure基盤管理者は、VM、VMSS、Azure Arc対応サーバーごとに設定方法が異なる点を確認します。VMSSで手動アップグレードポリシーを使っている場合、VMSSモデル変更後に既存インスタンスの更新が必要です。自動またはローリング アップグレードポリシーの場合は、拡張機能がインスタンスへ自動適用されます。(Microsoft Learn)
開発者やSREは、カスタム ログ、IISログ、Syslog、Windowsイベント、パフォーマンス カウンターなど、収集対象が新しいDCR/DCE構成で正しく取り込まれるかを検証する必要があります。Log Analyticsエージェントから移行中の場合は、重複取り込みによるコスト増や、逆に一部ログだけ欠落するリスクがあります。
ネットワーク要件で必ず確認する項目
Azure Monitor Agentの通信は、原則としてアウトバウンドのHTTPS通信です。ただし、許可すべき宛先は利用する機能や構成によって変わります。
サービス タグはAzureMonitorとAzureResourceManagerを確認する
VMの仮想ネットワークでは、AzureMonitorとAzureResourceManagerの両方のサービス タグが必要です。IPアドレスを個別に許可するより、サービス タグを使ったほうがAzure側の変更に追従しやすく、NSGやAzure Firewallのルールも管理しやすくなります。(Microsoft Learn)
ただし、DCEのパブリックIPアドレスを含めるためにネットワーク サービス タグを使うことはできません。カスタム ログやIISログのDCRを使う場合は、DCEのパブリックIPアドレスを許可することを検討する必要があります。ここを見落とすと、基本的なメトリックや一部ログは届くのに、カスタム ログだけ届かないという切り分けしづらい状態になります。(Microsoft Learn)
ファイアウォールで許可する主なエンドポイント
ファイアウォールでは、利用する機能に応じて次のエンドポイントへのポート443アウトバウンド通信を許可します。
| エンドポイント | 用途 | 確認ポイント |
|---|---|---|
global.handler.control.monitor.azure.com | コントロール サービスへのアクセス | DCR取得や制御系通信で重要 |
global.prod.microsoftmetrics.com | メトリック サービスへのアクセス | メトリック収集を使う環境で確認 |
<virtual-machine-region-name>.handler.control.monitor.azure.com | 特定マシンのDCR取得 | VMのリージョン名を正しく反映する |
<log-analytics-workspace-id>.ods.opinsights.azure.com | ログ データの取り込み | ワークスペースID単位で許可が必要 |
management.azure.com | Azure Monitorカスタム メトリックへの送信時に必要 | カスタム メトリック利用時のみ確認 |
<virtual-machine-region-name>.monitoring.azure.com | Azure Monitorカスタム メトリックへの送信時に必要 | リージョンごとの許可を確認 |
<data-collection-endpoint>.<virtual-machine-region-name>.ingest.monitor.azure.com | DCE経由のログ取り込み | DCEを使うDCRでは必須 |
Azure Commercialでは.com、Azure Governmentでは.us、21Vianetが運営するMicrosoft Azureでは.cnのサフィックスを使います。国内企業で通常のAzureを使っている場合は多くがAzure Commercialですが、グローバル展開や公共系案件ではクラウド種別を確認してからルールを作成してください。(Microsoft Learn)
プロキシ構成で失敗しやすいポイント
Azure Monitor Agent拡張機能は、WindowsとLinuxの両方でプロキシ サーバーまたはLog Analyticsゲートウェイ経由の通信に対応しています。構成は拡張機能の設定として定義し、匿名認証と、ユーザー名・パスワードによる基本認証がサポートされています。(Microsoft Learn)
代表的な設定は次の考え方で整理できます。
| 設定内容 | 使う値 | 注意点 |
|---|---|---|
| プロキシなし | {"proxy":{"mode":"none"}} | 直接インターネットへ出られる環境向け |
| 認証なしプロキシ | mode:"application"、auth:"false" | プロキシのアドレスとポートを正確に指定する |
| 認証ありプロキシ | auth:"true" | ユーザー名とパスワードは保護された設定として扱う |
| 既定値へ戻す | {} | 誤ったプロキシ設定の解除時に使う |
資格情報を通常の設定値として残すと、テンプレート、実行ログ、構成管理ツール経由で漏えいするリスクがあります。認証ありプロキシを使う場合は、ProtectedSettingStringや--protected-settingsなど、保護された設定の利用を前提にしてください。
Linuxでは、http_proxyやhttps_proxyなどの環境変数によるシステム プロキシ設定は、Azure Monitor Agent for Linux 1.24.2以降でのみサポートされます。古いエージェントを使っている環境では、環境変数を設定しても期待通りに通信しない可能性があるため、エージェントのバージョン確認を先に行いましょう。(Microsoft Learn)
また、Azure Monitor Metricsのプレビュー宛先ではプロキシ構成がサポートされず、その宛先へメトリックを送る場合はプロキシなしでパブリック インターネットが使われます。閉域化やプロキシ強制を前提にした設計では、ログとメトリックを同じ扱いにしないことが重要です。(Microsoft Learn)
Log Analyticsゲートウェイを使う場合の確認ポイント
Log Analyticsゲートウェイを使う場合は、Azure Monitor Agent側のプロキシ設定でゲートウェイ サーバーのIPアドレスとポート番号を指定します。複数のゲートウェイ サーバーをロード バランサー配下に置いている場合は、エージェント側にロード バランサーの仮想IPアドレスを設定します。(Microsoft Learn)
ゲートウェイ側では、DCRを取得するための構成エンドポイントと、データ取り込み用エンドポイントを許可リストに追加します。
Add-OMSGatewayAllowedHost -Host global.handler.control.monitor.azure.com
Add-OMSGatewayAllowedHost -Host <gateway-server-region-name>.handler.control.monitor.azure.com
Add-OMSGatewayAllowedHost -Host <log-analytics-workspace-id>.ods.opinsights.azure.comPrivate Linkをエージェントで使う場合は、DCEも追加する必要があります。許可リストを更新した後は、Log Analyticsゲートウェイ、つまりOMS Gatewayサービスを再起動して変更を反映します。(Microsoft Learn)
Stop-Service -Name <gateway-name>
Start-Service -Name <gateway-name>注意点として、Azure Arc対応サーバーでは、プロキシ接続、Private Link接続、パブリック エンドポイント接続オプションに対するOMS Gatewayがサポートされません。オンプレミスや他クラウドのサーバーをAzure Arcで管理している場合は、「Arcだからゲートウェイで集約できる」と決めつけず、公式のサポート範囲に沿ってプロキシやPrivate Link設計を見直してください。(Microsoft Learn)
Private Link構成ではDCEとDCRの関係が重要
Azure Monitor AgentでPrivate Linkを使う場合、エージェントは通常の非プライベート エンドポイントではなく、プライベートDCEを使います。公式情報では、Private LinkまたはプライベートDCEを使う場合、エージェントは一覧にある非プライベート エンドポイントを使用しないと説明されています。(Microsoft Learn)
Azure Monitor Private Link ScopeとAzure Monitor Agentを組み合わせる場合は、すべてのDCRでDCEを使う必要があります。さらに、DCEをAzure Monitor Private Link Scope構成へPrivate Link経由で追加します。(Microsoft Learn)
ここでよくある失敗は、Private Link自体は作成したものの、既存のDCRがDCEを使う構成になっていないケースです。この場合、ネットワーク側では閉域化できているように見えても、実際のデータ収集経路が成立せず、ログが取り込まれない可能性があります。
Private Link化する前に、次の順番で棚卸ししてください。
| 確認順 | 確認内容 |
|---|---|
| 1 | 対象VM、VMSS、Arc対応サーバーを一覧化する |
| 2 | 各リソースに関連付くDCRを確認する |
| 3 | それぞれのDCRがDCEを使っているか確認する |
| 4 | DCEがPrivate Link Scopeに追加されているか確認する |
| 5 | NSG、Azure Firewall、DNS、Private Endpointの名前解決を確認する |
| 6 | パイロットVMでHeartbeatと対象ログの取り込みを確認する |
VMSS展開では「モデル更新」と「インスタンス反映」を分けて考える
VMSSでは、拡張機能の設定をVMSSモデルに追加しても、既存インスタンスへすぐ反映されるとは限りません。スケール セットのアップグレードポリシーがManualの場合、VMSSモデル変更後にUpdate-AzVmssInstanceやaz vmss update-instancesを実行して既存インスタンスを更新する必要があります。AutomaticまたはRollingの場合は、拡張機能がインスタンスへ自動的に適用されます。(Microsoft Learn)
実務では、次のような確認手順を入れると安全です。
| 手順 | 作業内容 | 失敗しやすいポイント |
|---|---|---|
| 1 | VMSSのアップグレードポリシーを確認する | Manualなのにモデル更新だけで完了したと思い込む |
| 2 | Windows/Linuxの拡張機能名を確認する | AzureMonitorWindowsAgentとAzureMonitorLinuxAgentを取り違える |
| 3 | プロキシ設定をVMSSモデルへ追加する | 認証ありプロキシの資格情報を通常設定に入れてしまう |
| 4 | 既存インスタンスへ反映する | Manualの場合に更新コマンドを実行し忘れる |
| 5 | 取り込み状況を確認する | 一部インスタンスだけ旧設定のまま残る |
VMSSは台数が多く、更新漏れに気づきにくい構成です。展開後は、インスタンス単位で拡張機能のプロビジョニング状態と、Log Analytics側のHeartbeatを照合してください。
Log Analyticsエージェントから移行する場合の注意点
Log Analyticsエージェント、つまりMMA/OMSからAzure Monitor Agentへ移行している環境では、ネットワーク構成とDCR設計を同時に見直す必要があります。Microsoft Learnでは、Log Analyticsエージェントは2024年8月31日に廃止され、2026年3月2日以降はLog Analyticsエージェントからのデータ アップロードが予告なく停止する可能性があると説明されています。(Microsoft Learn)
移行では、次の順序で進めるのが現実的です。
| フェーズ | 実施内容 |
|---|---|
| 現状把握 | 既存のLog Analyticsエージェント、ワークスペース、依存サービスを棚卸しする |
| 設計 | DCR、DCE、通信経路、Private Link、プロキシ要件を決める |
| パイロット | 少数のVMでAzure Monitor Agentを展開し、収集内容を比較する |
| 重複防止 | テスト中は旧エージェントのワークスペース構成を外し、二重取り込みを避ける |
| 本番展開 | Azure Policyなどを使い、大規模にエージェントとDCR関連付けを展開する |
| 撤去 | Azure Monitor Agentの収集が安定した後、旧エージェントを削除する |
移行ツールとしては、Azure Monitor Agent Migration Helper workbookとDCR Config Generatorが案内されています。前者はエージェントのインベントリ、ワークスペース監査、依存サービスの識別、移行進捗の追跡に役立ち、後者は既存のLog Analyticsエージェントのワークスペースベース構成をDCRへ変換するために使います。(Microsoft Learn)
検証では、Log Analyticsワークスペースに対してKQLを実行し、Log AnalyticsエージェントとAzure Monitor Agentの取り込みデータを比較します。公式情報では、Heartbeatテーブルを使ってAzure Monitor Agentのハートビート到着を確認し、パフォーマンス カウンター、Windowsイベント、Syslog、カスタム ログなどのデータ型にギャップがないか確認する流れが示されています。(Microsoft Learn)
よくある設定ミスと回避策
Azure Monitor Agentのネットワーク構成では、設定自体よりも「一部だけ正しく、一部だけ抜けている」状態が問題になりがちです。次の表を変更前レビューに使ってください。
| よくあるミス | 起きること | 回避策 |
|---|---|---|
AzureMonitorだけ許可し、AzureResourceManagerを忘れる | DCR取得や管理系通信で問題が出る可能性がある | 両方のサービス タグを確認する |
| DCEのパブリックIPを許可していない | カスタム ログやIISログだけ欠落する可能性がある | DCEを使うDCRを洗い出し、必要なIPを許可する |
| HTTPS検査を有効にしたままにする | TLS通信が中断され、エージェント通信が失敗する可能性がある | Azure Monitor Agent向け宛先ではHTTPS検査を無効化する |
| Private Linkを作っただけでDCRを見直していない | DCEを使わないDCRが残り、収集経路が成立しない | すべてのDCRでDCEを使うか確認する |
| VMSSのManual更新を忘れる | 一部インスタンスだけ旧設定のまま残る | Update-AzVmssInstanceまたはaz vmss update-instancesを実行する |
| 認証情報を通常設定に入れる | プロキシ資格情報が漏えいするリスクがある | protected settingsを使う |
| 旧エージェントとAMAを同時に収集させる | 二重取り込みでコストが増える | パイロット中は旧エージェントの収集を無効化して比較する |
管理者が次に取るべき行動
まず、対象リソースを「Azure VM」「VMSS」「Azure Arc対応サーバー」に分けて棚卸ししてください。そのうえで、各リソースが使う通信方式を直接接続、プロキシ、Log Analyticsゲートウェイ、Private Linkのいずれかに分類します。
次に、DCRとDCEの対応関係を確認します。特にPrivate Linkを使う環境では、DCRがDCEを使っているか、DCEがPrivate Link Scopeに追加されているかを優先して確認してください。
最後に、パイロット対象を決め、Azure Monitor Agentを少数のVMへ展開します。Heartbeat、Windowsイベント、Syslog、パフォーマンス カウンター、カスタム ログなど、実際に必要なデータが届いているかを確認してから、Azure PolicyやVMSS拡張機能設定で横展開します。
Azure Monitor Agent Network Configurationは、単なるネットワーク許可リストではありません。監視データの取り込み経路、セキュリティ境界、移行計画、運用コストに直結する設計項目です。今回の公式情報をもとに、まずは自社環境の通信経路、DCR、DCE、プロキシ、VMSS反映状況を一覧化し、パイロット検証から安全に展開を進めましょう。
コメント