Azure Monitorとは？監視の仕組み・Log AnalyticsとApplication Insightsの関係・料金モデルとDatadogとの違いを実装者目線で解説

Azure MonitorはMicrosoft Azureの統合オブザーバビリティサービスで、クラウドやハイブリッド環境のメトリック・ログ・トレース・イベントを1つの監視基盤に集めて、システムの正常性とパフォーマンスを可視化します。実装で最初に押さえるべきは、データを収める2種類のワークスペース（Log AnalyticsワークスペースとAzure Monitorワークスペース）、アプリ監視を担うApplication Insights、そして「取り込んだデータのGB量」でほぼ費用が決まる従量課金の料金構造です。この記事では定義から、データ収集規則での収集設計、KQLでの使用量と障害の調査、アラートとAutoscale、料金の内訳とコスト管理、Datadogとの使い分け、そして「どんなシステムで採用し、どこでは見送るか」の判断基準までを、2026年9月時点のMicrosoft Learnを一次情報として実装者向けに整理します。

まとめ：Azure Monitorの要点とコスト設計・採用判断の分岐

Azure Monitorは、Azureの各リソースが標準で吐き出すメトリックとログを収集し、Application InsightsでのAPMやアラート、自動スケールまでを一体で提供する監視プラットフォームです。データはKQLで分析するLog Analyticsワークスペースと、PromQLで分析するAzure Monitorワークスペースに分かれて格納され、この2つの違いが設計と費用の起点になります。

料金は従量課金で、プラットフォームメトリックの収集やアクティビティログ、アラートの一部は無料。費用の大半はLog Analyticsへのログ取り込み（GB課金）と保持で決まります。取り込み価格には31日間のAnalytics保持が含まれるため、保持を31日未満へ下げてもコストは下がらない、といった実務上の分岐点も公式ドキュメントに明記されています。採用が合理的なのは、Azure中心の環境をポータルと同じ画面で監視し、追加SaaSを増やさずに可観測性をそろえたい場合。逆に、AWS・GCPを含む複数クラウドや多数のSaaSを横断して1画面で見たいならDatadogのようなサードパーティが向きます。どの範囲をどのワークスペースで受け、取り込み量をどう抑えるかは月次コストへ直結するので、監視設計の段階から運用を見据えて詰めておくと後の作り直しを避けられます。

Azure Monitorの全体像とデータプラットフォームの構造

Azure Monitorを理解する起点は、「どんなデータを集め、どこに格納し、何で分析するか」という一本の流れです。ここを押さえると、料金も分析手段も同じ筋で読めます。

統合オブザーバビリティサービスとしての定義と収集するデータ種別

Azure Monitorは、クラウドおよびハイブリッド環境からのテレメトリを収集・分析・操作するMicrosoftの統合可観測性サービスです（Azure Monitor の概要／Microsoft Learn・2026年9月時点）。扱うデータはメトリック（数値の時系列）、ログ（構造化・非構造化のイベント記録）、トレース（分散処理の追跡）、イベントの4種で、これらを1つの監視エクスペリエンスにまとめます。Azureサービスのほとんどは、起動した時点でプラットフォームメトリックとアクティビティログを自動的に生成するため、監視の初期データは追加設定なしで集まり始める設計です。Defender for CloudやMicrosoft Sentinelも同じデータプラットフォーム上で動くので、監視とセキュリティで基盤を共有できます。SIEM側の設計はMicrosoft Sentinelの仕組みと料金モデルを整理した記事で扱っています。

Log AnalyticsとAzure Monitorワークスペースの違いと使い分け

データプラットフォームの中心には、用途の異なる2種類のワークスペースがあります。名前は似ていますが、格納するデータとクエリ言語が別の、独立したリソースです。

