Azure Monitor Agent extension versionsを確認すべき理由は、単に「最新版が出たか」を知るためではありません。管理者にとって重要なのは、どのOSに影響する更新なのか、Azure VM・VMSS・Azure Arc対応サーバーでいつ反映されるのか、DCRやSyslog変換、メトリック収集に手を入れる必要があるのかを判断することです。
2026年6月時点で特に確認したいのは、Windows向けのAzure Monitor Agent 1.43、Linux向け1.41、Metrics Extensionの更新、そしてLinuxのCEF/Syslogまわりの破壊的変更です。Azure Monitor Agentは段階的にロールアウトされるため、全リソースが同じタイミングで同じバージョンになるとは限りません。運用では「自動更新を有効にして終わり」ではなく、バージョン、DCR、KQL変換、データ欠損、重複収集をセットで確認する必要があります。(Microsoft Learn)
Azure Monitor Agent extension versionsとは
Azure Monitor Agent extension versionsは、Azure Monitor Agent、通称AMAの仮想マシン拡張機能に関するリリースノートです。Azure Monitor Agentは、Azure仮想マシン、仮想マシンスケールセット、Azure Arc対応サーバーにデプロイされ、ゲストOS上のログやパフォーマンスデータをAzure Monitorへ送る役割を持ちます。(Microsoft Learn)
管理者がこのページを見るべきタイミングは、主に次の4つです。
- Azure VMやAzure Arc対応サーバーの監視データが急に欠けたとき
- Log Analytics Agent、MMA、OMSからAzure Monitor Agentへ移行しているとき
- Microsoft Sentinel、VM insights、カスタムログ、Syslog、CEFログを使っているとき
- Azure PolicyやIaCでAMAを大規模展開しているとき
Microsoftは、過去1年以内にリリースされたAzure Monitor Agentのバージョンをサポート対象とし、バグ修正は最新バージョンで提供すると説明しています。つまり、古いバージョンを固定して運用している環境では、セキュリティ修正や信頼性改善を取り込めないリスクがあります。(Microsoft Learn)
2026年6月時点で押さえるべき主な変更点
Azure Monitor Agentの更新は、Windows、Linux、Metricsで同じタイミング・同じ番号になるとは限りません。2026年6月時点の公式リリースノートでは、2026年5月のWindows 1.43、2026年4月のWindows 1.42 / Linux 1.41、2026年2月のWindows 1.41.0 / Linux 1.40.0が実務上の確認ポイントになります。(Microsoft Learn)
| 時期 | 対象 | 主なバージョン | 管理者が見るべきポイント |
|---|---|---|---|
| 2026年5月 | Windows | 1.43 | AMAインストーラーのクラッシュ修正、Metrics Extension更新、AMACA更新、OpenSSL 3.6.2.1更新 |
| 2026年4月 | Windows | 1.42 | XPathによるWindowsイベントXML解析、ローカルフィルター処理の性能改善、アンインストール処理改善 |
| 2026年4月 | Linux | 1.41 | CEF/Syslog解析の破壊的変更、rsyslog構造化データ対応、CJK・絵文字など二重幅Unicode文字の修正 |
| 2026年2月 | Windows / Linux | 1.41.0 / 1.40.0 | Azure Batchサポート、メモリ関連修正、Debian 13対応、fluent-bit更新 |
| 2026年1〜2月 | Metrics | 2.2025.905.1550以降 | OpenTelemetryプロセスカウンターのメタデータ追加、1024文字超のディメンション切り捨て |
Windows環境ではインストール・イベント処理・OpenSSL更新を確認する
Windows向けの最新ポイントは、2026年5月のAzure Monitor Agent 1.43です。この更新では、AMAインストーラーのクラッシュ修正、Metrics Extension 2.2026.424.2329への更新、AMACA 3.0.77への更新、OpenSSL 3.6.2.1への更新が含まれています。(Microsoft Learn)
実務上の影響は、主に次の3つです。
1つ目は、新規インストールや更新時の失敗リスク低減です。過去にAMA拡張機能の展開で失敗していた環境では、手動更新や再デプロイ前に1.43以降を候補に入れる価値があります。
2つ目は、セキュリティ依存関係の更新です。OpenSSL更新は、アプリケーション機能の追加というより、監視エージェント自体の安全性と保守性に関わる更新です。セキュリティ基準が厳しい環境では、AMAのバージョンだけでなく、依存コンポーネントの更新も変更管理の記録に残しておくとよいでしょう。
3つ目は、Windowsイベントログ処理の改善です。2026年4月のWindows 1.42では、WindowsイベントXMLデータをXPathクエリで解析するparse.XmlPath多段階変換のサポートや、ローカルフィルターイベント処理の性能改善が入っています。イベントログの収集量が多いサーバー、Microsoft Sentinel向けにWindowsイベントを絞り込んでいる環境では、更新後にDCRの変換、取り込み量、クエリ結果を確認してください。(Microsoft Learn)
Linux環境ではCEF/Syslogの破壊的変更に注意する
2026年4月のLinux 1.41で最も注意すべき点は、CEFデータの標準準拠と解析一貫性を高めるための変更です。公式リリースノートでは、汎用SyslogパーサーがメッセージフィールドからCEFトークンを抽出しなくなり、フィルターを入れない場合はSyslogテーブルに不正なCEFイベントが表示される可能性があると説明されています。(Microsoft Learn)
Microsoft SentinelやCEFコネクタを使っている場合、次のような環境は特に確認が必要です。
| 確認対象 | 確認内容 |
|---|---|
| Syslog用DCR | CEFログと通常Syslogを同じ流れで収集していないか |
| KQL変換 | CEFをSyslogテーブル側に混入させないフィルターがあるか |
| Sentinel分析ルール | CommonSecurityLogやSyslogを前提にした検出ルールの件数が変わっていないか |
| ダッシュボード | CEFログの件数、重大度、デバイス名、ホスト名の集計が更新前後で極端に変わっていないか |
| SIEM連携 | Fortinet、Palo Alto、Cisco FTD/FMCなどのCEF転送経路に影響がないか |
Syslog側でCEFを除外する必要がある場合は、DCRの変換やクエリに次のような条件を入れることを検討します。
| where SyslogMessage !contains "CEF:0"ただし、この条件をどこに入れるべきかは、環境のDCR構成、Sentinelコネクタ、CEFフォワーダーの設計によって変わります。すぐに本番全体へ適用せず、まずパイロット対象のLinuxサーバーでSyslog、CommonSecurityLog、関連アラートの件数を比較してください。
Metrics ExtensionとOpenTelemetryメトリックの確認ポイント
2026年1月から2月にかけて、Metrics関連ではOpenTelemetryプロセスパフォーマンスカウンターにプロセスID、実行可能ファイル名、コマンド、所有者などの既定ディメンションが追加され、1024文字を超える大きなディメンションは切り捨てられるようになりました。これは、ディメンションが大きすぎるメトリックがドロップされるのを避けるための変更です。(Microsoft Learn)
開発者やSREが見るべきポイントは、単に「メトリックが来ているか」ではありません。次の観点で確認します。
| 確認項目 | 見るべき理由 |
|---|---|
| プロセス名やコマンド単位のメトリック | ディメンション追加により、集計粒度が変わる可能性がある |
| アラート条件 | 以前より細かい系列に分かれ、しきい値判定の見え方が変わる場合がある |
| ダッシュボード | 凡例や系列数が増え、グラフが読みにくくなることがある |
| 長いコマンドライン | 1024文字超のディメンション切り捨てにより、完全一致のクエリが合わなくなる可能性がある |
| Azure Monitor Metrics / AMW連携 | OpenTelemetryメトリックの送信先設計に影響する |
特にコンテナ、バッチ処理、ジョブ実行基盤のようにコマンドラインが長くなりやすい環境では、更新後に「メトリックが減った」のではなく「ディメンションの扱いが変わった」可能性があります。
ロールアウトは段階的。全台同時更新を前提にしない
Azure Monitor Agentは定期的にリリースされ、Azureの安全な展開プラクティスに基づいて段階的に展開されます。Azure VMと仮想マシンスケールセットでは、自動更新がロールアウト開始から通常4〜6週間で完了し、Arc対応サーバーは追加検証によりさらに時間がかかる場合があります。また、ロールアウト中はリソースごとに異なるエージェントバージョンが動くことがあります。(Microsoft Learn)
この仕様を理解していないと、次のような誤解が起きます。
| よくある誤解 | 実際の考え方 |
|---|---|
| 公式リリースノートに出たので全台更新済み | リージョンやリソース種別により反映時期がずれる |
| 一部のVMだけバージョンが違うので障害 | 段階的ロールアウト中は正常な場合がある |
| すぐ最新版にするには待つしかない | リージョンで利用可能なら手動更新できる場合がある |
| 自動更新なら検証不要 | DCR、KQL変換、アラート、ダッシュボードの確認は必要 |
本番環境では、更新の前後で「収集できているか」「期待するテーブルに入っているか」「重複取り込みがないか」「アラート件数が不自然に変わっていないか」を確認しましょう。
管理者が最初に確認すべき設定
Azure Monitor Agent extension versionsの更新を見たら、まず現在の展開状態を確認します。Azureポータルでは、対象VMまたはAzure Arc対応サーバーの「拡張機能」から、AzureMonitorWindowsAgentまたはAzureMonitorLinuxAgentが正常にプロビジョニングされているか確認できます。Azure CLIでは、VMの場合はaz vm extension list、Arc対応サーバーの場合はaz connectedmachine extension listで確認できます。(Microsoft Learn)
az vm extension list \
--resource-group <resource-group-name> \
--vm-name <virtual-machine-name> \
--output tableAzure Arc対応サーバーでは次のように確認します。
az connectedmachine extension list \
--resource-group <resource-group-name> \
--machine-name <arc-server-name> \
--output table次に、Log AnalyticsワークスペースのHeartbeatテーブルで、AMAがデータを送っているか確認します。公式ドキュメントでは、Azure Monitor Agentのハートビート確認に次のようなクエリが示されています。(Microsoft Learn)
Heartbeat
| where Category == "Azure Monitor Agent"
| where TimeGenerated > ago(5m)
| project Computer, TimeGenerated, Category, OSType
| order by TimeGenerated descバージョン確認も併せて行う場合は、HeartbeatテーブルのVersion列を使います。Heartbeatテーブルには、エージェントのバージョンを示すVersion列があります。(Microsoft Learn)
Heartbeat
| where TimeGenerated > ago(24h)
| summarize LatestHeartbeat=max(TimeGenerated), Versions=make_set(Version) by Computer, OSType, _ResourceId
| order by LatestHeartbeat desc自動アップグレードは有効化しておく
ほとんどの環境では、Azure Monitor Agent拡張機能の自動アップグレードを有効にしておくのが基本です。Microsoftも、最新バージョンに更新するか、自動アップグレードを選択することを推奨しています。自動更新は数週間かけて段階的に行われるため、即時反映ではありませんが、サポート対象バージョンを維持するうえで重要です。(Microsoft Learn)
Azure VMでAzure CLIから自動アップグレードを有効化する例は次の通りです。
az vm extension set \
--name AzureMonitorWindowsAgent \
--publisher Microsoft.Azure.Monitor \
--vm-name <virtual-machine-name> \
--resource-group <resource-group-name> \
--enable-auto-upgrade trueLinuxの場合は、拡張機能名を変更します。
az vm extension set \
--name AzureMonitorLinuxAgent \
--publisher Microsoft.Azure.Monitor \
--vm-name <virtual-machine-name> \
--resource-group <resource-group-name> \
--enable-auto-upgrade trueAzure Arc対応サーバーでは次のように更新できます。
az connectedmachine extension update \
--name AzureMonitorLinuxAgent \
--machine-name <arc-server-name> \
--resource-group <resource-group-name> \
--enable-auto-upgrade trueVMSSではアップグレードポリシーに注意する
仮想マシンスケールセット、VMSSでAzure Monitor Agentを運用している場合は、VMSSのアップグレードポリシーを確認してください。手動アップグレードポリシーの場合、VMSSモデルを変更しただけでは既存インスタンスに反映されず、az vmss update-instancesなどで既存インスタンスを更新する必要があります。自動またはローリングアップグレードポリシーでは、拡張機能がインスタンスへ自動的に適用されます。(Microsoft Learn)
VMSSで起きやすい失敗は、「モデル上は更新済みなのに、稼働中インスタンスのエージェントが古いまま」という状態です。更新後は、VMSSモデルだけでなく、実インスタンスの拡張機能状態とHeartbeatの到着を確認してください。
DCRとAgentSettings DCRの確認ポイント
Azure Monitor Agentでは、データ収集規則、DCRが中心的な設定単位です。VM拡張機能だけを入れても、データ収集を開始するには少なくとも1つのDCRを作成し、エージェントに関連付ける必要があります。AzureポータルでDCRを作成すると、対象マシンへAMAが必要に応じてインストールされ、DCRとの関連付けも作成されます。(Microsoft Learn)
また、AgentSettings DCRを使うと、エージェント固有の設定を構成できます。2026年時点では、Azure Resource Managerテンプレートでのみ構成でき、AgentSettingsは他の設定を含まない単一のDCRである必要があります。VMとAgentSettings DCRは同じリージョンに配置する必要があります。(Microsoft Learn)
| パラメーター | 用途 | 実務での判断基準 |
|---|---|---|
MaxDiskQuotaInMB | データ送信できない間にローカルキャッシュへ保存する容量を指定 | ネットワーク断やPrivate Link構成で一時的に送信できない環境では既定値のままで足りるか確認 |
UseTimeReceivedForForwardedEvents | Microsoft SentinelのWindows Event Forwarding関連の時刻扱いを調整 | WEFを使い、イベント発生時刻と受信時刻のどちらを分析で重視するかで判断 |
ディスククォータを小さくしすぎると、ネットワーク障害時に保持できるデータ量が減ります。一方で、過度に大きくするとサーバーの空き容量を圧迫する可能性があります。ログ量が多いサーバーでは、日次の取り込み量、ネットワーク断の想定時間、OSディスク容量を見て決めるのが現実的です。
Log Analytics AgentやAzure Diagnostics extensionからの移行も再確認する
Azure Monitor Agent extension versionsの更新は、MMAやOMS、Azure Diagnostics extensionからの移行計画にも関係します。Log Analytics Agentは2024年8月31日に廃止済みで、2026年3月2日以降はLog Analytics Agentからのデータアップロードが予告なく停止する可能性があります。Microsoftは、MMA/OMSからAzure Monitor Agentへの移行手順として、現行環境の評価、DCRによるAMA構成、データ収集の検証、Log Analytics Agentの削除を示しています。(Microsoft Learn)
移行時は、いきなり全台切り替えるのではなく、次の順序で進めると失敗しにくくなります。
| 手順 | 実施内容 | 失敗しやすいポイント |
|---|---|---|
| 現状把握 | 既存エージェント、ワークスペース、依存サービスを棚卸し | 使われていない古いワークスペースや自動展開設定を見落とす |
| DCR作成 | 既存の収集設定をDCRへ変換・整理 | MMA時代のワークスペース設定をそのまま再現しようとして複雑化する |
| パイロット展開 | 少数サーバーでAMAとDCRを検証 | 本番相当のSyslog、IIS、Windowsイベントを含めず検証が薄くなる |
| 二重取り込み防止 | テスト中は旧エージェントの収集を止める | MMAとAMAが同じログを送り、コストや検知件数が増える |
| 本番展開 | Azure PolicyやIaCで大規模展開 | 新規VMへの自動適用設定を忘れ、移行後に未監視VMが増える |
| 旧エージェント削除 | 収集検証後にLog Analytics Agentを削除 | SCOM例外や依存サービスを確認せず削除する |
Azure Diagnostics extension、WAD/LADについても注意が必要です。Azure Diagnostics extensionは2026年3月31日に非推奨となり、サポート対象外になっています。Microsoftは、新規デプロイでは使用せず、LAD/WADから代替ソリューションへ移行し、Azure Monitor Agent構成後は重複データを避けるためLAD/WADを削除するよう案内しています。(Microsoft Learn)
Azure Batch利用環境では移行ブロック解消を確認する
2026年2月の更新では、Azure BatchプールへのDCR関連付けが有効になり、レガシエージェント、MMAからAMAへの移行をブロックする残りのシナリオがないと説明されています。Azure Batchを利用していて、これまで監視エージェント移行を保留していた環境では、改めてAMA移行計画を見直すタイミングです。(Microsoft Learn)
確認すべきことは次の通りです。
- Batchプールに関連付けるDCRが決まっているか
- IMDSメタデータ由来のリソースタグを使った識別に問題がないか
- ジョブ実行中の一時的なVMでHeartbeatやメトリックが期待どおり届くか
- 短時間で破棄されるノードのログをどこまで保存する必要があるか
- 旧エージェントとAMAの二重取り込みが発生していないか
Batch環境では、通常の常駐VMよりもライフサイクルが短いため、「インストール成功」だけでは不十分です。ジョブ開始からログ送信までの時間、ノード削除前に必要なデータが届くかを確認してください。
避けるべきバージョンと既知の問題
公式リリースノートでは、使用を避けるべきバージョンも明示されています。Linuxではv1.10.7、v1.15.1、v1.25.2、Windowsではv1.1.3.1、v1.1.5.0を使わず、修正プログラムのバージョンを使うよう案内されています。また、v1.1.3.2およびv1.12.2.0ではLinux Arc対応サーバーからデータが収集されない既知の問題、v1.29.4ではLinuxパフォーマンスカウンターのデータが再起動後に停止する既知の問題が挙げられています。(Microsoft Learn)
現在それらのバージョンを使っている可能性が低くても、長期間更新していないArc対応サーバー、閉域環境、検証環境から昇格したVMでは古いエージェントが残っていることがあります。大規模環境では、HeartbeatのVersion列、拡張機能一覧、Azure Resource Graphを組み合わせて棚卸しするのが安全です。
更新後に確認するKQLクエリ例
AMA更新後は、少なくとも「ハートビート」「バージョン分布」「データ欠損」「重複収集」を確認します。
AMAのハートビート確認
Heartbeat
| where TimeGenerated > ago(1h)
| where Category == "Azure Monitor Agent"
| summarize LastSeen=max(TimeGenerated) by Computer, OSType, _ResourceId
| order by LastSeen descエージェントバージョンの分布確認
Heartbeat
| where TimeGenerated > ago(24h)
| summarize LastSeen=max(TimeGenerated), Computers=dcount(Computer) by Version, OSType
| order by OSType asc, Version desc更新後にハートビートが止まった可能性のあるマシン
Heartbeat
| where TimeGenerated > ago(7d)
| summarize LastSeen=max(TimeGenerated) by Computer, _ResourceId, OSType
| where LastSeen < ago(1h)
| order by LastSeen ascCEF混入の確認例
Syslog
| where TimeGenerated > ago(24h)
| where SyslogMessage contains "CEF:0"
| summarize Count=count() by Computer
| order by Count descこのクエリで想定外に件数が出る場合、CEFログがSyslog側に混入している可能性があります。DCRの変換、CEFフォワーダー、Sentinelコネクタの設計を見直してください。
運用チーム向けのチェックリスト
Azure Monitor Agent extension versionsの更新を受けて、管理者や開発者は次の順で確認すると効率的です。
| 優先度 | 確認項目 | 判断基準 |
|---|---|---|
| 高 | 自動アップグレードが有効か | --enable-auto-upgrade trueまたはポータル設定で確認 |
| 高 | Windows / Linux / Metricsの対象バージョン | Windowsだけ、Linuxだけ、Metricsだけの更新を混同しない |
| 高 | Linux CEF/SyslogのDCR変換 | CEF:0を含むログがSyslogテーブルに想定外に入っていないか |
| 高 | Log Analytics AgentやWAD/LADの残存 | 二重取り込み、コスト増、移行漏れを防ぐ |
| 中 | VMSSの実インスタンス反映 | モデル更新だけでなく既存インスタンスに適用済みか確認 |
| 中 | Metricsのディメンション変更 | アラート、ブック、ダッシュボードの系列数や集計条件を確認 |
| 中 | Azure BatchのDCR関連付け | 短命ノードでもログ・メトリックが届くか確認 |
| 低 | Linuxローカルユーザー | azuremonitoragentなどのシステムユーザーを削除・変更しない |
Linuxでは、AMAインストール時にazuremonitoragent、azureotelcollector、azuremetricsextなどのローカルユーザーアカウントが作成されます。これらはコンポーネントサービスを安全に実行するための非対話型システムユーザーであり、削除や変更をするとエージェントが正しく動作しない可能性があります。セキュリティスキャンでホームディレクトリがないと指摘されても、仕様として扱えるケースがあります。(Microsoft Learn)
まとめ：最新版の把握だけでなく、DCRとデータ品質まで確認する
Azure Monitor Agent extension versionsの更新で見るべきポイントは、バージョン番号だけではありません。2026年6月時点では、Windows 1.43のインストーラー修正とOpenSSL更新、Linux 1.41のCEF/Syslog破壊的変更、Metrics ExtensionのOpenTelemetry関連更新、Azure Batchサポート、MMAやWAD/LADからの移行状況が重要です。
まずは、自動アップグレードの有効化、現在のAMAバージョン確認、Heartbeatの到着確認を行いましょう。そのうえで、LinuxのCEF/Syslog、Windowsイベントログ、Metricsのディメンション、VMSSの実インスタンス反映、旧エージェントの残存を確認します。
特に本番環境では、いきなり全台で設定を変えるのではなく、代表的なWindowsサーバー、Linuxサーバー、Arc対応サーバー、VMSS、Batchノードを含むパイロットグループで更新後のデータを比較してください。Azure Monitor Agentは監視基盤そのものなので、「エージェントが入っている」ではなく「必要なデータが、正しいテーブルに、重複なく、期待する粒度で届いている」ことを確認するのが最終ゴールです。
コメント