Azure Monitorで仮想マシンのログデータを収集する場合、いま確認すべき中心は「Azure Monitor Agent（AMA）を個別に入れるか」ではなく、データ収集ルール（DCR）を作成し、対象VM・VMスケールセット・Azure Arc対応サーバーに関連付ける設計になっているかです。2026年5月の公式ドキュメント更新では、AzureポータルでDCRを作成してVMリソースを追加する方法が、AMAを導入する推奨手順として明確化されています。DCRにVMを追加すると、必要に応じてAMAが自動的にインストールされ、DCRと各VMの関連付けも作成されます。(GitHub)
この記事では、Azure Monitorの「Collect log data from virtual machines with Azure Monitor」で何を読み取るべきかを、管理者・開発者向けに整理します。対象範囲、変更点、既存環境への影響、DCR・DCE・Log Analytics workspace・マネージドIDの確認ポイント、Log Analytics agentからの移行時に失敗しやすい点まで、実務でそのまま点検できる形で解説します。
Azure Monitorの仮想マシンログ収集は「AMA + DCR」が基本になる
Azure Monitorは、Azure VM、Virtual Machine Scale Sets、Azure Arc対応サーバーからホストメトリックやアクティビティログを自動的に収集できます。ただし、ゲストOSやアプリケーションの詳細なログ、たとえばWindowsイベントログ、Linux Syslog、IISログ、カスタムテキストログなどは、標準では十分に集まりません。これらを収集するには、Azure Monitor Agentとデータ収集ルールを使って、どのデータをどこへ送るかを定義する必要があります。(Microsoft Learn)
今回のポイントは、ログ収集の入口が「エージェントを先に手作業で入れる」よりも、DCRを作成して対象リソースを追加する運用に寄っていることです。AzureポータルでDCRを作成し、VMをリソースとして追加すると、必要に応じてAzure Monitor Agentが自動的にインストールされ、DCRとの関連付けも作成されます。(Microsoft Learn)
これは新しいログ種別が大量に増えたというより、運用手順と責任範囲が分かりやすく整理された更新です。管理者は「AMAが入っているか」だけでなく、「正しいDCRが関連付いているか」「DCRの送信先やデータソースが適切か」まで確認する必要があります。
何が変わるのか：実務上の変更点
2026年5月のMicrosoftDocs上の更新では、AzureポータルでDCRを作成することがAMA導入の推奨方法であり、DCRにリソースを追加するとAMAの自動インストールとDCR関連付けが行われる、という説明が補強されました。GitHub上の公式ドキュメント履歴でも、この更新は「AzureポータルでのAMAインストール説明を改善する」趣旨で、data-collection.mdとazure-monitor-agent-manage.mdの両方に反映されています。(GitHub)
実務での影響は、次の3点です。
| 確認項目 | これまで起きがちな運用 | 今後の推奨される見方 |
|---|---|---|
| AMAの導入 | 拡張機能としてAMAを個別に入れて終わりにする | DCR作成・リソース追加・関連付けまでを一連の設定として確認する |
| ログ収集設定 | ワークスペース側やエージェント側の設定だけを見る | DCRのデータソース、送信先、DCRAを確認する |
| 展開方法 | 手作業でVMごとに設定する | 小規模ならポータル、大規模ならAzure PolicyやIaCでDCR関連付けを展開する |
特に注意したいのは、AMAがインストールされていても、DCRが関連付いていなければ期待したログは収集されない点です。AMAは、関連付けられたDCRを取得し、その内容に従ってデータを収集します。DCRは「何を集めるか」「どう加工するか」「どこへ送るか」を定義する設定リソースです。(Microsoft Learn)
対象になるリソース
対象になるのは、主に次のリソースです。
| 対象 | 確認ポイント |
|---|---|
| Azure Virtual Machines | Windowsイベントログ、パフォーマンスカウンター、IISログ、カスタムログなどの収集対象をDCRで定義する |
| Virtual Machine Scale Sets | スケールセット全体の運用方針と、インスタンスへの適用タイミングを確認する |
| Azure Arc-enabled servers | オンプレミスや他クラウド上のサーバーをAzure管理下に置き、AMAとDCRで収集する |
| Windows Server / Windows Client | Windowsイベント、IISログ、Windows Firewall logsなどの対象を確認する |
| Linuxサーバー | Syslog、パフォーマンス、テキストログ、JSONログ、SNMP trapsなどを確認する |
Azure以外のサーバーでは、AMAを入れる前にAzure Arc Connected Machine agentを導入し、Azure上で管理対象リソースとして扱える状態にする必要があります。(Microsoft Learn)
また、フレキシブル オーケストレーションのVirtual Machine Scale Setsは、DCRのリソースとしてスケールセットそのものを追加するのではなく、含まれる各VMを追加する扱いになる点に注意が必要です。(Microsoft Learn)
収集できる主なログデータと送信先
公式ドキュメントでは、VMクライアントから収集できるデータソースとして、Windows events、Performance counters、OpenTelemetry metrics、Syslog、Text log、JSON log、IIS logs、SNMP traps、Windows Firewall logsなどが整理されています。送信先はデータソースによって異なりますが、多くのログはLog Analytics workspaceへ送信します。(Microsoft Learn)
| データソース | 主な対象OS | 主な送信先 | よくある用途 |
|---|---|---|---|
| Windows events | Windows | Log Analytics workspace | アプリケーション障害、OSエラー、セキュリティ関連イベントの調査 |
| Syslog | Linux | Log Analytics workspace | Linuxサーバーの認証、サービス、システムログ監視 |
| Performance counters | Windows / Linux | Log Analytics workspace、Azure Monitor metricsなど | CPU、メモリ、ディスク、プロセス関連の傾向分析 |
| Text log | Windows / Linux | Log Analytics workspace | 独自アプリケーションのテキストログ収集 |
| JSON log | Windows / Linux | Log Analytics workspace | 構造化されたアプリケーションログの収集 |
| IIS logs | Windows | Log Analytics workspace | Webサーバーのアクセスログ、障害調査 |
| Windows Firewall logs | Windows | Log Analytics workspace | 通信許可・拒否ログの確認 |
| SNMP traps | Linux | Log Analytics workspace | ネットワーク機器や監視対象からのトラップ収集 |
ここで重要なのは、「何でも全部集める」ではなく、目的に合わせてDCRを分けることです。たとえば、障害調査用のWindowsイベントログ、性能監視用のパフォーマンスカウンター、セキュリティ監査用のログを同じDCRにまとめすぎると、後から変更範囲が分かりにくくなります。
管理者が最初に確認すべき設定
Azure MonitorでVMログ収集を運用している管理者は、次の順番で確認すると抜け漏れを減らせます。
| 順番 | 確認するもの | 見るべきポイント |
| -: | ———————– | —————————— |
| 1 | Log Analytics workspace | 送信先ワークスペース、リージョン、権限、保持期間、コスト管理 |
| 2 | DCR | 収集するデータソース、送信先、変換、命名規則 |
| 3 | DCRA | 対象VM・ArcサーバーとDCRの関連付け |
| 4 | AMA | 拡張機能の状態、バージョン、自動更新の有無 |
| 5 | マネージドID | システム割り当てかユーザー割り当てか |
| 6 | DCE | Private Linkや特定データソースで必要か |
| 7 | 重複収集 | 同じデータを複数DCRや旧エージェントで収集していないか |
DCRのリージョンは、送信先として使うLog Analytics workspaceまたはAzure Monitor workspaceと同じリージョンにする必要があります。ワークスペースが複数リージョンに分かれている場合は、同じVM群に対して複数のDCRを作成する設計が必要になります。(Microsoft Learn)
また、DCRを作成するには、Log Analytics workspaceへの共同作成者相当の権限やDCRオブジェクトを作成する権限が必要です。テナントをまたいでデータを送る場合は、Azure Lighthouseの有効化も前提になります。(Microsoft Learn)
DCRを設計するときの判断基準
DCRは便利ですが、無計画に増やすと管理しづらくなります。おすすめは、次の単位で分ける考え方です。
| 分け方 | 向いているケース | 注意点 |
|---|---|---|
| OS別 | WindowsとLinuxで収集対象が大きく異なる | 共通ルールにしすぎると不要な項目が増える |
| 用途別 | 障害調査、性能監視、セキュリティ監査を分けたい | 同じログを重複収集しないよう確認する |
| 環境別 | 本番、検証、開発で保持期間や送信先を変えたい | 命名規則を決めないとDCRが乱立する |
| リージョン別 | ワークスペースが複数リージョンにある | 同じVM群に複数DCRを関連付ける場合は重複に注意 |
| アプリ別 | 特定アプリのカスタムログだけ収集したい | アプリ更新でログパスや形式が変わると収集漏れが起きる |
DCRは1つのVMに複数関連付けできます。公式ドキュメントでは、DCRAは多対多の関係で、1つのリソースに最大30個のDCRを関連付けられると説明されています。(Microsoft Learn)
ただし、最大数まで使えることと、使うべきことは別です。実務では、1台のVMに多くのDCRが関連付いていると、どのルールがどのログを収集しているのか追いにくくなります。運用しやすい目安としては、まず「共通監視」「OS別ログ」「アプリ固有ログ」「セキュリティ系ログ」程度に整理し、必要になった時だけ追加する方が安全です。
AzureポータルでDCRを作るときの注意点
AzureポータルでDCRを作成する場合、MonitorメニューからData Collection Rulesを開き、Createを選択して作成します。基本的なログ収集であれば、ポータル上でDCRの作成、VMの追加、データソースと送信先の設定まで進められます。(Microsoft Learn)
ただし、ポータル編集には重要な注意点があります。DCRのJSONを直接編集して、ポータルが対応していない高度な変換などを設定している場合、その後にAzureポータルから同じDCRを編集すると、ポータルでサポートされていない設定が上書き・削除される可能性があります。(Microsoft Learn)
実務では、次のように運用を分けると事故を防ぎやすくなります。
| DCRの種類 | 推奨する編集方法 |
|---|---|
| 標準的なWindowsイベント、Syslog、IISログ収集 | Azureポータルで管理 |
| 変換、複雑なデータフロー、IaC管理が必要なDCR | JSON、ARM/Bicep、Terraform、Azure CLIなどに統一 |
| Azure Policyで大量展開するDCR | ポータルで手直しせず、定義ファイル側で変更 |
| 検証中のDCR | 本番DCRと分けて作成し、名前で用途を明確化 |
ポータルで少し直しただけのつもりが、JSONで入れていた変換を消してしまうと、コスト削減のために除外していたログが再び取り込まれる、機密性の高い列が保存される、スキーマが変わるといった問題につながります。
マネージドIDの扱いに注意する
DCRにリソースを追加するとき、Azureポータルの既定では対象リソースにシステム割り当てマネージドIDを有効化する動きがあります。既存アプリケーションでユーザー割り当てマネージドIDを利用している場合、DCR追加時に明示しないと、DCRによって適用されたシステム割り当てIDを使う状態になる可能性があります。(Microsoft Learn)
これは、監視チームだけで完結しない論点です。アプリケーションがKey Vault、Storage、SQL Databaseなどへユーザー割り当てIDでアクセスしている環境では、インフラ管理者と開発者が次の点を確認してください。
| 確認項目 | 具体的な確認内容 |
|---|---|
| 既存IDの利用状況 | VMやアプリがユーザー割り当てIDを使っているか |
| DCR追加時のID設定 | システム割り当てIDが意図せず有効になっていないか |
| 権限の付与範囲 | 監視用IDに過剰な権限を与えていないか |
| 変更後の動作 | アプリケーションの認証やデプロイに影響が出ていないか |
監視設定は「ログを集めるだけ」と見られがちですが、ID設定を変更する場合はセキュリティ設計に影響します。特に本番VMでは、DCR適用前後のマネージドID状態を記録しておくと、トラブル時の切り戻しが容易です。
DCEが必要なケースを見極める
Data Collection Endpoint（DCE）は、Azure Monitorのデータ収集、構成取得、取り込みに関するエンドポイントを定義するAzureリソースです。ただし、すべてのAMAログ収集でDCEが必須になるわけではありません。AMAは既定ではパブリックエンドポイントを使ってAzure Monitorから構成を取得し、DCEが必要になる代表的なケースはPrivate Linkを使う場合です。(Microsoft Learn)
また、特定のデータソースではDCEが必要です。公式ドキュメントでは、Windows Firewall LogsやPrometheus Metrics（Container Insights）がDCEを必要とするデータソースとして挙げられています。(Microsoft Learn)
判断基準はシンプルです。
| 状況 | DCEの要否 |
|---|---|
| 通常のWindowsイベントやSyslogをパブリック経由で収集 | 多くの場合、DCEは不要 |
| Azure Monitor Private Link Scopeを使っている | DCEが必要 |
| Private Link構成のLog Analytics workspaceへ送信 | DCEとAMPLSの関連を確認 |
| Windows Firewall LogsをDCRで収集 | DCE要否を確認 |
| 複数リージョンのVMとワークスペースがある | 構成取得用・取り込み用のDCE配置を設計 |
DCEを誤って省略すると、エージェントは入っているのに設定を取得できない、または特定データソースだけ収集されないといった分かりにくい障害になります。Private Linkを使う環境では、ネットワーク担当者とAzure管理者がDNS、AMPLS、DCE、DCRの関係を一緒に確認してください。
Log Analytics agentから移行中の環境で確認すべきこと
Log Analytics agent、別名MMAまたはOMS agentを使っている環境では、Azure Monitor Agentへの移行が重要です。Microsoftの公式ドキュメントでは、Log Analytics agentは2024年8月31日に廃止されており、2026年3月2日以降はLog Analytics agentからのデータアップロードが予告なく停止する可能性があると説明されています。(Microsoft Learn)
移行中の環境では、次の順番で作業すると安全です。
| 手順 | 作業内容 | 失敗しやすいポイント |
| -: | ——————————– | ————————————- |
| 1 | 現在のLog Analytics agent利用状況を棚卸しする | 使っていないと思っていたワークスペースやソリューションが残っている |
| 2 | 収集しているデータソースを洗い出す | Windowsイベント、Syslog、IIS、カスタムログの差分を見落とす |
| 3 | DCR Config GeneratorなどでDCR化を検討する | 自動変換後のDCRを検証せず本番展開する |
| 4 | 小規模なパイロットVMにAMAとDCRを適用する | いきなり全台展開してログ形式や量の差に気付く |
| 5 | Heartbeatと各テーブルの件数を比較する | AMAのHeartbeatだけ見て、実ログの欠落を見逃す |
| 6 | 重複収集を止める | Log Analytics agentとAMAの両方が同じデータを送る |
| 7 | 問題がなければ旧エージェントを削除する | SCOM管理対象など例外を消してしまう |
公式の移行手順でも、移行前の棚卸し、DCRの生成、パイロット展開、データ収集の検証、Log Analytics agentの削除という流れが示されています。(Microsoft Learn)
特にコスト面で重要なのが、二重取り込みです。旧エージェントとAMAが同じログを同じワークスペースへ送ると、見かけ上は監視が強化されたように見えても、実際には重複データによって課金が増える可能性があります。
重複収集を防ぐチェックポイント
公式ドキュメントでは、重複データにより課金が増える可能性があるシナリオとして、同じデータソースを持つ複数DCRを同じVMに関連付けるケース、Microsoft SentinelとAzure Monitorの両方で同じセキュリティログを収集するケース、Log Analytics agentとAMAが同じマシン上で同じデータを収集するケースが挙げられています。(Microsoft Learn)
次の確認表を使うと、運用前レビューで見落としを減らせます。
| リスク | 確認方法 | 対応 |
|---|---|---|
| 同じVMに似たDCRが複数関連付いている | Get-AzDataCollectionRuleAssociation -resourceUri <vm-resource-id>で確認 | データソースやフィルターを見直す |
| SecurityログをAzure MonitorとSentinelで二重収集 | EventテーブルとSecurityEventテーブルの収集条件を確認 | Sentinel向けコネクタとDCRの役割を分ける |
| Log Analytics agentとAMAが併存 | VM拡張機能、Heartbeat、ワークスペース接続を確認 | 移行検証後に旧エージェントを削除 |
| 複数ワークスペースへ同じログを送信 | DCRのDestinationを確認 | 必要な保存先だけに絞る |
| カスタムログのパス指定が広すぎる | ワイルドカード指定と実ファイル数を確認 | 対象ディレクトリとファイル名を限定する |
同じログを複数の目的で使いたい場合でも、まずは1つの収集経路に集約し、Log Analytics上のKQL、ブック、アラート、Microsoft Sentinel側の分析ルールなどで活用方法を分ける方が管理しやすくなります。
動作確認はHeartbeatだけで終わらせない
DCRを作成した後、データが送信先に届くまで最大で数分かかる場合があります。公式ドキュメントでは、DCR作成後に宛先へデータが送られるまで最大5分かかることがあり、エージェントの動作確認にはHeartbeatテーブルを確認する方法が示されています。(Microsoft Learn)
ただし、Heartbeatが出ていることは「AMAが通信できている」ことの確認であり、「必要なログがすべて収集されている」ことの証明ではありません。次の2段階で確認してください。
エージェント通信の確認
Log Analyticsで次のような考え方でHeartbeatを確認します。
Heartbeat
| where TimeGenerated > ago(15m)
| summarize LastHeartbeat=max(TimeGenerated) by Computer, Category, OSType
| order by LastHeartbeat descAzure Monitor Agentの確認では、CategoryにAzure Monitor Agentが入るかを確認すると、旧エージェントとの区別がしやすくなります。公式ドキュメントでも、AMAのHeartbeat確認例としてCategoryでAzure Monitor Agentを絞り込む考え方が示されています。(Microsoft Learn)
収集対象テーブルの確認
次に、DCRで設定したデータソースごとにテーブルを確認します。
| データソース | 確認するテーブル |
|---|---|
| Windows events | Event |
| Performance counters | Perf |
| Syslog | Syslog |
| IIS logs | W3CIISLog |
| Text log | カスタムテーブル |
| JSON log | カスタムテーブル |
公式ドキュメントでも、Windows eventsはEvent、Performance countersはPerf、SyslogはSyslog、IIS logsはW3CIISLog、Text logやJSON logはカスタムテーブルで確認する流れが示されています。(Microsoft Learn)
たとえばWindowsイベントログを収集したつもりなら、Heartbeatだけでなく次のようにEventテーブルを確認します。
Event
| where TimeGenerated > ago(1h)
| summarize Count=count() by Computer, EventLog, EventLevelName
| order by Count descSyslogなら、施設や重要度の偏りも確認します。
Syslog
| where TimeGenerated > ago(1h)
| summarize Count=count() by Computer, Facility, SeverityLevel
| order by Count desc開発者が確認すべきアプリケーションログのポイント
開発者にとって重要なのは、アプリケーションログをAzure Monitorへ送る際に、ログ形式、ファイル出力方式、タイムスタンプ、ローテーション方式を監視設計と合わせることです。
Text logやJSON logを収集する場合、ログファイルがローカルディスク上にあり、追記型で書き込まれることが重要です。ログローテーションでファイル名が日付ごとに変わる場合は、DCRのファイルパターンを適切に指定する必要があります。対象範囲を広げすぎると、意図しないファイルまで取り込んでコスト増やノイズ増加につながります。
開発者側で最低限確認したい項目は次の通りです。
| 項目 | 推奨 |
|---|---|
| ログ形式 | 可能ならJSONなどの構造化ログにする |
| タイムスタンプ | タイムゾーンを明確にし、解析しやすい形式に統一する |
| ログレベル | DebugやTraceを本番で常時出さない |
| 個人情報・機密情報 | DCR変換だけに頼らず、アプリ側でも出力しない |
| ローテーション | ファイル名、保存期間、圧縮タイミングを監視担当に共有する |
| 障害時の相関 | リクエストID、ジョブID、ユーザー操作IDなどを出す |
監視はインフラ側だけで完結しません。アプリケーションが意味のあるログを出していなければ、Azure Monitorで収集しても障害調査には役立ちません。
展開時のおすすめ手順
本番環境に展開する場合は、次の順番で進めると安全です。
| フェーズ | 実施内容 |
|---|---|
| 設計 | 収集目的、対象VM、送信先ワークスペース、DCR分割方針を決める |
| 検証 | 代表的なWindows/Linux VMでDCRを作成し、ログ量とテーブルを確認する |
| コスト確認 | 1日あたりの取り込み量を確認し、不要ログやDebugログを除外する |
| パイロット | 本番の一部VMに適用し、アラートやダッシュボードへの影響を確認する |
| 自動展開 | Azure PolicyやIaCでDCR関連付けを展開する |
| 旧設定整理 | Log Analytics agent、重複DCR、不要なワークスペース接続を削除する |
| 運用化 | DCR変更ルール、レビュー周期、命名規則、例外管理を文書化する |
小規模環境であればAzureポータルのDCR作成で十分です。一方、数十台から数百台以上のVMやArcサーバーを管理する場合は、手作業では設定差分が出やすくなります。Azure PolicyやIaCを使い、DCRとDCRAをコードとして管理する方が、監査や再展開に強くなります。
よくある失敗と対策
AMAを入れただけでログが来ると思っている
AMAは収集の実行役ですが、何を集めるかはDCRで定義します。AMAインストール後にHeartbeatが出ていても、EventやSyslogが空なら、DCRのデータソースや関連付けを確認してください。
DCRのリージョンとワークスペースの関係を見落とす
DCRのリージョンは、送信先のLog Analytics workspaceまたはAzure Monitor workspaceと同じリージョンである必要があります。複数リージョンのワークスペースへ送る場合は、DCRを分けて設計します。(Microsoft Learn)
ポータル編集でJSONの高度な設定を消す
変換や高度な設定をJSONで入れたDCRは、ポータルで編集するとサポートされない設定が上書きされる可能性があります。高度なDCRは、編集手段をJSONやIaCに統一しましょう。(Microsoft Learn)
SentinelとAzure MonitorでSecurityログを二重収集する
SecurityログをAzure MonitorのEventテーブルとMicrosoft SentinelのSecurityEventテーブルへ重複送信すると、コストと調査ノイズが増えます。どちらを主経路にするかを先に決めてください。(Microsoft Learn)
移行中に旧エージェントを残し続ける
Log Analytics agentとAMAが同じデータを収集すると、同一テーブルに重複データが入る可能性があります。移行検証が終わったら、例外を除いて旧エージェントを整理します。(Microsoft Learn)
まず実施すべきチェックリスト
最後に、管理者と開発者がすぐに確認できるチェックリストをまとめます。
| チェック | 対応状況 |
|---|---|
| 監視対象のAzure VM、VMSS、Arcサーバーを一覧化した | 未確認なら最優先 |
| AMAが導入済みか、DCR経由で自動導入する方針かを決めた | 手作業と自動展開の混在に注意 |
| DCRのデータソースと送信先を確認した | 収集目的と一致しているか確認 |
| DCRとVMの関連付けを確認した | AMAだけでは不十分 |
| DCRのリージョンとワークスペースのリージョンを確認した | 複数リージョン環境は要注意 |
| DCEが必要なPrivate Link構成か確認した | AMPLS/DNSも確認 |
| Log Analytics agentとの重複収集がないか確認した | コスト増の原因になりやすい |
| SentinelとAzure MonitorのSecurityログ収集経路を整理した | Event/SecurityEventの重複に注意 |
| HeartbeatだけでなくEvent、Syslog、Perfなど実データを確認した | 収集漏れ防止 |
| DCRの編集方法をポータルかIaCに統一した | JSON設定の上書き防止 |
Azure MonitorのVMログ収集は、単にエージェントを入れる作業ではありません。DCRを中心に、収集対象、送信先、関連付け、ID、ネットワーク、重複収集、移行計画をまとめて設計する必要があります。
まずは既存環境で「どのVMに、どのDCRが、どのログを、どのワークスペースへ送っているか」を棚卸ししてください。そのうえで、ポータルで管理する標準DCRと、IaCで管理する高度なDCRを分け、不要な旧エージェントや重複収集を整理することが、安定したAzure Monitor運用への近道です。
コメント