Azure Monitor Agentのインストールと管理でまず押さえるべき結論は、「エージェントを入れる作業」ではなく「DCRで何を集め、どこへ送るかを設計する作業」へ運用の中心が移っているという点です。Azure VM、仮想マシン スケール セット、Azure Arc対応サーバーを監視する場合、Azure Monitor Agentの導入、DCRの関連付け、更新方式、ネットワーク、旧エージェントからの移行をセットで確認する必要があります。
2026年5月15日更新の対応OS情報と、同月更新の「Install and manage the Azure Monitor Agent」公式情報を踏まえると、管理者がすぐ確認すべきポイントは、対応OS、Azure Arcの前提、マネージドID、DCR関連付け、Azure Policyによる展開、Heartbeatでの疎通確認、旧Log Analytics agentやWAD/LADとの二重取り込み防止です。(Microsoft Learn)
Azure Monitor Agentのインストール管理で何が変わるのか
Azure Monitor Agentは、Azure MonitorでゲストOSのログやパフォーマンスデータを収集するためのサポート対象エージェントです。従来のLog Analytics agentを利用している環境では、Azure Monitor Agentへの移行を前提に運用設計を見直す必要があります。(Microsoft Learn)
特に重要なのは、Azure Monitor AgentがData Collection Rules（DCR）に基づいてデータを収集する点です。DCRは「何を収集するか」「どう加工するか」「どの宛先へ送るか」を定義します。つまり、Azure Monitor Agentをインストールしただけでは、期待したログやメトリックが自動的にすべて送信されるとは限りません。(Microsoft Learn)
| 確認項目 | 実務での意味 | 見落とすと起きること |
|---|---|---|
| DCRの作成・関連付け | 収集対象と送信先を決める中心設定 | エージェントは入っているのにデータが出ない |
| Azure Policy | 既存・新規VMへ自動展開する仕組み | 新規VMだけ監視漏れになる |
| マネージドID | Azure Monitor Agentの認証方式 | 大量展開時にID管理が煩雑になる |
| ネットワーク要件 | DCR取得・ログ送信に必要な通信 | Private Linkやプロキシ環境でデータ欠落が起きる |
| 旧エージェント移行 | Log Analytics agentやWAD/LADからの切り替え | 二重取り込みによるコスト増、監視の重複 |
| 更新方式 | 自動更新か手動更新かを決める | 古いバージョンが残り、サポート範囲外になる |
Azure Monitor AgentはDCRとセットで考える
Azure Monitor Agentの運用では、エージェント本体とDCRを分けて理解すると失敗しにくくなります。
エージェントは、VMやAzure Arc対応サーバー上でローカルのイベントログ、Syslog、パフォーマンスデータ、ファイルベースのログなどにアクセスします。一方でDCRは、収集対象、変換、送信先をAzure側で一元管理する設定です。DCRはAzureリソースとして管理され、インフラ構成管理やDevOpsプロセスにも組み込みやすい設計です。(Microsoft Learn)
DCRベースの運用では、たとえば次のような設計ができます。
| シナリオ | DCRで決めること | 実務上のメリット |
|---|---|---|
| Windowsイベントログを収集 | System、Application、Securityなどの対象ログ | 必要なログだけ送信し、分析しやすくする |
| Linux Syslogを収集 | facility、severity、送信先ワークスペース | サーバー種別ごとに収集レベルを分けられる |
| パフォーマンスカウンターを収集 | CPU、メモリ、ディスク、収集間隔 | コストと可視性のバランスを調整できる |
| カスタムログを収集 | ファイルパス、スキーマ、送信先テーブル | アプリ固有ログをLog Analyticsで扱える |
| 取り込み前に変換 | 不要データの除外、形式調整、機密情報の除去 | 取り込み量の削減やデータ品質向上につながる |
DCRの変換機能は、受信データを保存前にフィルター、加工、宛先スキーマへ整形できるため、ログ量の多い環境ではコスト管理にも関わります。すべてを収集してからクエリで絞るのではなく、最初から「監視に必要なシグナル」を設計するのがポイントです。(Microsoft Learn)
インストール方法は環境規模と運用方式で選ぶ
公式ドキュメントでは、Azure Monitor Agentの導入方法として、VM拡張機能、DCR作成、VM insights、Container insights、Windowsクライアント向けインストーラー、Azure Policyなどが整理されています。特にAzure外のサーバーでは、Azure Monitor Agentを入れる前にAzure Arc agentが必要です。(Microsoft Learn)
| 方法 | 向いている環境 | 注意点 |
|---|---|---|
| AzureポータルでDCRを作成 | 小規模環境、初回検証 | DCRに追加したマシンへエージェントが導入され、DCR定義に沿って収集が始まる |
| VM拡張機能 | 個別VM、スクリプト運用 | VM拡張機能だけではDCRは作成されないため、別途DCR関連付けが必要 |
| VM insights | VMの標準的な可視化を始めたい場合 | 事前定義のDCRが作成されるため、直接変更せず追加DCRで拡張する |
| Container insights | KubernetesのログやPrometheusメトリック収集 | コンテナ化されたAzure Monitor Agentがクラスターに導入される |
| Windowsクライアント用MSI | Windows 10、Windows 11端末 | サーバーVM拡張機能とは導入経路が異なる |
| Azure Policy | 大規模環境、継続的な監視統制 | 既存VMと新規VMの両方に展開しやすい |
| ARMテンプレート | IaC、厳密な構成管理 | DCRは関連付け前に作成しておく必要がある |
大規模環境では、手作業でVMごとにインストールするよりも、Azure PolicyやIaCを使って「エージェント導入」と「DCR関連付け」を標準化する方が安全です。公式ドキュメントでも、Azure Policyを使うと既存および新規のAzure VM、仮想マシン スケール セット、Azure Arc対応サーバーに対してAzure Monitor AgentとDCR関連付けを自動化できると説明されています。(Microsoft Learn)
展開前に確認すべき前提条件
Azure Monitor Agentの導入前には、対象OS、認証、ネットワーク、ディスク容量を確認します。対応OSはx64が前提で、x86はサポートされません。Windows 10やWindows 11クライアント端末では、Windowsクライアント向けインストーラーを使う点にも注意が必要です。(Microsoft Learn)
対象サーバーとAzure Arc
オンプレミスや他クラウドのサーバーをAzure Monitor Agentで監視する場合は、Azure Arc-enabled serversとしてAzureに接続する必要があります。Azure Arc agentはインストールの土台になり、Azure Monitor AgentはマネージドIDを使って認証します。(Microsoft Learn)
実務では、次の順で確認すると抜け漏れを減らせます。
| 確認対象 | 確認内容 |
|---|---|
| Azure VM | 対応OS、VM拡張機能の導入権限、DCR関連付け |
| VM Scale Sets | アップグレードポリシー、既存インスタンスへの反映方法 |
| オンプレミスサーバー | Azure Arc agent導入状況、Arcリソースとしての表示 |
| 他クラウドVM | Arc接続、ネットワーク疎通、対象OS |
| Windowsクライアント | MSIインストーラー利用、DCR関連付け方法 |
マネージドIDの選び方
Azure VMや仮想マシン スケール セットでは、ユーザー割り当てマネージドIDとシステム割り当てマネージドIDを使い分けます。小規模な検証ではシステム割り当てでも始められますが、大規模展開ではユーザー割り当てマネージドIDの方がスケーラブルです。一方、Azure Arc対応サーバーではシステム割り当てマネージドIDのみがサポートされます。(Microsoft Learn)
| 環境 | 推奨しやすいID | 判断基準 |
|---|---|---|
| 少数のAzure VM | システム割り当て | 検証や小規模運用で管理を簡単にしたい場合 |
| 多数のAzure VM/VMSS | ユーザー割り当て | サブスクリプション単位、リージョン単位で標準化したい場合 |
| Azure Policy展開 | ユーザー割り当て | ポリシー主導で大規模に導入する場合 |
| Azure Arc対応サーバー | システム割り当て | Arcではこの方式が前提 |
ネットワークとPrivate Link
Azure Monitor Agentは、DCR取得、ログ送信、メトリック送信のためにAzure Monitor関連エンドポイントへ通信します。ネットワーク制御では、AzureMonitorとAzureResourceManagerのサービス タグが必要で、ファイアウォールではアウトバウンド443番ポートの許可が前提です。また、HTTPSインスペクションは無効化する必要があります。(Microsoft Learn)
Private Linkを使う環境では、DCRがData Collection Endpoint（DCE）を使う構成かどうかを確認してください。Azure Monitor Private Link Scopeを使う場合、DCR側でもDCE利用が必要になります。プロキシ構成やLog Analytics gatewayを使う環境でも、Azure Arc対応サーバーでは一部の接続方式がサポートされないため、ネットワーク方式を先に決めてから展開するのが安全です。(Microsoft Learn)
Azure Monitor Agentの基本的な展開手順
Azure Monitor Agentは複数の方法で導入できますが、実務では次の流れで進めると失敗しにくくなります。
| 手順 | 作業 | 確認ポイント |
|---|---|---|
| 1 | 対象リソースを棚卸しする | Azure VM、VMSS、Arc対応サーバー、OS、既存エージェント |
| 2 | 収集要件を整理する | イベントログ、Syslog、性能情報、カスタムログ、送信先 |
| 3 | DCRを作成する | 収集対象、変換、宛先、リージョン |
| 4 | インストール方式を選ぶ | ポータル、Azure CLI、PowerShell、ARM、Azure Policy |
| 5 | DCRを関連付ける | 対象リソースにDCRAが作成されているか |
| 6 | Heartbeatで確認する | Azure Monitor Agentからデータが届いているか |
| 7 | 旧エージェントを整理する | 二重収集がないか、移行後に削除できるか |
Azureポータルから導入する場合は、DCR作成を起点にする方法が推奨されています。Azure CLIやPowerShellでVM拡張機能として導入する場合は、WindowsではAzureMonitorWindowsAgent、LinuxではAzureMonitorLinuxAgentを使います。(Microsoft Learn)
インストール、アップグレード、アンインストールでは、マシンの再起動は不要です。ただし、後述するAgentSettings DCRの変更適用では、Azure Monitor Agent自体の再起動が必要になるため、「OS再起動不要」と「エージェント再起動不要」を混同しないようにしてください。(Microsoft Learn)
インストール後はHeartbeatで必ず確認する
Azure Monitor Agentの導入後は、拡張機能の状態だけでなく、Log Analyticsワークスペースにデータが届いているかを確認します。公式ドキュメントでは、Azureポータルで拡張機能がProvisioning succeededになっていることを確認し、さらにHeartbeatテーブルでAzure Monitor Agentのハートビートを確認する方法が示されています。(Microsoft Learn)
Heartbeat
| where Category == "Azure Monitor Agent"
| where TimeGenerated > ago(5m)
| project Computer, TimeGenerated, Category, OSType
| order by TimeGenerated descこのクエリで結果が出れば、Azure Monitor AgentがLog Analyticsワークスペースへデータを送信できています。インストール直後は最初のHeartbeatが表示されるまで数分かかることがあります。結果が出ない場合は、エージェントの有無だけでなく、DCRが対象マシンに関連付けられているかを確認してください。(Microsoft Learn)
Azure CLIで拡張機能の状態を確認する場合は、Azure VMでは次のように確認します。
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更新管理では自動アップグレードを前提にする
Azure Monitor Agentは、最新版への更新または自動拡張機能アップグレードの有効化が推奨されています。自動更新は安全なロールアウトのため段階的に配布されるため、すべてのVMやArc対応サーバーが同時に更新されるとは限りません。緊急で更新したい場合は、手動更新の手順を使う必要があります。また、過去1年以内にリリースされたエージェントのみがサポート対象とされています。(Microsoft Learn)
VM Scale Setsでは、アップグレードポリシーに注意が必要です。手動アップグレードポリシーの場合、VMSSモデルを更新しただけでは既存インスタンスへ反映されないため、既存インスタンスの更新操作が必要です。AutomaticまたはRollingの場合は、自動的にインスタンスへ適用されます。(Microsoft Learn)
運用ルールとしては、次のように分けると管理しやすくなります。
| 環境 | 更新方針 |
|---|---|
| 検証環境 | 自動更新を有効化し、更新影響を早めに確認 |
| 本番環境 | 自動更新を基本にしつつ、監視アラートや主要クエリを更新後に確認 |
| 厳格な変更管理環境 | 自動更新の可否を社内ルールで整理し、必要に応じて手動更新手順を定義 |
| VMSS | アップグレードポリシーと既存インスタンスへの反映方法を明文化 |
AgentSettings DCRはプレビュー機能として慎重に扱う
Azure Monitor Agentの一部パラメーターは、AgentSettings DCRで構成できます。ただし、現時点ではプレビュー扱いで、Azure Resource Managerテンプレートでのみ設定可能です。また、AgentSettingsは他の設定と混在しない単一DCRである必要があり、対象VMとAgentSettings DCRは同じリージョンに配置する必要があります。(Microsoft Learn)
現在サポートされている主なパラメーターは次のとおりです。
| パラメーター | 用途 | 注意点 |
|---|---|---|
MaxDiskQuotaInMB | 送信できないデータをローカルキャッシュする際のディスク使用量を制御 | Linux/Windowsともに指定範囲を守る |
UseTimeReceivedForForwardedEvents | Microsoft SentinelのWindows Event ForwardingでTimeGeneratedではなくTimeReceivedを使う | 値は0または1 |
ログ送信が一時的に止まる可能性がある環境では、MaxDiskQuotaInMBの設定が重要になります。ただし、キャッシュを大きくすればよいわけではありません。ディスク容量、ログ量、障害時の保持要件、復旧後の送信負荷を合わせて考える必要があります。
Linux環境では自動作成ユーザーを削除しない
LinuxにAzure Monitor Agentをインストールすると、エージェントのコンポーネントを安全に実行するためのローカルユーザーが作成されます。代表的なものに、ログやメトリック収集用のazuremonitoragent、OpenTelemetry Collector用のazureotelcollector、Metrics Extension用のazuremetricsextがあります。これらのアカウントを削除または変更すると、エージェントが正常に動作しなくなる可能性があります。(Microsoft Learn)
また、Azure Arc対応サーバーでは、Azure Connected Machine Agentと拡張機能フレームワークによりhimds、arcproxy、arcuserなどの追加アカウントが作成されることがあります。これはAzure Monitor Agent単体が作成するものではないため、Linuxのローカルユーザー棚卸しでは役割を分けて確認してください。(Microsoft Learn)
旧エージェントから移行する場合の進め方
Log Analytics agent、Microsoft Monitoring Agent（MMA）、Operations Management Suite（OMS）agentを使っている環境では、Azure Monitor Agentへの移行を計画します。公式ドキュメントでは、現在の環境評価、DCRによるAzure Monitor Agent展開、データ収集の検証、旧Log Analytics agentの削除という流れが示されています。(Microsoft Learn)
移行では、最初から全台へ展開しないことが重要です。まず小さなパイロットグループを選び、DCR Config Generatorで既存のワークスペースベース設定をDCRへ変換し、旧エージェントとのデータ差分を確認します。テスト中は二重取り込みを避けるため、パイロットサーバーではLog Analytics agentのワークスペース構成を外すなど、収集経路を明確にします。(Microsoft Learn)
| フェーズ | 実施内容 | 判断基準 |
|---|---|---|
| 棚卸し | 旧エージェント、ワークスペース、依存サービスを確認 | 何を移行すべきか分かる状態 |
| DCR設計 | 既存収集設定をDCRへ置き換える | 収集対象と宛先が明文化されている |
| パイロット展開 | 少数のサーバーへAzure Monitor Agentを導入 | Heartbeatと主要ログが届いている |
| 差分確認 | 旧エージェントとAzure Monitor Agentのデータを比較 | イベント、Syslog、性能値、カスタムログに欠落がない |
| 本番展開 | Azure Policyなどで段階的に拡大 | 新規VMにも自動適用される |
| 旧エージェント削除 | 検証後にLog Analytics agentを削除 | 二重取り込みと余計なコストを防げている |
WAD/LAD、つまりAzure Diagnostics extensionsを使っている環境も注意が必要です。公式情報ではWAD/LADは2026年3月31日に非推奨化・廃止とされ、移行先の選択肢としてAzure Monitor AgentとDCRが示されています。移行後は、データの同等性を確認してからWAD/LADを停止または削除し、二重取り込みによるコスト増を避けます。(Microsoft Learn)
開発者が確認すべきポイント
開発者がAzure Monitor Agentを利用する場合、単に「ログがLog Analyticsに届くか」だけでなく、アプリケーションログの形式、カスタムテーブル、DCR変換、クエリ、アラートまで一体で確認する必要があります。
特にカスタムログでは、ファイルパス、レコード区切り、時刻形式、テーブルスキーマがずれると、ログが欠落したり、意図しない形式で保存されたりします。WAD/LADから移行する場合も、WindowsとLinuxを同じDCRへ雑にまとめると、カウンター名やログ形式の違いで重複や誤集計が起きやすくなります。(Microsoft Learn)
開発チーム側では、次の項目を事前に決めておくと運用チームとの認識違いを減らせます。
| 項目 | 決めること |
|---|---|
| アプリログ | 収集するファイル、ローテーション方式、ログ形式 |
| エラー判定 | どの文字列・ステータスをアラート対象にするか |
| 個人情報・機密情報 | 収集前に除外・マスクすべき項目 |
| 保存先 | 既存テーブルかカスタムテーブルか |
| コスト | 収集頻度、ログ量、保持期間 |
| ダッシュボード | 移行後も同じKQLで見えるか |
よくある失敗と対策
Azure Monitor Agentの導入でよくある失敗は、技術的なインストールミスよりも、DCRや移行計画の抜け漏れに起因します。
| 失敗例 | 原因 | 対策 |
|---|---|---|
| エージェントは入ったがデータが出ない | DCRが関連付けられていない | DCRAを確認し、Heartbeatを実行 |
| 新規VMだけ監視されていない | 手動導入で標準化していない | Azure Policyで自動展開 |
| コストが急増した | 旧エージェントとAMAの二重取り込み | パイロット検証後に旧構成を停止 |
| Private Link環境で収集できない | DCEやエンドポイント許可が不十分 | DCR、DCE、Private Link Scopeを確認 |
| Linuxで突然動かない | エージェント用ローカルユーザーを削除 | azuremonitoragentなどを変更しない |
| VMSSの一部だけ古い | 手動アップグレードポリシーで既存インスタンス未更新 | update-instances相当の反映作業を実施 |
| 強化Linuxで通信できない | FUTURE暗号化ポリシーなどが影響 | サポートされるハードニング条件を確認 |
Linuxでは、システム全体の暗号化ポリシーをFUTUREに設定しているとAzure Monitor Agentが動作しないとされています。また、過度にカスタマイズされたディストリビューションや、ユーザーによるOS変更が制限されるアプライアンス型環境はサポート対象外となる場合があります。(Microsoft Learn)
まず実施すべき確認リスト
Azure Monitor Agentをこれから展開・移行する管理者は、次の順で確認してください。
| 優先度 | 確認内容 | 完了条件 |
|---|---|---|
| 高 | 対象VMと既存エージェントを棚卸し | Log Analytics agent、WAD/LAD、AMAの有無が分かる |
| 高 | 対応OSとAzure Arc要件を確認 | 対象サーバーがAMA導入可能と判断できる |
| 高 | DCRを設計 | 収集対象、変換、宛先が決まっている |
| 高 | Azure Policyの利用可否を決める | 新規VMも自動的に監視対象へ入る |
| 中 | ネットワーク要件を確認 | 443番、サービス タグ、DCE、Private Linkが整理済み |
| 中 | Heartbeat確認手順を用意 | 展開後に正常性を即確認できる |
| 中 | 移行時の二重取り込み対策 | 旧エージェント停止・削除の条件が決まっている |
| 低 | AgentSettings DCRの必要性を判断 | キャッシュ容量やWEF時刻列の要件が明確 |
Azure Monitor Agentの導入は、1台のVMであれば難しくありません。しかし本番環境では、DCR、Azure Policy、マネージドID、ネットワーク、旧エージェント移行が絡むため、最初に設計を固めることが重要です。
次に取るべき行動は、既存環境の棚卸しです。まずは対象VM、OS、旧エージェント、Log Analyticsワークスペース、収集しているログ種別を一覧化し、小さなパイロット環境でAzure Monitor AgentとDCRを検証してください。そのうえで、Azure PolicyやIaCを使って標準化すれば、監視漏れと移行時のトラブルを大きく減らせます。
コメント