Log Analyticsワークスペースは、KQLで横断検索・集計できるログとトレースの受け皿で、Azure Monitorの費用が最も乗りやすい場所になります。ワークスペースを分割するかどうかの判断軸やテーブルプランごとの課金差は、Azure Log Analyticsとは？ワークスペース設計・KQL検索・テーブルプラン別の保存コストで詳しく整理しました。一方のAzure Monitorワークスペースは、KubernetesなどのPrometheusメトリックをPromQLで扱う専用ストアで、Grafanaダッシュボードと組み合わせて使う設計です。自前でPrometheusを立てる場合との比較はPrometheusで監視を構築する手順の記事が参考になります。設計時にどのデータをどちらへ流すかを決めることが、後述の料金設計の前提になります。

Azure Monitorエージェントとデータ収集規則で収集対象を決める

Azureリソース自身のメトリックとログは自動で集まりますが、それ以外は収集を明示的に設計します。ここが取り込み量、つまり費用を決める最初の分岐です。

Azure Monitorエージェントを入れてデータ収集規則を割り当てる

仮想マシンやサーバーの中身（OSのイベントログ・パフォーマンスカウンター・カスタムログ）は、Azure Monitorエージェント（AMA）を入れて集めます。何を、どの頻度で、どのワークスペースへ送るかはデータ収集規則（DCR）で定義し、データ収集規則の関連付け（DCRA）でリソースへ割り当てます。この関係は多対多で、1つのリソースには最大30個のDCRを関連付けられる仕様です。DCRはAzureリソースとして格納されるため、Resource Managerテンプレートやコマンドラインで監視構成をコード管理下に置けます。DCRは従来方式の置き換えでもあり、Log Analyticsエージェントの後継がAMA、データコレクターAPIの後継がログインジェストAPI、という対応関係は公式に示されているとおりです。監視対象となるVM側の構成はAzure Virtual Machinesの仕組みと料金モデルの記事と合わせて読むと、エージェント配置の判断がしやすくなります。Azure Arcの基盤技術を解説した記事のとおり、Arcで接続すれば他クラウドやオンプレミスのサーバーも同じDCRの枠組みで扱えます。

取り込み前の変換（transformKql）で不要なログを落とす

変換（transformation）は、受信した各レコードに対して実行されるKQLクエリで、DCRのデータフローに書きます。格納前に不要な行を捨て、機微な列を削り、宛先スキーマへ整形できるため、取り込み課金を減らす手段として効きます。次はSyslogからデバッグレベルを落とし、ホストIPとプロセスIDを除いてからLog Analyticsへ送る定義です（Azure CLIやテンプレートでDCRを作成・更新するときの本体部分にあたります）。

{
  "properties": {
    "dataFlows": [
      {
        "streams": [ "Microsoft-Syslog" ],
        "destinations": [ "laDestination" ],
        "transformKql": "source | where SeverityLevel != 'Debug' | project-away HostIP, ProcessID",
        "outputStream": "Microsoft-Syslog"
      }
    ]
  }
}

変換の出力を次の変換の入力にする複数ステージ変換もプレビューで提供され、エージェント側のクライアント変換とAzure側の取り込み時変換を組み合わせられます。DCRはLog Analyticsワークスペースが使える全パブリックリージョンで利用でき、同一地域のペアリージョンへバックアップされ、リージョン内の3つの可用性ゾーンへ展開されるゾーン冗長サービスです。プレビュー扱いの機能は時点で変わるため、採用前に公式の状態表示を確認してください。

メトリックエクスプローラーとKQLで使用量と障害の原因を調べる

集めたデータを見る手段は用途で分かれます。数値の時系列とログ・トレースで道具が違う点を押さえると、調査が速くなります。

メトリックエクスプローラーとブックで正常性を可視化する手順と勘所

数値の時系列はメトリックエクスプローラーで素早くグラフ化し、ログとトレースはLog AnalyticsでKQLを書いて検索・集計する流れになります。KQLはテーブルをパイプでつないで絞り込む問い合わせ言語で、エラーの相関やボトルネックの特定に向いた道具です。PrometheusメトリックはPromQLで扱います。可視化の選択肢は、Azureポータルの組み込みブック（Workbooks）、Grafanaダッシュボード、独自のカスタムダッシュボードの3系統で、ダッシュボード側の版差はGrafana 12と最新版13の違いを整理した記事にまとめました。まず押さえるのはメトリックエクスプローラーとKQLの2つで、この2つで日常の調査の大半はこなせます。

