Azure MonitorでLog Analyticsエージェント（MMA／OMS）を使っている環境では、結論としてAzure Monitor Agent（AMA）への移行を急ぐべき状況です。Log Analyticsエージェントはすでに廃止されており、2026年3月2日以降はデータアップロードが予告なく停止する可能性があります。単にエージェントを入れ替えるだけでなく、データ収集規則（DCR）、依存サービス、Azure Policy、検証方法まで見直すことが重要です。(Microsoft Learn)
本記事では、2026年5月9日時点で確認できるMicrosoft Learnの公式情報を基に、Azure Monitorにおける「Log Analytics Agent Migration」で何が変わるのか、どの環境が影響を受けるのか、管理者や開発者が移行前に確認すべきポイントを実務目線で整理します。なお、Microsoft Learn上の当該ページの最終更新表示は2026年5月8日です。(Microsoft Learn)
Log Analytics Agent Migrationで最も重要な変更点
Log Analytics Agent Migrationの中心は、従来のLog AnalyticsエージェントからAzure Monitor Agentへ移行することです。Azure Monitor Agentは、Azure VMだけでなく、Azure外のサーバー、オンプレミス、他クラウド上のWindows／Linuxマシンにも対応する後継エージェントとして位置付けられています。旧エージェントがワークスペースベースで構成されていたのに対し、AMAではデータ収集規則（DCR）を使って「何を収集し、どう処理し、どこへ送るか」を管理します。(Microsoft Learn)
実務上の変化は、次の3点に集約できます。
| 観点 | 従来のLog Analyticsエージェント | Azure Monitor Agentへの移行後 |
|---|---|---|
| 構成管理 | Log Analyticsワークスペース中心 | DCR中心で収集対象・宛先・変換を管理 |
| 展開方法 | 個別導入や拡張機能、既存自動化に依存 | Azure Policy、VM拡張機能、DCR作成、VM insightsなどで展開 |
| 運用上のリスク | 廃止済み。サポートや新OS対応が期待できない | Azure Monitorの標準的なゲストOSデータ収集エージェントとして利用 |
特に注意したいのは、AMAへの移行は「監視エージェントの置き換え」ではなく、監視データ収集設計の作り直しに近い点です。既存のパフォーマンスカウンター、Windowsイベント、Syslog、カスタムログ、IISログ、Microsoft Sentinel連携などを棚卸ししないまま移行すると、移行後にログ欠落や重複課金が発生しやすくなります。
影響を受ける環境と受けない環境
Log Analyticsエージェントの移行対象は広く、Azure上の仮想マシンだけに限られません。Azure Monitor AgentはAzure、非Azure、オンプレミス、他クラウド環境のWindows／Linuxマシンで利用されます。一方で、オンプレミスのSystem Center Operations Manager（SCOM）だけに接続されているLog Analyticsエージェントについては、この廃止の対象外とされています。(Microsoft Learn)
| 環境 | 移行判断 |
|---|---|
| Azure VM | AMAへの移行対象。DCRと関連付けて収集を再設計する |
| Azure Virtual Machine Scale Sets | 移行対象。大規模展開ではAzure Policyや自動化を使う |
| Azure Arc対応サーバー | 移行対象。オンプレミスや他クラウドではAzure Arc Connected Machine Agentが前提 |
| オンプレミスサーバー | Azure Arc経由でAMAを導入する |
| 他クラウド上のサーバー | Azure Arc経由で管理対象にしてAMAを導入する |
| SCOMのみに接続されたLog Analyticsエージェント | 廃止対象外。ただしAzure Monitor連携の有無を確認する |
オンプレミスや他クラウドのサーバーでは、旧エージェントがワークスペースIDとキーで認証していたのに対し、AMAではAzure Arcを通じたマネージドIDによる認証が使われます。これはセキュリティと管理性の面では改善ですが、移行時にはAzure Arc導入、権限、ネットワーク到達性を事前に確認する必要があります。(Microsoft Learn)
旧エージェントを使い続けるリスク
Log Analyticsエージェントは2024年8月31日に廃止済みです。公式情報では、2026年3月2日以降、Log Analyticsエージェントからのデータアップロードは予告なく停止する可能性があるとされています。また、Azureポータルからの新規インストールはできず、Microsoftのサポート対象外で、新しいディストリビューションやサービスパック対応も提供されません。(Microsoft Learn)
このため、次のような運用リスクがあります。
| リスク | 起こり得る影響 |
|---|---|
| ログ送信停止 | 監視アラート、監査ログ、セキュリティ検知が欠落する |
| 新OS非対応 | OS更新後に監視が継続できない可能性がある |
| サポート終了 | 障害発生時にMicrosoftサポートを前提にした復旧計画が立てにくい |
| 二重収集 | AMAと旧エージェントを併用したまま同じデータを送信し、コストが増える |
| 依存サービスの見落とし | Update Management、Sentinel、Defender for Cloudなどの機能に影響する |
特にセキュリティ監視でMicrosoft SentinelやDefender for Cloudを使っている場合、ログが届いているように見えても、一部のテーブルやイベント種別だけが欠落しているケースがあります。移行後は「エージェントが入っているか」ではなく、「必要なテーブルに期待したデータが入っているか」で判断することが重要です。
移行前に棚卸しすべき項目
Log Analytics Agent Migrationで失敗しやすいのは、移行対象マシンだけを数えて、ワークスペースや依存ソリューションを十分に確認しないケースです。Microsoftは、移行前にエージェント、ワークスペース、依存サービスを評価し、その後DCRを構成してAMAを展開し、データ収集を検証してから旧エージェントを削除する流れを示しています。(Microsoft Learn)
まず確認するべき一覧
| 確認項目 | 見るべきポイント |
|---|---|
| 旧エージェントの導入状況 | Log Analyticsエージェントのみ、AMAのみ、両方導入済みのマシンを分ける |
| 送信先ワークスペース | どのワークスペースに、どのマシンがデータを送っているか |
| データソース | Windowsイベント、Syslog、Perf、IISログ、カスタムログなど |
| 依存サービス | Update Management、Change Tracking、Sentinel、Defender for Cloudなど |
| Azure外のサーバー | Azure Arc導入状況、Arc未対応のハイブリッドマシン |
| 自動展開設定 | 旧エージェントを新規サーバーへ自動配布していないか |
| コスト影響 | 同じログを複数DCRや複数宛先へ送っていないか |
棚卸しには、Azure Monitor Agent Migration Helper workbookが有用です。このワークブックは、複数サブスクリプションにまたがるリソース、ワークスペース、Azure VM、VM Scale Sets、Arc対応サーバー、Arc未対応で旧エージェントが入っているハイブリッドマシンなどを検出し、移行ステータスを確認できます。(Microsoft Learn)
ワークブック上では、旧エージェントのみのリソースは「Not Started」、両方のエージェントがあるリソースは「In progress」、AMAのみのリソースは「Completed」といった形で進捗を把握できます。結果はExcelにエクスポートできるため、サーバー管理チーム、セキュリティチーム、アプリケーション担当者で移行対象を分担する際にも使いやすいです。(Microsoft Learn)
依存サービス別の移行ポイント
Log Analyticsエージェントは、単なるログ転送だけでなく、複数のAzureサービスや監視ソリューションに使われていました。そのため、エージェント移行と同時に依存サービスの移行方針も確認する必要があります。
| 依存サービス | 確認すべき移行方針 |
|---|---|
| Azure Automation Update Management | Azure Update Managerへ移行する。Azure Update ManagerはAMAとは独立した仕組みを使う |
| Change Tracking and Inventory | AMA向けの変更追跡ソリューション用DCRを作成する |
| Microsoft Defender for Cloud | Defender for Servers Plan 2ではエージェントレススキャンへの変更を検討する。セキュリティイベント収集はカスタムDCRを確認する |
| Microsoft Sentinel | 旧エージェントを使っていたソリューションを、AMA対応の最新バージョンへ更新する |
| VM insights | パイロットグループでAMA対応へ移行し、収集データを検証する |
公式ドキュメントでは、Azure Automation Update ManagementはAzure Update Managerへ、Change Tracking and InventoryはAMA向けDCRへ、Defender for CloudやSentinelは利用プランやソリューションに応じた更新が必要と整理されています。(Microsoft Learn)
運用現場では、ここで部門間の認識差が出やすくなります。たとえば、インフラ担当者は「AMAを入れたので移行完了」と判断していても、セキュリティ担当者側ではSentinelのソリューション更新やセキュリティイベントのDCR設定が未完了ということがあります。移行チェックリストには、必ず依存サービスのオーナーと検証担当を明記しておきましょう。
DCR設計で確認すべきポイント
Azure Monitor Agentでは、DCRが移行後の監視品質を左右します。DCRはデータソース、スキーマ、変換、宛先を定義する仕組みで、旧来のデータ収集方法よりも一貫性があり、Infrastructure as CodeやDevOpsプロセスにも組み込みやすい構成です。(Microsoft Learn)
DCR設計では、次の判断が重要です。
| 判断ポイント | 実務上の考え方 |
|---|---|
| DCRの粒度 | OS別、用途別、本番／検証別などで分ける。細かすぎると管理が複雑になる |
| 宛先ワークスペース | 監査、運用監視、セキュリティ監視で送信先が異なる場合は重複送信に注意する |
| データソース | Windowsイベント、Perf、Syslog、IISログ、カスタムログなどを旧設定と比較する |
| 変換処理 | 不要ログの除外、機密情報の削除、スキーマ整形を検討する |
| リージョン | DCRは宛先のLog AnalyticsワークスペースまたはAzure Monitorワークスペースと同じリージョンに作成する |
| 変更管理 | JSON編集を使う場合はGitHubやAzure DevOpsでバージョン管理する |
DCRには変換処理を定義でき、受信データをLog Analyticsワークスペースへ送る前にフィルターや加工を実行できます。不要なログを落としてコストを抑える、保存すべきでない情報を除外する、宛先テーブルに合わせて形式を整える、といった用途で有効です。(Microsoft Learn)
ただし、Azureポータルで既存DCRを編集すると、ポータル側でサポートされていないJSON上の変更が上書きされる可能性があります。特に変換処理をJSONで細かく調整している場合は、ポータル編集とJSON編集を混在させない運用ルールを決めておくべきです。(Microsoft Learn)
移行手順は「小さく試してから広げる」が基本
大規模環境では、いきなり全サーバーへAMAを展開するのは避けるべきです。公式ドキュメントでも、まず小規模なパイロットグループを選び、DCRを生成・展開し、VM insightsなどの依存機能を移行し、旧エージェント側のデータ収集を無効化して二重取り込みを避けたうえで検証する流れが示されています。(Microsoft Learn)
| ステップ | 作業内容 | 失敗しやすいポイント |
|---|---|---|
| 現状把握 | Migration Helper workbookで対象を棚卸し | Arc未対応サーバーや休眠ワークスペースの見落とし |
| パイロット選定 | 代表的なOS、用途、監視要件を含む少数のサーバーを選ぶ | 本番と構成が違いすぎる検証機だけで試す |
| DCR作成 | DCR Config Generatorやポータル、JSONで収集設定を作る | 旧ワークスペース設定を完全に再現できたと思い込む |
| AMA展開 | VM拡張機能、DCR作成、Azure Policyなどで導入 | DCR関連付けを忘れ、エージェントだけ入る |
| 二重収集対策 | 旧エージェントのワークスペース構成を外す | AMAと旧エージェントが同じテーブルへ送信する |
| 検証 | Heartbeat、Perf、Event、Syslog、カスタムログを確認 | エージェント正常だけでログ品質を確認しない |
| 本番展開 | Azure PolicyやIaCで段階展開 | 例外サーバーや依存サービスの検証漏れ |
| 旧エージェント削除 | 検証後にMMA Discovery and Removal toolなどを使う | SCOM管理マシンまで誤って削除する |
Azure外のサーバーやオンプレミスサーバーでは、AMAを導入する前にAzure Arc Connected Machine Agentをインストールし、Azure上の管理対象リソースとして扱える状態にしておく必要があります。(Microsoft Learn)
Azure Policyを使った大規模展開の注意点
サーバー台数が多い場合は、Azure Policyを使ってAMAのインストールとDCR関連付けを自動化するのが現実的です。Azure Policyでは、既存および新規の仮想マシン、VM Scale Sets、Azure Arc対応サーバーに対して、Azure Monitor Agentを自動インストールし、関連するDCRを自動的に関連付けることができます。(Microsoft Learn)
ただし、Azure Policy展開ではマネージドIDの扱いに注意が必要です。Microsoftのドキュメントでは、Azure VMやVM Scale SetsへのAMAインストールポリシーでは、スケーラビリティと回復性の観点からユーザー割り当てマネージドIDを使うことが説明されています。一方、Azure Arc対応サーバーではシステム割り当てマネージドIDが現在のサポート対象です。(Microsoft Learn)
実務では、次のような設定ミスが起こりがちです。
| ミス | 結果 | 対策 |
|---|---|---|
| DCRのResource IDを誤る | エージェントは入るがデータ収集されない | ポリシー割り当て前にDCR IDを確認する |
| 既存リソースに修復タスクを実行しない | 新規VMだけAMA化され、既存VMが残る | ポリシー割り当て時にremediationを計画する |
| カスタムイメージを対象に含めない | 一部VMにポリシーが適用されない | Additional Virtual Machine Imagesを確認する |
| リソースグループスコープで権限不足 | デプロイ失敗 | ポリシー割り当てIDに必要なロールを付与する |
| 旧エージェントの自動展開を止めない | 移行しても新規サーバーで旧エージェントが増える | 旧エージェント配布ルールを停止する |
移行のゴールは「一度AMAを配ること」ではありません。新しいサーバーが作られたときにもAMAとDCRが自動的に適用され、旧エージェントが増えない状態を作ることが、本当の完了条件です。
権限・OS・ディスク容量の確認ポイント
AMA移行では、権限不足やOS非対応、ディスク容量不足が原因で展開に失敗することがあります。Azure Monitor AgentはAzure VM拡張機能として実装され、WindowsではAzureMonitorWindowsAgent、LinuxではAzureMonitorLinuxAgentが使われます。(Microsoft Learn)
権限面では、エージェントのデプロイにVirtual Machine ContributorやAzure Connected Machine Resource Administrator、ARMテンプレート展開に必要なMicrosoft.Resources/deployments/*を含むロールなどが関係します。また、DCRの作成・編集・関連付けではMonitoring Contributorなどの権限が必要になります。(Microsoft Learn)
OSについては、Windows Server 2025／2022／2019／2016、ESU契約付きWindows Server 2012 R2、Windows 10／11の一部エディション、主要Linuxディストリビューションなどがサポート対象として整理されています。ただし、x86はサポートされず、LinuxではPythonや必要パッケージ、ディスク要件も確認が必要です。(Microsoft Learn)
ディスク容量も軽視できません。AMAはローカルファイルシステムにキャッシュやログを保持します。Windows環境ではエージェントキャッシュに大きめの領域が必要になるため、監視対象が小容量ディスクのサーバーやVDI系の環境では、展開前に空き容量を確認しておきましょう。アップグレード中は一時的に2つのバージョンが共存し、必要容量が増える点にも注意が必要です。(Microsoft Learn)
移行後の検証はKQLで具体的に確認する
AMAを展開した後は、Azureポータル上で拡張機能が「成功」と表示されているだけでは不十分です。公式ドキュメントでは、Log Analyticsワークスペースに対してKQLクエリを実行し、旧エージェントとAMAの取り込みデータを比較することが推奨されています。たとえばHeartbeatテーブルを確認し、CategoryでフィルターしてAMAのハートビートが到着しているかを確認します。(Microsoft Learn)
検証では、次のように「テーブル単位」で確認すると抜け漏れを減らせます。
| データ種別 | 主な確認テーブル | 見るべきポイント |
|---|---|---|
| エージェント疎通 | Heartbeat | AMAのハートビートが継続しているか |
| Windowsイベント | Event | 必要なイベントログが入っているか |
| パフォーマンス | Perf | CPU、メモリ、ディスクなどのカウンターが旧設定と同等か |
| Syslog | Syslog | Linuxサーバーのfacility、severityが想定通りか |
| IISログ | W3CIISLog | サイト名やURLなど必要列が入っているか |
| カスタムログ | カスタムテーブル | テーブル名、スキーマ、件数が想定通りか |
| Sentinel関連 | SecurityEventなど | 検知ルールに必要なイベントが欠落していないか |
DCRのトラブルシューティングでは、Logs Ingestion Bytes per Min、Logs Rows Received per Min、Logs Rows Dropped per Min、Logs Transformation Errors per Minなどのメトリックや、DCRLogErrorsテーブルを確認できます。変換処理を入れている場合は、ログが「届いていない」のか、「変換で落とされている」のかを分けて調査することが重要です。(Microsoft Learn)
二重取り込みとコスト増を防ぐ
AMA移行でよくある失敗が、旧エージェントとAMAが同時に同じデータを収集し、Log Analyticsの取り込み量が増えるケースです。DCRで同じデータソースを複数定義したり、同じVMに重複したDCRを関連付けたり、Microsoft SentinelとAzure Monitor側で同じセキュリティログを収集したりすると、重複データにより課金が増える可能性があります。(Microsoft Learn)
移行テスト中は、旧エージェントをすぐアンインストールするのではなく、パイロットサーバー上の旧エージェントのワークスペース構成を削除し、データ収集を止める方法が示されています。これにより、旧エージェントを残したまま切り戻し余地を確保しつつ、二重取り込みを避けられます。(Microsoft Learn)
実務では、移行期間中に次のKQL確認を定期的に行うと安全です。
Heartbeat
| summarize Count=count() by Computer, Category
| order by Computer ascこのクエリで、同じサーバーに旧エージェント系とAMA系のハートビートが混在していないかを確認できます。さらに、Event、Perf、Syslogなどのテーブルで移行前後の件数を比較し、想定以上に増えていれば二重収集を疑います。
既知の問題：IISログとSQL Assessment Solution
公式ドキュメントでは、移行時の既知の問題としてIISログとSQL Assessment Solutionが挙げられています。IISログでは、AMAがW3CIISLogテーブルのsSiteName列を設定しない場合があり、AMAでsSiteNameを収集するにはIISのW3CログでService Name（s-sitename）フィールドを有効にする必要があります。(Microsoft Learn)
IISを運用している環境では、移行後に「ログは入っているがサイト名で分析できない」という問題が起こりやすくなります。特に複数サイトを1台のIISでホストしている場合、sSiteNameが欠落すると、障害調査やアクセス分析の精度が落ちます。移行前のテストで、W3CIISLogの主要列を必ず確認してください。
SQL Assessment Solutionについては、SQLベストプラクティス評価の一部として扱われ、デプロイポリシーがサブスクリプションごとに1つのLog Analyticsワークスペースを要求する点が、推奨されるAMA展開アプローチと異なると説明されています。(Microsoft Learn)
開発者が確認すべきポイント
開発者やSREが関わる場合は、カスタムログとDCR変換を重点的に確認する必要があります。AMAでは、テキストログ、JSONログ、IISログ、Windowsイベント、Syslog、パフォーマンスカウンターなどをDCRで収集対象にできます。(Microsoft Learn)
特にアプリケーションログでは、次の点を確認しましょう。
| 確認項目 | 具体例 |
|---|---|
| ログファイルのパス | ローテーション後もDCRが対象ファイルを拾えるか |
| ログ形式 | テキスト、JSON、独自形式のどれか |
| テーブル設計 | 既存のクエリやダッシュボードが使う列名と合うか |
| 変換処理 | 不要行の除外、個人情報や秘匿情報の削除が必要か |
| アラート条件 | AMA移行後も同じKQLで検知できるか |
| IaC管理 | DCR JSONをリポジトリで管理し、変更履歴を残すか |
旧エージェント時代に「とりあえずワークスペースへ送ってからKQLで絞る」運用をしていた場合、AMA移行はログ設計を見直す好機です。DCR変換で不要データを取り込む前に落とせば、Log Analyticsの取り込み量を抑えられる可能性があります。ただし、変換で落としたログは後から復元できないため、監査要件のあるログでは削除条件を慎重にレビューしてください。
管理者向けの移行チェックリスト
実際に移行を進める際は、次のチェックリストを使うと抜け漏れを防ぎやすくなります。
| フェーズ | チェック項目 |
|---|---|
| 計画 | 対象サブスクリプション、ワークスペース、VM、Arcサーバーを一覧化した |
| 計画 | Update Management、Sentinel、Defender for Cloud、Change Trackingの利用有無を確認した |
| 計画 | 旧エージェントの自動展開ルールを特定した |
| 設計 | DCRの粒度、宛先、リージョン、データソースを決めた |
| 設計 | カスタムログや変換処理の要件を確認した |
| 準備 | Azure Arc、マネージドID、必要ロール、ネットワーク要件を確認した |
| 準備 | サポートOS、ディスク容量、Linuxの必要パッケージを確認した |
| 検証 | パイロットグループへAMAとDCRを展開した |
| 検証 | Heartbeat、Event、Perf、Syslog、カスタムログの件数を比較した |
| 検証 | Microsoft SentinelやDefender for Cloudなど依存サービスの動作を確認した |
| 展開 | Azure PolicyやIaCで段階的に本番展開した |
| 展開 | 既存リソース向けのremediationを実行した |
| 完了 | 旧エージェントを削除し、二重取り込みが解消されたことを確認した |
| 完了 | SCOM管理マシンなど例外対象を誤って削除していないことを確認した |
まとめ：移行の成否はDCR設計と検証で決まる
Log Analytics Agent Migrationでは、Azure Monitor Agentへ置き換えること自体よりも、DCRを中心に監視データ収集を再設計し、移行後のデータ品質を検証することが重要です。Log Analyticsエージェントはすでに廃止され、2026年3月2日以降はデータアップロード停止の可能性があるため、未移行の環境では優先度の高い対応項目です。(Microsoft Learn)
まずはMigration Helper workbookで対象と依存サービスを棚卸しし、小規模なパイロットでDCR、AMA、KQL検証、二重取り込み対策を確認しましょう。その後、Azure PolicyやIaCで段階展開し、検証が完了した環境から旧エージェントを削除する流れが現実的です。
最初に着手すべき作業は、全サーバーへの一括展開ではありません。旧エージェントがどこにあり、どのワークスペースへ何を送っていて、どのサービスが依存しているかを可視化することです。その一覧ができれば、AMA移行は計画的に進められます。
コメント