Azure SRE Agent に障害調査から GitHub の修正 PR 作成まで任せてみた
製造ビジネステクノロジー部の小林です。
Azure SRE Agent は、アラートを起点に Application Insights のデータやデプロイ履歴を調べて原因を分析するサービスです。同様の機能を持つサービスとして AWS DevOps Agent があります。
今回は Azure SRE Agent を実際に動かして、次の 3 つをどこまで任せられるのかを確かめてみました。
- 障害検知: Azure Monitor のアラートを受け取って自動で調査を開始する
- 障害調査: ログ、メトリクス、ソースコード、デプロイ履歴を突き合わせて根本原因を特定する
- PR 作成: 特定した原因に対する修正ブランチを作り、GitHub に Pull Request を出す
検証はすべて Azure ポータルと SRE Agent ポータルの画面操作で行います。
今回つくる構成
App Service 上の .NET アプリにわざとバグを含むコミットをデプロイし、HTTP 500 を発生させます。メトリクスアラートが発火すると、SRE Agent がアラートを拾って調査を始め、最後に GitHub へ修正 PR を作成する流れです。
SRE Agent 側のポイントは次の 3 つです。
- インシデントプラットフォームとして Azure Monitor を接続すると、エージェントが 1 分ごとにアラートをスキャンして自動で調査スレッドを開きます
- レスポンスプランで「どの重大度・どのタイトルのアラートを拾うか」と「Review（承認制）か Autonomous（自律）か」を決めます
- GitHub をコード参照用と操作用（GitHub MCP）の 2 通りで接続すると、コードの行番号付きで原因を示したうえで PR 作成まで行えます
前提と注意点
必要な権限とアカウント
| 項目 | 内容 |
|---|---|
| Azure サブスクリプション | エージェントを作成する RG またはサブスクリプションに対して Owner、もしくは Contributor と User Access Administrator の両方 |
| サブスクリプション種別 | 無料試用版では App Service のクォータの上限が 0 に設定されているリージョンがあります。また sre.azure.com の作成画面で Region が空欄なら、そのサブスクリプションは SRE Agent 未登録です |
| GitHub アカウント | サンプルリポジトリをフォークし、OAuth でサインインできること |
| リージョン | 執筆時点では Japan East / Japan West を含む 22 リージョンで利用可能。作成後に変更はできません |
料金について
SRE Agent は Azure Agent Unit（AAU）という単位で課金されます。押さえておきたいのは、エージェントが存在するだけで発生する固定費がある点です。
| 課金区分 | 内容 |
|---|---|
| Always-on（固定） | エージェント 1 つにつき 4 AAU / 時。作成から削除まで継続して発生 |
| Active flow（変動） | 調査やチャットで消費した LLM トークン量に応じて発生。モデルごとに AAU レートが異なる |
公式ドキュメントの目安では、Azure Monitor からの自動インシデント調査 1 件で 35 AAU 前後（Claude Opus 4.6 の場合）とされています。新規利用者は最初の 30 日間 Always-on 分が免除される評価プログラムがあります。
検証が終わったら「停止」ではなく「削除」してください。停止では Always-on の課金が続きます。詳細と最新の単価は料金ページを確認してください。
準備 1: サンプルアプリを GitHub にフォークする
Microsoft が SRE Agent のチュートリアル用に公開している .NET のサンプルアプリを使います。ボタンを押すとカウンターが増えるだけの小さな Web アプリで、環境変数 INJECT_ERROR が 1 のときに 6 回目以降のクリックで例外を投げる仕組みが入っています。
- 上記リポジトリを自分の GitHub アカウントにフォークします
- フォーク先のリポジトリ名を控えておきます（以下
OWNER/app-service-dotnet-agent-tutorialと表記）
後で SRE Agent に PR を作らせるため、必ず自分が書き込めるフォーク先を使います。
準備 2: App Service を作成して GitHub からデプロイする
Web App の作成
Azure ポータルで「App Services」を開き、「作成」から「Web アプリ」を選びます。
| 設定 | 値 |
|---|---|
| リソースグループ | 新規作成 rg-sre-demo-app |
| 名前 | 任意（例: sre-demo-app-xxxx） |
| 公開 | コード |
| ランタイムスタック | .NET 9 (STS) |
| オペレーティングシステム | Windows |
| リージョン | Japan West（後述のクォータの都合。Japan East でも可） |
| 価格プラン | Free F1（検証用。負荷をかけないので無料枠で足ります） |
「監視 + セキュリティ」タブで Application Insights を「有効」にして、新規作成を選びます。リージョンは Web アプリと同じにします。SRE Agent が後でリクエストの失敗ログを調べるために使います。
「確認および作成」から作成します。
作成時に「Operation cannot be completed without additional quota」というエラーが出た場合は、そのリージョンの App Service VM の上限（クォータ）が 0 になっています。
無料試用版や作成直後のサブスクリプションで起こりやすく、SKU を変えても解消しません。クォータはリージョンごとなので、別のリージョンに切り替えるのが近道です。私の環境では Japan East と East US 2 が 0 で、Japan West では作成できました。
デプロイセンターで GitHub を接続
作成した Web App の「デプロイ センター」を開きます。ソースで「GitHub」を選んだ直後は組織やリポジトリのドロップダウンが表示されません。
「サインイン ユーザー名」の横にある「認可」を押して GitHub の認可ポップアップを許可すると、組織・リポジトリ・ブランチが選べるようになります。組織では会社の Organization ではなく、フォーク先の自分のユーザー名を選びます。
認可後に次の設定で保存します。
| 設定 | 値 |
|---|---|
| ソース | GitHub |
| 組織 / リポジトリ | フォークした OWNER/app-service-dotnet-agent-tutorial |
| ブランチ | main |
| 認証の種類 | ユーザー割り当て ID（既定） |
上部に「運用スロットにいます。CI/CD の設定にはおすすめできません」という情報バーが出ますが、今回はスロットを使わず運用スロットへ直接デプロイする構成なので、そのまま進めて問題ありません。
保存すると、リポジトリに GitHub Actions のワークフローファイルがコミットされ、初回デプロイが走ります。GitHub 側の Actions タブでワークフローが成功したことを確認します。
この「GitHub Actions 経由でデプロイする」構成にしておくことで、SRE Agent が「どのコミットがいつデプロイされたか」をコードと突き合わせられるようになります。
動作確認
Web App の「概要」から「参照」で URL を開き、カウンターが表示されてボタンで増えることを確認します。
GitHub Actions が成功した直後は「Your web app is running and waiting for your content」という App Service の初期ページが表示されることがあります。反映まで数分かかるので、少し待ってからリロードしてください。
準備 3: HTTP 5xx のメトリクスアラートを作成する
SRE Agent がアラートを拾うための Azure Monitor アラートルールを作ります。Web App の左メニューで「監視」の「警告」を開き、「作成」から「アラート ルール」を選びます。
| 設定 | 値 |
|---|---|
| シグナル | Http Server Errors（メトリクス Http5xx） |
| しきい値の種類 | 静的 |
| 集計の種類 | 合計 |
| 演算子 | 次の値より大きい |
| 単位 | カウント |
| しきい値 | 3 |
| 評価の頻度 / 集計の粒度 | 1 分 / 5 分 |
| 重大度 | 2 - 警告 |
| アラート ルール名 | [SRE-TEST] sre-demo-app Http5xx |
アクショングループは不要です。SRE Agent はアクショングループ経由ではなく、マネージド ID でアラート一覧を直接スキャンします。
アラートルール名の先頭に [SRE-TEST] を付けているのは、後でレスポンスプランの「Title contains」フィルターでこのアラートだけを拾わせるためです。
SRE Agent を作成する
エージェント本体の作成
SRE Agent の管理ポータルは Azure ポータル（portal.azure.com）とは別の専用サイトです。ここから先の「ビルダー」「コネクタ」「インシデント」といったメニューはすべてこの専用サイト側にあり、Azure ポータルの Web アプリの画面には出てきません。
- Azure の資格情報でサインインし、「エージェントの作成」を選びます
- 基本情報で次の値を入力します
| 項目 | 値 |
|---|---|
| Subscription | 利用するサブスクリプション |
| Resource group | rg-sre-demo-app_group（今回は検証なのでアプリと同じ RG にまとめました。本番ではエージェント用に分ける方が管理しやすいです） |
| Agent name | sre-demo-agent |
| Region | Japan West（アプリと同じ） |
| Model provider | Anthropic（私の環境では Anthropic と Azure OpenAI が表示され、Anthropic が「優先」でした。候補はサブスクリプションとリージョンにより異なります） |
| User-assigned managed identity | 新規作成 |
| Application Insights | 新規作成（エージェント自身の監査ログ用） |
- レビューで内容を確認し、「作成」を選びます。デプロイには 2〜5 分かかります
デプロイが完了すると、エージェント用のユーザー割り当てマネージド ID、Application Insights、Log Analytics ワークスペースが同じリソースグループに作成されます。
コード・ログ・Azure リソースの接続
デプロイ後に「Set up your agent」を選ぶと「コンテキストが多いほど、調査が向上します。」というセットアップ画面が開きます。クイックスタート タブで 3 つのデータソースを順に接続します。
コードカードの「+」を選び、GitHub を「Your account」（OAuth）で認証します。
リポジトリ URL にフォークした OWNER/app-service-dotnet-agent-tutorial を入力し、「GitHub にサインイン」で認可して保存します。
ログカードの「+」を選び、「Application Insights」を選択します。
準備 2 で作成した App Service 側の Application Insights（今回は sre-demo-app）を指定して「コネクタの追加」を選びます。
保存時にエージェントのマネージド ID へ Log Analytics Reader と Monitoring Reader が自動で付与されます。
Azure リソースカードの「+」を選び、リソースの種類で「リソース グループ」、続いて rg-sre-demo-app_group を選択します。権限レベルは「閲覧者」と「特権」から選べます。
| 権限レベル | 付与されるロール | 挙動 |
|---|---|---|
| 閲覧者 | Reader、Monitoring Reader、Log Analytics Reader など読み取り系 | 書き込み操作が必要なときは、SRE Agent 管理者の資格情報を一時的に借りる On-Behalf-Of フローで承認を求める |
| 特権 | Reader 相当に加えて、RG 内のリソース種別に応じた Contributor 系ロール | 承認後にマネージド ID 自身で再起動やスロットスワップなどを実行する |
今回のゴールは「調査して PR を出す」ことで、Azure リソースへの書き込みは必要ありません。影響範囲を小さく保つため「閲覧者」を選びました。
最後に「完了してエージェントに移動」を選ぶとチャット画面に移ります。チャットが開くとエージェントがすぐに環境の把握を始め、Azure Resource Graph のクエリに続いて az webapp show を実行しようとしました。
ここで早速、マネージド ID では認可エラーになったとして「アクセス許可の付与」（On-Behalf-Of）を求められました。閲覧者権限でも読み取りコマンドで OBO を求められる点は、後のインシデント調査でも同じ挙動でした。
接続確認として次のように聞いてみます。
過去24時間以内にエラーが発生していないか確認してください。
エージェントは Application Insights に 3 本のクエリを投げ、いずれも空だったため「本当にデータが無いのかクエリ対象が違うのか」を切り分けるサンプル取得まで自分で行いました。
最終的にはプラットフォーム メトリクスに切り替え、過去 24 時間の Http5xx が 0 件、Http4xx が 1 件、リクエストが 17 件という表にまとめたうえで、Application Insights のテーブルが空である点を注意点として挙げてきました。
GitHub MCP コネクタの追加（PR 操作用）
セットアップ画面で接続した Code Access は、コードを読んで原因箇所を特定するためのものです。ブランチの作成や PR の作成といった GitHub への書き込み操作には、別途コネクタが必要です。
今回は GitHub 公式の MCP サーバーに接続する GitHub MCP を使いました。
まず GitHub 側で Fine-grained の個人用アクセストークン（PAT）を作ります。「Settings」の「Developer settings」から「Personal access tokens」、「Fine-grained tokens」で「Generate new token」を選びます。
| 項目 | 値 |
|---|---|
| Resource owner | 自分のアカウント |
| Expiration | 7 日程度（検証後に失効させるため短めに） |
| Repository access | Only select repositories で、フォークした app-service-dotnet-agent-tutorial を選択 |
| Contents | Read and write（ブランチ作成とファイル push に必要） |
| Pull requests | Read and write（PR 作成に必要） |
| Issues | Read and write（Issue 作成に必要） |
| Metadata | Read-only（自動で付与） |
続いて SRE Agent ポータルでコネクタを追加します。
- 左メニューの「Builder」（構築とセットアップ）から「Connectors」（コネクタ）を開き、「Add connector」（コネクタの追加）を選びます
- コネクタの選択で GitHub を選び、コネクタの設定で次の値を入力します
| 項目 | 値 |
|---|---|
| 名前 | sre-demo-app-github-connector |
| 接続の種類 | Streamable-HTTP |
| URL | https://api.githubcopilot.com/mcp/ |
| 個人用アクセス トークン (PAT) または API キー | 上で作成した PAT |
- 「接続の確認とテスト」で接続が通ることを確認します
- 「ツールの選択」で、エージェントに許可するツールを選びます。GitHub MCP には 49 個のツールがあり、今回は検証なのですべて有効にしました
本番で使う場合は、ここで削除系やマージ系のツールを外しておくと安心です。許可するツールをコネクタ単位で絞れるのが MCP コネクタの利点です。
接続できたか、チャットで確認します。
https://github.com/OWNER/app-service-dotnet-agent-tutorial の直近のコミット一覧を取得してください。
MCP の List Commits ツールが呼ばれ、デプロイ設定のコミットとフォーク元の初期コミット 2 件が表で返ってきました。GitHub への接続はこれで確認できました。
Azure Monitor を接続してレスポンスプランを作る
左メニューの「インシデント」から「トリガーと応答プラン」を開きます。
- 「インシデントプラットフォームを接続する」を選び、「Azure Monitor」を選択して保存します。執筆時点の日本語 UI では、接続済みでも「Azure Monitor が接続されていません」と表示されました。緑のチェックが付き、「…」メニューに「切断」が出ていれば接続できています
- 「対応計画を追加する」を選び、次の内容で作成します
| 項目 | 値 | 補足 |
|---|---|---|
| インシデント対応計画名 | sre-test-http5xx-review |
|
| 重大度 | Sev2 | アラートルールの重大度に合わせる |
| 次を含むタイトル | SRE-TEST |
検証用アラートだけを拾う。部分一致なので角かっこは付けない方が確実 |
| タイトルが次の値を含まない | 空欄 | 除外キーワードの欄。今回は不要 |
| 応答サブエージェント | メタ エージェント（既定） | |
| エージェント自律性レベル | レビュー | 既定は自律（Autonomous）。初回は Review で検証 |
| アラートの再調査のクールダウン | 有効（既定 3 時間） | 同じアラートの再発火を 1 つのスレッドにまとめる |
- 「次へ」で過去のアラートのプレビューを確認し、「作成」を選びます。まだアラートが発火していなければ一覧は空で正常です
一覧に状態「オン」、自律性レベル「レビュー」でプランが表示されれば準備完了です。
わざとバグをコミットして障害を起こす
ここからが本番です。フォークしたリポジトリの Program.cs に、環境変数の判定を反転させるバグを含むコミットを main ブランチに直接 push します。
- bool injectError = Environment.GetEnvironmentVariable("INJECT_ERROR") == "1";
+ bool injectError = Environment.GetEnvironmentVariable("INJECT_ERROR") != "1";
この変更により、INJECT_ERROR を設定していない本番環境でエラー注入が有効になり、6 回目以降のクリックで例外が発生して HTTP 500 が返るようになります。「設定を見直したつもりが条件を逆にしてしまった」という、実際にも起こりがちな障害の再現です。今回は GitHub の Web エディタで直接編集し、「意図的にバグを混入」というコミットメッセージで main に push しました。
push すると GitHub Actions が走り、数分でデプロイが完了します。デプロイ後にアプリの URL を開き、ボタンを 6 回以上押します。HTTP 500 のエラーページになったら、F5 で何度かリロードして 5xx を積み上げます。
しきい値を超えると数分以内にアラートが「発生」状態になります。Web アプリの「警告」画面で確認できます。私の環境では 01:41 に 5xx を 5 件発生させ、01:43:29 にアラートが発生しました。
障害検知から調査まで
SRE Agent ポータルの「インシデント」を開くと、インシデントのスレッドが自動で作成されていました。アラートの発生が 01:43:29、Azure Monitor 側のアラートが「確認済み」に変わったのが 01:44:40 なので、発生から約 70 秒でエージェントが拾ったことになります。
アラート側のステータスの変化は、エージェントがアラートを取り込んだ合図です。
スレッドを開くと、冒頭にアラートの基本情報（インシデント ID、状態、監視対象のリソース、サブスクリプション、リソース グループ）が表示され、その下にエージェントの調査が時系列で流れていきます。
最終的な調査結果のまとめは次のとおりです。ステータスは「解決済み」で、実施した対応としてアプリの状態確認、INJECT_ERROR が未設定であることの確認、01:43 以降に 5xx が 0 件であることの確認、アプリの再起動が挙げられていました。
根本原因の指摘は「Program.cs のエラーインジェクション機能が例外を投げている」という内容で、行番号まで示されました。一方で、直近のコミットで比較条件が != に反転したことには言及がなく、「INJECT_ERROR=1 が設定された状態でクリックされた」という前提で説明されていました。
メトリクスのパターンとコードの突き合わせは的確でしたが、コミット差分との照合までは行われなかった形です。コード アクセスの Deep Context（リポジトリの事前解析）が進む前の調査だった影響もありそうです。
修正 PR を作ってもらう
原因が特定できたら、同じインシデントのスレッドで修正を依頼します。
根本原因となったコミットの修正を OWNER/app-service-dotnet-agent-tutorial に反映してください。
main から fix/inject-error-flag ブランチを作成し、Program.cs の INJECT_ERROR の判定を修正したうえで、
main 向けの Pull Request を作成してください。PR の説明には、今回のインシデントの調査サマリーと根拠となったログを含めてください。
依頼から数分で、ブランチ作成、コード修正、PR 作成までが一度に完了しました。スレッドには実施内容が箇条書きで返ってきます。
実際に行われたのは次の 3 つです。
- main から
fix/inject-error-flagブランチを作成 Program.csを修正。INJECT_ERRORの環境変数チェックと未処理例外のthrowを削除し、クエリパラメータcrash/safeをincrement/resetにリネーム、エラーインジェクション関連の警告 UI も削除- インシデント調査サマリーとメトリクスのエビデンスを含む PR を作成
PR の説明文には、アラート名・重大度・発火時刻・リソース ID、根本原因、1 分粒度のメトリクス表、アクティビティ ログ、対応内容、変更内容が整理されていて、末尾には SRE Agent のスレッドへのリンクが付いていました。
障害対応の記録としてそのまま残せる内容です。
差分は 110 行追加、123 行削除でした。私が依頼したのは「INJECT_ERROR の判定を修正」でしたが、エージェントが選んだ修正は比較条件を == "1" に戻すことではなく、エラーインジェクション機能そのものを取り除く方針でした。
本番環境で意図しない 500 を出さないという安全性を優先した判断と言えます。ただし、デモ用の機能も一緒に消えるため、PR の内容は人がレビューしてから取り込む、という前提で運用することをお勧めします。
今回は GitHub MCP コネクタ経由だったため、ブランチ作成からコード修正、PR 作成まで一度の依頼で完了しました。
環境によってブランチ作成まで行えない場合は、修正案を含む GitHub Issue を作ってもらい、自分でブランチを用意してから PR 作成だけを依頼する 2 段階に分ける方法があります。
まとめ
Azure SRE Agent を使って、Azure Monitor のアラート検知から原因調査、GitHub への修正 PR 作成までを試してみました。
セットアップは専用ポータルで完結します。コード・ログ・Azure リソース・インシデントプラットフォームを接続して、レスポンスプランを決めるだけで動いてくれます。
調査は人間の SRE に近い流れで進んでいきました。Code Access を接続しておくと、例外の発生箇所を行番号まで示してくれます。調査結果をそのまま修正 PR の説明文にできるのも、障害対応の記録として嬉しいですね。
SRE Agent は、Azure Monitor・Teams・Azure DevOps / GitHub との統合が中心にある点が特徴だなと思いました。
それから、権限レベルが「閲覧者」だとチャット中に許可を求められます。自動で進めて欲しいなら「特権」でも良いかもしれません。ここはエージェントに何をさせるか、よく検討した上で決めると良いですね。
この記事がどなたかの参考になれば幸いです。