Usageテーブルへのクエリで課金対象の取り込み量を実測する

コストの話を勘で進めないために、最初に書くべきKQLがUsageテーブルへの集計です。直近30日の課金対象データをテーブル別に並べると、どのログが費用を食っているかが数分でわかります。

Usage
| where TimeGenerated between (ago(30d) .. now())
| where IsBillable == true
| summarize BillableGB = sum(Quantity) / 1000 by DataType
| sort by BillableGB desc

Quantityの単位はMBなので、1000で割ってGBに直します。上位に来たテーブルから順に、DCRの変換で行を落とすか、テーブルプランを下げるか、保持を縮めるかを決める流れです。Usageテーブル自体とAzureActivityテーブルは取り込み課金の対象外で、しかも既定で90日以上、無料で保持されます。Application Insights関連のAppRequestsやAppExceptionsなどのテーブルも90日は無料保持の扱いです。「調べるためのログにも課金されるのでは」という心配なしに、まず実測から入れます。

Application Insightsとアラートで検知から自動対応までつなぐ

収集と分析がそろったら、アプリの内部を見る手段と、問題を行動へつなげる手段を組みます。ここがAzure Monitorを「見るだけ」で終わらせないための要です。

Application InsightsでアプリとAIエージェントを監視する

アプリケーションの内部を監視するのがApplication Insightsで、Azure MonitorのOpenTelemetryベースのAPM機能にあたります。応答時間・依存関係・例外・スループットを収集し、リクエストがどのコンポーネントで遅延したかを追跡できる仕組みです。計装の考え方そのものはOpenTelemetry（OTel）の3つのシグナルを解説した記事と、APM（アプリケーション性能監視）の仕組みを整理した記事が土台になります。現時点ではFoundryやCopilot Studio、サードパーティのエージェントフレームワークにまたがる生成AIエージェントの監視にも対応し、トークン消費・待機時間・エラー率・品質スコアといった運用メトリックを組み込みダッシュボードで見られます（2026年9月時点）。Application Insightsは単体の製品ではなくAzure Monitor配下の一機能で、収集データはLog Analyticsワークスペースに格納されます。導入手順やLog Analyticsとの関係の詳細はApplication Insightsの機能と導入を解説した記事で扱いました。

アラートとAutoscale・Issuesで検知から対応まで自動化する

集めたデータを行動につなげるのがアラートとAutoscaleです。アラートは、メトリックやログクエリの条件が満たされたときにアクショングループ経由で通知やワークフローを起動します。機械学習でノイズを減らすAIOps機能もあり、メトリックの変動に追従する動的しきい値や、アプリの異常を捉えるスマート検出が含まれます。関連するアラートを1つの問題へ束ねてトリアージを助けるAzure Monitor の問題（Issues）、自然言語で調査を進めるAzure Copilot Observability Agentも公式ドキュメントに記載されました（2026年9月時点）。Autoscaleは負荷に応じてインスタンスを増減させる機能で、メトリック・スケジュール・その両方の組み合わせでルールを組めます。障害を「気づく」だけでなく「自動で対処する」ところまでを、同じ基盤で設計できるのがAzure Monitorの持ち味です。

Azure Monitorの料金モデルとコスト設計で押さえる勘所

Azure Monitorで最初につまずくのは料金の読み方です。従量課金のどこに費用が乗るかを先に理解すると、設計段階でコストを制御できます。

Azure Monitorで無料の機能と課金対象になる使用量の切り分け

Azure Monitorは使用量ベースの従量課金で、既定で有効な機能の多くは無料です。無料で使えるのは、アクティビティログの収集とそのアラート、Azureリソースの標準（プラットフォーム）メトリックの収集と分析など。費用が生じるのは主に、集めたデータの取り込みと保持にかかります。次の切り分けを押さえておくと見積もりを外しにくくなります。

