Azure SRE Agent の実力とコストを確かめてみた ― App Service / VM / ネットワークの障害を復旧させて実測

Last updated at 2026-07-31Posted at 2026-07-31

「復旧してください」と日本語で頼んだら、承認ゲートを挟んで設定を直し、HTTP 200 に戻ったことまで自分で確認して報告してきました。

はじめに

2026年3月に Azure SRE Agent が GA しました。名前は聞いていたものの「結局どこまで自律的に動くの？」がずっと気になっていたので、検証環境で障害を起こし、調査・原因分析・復旧・復旧確認までを通しで任せてみました。

この記事で扱うこと。

Azure SRE Agent で何ができるのか（GA 後の最新機能ベース）
利用開始までの手順（実機のウィザード画面つき）
つかってみた（3 種類の障害を起こして、調査 → 根本原因分析 → 復旧まで）
費用感（AAU という課金単位と、シナリオ別の実測値 ）
Azure の他の AI ツール（Azure Copilot / GitHub Copilot）との違い

想定読者は、Azure 上でアプリケーションを運用していて、インシデント対応の一次切り分けを自動化したいと考えている方です。

注意: 本記事は 2026年7月30日時点の実機検証と公開情報にもとづきます。Azure SRE Agent は GA 後も機能追加が続いているため、UI や価格は変わる可能性があります。最新は公式ドキュメントをご確認ください。

TL;DR（先に結論）

Azure SRE Agent は「聞くと答えるアシスタント」ではなく「実際に Azure を操作する運用エージェント」 。マネージド ID を使って az コマンドを自分で実行し、ログとメトリクスと Activity Log を突き合わせて根本原因を出してきます。
既定の「レビューモード」では、書き込み操作の前に必ず人間の承認ゲートが入ります 。操作の危険度に応じて Low / Medium / High risk のラベルが付き、押すまで実行されません。ただし 承認を待たずに実行する「自律モード」もあり、インシデント対応計画とスケジュールタスクは自律が既定 なので注意が必要です。
PaaS だけでなく、VM の OS 内部や NSG のルールまで切り分けられました 。VM ・ネットワークのケースでは、ネットワーク→VM→プロセスと人間と同じ順で外側から消し込んでいきました。
一発で直らなかったときに、自分の修正の失敗を検知して軌道修正しました （VM ケース）。ここが単発のコマンド生成 AI との一番の違いだと感じました。
ドキュメント上は「チャットは英語のみサポート」ですが、日本語で聞いたら最後まで日本語で返してきました （公式サポート外の挙動なので過信は禁物）。
費用は AAU（Azure Agent Units）建て。1 AAU = 0.10 USD 。エージェントを作った時点から削除するまで 常時 4 AAU/時（= 0.40 USD/時、月あたり約 292 USD） が固定でかかります。
実測した調査＋復旧のコストは、App Service 83 AAU / VM 12 AAU / ネットワーク 6 AAU 。同じ「調査＋復旧」でも 1 桁変わりました 。
止めるだけでは課金は止まりません。完全に止めるには Delete が必要 です。検証したら消しましょう。

1. Azure SRE Agent で何ができるのか

1-1. ひとことで言うと

Azure SRE Agent は、Azure 上のワークロードに対して インシデント対応・定型運用・調査助言 を自律的に行うマネージドなエージェントサービスです。Azure Monitor / Application Insights / Log Analytics などの可観測性データにアクセスし、必要に応じて Azure CLI や kubectl を自分で実行して状況を確認します。

公式ドキュメントに書かれている主要ユースケースは次の 3 つです。

ユースケース	内容
インシデント対応の自動化	アラートや PagerDuty / ServiceNow のインシデントを起点に自動起動し、切り分け・是正を実施
定型運用の自動化	スケジュール実行タスクとして、定期的なヘルスチェックやレポート生成を実施
調査と助言	チャットで「なぜ落ちたのか」を聞き、根拠つきの分析と改善提案を得る

そして最も重要な設計思想がこれです。

The agent proposes changes and your team approves. No change deploys without human sign-off.
（エージェントは変更を提案し、あなたのチームが承認する。人間の承認なしにいかなる変更もデプロイされない。）

つまり 「勝手に本番をいじる AI」ではなく「提案と実行準備までやって、最後の引き金は人間に引かせる AI」 です。後述しますが、この承認ゲートの体験がかなり良くできています。

出典: Azure SRE Agent の概要 (Microsoft Learn)

ただし「常に承認が入る」わけではない

このキャッチーな一文だけを読むと誤解しそうなので、先に補足します。Azure SRE Agent には 実行モード（run modes） が 2 つあります。

モード	何が起きるか	推奨される用途
レビュー（Review）	エージェントがアクションを提案し、人間が承認または拒否する	本番システム、重要なインフラ
自律（Autonomous）	エージェントが承認を待たず即座に実行し、事後に報告する	非本番環境、信頼できる定型タスク

注意が必要なのは 実行モードはエージェント単位ではなく、応答プラン（インシデント対応計画）とスケジュールタスクごとに設定する という点です。しかも この 2 つの既定値は「自律」 です（エージェント作成時のグローバル既定値はレビュー）。「自動でインシデント対応させる」ところまで進めるなら、ここを意識的に設定する必要があります。

本記事の検証はすべて チャットからの手動依頼（レビューモード相当） で行っています。以降に出てくる「必ず承認カードが出る」という記述は、この前提で読んでください。

なお、レビューモードで承認ボタンが出るのは Azure インフラ操作（Azure CLI / ARM の書き込み）に対してだけ です。メール送信、Teams への投稿、外部データソースへの照会などは承認なしで進みます。そこを統制したい場合は、前述の Agent hooks やツールアクセスポリシーを使います。

