Azure AIエージェントによるシステム運用の実践と検証

Azure AIエージェントによるシステム運用の実践と検証 .NETラボ 勉強会 2026年7月 1

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

前回の話 ● そもそも運用するな/AI時代のNoOpsについての解説 ● 従来型の有人対応/伴走型運用/自律型運用の違い ● 自律型運用、実は結構難しい ● コスト、レイテンシ、推論コストとインシデント対応コストの対比 ● AIエージェント同士がインシデントを情報を共有、長期記憶どうする？ ● インシデント対応は役割ベース ○ 役割によってLLMを変える。（今日はこの話が中心） 3

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

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

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

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

今日話すこと 前半 ● 前回の話 ● 自律型のシステム運用に移行するためのステップ ● インシデント対応を役割で分割して役割ベースのエージェントを作る 後半 ● AIエージェントとユーザーのつながり ● どのように実現したら良いか 7

自律型のシステム運用に移行するためのステップ 1. 有人対応のインシデント対応を確立する 2. インシデント対応の自動化（ルールベースのインシデント対応）を推進する 3. 有人対応インシデントとルールベース対応インシデントを明確にする 4. 伴走型のシステム運用を導入、人が対応するインシデントにフォーカス 5. インシデント対応を役割で分割して役割ベースのAIエージェントを作る 6. AIエージェントを適切に配置してインシデント対応ができるか評価する 8

有人対応とルールベースによるインシデント対応を確立 ルールセット ルール1 インシデント ルール2 ルール3 修正をコミット ● 発生したインシデントをルールベースで対応できるように整備する ● ルールから漏れたものを有人対応しながらルールに組み込む（組み込めるなら） ● 組み込めないインシデントについてディスカッション（次のスライド） 9

有人対応インシデントとルールベース対応インシデントを明確にする ルールセット ルール インシデント 有人対応 フィードバック、修正 ● 既存のルールセットを維持管理していく ● ルールセットで対応できるインシデントかどうかを判定 ● 自動で対応可能なインシデントであることが多いが、そうでないケースもある 10

補足：自動で対応可能なインシデントであることが多いが、そうでないケース ● システム運用の方針が契約でガッチリ決められている ● 当時の暫定対応がそのまま理由なく続けられている ○ （なお理由は誰も知らない） ● 有人対応であることが原則になっている。あるいはそう決めている場合 ● インシデント対応の自動化に必要な権限・認可が不足している 自動化以前にインシデント対応事情を改善することやステークホルダーを巻 き込んでディスカッションする必要がある。黙ってやらずに話し合いをしま しょう。 11

※Copilotで表現していますが、深い意味はないです。 伴走型のシステム運用を導入 Resolve ルールセット ルール1 インシデント ルール2 ● ルールセットでインシデント対応を解決しつつ、伴走型のシステム運用を導入 ● 有人/有人+Copilotによるインシデント対応を続ける ● AIエージェントによるシステム運用がどこまでのラインならば問題ないかを確認 12

インシデント対応を役割で分割して役割ベースのエージェントを作る 名前 説明 SREエージェント インシデントのトリアージと解決を直接的に支援する エージェント Scribeエージェント インシデント対応中のコミュニケーションと記録の自 動化に特化 Shiftエージェント オンコールシフトの管理とスケジュールの競合解決を 担うAIアシスタント システム運用のデータから、予防的なアプローチと改 Insights エージェント 善案を提示 SlackやTeams内でエンジニアが直接対話するための、 Assistantエージェント 汎用インターフェースとしての役割を持つ 13

※Copilotで表現していますが、深い意味はないです。 404 Not Found Webシステム Log 1. ログ調査と切り分け 2.調査を元に復旧計画を作成 Azure上の サービス 3.復旧計画の提示、コマンド実行 ユーザー 4. インシデント対応の記録 14

※Copilotで表現していますが、深い意味はないです。 404 Not Found Webシステム Log 1.Tier 1 SREエージェント 2.Insights エージェント Azure上の サービス 3.Tier 2 SREエージェント ユーザー 4.Scribeエージェント 15

SREエージェントをTier 1とTier 2で分ける理由 有人対応は2層に分割 → そのままアーキテクチャに反映したという 意味ではない。 エージェント毎の推論時間を考慮 →計算コストと待ち時間を最適化する設計 16

補足：AIエージェント毎に計算コストと待ち時間を最適化する設計とは AIエージェントの性質を考慮する設計のこと、具体的には以下のとおりです。 ● レイテンシ ○ ターンアラウンドタイムが短い ● コンテキスト長 ○ インプット/アウトプットの量 ● モデルコスト ○ 対応したいことにモデル単価が見合っているか ● 推論能力 ○ 問題に対する回答で解決策を提示できているか 17