• 無料：標準メトリックの収集・分析、アクティビティログ、既定のアラート評価の一部
• 課金：Log Analyticsワークスペースへのログ取り込みと保持、カスタムメトリック、Web テスト、Prometheusメトリックの取り込み／クエリサンプル

ほとんどの利用者にとって、費用の最大の構成要素はログデータの取り込み量です。Azure Monitor Logs のコスト計算では、課金対象サイズの数え方も明示されています。_ResourceIdや_ItemIdなどの標準列はサイズ計算から除外され、全イベントを平均すると課金対象サイズは受信データより約25%小さく、小さなイベントでは最大50%小さくなる、という記述です。AzureActivity・Heartbeat・Usage・Operationといったテーブルは取り込み料金が一切かかりません。見積もりを外さないために、この「受信バイト数と課金バイト数は別物」という前提を先に共有しておきます。標準メトリックが無料である一方、カスタムメトリックの収集やREST APIからのメトリック取得には費用がかかる点も、設計時に押さえます。

テーブルプランとコミットメントレベルで取り込み単価を下げる手順

費用の主軸がログ取り込み量である以上、コスト管理は「取り込む量を絞る」と「単価を下げる」の2方向で考えます。量を絞る側では、テーブルプランをテーブル単位で選べる仕組みがあり、頻繁に分析するデータはAnalytics、まれにしか参照しないデータは単価の低いBasic、大量で冗長なデータは最安のAuxiliary（補助／Lake）へ振り分けます。BasicとAuxiliaryは対話型クエリがスキャンGB課金になる点、Auxiliaryに変えたテーブルではアラートが動かなくなる点、プラン変更は1週間にテーブルあたり1回までという制限が、切り替え前に確認したい条件です。Azure CLIなら次の1コマンドで切り替えられます。

az monitor log-analytics workspace table update \
  --resource-group "rg-monitoring" \
  --workspace-name "law-prod" \
  --name "ContainerLogV2" \
  --plan Basic \
  --total-retention-time 730

単価を下げる側では、日次で一定量以上を安定して取り込む場合にコミットメントレベルを選ぶと、従量課金に比べて最大30%安くなります。購入できるのは100 GB/日からで、選択または変更した時点から31日間のコミットメント期間が始まり、期間中は従量課金や下位レベルへ戻せません（誤操作の救済として、構成後6時間以内なら下げられます）。コミットメントレベルが効くのはAnalyticsログの取り込みだけで、BasicとAuxiliaryはGB単位の定額のままである点は取り違えやすいところです。どのレベルが有利かは、Log Analyticsの「使用量と推定コスト」画面で31日間の実績から見積もれます。

保持期間も費用に効きます。データ保持の管理によると、既定の保持は30日、Analyticsプランなら最長2年（730日）まで対話型保持を延ばせ、長期保持を含む合計保持期間は最長12年（4,383日）まで設定できます。ここで効く実務上の注意が2つ。取り込み価格には31日間のAnalytics保持が含まれるため、31日未満へ下げてもコストは減りません。そして合計保持期間を縮めた場合は削除まで30日の猶予があるので、設定ミスは巻き戻せます。データ転送料金も発生しうるものの、通常は取り込み・保持コストに比べると小さいため、まず取り込み量の設計を優先します。実額はリージョンごとに異なるので、見積もりの最終確認はAzure Monitorの価格ページとAzure Monitorのコストと使用量で時点ごとに行ってください。

Datadogなど他の監視ツールとの違いとAzure Monitorの使い分け

監視基盤の選定では、Azure Monitorとサードパーティの監視SaaSがよく並べて比較されます。守備範囲を押さえると、単独で使うか併用するかの判断がつきます。

Azureネイティブの強みとマルチクラウド監視での限界という境界線