出典: Azure SRE エージェントでの実行モード (Microsoft Learn)

1-2. エージェントを拡張する 5 つの「拡張プリミティブ」

Learn の日本語版には、次のような表現が出てきます。

エージェントは、次の 5 つの 拡張プリミティブ を介して動作します。

ここでいう プリミティブ（primitive）とは「それ以上分解できない、組み合わせの土台になる最小単位の部品」 のことです。つまり Azure SRE Agent は「箱を開けたら完成品」ではなく、5 種類の部品を組み合わせて自分たちの運用に合わせて作り込む 設計になっています。「この障害のときはこの手順を踏んでほしい」「うちは Datadog も見ている」といった固有の事情を、コードを書かずに（あるいは少しだけ書いて）注入できる、ということです。ここが「単なるチャットボット」との一番の違いです。

拡張プリミティブ	何をするもの	使う場面の例
Skills（スキル）	自社固有の運用手順をエージェントに教え込む。Marketplace の Runbook や Azure CLI スクリプトを追加できる	「本番のロールバックはこの手順で」を覚えさせる
Subagents（サブエージェント）	専門特化した子エージェントに処理を委譲し、並列で調査させる。組み込みで Explore / Plan / CodeReview / Bash / Verification / GeneralPurpose の 6 種	調査とコードレビューを同時に走らせる
Python tools	Python コードを道具として持たせ、独自のロジックや API 連携を実行させる	社内 API からサービスのオーナー情報を引く
MCP servers	Model Context Protocol 経由で外部ツールに接続。Datadog / New Relic / Splunk / Elasticsearch / Dynatrace など 40 以上のコネクタが利用可能	監視基盤が Azure Monitor 以外でも参照させる
Agent hooks（フック）	エージェントのライフサイクルに介入する。確定的な CLI を実行する command hooks と、LLM で評価して構造化 JSON を返す prompt hooks の 2 種	調査開始前にポリシーチェック、解決後に外部承認フローをキック

そして、これら すべてのプリミティブは「許可ゲート（permission gate）」を通過します 。これは実行前の安全レイヤーで、提案されたツール呼び出しをすべて実行前に評価します。人間の承認を要求したり、ポリシールールを適用したり、禁止された操作をブロックしたりできます。何を実行しようとして、何が許可・拒否されたかの監査テレメトリは、自分で用意した Application Insights に出力されます。

この記事の実機検証は、これらの拡張を一切使わず 素の状態（組み込みの Azure 知識だけ） でどこまでやれるかを見ています。

補足として、Model Context Protocol（MCP） は「AI エージェントが外部のツールやデータソースに接続するための共通プロトコル」です。これに対応しているおかげで、監視基盤が Azure Monitor 以外（Datadog など）でも SRE Agent から参照できるようになっています。

1-3. 対応リソースと連携先

管理対象としてサポートされている主な Azure リソースは以下です。

コンピューティング: Virtual Machines / App Service / Container Apps / AKS / Functions
ストレージ: Blob Storage / ファイル共有 / マネージドディスク / ストレージアカウント
ネットワーク: 仮想ネットワーク / ロードバランサー / Application Gateway / ネットワークセキュリティグループ
データ: Azure SQL Database / Cosmos DB / PostgreSQL / MySQL / Redis
監視・管理: Azure Monitor / Log Analytics / Application Insights / Resource Manager

補足: Learn は「Redis」とだけ記載しています。なお Azure Cache for Redis は 2025年10月に全 SKU のリタイア（廃止）が発表 され、後継の Azure Managed Redis への移行が推奨されています（Enterprise / Enterprise Flash は 2027年3月31日、Basic / Standard / Premium は 2028年9月30日にサービス終了し、翻日以降に停止）。これから Redis を新規に使う場合は Azure Managed Redis を選ぶことになります。

出典: Azure Cache for Redis の新機能 (Microsoft Learn) / Azure Cache for Redis の提供終了に関する FAQ (Microsoft Learn)

連携先は次のとおりです。

分類	連携先
可観測性	Azure Monitor / Application Insights / Log Analytics / Grafana
インシデント管理	PagerDuty / ServiceNow / Azure Monitor アラート
ソース管理	GitHub / Azure DevOps
データ・拡張	Azure Data Explorer / MCP
通知	Slack / Microsoft Teams

出典: Azure SRE Agent の概要 (Microsoft Learn) / Generally Available: Azure SRE Agent with new capabilities (Azure Updates)

2. 利用開始までの手順

2-1. 入り口は Azure ポータルではなく専用ポータル

Azure SRE Agent の操作は https://sre.azure.com という専用ポータルから行います。Azure ポータル（portal.azure.com）の中ではなく、独立した SPA です。複数テナントに所属している場合は、右上のアバターメニュー > Directory からテナントを切り替えます。

2-2. リージョンを確認する

エージェントを作れるリージョンは限られています。2026年7月30日時点で、検証に使ったサブスクリプションの ARM とポータルの両方から選択可能だったのは以下の 10 リージョン でした。

swedencentral / uksouth / eastus2 / australiaeast / francecentral
canadacentral / italynorth / koreacentral / southeastasia / southafricanorth

確認は Azure CLI でもできます。

