Azure SRE Agent の引き合いが少しずつ増えてきています。

Azure SRE Agent が具体的にどのような運用を支援できるのかを理解するため、公式リポジトリで公開されている Hands-On Lab をベースに実際に操作してみます。

本記事はシリーズの第 1 回として、チュートリアル環境の構成、前提条件、デプロイまでを扱います。次回以降では、障害調査、コードを利用した根本原因分析、GitHub issue のトリアージを順に試す予定です。

本記事は GitHub Copilot を活用して作成しています。

要約

• Azure SRE Agent は、アラートの調査、定常運用、根本原因分析を支援する Azure のエージェント型運用サービスです
• 公式 Hands-On Lab では、サンプルアプリケーション、Azure Monitor、Log Analytics、Application Insights、Azure SRE Agent をまとめてデプロイできます
• チュートリアルを通じて、監視シグナル、ナレッジ、ソースコードをどのように調査へ活用するのかを確認します
• 変更や修復は人による承認を前提とし、エージェントにすべてを無条件で任せる仕組みではありません

想定される読者

• Azure 環境の運用や SRE に関心がある
• Azure SRE Agent でできることを、実際のサンプル環境で確認したい
• Azure Monitor、Application Insights、Log Analytics を利用した障害調査を効率化したい

Azure SRE Agent とは

Azure SRE Agent は、インシデント調査や定常運用の作業を支援し、運用上の手作業（toil）を減らすためのサービスです。

監視ツール、インシデント管理ツール、ソースコードリポジトリを接続し、アラートに対して関連するログ、メトリック、デプロイ履歴、コードを横断して調査します。調査結果では根本原因の仮説と対応案を提示し、対応の実行は人による承認を経て行う設計です。

主なユースケースは次のとおりです。

• アラート発生時の情報収集、相関分析、根本原因の仮説提示
• ヘルスチェックやコンプライアンス確認など、スケジュールされた定常作業
• 「直近で何が変わったか」「なぜサービスが劣化しているか」といった自然言語での調査

Azure SRE Agent は、スキル、サブエージェント、Python ツール、MCP サーバー、エージェント フックによって拡張できます。実行前には権限ゲートが評価され、必要に応じて承認やポリシーによる制御を行えます。

今回試す Hands-On Lab

今回利用するのは、Microsoft が公開している Azure SRE Agent Hands-On Lab です。

Lab では、障害を発生させることができる Grubify というサンプルアプリケーションと Azure SRE Agent をデプロイし、アラートから調査、修復提案までの流れを確認できます。

flowchart LR
  User["利用者"] --> Frontend["Grubify Frontend<br/>Azure Container Apps"]
  Frontend --> API["Grubify API<br/>Azure Container Apps"]
  API --> AI["Application Insights"]
  API --> LA["Log Analytics"]
  AI --> Alert["Azure Monitor Alert"]
  Alert --> SRE["Azure SRE Agent"]
  LA --> SRE
  KB["Knowledge Base<br/>Runbook / Architecture"] --> SRE
  GitHub["GitHub Repository<br/>任意"] --> SRE
  SRE --> Review["調査結果と修復案"]
  Review --> Approval["人による承認"]

  classDef app fill:#e8f4fd,color:#000,stroke:#0078d4,stroke-width:2px
  classDef observe fill:#fff4ce,color:#000,stroke:#d83b01,stroke-width:2px
  classDef agent fill:#e6f4ea,color:#000,stroke:#107c10,stroke-width:3px
  classDef human fill:#f3e8ff,color:#000,stroke:#8764b8,stroke-width:2px

  class Frontend,API app
  class AI,LA,Alert observe
  class SRE,KB,GitHub agent
  class User,Review,Approval human

Lab で作成される主なリソース

デプロイ後は、HTTP エラーの Runbook、アプリケーション構成、インシデント テンプレートをナレッジとして読み込ませます。また、HTTP 500 アラートを調査するためのサブエージェントと応答プランも設定されます。

前提条件

Hands-On Lab を実施するには、次の環境を用意します。

