Azure Monitor を使っている組織にとって、2026年4月20日に公開された「Azure Monitor native OTLP ingestion via Azure Monitor Agent enters public preview」は、単なる新機能ニュースではありません。結論から言うと、このアップデートは Azure Monitor が OpenTelemetry / OTLP を前提にした標準化された監視基盤へ進んでいる ことを示す重要なシグナルです。
ただし、現時点ではパブリックプレビューです。すぐに本番監視を全面移行するよりも、Product owner、IT decision-maker、technical strategist は「どのワークロードを OpenTelemetry 化するか」「Azure Monitor Agent と DCR をどう標準化するか」「既存の Application Insights や Log Analytics をどう整理するか」を計画する段階と考えるべきです。
Azure Monitor native OTLP ingestion via Azure Monitor Agent の何が重要なのか
2026年4月20日の Microsoft のリリース情報では、Azure Monitor が Azure Monitor Agent、いわゆる AMA を使った OpenTelemetry Protocol（OTLP）シグナルのネイティブ取り込み をパブリックプレビューとして提供すると説明されています。対象は Azure VM、Virtual Machine Scale Sets、Azure Arc 対応プラットフォームです。OpenTelemetry で計装されたアプリケーションから AMA にテレメトリを送り、AMA が Azure Monitor へ転送する構成になります。(マイクロソフト)
この更新で注目すべき点は、「OTLP を受け付ける入口が増えた」ことだけではありません。Azure Monitor のロードマップを読むうえでは、次の3点が重要です。
- Azure Monitor が OpenTelemetry をアプリケーション監視の中心に据えつつある
- Azure Monitor Agent と Data Collection Rules（DCR）がデータ収集の標準的な制御面になっている
- VM、AKS、Arc、ハイブリッド環境ごとに、OTLP 取り込み方式を選べる設計へ進んでいる
つまり、今後の Azure Monitor 運用では「どの画面を使うか」よりも、どの標準で計装し、どの経路で取り込み、どの保存先・分析先へ送るか が設計の中心になります。
まず押さえるべきアップデート内容
今回のプレビューでは、OpenTelemetry SDK などで計装したアプリケーションから OTLP データを AMA に送信し、Azure Monitor 側で Application Insights、Grafana ダッシュボード、Prometheus クエリ、Log Analytics などを使って分析できる構成が示されています。Microsoft Learn では、Azure Monitor の OTLP 取り込み方法として OpenTelemetry Collector、Azure Monitor Agent、AKS add-on の3種類が整理されています。(aka.ms)
特に AMA 経由の取り込みは、Azure VM、VM Scale Sets、Azure Arc 対応サーバー上のアプリケーションに向いています。ホスト上のエージェントがローカルで OTLP を受け取り、認証や Azure Monitor へのルーティングを担うため、個別に Collector を運用する負担を減らせる可能性があります。(Microsoft Learn)
一方で、Microsoft Learn ではこの機能がプレビューであり、プレビュー機能は SLA なしで提供され、本番ワークロードには推奨されないと明記されています。したがって、現時点の適切な使い方は「本番全面導入」ではなく、将来の標準化を見据えた検証です。(aka.ms)
Azure Monitor のロードマップは「OpenTelemetry 標準化」に向かっている
Azure Monitor の中期的な方向性を読むうえで、OpenTelemetry は避けて通れません。OpenTelemetry は、トレース、メトリック、ログなどのテレメトリを生成・収集・エクスポートするためのベンダーニュートラルなフレームワークです。OTLP はそのテレメトリを送るためのプロトコルで、トレース、メトリック、ログのシグナルについて stable とされています。(OpenTelemetry)
これは、Azure Monitor の利用者にとって大きな意味があります。従来は、監視ツールごとに SDK、エージェント、データ形式、ダッシュボード設計が分断されがちでした。OpenTelemetry を採用すれば、アプリケーション側の計装をより標準化し、将来的な監視基盤の変更やマルチクラウド戦略にも対応しやすくなります。
ただし、「OpenTelemetry を使えば Azure 固有の設計が不要になる」という理解は誤りです。今回の AMA 経由の OTLP 取り込みでも、Application Insights との連携には microsoft.applicationId の設定が必要になる場合があります。また、Application Insights の体験では OTLP メトリックに delta temporality と exponential histogram aggregation が求められる点も示されています。(aka.ms)
つまり、今後の設計方針は次のように考えると現実的です。
| 観点 | これまでの発想 | 今後の発想 |
|---|---|---|
| アプリ計装 | 監視製品ごとの SDK を選ぶ | OpenTelemetry を第一候補にする |
| 収集経路 | ワークロードごとに個別最適 | AMA、AKS add-on、Collector を使い分ける |
| 設定管理 | エージェント単位で設定 | DCR で収集・加工・送信先を管理 |
| 分析 | Application Insights や Log Analytics を個別に見る | シグナル別に最適な分析先を組み合わせる |
| 移行判断 | 機能追加のたびに対応 | 標準化・コスト・運用負荷で判断する |
Azure Monitor Agent と DCR が運用の中心になる
Azure Monitor Agent は、Azure やハイブリッド環境の VM からゲスト OS の監視データを収集し、Azure Monitor や関連サービスへ届けるエージェントです。Microsoft は、ゲスト OS データ収集において AMA をサポートされるエージェントとして位置付けています。(Microsoft Learn)
AMA の重要な特徴は、Data Collection Rules（DCR）に基づいて動作する点です。DCR は、何を収集するか、どのように処理するか、どこへ送るかを定義します。エージェントは関連付けられた DCR を取得し、複数のエージェントや環境に対して一貫したデータ収集設定を適用できます。(Microsoft Learn)
今回の OTLP 取り込みも、この流れの延長にあります。AMA が単に OS ログやパフォーマンスカウンターを集めるだけでなく、OpenTelemetry のアプリケーションシグナルを受け取る入口にもなることで、Azure Monitor の収集基盤がより統合されていくと考えられます。
DCR 設計を後回しにすると失敗しやすい
DCR は便利ですが、設計を誤ると運用が複雑になります。Microsoft のベストプラクティスでは、DCR を単一の巨大なルールにまとめるのではなく、観測範囲、データソース種別、送信先などに応じて分けることが推奨されています。不要なデータ収集はコスト増につながり、DCR の分離はデータ主権や地域要件の管理にも役立ちます。(Microsoft Learn)
実務では、次のような切り方が扱いやすいです。
| DCR の分け方 | 具体例 | 向いている理由 |
|---|---|---|
| 環境別 | dev、test、prod | 本番だけ厳格な保持・送信先を設定しやすい |
| ワークロード別 | 決済 API、社内業務アプリ、AI エージェント | アプリ単位で責任者とコストを追跡しやすい |
| データ種別別 | OS メトリック、アプリログ、OTLP トレース | 変更時の影響範囲を限定しやすい |
| 送信先別 | Log Analytics、Azure Monitor workspace、Event Hubs | 規制・監査・分析要件に合わせやすい |
| 地域別 | Japan East、West Europe、East US | データ所在地やリージョン制約を整理しやすい |
避けたいのは、「全 VM に同じ DCR を付ける」「全アプリのログ・メトリック・トレースを1つのルールで扱う」「送信先の違いを後から考える」といった設計です。最初は簡単に見えても、アプリ数や国・地域が増えると、変更管理とコスト配賦が難しくなります。
OTLP 取り込み方式はワークロード別に選ぶ
Azure Monitor の OTLP 対応は、1つの方式に集約されるというより、ワークロードに応じて複数の入口を選ぶ形になっています。Microsoft Learn では、AKS、VM / VMSS / Arc、Azure Monitor Agent が使えない環境などに応じて、AKS add-on、AMA、OpenTelemetry Collector を使い分ける説明がされています。(Microsoft Learn)
| ワークロード | 第一候補の取り込み方式 | 向いているケース | 注意点 |
|---|---|---|---|
| Azure VM / VM Scale Sets | AMA 経由の OTLP 取り込み | ホスト単位でエージェント管理したい、Collector 運用を減らしたい | 現時点ではプレビュー。AMA のバージョン、DCR、Managed Identity の確認が必要 |
| Azure Arc 対応サーバー | AMA 経由の OTLP 取り込み | オンプレミスや他クラウドのサーバーを Azure 管理下に置いている | Arc 接続、権限、ネットワーク経路の整備が前提 |
| AKS | AKS add-on / Azure Monitor OpenTelemetry for Kubernetes | クラスター統合で監視したい、名前空間やデプロイ単位で扱いたい | プレビュー機能の範囲とサポート状況を確認する |
| AMA が使えない環境 | OpenTelemetry Collector | マルチクラウド、独自基盤、細かいパイプライン制御が必要 | Collector のデプロイ、認証、スケール、更新管理が必要 |
| 新規のサーバーサイドアプリ | Azure Monitor OpenTelemetry Distro + Application Insights | コードベースで標準的に計装したい | 既存 SDK との混在や移行方針に注意する |
Product owner や technical strategist が見るべきポイントは、「どの方式が最新か」ではなく、自社の運用モデルに合っているか です。たとえば、プラットフォームチームが VM と Arc サーバーを一元管理しているなら AMA 経由は有力です。一方、複数クラウドにまたがる共通 observability platform を作るなら、OpenTelemetry Collector の柔軟性を評価する価値があります。
Application Insights、Log Analytics、Grafana の役割を整理する
今回の更新では、OTLP データを Application Insights でアプリケーション性能の監視、トリアージ、トラブルシューティングに使えることが示されています。また、OTLP メトリックは Grafana ダッシュボードや Prometheus クエリ言語で可視化し、ログやトレースは OpenTelemetry セマンティクスで Log Analytics からクエリできると説明されています。(マイクロソフト)
ここで重要なのは、Azure Monitor を単一の画面として考えないことです。実際の運用では、目的ごとに見る場所が変わります。
| 目的 | 主な利用先 | 判断基準 |
|---|---|---|
| アプリの性能劣化を調べる | Application Insights | リクエスト、依存関係、失敗、レスポンス時間を追いたい |
| メトリックを時系列で監視する | Azure Monitor Metrics / Grafana | SLO、キャパシティ、リソース傾向を見たい |
| ログやトレースを横断検索する | Log Analytics | KQL で原因調査や相関分析をしたい |
| 開発者向けに標準ダッシュボードを作る | Application Insights / Grafana | チームが日常的に見るビューを統一したい |
| 経営・事業向けに状態を見せる | Workbooks / ダッシュボード | 可用性、エラー率、ユーザー影響を簡潔に示したい |
Product owner にとっては、Application Insights の障害・性能分析だけでなく、「顧客影響を説明できる指標」を作れるかが重要です。IT decision-maker にとっては、Log Analytics のデータ量、保存期間、リージョン、アクセス権限がコストとガバナンスに直結します。Technical strategist にとっては、OpenTelemetry の計装をどの程度アプリ共通の標準にできるかが長期的な価値になります。
既存環境では「移行」と「二重取り込み」に注意する
Azure Monitor の方向性を読むうえで、既存エージェントの整理も重要です。Log Analytics agent は 2024年8月31日に retired となっており、Microsoft は Azure Monitor Agent への移行ガイダンスを提供しています。移行では、エージェント数、ワークスペースの使われ方、既存ソリューション、データ収集設定、依存サービスを把握し、パイロットで検証することが推奨されています。(Microsoft Learn)
また、Azure Diagnostics extensions（WAD / LAD）は 2026年3月31日に retire とされ、移行先として AMA と DCR が示されています。DCR では取り込み時のフィルタリングや解析、複数宛先へのルーティングなどが可能で、WAD / LAD よりも集中管理しやすい構成になります。(Microsoft Learn)
移行で失敗しやすいのは、古いエージェントを残したまま新しい収集経路を有効にし、同じデータを二重に取り込んでしまうケースです。これはコスト増だけでなく、アラートの重複、ダッシュボードの誤差、障害調査時の混乱につながります。
既存環境で確認すべき項目
| 確認項目 | 見るべきポイント | 判断 |
|---|---|---|
| 既存エージェント | MMA / OMS、WAD / LAD、Dependency Agent、AMA の有無 | 古い経路を棚卸しする |
| ワークスペース | Log Analytics workspace が乱立していないか | 統合・用途分離を検討する |
| Application Insights | Classic SDK、OpenTelemetry Distro、接続文字列の状態 | 新規アプリは OpenTelemetry 前提に寄せる |
| データ量 | 健康チェック、低価値ログ、重複ログが多くないか | フィルタリングやサンプリングを検討する |
| 権限 | Managed Identity、DCR への書き込み権限 | 最小権限で標準化する |
| ネットワーク | 送信先エンドポイント、プロキシ、HTTPS inspection | 取り込み失敗の原因を事前に潰す |
今後の運用方針：プレビューを「標準化の実験場」として使う
今回の AMA 経由 OTLP 取り込みは、現時点では本番の監視基盤を丸ごと置き換える材料ではありません。しかし、将来の Azure Monitor 運用を設計するうえで、かなり有用な検証テーマです。
おすすめは、次のような段階的アプローチです。
まずは対象ワークロードを絞る
最初の検証対象は、以下の条件を満たすアプリが向いています。
- Azure VM、VM Scale Sets、Azure Arc 対応サーバー上で動いている
- すでに OpenTelemetry SDK を使っている、または導入しやすい
- 本番影響が限定的な dev / test 環境がある
- Application Insights や Log Analytics で見たいユースケースが明確
- 既存の監視経路との比較ができる
反対に、ミッションクリティカルな本番アプリ、規制要件が厳しい本番ログ、既存監視が複雑で責任分界が不明な環境は、最初の対象から外したほうが安全です。
検証では「データが届いた」だけで終わらせない
OTLP 取り込みの検証でありがちな失敗は、テレメトリが Azure Monitor に表示された時点で成功と判断してしまうことです。実際には、運用に使えるかどうかを次の観点で確認する必要があります。
| 検証観点 | 確認内容 |
|---|---|
| 完全性 | トレース、メトリック、ログが必要な粒度で届いているか |
| 相関 | request、dependency、log、exception を同じ操作単位で追えるか |
| 遅延 | 障害対応に使える時間内に表示されるか |
| コスト | 取り込み量が想定を超えていないか |
| セキュリティ | 個人情報、認証情報、プロンプトなどが不要に送信されていないか |
| 権限 | DCR、Managed Identity、ワークスペースへのアクセスが過剰でないか |
| 運用性 | チームがダッシュボード、アラート、KQL を使いこなせるか |
特に、OpenTelemetry データのフィルタリングは早めに設計すべきです。Microsoft Learn でも、ヘルスチェックのようなノイズの削減、個人情報や資格情報の収集防止、低価値テレメトリの除外が、パフォーマンス最適化やコンプライアンス対応に役立つと説明されています。(Microsoft Learn)
経営・製品・技術の視点で見る判断基準
Azure Monitor のロードマップを読む記事として重要なのは、技術的な新機能を「誰が何を判断する材料にするか」まで落とし込むことです。
| 読者 | 注目すべき判断 | 実務での問い |
|---|---|---|
| Product owner | 顧客体験を説明できる監視になっているか | 障害時に「どの機能が何人に影響したか」を示せるか |
| IT decision-maker | 標準化とコスト統制に効くか | エージェント、DCR、ワークスペースを組織標準にできるか |
| Technical strategist | 将来の拡張性があるか | OpenTelemetry を共通言語にして、Azure / hybrid / multicloud を横断できるか |
| Platform engineer | 運用負荷が下がるか | Collector を増やすべきか、AMA に寄せるべきか |
| Security / compliance | データの所在と内容を制御できるか | DCR、フィルター、権限、リージョンを監査可能にできるか |
このアップデートを単に「AMA が OTLP を受けられるようになった」と読むと、価値を見誤ります。より重要なのは、Azure Monitor が OpenTelemetry 標準、AMA、DCR、Application Insights、Log Analytics、Grafana を組み合わせた運用基盤 へ進んでいることです。
90日で進める Azure Monitor 運用見直しプラン
中期的な運用方針を作るなら、次の90日プランが現実的です。
| 期間 | やること | 成果物 |
|---|---|---|
| 0〜30日 | 既存の監視経路、エージェント、SDK、ワークスペース、データ量を棚卸しする | 監視アーキテクチャの現状図、移行リスク一覧 |
| 31〜60日 | AMA 経由 OTLP の検証環境を作り、DCR、Managed Identity、Application Insights、Log Analytics の動作を確認する | パイロット結果、必要な設定テンプレート |
| 61〜90日 | コスト、データ品質、アラート、ダッシュボード、運用手順を評価し、標準化方針を決める | Azure Monitor 標準設計、DCR 命名規則、移行ロードマップ |
この段階では、全アプリを一気に移行する必要はありません。むしろ、1〜2個の代表的なアプリで「OpenTelemetry 計装」「AMA 経由の取り込み」「DCR 管理」「Application Insights / Log Analytics での調査」までを通しで確認することが重要です。
失敗しやすいポイントと回避策
プレビュー機能を本番標準にしてしまう
パブリックプレビューは将来性を確認するには有用ですが、SLA やサポート条件の面で本番標準として扱うには慎重さが必要です。まずは dev / test、社内向けアプリ、影響範囲の限定されたサービスで評価しましょう。
OpenTelemetry だけで設計が完結すると考える
OpenTelemetry は計装とテレメトリ転送の標準化に役立ちますが、Azure Monitor 側の保存先、クエリ、ダッシュボード、権限、コスト管理は別途設計が必要です。特に Application Insights の体験を使う場合は、Azure 側の要件に合わせた属性やメトリック設定を確認してください。
DCR を大きく作りすぎる
1つの DCR に多くのデータソースと宛先を詰め込むと、変更の影響範囲が広がります。アプリ、環境、データ種別、送信先のいずれかで分割し、テンプレート化して管理するのが現実的です。
データ量とコストを後回しにする
OpenTelemetry は便利ですが、何でも送るとログ・トレース・メトリックの取り込み量が増えます。ヘルスチェック、静的ファイル、低価値な詳細ログ、個人情報を含む可能性のある属性は、早い段階でフィルタリングやサンプリングを検討しましょう。
既存監視との二重運用を放置する
移行期には、旧 SDK、旧エージェント、AMA、Collector が並存しがちです。二重取り込みや重複アラートを避けるため、移行完了後にどの経路を止めるかまで計画に含める必要があります。
Azure Monitor の今後を見据えた結論
Azure Monitor native OTLP ingestion via Azure Monitor Agent enters public preview は、Azure Monitor のロードマップを読むうえで重要な節目です。今回の更新は、Azure Monitor が OpenTelemetry / OTLP を取り込み、AMA と DCR を軸に、VM、Arc、AKS、ハイブリッド環境を横断する監視基盤へ進んでいることを示しています。
現時点で取るべき行動は、次の3つです。
1つ目は、既存の監視経路とエージェントを棚卸しすることです。Log Analytics agent、WAD / LAD、Classic Application Insights SDK、Collector、AMA が混在していないかを確認します。
2つ目は、OpenTelemetry を新規アプリの標準計装候補にすることです。特にサーバーサイドアプリや AI エージェントを含むモダンなアプリケーションでは、将来の拡張性を考えて OpenTelemetry 前提の設計を検討する価値があります。
3つ目は、AMA と DCR を単なる設定項目ではなく、組織の observability governance として設計することです。どのデータを、どの粒度で、どの地域の、どの保存先に送るかを決めることが、今後の Azure Monitor 運用の成否を左右します。
このプレビューをきっかけに、Azure Monitor を「監視ツール」ではなく、アプリケーション、インフラ、ハイブリッド環境、事業指標をつなぐ標準化された observability platform として再設計することが、次に取るべき実務的な一歩です。
コメント