Azure Monitor Agent Supported Operating Systemsを確認する目的は、「エージェントを入れられるOSか」を見るだけではありません。実務では、OSの種類、x64/ARM64、Azure VMかオンプレミスか、Data Collection Rule（DCR）の関連付け、Log Analytics agentからの移行可否まで含めて判断する必要があります。
2026年5月16日時点で確認すべき結論は、Azure Monitor Agent（AMA）は幅広いWindows/Linuxに対応している一方、x86はサポート対象外で、LinuxではPythonや一部パッケージ、ディスク容量、ハードニング設定が原因で展開に失敗するケースがあるという点です。Microsoft Learnの公式ページでは、対象OS一覧に加えて、カスタム化されたディストリビューションやアプライアンス環境の制限も明記されています。なお、公式ページ上の最終更新日は2026年5月15日です。(Microsoft Learn)
この記事では、Azure Monitor Agent Supported Operating Systemsの要点を、管理者・開発者が実際に確認すべき変更点、影響範囲、展開前チェック、移行時の注意点に分けて整理します。
Azure Monitor Agent Supported Operating Systemsの要点
Azure Monitor Agent Supported Operating Systemsで最初に押さえるべきポイントは、次の4つです。
| 確認項目 | 実務上の意味 |
|---|---|
| x86は非対応 | 公式の対応OS一覧はx64前提です。古い32bit OSや32bit前提のアプライアンスは展開対象から外します。 |
| Windows Server 2025や主要Linuxが対象 | 新しいOS世代を使うAzure VMやサーバー更改でもAMAを前提に設計しやすくなっています。 |
| Windows Server 2012 R2はESU条件付き | 「対応表にあるから問題ない」と判断せず、ESU契約の有無を確認します。 |
| オンプレミス・他クラウドはAzure Arcが前提 | 非Azure環境ではAzure Arc-enabled serversとして管理し、AMAを展開します。 |
特に重要なのは、AMAのインストールとデータ収集は同じではないという点です。Azure Monitor Agentはインストール後、Data Collection Rule（DCR）と関連付けて初めて、収集対象のログやメトリックをAzure Monitorへ送信します。エージェントだけを入れて「データが来ない」と判断するのは、よくある確認漏れです。(Microsoft Learn)
対応Windows OS：サーバー、クライアント、Azure Localを分けて確認する
公式情報では、Azure Monitor Agentは以下のWindows OSをサポート対象として掲載しています。すべてのOSは原則x64前提です。(Microsoft Learn)
| 分類 | サポート対象 | 確認すべきポイント |
|---|---|---|
| Windows Server | Windows Server 2025、2022、2022 Core、2019、2019 Core、2016、2016 Core | サーバー更改や新規VM構築では、AMAを前提に監視設計できます。 |
| 条件付きの旧OS | Windows Server 2012 R2 with an ESU agreement | ESU契約が前提です。ESUなしの環境はOS移行計画を優先します。 |
| Windows 11 | Windows 11 Client and Pro、Windows 11 Enterprise（multi-sessionを含む） | Windows 11 Client and ProはARM64ベースのマシンもサポート対象です。 |
| Windows 10 | Windows 10 1803（RS4）以降、Windows 10 Enterprise（multi-sessionを含む）およびProのサーバーシナリオ | Windows 10/11クライアント端末では、Windows client installerの要否を確認します。 |
| その他 | Azure Local、Windows IoT Enterprise | エッジ環境やIoT用途では、OSそのものだけでなくカスタム化の有無も確認します。 |
Windows Server 2012 R2が表に残っている点は、移行を先送りする理由にはなりません。AMAの対応可否と、OS自体のライフサイクル、セキュリティ更新、アプリケーションサポートは別の論点です。監視エージェントが入るとしても、脆弱性対応やベンダーサポートの観点から、旧OSは移行対象として管理するのが安全です。
対応Linux OS：ディストリビューション名だけでなく条件も見る
Linuxでは、同じ「Red Hat系」「Debian系」でも、バージョンやARM64対応、必要パッケージの有無によって展開可否が変わります。公式情報では、次のディストリビューションファミリーがサポート対象として整理されています。(Microsoft Learn)
| 系統 | サポート対象 | 実務上の注意点 |
|---|---|---|
| Red Hat系 | AlmaLinux 9/8、Oracle Linux 9/8/7、Red Hat Enterprise Linux Server 10、9+、8.6+、8.0-8.5、7.9、Rocky Linux 9/8 | RHEL 10のような新しい世代も対象です。一方で、RHEL 7.9など古い世代はOS更改計画と併せて確認します。 |
| Debian系 | Debian 13/12/11/10/9、Ubuntu 24.04 LTS、22.04 LTS、20.04 LTS、18.04 LTS、16.04 LTS | Ubuntu 24.04 LTSやDebian 13も対象です。古いUbuntu 16.04 LTSなどは、監視可否とOS保守の観点を分けて判断します。 |
| SUSE系 | OpenSUSE 15、SUSE Linux Enterprise Server 15 SP7 | SLES環境ではサービスパック単位で確認します。 |
| Amazon Linux | Amazon Linux 2、Amazon Linux 2023 | 他クラウド環境で利用する場合は、Azure Arc-enabled serversとしての管理が前提になります。 |
| Azure Linux | Azure Linux 3.0、CBL-Mariner 2.0 | CBL-Mariner/Azure Linuxではディスク容量の条件に注意します。 |
Linuxでは、Python 3またはPython 2、which、initscriptsパッケージが必要です。また、公式対応表に載っているディストリビューションでも、強くカスタム化されたイメージや、ユーザーによるOS変更を許可しないホステッドアプライアンスはサポート対象外になる場合があります。(Microsoft Learn)
たとえば、監視エージェントを入れるために必要なパッケージ、サービス管理、ログ出力先、暗号化ポリシーが削られていると、OS名だけは一致していても展開に失敗します。Linuxアプライアンスやマーケットプレイスイメージを使う場合は、「Ubuntu 22.04だから対応」ではなく、「公式イメージ相当のベース機能が残っているか」まで確認してください。
2026年5月時点で管理者が見るべき変更点
今回のAzure Monitor Agent Supported Operating Systemsで実務上目立つのは、新しいOS世代と条件付きOSが同じ表に並んでいる点です。Windows Server 2025、Red Hat Enterprise Linux Server 10、Debian 13、Ubuntu 24.04 LTS、Amazon Linux 2023、Azure Linux 3.0などが対象に含まれているため、新規構築・更改案件ではAMAを標準エージェントとして設計しやすくなっています。(Microsoft Learn)
一方で、古いOSも一部掲載されています。ここで誤解しやすいのは、「AMAが対応している」ことと「そのOSを使い続けてよい」ことは同義ではないという点です。Windows Server 2012 R2はESU契約が条件ですし、古いLinuxディストリビューションでは、OS自体の保守期限、アプリケーション要件、セキュリティ基準を別途確認する必要があります。
ARM64対応も、すべてのOSに広がっているわけではありません。公式ページでは、Windows 11 Client and Proのほか、脚注で指定された一部LinuxディストリビューションがARM64対応として扱われています。ARM64のAzure VMや省電力サーバーを利用する場合は、CPUアーキテクチャを資産台帳に入れ、x64前提の展開スクリプトをそのまま流用しないようにします。
影響範囲：Azure VM、VMSS、オンプレミス、他クラウドまで確認する
Azure Monitor Agentの対応OS更新は、単にAzure VMだけに影響するものではありません。AMAはAzure仮想マシン、仮想マシンスケールセット、Azure Arc-enabled serversに展開でき、オンプレミスや他クラウドのサーバーもAzure Arcを通じて対象になります。(Microsoft Learn)
Azure VMと仮想マシンスケールセット
Azure VMでは、拡張機能としてAzure Monitor Agentを展開します。WindowsではAzureMonitorWindowsAgent、LinuxではAzureMonitorLinuxAgentを使います。Azure CLIやPowerShell、ARMテンプレート、Azure Policyから展開できるため、数台の検証環境では手動、数百台以上ではAzure PolicyやIaCで管理するのが現実的です。
仮想マシンスケールセットでは、アップグレードポリシーにも注意が必要です。手動アップグレードポリシーの場合、拡張機能をモデルに追加しただけでは既存インスタンスへ反映されないことがあります。その場合は、既存インスタンスの更新操作が必要です。(Microsoft Learn)
オンプレミスと他クラウド
オンプレミスや他クラウドのサーバーでAMAを利用する場合は、Azure Arc-enabled serversが前提です。従来のLog Analytics agentはワークスペースIDとキーで認証していましたが、Azure Monitor AgentではマネージドIDを使います。非Azure環境では、Azure ArcのConnected Machine agentを入れることで、対象サーバーがAzure上の管理対象リソースとして扱われます。(Microsoft Learn)
この違いは、移行時に大きな影響があります。旧エージェントのインストールスクリプトをそのまま置き換えるだけでは、Arc登録、マネージドID、DCR関連付けが不足し、データ収集まで完了しません。
Windowsクライアント端末
Windows 10/11のクライアント端末は、サーバーVMと同じ考え方で展開できるとは限りません。公式情報では、WindowsクライアントデバイスではAzure Monitor Agentのclient installerが必要とされています。(Microsoft Learn)
VDI、Windows 11 Enterprise multi-session、Windows 10 Enterprise multi-sessionを監視する場合は、通常のサーバー監視と、クライアント端末監視の境界を明確にしてください。収集するイベントログ、パフォーマンスカウンター、セキュリティイベント、利用者端末としてのプライバシー要件も変わります。
展開前チェックリスト
AMAの展開前には、OS対応表だけでなく、次の項目を確認します。
| チェック項目 | 確認内容 | 見落とした場合の影響 |
|---|---|---|
| OS名とバージョン | Windows Server、Ubuntu、RHELなどが公式対応表に含まれるか | エージェント展開失敗、サポート対象外運用 |
| CPUアーキテクチャ | x64か、ARM64対応OSか | x86環境では利用不可。ARM64は対象OSが限定されます。 |
| Azure/非Azureの区分 | Azure VM、VMSS、Azure Arc-enabled serverのどれか | オンプレミスや他クラウドでArc登録が漏れます。 |
| マネージドID | Azure VMではシステム割り当てまたはユーザー割り当て、Arcではシステム割り当て | 認証できず、収集データを送れません。 |
| DCR | 収集対象ログ、メトリック、送信先ワークスペースを定義して関連付ける | エージェントは入っているのにデータが来ません。 |
| Linux依存パッケージ | Python、which、initscriptsの有無 | インストールや実行に失敗します。 |
| ディスク容量 | インストール領域、ログ、キャッシュ、イベントキャッシュを確保 | アップグレード時や高負荷時に失敗しやすくなります。 |
| ハードニング設定 | FIPS、STIG、CIS、SELinux、暗号化ポリシー | 特定ポリシーで通信や起動が失敗する可能性があります。 |
| 旧エージェント | Log Analytics agentとの重複収集がないか | データ重複、コスト増、移行判定ミスにつながります。 |
Azure Monitor Agentの要件では、Azure VMにマネージドIDが必要で、大規模展開ではユーザー割り当てマネージドIDが推奨されます。一方、Azure Arc-enabled serversではシステム割り当てマネージドIDのみがサポートされます。(Microsoft Learn)
OS棚卸しからAMA展開までの実務手順
まずAzure Resource Graphで対象OSを棚卸しする
Azure VMのOS情報は、Azure Resource Graphで一括確認できます。カスタムイメージではpublisherやofferが空になることがあるため、必要に応じてゲストOS側の情報と突き合わせます。
Resources
| where type =~ 'microsoft.compute/virtualmachines'
| extend osType = tostring(properties.storageProfile.osDisk.osType)
| extend publisher = tostring(properties.storageProfile.imageReference.publisher)
| extend offer = tostring(properties.storageProfile.imageReference.offer)
| extend sku = tostring(properties.storageProfile.imageReference.sku)
| extend version = tostring(properties.storageProfile.imageReference.version)
| project subscriptionId, resourceGroup, name, location, osType, publisher, offer, sku, version
| order by osType, publisher, offer, skuAzure Arc-enabled serversは、次のように一覧化します。
Resources
| where type =~ 'microsoft.hybridcompute/machines'
| extend osName = tostring(properties.osName)
| extend osVersion = tostring(properties.osVersion)
| extend status = tostring(properties.status)
| project subscriptionId, resourceGroup, name, location, osName, osVersion, status
| order by osName, osVersion棚卸し後は、対象サーバーを次の4分類に分けると、移行計画が作りやすくなります。
| 分類 | 判断基準 | 次のアクション |
|---|---|---|
| そのまま展開可能 | 対応OS、x64、標準的な構成 | DCRを設計し、パイロット展開します。 |
| 条件付きで展開可能 | Windows Server 2012 R2 with ESU、ARM64対応OS、ハードニング環境 | 条件を証跡として残し、検証環境で展開します。 |
| OS更改を優先 | サポート表にないOS、x86、保守切れOS | AMA展開ではなく、OS移行計画を先に作ります。 |
| 個別検証が必要 | アプライアンス、強くカスタム化されたLinux、独自イメージ | ベンダー仕様、パッケージ、変更可否を確認します。 |
DCRを先に設計する
AMAでは、Data Collection Rule（DCR）が収集設定の中心です。従来のLog Analytics agentのように、ワークスペース側の設定だけで自動的に同じ収集が行われるわけではありません。Microsoftの移行ガイドでも、AMAはDCRを使ってデータ収集を構成する点が説明されています。(Microsoft Learn)
DCR設計では、最低限次を決めます。
- 収集するWindowsイベントログ
- 収集するLinux Syslog
- パフォーマンスカウンター
- カスタムログ
- 送信先のLog Analytics workspace
- 対象リソースとの関連付け
- VM insightsやMicrosoft Sentinelなど依存サービスとの関係
本番展開前に、既存のLog Analytics agent設定をそのまま再現する必要があるのか、不要なログを削減するのかを決めてください。移行は、監視コストとログ設計を見直すよいタイミングです。
小さなパイロットグループで検証する
最初から全台に展開せず、OS種別ごとに代表サーバーを選びます。たとえば、Windows Server 2022、Windows Server 2019 Core、Ubuntu 22.04 LTS、RHEL 9、オンプレミスArcサーバーを1〜数台ずつ選ぶと、主要パターンを短期間で検証できます。
Azure VMにシステム割り当てマネージドIDでAMAを展開する例は次のとおりです。
az vm extension set \
--name AzureMonitorLinuxAgent \
--publisher Microsoft.Azure.Monitor \
--ids <vm-resource-id> \
--enable-auto-upgrade trueWindowsの場合は、拡張機能名をAzureMonitorWindowsAgentにします。
az vm extension set \
--name AzureMonitorWindowsAgent \
--publisher Microsoft.Azure.Monitor \
--ids <vm-resource-id> \
--enable-auto-upgrade trueAzure Arc-enabled serverでは、次のようにConnected Machineの拡張機能として展開します。
az connectedmachine extension create \
--name AzureMonitorLinuxAgent \
--publisher Microsoft.Azure.Monitor \
--type AzureMonitorLinuxAgent \
--machine-name <arc-server-name> \
--resource-group <resource-group-name> \
--location <arc-server-location> \
--enable-auto-upgrade true展開後はHeartbeatで確認する
展開後は、Azure portalの拡張機能ステータスだけでなく、Log Analytics workspaceにHeartbeatが届いているかを確認します。公式ドキュメントでも、HeartbeatテーブルでCategory == "Azure Monitor Agent"を確認する方法が示されています。(Microsoft Learn)
Heartbeat
| where Category == "Azure Monitor Agent"
| where TimeGenerated > ago(24h)
| summarize LastSeen = max(TimeGenerated) by Computer, OSType
| order by LastSeen descデータが出ない場合は、次の順に確認します。
- AMA拡張機能が
Provisioning succeededになっているか - DCRが対象VMまたはArcサーバーに関連付いているか
- Log Analytics workspaceの送信先が正しいか
- ネットワークやPrivate Linkの経路でブロックされていないか
- Linuxの依存パッケージや暗号化ポリシーが要件を満たしているか
Log Analytics agentからの移行で注意すべき点
Log Analytics agent、別名Microsoft Monitoring Agent（MMA）やOperations Management Suite（OMS）agentは、2024年8月31日に廃止されています。Microsoftの移行ガイドでは、2026年3月2日以降、Log Analytics agentからのデータアップロードが予告なく停止する可能性、Azure portalからのインストール不可、サポート終了、新しいOSやディストリビューションの追加なしといった影響が説明されています。(Microsoft Learn)
そのため、対応OS一覧を確認するだけでなく、既存のLog Analytics agent環境をAMAへ移行する計画が必要です。移行の流れは次の順番が安全です。
| 手順 | 作業内容 | 注意点 |
|---|---|---|
| 現状把握 | 旧エージェント、ワークスペース、依存サービスを棚卸し | Microsoft Sentinel、Defender for Cloud、Change Trackingなどの利用有無を確認します。 |
| DCR作成 | 既存の収集設定をDCRへ変換・再設計 | DCR Config Generatorなどを使い、必要な収集だけに絞ります。 |
| パイロット展開 | 少数サーバーでAMAとDCRを関連付け | 旧エージェントとの二重収集に注意します。 |
| データ比較 | Heartbeat、イベント、Syslog、パフォーマンスデータを比較 | 収集件数、列、欠落データを確認します。 |
| 段階展開 | Azure PolicyやIaCで対象を拡大 | 新規VMにも自動適用されるようにします。 |
| 旧エージェント削除 | 検証後にLog Analytics agentを削除 | 重複コストと誤検知を防ぎます。 |
移行で失敗しやすいのは、「AMAを入れたから旧エージェントをすぐ消す」という進め方です。特にIISログ、セキュリティイベント、Syslog、カスタムログは、DCRで同じ範囲を収集できているかを確認してから削除します。Microsoftの移行ガイドでも、パイロットグループで検証し、データ収集が正しく機能することを確認してから展開を広げる流れが示されています。(Microsoft Learn)
ハードニング環境で失敗しやすいポイント
セキュリティ基準を適用した環境では、Azure Monitor Agentの展開前検証が特に重要です。公式情報では、WindowsのSTIG、FIPS、FedRAMPに関する対応、LinuxのSELinux、CIS level 1/2、STIG、FIPS、FedRAMPに関する対応が説明されています。ただし、Linuxのハードニング基準に関する説明はAzure Monitor Agent for Linuxが対象であり、Dependency AgentやAzure Diagnostics extensionには適用されません。(Microsoft Learn)
Linuxで特に注意すべきなのが、システム全体の暗号化ポリシーです。公式情報では、Linuxマシンのsystem-wide crypto policyをFUTUREに設定すると、Azure Monitor Agentが動作しないとされています。現在の設定は次のコマンドで確認できます。(Microsoft Learn)
sudo update-crypto-policies --showセキュリティチームが暗号化ポリシーを一括適用している環境では、AMAの通信要件と組織のセキュリティ基準を事前に調整してください。本番展開後に通信できないことが分かると、監視の空白期間が発生します。
また、Azure LinuxやCBL-Marinerでは、ディスク容量にも注意が必要です。公式情報では、Azure Monitor Agentのインストールと正常動作に少なくとも4GBのディスクサイズが必要とされています。(Microsoft Learn)
ディスク容量とアップグレード設計も確認する
Azure Monitor Agentは、インストールパッケージ、拡張機能ログ、エージェントキャッシュ、イベントキャッシュをローカルファイルシステムに保持します。公式要件では、Windowsのエージェントキャッシュに10.5GB、Linuxのイベントキャッシュに10GBなど、用途別の目安が示されています。さらに、アップグレード中は一時的に2つのバージョンが共存するため、必要ディスク容量が実質的に増えます。(Microsoft Learn)
小さなOSディスクで構築されたVM、ログ量が多いサーバー、短時間にイベントが集中するサーバーでは、ディスク不足が監視停止の原因になります。特に以下の環境は、展開前に空き容量を確認してください。
- 小容量OSディスクのLinux VM
- Azure Linux/CBL-MarinerベースのVM
- セキュリティイベントを大量に収集するWindows Server
- Syslogやアプリケーションログが多いLinuxサーバー
- VMSSで一斉アップグレードする環境
AMAの更新については、自動拡張機能アップグレードを有効にするのが基本です。ただし、自動ロールアウトは段階的に行われるため、すべてのVMが同時に最新化されるとは限りません。緊急対応が必要な場合は、手動更新の手順も運用 Runbook に入れておきます。(Microsoft Learn)
よくある失敗と対策
| 失敗パターン | 主な原因 | 対策 |
|---|---|---|
| AMAは入っているのにログが来ない | DCR未作成、DCR未関連付け、送信先ワークスペース違い | DCRとDCR associationを確認し、HeartbeatをKQLで確認します。 |
| オンプレミスサーバーに展開できない | Azure Arc登録がない、ArcのマネージドID前提を理解していない | Connected Machine agentを導入し、Arcリソースとして管理します。 |
| Windows Server 2012 R2で判断に迷う | ESU契約の有無が不明 | ESU契約を確認し、なければOS更改を優先します。 |
| Linuxでインストールが失敗する | Python、which、initscripts不足 | パッケージの有無を事前確認し、標準構成との差分を洗い出します。 |
| ハードニング済みLinuxで通信できない | crypto policyがFUTURE、または独自CIS設定 | update-crypto-policies --showで確認し、セキュリティ部門と調整します。 |
| VMSSの一部だけ古い状態になる | 手動アップグレードポリシーで既存インスタンス未更新 | VMSSの既存インスタンス更新を実行します。 |
| 監視コストが増える | Log Analytics agentとAMAの二重収集 | パイロット時に旧エージェントの収集設定を止め、データ比較後に削除します。 |
| カスタムアプライアンスでサポート外になる | OS名は一致しているが、必要なベース機能が削られている | ベンダー仕様、変更可否、必要パッケージを確認します。 |
この表の中でも、DCR未関連付けと二重収集は特に多い失敗です。Azure Monitor Agentは、従来のLog Analytics agentとは設定の考え方が変わっています。移行時は「エージェント展開」「DCR設計」「データ検証」「旧エージェント削除」を別工程として管理してください。
管理者・開発者が次に取るべき行動
Azure Monitor Agent Supported Operating Systemsを確認したら、次にやるべきことは明確です。
まず、Azure VM、VMSS、Azure Arc-enabled serversを棚卸しし、OS名、バージョン、アーキテクチャ、Azure/非Azureの区分を一覧化します。次に、公式対応表と照合して「そのまま展開可能」「条件付き」「OS更改優先」「個別検証」の4分類に分けます。
そのうえで、DCRを設計し、代表的なOSごとにパイロット展開します。Heartbeat、イベントログ、Syslog、パフォーマンスデータを確認し、旧Log Analytics agentとの重複や欠落がないことを見てから、Azure PolicyやIaCで段階展開します。
最後に、Log Analytics agentを使っている環境では、移行を先延ばしにしないことが重要です。Log Analytics agentは既に廃止されており、今後の新しいOSやディストリビューションの監視はAMA前提で考える必要があります。対応OS一覧の確認は、単なる互換性チェックではなく、監視基盤をAMAとDCR中心に作り直すための出発点です。
コメント