Azure AI Metrics Advisor

解決する課題

ビジネス指標やシステムメトリクスの異常、たとえば「売上が急に落ちた」「あるリージョンだけエラー率が跳ねた」といった変化を、人手のダッシュボード監視や固定しきい値で検知し続けるのは大変です。系列の数が増え、曜日・季節などの周期があると、固定しきい値は誤検知と見逃しを繰り返します。Azure AI Metrics Advisor は、時系列データに異常検知を自動適用し、検知した異常をインシデントにまとめ、どの次元（ディメンション）が原因かの診断まで支援する仕組みを、機械学習の専門知識なしに使えるようにすることを狙ったサービスです。

• 多数の 時系列メトリクスを横断的に監視し、異常を自動検知したい
• 売上やトラフィックなど 周期性のあるデータを、固定しきい値ではなく学習ベースで監視したい
• 検知した異常を インシデント単位に集約し、アラート疲れを減らしたい
• 「どの国・どの製品が原因か」といった 次元の切り口で根本原因を素早く絞り込みたい
• モデルの構築・運用を抱えずに マネージドな異常検知を業務システムへ組み込みたい

主要概念と用語

• データフィード（Data Feed）: 監視対象の時系列データを取り込む単位。データソースへの接続情報や取り込み間隔（粒度）を定義する
• メトリック（Metric）: 監視対象となる数値の系列。売上やリクエスト数など、時間とともに変化する値を指す
• ディメンション（Dimension）: メトリックを切り分けるカテゴリ軸。国・言語・製品などの値の組み合わせが1本の単変量時系列（系列）を特定する
• 時系列（Time Series）: 1つのメトリックと特定のディメンション値の組み合わせで決まる、時間に沿った1本のデータ列
• 異常（Anomaly）: 学習された通常範囲から外れた点。各時系列ごとに検知される
• インシデント（Incident）: 同じタイミングで関連して発生した複数の異常をまとめた単位。アラートやトリアージはこの単位で扱う
• 検知設定（Detection Configuration）: どの感度・手法で異常とみなすかを定める設定。系列ごと・グループごとに調整できる
• 根本原因の診断（Diagnostics / Root Cause）: 1つの多次元メトリック内の異常を診断ツリーとして整理し、相関やクラスタリングで原因のディメンションを絞り込む機能
• フック（Hook）とアラート設定: 異常検知時にメール・Teams・Webhook などへ通知する連携先と条件の設定

仕様・制限・クォータ

• 取り込み→検知→診断→通知という一連の流れを、API と（提供期間中の）Web ポータルで扱う
• 多次元メトリクスを対象とし、ディメンション値の全組み合わせの時系列を自動で監視する
• 取り込みには データソースへの接続が必要で、SQL 系・ストレージ・各種データウェアハウスなど複数のソース種別をサポートしていた
• データには 一定の粒度（取り込み間隔）と過去データの蓄積が前提となり、周期や傾向の学習に十分な履歴が要る
• データフィードあたりのディメンション数・系列数・メトリック数などに上限があり、規模が大きいデータは設計時に分割を検討する
• 新規リソースの作成は停止され、サービス自体に 廃止スケジュールが設定されている。具体的な上限値・対応データソース・廃止日付は更新されるため、必ず最新の公式情報で確認する

内部の仕組み

Azure AI Metrics Advisor は、取り込んだ時系列に対して 異常検知モデルを自動的に適用し、各系列の通常範囲を学習したうえで外れ値を異常として検出します。利用者はモデルそのものを構築・調整する必要がなく、感度などの設定を通じて挙動を調整します。

