Azure AIエージェントによる自律型運用の実践
252 Views
August 22, 26
スライド概要
.NETラボ 勉強会 2026年8月の登壇資料です。
https://dotnetlab.connpass.com/event/396232/
カジュアル面談や友達採用もやっています。ご相談ください。
【デリバリーリード（Azure）】フルリモート
https://hrmos.co/pages/iret/jobs/0001131
【ソリューションアーキテクト（Azure）】フルリモート
https://hrmos.co/pages/iret/jobs/0001132
【クラウドエンジニア（Azure）】フルリモート
https://hrmos.co/pages/iret/jobs/0001133
【Webアプリエンジニア（Azure）】フルリモート
https://hrmos.co/pages/iret/jobs/0001134
カジュアル面談の申し込み
https://www.iret.co.jp/recruit/career/job/
Cloud Developer,404ニキ,Microsoft MVP,LINE API Expert,PagerDuty Ambassador,Google Cloud PTE/Tech Influencer,AWS Community Builder, #AIDD #AI駆動開発 #dotnetlab 投稿は個人の見解, #AzPoC
関連スライド
各ページのテキスト
Azure AIエージェントによる自律型運用の実践 .NETラボ 勉強会 2026年8月 1
自己紹介 山田顕人（Kento.Yamada） @ymd65536 By the wayの人、404ニキなど呼び方はさまざま 仕事：DevSecOps、クラウドインテグレーション コミュニティ運営：.NETラボ、AI運用、AI駆動開発 受賞歴（10個、継続中の称号を掲載） ● 初代PagerDutyアンバサダー 2
前回の話 自律型運用を目指したAIエージェントの実装・検証を通じて、推論遅延や エージェントの役割分担など実践から見えてきた課題を紹介 ● 自律型のシステム運用に移行するためのステップ ● AIエージェント毎に計算コストと待ち時間を最適化する ● AIエージェントの使いどころ考える。ルールベースを最初に通す ● 推論効率は計算資源にも影響する。GPUを調達しようぜ！ 今日は自律型運用の話 3
デモ ローカル上のGitHub CopilotとMicrosoft FoundryのHosted Agentsを活用 1. ローカルからAzure上のAzure VMにhttpリクエスト 2. httpリクエストの結果をプロンプトに含めてHosted Agentsを起動（azd ai） 3. Hosted Agentsの調査内容をもとにGitHub CopilotでAzure VMを直す 4. Azure VMが 404 Not Found→ 200 OKに変化する 4
最初のステップ プロンプト： nginxを導入されたAzure VMにアクセスしました。アクセス先は http://20.25.31.242/healthで す。 curlでアクセスした結果は<html>\r\n<head><title>404 Not Found</title></head>\r\n<body>\r\n<center><h1>404 Not Found</h1></center>\r\n<hr><center>nginx/1.18.0 (Ubuntu)</center>\r\n</body>\r\n</html>\r でした。ステータスコード、応答内容、原因候補 を日本語で簡潔に示し、GitHub Copilot向けに修正のためのプロンプトを考えて生成してくださ い。 5
原因候補 6
運用担当者に依頼すべき具体的対処 7
運用担当者に依頼すべき具体的対処2 8
Copilotへ指示 9
出力のおわり 10
自律型運用の現在地 レイヤー 段階 状態 2026年現在 L1 自動化 条件→決められた処理 普及済 L2 AI支援運用 AIが調査・要約・原因候補提示 普及期 L3 Agentic Operations AIが調査→判断→実行計画 製品化済み L4 Closed-loop Operations 検知→調査→変更→検証を自動実行 限定領域で本番 化 L5 Self-Adaptive Operations 未知障害を含め自ら運用方法を変える まだ未到達 L6 完全自律運用 システム全体を人間なしで維持・進化 まだない 11
Azure SRE Agentはどこまで来てるか/やれるか レイヤー 段階 状態 2026年現在 L1 自動化 条件→決められた処理 普及済 L2 AI支援運用 AIが調査・要約・原因候補提示 普及期 L3 Agentic Operations AIが調査→判断→実行計画 製品化済み L4 Closed-loop Operations 検知→調査→変更→検証を自動実 行 限定領域で本 番化 L5 Self-Adaptive Operations 未知障害を含め自ら運用方法を変 える まだ未到達 L6 完全自律運用 システム全体を人間なしで維持・ 進化 まだない 12
Azure SRE Agentはどこまで来てるか/やれるか 障害検知 ソースコード調査 原因特定 コード修正 Container restart サービス正常性確認 git commit git push GitHub Issue さらにAzure CLI経由でAzure Resourceに対する変更を実行できる。 →（ある程度）エージェントに閉じて改善アクションをループできる 13
しかし、これがまたおもしろいところ No change deploys without human sign-off. ？！ ● 最新のoverviewでは「変更は人間が承認する」と説明 ● 一方、SRE AgentにはReview/Autonomous modeというモードがある ● Autonomousでは承認なしで実行できるが、本番ではReview modeを推奨 14
自動で検知することの弊害 実はこれも？！って話を付け加えて話します！ 15
Azure SRE Agentにアラート静観の概念はない？ 16
「静観(Watch)」という状態 ● デプロイ直後だから5分様子を見る ● オートスケール中だから一旦待つ ● Podが再起動中 ● DBフェイルオーバー中 ● Cold Start中 正常な自己回復と競合する！静観 = 「対応できない」のではなく、状況変化 を待ってから再評価するという意図的な運用判断 17
技術的には自律実行できる。 しかし、どこまで自律させるべきかは別問題 You are free to move however much you like, but that doesn't mean you *should*. いくらでも動けるが、いくらでも動いて良いとは言っていない。 18
では「完全自律」に何が足りないのか Could it be... the power to fight 24 hours a day ? もしかして、24時間戦うパワー？ 19
結論：自分自身の運用方法を更新する Observe Reason Act Verify すでにできる領域 Learn Change its own operational policy Observe... 本当に必要なこと インシデント対応が終わったあとの振り返りと学習が重要 20
自律型運用のポイント ヒト駆動（前回） ● 継続的に推論効率を高める方法を実践 ○ すべてをAIに任せるのではなくAIを使わない判断を含める運用 AI駆動（今回） ● AI自らが判断してインシデント対応をしない方法を模索して実践 ○ 運用システム自身が経験からルールベースを更新し続ける運用 21
完全自律型運用では何が起きるか 完全自律型運用の特徴（改めてまとめる） ● 人間が介在しないこと ● AIに多くのことを推論させないこと ● AIはルールベースの仕組みに仕事を奪われること（これが重要） AIが人の仕事を奪う一方で起きること！ AIが自分の仕事をルールベースで構築してAIが楽をする！ 22
AIはルールベースの仕組みに仕事を奪われること 404 Not Found Server 65,536台 Serverから404エラー、65,536台すべてのエラーをAIで対応？ →1台対応したら残りの65,535台はルールで処理したら良い 23
例：nginxのエラー 404 → nginx設定調査 → route修正 → deploy → verify 100回 1発目のインシデントに対応したら、インシデントを学習してルール を生成する。残りの99回はルールベースで解決する。 24
ステータスコードが同じでも原因は異なる。 同じ対応で本当に良いか ケースよってはルールベースを更新するタイミングが必要では？ 25
※Copilotで表現していますが、深い意味はないです。 インシデント対応を一周させる Resolve ルールセット インシデント ルール rule update No match rule L1 SRE L2 SRE Resolve Scribe Rule Manager 26
※Copilotで表現していますが、深い意味はないです。 ルールベースの更新（昇格） ルールセット ルール インシデント ペロっ！ これはパターン入ってきた 次のインシデントからはルールで対応、AIはサボれるようにする！ 27
※Copilotで表現していますが、深い意味はないです。 ルールベースの更新（降格） インシデント ルール1 NG ルール2 NG ルール3 NG どのルールもダメやんけ お前ら降格な！ もちろん、運用の変化によって既存のルールが変わることもある。 新しい運用に適応したルールをAIが再生成する。 28
なぜAIに毎回答えさせないのか？ AIは万能ではない 推論資源も無限ではない それ以外にも理由がある。 29
AIは万能ではない。推論資源も無限ではない。それ以外 にも理由がある 同じ既知障害に毎回推論資源を使う？ それとも未知障害へ回す？ 推論回数を増やせば賢くなるとは限らない 30
推論回数を増やせば賢くなるとは限らない 引用：https://huggingface.co/blog/ibm-research/itbench-aa フロンティアモデルによるインシデント対応は50%未満のベンチマーク 31
インシデント対応を実験として管理する Incident Response Experiment Management ● どの種類のインシデントか ● Rule / Agent / Humanのどれで処理したか ● どのモデルを使ったか ● 何回推論したか ● どのToolを使ったか ● 復旧に成功したか ● 復旧まで何秒かかったか ● 推論コストはいくらか ● 不要な操作はなかったか ● 次回Ruleへ昇格できるか 32
補足：単なるLLM Evaluationではない ● Model Evaluation ○ モデルがどれだけ賢いか ● Incident Response Experiment Management ○ どのインシデントにどのAgent / Model / Rule / Actionを割 り当てると最も良い運用になるか 33
まとめ ● 行動しないことも運用判断のひとつ ● AIエージェントを動かさないことも自律性のひとつ ● Ruleを増やし続けるだけではない ○ Ruleの有効性を評価して昇格・更新・降格する ● 完全自律型運用とは ○ インシデント対応を継続的に実験・評価してより良いRule、 Agent、Model、Actionへ更新し続ける運用 34
次回予告 ● .NETラボ 勉強会 2026年9月 ○ https://dotnetlab.connpass.com/event/399503/ 次はIncident Response Experiment Management 35