Azure Monitorのアラートと自動化を実務目線で解説｜診断設定・アクショングループ・動的しきい値・Workbooks・Autoscale

Azure Monitorをひととおり触って「メトリックのグラフも見られるし、ログも溜まってきた」となったあと、次にぶつかるのが「で、この監視、誰がずっと見張るの？」という問題です。CPUが跳ねても、ディスクが埋まっても、夜中に人がダッシュボードを眺めていなければ気づけません。監視を「見るだけ」で終わらせていると、結局は障害が起きてから慌てて画面を開くことになります。

そこで効いてくるのが、この記事のテーマであるアラートと自動化です。異常を自動で検知して、メールで知らせたり、さらには人の手を介さずに自動で対処・スケールさせたりする——ここまで組んで、はじめて監視は「運用」になります。私自身、最初は「アラートってメトリックにしきい値を付けるだけでしょ」と軽く見ていて、動的しきい値やアクショングループの自動対応まで来てようやく「監視ってこんなに手を離せるのか」と実感しました。

「アラートを飛ばすところまでは分かる。でも『自動で直す』とか『自動でスケールする』って、どう繋げばいいの？そこが未知の領域なんだよね……」

この記事では、Azure Monitorの診断設定・アクショングループ（通知と自動対応）・メトリック／ログアラートの使い分け・動的しきい値・Workbooks・Autoscaleまでを、公式ドキュメント（Microsoft Learn）の内容を押さえつつ、初心者がつまずく所を噛み砕いて解説します。読み終わるころには、監視を「見るだけ」から「自動で動く」へ引き上げる全体像が描けるようになります。

なお、そもそもAzure Monitorが何を集めて何ができるサービスなのか、全体像があやふやな方は先に Azure Monitorとは（親記事・全体像）に目を通しておくと、この記事の位置づけがはっきりします。本記事はその中の「アラートと自動化」を深掘りする子記事です。

まず全体の流れをつかむ：検知→通知→対処
診断設定：ログとメトリックの「送り先」を決める
メトリックアラートとログアラートの使い分け
動的しきい値：しきい値を機械学習に決めさせる
アクショングループ①：メール・SMSで「通知」する
アクショングループ②：RunbookやFunctionsで「自動対処」する
Workbooks：監視を「見せる」ダッシュボードにする
Autoscale：負荷に応じて「器」を自動で増減する
まとめ：監視を「見るだけ」から「自動で動く」へ
Azureのスキルを「年収」に変えるなら

まず全体の流れをつかむ：検知→通知→対処

細かい設定に入る前に、アラートと自動化の登場人物の関係だけ頭に入れておくと、あとで迷いません。火災報知器にたとえると分かりやすいです。

アラートルールは「煙を感知するセンサー」です。CPUが80%を超えたら、エラーログが5分で10件出たら——といった「どうなったら鳴らすか」の条件を決めます。そして条件を満たすと発報しますが、センサー自体は音を出しません。実際に「ベルを鳴らす」「消防に通報する」役を担うのがアクショングループです。メールを送る、SMSを飛ばす、さらにはスプリンクラーを作動させる（＝自動で対処する）ところまでを引き受けます。

つまり流れはいつも「アラートルールで検知 → アクショングループで通知・対処」という二段構えです。この分業を押さえておくと、以降の「どのアラートを使うか」「通知先をどう組むか」という話が一本の線でつながります。加えて、アラートの手前でログを溜める診断設定、可視化するWorkbooks、負荷に応じて器を増やすAutoscaleが周辺に並ぶ、という地図でこの記事を進めます。

診断設定：ログとメトリックの「送り先」を決める

アラートを賢くするには、まず材料となるログとメトリックを適切な場所へ送っておく必要があります。それを担うのが診断設定（Diagnostic settings）です。

ここで最初に区別しておきたいのが、メトリックとリソースログ（診断ログ）の違いです。メトリックは「CPU使用率」「リクエスト数」のような、数値が時系列で並ぶデータ。これは各リソースが自動で集めていて、ポータルのグラフですぐ見られます。一方のリソースログは「いつ、誰が、何をした」「どんなエラーが出た」といった出来事の記録で、こちらは放っておくと保存されず流れていってしまうのがポイントです。この流れ去るログを掴まえて溜める役が診断設定、というわけです。

設定は各リソースの左メニュー「診断設定」から行い、「診断設定を追加する」でどのログ・メトリックを、どの送り先へ流すかを選びます。送り先は代表的に次の3つで、用途がはっきり分かれています。

Log Analyticsワークスペース：ログをKQLで検索・分析したいとき。アラートやWorkbooksの材料にするならほぼこれが本命です。
ストレージアカウント：とにかく安く長期保管したいとき。監査要件で「1年分残す」といった保存目的向き。検索は苦手です。
Event Hubs：外部のSIEMや自作の分析基盤など、Azureの外へリアルタイムに流し込みたいとき。

