Azure Monitor Agent (AMA) 移行ガイド｜最新エージェントの導入と設定
生徒
「Azureでサーバーのログを集めたいのですが、古いエージェントが廃止されるって本当ですか？」
先生
「はい、その通りです。従来のLog Analytics（ログ アナリティクス）エージェントは2024年8月でサポートが終了するため、新しいAzure Monitor Agent（アジュール モニター エージェント）、略してAMAへの移行が必須となっています。」
生徒
「AMAになると何が変わるんですか？設定は難しいでしょうか？」
先生
「セキュリティが向上し、データ収集ルール（DCR）という仕組みでより柔軟な管理ができるようになります。初心者の方でもポイントを押さえれば大丈夫ですよ。それでは、AMAの導入と設定方法を詳しく解説していきますね！」
1. Azure Monitor Agent (AMA) とは？
Azure Monitor Agent（アジュール モニター エージェント）は、Azure（アジュール）やオンプレミスで動作する仮想マシンから、パフォーマンスデータやログデータを収集するための最新のソフトウェアです。以前は「Log Analytics エージェント」や「Telegraf エージェント」など、用途によって複数のプログラムを使い分ける必要がありましたが、これらを一つに統合したものがAMAです。
AMAの大きな特徴は、DCR（データ収集ルール）という設定ファイルを使用して、「どのデータを」「どこから」「どこへ送るか」をクラウド上で一元管理できる点にあります。これにより、サーバーごとに個別の設定ファイルを手動で書き換える手間が省け、大規模なシステム運用でもミスを減らすことが可能になります。
また、AMAはマネージドID（アイデンティティ）を利用した認証を行うため、従来のワークスペースIDやプライマリキーをOS内に保持する必要がなく、セキュリティの観点からも非常に安全な設計となっています。クラウド環境の監視（モニタリング）において、AMAへの移行は避けて通れない重要なステップです。
2. 旧エージェントからの移行が必要な理由
なぜ今、多くの企業がAMAへの移行（マイグレーション）を急いでいるのでしょうか。その最大の理由は、従来の「Log Analytics エージェント（別名：MMA / OMSエージェント）」のサポート終了（リタイア）です。Microsoftは、2024年8月31日をもって旧エージェントのサポートを打ち切ることを発表しています。
サポートが終了すると、新しいOSへの対応が行われなくなるだけでなく、重要なセキュリティパッチの提供も止まってしまいます。また、最新のAzureポータル機能が利用できなくなる可能性も高いです。AMAは、旧エージェントと比較して最大で25パーセント以上のコスト削減が見込めるケースもあります。これは、必要なデータだけをピンポイントで収集し、不要なログをクラウドに送らないようにフィルタリングする機能が強化されているためです。
移行作業は単にソフトを入れ替えるだけでなく、ログの収集定義を「DCR」として作成し直す必要があります。早めに準備を進めることで、予期せぬトラブルを防ぎ、安定した監視基盤を構築することができます。
3. データ収集ルール (DCR) の仕組みを理解する
AMAを語る上で欠かせないのが「データ収集ルール（Data Collection Rules）」、通称DCRです。これは、ログ収集の「レシピ」のようなものだと考えてください。従来の方式では、サーバー内の設定ファイルに「このログを送信する」と書き込んでいましたが、DCRはAzure側のリソースとして作成します。
DCRには以下の3つの要素が含まれます。
- ソース（データ元）： どの仮想マシン（VM）からデータを集めるか。
- ストリーム（データの種類）： Windowsイベントログ、Linuxシスログ、パフォーマンスカウンターなど。
- 送信先： Log Analytics ワークスペースや Azure Monitor メトリクスなど。
例えば、開発環境のサーバーからは「エラーログ」だけを収集し、本番環境のサーバーからは「すべての情報（インフォメーション）」を収集するといった使い分けが、一つのDCRまたは複数のDCRをマシンに割り当てるだけで完結します。この中央集権的な管理こそが、最新エージェントの最大のメリットです。
4. Linux環境でのAMAインストール手順
まずは、Linux（リナックス）サーバーにAMAを導入する方法を見ていきましょう。Azure上の仮想マシンであれば、Azureポータルから数クリックで導入可能ですが、コマンドライン（CLI）やスクリプトでの自動化も頻繁に行われます。Linuxの場合、内部的には「Azure Monitor Linux Agent」という拡張機能としてインストールされます。
以下は、Azure CLI（コマンドラインインターフェース）を使用して、特定の仮想マシンにエージェントをインストールする際のイメージです。
az vm extension set --name AzureMonitorLinuxAgent --publisher Microsoft.Azure.Monitor --ids /subscriptions/sub-id/resourceGroups/rg-name/providers/Microsoft.Compute/virtualMachines/vm-name
{
"autoUpgradeMinorVersion": true,
"forceUpdateTag": null,
"id": "/subscriptions/.../extensions/AzureMonitorLinuxAgent",
"name": "AzureMonitorLinuxAgent",
"provisioningState": "Succeeded"
}インストールが成功すると、上記のように「Succeeded（サクシーディッド：成功）」というメッセージが表示されます。これでサーバー側でデータを送る準備が整いました。次に、どのデータを送るかを定義するDCRを紐付ける作業に進みます。
5. Windowsイベントログを収集する設定例
Windowsサーバーの場合、システムログやアプリケーションログを収集して解析することが一般的です。AMAでは、XPath（エックスパス）という記法を使って、特定のイベントIDのみを抽出して送信することができます。これにより、無駄なトラフィックを抑え、ストレージ容量の節約につながります。
以下は、DCRで定義するデータソース構成の一部をJSON（ジェイソン）形式で表現した例です。初心者の方向けに、どのようなデータが定義されているかをイメージしやすいようにしています。
{
"dataSources": {
"windowsEventLogs": [
{
"streams": ["Microsoft-Event"],
"scheduledTransferPeriod": "PT1M",
"queries": [
"System![System[(EventID=7036)]]",
"Application![System[(Level=1 or Level=2)]]"
],
"name": "myWindowsLogs"
}
]
}
}
この設定では、システムログの中から「サービスの開始や停止」を示すID 7036のログと、アプリケーションログの中の「エラー（Level 1）」および「警告（Level 2）」だけを収集するように指定しています。非常にシンプルかつ強力なフィルタリングが可能です。
6. カスタムログ収集とテーブル定義
標準のイベントログ以外に、独自のアプリケーションが出力するテキスト形式のログ（カスタムログ）を収集したい場合もあります。AMAでは、あらかじめLog Analyticsワークスペース側に「テーブル」を作成しておく必要があります。テーブルとは、データベース（DB）のようなデータの容れ物のことです。
例えば、Webアプリケーションのアクセスログを保存する「MyAppLog_CL」というテーブルの構造は以下のようになります。
TimeGenerated [DateTime] | LogMessage [String] | Severity [String] | ClientIP [String]
-------------------------+----------------------+------------------+---------------
2026-04-07 10:00:00 | User login success | Information | 192.168.1.10
2026-04-07 10:05:20 | Connection timeout | Error | 192.168.1.15
2026-04-07 10:10:45 | Invalid password | Warning | 192.168.1.12
2026-04-07 10:15:00 | Disk space low | Critical | 10.0.0.5
このように、あらかじめ項目の型を決めておくことで、後から高速な検索が可能になります。AMAはこのテーブルの定義に従って、テキストファイルを解析し、データをアップロードします。
7. KQLを使って収集したログを分析する
ログが正常に収集されたら、次はKusto Query Language（クスト クエリ ラングエッジ）、通称KQLを使ってデータを分析します。KQLはSQL（エスキューエル）に似た構文を持つ、Azure Monitor専用の強力な言語です。初心者の方でも、パイプ記号（|）を使って処理を繋いでいく感覚を掴めば、すぐに使いこなせるようになります。
例えば、先ほどのカスタムログからエラーだけを抽出して、発生件数が多い順に並べるクエリは以下のようになります。
MyAppLog_CL
| where Severity == "Error"
| summarize count() by LogMessage
| order by count_ desc;
実行結果は、以下のように集計されて表示されます。
LogMessage | count_
---------------------+--------
Connection timeout | 45
Database unreachable | 12
Permission denied | 3
KQLをマスターすれば、サーバーの異常をグラフ化したり、特定の条件でアラート（警告）を飛ばしたりすることが自由自在になります。AMAの導入とKQLの活用は、セットで覚えるのが上達の近道です。
8. 移行時の注意点とトラブルシューティング
AMAへの移行において、初心者がハマりやすいポイントがいくつかあります。最も多いのが、マネージドIDの設定漏れです。AMAは、仮想マシンがAzureリソースとして自分自身を証明するための「システム割り当てマネージドID」を必要とします。これが有効になっていないと、エージェントはLog Analyticsにデータを送信する許可を得られず、エラーになります。
次に注意すべきは、ネットワークの到達性です。AMAはHTTPS（ポート443）を使用してAzure Monitorの各種エンドポイントと通信します。ファイアウォールやプロキシサーバーで通信が遮断されていないか、事前に確認が必要です。特に「Azureタグ」を使用した通信許可設定を活用すると、管理が非常に楽になります。
万が一ログが届かない場合は、エージェントの動作状況を確認するコマンドを試してみましょう。Linuxであれば以下のコマンドでサービスの状態を確認できます。
systemctl status azuremonitoragent
● azuremonitoragent.service - Azure Monitor Agent
Loaded: loaded (/lib/systemd/system/azuremonitoragent.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2026-04-07 09:00:00 JST; 1h ago
Main PID: 1234 (agent)このように「active (running)」と表示されていれば、プログラム自体は正常に起動しています。もし停止していれば、再起動（restart）を試みることで解決することもあります。一歩ずつ確認していくことが、安定した運用のコツです。
まとめ
ここまで、最新の監視エージェントである「Azure Monitor Agent（AMA：アジュール モニター エージェント）」の基本概念から導入手順、そしてデータ収集の要となる「DCR（データ収集ルール）」の仕組みについて詳しく解説してきました。従来のLog Analyticsエージェント（MMA）が2024年8月末にサポート終了を迎える中で、AMAへの移行は単なる「古いものから新しいものへの置き換え」以上の価値を持っています。セキュリティの強化、コストの最適化、そして何より「どのデータをどこへ送るか」というルールをクラウド側で一元管理できる柔軟性は、現代の複雑なクラウドネイティブ環境において不可欠な要素と言えるでしょう。
AMAの導入にあたって最も重要なポイントは、これまでの「サーバー単位の設定」という考え方を捨て、Azureリソースとしての「DCR」を中心に据えた設計に切り替えることです。例えば、複数の仮想マシン（VM）に対して同じ収集ルールを一括で適用したり、特定の重要なサーバーだけ詳細なデバッグログを取得したりといった運用が、ポータル上やInfrastructure as Code（IaC）を通じて極めてスムーズに行えるようになります。また、マネージドID（アイデンティティ）による認証方式の採用により、接続文字列や共有キーをサーバー内に保持する必要がなくなったことは、情報漏洩リスクを低減させる大きな進歩です。
実務においては、Linux環境での拡張機能インストールや、WindowsイベントログのXPath（エックスパス）による高度なフィルタリング、さらにはカスタムログを保存するためのカスタムテーブル定義など、多岐にわたる設定項目が存在します。しかし、これらを一つずつ理解し、KQL（Kusto Query Language：クスト クエリ ラングエッジ）によるデータ分析と組み合わせることで、システムの健康状態をリアルタイムで可視化し、異常の兆候をいち早く察知できる強力な監視基盤を構築することができます。本記事で紹介した手順やコード例を参考に、まずはスモールスタートでAMAの検証環境を構築し、新しいモニタリングの世界を体験してみてください。
AMA移行とデータ運用のポイント再確認
移行のプロセスで混乱しがちなのが、既存の「ワークスペース」と新しい「エージェント」の関係性です。AMAは既存のLog Analytics ワークスペースをそのまま送信先として利用できるため、過去のデータを捨て去る必要はありません。大切なのは「収集の入り口」をAMAに変えることです。また、移行期間中は旧エージェントとAMAを一時的に共存させる「マルチホーミング」状態にすることも可能ですが、データの重複課金には注意が必要です。計画的なマイグレーションプランを立て、確実に最新環境へとステップアップしていきましょう。
運用で役立つサンプルスクリプトとデータ構造
ここでは、AMAの稼働状況をチェックするための実用的なコマンドや、実際に収集されるデータのイメージを整理しておきましょう。
例えば、Linuxサーバーにおいてエージェントの診断ログを確認したり、設定が正しく反映されているかをチェックする際には、以下のコマンドが頻繁に使用されます。
/opt/microsoft/azuremonitoragent/bin/ama_status.py
--------------------------------------------------------------------------------
AMA STATUS REPORT
--------------------------------------------------------------------------------
Status: Summary
AMA Version: 1.25.0
AMA Run Status: running
DCR Config Status: Success (Last fetched: 2026-04-07 10:15:00)
--------------------------------------------------------------------------------次に、SQLデータベースのような構造でログを管理する際の、テーブルの状態を確認してみましょう。以下は、セキュリティイベントを模したデータのBefore/Afterの状態です。
TenantId | TimeGenerated | EventID | Computer | AccountName
---------+----------------------+---------+-------------+------------
111-222 | 2026-04-07 10:20:00 | 4624 | WebServer01 | admin
111-222 | 2026-04-07 10:21:05 | 4625 | DBServer02 | guest
111-222 | 2026-04-07 10:22:15 | 4624 | WebServer01 | user01
111-222 | 2026-04-07 10:23:30 | 4648 | AppServer03 | service_acc
このデータに対して、特定のイベントID（例えば4625のログオン失敗）を抽出するSQL（KQL）クエリを実行する例です。
SecurityEvent
| where EventID == 4625
| project TimeGenerated, Computer, AccountName
| order by TimeGenerated desc;
実行結果（出力）は以下のようになります。
TimeGenerated | Computer | AccountName
---------------------+-------------+------------
2026-04-07 10:21:05 | DBServer02 | guest
生徒
「先生、AMAの仕組みがだいぶ見えてきました！旧エージェントとの一番の違いは、設定ファイルがサーバーの中にあるか、Azureクラウド側（DCR）にあるか、という点なんですね。」
先生
「その通り、素晴らしい理解です！これまでは各サーバーにログインして設定をいじる必要がありましたが、これからはAzureポータル上でルールを作って、それを対象のサーバーに『ガチャン』とはめるだけで済むようになります。」
生徒
「DCR（データ収集ルール）はレシピのようなもの、という例えが分かりやすかったです。でも、設定を間違えて大量のログを送ってしまったら、料金が高くなってしまいそうで怖いです……。」
先生
「鋭い指摘ですね。だからこそ、AMAの『フィルタリング機能』が活きてくるんです。XPath（エックスパス）を使って、本当に必要な重大なエラーや警告だけを絞り込んで送るように設定すれば、無駄なコストを大幅に抑えることができますよ。SQLのような感覚で条件を書けるので、慣れれば簡単です。」
生徒
「なるほど、必要なものだけを選ぶ技術が大事なんですね。あと、マネージドIDの設定を忘れないようにしないといけないという点も心に刻んでおきます！」
先生
「そうですね。マネージドIDは、AMAがAzureと安全に通信するための『身分証明書』です。これが無いと、どんなに良い設定をしてもデータは届きません。トラブルが起きたときは、まずはIDの設定と、ネットワークの疎通、そしてエージェントのサービス状態を確認するクセをつけましょう。」
生徒
「分かりました！さっそくテスト用のVM（仮想マシン）でAMAを動かしてみて、KQLでログを検索するところまでやってみます。先生、ありがとうございました！」
先生
「はい、頑張ってくださいね。実際にデータを触ってみるのが一番の上達法です。もしクエリの書き方で迷ったら、いつでも聞いてください。応援していますよ！」
