Azure Monitorで実現するオブザーバビリティ | VM監視を成功させる5つの実践ステップ

セキュリティ

蒔苗純平

2026年03月24日

はじめに

はじめまして、株式会社メンバーズ25卒の蒔苗です。

近年、サイバー攻撃が増えてきており、2025年上半期のランサムウェア被害報告件数は116件と、前年後半に続き過去最多を記録しております。こうした攻撃に対し、完璧な防御を敷くことは困難です。そこで重要となるのが「異常検知」ですが、単に検知するだけでは不十分です。「なぜその異常が発生したのか」という根本原因を迅速に特定できなければ、対策もままなりません。ここで鍵となるのが、オブザーバビリティ（可観測性）です。

システムを「外から監視する」だけでなく、内部で「何が、なぜ起きているのか」を詳細に把握できる状態を整えることは、セキュリティインシデントへの迅速なレスポンスのみならず、日常的なパフォーマンス向上やトラブルシューティングにおいても不可欠な戦略となります。

本記事では、このオブザーバビリティの基本概念を整理した上で、Azure VMを対象としたテレメトリデータの収集から通知までの一連の流れに沿って、Azure Monitorを中心としたサービスの役割分担について解説します。

オブザーバビリティについて

オブザーバビリティ（可観測性：Observability）とは、システムの外部出力（データ）を分析することで、その内部の状態をどれだけ深く理解できるかという能力のことです。

「監視（モニタリング）」との違い

従来の「監視」と「オブザーバビリティ」は似ていますが、目的が異なります。

監視：あらかじめ決められたルールに基づき、「異常が起きているか」を確認することに重点を置きます。
オブザーバビリティ：収集したデータを詳細に探ることで、「なぜその問題が起きているのか」という、予測できない未知の原因を突き止める能力を指します。

オブザーバビリティを支える「3つの柱」

システムの状態を把握するために、主に以下の3種類のデータ（テレメトリー）を組み合わせて分析します。

メトリクス：システムの性能を表す数値データ。
ログ：OSやアプリで発生したイベントのテキスト記録。
トレース：1つのリクエストが複数のサービスをまたいで処理される流れを追跡したデータ。

Azure Monitorを使ったオブザーバビリティの実践方法

Azureにおけるオブザーバビリティは、独立した複数のツールを使い分けるのではなく、「Azure Monitor」という単一のプラットフォームに集約して考えるのが基本です。
リソースのメトリクス、OSのログ、アプリのトレースが同じ基盤（Azure Monitor）に集まることで、それらを横断して分析できます。

今回は、Azure VMのオブザーバビリティに焦点を当て各ステップに分けて解説していきます。

収集：オブザーバビリティの起点となるデータの取得

まず、オブザーバビリティの出発点は「データの取得」です。ここでは、3本の柱である、メトリクス、ログ、トレースについて、Azure Monitorを中心とした各サービスでどのようなデータを取得できるのかを整理していきます。

メトリクス

プラットフォームメトリクス
AzureがVMの外側から取得するメトリクスです。
CPU使用率、ディスク、ネットワークの基本的な利用状況など、まず「異常の兆候」を最短で検知するのに向きます。

ゲストOS メトリクス（パフォーマンスカウンター等）
メモリ使用量、プロセス、OS内部のより詳細な状態は、VM内（ゲスト OS）から取得する必要があります。
そのため、Azure Monitor Agent（AMA）をVMに導入し、Data Collection Rule（DCR）で収集対象を定義してAzure側へ送ります。

カスタムメトリクス
リクエスト件数、キュー長、注文数などアプリ固有の指標は、アプリケーションの計装（SDKなど）で送信します。

ログ

ログは「何が起きたか」を具体的に残すテレメトリで、Azure VMでは主に次を収集します。

OSログ：Windows Event Log、Linux Syslog
ミドルウェア・アプリログ：nginx / apache、アプリの出力ログ、ジョブログなど

これらをAzure側へ送る方式が、Data Collection Rule（DCR）とAzure Monitor Agent（AMA）です。

Data Collection Rule（DCR）
DCRは、「どのログを、どの粒度で、どこへ送るか」を定義する設計図のような存在です。

例えば、

syslogのerror以上のみ収集する
nginxのアクセスログをカスタムログとして取得する
といった制御が可能です。

Azure Monitor Agent（AMA）
AMAは、実行中のプロセスにアクセスしてログやパフォーマンスデータを集めるためのエージェントです。

最大の特徴は、前述のDCRとセットで動く点にあります。DCR に従ってデータを転送します。従来の古いエージェント（Log Analytics エージェント）に比べ、マネージドIDによる安全な認証や、必要なデータだけを絞り込んで送ることによるコスト削減、スループットの改善（25%）が大きな強みです。

