--- title: Azure AIエージェントによる自律型運用の実践 tags: #生成ai #azure #aiエージェント #システム運用 author: [Kento Yamada](https://docswell.com/user/ymd65536) site: [Docswell](https://www.docswell.com/) thumbnail: https://bcdn.docswell.com/page/YJ6WGQQ1JV.jpg?width=480 description: .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/ published: August 22, 26 canonical: https://docswell.com/s/ymd65536/ZL3ND8-2026-08-22 --- # Page. 1 ![Page Image](https://bcdn.docswell.com/page/YJ6WGQQ1JV.jpg) Azure AIエージェントによる自律型運用の実践 .NETラボ 勉強会 2026年8月 1 # Page. 2 ![Page Image](https://bcdn.docswell.com/page/GJ5MVRRLJ4.jpg) 自己紹介 山田顕人（Kento.Yamada） @ymd65536 By the wayの人、404ニキなど呼び方はさまざま 仕事：DevSecOps、クラウドインテグレーション コミュニティ運営：.NETラボ、AI運用、AI駆動開発 受賞歴（10個、継続中の称号を掲載） ● 初代PagerDutyアンバサダー 2 # Page. 3 ![Page Image](https://bcdn.docswell.com/page/LE3WDPPDE5.jpg) 前回の話 自律型運用を目指したAIエージェントの実装・検証を通じて、推論遅延や エージェントの役割分担など実践から見えてきた課題を紹介 ● 自律型のシステム運用に移行するためのステップ ● AIエージェント毎に計算コストと待ち時間を最適化する ● AIエージェントの使いどころ考える。ルールベースを最初に通す ● 推論効率は計算資源にも影響する。GPUを調達しようぜ！ 今日は自律型運用の話 3 # Page. 4 ![Page Image](https://bcdn.docswell.com/page/8EDKPLL27G.jpg) デモ ローカル上の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 # Page. 5 ![Page Image](https://bcdn.docswell.com/page/V7PKN22LJ8.jpg) 最初のステップ プロンプト： 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 # Page. 6 ![Page Image](https://bcdn.docswell.com/page/2JVVKDD6JQ.jpg) 原因候補 6 # Page. 7 ![Page Image](https://bcdn.docswell.com/page/5EGLQYY2JL.jpg) 運用担当者に依頼すべき具体的対処 7 # Page. 8 ![Page Image](https://bcdn.docswell.com/page/4JQYKMM97P.jpg) 運用担当者に依頼すべき具体的対処2 8 # Page. 9 ![Page Image](https://bcdn.docswell.com/page/K74WPV4RE1.jpg) Copilotへ指示 9 # Page. 10 ![Page Image](https://bcdn.docswell.com/page/LJ1Y934VEG.jpg) 出力のおわり 10 # Page. 11 ![Page Image](https://bcdn.docswell.com/page/GJWGQPX372.jpg) 自律型運用の現在地 レイヤー 段階 状態 2026年現在 L1 自動化 条件→決められた処理 普及済 L2 AI支援運用 AIが調査・要約・原因候補提示 普及期 L3 Agentic Operations AIが調査→判断→実行計画 製品化済み L4 Closed-loop Operations 検知→調査→変更→検証を自動実行 限定領域で本番 化 L5 Self-Adaptive Operations 未知障害を含め自ら運用方法を変える まだ未到達 L6 完全自律運用 システム全体を人間なしで維持・進化 まだない 11 # Page. 12 ![Page Image](https://bcdn.docswell.com/page/4EZLWK6G73.jpg) Azure SRE Agentはどこまで来てるか/やれるか レイヤー 段階 状態 2026年現在 L1 自動化 条件→決められた処理 普及済 L2 AI支援運用 AIが調査・要約・原因候補提示 普及期 L3 Agentic Operations AIが調査→判断→実行計画 製品化済み L4 Closed-loop Operations 検知→調査→変更→検証を自動実 行 限定領域で本 番化 L5 Self-Adaptive Operations 未知障害を含め自ら運用方法を変 える まだ未到達 L6 完全自律運用 システム全体を人間なしで維持・ 進化 まだない 12 # Page. 13 ![Page Image](https://bcdn.docswell.com/page/Y76WGQ2Q7V.jpg) Azure SRE Agentはどこまで来てるか/やれるか 障害検知 ソースコード調査 原因特定 コード修正 Container restart サービス正常性確認 git commit git push GitHub Issue さらにAzure CLI経由でAzure Resourceに対する変更を実行できる。 →（ある程度）エージェントに閉じて改善アクションをループできる 13 # Page. 14 ![Page Image](https://bcdn.docswell.com/page/G75MVR2274.jpg) しかし、これがまたおもしろいところ No change deploys without human sign-off. ？！ ● 最新のoverviewでは「変更は人間が承認する」と説明 ● 一方、SRE AgentにはReview/Autonomous modeというモードがある ● Autonomousでは承認なしで実行できるが、本番ではReview modeを推奨 14 # Page. 15 ![Page Image](https://bcdn.docswell.com/page/9J293D41ER.jpg) 自動で検知することの弊害 実はこれも？！って話を付け加えて話します！ 15 # Page. 16 ![Page Image](https://bcdn.docswell.com/page/DEY412M4JM.jpg) Azure SRE Agentにアラート静観の概念はない？ 16 # Page. 17 ![Page Image](https://bcdn.docswell.com/page/VJNY28W678.jpg) 「静観(Watch)」という状態 ● デプロイ直後だから5分様子を見る ● オートスケール中だから一旦待つ ● Podが再起動中 ● DBフェイルオーバー中 ● Cold Start中 正常な自己回復と競合する！静観 = 「対応できない」のではなく、状況変化 を待ってから再評価するという意図的な運用判断 17 # Page. 18 ![Page Image](https://bcdn.docswell.com/page/YE9P1KXRJ3.jpg) 技術的には自律実行できる。 しかし、どこまで自律させるべきかは別問題 You are free to move however much you like, but that doesn't mean you *should*. いくらでも動けるが、いくらでも動いて良いとは言っていない。 18 # Page. 19 ![Page Image](https://bcdn.docswell.com/page/GE8D4R2GED.jpg) では「完全自律」に何が足りないのか Could it be... the power to fight 24 hours a day ? もしかして、24時間戦うパワー？ 19 # Page. 20 ![Page Image](https://bcdn.docswell.com/page/LELM6K2X7R.jpg) 結論：自分自身の運用方法を更新する Observe Reason Act Verify すでにできる領域 Learn Change its own operational policy Observe... 本当に必要なこと インシデント対応が終わったあとの振り返りと学習が重要 20 # Page. 21 ![Page Image](https://bcdn.docswell.com/page/4JMY5283JW.jpg) 自律型運用のポイント ヒト駆動（前回） ● 継続的に推論効率を高める方法を実践 ○ すべてをAIに任せるのではなくAIを使わない判断を含める運用 AI駆動（今回） ● AI自らが判断してインシデント対応をしない方法を模索して実践 ○ 運用システム自身が経験からルールベースを更新し続ける運用 21 # Page. 22 ![Page Image](https://bcdn.docswell.com/page/PJR93M5R79.jpg) 完全自律型運用では何が起きるか 完全自律型運用の特徴（改めてまとめる） ● 人間が介在しないこと ● AIに多くのことを推論させないこと ● AIはルールベースの仕組みに仕事を奪われること（これが重要） AIが人の仕事を奪う一方で起きること！ AIが自分の仕事をルールベースで構築してAIが楽をする！ 22 # Page. 23 ![Page Image](https://bcdn.docswell.com/page/PEXQ4VKYJX.jpg) AIはルールベースの仕組みに仕事を奪われること 404 Not Found Server 65,536台 Serverから404エラー、65,536台すべてのエラーをAIで対応？ →1台対応したら残りの65,535台はルールで処理したら良い 23 # Page. 24 ![Page Image](https://bcdn.docswell.com/page/3EK9ZQ54ED.jpg) 例：nginxのエラー 404 → nginx設定調査 → route修正 → deploy → verify 100回 1発目のインシデントに対応したら、インシデントを学習してルール を生成する。残りの99回はルールベースで解決する。 24 # Page. 25 ![Page Image](https://bcdn.docswell.com/page/L73WDPKD75.jpg) ステータスコードが同じでも原因は異なる。 同じ対応で本当に良いか ケースよってはルールベースを更新するタイミングが必要では？ 25 # Page. 26 ![Page Image](https://bcdn.docswell.com/page/87DKPL32JG.jpg) ※Copilotで表現していますが、深い意味はないです。 インシデント対応を一周させる Resolve ルールセット インシデント ルール rule update No match rule L1 SRE L2 SRE Resolve Scribe Rule Manager 26 # Page. 27 ![Page Image](https://bcdn.docswell.com/page/VJPKN24LE8.jpg) ※Copilotで表現していますが、深い意味はないです。 ルールベースの更新（昇格） ルールセット ルール インシデント ペロっ！ これはパターン入ってきた 次のインシデントからはルールで対応、AIはサボれるようにする！ 27 # Page. 28 ![Page Image](https://bcdn.docswell.com/page/2EVVKDX6EQ.jpg) ※Copilotで表現していますが、深い意味はないです。 ルールベースの更新（降格） インシデント ルール1 NG ルール2 NG ルール3 NG どのルールもダメやんけ お前ら降格な！ もちろん、運用の変化によって既存のルールが変わることもある。 新しい運用に適応したルールをAIが再生成する。 28 # Page. 29 ![Page Image](https://bcdn.docswell.com/page/57GLQYV2EL.jpg) なぜAIに毎回答えさせないのか？ AIは万能ではない 推論資源も無限ではない それ以外にも理由がある。 29 # Page. 30 ![Page Image](https://bcdn.docswell.com/page/4EQYKM69JP.jpg) AIは万能ではない。推論資源も無限ではない。それ以外 にも理由がある 同じ既知障害に毎回推論資源を使う？ それとも未知障害へ回す？ 推論回数を増やせば賢くなるとは限らない 30 # Page. 31 ![Page Image](https://bcdn.docswell.com/page/KJ4WPVMR71.jpg) 推論回数を増やせば賢くなるとは限らない 引用：https://huggingface.co/blog/ibm-research/itbench-aa フロンティアモデルによるインシデント対応は50%未満のベンチマーク 31 # Page. 32 ![Page Image](https://bcdn.docswell.com/page/LE1Y938V7G.jpg) インシデント対応を実験として管理する Incident Response Experiment Management ● どの種類のインシデントか ● Rule / Agent / Humanのどれで処理したか ● どのモデルを使ったか ● 何回推論したか ● どのToolを使ったか ● 復旧に成功したか ● 復旧まで何秒かかったか ● 推論コストはいくらか ● 不要な操作はなかったか ● 次回Ruleへ昇格できるか 32 # Page. 33 ![Page Image](https://bcdn.docswell.com/page/GEWGQPZ3J2.jpg) 補足：単なるLLM Evaluationではない ● Model Evaluation ○ モデルがどれだけ賢いか ● Incident Response Experiment Management ○ どのインシデントにどのAgent / Model / Rule / Actionを割 り当てると最も良い運用になるか 33 # Page. 34 ![Page Image](https://bcdn.docswell.com/page/47ZLWK1GJ3.jpg) まとめ ● 行動しないことも運用判断のひとつ ● AIエージェントを動かさないことも自律性のひとつ ● Ruleを増やし続けるだけではない ○ Ruleの有効性を評価して昇格・更新・降格する ● 完全自律型運用とは ○ インシデント対応を継続的に実験・評価してより良いRule、 Agent、Model、Actionへ更新し続ける運用 34 # Page. 35 ![Page Image](https://bcdn.docswell.com/page/YJ6WGQLQJV.jpg) 次回予告 ● .NETラボ 勉強会 2026年9月 ○ https://dotnetlab.connpass.com/event/399503/ 次はIncident Response Experiment Management 35