Azure MonitorのHealth models（preview）は、VMやAKS、Application Insights、Log Analyticsなどの監視データを、単なる個別アラートではなく「ワークロード全体の健全性」として見える化するための機能です。2026年5月26日に更新されたMicrosoft公式情報では、エンティティ、依存関係、シグナル、ヘルス状態、アラートを組み合わせ、アプリケーションや業務サービス単位で状態を追跡できることが示されています。まず確認すべき結論は、既存のAzure Monitorを置き換える機能ではなく、既存のメトリック、ログ、Prometheusメトリック、Application Insightsのデータに業務コンテキストを重ねる機能だという点です。(Microsoft Learn)
Azure MonitorのHealth models（preview）で何が変わるのか
Health models in Azure Monitorは、Azure Monitorに状態ベースの監視を追加する機能です。従来の監視では「CPU使用率がしきい値を超えた」「HTTP 5xxが増えた」といった個別シグナルごとにアラートを扱うことが多く、実際に業務影響があるのか判断するには、運用担当者が複数のメトリックやログを横断して確認する必要がありました。
Health modelsでは、Azureリソースや業務上の構成要素をエンティティとしてモデル化し、それぞれのシグナルをもとにHealthy、Degraded、Unhealthy、Unknownといった状態で表します。さらに依存関係を定義することで、下位コンポーネントの不調が上位のアプリケーション全体にどう影響するかをロールアップできます。(Microsoft Learn)
たとえば、ECサイトを構成する次のような要素を1つのヘルスモデルにできます。
| 構成要素 | Health modelsでの扱い | 確認する状態の例 |
|---|---|---|
| Web App | Azure resource entity | HTTPエラー率、応答時間、可用性 |
| Azure SQL Database | Azure resource entity | DTU/CPU、接続失敗、クエリ遅延 |
| AKS上のAPI | Azure resource entityまたはPrometheusベースのシグナル | Pod再起動、リクエスト失敗率 |
| 決済処理 | Generic entity | 関連リソースの状態を集約 |
| ECサイト全体 | Root entity | サービス全体が正常か、業務影響があるか |
この考え方により、個別リソースの異常を追うだけでなく、「顧客向けサービスとして今使える状態か」を判断しやすくなります。
Health modelsは既存のAzure Monitorを置き換える機能ではない
重要なのは、Health modelsが監視データを新しく収集する仕組みではないことです。公式ドキュメントでは、Health modelsのシグナルはAzure Monitorがすでに収集しているデータをサンプリングまたはクエリするものと説明されています。対象データには、Azureリソースのプラットフォームメトリック、リソースログ、KubernetesのPrometheusメトリック、VMのログやパフォーマンスカウンター、Application Insightsのアプリケーションデータなどが含まれます。(Microsoft Learn)
つまり、導入前に見るべきポイントは「Health modelsを有効にすれば何でも見える」ではなく、既存の監視データが十分に収集されているかです。
特に次のような環境では効果が出やすいでしょう。
| 向いている環境 | 理由 |
|---|---|
| 複数のAzureリソースで構成される業務アプリ | 依存関係をモデル化し、全体の正常性を確認しやすい |
| 既存アラートが多く、通知ノイズが課題 | 複数シグナルを1つのヘルス状態に集約できる |
| SLOや可用性目標を追跡したい | Health objectiveで健全な時間の割合を追跡できる |
| Application InsightsやLog Analyticsをすでに活用している | 既存データをシグナルとして利用しやすい |
| AKSやPrometheusベースの監視を使っている | Azure Monitor workspaceのPromQLシグナルを使える |
一方で、単体のVMや小規模なリソース監視だけで十分な場合は、従来のメトリックアラートやログアラートのほうがシンプルです。Health modelsは、複数コンポーネントの関係性と業務影響を表現したい場面で価値が出ます。
管理者・開発者が押さえるべき基本概念
Health modelsを理解するうえで、最初に押さえるべき要素は「エンティティ」「リレーションシップ」「シグナル」「ヘルス状態」「ヘルス伝播」です。
エンティティは監視対象の部品
エンティティは、ヘルスモデルを構成する基本単位です。公式ドキュメントでは、Root entity、Azure resource entity、Generic entityの3種類が説明されています。Root entityはモデル全体を表す単一のエンティティで削除できません。Azure resource entityはAzureリソースを表し、Generic entityはAzureリソースではない業務プロセスや集約単位を表すために使えます。(Microsoft Learn)
実務では、Generic entityの使い方が設計の質を左右します。たとえば「東日本リージョン」「決済基盤」「検索機能」「管理者向けAPI」のように、業務や運用単位でまとめると、障害時に影響範囲を判断しやすくなります。
リレーションシップは依存関係を表す
Health modelsでは、親子関係によって依存関係や集約関係を表します。多くのモデルでは、各エンティティを直接または間接的にRoot entityへ接続し、ワークロード全体の健全性をロールアップします。(Microsoft Learn)
たとえば「APIサーバーはAzure SQL Databaseに依存する」「WebフロントエンドはAPIに依存する」という関係を設定すれば、DBのUnhealthyが上位のAPIやサービス全体に影響する構造を表現できます。
シグナルは状態判定の材料
シグナルは、メトリックやクエリ結果をしきい値と比較し、エンティティの状態を決める材料です。Health modelsでは、Azure resource、Log Analytics workspace、Azure Monitor workspaceの3種類のシグナルが利用できます。Azure resourceシグナルはプラットフォームメトリック、Log Analytics workspaceシグナルはKQLクエリ、Azure Monitor workspaceシグナルはPromQLクエリを使います。(Microsoft Learn)
代表的な使い分けは次の通りです。
| シグナル種別 | 使うデータ | 向いている例 |
|---|---|---|
| Azure resource | Azureリソースのプラットフォームメトリック | CPU、メモリ、要求数、失敗数、可用性など |
| Log Analytics workspace | KQLクエリ結果 | エラーログ件数、特定イベントの発生数、複雑な集計 |
| Azure Monitor workspace | PromQLクエリ結果 | AKSやPrometheusベースのメトリック監視 |
ログクエリやPromQLクエリは、単一レコードの数値を返す必要があります。複数レコードを返すクエリをそのまま使うと、意図した判定にならない可能性があるため、summarizeなどで評価用の値に集約してから使うのが実務上の基本です。(Microsoft Learn)
変更点として注目すべきポイント
2026年5月26日時点の公式情報から見ると、Health modelsで注目すべき変更点は、Azure Monitorに「個別アラート中心」ではない監視の整理軸が追加されることです。単に新しい画面が増えるのではなく、監視設計の単位がリソース単位からワークロード単位へ広がります。
アラートではなくヘルス状態を中心に監視できる
Health modelsでは、個々のシグナルではなく、エンティティのヘルス状態に対してアラートを設定できます。公式ドキュメントでは、Health modelsのアラートはエンティティがDegradedまたはUnhealthyになったときに発火し、既存のAzure Monitorアラートと同じAction groupsを利用できると説明されています。(Microsoft Learn)
これにより、同じ原因で複数のメトリックアラートが鳴るようなケースでも、「業務上重要なエンティティがUnhealthyになった」という単位で通知を整理できます。
依存関係を使って業務影響を表現できる
Health modelsでは、子エンティティの状態を親エンティティへ伝播できます。デフォルトでは依存関係の中で最も悪い状態を上位へ反映する考え方ですが、ImpactやDependenciesの設定で伝播の強さを調整できます。(Microsoft Learn)
たとえばキャッシュサーバーが停止してもアプリケーションは遅くなるだけで提供継続できる場合、キャッシュのUnhealthyを親にはDegradedとして伝える設計が考えられます。一方、認証基盤の停止がサービス全体の停止に直結するなら、Standardの伝播でUnhealthyをそのまま上位へ反映させるべきです。
Graph viewとTimeline viewで現在と過去を追える
Health modelsには、現在の構造と状態を見るGraph view、時系列で状態を追うTimeline view、個別エンティティの詳細を見るEntity detailsがあります。Graph viewでは特定時点のスナップショットも確認でき、Timeline viewでは時間範囲を変えながら状態変化を追跡できます。(Microsoft Learn)
障害対応では、まずRoot entityや主要なGeneric entityで全体影響を確認し、次にUnhealthyまたはDegradedの子エンティティへ掘り下げる流れが実用的です。従来のように、先に大量のアラート一覧から原因候補を探す運用より、影響範囲を把握しやすくなります。
影響範囲：誰が何を確認すべきか
Health modelsは、Azure Monitorを利用しているすべての担当者に同じ影響があるわけではありません。役割ごとに確認すべきポイントが異なります。
| 対象者 | 確認すべきこと | 実務上の判断基準 |
|---|---|---|
| Azure管理者 | 権限、マネージドID、リソースグループ、Action groups | 誰が作成・閲覧・管理できるかをRBACで整理する |
| SRE・運用担当 | 既存アラートとの重複、通知ルール、障害時の導線 | 既存アラートをすぐ止めず、並行運用で妥当性を確認する |
| アプリ開発者 | 業務機能と依存関係の定義 | 技術構成ではなく、ユーザー影響のある単位でモデル化する |
| プラットフォームチーム | 標準モデル、タグ、検出ルール、命名規則 | チームごとにバラバラなモデルを作らせない |
| セキュリティ・監査担当 | 監視データへのアクセス権限 | マネージドIDに必要最小限のMonitoring Reader権限を付与する |
特に注意したいのは、Health modelsが「リソースの所有チーム」と「業務サービスの責任チーム」をまたぐことです。たとえばDBは基盤チーム、APIは開発チーム、監視はSREチームが担当している場合、しきい値や依存関係の判断を誰が承認するかを決めておかないと、モデルが運用実態とずれていきます。
作成前に確認すべき前提条件と権限
Health modelを作成するには、Azureサブスクリプション、監視対象リソース、利用するシグナルに必要な監視データが必要です。また、作成にはリソースグループまたはサブスクリプションから継承されたContributor以上の権限、既存Health modelの管理にはMonitoring Contributor、閲覧にはMonitoring Readerが必要とされています。(Microsoft Learn)
作成時には、Health modelがテレメトリへアクセスするためのマネージドIDも重要です。公式ドキュメントでは、Health modelsは監視対象リソースのデータやディスカバリー実行のために、1つ以上のマネージドIDを必要とすると説明されています。ユーザー割り当てマネージドIDを使う場合は、対象Azureリソース、Log Analytics workspace、Azure Monitor workspaceに対してMonitoring Reader権限を付与する必要があります。(Microsoft Learn)
導入前チェックリストとしては、次の項目を確認してください。
| 確認項目 | 見落としやすいポイント |
|---|---|
| 監視対象リソース | Health modelと同じサブスクリプション・リソースグループである必要はないが、アクセス権は必要 |
| メトリック | 対象リソースのメトリックが取得できているか |
| ログ | Log Analytics workspaceに必要なログが送信されているか |
| Prometheus | Azure Monitor workspaceにPrometheusメトリックが入っているか |
| マネージドID | 必要なスコープにMonitoring Readerが付いているか |
| Action groups | 通知先、ITSM連携、自動化処理が現行運用と合っているか |
| 命名規則 | モデル名、エンティティ名、タグが運用で検索しやすいか |
設定時の実務ポイント
Health modelsはグラフィカルなDesignerで構成します。Designerでは、エンティティの追加、関係の作成、シグナルやアラートの設定、配置の保存などができます。変更はブラウザー上だけに存在するものと、エンティティエディターで保存されるものがあるため、設定後は保存状態を必ず確認しましょう。(Microsoft Learn)
最初は小さなモデルから作る
最初から全社システム全体を1つのHealth modelにしようとすると、依存関係やしきい値の調整が難しくなります。まずは、次のように範囲を絞るのが現実的です。
| 初期導入の単位 | 理由 |
|---|---|
| 1つの業務アプリ | Root entityの意味が明確になる |
| 1つの重要API | シグナルと業務影響を対応付けやすい |
| 1つのリージョン | フェールオーバーや冗長性の判断を検証しやすい |
| 既存アラートが多いサービス | 通知削減の効果を測りやすい |
小さく始めることで、Health modelsの状態が実際の障害感と合っているかを確認しやすくなります。
シグナルは「原因」ではなく「状態」を表すものから選ぶ
Health modelsで失敗しやすいのは、あらゆるメトリックをシグナルとして詰め込みすぎることです。シグナルは多ければよいわけではありません。業務上の健全性を判断できるものを優先します。
たとえば、Web APIなら次のような考え方が実用的です。
| 目的 | シグナル例 | 判断の考え方 |
|---|---|---|
| ユーザー影響を検知 | HTTP 5xx率、失敗リクエスト数 | 一定以上ならDegradedまたはUnhealthy |
| 性能劣化を検知 | 応答時間、キュー滞留 | 遅延が継続する場合にDegraded |
| リソース枯渇を検知 | CPU、メモリ、接続数 | 単独では原因候補。業務影響シグナルと組み合わせる |
| データ処理遅延を検知 | 未処理メッセージ数 | 処理遅延がSLOに影響する場合に重要 |
CPU使用率が高いだけでは、必ずしもユーザー影響があるとは限りません。逆にCPUが正常でも、依存先APIのエラーで業務処理が失敗している場合があります。Health modelsでは、リソース状態と業務状態を混同しない設計が重要です。
しきい値は「Degraded」と「Unhealthy」を分けて考える
Health modelsのシグナルでは、DegradedとUnhealthyのしきい値を設定できます。公式ドキュメントでは、Degradedのしきい値は任意、Unhealthyのしきい値は必須と説明されています。(Microsoft Learn)
実務では、次のように分けると判断しやすくなります。
| 状態 | 意味 | 運用例 |
|---|---|---|
| Healthy | 期待範囲内で動作している | 通常運用 |
| Degraded | 動作しているが性能や機能が低下している | 調査開始、影響監視、必要に応じて通知 |
| Unhealthy | 動作不能、または許容できない性能 | 即時対応、オンコール通知、自動復旧の対象 |
| Unknown | データ不足などで判定できない | 監視データ、権限、クエリ、収集設定を確認 |
Degradedを軽視しすぎると、ユーザー影響が大きくなるまで検知できません。一方で、Degradedを厳しく設定しすぎると通知ノイズが増えます。過去の障害時の数値、SLO、利用ピーク時間帯の正常値を見ながら調整しましょう。
自動検出を使う場合の注意点
Health modelsでは、ディスカバリーによってAzure resource entityを自動追加できます。公式ドキュメントでは、Application Insights topology、Resource graph query、Service groupの3種類のディスカバリーが説明されており、ディスカバリーは5分ごとに実行され、この頻度は変更できないとされています。(Microsoft Learn)
自動検出は便利ですが、設計なしに使うとモデルが膨らみすぎる可能性があります。特にResource Graph queryを使う場合は、タグ、リソースグループ、サブスクリプション、リージョンなどで対象を絞り込むことが重要です。
また、同じリソースが複数のディスカバリールールに一致した場合、それぞれ別のエンティティとしてモデルに作成される点にも注意が必要です。(Microsoft Learn)
実務上は、次の方針をおすすめします。
| 設定方針 | 理由 |
|---|---|
| 本番環境だけを対象にする | 開発・検証環境の一時的なリソースでノイズが増えるのを防ぐ |
| タグでサービス名を統一する | Resource Graph queryで対象を絞りやすくする |
| ディスカバリーごとに親エンティティを決める | 自動追加されたリソースの所属が分かりやすい |
| 推奨シグナルの自動追加は検証後に使う | しきい値が自社のSLOと合うとは限らない |
| プレビューで結果を確認してから作成する | 想定外のリソース追加を防ぐ |
既存アラートから移行する際の注意点
Health modelsを導入しても、既存のリソース固有アラートは自動的に停止しません。公式ドキュメントでは、AzureリソースをHealth modelに追加し、Health model側のアラートを有効化しても、既存のリソース固有アラートは引き続き動作するため、同じ問題に対して重複アラートが発生する可能性があると説明されています。(Microsoft Learn)
移行時は、いきなり既存アラートを削除するのではなく、段階的に進めるべきです。
| フェーズ | 実施内容 | 判断基準 |
|---|---|---|
| 評価 | Health modelにリソースを追加し、シグナルのみ設定 | 実際の状態がモデルに正しく反映されるか確認 |
| 並行運用 | 既存アラートとHealth modelアラートを同時に運用 | 通知タイミング、重大度、対応フローを比較 |
| 調整 | しきい値、Impact、Dependenciesを修正 | 誤検知や過小検知がないかを見る |
| 移行 | Health modelアラートを正式運用し、重複する既存アラートを無効化 | 同一原因の二重通知を避ける |
| 定着 | 障害レビューでモデルを見直す | 実際の業務影響とモデルの状態が一致しているか確認 |
既存アラートルールからシグナルをインポートする方法も用意されています。既存の判定条件を活かしたい場合は、Designerでシグナル追加時にImport from alert rulesを使う選択肢があります。(Microsoft Learn)
展開時に失敗しやすいポイント
Health modelsは強力ですが、モデル設計を誤ると「見た目は立派だが運用で使われない監視画面」になりがちです。特に次の点に注意してください。
| 失敗しやすいポイント | 起きる問題 | 対策 |
|---|---|---|
| 技術構成をそのまま並べる | 業務影響が分からない | Generic entityで業務機能単位に整理する |
| シグナルを増やしすぎる | 原因候補が多すぎて判断しづらい | ユーザー影響に近いシグナルを優先する |
| しきい値を机上で決める | 平常時でもDegradedが頻発する | 過去データやピーク時の正常値を確認する |
| 既存アラートをすぐ停止する | 重要通知を見逃す可能性がある | 並行運用期間を設ける |
| 権限設計を後回しにする | シグナルがUnknownになる | マネージドIDとMonitoring Reader権限を先に確認する |
| ディスカバリー範囲が広すぎる | 不要なエンティティが増える | タグやResource Graph queryで対象を絞る |
| ImpactをすべてStandardにする | 軽微な依存先障害が全体障害に見える | キャッシュや補助機能はLimitedやSuppressedも検討する |
特にUnknownが頻発する場合は、Health models自体の問題と決めつけず、監視データの収集設定、Log Analytics workspaceへのデータ送信、PromQL/KQLの戻り値、マネージドIDの権限を順に確認するのが近道です。
プレビュー機能としての扱い方
Health modelsは、現時点でpreviewとして提供されています。プレビュー機能は、一般提供機能と比べて仕様や画面、対応範囲が変更される可能性があります。そのため、本番運用に組み込む場合でも、いきなり既存の監視基盤を置き換えるのではなく、重要ワークロードの可視化やアラート整理の検証から始めるのが安全です。
おすすめの進め方は次の通りです。
| ステップ | 実施内容 |
|---|---|
| 現状把握 | 既存アラート、通知先、障害対応フローを棚卸しする |
| 対象選定 | 障害影響が大きく、構成要素が複数あるワークロードを選ぶ |
| モデル設計 | Root entity、Generic entity、Azure resource entityの関係を図にする |
| データ確認 | メトリック、ログ、Prometheus、Application Insightsの収集状況を確認する |
| シグナル設定 | 少数の重要シグナルから始める |
| 並行運用 | 既存アラートと比較し、検知品質を確認する |
| 展開判断 | 重複アラート削減、MTTR短縮、障害レビューのしやすさで評価する |
プレビュー段階では、「本番障害対応の唯一の根拠」にするのではなく、「既存監視を業務視点で整理する補助線」として使うのが現実的です。
Health modelsを活用すべき具体的なシーン
Health modelsは、単に新機能だから導入するのではなく、運用上の課題が明確な場面で使うと効果が出ます。
アラートが多すぎて優先順位が分からない
複数のリソースから同時にアラートが発生する環境では、担当者が「どれが本当に重要か」を判断するまでに時間がかかります。Health modelsで業務サービス全体のRoot entityや主要機能のGeneric entityにアラートを設定すれば、業務影響のある状態変化を優先して確認できます。
障害時の影響範囲を早く知りたい
Graph viewで依存関係と現在の状態を確認できるため、「どのリソースが悪いか」だけでなく「それがどの業務機能に影響しているか」を追いやすくなります。特に、複数チームが関わるシステムでは、初動の切り分けに役立ちます。
SLOや可用性目標を運用に落とし込みたい
Health objectiveを使うと、エンティティがHealthyだった時間の割合を追跡できます。公式ドキュメントでは、各エンティティに設定するのではなく、ワークロード全体を表すRoot entityに設定する使い方も示されています。(Microsoft Learn)
SLOを管理したい場合は、単に「CPUが高い時間」ではなく、「サービスとしてHealthyだった時間」を追う設計にすると、運用指標として使いやすくなります。
導入前の実務チェックリスト
最後に、管理者や開発者がHealth models in Azure Monitorを試す前に確認すべき項目を整理します。
| チェック項目 | 確認内容 |
|---|---|
| 対象ワークロード | 何の業務サービスを表すモデルか説明できるか |
| Root entity | 全体の正常性を表す単位が明確か |
| Generic entity | 機能、リージョン、業務プロセスなどの集約単位が適切か |
| Azure resource entity | 監視対象リソースが過不足なく含まれているか |
| 依存関係 | 障害時の影響伝播が実態に合っているか |
| Impact | キャッシュ、バックアップ、補助機能などの影響度を調整しているか |
| Dependencies | 冗長構成の場合、1台停止で全体Unhealthyにしていないか |
| シグナル | ユーザー影響やSLOに近い指標を優先しているか |
| しきい値 | DegradedとUnhealthyを明確に分けているか |
| 権限 | マネージドIDに必要なMonitoring Reader権限があるか |
| アラート | 既存アラートとの重複を把握しているか |
| 展開計画 | プレビュー機能として段階導入する計画があるか |
Health models in Azure Monitorは、Azure Monitorの監視データを「リソースの異常」から「ワークロードの健全性」へ引き上げるための機能です。導入時は、まず重要な1サービスを選び、既存メトリックやログを確認し、少数のシグナルでモデルを作成しましょう。そのうえで、Graph viewやTimeline viewで実際の状態と照らし合わせ、既存アラートとの重複を整理していくのが、失敗しにくい進め方です。
コメント