# Microsoft.App/agents がサポートするリージョンを確認する
az provider show -n Microsoft.App `
  --query "resourceTypes[?resourceType=='agents'].locations" -o json

注意: 日本リージョン（Japan East / Japan West）はまだ非対応 です。今回は Korea Central に作成しました。監視対象のリソース自体は別リージョンにあっても問題ありません（今回、エージェントは Korea Central、アプリは Japan West）。

なお上記はあくまで このサブスクリプションで選択できたリージョン です。公式のサポート対象は Learn の対応リージョン一覧が正で、執筆時点では 9 リージョンの記載でした（create-agent と FAQ では 3 リージョンと、ページ間に差異もあります）。実際に作れるかは上記 CLI で、サポート対象かどうかは公式一覧で、と使い分けるのが安全です。

出典: Azure SRE エージェントの対応リージョン (Microsoft Learn)

2-3. エージェントを作成する

Create agent ウィザードは Basics → Review → Deploy の 3 ステップ です。

Basics でモデルプロバイダーを選びます。Anthropic 側に「Preferred」の表示。

指定する項目は次のとおりです。

項目	内容
Subscription / Resource group	エージェントリソースを置く場所
Agent name	エージェント名
Region	上記 10 リージョンから選択
Model provider	Anthropic (3x) Preferred または Azure OpenAI (1x)
Application Insights	新規作成 or 既存を使用

Model provider の (3x) (1x) は、後述する AAU の消費レート の目安です。Anthropic（Claude）のほうがトークンあたりのコストは高いものの、既定の推奨になっています。

注意: Anthropic を選ぶと画面に「Anthropic processes data in the United States and is excluded from European Union Data Boundary (EUDB)...」という注意書きが出ます。Anthropic はデータを米国で処理し、EU データ境界（EUDB）の対象外 になるため、データ所在地に制約がある場合は Azure OpenAI を選びます。

作成すると、エージェント本体に加えて Application Insights / Log Analytics ワークスペース / マネージド ID が自動で作られます。

出典: モデルプロバイダーの選択 (Microsoft Learn)

2-4. 監視対象を教え込む（Setup）

デプロイが終わると Setup 画面が出ます。「More context. Better investigations.（コンテキストが多いほど調査精度が上がる）」という考え方で、以下 4 種類を追加していきます。

Azure resources に監視対象のリソースグループを 1 つ追加した状態。

カード	追加するもの
Code	GitHub / Azure DevOps のリポジトリ
Logs	Log Analytics などのログソース
Azure resources	監視対象のサブスクリプション / リソースグループ
Incidents	PagerDuty / ServiceNow などのインシデント管理

今回は最低限、Azure resources に監視対象のリソースグループを 1 つ 登録しました。このとき、エージェントのユーザー割り当てマネージド ID（UAMI）には対象リソースグループのスコープで読み取り系のロール（Reader / Log Analytics Reader / Monitoring Reader）が付与されます（Monitoring Contributor はエージェント作成時に付与済みでした）。

ただしこれは 調査のための権限 です。後述のように 「復旧」まで任せるには書き込み権限が別途必要 になるので、今回は同じスコープで次のロールを追加しています。

書き込み系ロールを付与する PowerShell（クリックで展開）

# 復旧まで任せるために、エージェントの UAMI へ書き込み系ロールを追加する
$uami  = "<UAMI の principalId>"
$scope = "/subscriptions/<sub>/resourceGroups/rg-sre-agent-demo"

# App Service 向け / 仮想マシン向け / ネットワーク向け
foreach ($role in @("Website Contributor", "Virtual Machine Contributor", "Network Contributor")) {
  az role assignment create --assignee-object-id $uami `
    --assignee-principal-type ServicePrincipal `
    --role $role --scope $scope -o none
}

補足: 書き込み権限を事前に与えない場合でも、エージェントは後述の OBO（On-Behalf-Of） でユーザーの資格情報を借りる承認を都度求めてきます。「どこまでエージェントに持たせ、どこからを都度承認にするか」は設計の見せどころです。

出典: Azure SRE Agent の作成 (Microsoft Learn)

3. つかってみた（3 種類の障害を起こして直させる）

PaaS だけで判断するのは早いと思ったので、レイヤーの違う 3 種類の障害 を用意して、それぞれ同じように「調査して、直して、直ったことを確認して」と日本語で丸投げしてみました。

ケース	レイヤー	起こした障害	症状
A	PaaS（App Service）	アプリ設定 `DATABASE_URL` を削除	HTTP 503
B	IaaS（仮想マシン）	`nginx.conf` に不正なディレクティブを追加	接続拒否（Connection refused）
C	ネットワーク（NSG）	優先度の高い Deny ルールを追加	接続タイムアウト

B と C は「同じ URL につながらない」という点では同じですが、接続拒否とタイムアウトという症状の違い があります。エージェントがそこを切り分けられるかが見どころです。

3-1. デモ構成

ケース A 用に、シンプルな Node.js（Express）のカタログ API を App Service（Linux, B1）にデプロイしました。環境変数 DATABASE_URL が未設定だと起動時に process.exit(1) するようにしてあります。

app/server.js の抜粋（クリックで展開）

// app/server.js（抜粋）
// DATABASE_URL が無ければ起動を中止する = よくある設定ミス障害の再現
if (!process.env.DATABASE_URL) {
  console.error('FATAL: Missing required environment variable DATABASE_URL. Catalog service cannot start.');
  process.exit(1);
}

ケース B / C 用には、nginx を入れた Ubuntu の仮想マシンを NSG つきで用意しました。

デモ VM と NSG を作成する PowerShell（クリックで展開）

# nginx 入りのデモ VM を作成（cloud-init で nginx をインストール）
az vm create -g rg-sre-agent-demo -n vm-sre-demo -l southeastasia `
  --image Ubuntu2204 --size Standard_B2s --admin-username azureuser `
  --generate-ssh-keys --public-ip-sku Standard `
  --nsg nsg-sre-demo --vnet-name vnet-sre-demo --subnet snet-web `
  --custom-data "@scripts/cloud-init-nginx.yaml" -o none

# NSG でインターネットからの HTTP(80) を許可
az network nsg rule create -g rg-sre-agent-demo --nsg-name nsg-sre-demo `
  -n allow-http --priority 100 --access Allow --protocol Tcp --direction Inbound `
  --source-address-prefixes Internet --destination-port-ranges 80 -o none

補足: 検証したサブスクリプションでは Japan East / Japan West の VM SKU が容量制限（SkuNotAvailable）で確保できず、Southeast Asia に作成しました。監視対象リソースはエージェントと別リージョンでも問題なく扱えます （エージェントは Korea Central）。

権限は 2-4 のとおり、監視対象リソースグループのスコープで読み取り系ロールに加えて Website Contributor / Virtual Machine Contributor / Network Contributor を付与済みです。

3-2. ケース A: App Service（PaaS）— アプリ設定の欠落

3-2-1. 障害を注入する

アプリ設定から DATABASE_URL を削除します。実運用でいえば「IaC の完全置換でうっかり設定を消してしまった」に相当するシナリオです。

# アプリ設定から DATABASE_URL を削除して障害を起こす
az webapp config appsettings delete -g rg-sre-agent-demo `
  -n app-sre-demo-0730 --setting-names DATABASE_URL -o none

