Azure SRE Agent
MS Build 2025 で発表された Azure SRE Agent 、これまで waitlist に登録をして利用可能になるのを待つ必要がありましたが、 2025年10月に入り、誰でも試せるようになりました！
日々の運用を大きく楽にしてくれるサービスだと個人的に期待しているので、作成し、試してみたいと思います。
Azure SRE Agent を作成
作成自体は、公式ドキュメント に従って行うだけで、特段難しくはありません。
キャプチャ付きで載せておきます。
Azure Portal 上部の検索窓で "SRE" などと検索して、 Azure SRE Agent を開きます。
左上 [+Create] から作成開始です。
右側からタブが開いてくるので、SRE Agent をデプロイする サブスクリプション や リソースグループ を選択します。
SRE Agent のリソース名 や リージョン を選択します。2025年10月3日時点では、Sweden Central か East US 2 が選べます。ここでは、当初から利用可能であった Sweden Central を選択しました。
最下部 [+Choose resource group] をクリックして、 SRE Agent で確認したいリソースがあるリソースグループを選択します。 demo 用の VM をデプロイするつもりである demoRG を選択しています。
NEXT をクリックして、権限確認に進みます。
SRE Agent が対象リソースの確認したりできるよう、先ほど [+Choose resource group] で選んだリソースグループに対して、SRE Agent の Managed Identity へ権限を割り当てます。今回はより強力な Privileged を選択して、 Create しました。公式ドキュメント的にはこの辺に説明があります
デプロイが開始され、数分で完了しました。
作成されたリソースはこんな感じ。
SRE Agent のリソースに移動すると、早速もうチャットして状況を聞ける画面になっています。
SRE Agent を利用してみる - Virtual Machine の調査
現時点で SRE Agent が得意としているのは、 AppService や AKS などの PaaS リソースを対象にしたトラブルシューティングのようです。
公式ドキュメントでは、 AppService と Container Apps を対象にしたクイックスタートが用意されています。
また、satake-san の こちらの記事 で、実際に AppService のクイックスタートを試すハンズオンが紹介されています。
https://zenn.dev/microsoft/articles/azure_sre_agent_intro
一方、仮想マシンを対象に SRE Agent が 動作するかどうかは、公式ドキュメント上では明記がない感じです…
あまり得意ではないのかもしれませんが、あえて仮想マシンを対象に調査をしてみようと思います。
いいトラブルが浮かばなかったので、 SRE Agent 今回は CPU に高負荷を発生させてみて、 SRE Agent に調査してもらうことにしました。
SRE Agent で調査開始！
対象仮想マシンに CPU Stress Tool を導入して負荷をかけたのち、SRE Agent で調査を開始します。
異常はあるか？ → プラットフォーム観点では正常。nextstep : メトリック確認等を提案
VM が起動状態であるかや、パッチの状態まで見てくれたようです。
プラットフォーム的には問題ないよとの回答がきました。
また、より踏み込んで、 VM Insights や メトリック その他を見ますよとも提案してくれています。
メトリック調査を依頼 → CPU 使用率が高いことを発見、他メトリックは概ね正常と回答
なんとなく適当な理由を添えて、メトリックのチェックをお願いしてみます。
CPU 使用率が高いことがわかりました。
サクッとグラフも作ってくれました。すごい。
また、メモリやネットワークの状況も確認してくれています。
もしディスクに I/O 負荷をかけていたとしたら、そこも見て、気が付いてくれたのかとかちょっと気になりますね。
CPU 使用率の高いプロセス特定を指示 → コマンド実行を試みるも、危険と評価されて実行できず
CPU 使用率が高いプロセスを特定することを提案してくれているので、 SRE Agent さん自身に実行をお願いをしてみます。
run-command による操作を実施したいが良いか、確認してくれました。
複数の観点で、どのくらいリスクがありそうか、示してくれてもいます。
コマンドの実行を承認してみます。
が、どうやらこれは危険な操作だと判断されたようで、実行を拒否されてしまいました。
エラーメッセージを見たところでは、バックスラッシュ（\）を含むコマンド実行だったため、ブロックされたようです。
([Validation Failed]: Command contains potentially dangerous character(s): )
代替案（VM 上でコマンド代理実行し、結果をチャット）で調査続行！
SRE Agent の代わりに、SRE Agent が実行しようとしていたコマンドを VM にログインして打ち、その結果を共有してあげました。
実行結果を共有すると、ちゃんと CPUSTRES64 が CPU を食っていることを特定してくれました。
また、単にアプリを止めるという以外に、対策案をいくつか提案してくれています。
緩和策を実施してもらう → CPU 負荷を下げることに成功
SRE Agent の提案の中に、CPUSTRES64 が使えるコアを制限（CPUアフィニティを設定）するという緩和策がありましたので、この実行をお願いしてみます。
SRE Agent が VM 内のプロセスを止める操作は、再び危険な操作だと判断されて実施できなそうな感じでした。
成功したようです。
SRE Agent が動作し始めると、CPU 負荷が 100% 張り付き状態から 80% 程度に下がりました。
おお～、ちゃんと効果出ていますね…！
まとめ : 仮想マシン相手でも行けそう！
入力したプロンプトと SRE Agent からの回答概要
SRE Agent を試してみました。
まとめると大体こんな感じのやりとりでした。
| step | プロンプト | SRE Agent 回答 の 概要 |
|---|---|---|
| 1 | demovm に異常はありますか？ | プラットフォーム観点では異常は見当たりません。必要であれば、より詳細な来歴や性能の確認（VM Insights/メトリック可視化、RDP/SSH 接続性、Run Command によるサービス稼働チェック）も実施できます。 |
| 2 | demovm からのレスポンスが悪いとのユーザークレームを受けています。メトリックなど調査してもらえますか？ | 過去24時間のメトリックを確認したところ、メモリやネットワーク負荷は問題ありませんが、 CPU 使用率が高止まりしています。推奨アクションとして、プロセス別CPUを取得して原因プロセスを特定（Windowsなら Get-Process / PerfCounter、Run Commandでの収集）するなどを提示します。 |
| 3 | CPU 使用率の高いプロセスの調査をお願いします。 | 実行するコマンド ( az vm run-command invoke ～ ) を提示し、実行した場合の影響とリスクを評価しました。実行許可を求めます。 |
| 4 | 実行を許可します | Run Command の実行を試みるも、潜在的に危険と評価されて実行できませんでした。 |
| 5 | 代わりに Get-Process コマンドを実行し、結果を共有します。 | 解析のため、Get-Process の実行結果（上位15件の Name/Id/CPU/PM/WS）をそのまま貼り付けていただけますか？ |
| 6 | Get-Process の結果を共有しました。 | CPUSTRES64 が CPU 使用率を高くしています。対策案として、CPUSTRES64 のプロセス停止、CPUSTRES64 の優先度変更、CPUSTRES64 の CPU アフィニティ設定（使用コア制限）などを提案します。 |
| 7 | CPUSTRES64 の CPU アフィニティ設定を実施してください。 | 実行しました。 |
| 8 | CPU 使用率は下がりましたか？ | CPU 直近の平均値は約 86.2% です。現状の抑制（優先度Down/1コア制限）は実施済みですが、負荷が継続しているため、即時の解決にはプロセス停止が最も確実です、と、さらなる対応を提案しました。 |
感想
AppService などの PaaS リソースを対象にしたトラブルシューティングがメイン想定なようではありますが、 VM を対象にしても、ある程度調査を進めてくれそうでした。
全自動で、全部おまかせとまでは行きませんでしたが、ちゃんと原因特定に貢献してくれ、緩和策も実施してくれました！
特に、複数のメトリック等を確認して CPU 高負荷が原因ではないかという最初の当たりをつけるところまでは、かなりのスピードで進めてくれたように感じました。
途中何度か SRE Agent 自体のチャット応答が途絶えたり、応答にかなり時間を要したりする場面もありました。
また、生成AI なので当たり前ではありますが、同シナリオでも再度試したときには異なる応答が返ってきて、調査するポイントや、実行するコマンド等が違ったりもしました。
そういった、不安定に見える部分もありつつ、、、ではありましたが、今回十分に調査に協力してくれたような気がします。
SRE Agent 自体はまだプレビューですので、今後も色々試してみたいと思います。
おまけ
VM が停止状態で SRE Agent に調査をお願いしてみた
VM を Windows OS 側でシャットダウンにして、停止状態にし、SRE Agent に「応答がない」と調査をお願いしてみました。
ちゃんと電源落ちてるからだよ、と調査してくれ、起動もお願いしたら実施してくれました。
なお、最初は英語でしか応答してくれなかったのですが、しつこくお願いして日本語で答えてもらいました。
SRE Agent は日本語に対応しているか
基本的には英語でやり取りして欲しそうにしてくるのですが、お願いすると日本語で答えてくれました。
ただ指示の途中でお願いするより、まず冒頭に「日本語で回答してください。」と指示を入れた方が、良さげでした。
（それでも頑なに、英語でしか対応してくれないときもあるのですが…）
SRE Agent への追加の権限付与
SRE Agent には、VM 自体を操作する権限は付与されていません。
当初の権限でもある程度原因の調査はできそうでしたが、 例えば CPU 使用率の高いプロセスを az run-command で調査したり、緩和策の実施も SRE Agent にお願いをするなら、 SRE Agent が VM に対しての権限 ( 例えば Virtual Machine Contributor ) をもつ必要がありそうです。
最初からいきなりは権限を付与せずとも、 SRE Agent で調査を進めていると、何かを実行する際に権限不足であった場合などは、この権限があればできるかどうするかといった感じのメッセージをくれるので、そこで考えてもイイかなと。
今回は検証なので、 Virtual Machine Contributor 権限を SRE Agent の Managed Identity に付与しました。
参考リンク
Discussion