2026年5月更新のMicrosoft公式情報を読むうえで、Windows VMや仮想マシン スケール セットのAzure Monitor agent（AMA）で最初に確認すべき答えは明確です。エージェントを入れ直す前に、拡張機能のプロビジョニング、Heartbeat、DCRの関連付け、マネージドID、IMDS、AMCSからの構成取得を順番に切り分けることです。今回の内容は新機能の紹介というより、Windows環境で「Azure Monitor agentが入っているのにログやメトリックが来ない」状況を、管理者が迷わず調査できるように整理したトラブルシューティング指針と捉えると実務で役立ちます。Microsoft Learnの該当ページは、Windows VM/スケールセット上のAMAとData Collection Rules（DCR）に関する問題の確認手順を示しています。(Microsoft Learn)
WindowsのAzure Monitor agentトラブルシューティングで何が変わるのか
Azure Monitor agentは、Windows VMのゲストOS内にあるイベントログ、パフォーマンスカウンター、IISログなどをAzure Monitorへ送るためのエージェントです。Microsoftの公式説明では、AMAはゲストOSデータ収集でサポートされるエージェントであり、収集内容はDCRによって定義されます。DCRは「何を収集するか」「どう処理するか」「どこへ送るか」を管理する設定です。(Microsoft Learn)
実務上の変更点は、トラブル対応の発想が次のように変わることです。
| これまで起きがちな対応 | 今回の公式情報を踏まえた確認 |
|---|---|
| エージェントが入っているかだけを見る | 拡張機能の状態、プロセス、Heartbeat、DCR取得まで見る |
| Log Analytics workspace側だけを疑う | DCR、DCR関連付け、マネージドID、IMDS、AMCSも確認する |
| すぐ再インストールする | 10〜15分のプロビジョニング待ち、ログ確認、設定不備の切り分けを先に行う |
| すべてのデータ欠損を同じ原因として扱う | パフォーマンスカウンター、Windowsイベントログ、Custom Metricsで確認点を分ける |
| 旧Log Analytics agentと併用したまま様子を見る | 二重収集や移行漏れを前提に、段階的にAMAへ切り替える |
重要なのは、AMAの問題を「Windowsサービスが動いているか」だけで判断しないことです。公式手順では、Azure Portal上の拡張機能、MonAgentCore.exe、Heartbeatクエリ、ローカル構成ファイル、DCR関連付けを組み合わせて判断します。(Microsoft Learn)
影響範囲：確認すべきWindows環境
今回のトラブルシューティング指針の主な対象は、Azure上のWindows仮想マシンと仮想マシン スケール セットです。特に次の環境では、早めに確認しておく価値があります。
| 対象環境 | 確認すべき理由 |
|---|---|
| Windows VMでAMAを使っている環境 | Heartbeatやイベントログが止まると、監視・アラート・分析に影響する |
| VMSSでAMAを展開している環境 | インスタンス増減時に、拡張機能・DCR関連付け・マネージドIDの漏れが起きやすい |
| Log Analytics workspaceへログを送っている環境 | DCRのリージョン、関連付け、送信先設定の不備でデータが欠損する可能性がある |
| Custom Metricsを送っている環境 | Heartbeat確認だけでは判断できない場合があり、別の確認手順が必要 |
| 旧Log Analytics agent、WAD/LADから移行中の環境 | 二重収集、移行漏れ、旧エージェント停止によるデータ欠損に注意が必要 |
| Microsoft Sentinel、VM insights、Change Trackingなどと連携している環境 | 収集データの欠損がセキュリティ監視や運用レポートに波及する |
オンプレミスや他クラウド上のWindows ServerをAzure Arcで管理している場合もAMAを利用できますが、Arc-enabled server向けのパスや前提条件はAzure VMとは異なる場合があります。Azure VM向け手順をそのまま当てはめず、対象リソース種別に合った公式手順で確認してください。
まず確認するべき基本チェック
AMAでデータが来ないときは、いきなりDCRを書き換えるのではなく、下の順番で確認します。この順序にすると「インストールされていない」「動いていない」「設定が届いていない」「データソース定義が間違っている」を切り分けやすくなります。
| 順番 | 確認項目 | 判断基準 | 次の対応 |
|---|---|---|---|
| 1 | 拡張機能のプロビジョニング | Azure Portalの「Extensions + applications」でAzureMonitorWindowsAgentがProvisioning succeededになっている | 失敗していれば拡張機能ログを確認 |
| 2 | エージェントプロセス | タスクマネージャーでMonAgentCore.exeが動作している | 動いていなければコアエージェントログを確認 |
| 3 | Heartbeat | Log AnalyticsでAMAのHeartbeatが確認できる | Custom MetricsのみのDCRではHeartbeat確認をスキップ |
| 4 | DCRの存在と関連付け | 対象VMがDCRのResourcesに含まれている | 関連付けがなければDCRへ追加 |
| 5 | DCRのダウンロード | VM内にmcsconfig.latest.xmlやconfigchunksが存在する | なければマネージドID、IMDS、AMCS到達性を確認 |
| 6 | データ種類別設定 | performanceCounters、windowsEventLogs、Custom Metrics送信先などがDCRにある | 不足していればDCRを修正 |
Heartbeat確認では、次のKQLが実務での最初の確認に向いています。
Heartbeat
| where Category == "Azure Monitor Agent"
| where Computer == "<computer-name>"
| take 10公式手順では、拡張機能が表示されない場合にAzure CLIで対象リージョンの拡張機能バージョンを確認する方法も示されています。プロビジョニング中の状態が続くこともあるため、10〜15分待ってから再確認し、それでも改善しない場合にアンインストールと再インストールを検討します。(Microsoft Learn)
az vm extension image list-versions \
--location <machine-region> \
--name AzureMonitorWindowsAgent \
--publisher Microsoft.Azure.MonitorDCR関連の不具合は「作成済み」ではなく「関連付け済み」まで見る
Azure Monitor agentのトラブルで多いのは、DCRを作っただけで安心してしまうケースです。AMAはDCRを取得して、その内容に従ってデータを収集します。DCRが存在していても、対象VMやVMSSに関連付けられていなければ収集は始まりません。
DCRはAzure上に保存され、複数リソースへ関連付けられます。また、1つのリソースに複数DCRを関連付けることもできます。そのため、環境ごとに柔軟な管理ができる一方、重複収集や意図しないDCRの適用も起こり得ます。(Microsoft Learn)
DCR関連で確認するポイントは次の通りです。
| 確認項目 | 見る場所・内容 | 注意点 |
|---|---|---|
| DCRとVMの関連付け | Azure PortalのDCR > Resources | VMSSでは新規インスタンスにも適用される設計にする |
| Log Analytics workspaceとのリージョン | DCRとworkspaceの物理リージョン | 公式手順では、Log Analytics workspaceを送信先にする場合は同じ物理リージョンか確認する |
| ローカル構成ファイル | C:\WindowsAzure\Resources\AMADataStore.<virtual-machine-name>\mcs\mcsconfig.latest.xml | ファイルがない場合はDCR未関連付け、マネージドID、IMDS、AMCS到達性を疑う |
| DCR取得済み構成 | ...\mcs\configchunks | ここに最新DCRが落ちているか確認する |
| IMDS関連エラー | ...\Tables\MAEventTable.tsf | VMメタデータ取得に失敗している可能性がある |
特にVMSSでは、既存インスタンスでは動いていても、新しく作られたインスタンスにDCR関連付けやマネージドIDが適用されていないことがあります。スケールアウト後のインスタンスをサンプルで確認し、Azure PolicyやIaCで一貫して適用される状態にしておくことが重要です。
マネージドIDとIMDSは見落としやすい
Azure Monitor agentでは、マネージドIDが重要な前提になります。Microsoftの要件では、Azure VMでマネージドIDを有効にする必要があり、ユーザー割り当てマネージドIDとシステム割り当てマネージドIDの両方がサポートされています。大規模展開ではユーザー割り当てマネージドIDが推奨され、システム割り当ては初期テストや小規模展開に適していると説明されています。(Microsoft Learn)
実務では、次のように判断するとよいでしょう。
| 展開規模 | 推奨される考え方 |
|---|---|
| 数台の検証環境 | システム割り当てマネージドIDでも管理しやすい |
| サブスクリプション全体、VMSS、大量VM | ユーザー割り当てマネージドIDを使い、ポリシーやテンプレートで統一する |
| Azure Arc-enabled server | システム割り当てマネージドIDが基本となるため、Azure VMと混同しない |
IMDS（Instance Metadata Service）に到達できない場合、AMAはVMの情報を取得できず、DCR取得や構成反映に影響する可能性があります。DCRが正しいのにmcsconfig.latest.xmlが作られない場合は、マネージドIDの有効化だけでなく、IMDSへの到達性も確認してください。
ネットワーク制御をしている環境ではエンドポイント到達性を確認する
閉域化、Azure Firewall、NSG、プロキシ、Private Linkを使っている環境では、AMAの通信先が許可されていないだけでデータが止まることがあります。公式のネットワーク構成では、Azure Monitor agentはダイレクトプロキシ、Log Analytics gateway、Private Linkをサポートし、仮想ネットワークではAzureMonitorとAzureResourceManagerのサービス タグが必要とされています。(Microsoft Learn)
ただし、すべてをサービス タグだけで解決できるとは限りません。公式情報では、DCE（Data Collection Endpoint）のパブリックIPはAzure Monitorのネットワークサービス タグに含まれないため、Custom LogsやIISログのDCRを使う場合はDCEのパブリックIP許可を検討する必要があるとされています。(Microsoft Learn)
ネットワーク面では、次の確認を行います。
| 環境 | 確認ポイント |
|---|---|
| NSG・Azure Firewall利用 | AzureMonitor、AzureResourceManagerサービス タグの許可 |
| DCE利用 | DCEの名前解決、到達性、必要に応じたIP許可 |
| プロキシ利用 | AMA拡張機能のプロキシ設定、認証方式 |
| Private Link利用 | すべてのDCRでDCEを使い、Azure Monitor Private Link Scopeに追加されているか |
| Custom Metrics利用 | プロキシ非対応の制約が影響しないか確認 |
「Azure Portalではエージェントが成功しているが、ログが入らない」という場合は、ネットワークでAMCSや取り込み先に届いていない可能性があります。特にセキュリティ要件の強いWindows Server環境では、拡張機能の状態だけで正常と判断しないようにしましょう。
パフォーマンスカウンターが収集されない場合
CPU、メモリ、ディスクなどのパフォーマンスカウンターがLog Analyticsに入らない場合は、DCRのperformanceCountersセクションを確認します。DCRに定義がなければ、エージェントが正常に動いていても収集は行われません。
確認手順は次の通りです。
| 確認項目 | 具体的な見る場所 |
|---|---|
DCRにperformanceCountersがあるか | Azure Portal、ARM/Bicep、JSON定義 |
| ローカル構成が反映されているか | C:\WindowsAzure\Resources\AMADataStore.<virtual-machine-name>\mcs\mcsconfig.lkg.xml |
| CounterSetがあるか | mcsconfig.lkg.xml内のCounterSetノード |
| カウンター名が正しいか | \Processor(_Total)\% Processor Timeなど、Windowsの実在するカウンター名 |
パフォーマンスカウンターは、DCRのサンプリング間隔や対象カウンターの指定ミスで、意図した粒度にならないことがあります。移行時は旧エージェント時代の収集間隔やカウンター名をそのまま信じず、実際に入っているレコード数と時系列を確認してください。
Windowsイベントログが収集されない場合
Windowsイベントログが入らない場合は、DCRにwindowsEventLogsセクションがあるかを確認します。さらに、ローカルに反映された構成ファイルでSubscriptionノードが作られているかを見ると、DCRが実際にエージェントへ届いているかを判断しやすくなります。
公式情報で特に重要なのは、Azure Monitor AgentによるWindowsイベントログ収集は、Windows Event Logファイルがローカルディスク上に保存されている場合のみサポートされるという点です。ネットワーク共有やUNCパスに置いたイベントログはサポートされません。(Microsoft Learn)
よくある失敗例は次の通りです。
| 失敗例 | 影響 | 対応 |
|---|---|---|
windowsEventLogsをDCRに入れていない | イベントログがまったく収集されない | DCRを修正する |
| クエリ条件が狭すぎる | 重要イベントが対象外になる | Level、チャネル、プロバイダー条件を見直す |
| イベントログをUNCパスに置いている | AMAで収集できない | ローカルディスク上のイベントログを対象にする |
| Securityログの扱いを未確認 | 監査・セキュリティ監視に抜けが出る | SentinelやDefender連携も含めて検証する |
Windowsイベントログは、監視だけでなくセキュリティ調査にも使われます。移行後は「ログが来ている」だけでなく、必要なチャネルとイベントレベルが来ているかをKQLで確認してください。
Custom Metricsを使う場合はHeartbeatだけで判断しない
Custom MetricsをDCRの送信先にしている場合、公式手順ではHeartbeat確認をスキップする条件が示されています。つまり、Custom Metricsだけを送る構成では「Heartbeatが見えないからAMAが壊れている」とは判断できません。(Microsoft Learn)
Custom Metricsで見るべきポイントは次の通りです。
| 確認項目 | 具体的な内容 |
|---|---|
| DCRの送信先 | destinationsにazureMonitorMetricsがあるか |
| Metrics拡張プロセス | MetricsExtension.Native.exeのコマンドラインに-TokenSource MSIがあるか |
| MSIトークンファイル | AuthToken-MSI.jsonが存在するか |
| MonitoringAccount構成 | CUSTOMMETRIC_<subscription>_<region>_MonitoringAccount_Configuration.jsonが存在するか |
| エラーログ | MaMetricsExtensionEtw.csvでLevel 2エラーを確認 |
PowerShellでは、次のようにプロセスのコマンドラインを確認します。
Get-WmiObject Win32_Process -Filter "name = 'MetricsExtension.Native.exe'" |
select Name, ExecutablePath, CommandLine |
Format-ListCustom Metricsの問題は、DCRの送信先設定、マネージドID、ネットワーク制御、メトリック名や名前空間の扱いが絡みます。Log Analyticsのログ収集と同じ手順だけでは原因を見落としやすいため、専用の確認項目を用意しておくことが重要です。
移行上の注意：旧Log Analytics agentとWAD/LADは放置しない
Azure Monitor agentのトラブルシューティングを考えるとき、旧Log Analytics agent（MMA/OMS）やAzure Diagnostics拡張機能（WAD/LAD）からの移行状況も確認が必要です。
Microsoftは、Log Analytics agentがAzure Monitor Agentに置き換わること、そしてLog Analytics agentは2024年8月31日に廃止済みであることを示しています。さらに、2026年3月2日以降はLog Analytics agentからのデータアップロードが予告なく停止する可能性があると説明されています。(Microsoft Learn)
WAD/LADについても、公式情報では2026年3月31日に廃止されるとされ、AMAとDCRへの移行が案内されています。AMAではDCRによる集中管理、変換、マネージドIDベースのアクセス、標準化されたエンドポイントが特徴として整理されています。(Microsoft Learn)
移行時の実務手順は、次の流れが安全です。
| 手順 | 実施内容 | 失敗しやすいポイント |
|---|---|---|
| 棚卸し | MMA、WAD/LAD、AMAの導入状況を確認 | VMSSや停止中VMを見落とす |
| パイロット | 少数のWindows VMでAMAとDCRを検証 | 本番相当のイベント量・負荷で検証しない |
| データ比較 | Heartbeat、イベントログ、パフォーマンスデータを比較 | 「一部だけ来ている」を正常と判断する |
| 二重収集対策 | 旧エージェントの収集設定を止める | コスト増や重複アラートが発生する |
| 本番展開 | Azure PolicyやIaCで拡張機能とDCRを展開 | 新規VMやVMSSインスタンスへの自動適用漏れ |
| 旧エージェント削除 | データ同等性確認後に削除 | SCOM連携など例外を考慮しない |
移行期間中は「旧エージェントも動いているから安心」ではありません。二重取り込みによるコスト増、同じイベントに対する重複アラート、KQLの結果差分が起きるため、どのエージェントがどのデータを送っているかを明確にしてください。
展開時はAzure Policyとバージョン管理をセットで考える
Windows VMやVMSSへAMAを広く展開する場合、手作業で拡張機能を追加する運用は避けるべきです。公式情報では、Azure Policyを使って既存および新規の仮想マシンにAzure Monitor agentを自動インストールし、関連するDCRを自動的に関連付けられると説明されています。VMとVMSSでは、ポリシーによる展開でユーザー割り当てマネージドIDを利用する方針も示されています。(Microsoft Learn)
また、AMAのバージョン管理も重要です。Microsoftは、過去1年以内にリリースされたAzure Monitoring Agentバージョンをサポート対象とし、バグ修正は最新バージョンに提供すると説明しています。古いバージョンへ固定したままにすると、既知不具合の修正を受けられない可能性があります。(Microsoft Learn)
展開設計では、次の方針をおすすめします。
| 項目 | 推奨方針 |
|---|---|
| VMSS | Azure Policyやテンプレートで新規インスタンスにもAMAとDCRを適用 |
| マネージドID | 大規模展開ではユーザー割り当てマネージドIDを標準化 |
| DCR | OS別、用途別、環境別に分け、重複収集を避ける |
| バージョン | 自動アップグレードを有効化し、古い固定バージョンを避ける |
| 検証 | パイロット環境でHeartbeat、イベントログ、パフォーマンス、Custom Metricsを確認 |
| コスト | DCR変換や収集対象の絞り込みで不要データを減らす |
管理者と開発者が今すぐ確認すべきチェックリスト
最後に、Windows環境のAzure Monitor agentで確認すべき項目を、運用チーム向けにまとめます。
| チェック | 確認内容 |
|---|---|
| 拡張機能 | AzureMonitorWindowsAgentがProvisioning succeededか |
| プロセス | MonAgentCore.exeが動作しているか |
| Heartbeat | AMAカテゴリのHeartbeatがLog Analyticsに届いているか |
| DCR | 対象VM・VMSSがDCRに関連付けられているか |
| リージョン | Log Analytics workspace送信時にDCRとworkspaceのリージョン整合性が取れているか |
| マネージドID | VMにマネージドIDがあり、AMAの認証設定と一致しているか |
| IMDS | VMからIMDSへ到達できるか |
| ネットワーク | AzureMonitor、AzureResourceManager、DCE、Private Link、プロキシ設定を確認したか |
| Windowsイベントログ | ローカルディスク上のイベントログを対象にしているか |
| Custom Metrics | Heartbeatではなく、Metrics拡張とMSIトークン、設定ファイルで確認しているか |
| 旧エージェント | MMA、WAD/LADとの二重収集や移行漏れがないか |
| バージョン | サポート対象期間内のAMAを使い、最新修正を受けられる状態か |
Azure Monitor agentのWindowsトラブルシューティングでは、単に「エージェントを再インストールする」対応では原因を取り切れません。まず拡張機能、プロセス、Heartbeat、DCR、マネージドID、IMDS、ネットワークの順で切り分け、データ種類ごとの確認に進むことが重要です。移行中の環境では、旧Log Analytics agentやWAD/LADの残存もあわせて確認してください。次に取るべき行動は、代表的なWindows VMまたはVMSSインスタンスを1台選び、この記事のチェックリストに沿って現在のAMA構成を点検することです。
コメント