Azure Monitor Service Level Indicators（SLI）の一般提供で変わるのは、監視の軸を「CPU使用率が高いか」「アラートが鳴ったか」だけでなく、「ユーザーが実際にアプリケーションを快適に使えているか」に寄せられる点です。2026年6月5日に確認されたAzure Monitorの更新では、SLIとSLOをAzure Monitor上で扱えるようになり、可用性・遅延・エラー予算・バーンレートを使った信頼性管理を進めやすくなりました。MicrosoftはAzure Updatesでこの機能をGeneral Availabilityとして案内しており、Azure Updates上の「Launched」は、すべてのAzure顧客が利用できる本番対応のリリースを意味します。(マイクロソフト アジュール)
ただし、Azure Monitor SLIを入れれば監視が自動的に改善されるわけではありません。重要なのは、どのユーザー操作をサービス品質として測るのか、どのメトリックを「成功」とみなすのか、既存アラートやSRE運用とどう接続するのかを先に決めることです。
Azure Monitor SLI/SLOの一般提供で何が変わるのか
Azure MonitorのSLIは、Service Groupに対して信頼性やパフォーマンスを測定する仕組みです。公式ドキュメントでは、SLIは観測された動作をコンプライアンス期間内のベースライン目標と比較し、サービスが設定した期待値を満たしているかを判断するものと説明されています。(Microsoft Learn)
これまで多くのAzure監視では、次のようなシグナルが中心になりがちでした。
| 従来の監視で見がちな指標 | 課題 | SLI/SLOで補える視点 |
|---|---|---|
| CPU使用率、メモリ使用率 | インフラ負荷は分かるが、ユーザー影響が分かりにくい | 実際の成功率や応答時間で判断できる |
| 単発のメトリックアラート | 瞬間的なスパイクで通知が増えやすい | 一定期間の目標達成率で見られる |
| ログエラー件数 | エラーの量は分かるが、許容範囲か判断しにくい | エラー予算で「どれだけ余裕があるか」を判断できる |
| サービス単体の正常性 | アプリ全体の利用体験とずれることがある | Service Group単位でワークロード境界を定義できる |
今回の更新の本質は、Azure Monitorが単なる「異常検知ツール」から、SLOを軸にサービス品質を管理するための運用基盤に近づいたことです。
SLI、SLO、SLAの違いを整理する
Azure Monitor SLIを正しく使うには、まずSLI、SLO、SLAの違いを混同しないことが重要です。
| 用語 | 意味 | Azure Monitorでの使いどころ |
|---|---|---|
| SLI | Service Level Indicator。サービス品質を測る指標 | 成功率、遅延、可用性などを測定する |
| SLO | Service Level Objective。SLIに対する目標値 | 「99.9%のリクエスト成功率を維持する」など |
| SLA | Service Level Agreement。契約上の保証 | 顧客や外部契約で使う。社内SLOとは別物 |
MicrosoftのAzure Well-Architected Frameworkでも、SLOはワークロードやアプリケーションに対して設定する測定可能な目標、SLIはSLOへの準拠状況を測るための定量的な測定値として整理されています。(Microsoft Learn)
実務では、いきなりSLAに近い厳しい数値を設定するより、まず社内運用のSLOとして始める方が安全です。たとえば「ログインAPIの99.5%が500ミリ秒以内に応答する」「注文完了処理の99.9%が成功する」といった形で、ユーザー体験に直結する動作から定義します。
Azure Monitor SLIで設定できる主な要素
Azure MonitorのSLI設定では、何を測るかだけでなく、どの範囲をサービスとみなすか、どの期間で評価するか、どの条件を成功とみなすかを決めます。公式ドキュメントでは、Service Group、SLI type、Evaluation method、Signal design、Baseline target、Compliance periodが主要な構成要素として示されています。(Microsoft Learn)
| 設定項目 | 役割 | 実務での判断基準 |
|---|---|---|
| Service Group | アプリケーションやワークロードの境界 | サブスクリプション単位ではなく、利用者に見えるサービス単位で分ける |
| SLI type | 可用性か遅延かを選ぶ | まずは可用性と主要APIの遅延から始める |
| Evaluation method | リクエスト単位か時間窓単位かを選ぶ | トラフィック量が多いAPIはRequest-based、短期スパイクをならしたい場合はWindow-based |
| Signal design | 成功・失敗の判定に使うメトリックやフィルター | ステータスコード、リージョン、エンドポイントなどの条件を明確にする |
| Baseline target | SLOの目標値 | いきなり99.99%にせず、過去実績とビジネス要件から決める |
| Compliance period | 目標達成を評価する期間 | 月次運用なら30日、短期改善なら7日など、運用会議の周期と合わせる |
ここで失敗しやすいのは、「メトリックがあるからSLIにする」という順番で考えてしまうことです。正しくは逆です。先に「ユーザーにとって何が失敗なのか」を決め、その失敗を測れるメトリックを選びます。
可用性SLIと遅延SLIの使い分け
Azure Monitor SLIでは、SLI typeとしてAvailabilityとLatencyが示されています。Availabilityはサービスが動作しているか、Latencyは十分に速く応答しているかを測る考え方です。公式ドキュメントでは、可用性の例として「測定期間中に読み取り・書き込みリクエストの99.99%が成功した」、遅延の例として「リクエストの95%が300ミリ秒未満で完了した」といった考え方が示されています。(Microsoft Learn)
可用性SLIが向いているケース
可用性SLIは、成功・失敗を明確に判定しやすい処理に向いています。
たとえば、次のような処理です。
- ログイン
- 商品検索
- 決済
- ファイルアップロード
- API Gateway経由の主要API
- バッチ完了ではなく、ユーザーから見える処理の成功率
例として、注文APIなら次のように定義できます。
| 項目 | 設定例 |
|---|---|
| SLI名 | order-api-availability |
| Good signal | HTTP 2xxまたは業務上成功とみなすレスポンス数 |
| Total signal | 対象APIへの全リクエスト数 |
| SLO | 99.9% |
| 評価期間 | 30日 |
| 除外を検討するもの | 明らかなクライアント入力エラー、テストトラフィック、メンテナンス用エンドポイント |
ポイントは、4xxを成功率に含めるかどうかをチームで決めることです。すべての4xxを失敗にすると、ユーザーの入力ミスや不正リクエストでSLOが悪化する場合があります。一方で、アプリ側のバリデーション不備による4xxまで除外すると、実際のユーザー体験を隠してしまいます。
遅延SLIが向いているケース
遅延SLIは、サービスは落ちていないものの、遅くて使いにくい状態を捉えるのに向いています。
たとえば、ECサイトの商品検索が成功率99.9%でも、検索結果が毎回5秒かかるなら顧客体験は良くありません。この場合は「95%の検索リクエストが500ミリ秒以内」「99%の決済開始APIが1秒以内」のように、体感速度を基準にしたSLIを設定します。
遅延SLIでは、平均値だけに頼らないことが重要です。平均応答時間は一部の遅いリクエストを隠すことがあります。可能であれば、p95やp99など、遅い側のユーザー体験を見られるメトリックを使う方が実態に近づきます。
Request-basedとWindow-basedの選び方
Azure Monitor SLIでは、評価方法としてRequest-basedとWindow-basedが説明されています。Request-basedはGood requestsとTotal requestsの比率を評価し、Window-basedは一定の時間窓ごとに条件を満たしたかどうかを評価します。(Microsoft Learn)
| 評価方法 | 向いているケース | 注意点 |
|---|---|---|
| Request-based | API、Webリクエスト、イベント処理など、リクエスト数で品質を測りたい場合 | トラフィックが少ないサービスでは数件の失敗で大きく悪化する |
| Window-based | 一定間隔ごとの状態を見たい場合、短いスパイクをならしたい場合 | 時間窓の幅を広げすぎると短時間の重大障害に気づきにくい |
多くのWebアプリケーションでは、まずRequest-basedから始めるのが自然です。ユーザーの1回1回の操作を成功・失敗で判断しやすいためです。
一方、低トラフィックの管理画面や社内向けツールでは、Request-basedだけだとSLIが不安定になります。たとえば1日に10件しかリクエストがないAPIで1件失敗すると、成功率は90%まで落ちます。このような場合は、評価期間を長めにする、Window-basedを検討する、あるいはSLO対象から外す判断も必要です。
エラー予算とバーンレートで「どれくらい危ないか」を判断できる
Azure Monitor SLIの重要な価値は、単にSLOを下回ったかどうかではなく、エラー予算とバーンレートを使って信頼性の余裕を見られることです。
公式ドキュメントでは、エラー予算はベースライン目標を外すまでにサービスが吸収できる不信頼性の量、バーンレートはそのエラー予算を消費する速度と説明されています。たとえばSLOが99.9%なら、エラー予算は0.1%です。(Microsoft Learn)
| 状態 | 解釈 | 取るべき行動 |
|---|---|---|
| SLO達成、エラー予算に余裕あり | 通常運用で問題ない | 改善よりも変更リスクの管理を優先 |
| SLO達成中だがバーンレートが高い | このまま続くと期間内にSLO未達になる可能性 | リリース停止、ロールバック検討、原因調査を前倒し |
| SLO未達 | 顧客体験が目標を下回っている | インシデント対応、恒久対策、SLOの妥当性確認 |
| エラー予算を急速に消費 | 突発的な障害やリグレッションの疑い | Fast burn rateアラートで即時対応 |
従来のアラートでは「今、CPUが高い」「今、エラーが増えた」という瞬間の異常に反応しがちでした。エラー予算を使うと、「この品質劣化を放置すると月間SLOを守れない」という運用判断がしやすくなります。
管理者が確認すべき設定項目
Azure Monitor SLIを導入する前に、管理者は権限、ワークスペース、通知先、Service Groupの設計を確認する必要があります。公式ドキュメントでは、SLI作成の前提として、既存のService Group、評価対象メトリックを持つソースAzure Monitor workspace、評価済みSLI結果を保存する宛先Azure Monitor workspace、さらにワークスペースへアクセスできるユーザー割り当てマネージドIDが必要とされています。(Microsoft Learn)
| 確認項目 | 確認内容 | 放置した場合のリスク |
|---|---|---|
| Service Group | アプリや業務サービス単位で正しく分けられているか | SLIが実際のサービス境界とずれる |
| Azure Monitor workspace | ソースと宛先を同一にするか分けるか | 生データと評価結果の管理責任が曖昧になる |
| マネージドID | Monitoring Reader、Monitoring Metrics Publisherなど必要な権限があるか | SLI評価や結果保存に失敗する |
| Action Group | 通知先、Webhook、ITSM連携先が適切か | SLO違反やバーンレート悪化に気づけない |
| DCRへのアクセス | 宛先ワークスペースの既定Data Collection Ruleを確認できるか | 権限不足で設定時に詰まる |
| 命名規則 | SLI名に環境、サービス、地域、機能を含めるか | 本番・検証・地域別の判別が困難になる |
特に注意したいのは、関連ドキュメント上、Azure Service GroupsはカスタムのAzureリソースグルーピングを作る仕組みで、既存のリソース階層を変えずにサブスクリプションやリソースグループをまたいでまとめられる一方、Service Groupsの作成ドキュメントにはPublic Previewの表記が残っている点です。(Microsoft Learn)
SLI自体は一般提供として案内されていますが、組織のガバナンス上、前提コンポーネントのステータスや利用条件を確認してから本番標準に組み込むのが安全です。
開発者が見直すべきメトリック設計
開発者側で重要なのは、アプリケーションが「SLIとして使えるメトリック」を出しているかどうかです。
Azure Monitor SLIの設定画面でどれだけ丁寧に条件を作っても、元データが粗ければ信頼性の判断はできません。たとえば、すべてのエラーが同じカウンターに混ざっている、APIごとの成功率が取れない、リージョンやテナントのラベルがない、といった状態では、ユーザー影響の切り分けが難しくなります。
SLI向けに用意したいメトリック例
| 用途 | メトリック例 | 必要なディメンション例 |
|---|---|---|
| API可用性 | request_total、request_success_total | endpoint、method、status_code、region |
| API遅延 | request_duration_ms、request_latency_bucket | endpoint、method、region |
| ジョブ処理 | job_completed_total、job_failed_total | job_name、queue_name、environment |
| 外部依存 | dependency_success_total、dependency_latency_ms | dependency_name、operation、region |
| 業務処理 | order_created_total、payment_authorized_total | tenant、channel、region |
SLIに使うメトリックは、障害調査にも使える形で設計するのが理想です。「成功率が下がった」だけでなく、「どのAPI」「どのリージョン」「どの依存先」「どのリリース以降」で悪化したのかを追えるようにします。
既存アラートや監視ダッシュボードからの移行方針
Azure Monitor SLIが一般提供されたからといって、既存のメトリックアラート、ログアラート、Application Insights、Grafana、Workbook、外部SLOツールをすぐに置き換える必要はありません。移行は段階的に進めるべきです。
おすすめは、次の順序です。
| フェーズ | 実施内容 | 判断基準 |
|---|---|---|
| 現状棚卸し | 既存アラートとダッシュボードを一覧化 | ユーザー影響に直結するものを優先 |
| SLI候補選定 | 主要ユーザージャーニーを3〜5個選ぶ | ログイン、検索、購入、登録など |
| 並行運用 | 既存監視とAzure Monitor SLIを同時に見る | 1〜2評価期間は通知を比較 |
| 通知調整 | バーンレートアラートと既存アラートの重複を減らす | 同じ障害で通知が増えすぎないこと |
| 運用組み込み | インシデント基準、リリース判定、週次レビューに使う | SLO違反時の判断が明文化されていること |
既存アラートをすぐ削除すると、SLIの設定ミスに気づけないまま重要な異常を見逃す可能性があります。最初は通知を抑えめにしてダッシュボード確認から始め、実績が取れてからオンコール通知に組み込む方が安全です。
展開時に失敗しやすいポイント
Azure Monitor SLIの導入で失敗しやすいのは、ツール設定よりも運用設計です。
SLIを作りすぎる
最初から全API、全バッチ、全リソースにSLIを作ると、重要な品質指標が埋もれます。最初は「顧客が困る順」に絞ります。ECサイトなら、閲覧、検索、カート投入、決済、注文完了のように、売上や顧客体験に直結する導線から始めます。
SLOを高くしすぎる
99.99%は見栄えの良い数値ですが、月間の許容停止時間は非常に短くなります。実際のアーキテクチャ、リリース頻度、外部依存、運用体制が追いつかない場合、常にSLO違反となり、誰も見ない指標になります。
最初は過去30日から90日の実績を見て、少し背伸びした目標にするのが現実的です。
インフラ指標をそのままSLIにする
CPU使用率80%未満、メモリ使用率70%未満といった指標は、キャパシティ管理には有効です。しかし、それだけではユーザーがサービスを使えているかは分かりません。
SLIは「ユーザー操作が成功したか」「許容時間内に応答したか」を中心に置くべきです。CPUやメモリは、SLI悪化時の原因調査に使う補助指標と考えます。
地域やテナント差を平均で隠してしまう
グローバルサービスでは、全体の成功率が99.9%でも、特定リージョンだけ95%まで落ちていることがあります。全体SLIだけでなく、必要に応じてリージョン別、重要テナント別、主要エンドポイント別のSLIを設計します。
ただし、細分化しすぎると運用負荷が上がります。まず全体SLIを作り、インシデント分析で頻繁に問題になる軸だけ追加するのが現実的です。
導入前チェックリスト
Azure Monitor SLIを本番導入する前に、最低限次の項目を確認してください。
| チェック項目 | 確認 |
|---|---|
| 主要なユーザージャーニーを定義した | 監視対象をリソースではなく利用体験で説明できる |
| SLI候補を3〜5個に絞った | 最初から全メトリックを対象にしていない |
| Good signalとTotal signalの定義を文書化した | ステータスコードや除外条件が曖昧でない |
| SLO値を過去実績とビジネス要件から決めた | 99.9%などの数値を感覚で決めていない |
| Service Groupの境界を確認した | アプリケーション単位、環境単位、所有者が明確 |
| Azure Monitor workspaceと権限を確認した | マネージドID、RBAC、DCRアクセスを確認済み |
| Action Groupの通知先を確認した | SLO違反、Fast burn、Slow burnの通知先が適切 |
| 既存アラートとの重複を確認した | 通知疲れを増やさない設計になっている |
| 並行運用期間を決めた | いきなり既存監視を廃止しない |
| SLO違反時の判断を決めた | リリース停止、ロールバック、事後レビューの基準がある |
Azure Monitor SLIはどんなチームに向いているか
Azure Monitor SLIは、特に次のようなチームに向いています。
| チーム・状況 | 向いている理由 |
|---|---|
| Azure上で本番アプリを運用している | Azure Monitor内で信頼性指標をまとめやすい |
| アラートが多すぎて優先度判断に困っている | ユーザー影響とエラー予算で判断しやすい |
| SRE運用を始めたい | SLI、SLO、バーンレートの考え方を導入しやすい |
| 経営・CS・開発で品質認識がずれている | SLOを共通言語として使える |
| リリース速度と安定性のバランスを取りたい | エラー予算を使って変更リスクを判断できる |
一方で、まだ本番トラフィックが少ないサービス、メトリック設計が未整備のサービス、所有者が曖昧なワークロードでは、先に監視データと運用責任を整える必要があります。
まず何から始めるべきか
Azure Monitor SLIの導入は、設定画面を開く前に「どの顧客体験を守るか」を決めるところから始めます。
最初の一歩としては、次の3つで十分です。
1つ目は、最重要のユーザージャーニーを1つ選ぶことです。ログイン、検索、決済、申請送信など、止まると問い合わせや売上影響が出るものを選びます。
2つ目は、その処理の成功率または遅延をSLIとして定義することです。Good signal、Total signal、除外条件、SLO値、評価期間をチームで合意します。
3つ目は、Azure Monitor上でSLIを作成し、既存アラートと並行して1〜2評価期間観察することです。すぐに通知運用へ組み込まず、実際の障害やリリース時にSLIが納得できる動きをするか確認します。
Azure Monitor Service Level Indicatorsの一般提供は、Azure監視を「インフラ中心」から「サービス品質中心」へ進める良いタイミングです。まずは重要なサービスを1つ選び、可用性または遅延のSLIを小さく始めることが、失敗しにくい導入方法です。
コメント