AIエージェントとユーザーのつながり 承認作業 Insights (Sub Agent) Tier 1 SRE Scribe Tier 2 SRE ユーザー Resolve ● 最初にルールベースで推論コストがいらないインシデントをフィルターする ● Tier 1で障害を切り分け、Tier2に回すほどの対応でなければTier1で解決 ● Tier 2に届いたインシデントは高い推論力でインシデントに対応する 18

実際にやってみた 馴染みの技術で検証してみました！ 19

利用技術（概要） ● 言語: C#、言語ランタイム: .NET10 ● フレームワーク: Blazor ● Dapr Workflow ● インフラ: Kubernetes 参考：https://github.com/ymd65536/azure-agentic-ops-lab.git 20

• https://github.com/ymd65536/azure-agentic-ops-lab.git

実際に作ってみた 21

検証してみての気づき ルールベースで解決できるものはAIが不要 AIエージェントにも判断ポリシーが必要 推論コストを下げるとは安いモデルを選ぶことだけではない 22

ルールベースで解決できるものはAIが不要 Incident Layer 0: Rule Rule-based Layer 1: Tier 1 Layer 2: Tier 2 Layer 3: Human 解決可能 → 実行・検証 解決困難 → AIへ ルールで解決できるなら推論ではなくコンピューティングで解決 23

AIエージェントにも判断ポリシーが必要 ルールベース Tier 1 Tier 2 ルールセット ポリシーセット ポリシーセット ルール1 ポリシー1 ポリシー1 ルール2 ポリシー2 ポリシー2 ルール3 ポリシー3 ポリシー3 AIエージェントにもある種のルール（判断基準）が必要！ 24

推論コストを下げるとは安いモデルを選ぶことだけではない 推論効率を高める ≠ 高価なモデルを安いモデルに変える ● AIを使わずに済むか ● 小さい推論で済むか ● 深い推論が必要か ● 人間判断が必要か 推論コストはモデル選択だけでなく、推論そのものを発生させる かどうかから設計する 25

Azureネイティブの自律型運用へ 今回のアーキテクチャはAzureのマネージドサービスへ置き換えられる ● Microsoft Foundry ● Microsoft Foundry の Hosted Agent ● Copilot Observability ● Azure Monitor ● AKS 26

推論効率は計算資源にも影響する Rule システム運用の範囲 Tier1 Tier2 Human Inference Budget(推論予算) AI（柱となる部分） GPU Capacity 計算資源を継続して供給しないといけない！つまりGPU調達 27

自律型運用はシステム運用を超える 障害対応 推論効率 GPU調達 キャパシティ プランニング AIエージェントによるインシデント対応を継続するには 推論効率を高めるとともに必要なGPU容量を予測・確保するキャ パシティプランニングが重要になる。 28

まとめ ● AIエージェントの自律性とはAIの強さではなく、ルール・推論・人間判断を 適切に切り替える能力 ○ ルールで解決できるものはルールで解決する ○ 不確実なものだけAIに推論させる ○ 危険な判断は人間とポリシーが止める 自律型運用とはすべてをAIに任せることではなくAIを使わない判断も含める運用 のことです。継続的に推論効率を高める方法を実践 29

自律型運用はエージェンティックディフェンスにつながる 引用：OpenAI と Hugging Face、モデル評価中のセキュリティインシデント対応で連携 https://openai.com/ja-JP/index/hugging-face-model-evaluation-security-incident/ ● 検証環境内でインターネットへの経路見つけて攻撃（攻撃経路を自律的に特定） ● 教訓：モデルの強さに合わせて防御策を考えないといけない サンドボックスやガードレールでは突破される危険性ある。自律型防御が重要 30

• https://openai.com/ja-JP/index/hugging-face-model-evaluation-security-incident/

次回予告 ● .NETラボ 勉強会 2026年8月 ○ https://dotnetlab.connpass.com/event/396232/ ● 2026/07/28(火) ゆるよな Gh-CUG #04 ○ https://gh-cug.connpass.com/event/398599/ ○ GitHub Copilotの新しい課金方式との付き合い方 ― 推論効率を高めるた めの実践 次は今回の内容をAzureのマネージドサービスに置き換えてみるYo 31

• https://dotnetlab.connpass.com/event/396232/
• https://gh-cug.connpass.com/event/398599/

おわり 32