迷ったときの基本方針はシンプルで、「分析・アラートに使うならLog Analytics、長期保管ならストレージ、外部連携ならEvent Hubs」。この3択を覚えておけば、たいていの構成は組めます。1つの診断設定で複数の送り先を同時に指定できるので、「Log Analyticsで日々分析しつつ、ストレージにも安く長期保管」といった併用もよくやります。

なお、Log Analyticsに送ったログを実際にKQLでどう検索・集計するかは、それ自体で一本の記事になるボリュームなので、ここでは「送り先の設定まで」に留めます。KQLの書き方は Log Analytics の記事に譲ります。ここでは「アラートやダッシュボードの材料は、診断設定でLog Analyticsに送っておくところから始まる」とだけ押さえてください。

メトリックアラートとログアラートの使い分け

材料が揃ったら、いよいよアラートルールです。Azure Monitorのアラートにはいくつか種類がありますが、初心者がまず押さえるべきはメトリックアラートとログアラートの2つと、その使い分けです。ここを混同すると「なんか反応が遅い」「思ったより費用がかかる」といったハマり方をします。

メトリックアラート：速いが、対象は数値メトリック

メトリックアラートは、CPU使用率やメモリ、リクエスト数といった数値メトリックに対してしきい値を付けるアラートです。最大の強みは反応が速いこと。メトリックはほぼリアルタイムで評価されるので、「CPUが90%を超えたらすぐ知りたい」といった、時間との勝負になる監視に向いています。設定もGUIで「対象メトリック → 演算子 → しきい値」を選ぶだけと直感的です。

ログアラート：柔軟だが、少し遅れる

対してログアラートは、Log Analyticsに溜めたログに対してKQLクエリを書き、その結果の件数などで発報するアラートです。「特定の文言のエラーが5分間に10件以上出たら」「複数のテーブルを結合した条件で異常を判定」など、メトリックでは表現できない複雑で柔軟な条件を組めるのが強みです。

ただし弱点もあって、ログアラートはクエリを定期的に実行して評価する仕組みなので、メトリックアラートに比べると検知に少し遅れが出ます（評価間隔ぶんのタイムラグ）。また、実行するクエリの分だけコストもかかります。

使い分けの結論はこうです。「数値の急変をとにかく速く掴みたいならメトリックアラート、ログの中身まで踏み込んだ柔軟な条件で判定したいならログアラート」。まずはメトリックアラートで代表的な指標を押さえ、メトリックだけでは表せない条件が出てきたらログアラートを足す、という順番が現実的です。

動的しきい値：しきい値を機械学習に決めさせる

メトリックアラートを組んでいて、多くの人が最初にぶつかる悩みが「しきい値をいくつにすればいいのか分からない」です。CPU 80%で鳴らすと決めても、そのシステムは平常時から夜間バッチで90%まで上がるのが正常かもしれない。逆に、いつもは20%なのに深夜だけ静かに50%まで上がるのが異常のサインかもしれない。「正常」の基準は時間帯や曜日で揺れるのに、固定のしきい値ではそれを表現できません。

これを解決するのが動的しきい値（Dynamic Thresholds）です。固定の数値を人が決める代わりに、過去のメトリックのパターンを機械学習が分析し、「そのメトリックにとって普通の範囲」を自動で算出してくれます。そして、その普通の範囲から外れたときにアラートを出す。いわば「いつもと違う」を自動で判定してくれる仕組みです。

身近な例でいうと、体温計が「37.0度で発熱」と一律に決めるのではなく、その人の平熱を学習して「あなたにとっての発熱ライン」を出してくれるようなものです。平熱が高めの人にも低めの人にも、それぞれ妥当なラインを引ける。動的しきい値はこれをメトリックに対してやってくれます。

設定はメトリックアラート作成時に、しきい値の種類で「静的」ではなく「動的」を選ぶだけです。あとは「感度（Sensitivity）」を高／中／低から選びます。感度を高くするとちょっとの逸脱でも鳴り、低くすると大きく外れたときだけ鳴る、という調整です。

つまずきポイントとして、動的しきい値は過去データからパターンを学ぶため、ある程度の学習期間が必要です。作りたてのリソースや、データがまだ溜まっていないメトリックだと精度が出ません。まずは数日〜運用してデータが溜まったものに適用するのがコツです。「作った直後は挙動が安定しないことがある」と知っておくと、無用に慌てずに済みます。

アクショングループ①：メール・SMSで「通知」する

アラートルールが「検知」なら、ここからが「通知・対処」です。その受け皿がアクショングループ（Action groups）で、「アラートが鳴ったら誰に何をするか」をまとめて定義した束だと考えてください。一度作れば複数のアラートルールから使い回せるので、通知先を一元管理できます。