• データ取り込み: 設定した粒度でデータソースから定期的に値を取り込み、ディメンションの組み合わせごとに時系列を構成する
• 異常検知: 各時系列の周期・傾向を踏まえて通常範囲を推定し、そこから外れた点を異常としてフラグ付けする。感度（しきい値）は検知設定で調整できる
• インシデント集約: 同一の多次元メトリック内で同じタイミングに発生した複数の異常を相関・クラスタリングし、関連するものを1つのインシデントへまとめる
• 根本原因の診断: インシデントを診断ツリーとして整理し、どのディメンション値に異常が集中しているかを示して原因の切り口を絞り込む。複数メトリック間の関連も加味した分析を有効化できる
• 通知: アラート設定とフックに従い、インシデント発生時に外部へ通知する

設計パターン / ベストプラクティス

• ディメンション設計を絞る。組み合わせ爆発で系列数が膨らむと監視・診断が見づらくなるため、本当に切り分けたい軸だけを採用する
• 十分な履歴データを用意してから検知を有効化し、周期や傾向を学習させる
• 感度を段階的に調整し、まず緩めに始めて誤検知・見逃しのバランスを見ながら締めていく
• アラートはインシデント単位で設計し、系列ごとの大量通知によるアラート疲れを避ける
• 異常検知は 下流の対応フロー（チケット起票・自動対処）と連携させ、検知を行動につなげる
• 新規構築では本サービスを採用せず、代替サービスへの移行を前提に設計する

運用・監視

• Azure Monitor のメトリクスで API 呼び出し回数・遅延・エラー率・スロットリングを監視する
• 診断設定でログを Log Analytics へ送り、取り込み失敗や検知結果の傾向を分析する
• 取り込みジョブの 失敗・遅延を監視し、データフィードが止まって監視に穴が空かないようにする
• フックや通知先（メール・Teams・Webhook）の 到達性を定期確認し、アラートが確実に届く状態を保つ
• 廃止スケジュールを踏まえ、代替への移行計画とデータのエクスポートを運用タスクとして管理する

コスト

課金は基本的に 監視する時系列の数（系列数）を中心とした従量制で、取り込み頻度やディメンションの組み合わせ数が増えるほどコストが上がります。ディメンション設計を絞り、不要な系列を監視対象から外すことが直接的なコスト最適化になります。

セキュリティ

• Microsoft Entra ID 認証 + RBAC を基本とし、キー認証への過度な依存を避ける
• リソースのキーや接続文字列は Key Vault で管理し、コードへのハードコードを避ける
• データソースへの接続は 最小権限で設定し、読み取り専用の資格情報を用いる
• プライベートエンドポイント / 仮想ネットワークで通信を閉域化できる
• 保存データはサービス側で暗号化され、要件に応じて カスタマーマネージドキーにも対応する
• データレジデンシー（処理リージョン）の要件を満たすリージョンを選ぶ

関連サービス・比較

Azure AI Metrics Advisor は時系列の異常検知と診断に特化したサービスでした。単発の異常検知 API である Anomaly Detector が基盤的な機能を、Metrics Advisor が監視・診断・通知まで含むワークフローを担う関係でしたが、いずれも廃止の流れにあり、近い領域は Azure Monitor や Microsoft Fabric などへ移っています。

ハンズオン / CLI例

新規リソースの作成は停止されているため、ここでは既存リソースの情報確認を中心とした例を示します。ここに挙げる種別名やオプションは環境やサービス状態により異なるため、実行可否は最新の公式情報で確認してください。

# 既存の Cognitive Services / Azure AI services リソースを一覧する
az cognitiveservices account list \
  --resource-group demo-rg \
  --query "[].{name:name, kind:kind, location:location}" -o table

# 特定リソースのエンドポイントを確認（アプリから API を呼ぶ際に使う）
az cognitiveservices account show \
  --resource-group demo-rg \
  --name demo-metricsadvisor \
  --query "properties.endpoint" -o tsv

# アクセスキーを確認（Key Vault 管理を推奨）
az cognitiveservices account keys list \
  --resource-group demo-rg \
  --name demo-metricsadvisor \
  --query "key1" -o tsv

# 利用可能な種別を確認し、現行で作成可能なサービスかを把握する
az cognitiveservices account list-kinds -o table