AzureサービスとAIエージェントによるシステム運用の現実解

AzureサービスとAIエージェントによるシステム運用の現実解 .NETラボ 勉強会 2026年6月 1

自己紹介 山田顕人（Kento.Yamada） @ymd65536 By the wayの人、404ニキなど呼び方はさまざま 仕事：DevSecOps、クラウドインテグレーション コミュニティ運営：.NETラボ、AI運用、AI駆動開発 受賞歴（10個、継続中の称号を掲載） ● 初代PagerDutyアンバサダー 2

By the way: 弊社、Azure求人募集開始（唐突な宣伝？！） カジュアル面談や友達採用もやっています。ご相談ください。 ● 【デリバリーリード（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）】フルリモート Xのリンク ○ https://hrmos.co/pages/iret/jobs/0001134 3

• https://hrmos.co/pages/iret/jobs/0001131
• https://hrmos.co/pages/iret/jobs/0001132
• https://hrmos.co/pages/iret/jobs/0001133
• https://hrmos.co/pages/iret/jobs/0001134

前回の話 ● 有人対応から自動対応への昇華 ● システム運用にAIを導入、うまくできた例を紹介 ● システム運用のあり方（有人、ルールベース、AIOps） ● Azure SREエージェントの”SRE”は主語がデカい ● PagerDuty Advancedは役割ベースのシステム運用 ● 現実は伴走型運用、理想はAIエージェントによる自立型運用 4

24/365の有人対応から自動対応への昇華（実績共有） 引用：「AI運用勉強会#2」登壇レポート： AMSとAIエージェントが切り拓くクラウド運用の未来 https://iret.media/185536 5

• https://iret.media/185536

さまざまなシステム運用のあり方 自律型 vs 伴走型 vs ルールベース/有人対応 理想と現実の折衷案を見つける必要が出てくる。 ● AIエージェントにインシデント対応を任せる → 責任の所在が迷子 ● 逆に任せないとなるとルールベースで泥臭く立ち回る必要がある。 ● ルールベースだとシステム運用のためのシステム運用が必要 6

今日話すこと 前半 ● そもそもシステム運用をするなって？ ● ルールベース運用の話 ● 伴走型運用の話 後半 ● 自律型運用の話 ● 自律型運用が抱える問題点 7

そもそもシステム運用をするなって？（真のNoOps） 引用：.NETラボ 勉強会 2025年8月 AIエージェント開発、 DevOps and LLMOps https://www.docswell.com/s/ymd65536/KEYJXR-ai-agent-devops-and-llmops-2025-08-23#p8 8

• https://www.docswell.com/s/ymd65536/KEYJXR-ai-agent-devops-and-llmops-2025-08-23#p8

NoOps、運用を最小限にするという選択（少しだけ運用） 簡単にまとめると ● 運用のすべてをクラウドにアウトソーシングすれば、フルタイムの運用はいらないとい う考え方 ● 運用をゼロにすることは不可能なので実際は「運用作業を最小限にする」活動 例： Azure Functionsでサーバーレスを活用、運用にまつわる作業を自動化する。 👉 SREとしてトイル（労苦）を削減しながらサービスを運用していく 👉 ここでもう一歩、AI時代のNoOpsを考えてみると？（次のスライド） 9

AI時代のNoOps 人が運用しないという意味になるNoOps PaaSやサーバレスを活用して人がトイル（労苦）を削減してサービスを運用 PaaSやサーバレスを活用してAIがトイル（労苦）を削減してサービスを運用 10

AI時代のNoOps 人が運用しないという意味になるNoOps PaaSやサーバレスを活用して人がトイル（労苦）を削減してサービスを運用 ルールベース運用 PaaSやサーバレスを活用してAIがトイル（労苦）を削減してサービスを運用 伴走型/自律型運用 自律型運用 = AI時代のNoOps(人が一切介在しない運用) ※いずれにしてもシステム運用は残る。 11

クラウドでタスクをアウトソースしても 共有責任モデルは残るのでシステム運用は残り続ける https://learn.microsoft.com/ja-jp/azure/security/fundamentals/shared-resp onsibility-ai 12

• https://learn.microsoft.com/ja-jp/azure/security/fundamentals/shared-responsibility-ai

それぞれの運用について見てみよう 13

ルールベース運用 ルールセット Resolve ルール1 インシデント ルール2 ルール3 アラート検知、インシデントとして発行（場合によってはインシデントグルーピン グ）、ルールセットでインシデント対応、ルールに無いものは有人対応 👉 シンプルに考えられる上に手動対応からの自動対応のサイクルを回しやすい。 14

ルールベース運用の真価 AIの推論ではなく「透明性」と「100%の再現性」を担保 ミッションクリティカルなシステムを確実に保護するアプローチ。 つまりは多くのところで刺さりやすいフロー 15

ルールベース型のAzureインシデント対応 2. トリアージ (Triage) 4. 修復 (Mitigate) Action Groups Azure Automation 確実なルーティングと通知 承認済みRunbookの実行 1. 検知 (Detection) 3. 調査 (Investigate) 5. 事後対応 (Post) Azure Monitor Log Analytics (KQL) チケット管理 エスカレーション 厳格なしきい値とログ検索 エンジニアによる確証取得 16

※Copilotで表現していますが、深い意味はないです。 Resolve 伴走型（Copilotがいる運用） ルール1 インシデント ルール2 ルール3 アラート検知、インシデントとして発行（場合によってはインシデントグルーピング） ルールセット対応、場合によっては有人対応 + CopilotのHuman in the loop 👉ルールベース運用にAI(Copilot)を入れることができる。つまり運用がより楽？ 17