まずは分かりやすい通知（Notifications）から。アクショングループには通知先として次のようなものを登録できます。

メール：指定したアドレスへ発報内容を送る。もっとも基本。
SMS：携帯電話番号へショートメッセージ。深夜の重大障害など、メールでは気づけない緊急連絡向け。
プッシュ通知（Azureモバイルアプリ）：スマホのAzureアプリへ通知。
音声通話：電話をかけて読み上げる。絶対に見逃せない最重要アラート向け。

設定は「モニター」→「アラート」→「アクショングループ」→「作成」から。通知タブで種類（メール等）と宛先を追加していくだけです。実務でよくやるのは、重大度に応じて通知手段を変えること。軽微な警告はメールだけ、サービス停止級はSMSや音声通話も追加、という具合に、鳴り方でメリハリを付けると「通知疲れ（オオカミ少年化）」を防げます。

「全部のアラートをメールで飛ばしたら、受信箱が埋もれて逆に大事なやつを見落としました……重大度で分けるの、最初からやっておけばよかった。」

アクショングループ②：RunbookやFunctionsで「自動対処」する

ここからがこの記事の山場、自動化のいちばんおいしい部分です。アクショングループは通知だけでなく、アクション（Actions）として「人を介さずに処理を実行する」ことができます。つまり、アラートが鳴った瞬間にシステム自身に対処させる（自己修復させる）という世界です。

アクションとして呼び出せる代表的な相手は次の3つです。

Automation Runbook：Azure Automationに用意したPowerShell/Pythonスクリプトを実行。「VMを再起動」「詰まったサービスを再開」など、Azure操作の自動対処に最適。
Azure Functions：自作の関数を呼び出す。細かいロジックやAPI連携を自分のコードで書きたいとき。
Webhook：任意のURLへHTTPで通知を投げる。SlackやTeams、外部のインシデント管理ツール（PagerDuty等）へ連携する定番手段。

いちばんイメージしやすいのがRunbookによる自己修復です。たとえば「あるWindowsサービスが落ちてエラーメトリックが跳ねた」というアラートに対して、あらかじめ「そのサービスを再起動するRunbook」をアクションに紐づけておく。すると流れはこうなります。

[検知]  メトリックアラートが発報（サービス異常を検知）
   |
   v
[起動]  アクショングループが Automation Runbook を呼び出す
   |
   v
[対処]  Runbook がスクリプトを実行（サービスを自動再起動）
   |
   v
[通知]  同じアクショングループからメールで「自動対処しました」を送信

ポイントは、同じアクショングループに「Runbookで対処」と「メールで通知」を両方入れておけることです。こうすると「勝手に直しつつ、直したことは人にも報告する」という、運用者にとって理想的な形が作れます。夜中にサービスが落ちても、朝起きたら「自動で再起動して復旧しました」というメールが届いている——ここまで来ると、監視は完全に「自動で動く」側に回ります。

実務でのつまずきポイントを2つ。1つ目は権限です。Runbookが実際にVMを再起動したりするには、そのRunbookにAzureリソースを操作する権限（マネージドIDへのロール割り当て）が必要です。「アラートは鳴るのにRunbookがエラーで止まる」のときは、たいていこの権限不足が原因です。2つ目は暴走対策。自動対処が原因不明のまま何度も発火し続けると、かえって被害が広がることがあります。自動修復を仕込むときは「何回まで試みるか」「一定回数を超えたら人にエスカレーションする」といった歯止めもセットで考えておくと安全です。

なお、この自動対処の心臓部であるRunbookの書き方・マネージドIDによる安全な認証そのものは、Azure Automationの領域です。この記事では「アラートからRunbookを呼び出して自己修復させる」という繋ぎ方に焦点を当てました。Runbook自体をしっかり作りたい方は、末尾のあわせて読みたいからAutomationの記事へ進んでください。

Workbooks：監視を「見せる」ダッシュボードにする

アラートで「異常時に動く」仕組みは整いました。一方で、日々の状態をひと目で俯瞰したいという需要もあります。それに応えるのがブック（Workbooks）です。

Workbooksは、ざっくり言えばメトリック・ログ・表・グラフ・文章を自由に組み合わせて作る、対話的なレポート／ダッシュボードです。Excelの1シートに、グラフや表や説明文を好きに配置してレポートを作る感覚に近いです。「このサブスクリプションのVM一覧と、それぞれのCPU推移と、直近のエラー件数」を1枚にまとめる、といったことができます。

作成は「モニター」→「ブック」から。空のブックに「追加」でテキスト・メトリック・クエリ（KQL）・パラメーターといった部品（ステップ）を積み上げていきます。とはいえ最初からゼロで組む必要はなく、Azureが用意した豊富なテンプレートが並んでいるので、まずはそれを開いて中身を眺め、自分の環境に合わせて手直しするのが圧倒的に早いです。