コンテナが再起動して起動に失敗し、見事に 503 になりました。

Application Error ではなく、コンテナ起動失敗による 503。

3-2-2. 日本語で調査を依頼する

SRE Agent のチャットに、日本語で投げます。

Web アプリ app-sre-demo-0730 が 503 を返しています。
原因を調査して、根本原因と修正案を日本語で教えてください。

ドキュメントには「English is the only supported language in the chat interface.（チャット UI でサポートされる言語は英語のみ）」と明記されているのですが、実際には最後まで完全な日本語で応答してきました。公式サポート外の挙動なので本番運用で頼るのは避けるべきですが、体験としてはかなり快適でした。

エージェントは次々に Azure CLI を自分で実行していきます。

az webapp show
az webapp log tail
az webapp config appsettings list
az webapp config show
az webapp log show

各コマンドには Safe / Medium risk のリスクラベル が付き、実行したのがエージェントであることを示す SRE Agent バッジが表示されます。

3-2-3. 権限が足りないと「借りに来る」（OBO）

途中で、マネージド ID の権限不足によりコマンドが失敗しました。ここでエージェントは黙って諦めず、ユーザーの資格情報を借りる（On-Behalf-Of）ための承認カード を出してきます。

「マネージド ID で実行したら認可エラーになった。許可すればあなたの資格情報（OBO）で再実行する」という提案。スコープも明示される。

The agent tried to execute this command using its managed identity but received an authorization error. If you grant permissions, the command will be re-executed using your credentials (OBO) with scope: https://management.azure.com/.default, https://management.core.windows.net/.default

Grant permissions を押すと、そのコマンドだけがユーザー権限で再実行されます。何を、どのスコープで、なぜ昇格したいのかが毎回明示される ので、いわゆる「AI に強い権限を渡しっぱなし」にせずに済むのは良い設計だと感じました。

3-2-4. 根本原因分析（RCA）

しばらく待つと、根拠つきの分析が返ってきました。まず、途中経過でこんな指摘が出ます。

重要な発見です。06:07:55 UTC に <ユーザー> が Web サイト設定を更新 しており、その約3分後の 06:11 に可用性が 0% に急落しています。設定変更の内容を詳しく調査します。

Activity Log の変更イベントと可用性メトリクスの急落を時系列で相関させています 。人間の一次切り分けと同じ動きです。

最終的な RCA がこちら。

エビデンス・修正案・再発防止策がセットで出てくる。

根拠となるエビデンス として挙げられたのは次の 4 点でした。

#	エビデンス	内容
1	Docker ログ	`FATAL: Missing required environment variable DATABASE_URL. Catalog service cannot start.`
2	現在のアプリ設定	`SCM_DO_BUILD_DURING_DEPLOYMENT` など 4 つのみで `DATABASE_URL` が存在しない
3	メトリクス	06:11 以降 CPU=0%、メモリ=0 バイト（プロセス完全停止）
4	Activity Log	06:07:55 に appsettings の write 操作 → 直後にコンテナ再起動 → 起動失敗

さらに、可用性の推移グラフを自分で生成して添付 してきました。

チャットの中でグラフまで描いてくれる。

再発防止策 も 4 点提示されました。単なる復旧手順ではなく、構成の弱点まで踏み込んでいます。

アプリ設定の更新時に既存設定を上書きしない（ARM テンプレートや Terraform の完全置換に注意）
スロット設定（Slot Setting）の活用で重要な環境変数を保護
healthCheckPath の設定（現在未設定である ことを検出）
AlwaysOn の有効化（現在 false である ことを検出）

3 と 4 は、こちらが聞いていないのに現在の構成を読んで指摘してきた点です。

補足: 2 はエージェントの提案をそのまま載せていますが、スロット設定は「スワップ時にその設定をスロットに固定する」機能であって、設定の誤削除そのものを防ぐものではありません 。今回のような「設定が消える」事故への直接的な対策は、IaC やデプロイ前の検証、Azure Policy 側で担保する必要があります。エージェントの提案も鵜呑みにせず裏を取る という、良いサンプルになりました。

出典: ステージング環境の設定 - アプリ設定をスワップ対象外にする (Microsoft Learn)

3-2-5. 復旧まで任せる（承認ゲート）

ここからが本番です。復旧そのものを依頼します。

この障害を復旧してください。DATABASE_URL に <接続文字列> を設定し、
復旧後に HTTP 応答が 200 に戻ったことを確認してください。

書き込み操作の直前に、承認カード が出ました。

実行しようとしているコマンド全文とリスクレベルを見せてから承認を求める。