Azure MonitorはAzureリソースと深く統合され、各サービスのポータル画面にそのまま監視データが差し込まれる点が強みです。Azure中心の環境なら、追加のエージェントや契約を増やさずに監視を立ち上げられ、開発者にとってコスト効率も出しやすい設計になります。一方で、AWSやGCP、数百のSaaS製品を横断して1つのダッシュボードで見たい要件では、外部連携の幅でDatadogの機能と導入背景を解説した記事で扱うようなマルチクラウド前提の監視SaaSに分があります。判断軸は単純で、監視対象がAzureに閉じるならAzure Monitor、複数クラウドやサードパーティ製品が主戦場ならDatadogのような横断型、という切り分けです。ただしDatadogはホスト数・カスタムメトリック・ログのインデックスなど課金単位が複数あり、費用の膨らみ方がAzure Monitorとは異なります。比較の前にDatadogの料金体系と費用が膨らむ課金単位を整理した記事で両者の課金構造を並べておくと、見積もりの土俵がそろいます。両者は排他ではなく、Azure MonitorのデータをDatadogへ流して統合ビューを作る併用構成も現実的な選択肢です。Microsoft自身もマルチクラウド監視のベストプラクティスとして、Azure Arcでの接続やAzure Monitorパイプラインの配置を案内しています。

Azure Monitorを採用すべき場面と見送るべき場面の判断

ここからは判断です。Azure Monitorは万能の監視基盤ではなく、向く要件と向かない要件がはっきり分かれます。条件から逆算して採否を言い切ります。

Azure Monitorの採用が第一候補として合理的になる主なケースの条件

次のいずれかに当てはまるなら、Azure Monitorが第一候補になります。

• 監視対象がAzureのリソース中心で、ポータルと同じ画面で正常性を見たい
• アプリのAPMからインフラのメトリック、ログ検索までを1つの基盤にそろえたい
• アラートからAutoscaleやアクショングループでの自動対応まで一貫して組みたい
• 追加の監視SaaSを契約せず、取り込み量の設計で費用を制御したい

いずれもAzureネイティブの統合が効く領域です。標準メトリックとアクティビティログが無料で集まるため、小さく始めて、必要なログだけを課金対象のワークスペースへ足していく段階的な進め方が、初期費用のハードルを下げます。

Azure Monitorを選ぶべきでない場面と適切な代替の選択

一方で、次の要件にはAzure Monitorを主軸に据えません。第一に、AWS・GCPを含む複数クラウドや多数のSaaSを横断し、1画面で統合監視したいなら、外部連携の幅で勝るDatadogのような横断型SaaSが適します。第二に、ログの取り込み量が読めないまま全リソースの詳細ログを無制限に流すと、Log Analyticsの取り込み課金が膨らみやすく、テーブルプランや保持設計をしないままの導入は費用面で破綻しやすくなります。第三に、KQLやデータ収集規則を運用できる人手が社内になく、監視の設計・チューニングまで含めて外部に委ねたい場合は、ツール単体の導入より運用体制の確保を先に検討すべきです。

受託開発における監視基盤の設計・運用支援と外注先選定での勘所

実際の運用では、Azure Monitorを入れること自体より、どのデータをどのワークスペースで受け、どの保持期間で持ち、どのしきい値でアラートを鳴らすかという設計が成果を左右します。ここを詰めずに全ログを流すと、費用は膨らむのに肝心の障害検知は遅れる、という状態に陥りがちです。Azureそのものの土台づくりから相談したい場合はAWS・Google Cloud・Azureのインフラ構築支援が入口になります。監視の設計、KQLでのダッシュボード整備、アラート運用の内製化までを含めて、システムの保守運用・監視体制の構築や内製化の相談では、可観測性の設計から日々の運用定着までを一貫して支援できます。導入後のコスト膨張や検知漏れを避けるには、監視方針を要件定義の段階から固めておくのが近道です。

よくある質問

Azure Monitorの実装検討でよく挙がる質問を、公式ドキュメントの仕様に沿って整理します。

Azure MonitorとApplication Insightsはどう違いますか？

包含関係にあります。Azure Monitorがメトリック・ログ・トレースを扱う監視プラットフォーム全体で、Application Insightsはその中でアプリケーションのパフォーマンス監視（APM）を担う一機能です。Application Insightsが収集した応答時間や例外などのデータは、Azure MonitorのLog Analyticsワークスペースに格納されます。アプリの内部挙動を追うのがApplication Insights、インフラを含む全体を束ねるのがAzure Monitor、という関係になります。