Owner ロールは、Lab のデプロイ中にロール割り当てを作成するために必要です。また、Azure SRE Agent のリソース プロバイダーではなく、Container Apps 用の Microsoft.App リソース プロバイダーを事前に登録します。

1

az provider register --namespace Microsoft.App --wait

注意: チュートリアルでは Azure リソースをデプロイします。検証後は不要な課金を避けるため、リソース グループを削除します。

環境をデプロイする

公式 Lab の手順に従い、リポジトリを取得して azd up で環境をデプロイします。

1
2
3
4
5
6
7
8
9

git clone https://github.com/dm-chelupati/sre-agent-lab.git
Set-Location sre-agent-lab
git submodule update --init --recursive

az login
azd auth login

azd env new sre-lab
azd up

リージョンの選択では、Azure SRE Agent が利用可能なリージョンを選択します。本記事の執筆時点では、eastus2、swedencentral、australiaeast が対象です。

今回の環境では、プロビジョニングに 4 分 13 秒かかりました。所要時間は環境や Azure リソースの作成状況によって変わります。

SUCCESS: Your application was provisioned and deployed to Azure と表示されれば、デプロイは完了です。

Azure SRE Agent のセットアップを確認する

デプロイが完了したら、Azure SRE Agent を開き、対象のエージェントで 完全セットアップ を選択します。今回の環境では、azd up によってコード、Azure リソース、ナレッジ ファイルが自動的に登録されていました。

画面下部の 完了してエージェントに移動 を選択すると、Team onboarding スレッドが開きます。エージェントは接続済みのコード、Azure リソース、ナレッジを確認し、チーム構成、オンコール、担当サービス、エスカレーション経路を質問します。

オンボーディングとは別に新しいチャット スレッドを作成し、次のような質問でエージェントが取得したコンテキストを確認します。

1

Grubify アプリケーションのアーキテクチャについて、把握している内容を教えてください。

1

HTTP エラーの Runbook を要約してください。

1

リソース グループには、どのような Azure リソースがありますか？

Grubify アプリケーションのアーキテクチャについて質問すると、エージェントは接続済みのリポジトリから README.md、azure.yaml、Bicep、アプリケーション コードなどを参照し、フロントエンド、バックエンド、インフラストラクチャの構成を整理して回答しました。

HTTP エラーの Runbook について質問すると、ナレッジ ファイルから Container Apps の HTTP エラー診断 Runbook を検索し、利用するタイミングや 5 ステップの診断ワークフローを要約しました。

Azure リソースについて質問すると、接続済みのリソース グループに対してリソース一覧を取得し、Container Apps、Log Analytics workspace、Application Insights、Azure Container Registry、Managed Identity、Azure SRE Agent などを表形式で回答しました。

このシリーズで確認すること

このシリーズでは、環境準備に続いて Lab に用意された 3 つのシナリオを段階的に試します。

特に次の観点を意識して確認します。

• エージェントが根本原因の仮説を示す際に、どのログ、メトリック、ナレッジを根拠にするか
• 修復案に対して、どこまで人が判断・承認する必要があるか
• 既存の Runbook やチーム固有の情報を、どのようにナレッジとして活用できるか
• GitHub 連携により、運用情報とコード情報をどのように結び付けられるか

検証環境を削除する

シリーズの検証が完了したら、不要な課金を避けるために azd down で作成した Azure リソースを削除します。

1

azd down --purge

注意: このコマンドを実行すると、Lab で作成したリソースが削除されます。後続のシナリオを試す場合は、シリーズ全体の検証が完了してから実行してください。

まとめ

Azure SRE Agent の Hands-On Lab を使うと、サンプルアプリケーション、監視基盤、ナレッジ、Azure SRE Agent の連携を一度に構築できます。

初回では環境と構成を確認しました。次回は意図的にアプリケーション障害を発生させ、Azure Monitor のアラートを起点に Azure SRE Agent がどのように調査・修復提案を行うかを確認します。

参考

• Azure SRE Agent - Resources (GitHub)
• Azure SRE Agent Hands-On Lab (GitHub)
• Overview of Azure SRE Agent (Microsoft Learn)