Workbooksが便利なのはパラメーター（絞り込み）を置ける点です。画面上部にドロップダウンを付けて「サブスクリプションを選ぶと、その配下のリソースだけに表示が切り替わる」といった、見る人が操作できるダッシュボードが作れます。作った本人以外の運用メンバーや、状況を知りたい上長に共有するのに向いています。ここでも、グラフやクエリの中身自体はKQLやメトリックの知識が土台になるので、まずはテンプレートで「Workbooksでこういう見せ方ができる」という感覚を掴むのがおすすめです。

Autoscale：負荷に応じて「器」を自動で増減する

最後は、自動化のもう一つの主役Autoscale（自動スケール）です。ここまでの自動対処が「異常を直す」方向だったのに対し、Autoscaleは負荷そのものに合わせて、処理する器の数を自動で増やしたり減らしたりする仕組みです。Azure MonitorのメトリックをトリガーにするのでMonitorの領域として扱われます。

飲食店にたとえると分かりやすいです。ランチのピークで行列ができたら店員を増やし、暇な時間帯には店員を減らす。この「客の入り（＝負荷）を見てスタッフ数を自動調整する」のがAutoscaleです。対象になるのは仮想マシンスケールセット・App Service・その他スケール可能なサービスなど、複数インスタンスで動くリソースです。

スケールアウト／インとルールの考え方

Autoscaleでよく出てくるのがスケールアウト（インスタンス数を増やす）とスケールイン（減らす）という言葉です。設定は「メトリックがこうなったら何台にする」というルールで表現します。典型的にはこう組みます。

平均CPUが70%を超えたら、インスタンスを1台増やす（スケールアウト）
平均CPUが30%を下回ったら、インスタンスを1台減らす（スケールイン）
最小2台・最大10台の範囲で動く（下限と上限を必ず決める）

ここで最小・最大の台数を必ず設定するのが大事です。上限を決めておかないと、負荷が想定外に跳ねたときに際限なくインスタンスが増え、気づいたら請求額が跳ね上がっていたという事故につながります。下限も同様で、「最低これだけは常に動かす」を決めておかないと、スケールインしすぎてサービスが不安定になります。

つまずきポイント：クールダウンとフラッピング

Autoscaleで初心者がハマりやすいのが「増えたり減ったりを短時間で繰り返す」現象（フラッピング）です。しきい値ちょうど付近を負荷がウロウロすると、増やした直後にまた減らす、を繰り返してしまう。これを防ぐために、スケール後は一定時間だけ次のスケールを我慢するクールダウン（冷却期間）が用意されています。「スケールアウトのしきい値」と「スケールインのしきい値」に十分な差（余白）を持たせ、クールダウンを適切に取るのが安定運用のコツです。

また、CPUのような負荷が読める予測型のワークロードでは、時間ベースのスケール（「平日9時に増やして22時に減らす」など、スケジュールで台数を決める）も併用できます。メトリック連動と時間指定を組み合わせると、「普段はスケジュールで大枠を決めつつ、突発的な負荷にはメトリックで対応する」という手堅い構成が作れます。

まとめ：監視を「見るだけ」から「自動で動く」へ

この記事では、Azure Monitorのアラートと自動化を、検知から通知・対処・可視化・スケールまで一本の線で見てきました。要点を振り返っておきます。

診断設定：ログ／メトリックの送り先を決める。分析・アラート用途はLog Analytics、長期保管はストレージ、外部連携はEvent Hubs。
メトリック vs ログアラート：速さのメトリック、柔軟さ（KQL）のログ。急変検知はメトリック、複雑な条件はログ。
動的しきい値：機械学習が「そのメトリックの普通」を学び、固定値では拾えない「いつもと違う」を検知する。
アクショングループ：通知（メール／SMS／音声）と自動対処（Runbook／Functions／Webhook）の両方を担う。同じグループで「自動で直す＋人に報告」ができる。
Workbooks：メトリック・ログ・表・文章を組み合わせた対話的ダッシュボード。テンプレートから始めるのが近道。
Autoscale：負荷に応じて器を自動増減。最小・最大の台数とクールダウンを必ず設計する。

ここまで組めれば、監視は「人が画面を見張るもの」から「異常を自動で検知し、通知し、自ら対処し、負荷に合わせて器まで調整するもの」へと引き上がります。まずはメトリックアラート＋メール通知という最小構成から始め、慣れてきたら動的しきい値・Runbookによる自己修復・Autoscaleへと一段ずつ広げていってください。監視が「自動で動く」ようになると、運用の負担も夜間の不安も、驚くほど軽くなります。