Log AnalyticsとAzure Monitorワークスペースの違いは何ですか？

格納するデータとクエリ言語が異なる別リソースです。Log Analyticsワークスペースはログとトレースを受け、KQLで分析します。Azure MonitorワークスペースはPrometheusやOpenTelemetryのメトリックを受け、PromQLで分析する役割です。名前が似ているため混同されやすいものの、設計上は別々に作成・管理するリソースで、どのデータをどちらへ送るかを分けて設計します。

Azure Monitorの料金はどのように決まりますか？

使用量ベースの従量課金で、費用の大半はLog Analyticsワークスペースへのログ取り込み量（GB）と保持で決まります。標準メトリックの収集・分析やアクティビティログの収集は無料です。取り込むテーブルのプラン（Analytics／Basic／Auxiliary）の選択、コミットメントレベルによる割引、保持期間の設定でコストを管理します。詳細な単価はリージョンごとに異なるため、Azure Monitorの価格ページで時点ごとに確認してください。

Azure Monitorの取り込み量を減らすにはどうすればよいですか？

効く順に3つあります。まずUsageテーブルへのKQLでテーブル別の課金量を実測し、上位を特定するのが最初の手順です。次にデータ収集規則の変換（transformKql）で、格納前に不要な行と列を落とします。最後にテーブルプランをBasicやAuxiliaryへ下げ、保持期間をテーブル単位で必要最小限にします。取り込み価格には31日間のAnalytics保持が含まれるので、保持を31日未満へ短くしても費用は下がりません。

コミットメントレベルはどのくらいの取り込み量から得になりますか？

購入できるのは100 GB/日からで、従量課金と比べて最大30%の割引になります。適用されるのはAnalyticsログの取り込みだけで、BasicログとAuxiliaryログは対象外です。選択または変更した時点から31日間のコミットメント期間が始まり、期間中に下位レベルや従量課金へは戻せません（構成後6時間以内なら下げられます）。判断材料は、ワークスペースの「使用量と推定コスト」画面に出る31日間の実績と各レベルの見積もりです。

Azure Monitorで他クラウドやオンプレミスも監視できますか？

できます。Azure Arcを使って他クラウドやオンプレミスのサーバーをAzureに接続すると、Azureリソースと並べて同じ基盤で監視できるのが利点です。大規模なデータ量や断続的な接続の環境向けには、Azure Monitorパイプラインを配置して、データ収集機能を自社データセンターや他クラウドへ広げる方法も用意されています。Azureに閉じない構成でも、ハイブリッド監視の中心として使えます。

Azure MonitorとDatadogはどちらを選ぶべきですか？

監視対象の広がりで分かれます。Azureのリソースが中心なら、ネイティブ統合とコスト効率でAzure Monitorが有利です。AWS・GCPを含む複数クラウドや多数のSaaS製品を横断し、1つのダッシュボードで統合監視したいなら、外部連携の幅でDatadogのような横断型SaaSが向きます。課金単位の構造が違うので、ホスト数やログのインデックス量まで含めた試算で比べてください。両者は併用も可能で、Azure MonitorのデータをDatadogへ集約する構成も選べます。

関連記事

• Azure Log Analyticsとは？ワークスペース設計・KQL検索・テーブルプラン別の保存コストを実装者目線で解説：本記事の料金設計をワークスペース単位で深掘りできます。
• Application Insightsとは？機能・料金・導入手順とLog Analyticsとの違い【2026年版】：Azure Monitorのアプリ監視（APM）機能を単体で深掘りできます。
• Datadogとは何か？機能やメリット、導入の背景を詳しく解説：マルチクラウド監視の選択肢として、Azure Monitorとの使い分けを読み比べられます。
• Microsoft Sentinelとは？クラウドネイティブSIEM/SOARの仕組み・料金モデル・Defenderポータル統合を実装者目線で解説：同じデータプラットフォーム上で動くセキュリティ側の設計を確認できます。