伴走型運用の真価 ルールベースと有人対応にAIの推論を加えることによって 未知のインシデントに対応できる柔軟性を獲得したアプローチ つまりはバランスが良く提案しやすい インシデント対応に対して手段を多く持てるフロー 18

伴走型のAzureインシデント対応 2. トリアージ (Triage) 4. 修復 (Mitigate) Copilot Observability 相関分析とノイズ除去 Automation + HITL 承認された⼿順の実⾏ 1. 検知 (Detection) Azure Monitor AI異常検知による監視 3. 調査 (Investigate) 5. 事後対応 (Post) Azure SRE Agent ログ突合と仮説⽣成 M365 Copilot タイムライン⾃動⽣成 19

補足：Copilot Observabilityとは（最近GA） 引用 ：https://techcommunity.microsoft.com/blog/azureobservabilityblog/azure-copilot-observability-agent-is-generally-available-with-autonomous-o perati/4528213 Azure Monitorを基盤として実行される機能 ● 横断で因果関係を特定 ● 仮説→検証→結論までを自動化 ● 自動でトリアージ補助 20

• https://techcommunity.microsoft.com/blog/azureobservabilityblog/azure-copilot-observability-agent-is-generally-available-with-autonomous-operati/4528213

※Copilotで表現していますが、深い意味はないです。 （理想）自律型運用あるいは完全自律型運用 Resolve ルール1 インシデント ルール2 ルール3 アラート検知、インシデントとして発行（場合によってはインシデントグルーピン グ）、ルールセット対応、ルールに無いものはCopilotが対応（Copilotを人が承認） 👉人がメインの運用(一次対応)に入ることがない。人はEnterを押すだけ。 21

自律型運用の真価 ルールベース + AIの推論 + 人間の承認でより迅速に対応可能 つまりは何もすることがないの極地 22

だがちょっと待ってほしい ※実際にできたら最高（複雑な気分だけど） 23

自律型運用を考えるにあたっての壁（いくつか） ● 推論コスト vs インシデント対応コスト ● AI推論によるインシデント対応 = インシデント対応の可用性 実際に動かす際に重要なこと ● AIエージェントがインシデント対応のために動き続ける ○ インシデントが長期化あるいは大量発生した際のメモリーマネジメント ● インシデント対応はマルチエージェント ○ 役割ベースのアーキテクチャ、エージェント間の連携 24

※仮にAIが発生したインシデントに対応することを例にいくらかかるのか計算 推論コスト vs インシデント対応コスト 例：3か月で58万件のインシデント、平均1件/35秒、長くても平均1件/50秒で対応 モデル GPT-4o (Global Deployment) GPT-4o-mini または Phi-4 3ヶ月の推論コスト（概算） 約 $12,760 (約204万円) 約 $783 (約12.5万円) 運用のイメージ ログの相関分析や手順書（RAG）の検索、複雑な自 律復旧コマンドの組み立て・実行まで対応。 速度最優先。定型アラートの即時自動クローズ、エ ラーコードの分類、事前定義された復旧アクション の超高速実行 ※1ドル＝160円換算 ※1件あたりの想定トークン量:入力（Input）: 4,000 トークン/出力（Output）: 1,100 トークン ※GPT-4o: 入力 $2.50 / 出力 $10.00 （100万トークンあたり）: ※GPT-4o-mini: 入力 $0.15 / 出力 $0.60（100万トークンあたり）: 25

インシデント対応の可用性 さまざまなブロッカーがいる！ ● レートリミット（429 Too Many Requests エラー） ● AIの「空回り（無限ループ）」によるタイムアウト ● モデル自体の障害・リージョン停止 例：Microsoft FoundryとAzure FunctionsまたはAzure Logic Appsで構築した自律型運用 Microsoft Foundryでは99.9%、Azure FunctionsやAzure Logic Appsでは99.9% 90日間で3時間くらいのサービス停止やエラー 26

AIエージェントがインシデント対応のために動き続ける 比較的に短期間のインシデント対応は問題ない。 ※それはルールベースで良いのでは？と思うこともあるがいったん置いておく ● AIエージェントの長期記憶 ○ インシデント対応履歴をどのように保持するか ● シングルエージェント/シングルLLMの限界 ○ モデルによって得意不得意がある。コストも関係してくる ● セッションはどういう単位で管理すべきか。セッションの寿命は？ ○ インシデント単位？案件単位？システム単位？etc 27

AIエージェントが長期記憶できる仕組みmem9 参考：https://zenn.dev/ymd65536/articles/tidb_and_databricks_mem9 mem9を使ってTiDB CloudとAzure Databricksで長期記憶を可視化する検証 28

• https://zenn.dev/ymd65536/articles/tidb_and_databricks_mem9

インシデント対応はマルチエージェント 役割ベースのアーキテクチャでかつマルチエージェントは必須 （理由：可用性とパフォーマンスの観点から） さまざまなLLMでAIエージェントを作らないといけない ● 高速なインシデントレスポンスではより小さいLLM ● 精度を求められるインシデントレスポンスではより推論能力が高いLLM ● インシデント対応履歴の要約ではトークンあたりのコスト効率が良いLLM ※LLMと書いていますが、SLMでも良いと思っています。 29

まとめ 要件に合う運用設計を前提にシステム運用に立ち向かうエンジニアは単なるイン シデント対応者にとどまることなくビルダーになるべきである。 ● 運用の自動化基盤を設計・構築（ビルド） ● AIに任せる領域と人間が承認・介在する領域の棲み分けを慎重に設計 ● マルチモデル/マルチエージェント（役割ベースのアーキテクチャ） ● AIエージェントによるインシデント対応の可用性 30

次回予告 ● .NETラボ 勉強会 2026年7月 ○ https://dotnetlab.connpass.com/event/393450/ 31

• https://dotnetlab.connpass.com/event/393450/

おわり 32