Azure AI Metrics Advisorを利用していた環境では、監視・異常検知・通知の仕組みをすでに移行対象として扱う必要があります。MicrosoftのAzure Updatesでは、Azure AI Metrics Advisorが2026年5月18日時点で廃止されたと案内されており、代替先としてAzure Monitor、Open-Source Anomaly Detector、Microsoft Fabricなどが示されています。(Microsoft Azure)
特に注意したいのは、「Azureポータル上でリソースが見えるか」だけでは安全確認にならない点です。Metrics Advisorは2023年9月21日以降に新規リソースを作成できず、2026年3月31日時点でMetrics Advisorポータルが無効化されています。既存の監視アプリ、API連携、通知フック、運用手順書にMetrics Advisorが残っている場合は、Azure MonitorやMicrosoft Fabricを前提にした監視設計へ切り替えるべきです。(Microsoft Learn)
Microsoft Azureの廃止・変更予告を整理：AI Services Metrics Advisorで何が変わったのか
今回の変更は、Microsoft AzureのAI Servicesに含まれるAzure AI Metrics Advisorの廃止です。Metrics Advisorは、時系列データの異常検出、診断、根本原因分析、通知を行うためのサービスでした。AIOps、予測メンテナンス、ビジネスメトリック監視などで、売上・アクセス数・設備データ・処理件数といった時系列メトリックを監視する用途に使われていました。(Microsoft Learn)
Microsoft Learnのドキュメントでは、Metrics Advisorについて次の流れが示されています。(Microsoft Learn)
| 時期 | 内容 | 実務上の意味 |
|---|---|---|
| 2023年9月21日以降 | 新しいMetrics Advisorリソースを作成不可 | 新規開発で採用すべきではない |
| 2026年3月31日時点 | Metrics Advisorポータルが無効化 | GUIでの確認・調整・フィードバック操作に依存できない |
| 2026年5月18日時点 | Azure Updatesで廃止済みと案内 | 既存利用も停止・移行対象として扱うべき |
| 2026年10月1日まで | ドキュメント上はサービス廃止期限として記載 | 個別環境の通知や契約条件を確認し、猶予前提で運用しない |
日付の表現に幅があるため、管理者は「2026年10月1日まで使えるはず」と楽観的に判断するのではなく、2026年5月18日時点で廃止済みというAzure Updatesの案内を重視し、すでに利用継続リスクがある状態として確認するのが安全です。
影響を受ける可能性がある環境
影響を受けるのは、Azure AI Metrics Advisorを直接使っている環境だけではありません。Metrics AdvisorのAPI、SDK、Webhook、Teams通知、Azure DevOps連携、運用ダッシュボードなどを経由して、間接的に依存しているケースもあります。
確認すべき代表的な利用パターン
| 利用パターン | 影響の例 | 優先度 |
|---|---|---|
| Metrics AdvisorリソースをAzure上に作成していた | 異常検知や診断処理が利用できなくなる可能性 | 高 |
| Metrics Advisor REST APIやSDKをアプリから呼び出している | アプリの監視・通知・自動判定処理が失敗する可能性 | 高 |
| メール、Webhook、Teams、Azure DevOpsフックで通知している | 障害や異常を検知しても通知されない可能性 | 高 |
| Metrics Advisorポータルで検出条件を調整していた | 閾値調整、フィードバック、診断作業が継続できない | 中〜高 |
| AIOpsや予測メンテナンスで時系列異常検知を使っている | 業務KPIや設備異常の検出精度・運用フローに影響 | 高 |
| 過去の検知結果をレポートや監査に使っている | 履歴データの確認・再現性に影響する可能性 | 中 |
見落としやすいのは、Metrics Advisorを「監視基盤」ではなく「業務アプリの一部」として組み込んでいるケースです。たとえば、ECサイトの注文数、広告配信のCV数、工場設備のセンサー値、SaaSのテナント別利用量などをMetrics Advisorで判定し、その結果を社内通知や自動対応に使っていた場合、単にAzureリソースを削除するだけでは移行は完了しません。
管理者がまず確認すべきAzure設定
最初に行うべきことは、Azureサブスクリプション内にMetrics Advisor関連のリソースや依存設定が残っていないかを棚卸しすることです。Microsoft Learnでは、Azure Advisorの信頼性推奨事項として「AI Services Metrics Advisor is being retired」が用意されており、対象リソースの種類はmicrosoft.cognitiveservices/accounts、推奨事項IDは8dca8881-92ae-480a-aa8c-0933efdf9e02とされています。(Microsoft Learn)
Azure管理者向けチェックリスト
| 確認項目 | 見る場所 | 判断基準 |
|---|---|---|
| Metrics Advisorリソースの有無 | Azureポータル、Resource Graph、Azure CLI | Microsoft.CognitiveServices/accounts配下に該当リソースがないか |
| Azure Advisorの推奨事項 | Azure Advisorの信頼性カテゴリ | Metrics Advisor廃止に関する推奨事項が出ていないか |
| APIキー・エンドポイントの利用 | Key Vault、App Configuration、環境変数、CI/CD変数 | Metrics Advisorのエンドポイント名やキーが残っていないか |
| 通知先の設定 | Webhook、Teams、メール、Azure DevOps | 通知元がMetrics Advisorのままではないか |
| 監視手順書 | 運用Runbook、障害対応フロー | 異常検知時の確認先がMetrics Advisorポータルになっていないか |
| 権限設定 | Azure RBAC、Entra ID、管理グループ | 移行後のAzure MonitorやFabricに必要な権限があるか |
特にKey VaultやCI/CDの変数は見落とされやすい場所です。アプリケーションコードから直接Metrics Advisor APIを呼んでいなくても、バッチ処理、Functions、Logic Apps、Data Factory、社内ツールなどがエンドポイントを参照していることがあります。
開発者が確認すべきコード・API・SDKのポイント
開発者は、リソースの有無だけでなく、コード上の依存関係を確認する必要があります。Metrics AdvisorはAPIやクライアントSDKから利用できたため、アプリケーション内に監視処理として埋め込まれている可能性があります。
コード検索で探すべき文字列の例
以下のような文字列をリポジトリ全体で検索すると、依存箇所を発見しやすくなります。
MetricsAdvisor
metrics-advisor
metricsadvisor
MetricAdvisor
CognitiveServices
Anomaly
DataFeed
AnomalyAlertただし、Anomalyのような一般的な単語は他の異常検知処理にも使われるため、検索結果をそのまま廃止対象と決めつけないようにしてください。エンドポイントURL、Azureリソース名、SDKパッケージ、設定ファイルのキー名を組み合わせて確認すると精度が上がります。
移行時に見直すべき処理
| 既存処理 | 見直す内容 |
|---|---|
| データフィード登録 | Azure Monitor Logs、Log Analytics、Eventhouseなど、移行先のデータ取り込み方式へ変更 |
| 異常検知ロジック | KQL、PromQL、Fabricの異常検知、OSSライブラリなどへ置き換え |
| 検出条件の調整 | Metrics Advisor独自の感度・フィードバック設定をそのまま再現できるとは限らない |
| 通知処理 | Azure Monitorアラート、Action Group、Teams/Webhook連携へ再設計 |
| 根本原因分析 | KQLの集計、diffpatterns()、Workbook、Fabric分析などで代替 |
| テストデータ | 過去の異常・正常データを使い、検出結果の差分を確認 |
移行で失敗しやすいのは、旧サービスの検出結果を「完全に同じ結果で再現する」ことを前提にしてしまうことです。異常検知はアルゴリズム、学習期間、季節性、欠損データの扱いによって結果が変わります。移行後は、同じ異常を検出できるかだけでなく、誤検知が増えないか、通知量が運用可能な範囲かを検証する必要があります。
代替先はAzure Monitor、Fabric、OSSを用途で選ぶ
MicrosoftはMetrics Advisorの代替として、Azure Monitor、Open-Source Anomaly Detector、Microsoft Fabricを挙げています。(Microsoft Learn) ただし、どれか一つが常に正解というわけではありません。監視対象、データ量、リアルタイム性、分析の深さ、運用チームのスキルによって選び方が変わります。
| 代替候補 | 向いている用途 | 注意点 |
|---|---|---|
| Azure Monitor | Azureリソース、アプリ、インフラの監視。既存のLog Analyticsやアラート運用と統合したい場合 | KQLやAzure Monitorの設計理解が必要 |
| Microsoft Fabric | 複数指標を組み合わせた分析、ストリーミングデータ、BI・データ分析基盤との統合 | Fabricワークスペースや容量、データガバナンス設計が必要 |
| Open-Source Anomaly Detector | 独自アプリやオンプレ環境で異常検知ロジックを組み込みたい場合 | 運用、保守、モデル管理、セキュリティ確認を自社で行う必要 |
| 独自実装 | 既存の分析基盤やPython処理に統合したい場合 | 検出精度、説明可能性、監視運用まで自社責任になる |
Azure環境の運用監視が中心なら、まずAzure Monitorを検討するのが自然です。Azure Monitorはメトリック、ログ、トレース、イベントを統合的に収集・分析し、Azureリソースやハイブリッド環境の可観測性を提供するサービスです。(Microsoft Learn)
一方で、設備データ、金融取引、IoT、ネットワークトラフィックのように、複数の変数の関係性を見て異常を判断したい場合は、Microsoft Fabricの多変量異常検知も候補になります。Fabricでは、単一変数の異常検知だけでなく、複数変数の相互関係を見て異常を検出する考え方が説明されています。(Microsoft Learn)
Azure Monitorへ移行する場合の考え方
Azure Monitorへ移行する場合は、Metrics Advisorの機能を1対1で置き換えるのではなく、次のように役割を分解して設計すると進めやすくなります。
| Metrics Advisorでの役割 | Azure Monitorでの代替例 |
|---|---|
| 時系列データの取り込み | Log Analytics、Azure Monitor Metrics、Application Insights |
| 異常検知 | KQLの時系列分析、動的しきい値、スマート検出 |
| 可視化 | Workbook、Metrics Explorer、Azure Managed Grafana |
| 通知 | Azure Monitor Alerts、Action Group |
| 原因分析 | KQL、Log Analytics、Workbook、Application Insights |
| 運用対応 | Alert processing rules、Runbook、Logic Apps連携 |
Azure Monitorでは、KQLの機械学習機能を使って時系列の作成、異常検知、検出設定の調整、根本原因分析ができます。Microsoft Learnでは、make-seriesで時系列を作成し、series_decompose_anomalies()で異常を抽出し、diffpatterns()で異常日の特徴差分を分析する流れが紹介されています。(Microsoft Learn)
KQL移行の簡単なイメージ
たとえば、Log Analyticsに取り込んだ日次の処理件数から異常を検出する場合、考え方は次のようになります。
let starttime = 21d;
let endtime = 0d;
let timeframe = 1d;
YourTable
| where TimeGenerated between (startofday(ago(starttime))..startofday(ago(endtime)))
| make-series ActualValue=sum(Count) default=0
on TimeGenerated
from startofday(ago(starttime))
to startofday(ago(endtime))
step timeframe
by ServiceName
| extend (Anomalies, AnomalyScore, ExpectedValue) = series_decompose_anomalies(ActualValue)
| mv-expand TimeGenerated to typeof(datetime),
ActualValue to typeof(double),
Anomalies to typeof(double),
AnomalyScore to typeof(double),
ExpectedValue to typeof(double)
| where Anomalies != 0
| project TimeGenerated, ServiceName, ActualValue, ExpectedValue, AnomalyScore, Anomalies
| order by abs(AnomalyScore) descこの例はそのまま使う完成版ではなく、移行設計の出発点です。実際には、監視対象の粒度、欠損データ、曜日性、季節性、サービスごとの閾値、通知条件を調整する必要があります。
Microsoft Fabricを検討すべきケース
Microsoft Fabricは、単なる監視通知よりも、データ分析やリアルタイム分析基盤と組み合わせたい場合に候補になります。Fabricの多変量異常検知では、単一の値だけでなく、複数の変数の関係性を時系列で分析する考え方が示されています。(Microsoft Learn)
Fabricが向いている例
たとえば、次のようなケースではAzure MonitorだけでなくFabricも検討する価値があります。
| シナリオ | Fabricが向く理由 |
|---|---|
| 工場設備のセンサー監視 | 温度、圧力、振動、稼働率など複数指標の関係を見る必要がある |
| 金融・決済の不正兆候検知 | 取引額、回数、地域、時間帯などを組み合わせて判断する |
| SaaSの利用状況分析 | テナント別、機能別、時間帯別の変化を分析基盤で扱いやすい |
| BIレポートと異常検知を統合 | Power BIやOneLakeを含むデータ基盤と連携しやすい |
| ストリーミングデータ分析 | Eventhouseを使ったリアルタイム処理と相性がよい |
ただし、Fabricは監視アラートだけを置き換えるための軽量ツールではありません。データ基盤、ワークスペース、権限、容量、ガバナンスの設計が必要です。すでにAzure MonitorやLog Analyticsで運用監視が整っている場合、まずAzure Monitorで最低限の検知・通知を復旧し、その後にFabricで高度な分析を検討する段階的な進め方が現実的です。
移行作業の進め方
Metrics Advisor廃止対応は、技術移行だけでなく運用移行です。検出ロジックを置き換えても、通知先、対応手順、担当者、障害判定基準が古いままでは、実際の障害時に機能しません。
推奨する移行ステップ
| ステップ | 作業内容 | 成果物 |
|---|---|---|
| 現状把握 | Azureリソース、API、SDK、通知、Runbookを棚卸し | 依存一覧 |
| 重要度分類 | 業務影響、通知頻度、代替可否で優先順位付け | 移行優先度表 |
| 代替先選定 | Azure Monitor、Fabric、OSS、独自実装を比較 | 移行方針 |
| データ取り込み設計 | 監視対象データをどこに集約するか決める | データフロー図 |
| 異常検知設計 | 閾値、季節性、学習期間、除外条件を決める | 検知ルール |
| 通知設計 | 誰に、どの条件で、どのチャネルに通知するか決める | 通知設計書 |
| 並行検証 | 旧検知結果と新検知結果を比較する | 差分レポート |
| 切り替え | 通知・運用手順・ダッシュボードを新方式に統一 | 本番反映 |
| 旧設定整理 | 不要なキー、接続情報、手順書を削除 | 廃止完了チェック |
重要なのは、いきなり本番通知を切り替えないことです。過去に実際に発生した異常データを使い、新しい検知方法で同じ兆候を拾えるか確認してください。異常を拾えるだけでなく、正常な繁忙期やキャンペーン日を誤検知しないかも検証します。
移行で失敗しやすいポイント
旧サービスの検出結果を完全再現しようとする
異常検知サービスが変われば、モデル、学習期間、季節性の扱い、スコアリング方法が変わります。完全再現を目標にすると移行が進みません。目標にすべきなのは、旧サービスと同じ結果ではなく、業務上見逃してはいけない異常を検出し、対応可能な通知量に抑えることです。
通知だけ移行して診断手順を更新しない
Azure Monitorアラートに置き換えても、運用担当者が「どのクエリを見ればよいか」「どのダッシュボードで確認するか」を知らなければ、障害対応は遅れます。通知本文には、対象サービス、異常値、期待値、確認用WorkbookやLog Analyticsクエリへの導線を含めると実用性が上がります。
データ欠損を異常として扱ってしまう
Metrics AdvisorからAzure MonitorやFabricへ移行すると、データ取り込みのタイミングが変わります。バッチ集計が遅れた場合、値が0または欠損として扱われ、誤検知が増えることがあります。データ生成が遅れる業務では、取り込み遅延を考慮したクエリ期間や通知条件を設計してください。
多次元分析を単純な閾値監視に置き換えてしまう
Metrics Advisorを使っていた環境では、地域、テナント、商品、言語、チャネルなどのディメンション別に異常を見ていた可能性があります。移行時に全体値だけを監視すると、一部テナントや特定地域だけの異常を見逃すことがあります。旧設定で使っていたディメンションは必ず洗い出しましょう。
期限前に確認すべき実務チェックリスト
最後に、管理者と開発者がすぐに確認できるよう、実務向けのチェックリストをまとめます。
| 担当 | 確認項目 | 完了基準 |
|---|---|---|
| Azure管理者 | Metrics Advisorリソースの有無 | 対象サブスクリプション全体で確認済み |
| Azure管理者 | Azure Advisorの推奨事項 | Metrics Advisor廃止の推奨事項を確認済み |
| 開発者 | API・SDK依存 | リポジトリ、設定ファイル、環境変数を検索済み |
| 開発者 | 通知連携 | Webhook、Teams、メール、DevOps連携を確認済み |
| 運用担当 | 障害対応手順 | Metrics Advisor前提の手順を更新済み |
| データ担当 | 監視データの移行先 | Log Analytics、Fabric、その他基盤を決定済み |
| セキュリティ担当 | 不要なキー・シークレット | Key VaultやCI/CD変数から不要項目を削除済み |
| 全体 | 並行検証 | 過去データと本番相当データで検知結果を比較済み |
まとめ：Metrics Advisor廃止対応は「監視の再設計」として進める
Azure AI Metrics Advisorは、2026年5月18日時点で廃止済みと案内されており、Microsoftのドキュメントでも新規リソース作成不可、ポータル無効化、サービス廃止期限が示されています。(Microsoft Azure) そのため、既存環境では「まだ使えるか」を確認する段階ではなく、どこに依存が残っているか、何へ移行するか、運用手順まで更新できているかを確認する段階です。
まずはAzure Advisor、Azureリソース、APIキー、コード、通知設定、Runbookを棚卸ししてください。Azureリソースやアプリの監視が中心ならAzure Monitor、複数指標を組み合わせた高度な時系列分析が必要ならMicrosoft Fabric、独自アプリに組み込むならOSSや自社実装を検討します。
移行のゴールは、旧Metrics Advisorの画面や検出結果をそのまま再現することではありません。異常を見逃さず、誤通知を抑え、担当者がすぐ原因調査に入れる監視運用へ作り直すことです。まずは依存箇所の棚卸しから始め、重要度の高い通知・業務影響の大きいメトリックから優先して移行を進めましょう。
コメント