Azure Monitor Agent Overview で最初に押さえるべき結論は、Azure Monitor Agent（AMA）は、Azure VM とハイブリッド VM のゲスト OS 監視データを集めるための標準的なエージェントであり、運用の中心は「エージェントを入れること」ではなく「DCR（データ収集規則）で何を、どこへ、どう送るかを設計すること」に移っている、という点です。
従来の Log Analytics agent、MMA、OMS agent をまだ使っている環境では、移行の有無を確認するだけでは不十分です。DCR 設計、Azure Arc、マネージド ID、ネットワーク許可、重複取り込みによるコスト増まで含めて見直す必要があります。Microsoft Learn の Azure Monitor Agent Overview は 2026年4月9日更新、移行ガイドは 2026年5月8日更新として掲載されており、本記事では 2026年5月9日時点で管理者・開発者が確認すべき内容を実務目線で整理します。(Microsoft Learn)
Azure Monitor Agent Overviewで何が変わるのか
Azure Monitor Agent Overview の要点は、AMA が Azure Monitor におけるゲスト OS データ収集の中心になっていることです。AMA は Azure VM、オンプレミス、他クラウド上の Azure Arc 対応サーバーなどから、OS のログやパフォーマンスデータを収集し、Azure Monitor、Microsoft Sentinel、Microsoft Defender for Cloud などで使えるようにします。(Microsoft Learn)
ただし、以前のエージェント運用と大きく違うのは、設定の考え方です。Log Analytics agent ではワークスペース側の構成に依存する場面が多くありましたが、AMA では DCR（Data Collection Rule） が収集内容、処理方法、送信先を定義します。つまり、移行後の監視品質は「AMA をインストールしたか」ではなく、「DCR を適切に設計・関連付けできているか」で決まります。(Microsoft Learn)
実務上の変更点は、次のように整理できます。
| 観点 | 従来の見方 | AMAで重視すべき見方 |
|---|---|---|
| エージェント | サーバーに監視エージェントを入れる | VM 拡張機能や Azure Policy で展開し、DCR と関連付ける |
| 収集設定 | ワークスペースやソリューション側の設定に依存 | DCR で収集データ、変換、送信先を管理する |
| ハイブリッド環境 | 個別にエージェント導入を考える | Azure Arc 対応サーバーとして管理対象化する |
| コスト管理 | 収集後に利用量を見る | DCR で不要な収集や重複送信を抑える |
| 移行 | エージェント置き換え作業 | 依存サービス、DCR、検証、旧エージェント削除まで含むプロジェクト |
Azure MonitorのAI/Copilot更新と混同しない：AMAは監視データ収集の土台
Azure Monitor 関連では、Azure Copilot observability agent や Observability agent に関するドキュメント更新も行われています。Microsoft Learn の What’s new では、2026年2月に Azure Copilot observability agent 関連の記事が大幅に書き換えられ、2026年4月には Observability agent のガイダンスが現在の製品体験に合わせて整理されたことが示されています。(Microsoft Learn)
ここで混同しやすいのは、AMA と Copilot/Observability agent の役割です。Copilot や AI を使った調査体験は、トラブルシューティングや会話型の探索を支援する側です。一方、Azure Monitor Agent は、VM やサーバーから監視データを集める収集基盤です。AI による調査を活用する場合でも、そもそも必要なログ、イベント、パフォーマンスデータが正しく収集されていなければ、調査の精度は上がりません。
そのため、Azure Monitor の AI/Copilot 更新を追う管理者ほど、まず AMA と DCR の設計を確認する必要があります。AI 活用の前提は、きれいに整理された監視データです。
影響を受ける環境
Azure Monitor Agent Overview の内容は、Azure VM だけでなく、オンプレミスや他クラウドを含むハイブリッド監視環境にも影響します。AMA は Azure、他クラウド、オンプレミスの VM にインストールでき、Azure 以外のマシンでは Azure Arc エージェントの導入が前提になります。(Microsoft Learn)
| 対象 | 影響 | 確認すべきこと |
|---|---|---|
| Azure VM | AMA を VM 拡張機能として展開できる | DCR が関連付いているか、マネージド ID が有効か |
| VM Scale Sets | スケール環境にも展開対象になる | Azure Policy や IaC で一貫展開できるか |
| オンプレミスサーバー | Azure Arc 経由で AMA を導入する | Arc Connected Machine agent が導入済みか |
| 他クラウド上の VM | Azure Arc 対応サーバーとして管理する | ネットワーク、プロキシ、ID 設定を確認する |
| Microsoft Sentinel | AMA 対応の収集へ移行する必要がある | Sentinel ソリューションやセキュリティイベント収集の設定を見直す |
| Defender for Cloud | 一部のシナリオでは agentless scanning など別方式も関係する | Defender for Servers のプランと収集方法を確認する |
| Change Tracking | AMA 用 DCR の作成が必要になる | 旧エージェント依存のままになっていないか |
特に重要なのは、Log Analytics agent を使い続けている環境です。Microsoft の移行ガイドでは、Log Analytics agent は 2024年8月31日に廃止され、2026年3月2日以降はデータアップロードが予告なく停止する可能性があると説明されています。未移行の環境では、監視データが突然欠落するリスクを前提に対応を進めるべきです。(Microsoft Learn)
管理者が最初に確認すべき設定
Azure Monitor Agent の見直しでは、いきなり全 VM に展開するのではなく、現状把握から始めるのが安全です。確認すべき項目は大きく 5 つあります。
既存エージェントの棚卸し
まず、対象マシンに Log Analytics agent、MMA、OMS agent、Azure Diagnostics extension、Dependency Agent などが残っていないか確認します。複数のエージェントが同じデータを収集していると、Log Analytics ワークスペースへの重複取り込みが起き、コスト増やアラートの重複につながります。
棚卸しでは、次の情報を一覧化します。
| 確認項目 | 見るべきポイント |
|---|---|
| 対象マシン | Azure VM、VMSS、Arc 対応サーバー、他クラウド VM |
| 現在のエージェント | AMA、Log Analytics agent、Dependency Agent など |
| 送信先 | Log Analytics workspace、Azure Monitor workspace、Microsoft Sentinel |
| 収集データ | Windows イベント、Syslog、パフォーマンスカウンター、IIS ログ、カスタムログ |
| 依存サービス | Sentinel、Defender for Cloud、Change Tracking、Update Management、VM insights |
移行ガイドでは、Azure Monitor Agent Migration Helper workbook と DCR Config Generator が移行支援ツールとして紹介されています。前者はエージェントやワークスペース、依存サービスの把握に使え、後者は既存の Log Analytics agent のワークスペース構成を DCR に変換する用途で使えます。(Microsoft Learn)
DCRが関連付いているか
AMA はインストールしただけでは十分ではありません。VM 拡張機能として AMA を導入する方法では DCR は自動作成されないため、少なくとも 1 つの DCR を作成し、対象エージェントに関連付ける必要があります。DCR がない場合、期待したログやパフォーマンスデータは収集されません。(Microsoft Learn)
逆に、VM insights や Container insights を有効化した場合は、必要な DCR が自動的に作成されるケースがあります。ただし、VM insights が作成した DCR は直接変更せず、追加データが必要な場合は別の DCR を作成するのが安全です。(Microsoft Learn)
マネージドIDの設計
AMA ではマネージド ID が重要です。Azure VM ではシステム割り当てマネージド ID とユーザー割り当てマネージド ID の両方がサポートされていますが、大規模展開ではユーザー割り当てマネージド ID のほうが管理しやすいとされています。一方、Azure Arc 対応サーバーではシステム割り当てマネージド ID がサポートされ、Arc エージェント導入時に有効化されます。(Microsoft Learn)
注意したいのは、Azure portal から DCR にリソースを追加するときの既定動作です。既存アプリケーションでユーザー割り当てマネージド ID を使っている場合でも、指定しないと DCR によってシステム割り当て ID が適用される可能性があります。ID 設計を厳密に管理している環境では、ポータル操作だけに任せず、テンプレートや Azure Policy で明示的に管理するほうが安全です。(Microsoft Learn)
OSとディスク容量の要件
対応 OS も必ず確認します。Microsoft Learn の対応 OS 一覧では、Windows Server 2025、2022、2019、2016、ESU 契約付き Windows Server 2012 R2、Windows 10/11、複数の Linux ディストリビューションが掲載されています。ただし、全 OS は x64 前提で、x86 はサポートされていません。(Microsoft Learn)
Linux では Python、which、initscripts などの要件があり、Azure Linux ではディスクサイズにも注意が必要です。特に AMA のアップグレード時は一時的に 2 つのバージョンが同居するため、ディスク要件が実質的に増えることがあります。小容量ディスクの VM や、ログ領域を厳しく制限している環境では、展開前に空き容量を確認しておきましょう。(Microsoft Learn)
ネットワークとPrivate Link
閉域網、プロキシ、ファイアウォールを使う環境では、ネットワーク設定が移行失敗の原因になりやすいです。Azure Monitor Agent は直接プロキシ、Log Analytics gateway、Private Link をサポートしますが、必要なエンドポイントへの HTTPS 443 アウトバウンド通信やサービス タグの扱いを確認する必要があります。(Microsoft Learn)
特に注意すべき点は、HTTPS inspection を無効にする必要があることです。また、Azure Monitor Private Link Scope を使う場合は、すべての DCR で DCE（Data Collection Endpoint）を使用し、その DCE を Private Link Scope 構成に追加する必要があります。(Microsoft Learn)
DCR設計で失敗しやすいポイント
DCR は AMA 運用の中核です。DCR は、何を収集するか、どのように処理するか、どこへ送るかを定義します。Azure Monitor の DCR ドキュメントでは、DCR は従来のデータ収集方法を置き換える ETL に近い収集プロセスの一部として説明されています。(Microsoft Learn)
失敗しやすいのは、「すべてのログを 1 つの DCR に詰め込む」設計です。DCR は 1 つの DCR を複数リソースへ関連付けられ、1 つのリソースには最大 30 個の DCR を関連付けられます。そのため、用途ごとに分けて設計するほうが、運用・変更・コスト管理の面で扱いやすくなります。(Microsoft Learn)
| DCR設計の観点 | 推奨される考え方 | 具体例 |
|---|---|---|
| 監視スコープ | 役割や用途ごとに分ける | 共通 OS 監視、Web サーバー監視、DB サーバー監視 |
| データソース | 種類ごとに分ける | パフォーマンス、Windows イベント、Syslog、IIS ログ |
| 送信先 | 宛先ごとに分ける | Sentinel 用、運用監視用、長期分析用 |
| コスト | 必要なデータだけ収集する | 全イベントではなく重要イベント ID に絞る |
| 変更管理 | 変更影響を小さくする | 本番用 DCR と検証用 DCR を分ける |
たとえば、全 Windows VM に「CPU、メモリ、ディスクの基本パフォーマンスカウンター」を収集する DCR を関連付け、ドメインコントローラーには別途「セキュリティイベント」用 DCR を追加し、IIS サーバーには「IIS ログ」用 DCR を追加する設計が考えられます。これなら、IIS ログの設定変更が全サーバーに影響することを避けられます。
DCR の変換機能も重要です。変換では、受信データを保存前にフィルターしたり、不要な情報を削除したり、送信先テーブルのスキーマに合わせたりできます。不要データを取り込まない設計は、ログコスト削減とプライバシー対応の両方に効果があります。(Microsoft Learn)
移行は「入れ替え」ではなく段階的な検証で進める
Log Analytics agent から AMA への移行では、旧エージェントを消してから新エージェントを入れる進め方は避けるべきです。Microsoft の移行ガイドでは、現在の環境評価、DCR を使った AMA の構成と展開、データ収集の検証、旧 Log Analytics agent の削除という流れが示されています。(Microsoft Learn)
実務では、次の順番で進めると失敗を減らせます。
| 手順 | 作業内容 | 注意点 |
|---|---|---|
| 現状把握 | 既存エージェント、ワークスペース、依存サービスを棚卸しする | Sentinel、Defender、Change Tracking を忘れない |
| パイロット選定 | 少数の VM で検証する | 本番と同じ OS・ネットワーク条件を含める |
| DCR作成 | 既存設定を DCR に変換・整理する | DCR Config Generator の結果をそのまま本番投入しない |
| 重複回避 | テスト中は旧エージェント側のデータ収集を止める | すぐにアンインストールせず、比較期間を設ける |
| 検証 | Heartbeat、イベント、Syslog、パフォーマンス、カスタムログを確認する | 同じ期間で旧新の件数を比較する |
| 展開拡大 | Azure Policy や IaC で対象を広げる | 新規 VM にも自動適用されるようにする |
| 旧エージェント削除 | 検証後に Log Analytics agent を削除する | SCOM 管理対象は例外扱いを検討する |
移行中に特に注意すべきなのは、二重取り込みです。移行ガイドでは、テスト中の重複取り込みを避けるため、Log Analytics agent をすぐアンインストールするのではなく、パイロットサーバー上の Log Analytics agent のワークスペース構成を外してデータ収集を停止する方法が示されています。(Microsoft Learn)
Sentinel、Defender、Update Managementの依存関係を確認する
AMA への移行では、単に OS ログを集め直すだけでなく、周辺サービスの依存関係を確認する必要があります。
Microsoft Sentinel では、従来 Log Analytics agent を使っていたソリューションが AMA をサポートするようになっているため、ソリューションのバージョンやデータコネクタの構成を確認します。古い接続方式のままでは、期待したイベントが入らない場合があります。(Microsoft Learn)
Microsoft Defender for Cloud では、Defender for Servers Plan 2 を使っている場合、Log Analytics agent から agentless scanning への切り替えが移行アクションとして示されています。一方で、Defender for Cloud でセキュリティイベントを収集している場合は、カスタム DCR の作成が必要になる場合があります。(Microsoft Learn)
Azure Automation Update Management も注意が必要です。移行ガイドでは、Update Management は Azure Update Manager へ移行する対象として整理されています。AMA に置き換えればすべての更新管理機能がそのまま動く、という理解は危険です。(Microsoft Learn)
展開時の注意点：Azure Policyと自動更新を前提にする
AMA は、Azure portal、Azure PowerShell、Azure CLI、Resource Manager template、Azure Policy などで展開できます。大規模環境では、Azure Policy を使って AMA の自動インストールと DCR 関連付けを行う構成が現実的です。(Microsoft Learn)
手作業で VM ごとにエージェントを入れる運用は、初期検証には使えても、本番の継続運用には向きません。新規 VM、Arc 対応サーバー、VMSS の増減に追従できず、監視対象から漏れるサーバーが出やすくなります。
展開時に押さえるべき注意点は次の通りです。
| 注意点 | 実務での影響 |
|---|---|
| AMA のインストール、アップグレード、アンインストールにマシン再起動は不要 | 作業計画は立てやすいが、監視停止時間の確認は必要 |
| Azure 以外のマシンは Azure Arc エージェントが必要 | オンプレミスや他クラウドでは Arc 導入が先行作業になる |
| マシンのクローンはサポートされない | ゴールデンイメージ作成時は AMA を焼き込まず、Policy や IaC で展開する |
| DCR の関連付け前に DCR を作成する必要がある | テンプレート展開の順序に注意する |
| 自動更新は段階的にロールアウトされる | 一時的に VM 間で AMA バージョン差が出ることを想定する |
AMA のバージョン管理も重要です。Microsoft は過去 1 年以内にリリースされた Azure Monitor Agent バージョンをサポートし、すべてのバグ修正は最新バージョンに対して提供すると説明しています。可能な限り Automatic Extension Update を有効化し、緊急対応が必要な場合だけ手動更新を検討するのが現実的です。(Microsoft Learn)
2026年時点のバージョン確認ポイント
Azure Monitor Agent extension versions では、2026年4月版として Windows 1.42 が掲載され、OpenSSL 3.6.1、XPath を使った Windows Event XML データ解析、ローカルフィルターイベント処理のパフォーマンス改善などが示されています。Linux 側では CEF syslog stream への FTD/FMC メッセージ追加、ネストされた JSON の msgpack 処理修正、CJK や絵文字などのダブル幅 Unicode 文字への対応修正などが掲載されています。(Microsoft Learn)
ただし、バージョン情報は頻繁に更新されます。この記事を読んだ時点の最新バージョンと、実際に展開されている VM のバージョンが一致するとは限りません。自動ロールアウトは段階的に行われるため、同じサブスクリプション内でも VM によってバージョン差が発生することがあります。(Microsoft Learn)
運用では、次の 3 点を定期確認するとよいでしょう。
| 確認項目 | 判断基準 |
|---|---|
| AMA バージョン | 過去 1 年以内のサポート対象か |
| 自動更新 | Automatic Extension Update が有効か |
| 既知の修正 | 自社に関係する OS、ログ種別、ネットワーク条件の修正が含まれるか |
開発者・SREが見るべきポイント
開発者や SRE にとって、Azure Monitor Agent Overview の重要性は「インフラ担当向けのエージェント説明」にとどまりません。ログ設計、障害調査、コスト最適化、セキュリティ監査に直接関係します。
たとえば、アプリケーション障害時に「OS 側の CPU 使用率」「プロセスの異常」「Windows イベント」「Syslog」「IIS ログ」を横断して調べたい場合、AMA と DCR が正しく構成されていないと必要なデータが Log Analytics に存在しません。KQL の書き方以前に、収集設計が不足している状態です。
開発者・SRE が確認すべき観点は次の通りです。
| 観点 | 確認すること |
|---|---|
| 障害調査 | アプリログだけでなく OS ログやパフォーマンスデータが取れているか |
| コスト | 不要な高頻度カウンターや全イベント収集をしていないか |
| セキュリティ | 機密情報をログに残さないよう DCR 変換を使えるか |
| 可観測性 | Sentinel、Application Insights、Azure Monitor Logs のどこで見るか整理されているか |
| 検証 | Heartbeat や対象テーブルへのデータ到着を KQL で確認しているか |
特にカスタムログや変換を使う場合、Azure portal で DCR を編集すると、JSON で直接追加した一部の高度な設定が上書きされる可能性があります。変換などポータルで未対応の機能を使っている場合は、DCR の編集方法をチーム内で統一する必要があります。(Microsoft Learn)
コスト面で見るべきポイント
Azure Monitor Agent 自体に利用料金はありません。ただし、収集して取り込み、保存するデータには料金が発生する可能性があります。つまり、コストを左右するのはエージェントではなく、DCR で収集するデータ量、送信先、保持期間、重複送信の有無です。(Microsoft Learn)
よくあるコスト増の原因は、次の 4 つです。
| 原因 | 例 | 対策 |
|---|---|---|
| 二重取り込み | MMA と AMA が同じイベントを送信 | 移行中の収集経路を明確にする |
| 過剰なイベント収集 | すべての Windows イベントを収集 | 必要なログ、イベント ID、重大度に絞る |
| 高頻度カウンター | 短すぎる間隔で多数のパフォーマンスカウンターを収集 | 障害検知に必要な粒度へ調整する |
| 複数宛先への重複送信 | 同じデータを複数ワークスペースへ送る | 宛先別 DCR を整理し、目的を明確にする |
DCR のベストプラクティスでは、監視スコープ、データソース、宛先を意識して DCR を分けることが推奨されています。これは管理しやすさだけでなく、不要データの取り込みを抑えるコスト対策にもなります。(Microsoft Learn)
すぐに実施すべきチェックリスト
Azure Monitor Agent Overview を読んだ後、管理者が最初に行うべきことは、次のチェックです。
| チェック項目 | 実施内容 |
|---|---|
| 旧エージェント確認 | Log Analytics agent、MMA、OMS agent が残っていないか確認する |
| AMA 展開状況 | Azure VM、VMSS、Arc 対応サーバーに AMA が導入されているか確認する |
| DCR 関連付け | 対象 VM に適切な DCR が関連付いているか確認する |
| データ到着確認 | Heartbeat、イベント、Syslog、パフォーマンスデータを KQL で確認する |
| ネットワーク | 443 アウトバウンド、サービス タグ、Private Link、DCE を確認する |
| ID | マネージド ID の種類と権限を確認する |
| コスト | 重複取り込みと不要データ収集を確認する |
| 自動更新 | AMA の自動更新を有効化する |
| 移行計画 | パイロット、検証、本番展開、旧エージェント削除の順に進める |
Azure Monitor Agent は、単なる監視エージェントの置き換えではありません。DCR を中心に、収集データ、送信先、コスト、セキュリティ、ハイブリッド管理を再設計するための基盤です。
まずは既存環境のエージェントとワークスペースを棚卸しし、パイロット VM で DCR による収集を検証しましょう。そのうえで、Azure Policy や IaC による自動展開、自動更新、旧 Log Analytics agent の削除まで進めると、Azure Monitor の監視基盤を安定して移行できます。
コメント