トレース

トレースは、1つのユーザーリクエストが複数コンポーネントをまたいで処理されるときに、
「どこで遅くなったか」「どこで失敗したか」を追跡するためのテレメトリです。

AzureではApplication Insightsを中心に扱うことが多く、基本はアプリケーションをSDK（例：OpenTelemetry）で計装して送信します。送信先は「Connection string」で指定します。

メトリクスやログだけでは「遅いのはDBか、APIか、外部依存か」を切り分けにくい場面で、トレースは効果を発揮します。

データの保存：Log Analytics Workspaceを活用した効率的な管理

集めたデータを、後から分析できる状態で適切に保存しておくことも重要です。
この保存設計を誤ると、

必要なログが残っていない
保存期間が短く、原因追跡ができない
コストが想定以上に膨らむ

といった問題が発生します。

Azureでは、以下のサービスを利用して保存します。

メトリクス：Azure Monitor Metrics

CPU使用率やネットワーク量などの数値の時系列データは、Azure Monitor Metricsの時系列データベースに保存されます。
VMの「異常の兆候」を素早く捉える用途に強く、ダッシュボードやアラート設計の起点になります。
※ メトリクスは保持期間に上限があるため、長期分析が必要な場合は別の保存先へのエクスポートが必要になります。

設計ポイント

メトリクスは軽量で即時性に優れますが、メトリクスだけでは原因追跡が完結しないことが多いので、メトリクスを入口にして、ログ（Log Analytics）やトレース（Application Insights）へ調査をつなげる前提で設計する

ログ：Log Analytics Workspace

Log Analytics WorkspaceはAzure Monitor Logs（ログ基盤）の実体で、OSログやミドルウェアログ、アプリログなどのイベントデータをテーブルとして保存します。
ワークスペース設計により、複数のログソースを同じ基盤で横断して分析できます。

設計ポイント

保持期間：遡及調査の要件から決める（必要に応じてアーカイブで長期保存する）
ワークスペース統合・分割：横断分析のしやすさと、権限境界・請求境界の両立を考える
取り込み量：コストは主に取り込み量と保持期間で換算されるため、収集側（DCR）で不要データを絞る前提にする

以下はAzure VMのSyslogを取得した際のデータになります。 LevelやIP、メッセージなど基本的なデータは取れていることがわかります。

Azure VMのSyslogを取得した結果

トレース：Log Analytics Workspace

現在の一般的な構成（ワークスペースベース）では、トレースはLog Analytics Workspaceに保存され、KQLで横断的に分析できます。

設計ポイント（保存観点）

保持期間の整合：ログの保持要件と揃えるか、テーブル単位で差をつけるか決める
属性設計：URL（クエリ文字列）やuserIdなどの扱いは、検索性・コストだけでなく機微情報リスクにも影響するため、必要最小限にする（または、マスクする）

Go製アプリケーションにOTelで計装し、Application Insightsで収集した際のログ

データの分析：メトリクスやKQL、Application Insightsを用いた根本原因の特定

収集・保存したテレメトリは、ただ蓄積しただけでは価値になりません。
運用で重要なのは、原因を素早く特定し、次の打ち手につなげることです。
ここでは、Azure Monitorを使った分析の基本フローを、サービス単位で整理します。

Azure Monitor Metrics

分析の出発点は、多くの場合はメトリクスです。
例えば、

CPU使用率が急上昇している
5xxエラー率が増加している
レスポンスタイムが悪化している

こうした数値の変化は「異常の兆候」を示します。

Azure VMのメトリック表示例（CPU使用率やネットワークなど）

メトリクスは、軽量で時系列分析に優れているため、傾向やスパイクの検出に向いています。ただし、メトリクスはあくまで「症状」です。原因そのものを示すわけではありません。そのため、次の段階へ進む必要があります。

メトリクスで異常を検知した後は、ログ分析に進みます。

Log Analytics Workspace

Log Analyticsでは、KQL（Kusto Query Language）を用いて、

特定時間帯のエラー抽出
異常なIPアドレスの特定
例外発生回数の集計

といった高度な検索・分析が可能です。

例えば、5xxエラーが増加している場合、

どのエンドポイントで発生しているのか
どのIPからのアクセスが多いのか
特定の時間帯に集中していないか

を調査できます。

KQL実行例（nginxのカスタムログをもとにしたステータスコードの推移）

ログは「何が起きたか」を具体的に示す証拠となります。

Application Insights

さらに深掘りする場合、トレースが重要になります。
APIのレスポンスが遅い場合、その遅延が

データベース処理なのか
外部APIの呼び出しなのか
特定のマイクロサービスなのか

