Copilot Studio エージェントで Azure Monitor アラート調査を自動化してみた

本記事では、Azure Monitor のアラートを Microsoft Copilot Studio のエージェントが自動で分析し、Microsoft Teams に調査レポートを投稿する仕組みを検証した事例を紹介します。

Azure Monitor でアラート運用をしている方や、Copilot Studio を活用した運用自動化に関心がある方を対象としています。Azure Monitor、Azure Logic Apps、Microsoft Teams の基本操作を把握していることを前提とします。

背景と課題
全体アーキテクチャ
仕組みのポイント
検証結果
- 既知エラーの自動判定
- 新規エラーの自動調査
得られた知見と注意点
まとめ

背景と課題

筆者のチームでは、業務アプリケーションの運用監視において、例外（Exception）発生時の一次調査を効率化したいという課題がありました。

今回は Azure Monitor のログ検索アラートを使った構成を想定し、アラート発生時に担当者が行う以下の手順を自動化できないか検証しました。

アラートの詳細を開き、「結果をログに表示」リンクから Application Insights のログに遷移する
KQL（Kusto Query Language）クエリの実行結果から、エラータイプ、発生時刻、アクセス元を確認する
既知エラーの一覧と照合して、新規エラーか既知エラーかを判定する
調査結果をチケットに記載し、チームへ報告する

作業自体は定型的ですが、1件あたり 10～15分程度かかります。この一次調査をエージェントに任せられないかと考え、検証を行いました。

全体アーキテクチャ

構築した仕組みは、以下の 4つのコンポーネントで構成しています。

コンポーネント	役割
Azure Monitor ログ検索アラート	`exceptions` テーブルを監視し、例外の発生を検出すると Webhook を発火する
Azure Logic Apps	組み込みの HTTP トリガーで Webhook を受信し、KQL クエリでエラー詳細を取得して Teams に通知する
Microsoft Teams	Logic Apps からの通知を受け取り、エージェントへのメッセージハブとして機能する
Microsoft Copilot Studio エージェント	Teams への投稿をトリガーに起動し、ナレッジ照合とレポート生成を行う

おおまかな処理の流れは以下のとおりです。

Azure Monitor が例外を検出し、共通アラートスキーマの Webhook で Logic Apps に通知する
Logic Apps が KQL クエリを実行し、エラーの詳細データを取得して Teams に投稿する
Teams への投稿をトリガーに Copilot Studio エージェントが起動し、ナレッジの照合やレポート生成を行う
Adaptive Card 形式の調査レポートを Teams に投稿する

Logic Apps の HTTP トリガーは組み込み（Built-in）のため追加コストがかかりません。Power Automate Premium ライセンスなしで Webhook を直接受信できる点も、この構成を採用した理由の一つです。

仕組みのポイント

共通アラートスキーマの活用

Azure Monitor のアクショングループで「共通アラートスキーマを有効にする」を設定すると、アラートの種類に関わらず統一された JSON 形式のペイロードが送信されます。ただし、ログ検索アラート V2 のペイロードにはエラーの詳細データ行が含まれていません。

そのため、Logic Apps 側で別途 KQL クエリを実行して詳細を取得する設計としました。

Logic Apps による KQL クエリの実行

Azure Monitor Logs コネクタを使うと、Logic Apps から Application Insights の exceptions テーブルに直接クエリを実行できます。

exceptions
| where timestamp >= ago(10m)
| project type, operation_Name, timestamp,
         client_City, client_CountryOrRegion,
         outerMessage, session_Id
| order by timestamp desc

取得したエラータイプやエラーメッセージなどの詳細を Teams に投稿し、Copilot Studio エージェントの入力データとします。

エージェントの Instructions 設計

Copilot Studio エージェントの動作は、Instructions（指示）の記述に大きく左右されます。今回は以下の処理を自律的に実行するよう指示を記述しました。

受信データをエラータイプごとにグルーピングする
ナレッジファイル（既知エラー一覧）と照合し、既知エラーか新規エラーかを判定する
新規エラーの場合は Web 検索で技術情報を調査する
Adaptive Card 形式のレポートを生成し、Teams に投稿する

特に「完全自動実行」の制約が重要です。エージェントがユーザーに確認や入力を求めてしまうと自動化フローが止まるため、Instructions に「ユーザーへの質問は一切行わないこと」と明記しています。

検証結果

既知エラーの自動判定

既知エラーが検出された際のテストでは、エージェントがナレッジファイルと照合し、「既知エラー」と判定しました。ナレッジに記載されたエラー概要と問題管理番号を含むレポートが Teams に投稿されています。

出力結果は以下のとおりです。

新規エラーの自動調査

ナレッジに該当のないエラーが検出された際のテストでは、エージェントが Web 検索を実施し、推定原因、影響範囲、推奨対応を含むレポートが Teams に投稿されています。

出力結果は以下のとおりです。

いずれのケースでも、アラートの発火から Teams への調査レポート投稿まで 2～3 分で完了しました。

得られた知見と注意点

検証を通じて、エージェントの Instructions 設計に関する知見を得ました。

長い URL によるペイロードサイズ超過:
- エラーメッセージに長い URL が含まれると Adaptive Card のサイズ上限を超えることがあるため、URL を 50文字で切り詰めるルールを設けました。
Adaptive Card で \n は改行として描画されない:
- テキストを改行する場合は、1行ごとに個別の TextBlock を定義する必要があります。
Adaptive Card の JSON に脚注が混入する:
- エージェントがナレッジを参照すると、Adaptive Card 用の JSON 末尾に [1]: URL 形式の脚注が自動付加されることがあります。
- JSON として不正な形式になるため、Teams への投稿時に HTTP 400 エラーが発生します。
- Instructions に「JSON の外部にテキストを追加してはならない」と明記して回避しました
禁止事項には理由を添える:
- 「HTTP 400 エラーが発生するため」のように理由を併記すると、エージェントの遵守率が上がる傾向がありました