カードには次が含まれます。

操作名（Setting resource configuration）とリスクラベル（Medium risk）
実行予定の Azure CLI コマンドの全文
Approve action / Cancel のボタン
「Agent permissions will be used to complete this action.（この操作にはエージェントの権限が使われます）」という注記

Approve action を押すと実行され、そのあとの動きが良くできています。

設定 → 待機 → curl で検証 → 結果報告、という一連の流れを自分で完結させる。

Configuring database URL — アプリ設定を投入
Verifying app HTTP response status — sleep 30 && curl -s -o /dev/null -w "HT…" を実行（exit 0）
「HTTP 200 が返りました。復旧を確認できました。」

最終サマリでは、HTTP 応答が 200 OK であること、可用性が 07:22 UTC 以降 100% で安定していること、実施した変更内容がまとめられていました。「直した」で終わらず「直ったことを自分で検証する」 のがポイントです。

念のため手元からも確認しました。

手元からの復旧確認 PowerShell（クリックで展開）

# 復旧確認: 6 回連続でステータスコードを確認する
1..6 | ForEach-Object {
  (Invoke-WebRequest -Uri "https://app-sre-demo-0730.azurewebsites.net/" `
    -UseBasicParsing).StatusCode
}
# => 200 200 200 200 200 200

なお、チャット画面の下部には常に次の免責が表示されています。

AI-generated content might be incorrect, so review carefully before use. Do not include personal or confidential information in the chat.
（AI 生成コンテンツは誤っている可能性があるため、使用前に注意深く確認してください。個人情報や機密情報をチャットに含めないでください。）

3-3. ケース B: 仮想マシン（IaaS）— nginx の設定ミス

PaaS はエージェントにとって「Azure の API を叩けば状態がわかる」世界です。では OS の中で起きた障害 はどうでしょうか。

3-3-1. 障害を注入する

nginx.conf の末尾に、タイポを含む不正なディレクティブを追記して nginx を再起動します。「設定変更をコピペしたら綴りを間違えていた」という、ありがちなミスの再現です。

nginx に障害を注入する PowerShell（クリックで展開）

# nginx.conf に worker_prcesses（o が抜けたタイポ）を追記して再起動を失敗させる
$script = "echo 'worker_prcesses auto;' >> /etc/nginx/nginx.conf; systemctl restart nginx"
az vm run-command invoke -g rg-sre-agent-demo -n vm-sre-demo `
  --command-id RunShellScript --scripts $script -o none

nginx が起動できなくなり、HTTP は 接続拒否（curl の exit code 7） になりました。VM 自体は稼働しています。

3-3-2. 調査から復旧まで任せる

vm-sre-demo (パブリックIP 4.193.200.75) の Web サイトに HTTP でアクセスできません。
原因を調査し、復旧まで実施してください。復旧後は HTTP 200 が返ることを確認してください。

エージェントはいきなり VM の中に入らず、外側のレイヤーから順に潰していきました 。

az vm show — VM は running 状態
az network nsg rule list — ポート 80 は Allow 済み
az network nic show / az network public-ip show — パブリック IP は正しく関連付け済み
→「ネットワーク構成は問題なさそうです。VM 内部の Web サーバーの状態を確認します。」
az vm run-command invoke で VM 内部の systemctl status nginx を実行

そして原因を特定します。

タイポの特定 → 修正 → 自分の修正が生んだ新しいエラーの検知、という自己修復のループ。

原因が特定できました。Nginx の設定ファイルに タイポ があります：
/etc/nginx/nginx.conf:84 で worker_prcesses （o が抜けている）→ 正しくは worker_processes

ここからが面白いところです。 エージェントは sed でタイポを修正しましたが、修正後の worker_processes auto; が 2 行目の既存の記述と重複してしまい、nginx はやはり起動しませんでした。エージェント自身の修正が新しいエラーを生んだわけです。

しかしエージェントはそれを自分で検知しました。

タイポは修正されましたが、worker_processes ディレクティブが重複しています。設定ファイルの内容を確認して重複行を削除する必要があります。

そして cat -n /etc/nginx/nginx.conf でファイル構造を読み直し、

設定ファイルの構造がわかりました。行2に worker_processes auto; が既にあり、行84にも（元々タイポだった）重複行があります。行84の重複を削除して Nginx を再起動します。

sed -i '84d' で重複行を削除 → nginx -t で構文チェック → systemctl start nginx → HTTP 200 確認、と自力で収束させました。一発で直らなかったときに、自分の変更の結果を見て軌道修正できる のは、単発のコマンド生成 AI との明確な差です。

最後は「調査の流れ」「実施した修正」「復旧確認」の形でまとめてくれる。

もう 1 つ気づいた点として、az vm run-command invoke は 中身がただの cat であっても Medium risk 扱い になります。エージェント自身も次のように説明していました。

run-command invoke は write 操作として扱われるため、設定ファイルの確認もそちらで実行します。

VM の中でコマンドを実行できる時点で何でもできてしまうので、妥当な扱いだと思います。

3-4. ケース C: ネットワーク（NSG）— 通信の遮断

最後に、アプリも VM も正常なのにつながらない というパターンです。切り分けが一番厄介な種類の障害です。

3-4-1. 障害を注入する

NSG に、既存の Allow ルールより優先度の高い Deny ルールを追加します。

NSG に Deny ルールを追加する PowerShell（クリックで展開）

# 既存の許可ルールを優先度 300 に下げ、優先度 100 で Deny ルールを追加する
az network nsg rule update -g rg-sre-agent-demo --nsg-name nsg-sre-demo `
  -n allow-http --priority 300 -o none

az network nsg rule create -g rg-sre-agent-demo --nsg-name nsg-sre-demo `
  -n deny-inbound-web --priority 100 --access Deny --protocol Tcp --direction Inbound `
  --source-address-prefixes Internet --destination-port-ranges 80 443 -o none

今度はパケットが破棄されるため、接続拒否ではなくタイムアウト（curl の exit code 28） になります。

3-4-2. 調査から復旧まで任せる

ケース B との違いが伝わるよう、症状の差だけを添えて依頼しました。

vm-sre-demo (4.193.200.75) の Web サイトに再びアクセスできなくなりました。
数分前までは HTTP 200 が返っていました。今回は接続がタイムアウトします。
原因を調査し、復旧まで実施してください。復旧後は HTTP 200 が返ることを確認してください。

NSG のルールを列挙し、優先度の評価順まで踏まえて原因を確定させている。

原因を特定しました。NSG ルールを見ると:
deny-inbound-web （優先度 100）- Internet からの TCP を Deny
allow-http （優先度 300）- Internet からのポート 80 を Allow

優先度 100 の Deny ルールが先に評価され、ポート 80 の Allow ルール（優先度 300）に到達する前にトラフィックがブロックされています。

NSG は優先度の小さいルールから評価され、最初にマッチした時点で確定する という仕様を踏まえた説明です。単に「Deny ルールがある」ではなく「なぜ Allow があるのに効かないのか」まで説明しているのがポイントでした。

そしてここで初めて High risk のラベルが出ました。

ケース A（アプリ設定の変更）… Medium risk
ケース B（VM 内でのコマンド実行）… Low risk / Medium risk
ケース C（NSG ルールの削除）… High risk

セキュリティ境界を変更する操作は、より強い警告とともに提示されるようです。

復旧後は表形式でまとめ、さらに「誰がいつこのルールを追加したかは Activity Log で調査できる」と次の一手まで提示。

締めくくりのコメントも実務的でした。

VM 自体は正常に稼働しており、問題は NSG ルールのみでした。このルールがいつ・誰によって追加されたか確認が必要であれば、Activity Log を調査できます。

3-5. 3 ケースを並べて比べる

	ケース A: App Service	ケース B: 仮想マシン	ケース C: ネットワーク
症状	HTTP 503	接続拒否	接続タイムアウト
主に使ったツール	`az webapp log` / メトリクス / Activity Log	`az vm run-command`（OS 内部）	`az network nsg rule`
根本原因	アプリ設定 `DATABASE_URL` の欠落	`nginx.conf` のタイポ	Deny ルールの優先度
リスクラベル	Medium risk	Low / Medium risk	High risk
承認回数	1 回	3 回（自己修復のやり直し含む）	1 回
特徴的だった動き	Activity Log と可用性メトリクスの相関	自分の修正の失敗を検知して軌道修正	優先度の評価順まで説明

3 ケースに共通していたのは次の点です。

必ず根拠（ログ・メトリクス・構成・Activity Log）を示してから結論を述べる
書き込み操作の前には承認カードが出る （レビューモードの場合）
直したあとに必ず自分で curl して確認する

一方、外側のレイヤーから順に消し込む （ネットワーク → VM → プロセス）という進め方が明確に見えたのは、ケース B と C の VM 系だけでした。ケース A はネットワークが疑わしくない状況だったこともあり、最初からログ・アプリ設定・メトリクス・Activity Log を突き合わせにいっています。症状に応じて調査の入り口を変えている ようです。

3-6. 調査の中身をあとから追う（トレース / セッション分析情報）

チャットの見た目だけだと「AI がなんとなくやってくれた」で終わってしまいますが、SRE Agent には あとから中身を検証するための仕組み が用意されています。運用に載せるうえではむしろこちらのほうが重要かもしれません。

3-6-1. トレースの表示

スレッド右上の ［トレースの表示］ から、そのスレッドで何が起きたかを実行単位で追えます。

ユーザーの発話とエージェントの実行が交互に並び、それぞれの所要時間が出る。右ペインは選択したノードの入出力。

meta_agent の実行が 91 秒 / 28 秒 / 54 秒 / 481 秒 / 27 秒 / 116 秒 と並んでいます
ノードを選ぶと右側に 入力（ユーザープロンプト）と出力 が表示されます
各ノードを展開すれば、その中で呼ばれたツールまで辿れます

「なぜこの結論になったのか」を後から説明する必要があるとき、ここが根拠になります。なお この所要時間は課金額とは無関係 です。AAU はあくまでトークン量で決まるので、481 秒かかった実行が一番高いとは限りません。

3-6-2. セッション分析情報（Session Insights）

さらに 監視 > セッション分析情報 には、エージェントが自分の調査セッションを振り返って生成したインサイト が溜まっていきます。

今回の 3 ケースがそれぞれインサイトとして自動生成されていた。

今回の検証では、こちらが何もしていないのに 3 件が生成されていました。

インサイト	対応するケース
VM Website Timeout Resolved by Removing Blocking NSG Rule	ケース C（ネットワーク）
vm-sre-demo HTTP Access Restored by Fixing Nginx Configuration	ケース B（仮想マシン）
Web App 503 Investigation and Recovery by Restoring DATABASE_URL	ケース A（App Service）

中身は TIMELINE と EVALUATION に分かれていて、TIMELINE は調査の各ステップが「何をして、どうなったか」の形で要約されています。ケース C だとこうです。

Located VM and checked instance view — vm-sre-demo が southeastasia で VM running、プロビジョニング状態 Succeeded であることを確認

Mapped NIC, public IP, subnet, and NSG — NIC・パブリック IP・サブネット・アタッチされた NSG を特定

Listed NSG rules and spotted priority conflict — 優先度 300 の allow-http と、先に評価される優先度 100 の deny-inbound-web を発見

Confirmed deny rule blocked web ports — Internet からのポート 80 / 443 を拒否していることを確認

Deleted blocking NSG rule — az network nsg rule delete でブロックしているルールを削除

Verified NSG state and HTTP recovery — ルール消失を再確認し、curl で HTTP Status: 200 を 0.144869 秒で取得

インシデントの事後報告（ポストモーテム）の下書きがそのまま出てくる のはかなり実用的でした。人間がやると一番おっくうな作業です。

補足: この 2 画面を撮った時点では ポータル UI が日本語化 されていました（前日の検証時は英語表示）。チャットの応答言語は公式には英語のみサポートですが、UI 自体のローカライズは進んでいるようです。

4. 費用感

ここが一番気になるところだと思います。

4-1. 課金単位は AAU

Azure SRE Agent の課金単位は AAU（Azure Agent Units） です。

1 AAU = 0.10 USD

課金は 2 種類の流れ（flow）に分かれます。

課金の種類	内容	レート
Always-on flow（固定）	エージェントが存在するだけでかかる基本料金	4 AAU / エージェント・時間 = 0.40 USD/時
Active flow（変動）	実際にエージェントが動いたときのトークン消費	モデルとトークン種別ごとのレート（下表）

Always-on は エージェントを作成した時点から削除するまで課金が続きます 。月 730 時間として単純計算すると 0.40 USD × 730 時間 ≒ 約 292 USD/月・エージェント です。

4-2. Active flow のレート

トークンは input / output / cache read / cache write の 4 種類に分けて課金されます（100万トークンあたりの AAU）。

モデル	Input	Output	Cache read	Cache write
Claude Opus 4.6	100	500	10	125
GPT 5.3 Codex / GPT 5.2	35	280	3.5	0

作成時の Model provider にあった (3x) (1x) は、おおむねこのレート差を指しています。

公式に載っているタスク別の目安（Claude Opus 4.6 の場合）は以下です。

タスク	目安 AAU	概算
ちょっとした質問	約 3.8 AAU	約 0.38 USD
インシデント調査	約 35.3 AAU	約 3.5 USD
完全な是正（調査＋復旧）	約 86.5 AAU	約 8.7 USD

4-3. 3 ケースの消費量を実測してみた

Azure SRE Agent の消費量は Settings > Agent Consumption で確認できます。しかも スレッド（チャット）単位で AAU が集計される ので、シナリオごとのコストをそのまま比較できました。

スレッド単位で AAU が出るので、シナリオごとの費用がそのまま読める。

スレッド（シナリオ）	実測 AAU	概算
ケース A: App Service 503 の調査＋復旧	83	約 8.3 USD
ケース B: 仮想マシン（nginx）の調査＋復旧	12	約 1.2 USD
ケース C: ネットワーク（NSG）の調査＋復旧	6	約 0.6 USD
（参考）初回オンボーディングの会話	19	約 1.9 USD
合計	120	約 12 USD

ケース A の 83 AAU は、公式が示す「完全な是正 ≒ 86.5 AAU」という目安とほぼ一致しました。

一方で 同じ「調査＋復旧」でもケース B は 12、ケース C は 6 と、1 桁小さい という結果になりました。ケース B は承認を 3 回もはさんでいるのに、です。

この差の主因は エージェントがコンテキストに読み込んだデータ量 だと考えられます。

ケース A … az webapp log tail で Docker のログ全文 を読み込み、メトリクスと Activity Log も突き合わせ、さらに可用性グラフまで生成
ケース B … systemctl status や nginx.conf の中身という 数十行のテキスト だけ
ケース C … az network nsg rule list の JSON 数十行 だけ

AAU は 4 種類のトークン（入力 / 出力 / キャッシュ読み取り / キャッシュ書き込み）の合計で決まるので、「大量のログを読ませる調査」が高く、「構成情報をピンポイントで見る調査」は安い 傾向が出るのは自然です。公式のコスト最適化ガイドが「十分なコンテキストを与えて余計な探索を減らせ」と書いているのも、同じ構造を指しています。

注意: ただしこれは 条件を揃えていない 3 件の比較（n=1 ずつ） です。AAU は読み込むデータ量だけでなく、出力トークン、推論ステップ数、ツール呼び出し回数、プロンプトキャッシュの効き方、選んだモデルによっても変わります。「ログ量が支配的だった」と断定できるものではなく、傾向として観測できた という程度に受け取ってください。

裏を返すと、アラートの内容や調査範囲を絞って渡せるほど安くなる 可能性が高いので、response plans やカスタム指示でスコープを狭める工夫が効いてきそうです。

ただし、繰り返しになりますが Always-on の 0.40 USD/時が別途かかる ので、「たまにしか使わないのに立てっぱなし」は避けたいところです。今回の検証全体（3 シナリオ）でも Active flow は約 12 USD ですが、エージェントを 1 日立てておくだけで約 9.6 USD かかる計算になります。

4-4. 上限設定と、止め方の注意

使いすぎ防止のため、消費上限を設定できます。

上限はこのダイアログから変更する。背景には実測値の 120/10,000 AAU が見えている。

Settings > Agent consumption > Change AAU allocation
設定できる範囲は 最小 500 AAU 〜最大 1,000,000 AAU
対象は Active flow のみ （Always-on は上限の対象外）
上限に達すると 翌月まで チャットとアクションが実行できなくなる（引き上げは即時反映、引き下げは翌月から反映）

そして最重要の注意点。

Stop（停止）しても Always-on の課金は止まりません。課金を完全に止める唯一の方法は Delete（削除）です。

検証で作ったエージェントは、終わったら必ず削除しましょう。ちなみに「エージェントが自分の応答を待っている間は課金されるのか？」という FAQ には No と明記されています。

公式が挙げているコスト最適化のポイントは以下です。

十分なコンテキストを与える（余計な探索を減らす）
response plans でインシデントの対象を絞り込む
scheduled tasks でまとめて実行する
自動化する前にチャットで挙動を検証する
使っていないエージェントは Stop、不要なら Delete

出典: Azure SRE Agent の価格と課金 (Microsoft Learn) / Azure SRE Agent の価格 (azure.microsoft.com)

5. Azure の他の AI ツールとの違い

「Azure Copilot があるのに、なぜ別サービス？」という疑問への回答です。

補足: かつて Microsoft Copilot in Azure と呼ばれていたものは、現在 Learn では Azure Copilot に名称が統一されています。本記事も現行の名称に合わせます。

5-1. 三者比較

観点	Azure SRE Agent	Azure Copilot	GitHub Copilot
主戦場	本番運用・インシデント対応	Azure ポータルでの設計・運用・トラブルシュート	コードの作成・レビュー
入り口	sre.azure.com（専用ポータル）	Azure ポータル / Azure モバイルアプリ	IDE / GitHub
起動のきっかけ	アラート / インシデント / スケジュールで自動起動	人間がポータルで質問したとき	開発者がエディタで書いているとき
Azure への操作	マネージド ID / OBO で実際に CLI を実行	クエリ生成やタスク実行、ユーザーに代わっての操作も可能（確認を伴う）	基本的になし
変更の安全装置	リスクラベル付き承認ゲート + 許可ゲート（実行モードで切替可）	実行前の確認＋ポータルの通常の権限モデル	PR レビュー
コンテキストの保持	スレッドをまたいで環境の知識を蓄積	会話単位が中心	リポジトリ単位
拡張性	Skills / Subagents / Python tools / MCP / Hooks	組み込み機能中心	Extensions / MCP
課金	AAU（常時課金 + 従量）	追加料金なし	ユーザー単位のサブスクリプション

5-2. ざっくり言うと

GitHub Copilot は「書くのを助ける」。開発フェーズのツールです。
Azure Copilot は「聞けば答える」。Azure ポータル内のアシスタントで、Resource Graph クエリの生成、Service Health の要約、コスト分析、ネットワークトポロジの可視化、CLI/スクリプト生成、Advisor の推奨提示などを対話でこなします。タスクの実行やユーザーに代わった操作も可能 ですが、あくまで 人間が能動的に聞きに行く のが起点です（追加料金なしで利用でき、日本語を含む 19 言語に対応）。なお Azure Copilot のエージェント機能は現在プレビュー で、こちらもエージェント化が進んでいます。
Azure SRE Agent は「勝手に調べて、直す提案を持ってくる」。人間が見ていない時間に動く ことを前提にした運用エージェントです。

つまり「操作できるかどうか」では差がつきにくくなっており、違いは「常時稼働か」「アラート起点で自動起動するか」「スレッドをまたいで知見が蓄積されるか」「応答プランやスケジュールで運用を回せるか」にある、と考えるのが実態に近いです。

公式 FAQ の「他の AI アシスタントとどう違うか」でも、次の 5 点が差別化要素として挙げられています。

監視・可観測性ツールとの深い統合
SRE の方法論そのものの理解
権限を与えられた場合に実際にアクションを実行できること
調査セッションをまたいだコンテキストの保持
Azure サービスと障害パターンに関する専門知識

今回の検証で言えば、「Activity Log の変更イベントと可用性メトリクスの急落を相関させる」「healthCheckPath や AlwaysOn の未設定を勝手に見つけて指摘する」あたりが、まさに 2 と 5 に該当する動きでした。

出典: Azure SRE Agent の FAQ (Microsoft Learn) / Azure Copilot とは (Microsoft Learn) / Azure Copilot の機能 (Microsoft Learn)

まとめ

Azure SRE Agent は 2026年3月に GA した、Azure 運用に特化した自律エージェント 。アラート起点で自動起動し、マネージド ID で実際に Azure を操作します。
既定の レビューモードでは、書き込み操作にリスクラベル付きの承認ゲート が入り、権限が足りなければ OBO の昇格承認 を求めてきます。NSG のルール削除のようなセキュリティ境界の変更には High risk が付きました。ただし インシデント対応計画とスケジュールタスクの既定は「自律モード」 なので、本番では意識的にレビューに寄せる必要があります。
実機検証では PaaS / IaaS / ネットワークの 3 レイヤーすべてで、調査から復旧・復旧確認まで自走 しました。特に VM ケースでは 自分の修正が生んだ新しいエラーを検知して軌道修正 したのが印象的でした。一方で、提案された再発防止策には 説明が正確でないものも含まれていました 。提案は必ず裏を取るべきです。
費用は 1 AAU = 0.10 USD 。常時 0.40 USD/時（約 292 USD/月）+ 従量 。実測では App Service 83 AAU / VM 12 AAU / ネットワーク 6 AAU と、同じ「調査＋復旧」でも 1 桁変わりました 。
Azure Copilot が「聞けば答える」、GitHub Copilot が「書くのを助ける」のに対し、SRE Agent は「見ていない間に調べて直す提案を持ってくる」 、という棲み分けです。
検証が終わったら Delete を忘れずに。Stop では課金は止まりません。

現状は日本リージョン非対応・チャットは公式には英語のみ、と制約もありますが、「一次切り分けを任せられる相手」としての完成度は想像以上でした。夜中のアラートで叩き起こされる前に、エージェントに一次調査させておく、という運用は現実的に見えます。

参考リンク

本記事は GitHub Copilot および Microsoft Foundry を活用して作成されています。内容の正確性については各公式ドキュメントをご確認ください。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up