を追跡する必要があります。

Application Insightsでは、リクエスト単位で処理の流れを可視化できるため、「どこで遅延が発生しているのか」という因果関係を把握できます。

Application Insightsの依存関係を表すマップ

次の「可視化」では、この分析の流れを日常運用に落とし込むための見せ方を設計していきます。

データの可視化：Workbooksやダッシュボードによる「気づき」の設計

収集し、保存し、分析できる状態が整っても、その結果が適切に可視化されていなければ運用の現場では活かされません。
可視化の役割は「データを直感的に理解できる形に整え、異常に素早く気づけるようにすること」です。

Azureでは、目的に応じて複数の可視化サービスが用意されています。

Azure Portal ダッシュボード

日常的な状態確認であれば、Azure Portal のダッシュボード機能が手軽です。
メトリクスのグラフなどをタイル形式で並べるだけで、主要リソースの状態を俯瞰できます。

向いている用途

毎日見るための健康状態確認
重要メトリクスの固定表示（CPU、エラー率、レイテンシなど）

Azure Monitor Workbooks

より運用・分析に踏み込むなら、Azure Workbooksが有効です。
Workbooksは、KQLクエリによるログ分析結果とグラフ、説明テキスト、パラメータ入力（期間・リソース選択など）を組み合わせて表示できます。

単なるグラフではなく、「こうなったら次にこれを見る」という調査の流れまで含めて構成できるのが強みです。

向いている用途

トラブルシューティング手順のテンプレ化（一次切り分けの標準化）
月次・週次レポート（SLO/稼働状況のまとめ）
チーム内の知見共有（属人化の解消）

他サービス

他にも以下のようなサービスもあります。

Azure Managed Grafana：他クラウドや外部サービスのデータも含めて統合ダッシュボードを作成可能
Power BI：監視データをKPIやコストなどのビジネス指標と組み合わせ、月次・経営レポートとして可視化

このようにAzureでは、可視化は一つの機能ではなく、目的に応じたサービスの使い分けで実現されます。

可視化の本質は、情報を増やすことではありません。むしろ、

何を常に見るべきか
異常時に何が変化するか
次の分析へどうつなげるか

を設計することにあります。

収集と保存が「データの準備」だとすれば、可視化は「気づきの設計」です。ここまで整って初めて、次の段階である「通知」が意味を持つようになります。

アラートと通知：Action Groupsを使った「行動につながる」通知設計

可視化によって状態を理解できるようになっても、常に画面を見続けることは現実的ではありません。そこで必要になるのが通知です。
通知の役割は、「異常が発生した瞬間に、適切な人へ確実に伝えること」にあります。

Azureの通知はAzure Monitor Alertsを中心に構成し、

アラートルール：何を異常とみなすか
アクショングループ：誰にどう伝えるか、何を自動実行するか
アラート処理ルール：通知の抑止、メンテナンス時間帯の制御など

を組み合わせて設計します。

Azure Monitor Alerts

メトリクスアラート
CPU使用率が一定値を超えた、エラー率が閾値を超えた、レスポンスタイムが悪化したなど、数値の変化に基づいて発火します。
リアルタイム性が高く、VM運用の基本となるアラートです。

ログアラート
Log Analyticsに保存されたログに対してKQLクエリを定期実行し、条件一致したら通知します。
例外メッセージ、特定エンドポイントの5xx増加、怪しいIPの集中など、メトリクスでは表現しづらい条件検知に向いています。

アクティビティログアラート
リソース削除、設定変更、ポリシー変更などの管理操作を検知します。
セキュリティ・ガバナンス観点で重要なアラートになります。

Action Groups（通知と自動化の実行先）

アラートが発火した後、実際に「誰に・どう伝えるか」「何を実行するか」を担うのがAction Groupsです。代表的には次を設定できます。

メール通知
Teams / Slack（Webhookや連携）
Webhook
Logic Apps 連携（自動化フロー）

この仕組みにより、単なる通知にとどまらず、一次対応の自動化（チケット起票、フェイルオーバー連携など）にも繋げられます。

通知設計の要点

ただ、通知が多ければ良いわけではありません。過剰なアラートはアラート疲れを引き起こし、結果として重要な通知が見逃されます。
そのため、設計では次を明確にします。

SLOに直結する指標を優先する（ユーザー影響が出るものから）
影響の大きい異常に絞る（ノイズを減らす）
再通知・抑止（ノイズ制御）を設計する（一時的な揺れ・既知事象で鳴らし続けない）

通知は「検知」ではなく「行動」を起こすための仕組みです。
誰が見て、何を判断し、次にどの分析へ進むかまで含めて設計しておくと、運用で機能するアラートになります。