--- title: AIエージェントによるシステム運用の理想と現実 tags: #生成ai #システム運用 #aiエージェント #azure #aiops author: [Kento Yamada](https://image.docswell.com/user/ymd65536) site: [Docswell](https://www.docswell.com/) thumbnail: https://bcdn.docswell.com/page/GE5MZW3GE4.jpg?width=480 description: .NETラボ 勉強会 2026年5月 の登壇資料です。 https://dotnetlab.connpass.com/event/386362/ AIによる要約 ### 【要約】AIエージェントによるシステム運用の理想と現実 現在のシステム運用において、AIエージェントは「完全自律型」ではなく、人間の意思決定を補佐する「伴走型（SRE Copilot）」として活用するのが現実的かつ最適解である。 #### 1. SREエージェントの現在地 * 「SREエージェント」という呼称は広義すぎ、現状の技術は「インシデント対応」という特定機能に特化した「SRE Copilot」と呼ぶのが適切である。 #### 2. システム運用におけるAIの役割分担 * 発生前：メトリクス分析による予兆検知、動的しきい値設定による不要アラートの削減 * 発生中：アラートの相関分析、グループ化、根本原因分析（RCA）の提示によるMTTRの短縮 * 発生後：対応履歴の自動要約、タイムライン作成、再発防止に向けたコード修正案の提示 #### 3. 伴走型運用（Human-in-the-Loop）の推奨 * 完全自律型の課題：権限移譲に伴う本番環境の破壊的リスクや説明責任の欠如。 * 伴走型アプローチ：AIが分析とアクションプランのドラフトを作成し、人間が最終的な承認と実行を担うことでリスクを管理する。 * コマンド実行の留意点：推論レイテンシやLLMの可用性リスク、誤実行による二次災害を防ぐため、AIにコマンドを打たせない運用を推奨。 #### 4. 運用エンジニアのあり方 * 「システムを維持する」だけの運用は価値を失いつつある。 * AIによるプロセス自動化を前提とし、今後は全員が「ビルダー（作り手）」へとシフトすることが求められる。 published: May 23, 26 canonical: https://image.docswell.com/s/ymd65536/Z1QX28-2026-05-23 --- # Page. 1 ![Page Image](https://bcdn.docswell.com/page/GE5MZW3GE4.jpg) AIエージェントによるシステム運用の理想と現実 .NETラボ 勉強会 2026年5月 1 # Page. 2 ![Page Image](https://bcdn.docswell.com/page/9729RQZDJR.jpg) 自己紹介 山田顕人（Kento.Yamada） @ymd65536 By the wayの人、404ニキなど呼び方はさまざま 仕事：DevSecOps、クラウドインテグレーション コミュニティ運営：.NETラボ、AI運用、AI駆動開発 受賞歴（９つ、継続中の称号を掲載） ● New! 初代PagerDutyアンバサダー 2 # Page. 3 ![Page Image](https://bcdn.docswell.com/page/DJY4DWRM7M.jpg) 今日話すこと 前半 ● ● ● ● 24/365の有人対応から自動対応への昇華（実績共有） システム運用にAIを導入、うまくいってる例を紹介 有人対応、ルールベース、AIOps、それぞれの違い 後半へのつなぎ：SREエージェントは主語デカだし、厳密には〇〇では？ 後半 ● ● ● ● SREとはなんだったか（SREエージェントの話の前にひとつ） Azure SREエージェントはSREなのか PagerDuty SREエージェントではどうか AIエージェントによるシステム運用の理想と現実 3 # Page. 4 ![Page Image](https://bcdn.docswell.com/page/V7NY69D3E8.jpg) 24/365の有人対応から自動対応への昇華（実績共有） 引用：AI運用勉強会#2 2026/02/04 にライブ配信 https://www.youtube.com/live/y2kCoW4kYO0?si=Y1uTGxni91JGX-Xe&t=971 4 # Page. 5 ![Page Image](https://bcdn.docswell.com/page/YJ9PL2GP73.jpg) 24/365の有人対応から自動対応への昇華（実績共有） 引用：「AI運用勉強会#2」登壇レポート： AMSとAIエージェントが切り拓くクラウド運用の未来 https://iret.media/185536 5 # Page. 6 ![Page Image](https://bcdn.docswell.com/page/GJ8DX5VXJD.jpg) システム運用とAIエージェント 引用： https://www.youtube.com/live/y2kCoW4kYO0?si=gDVH5TiqJSQSuD32&t=1065 6 # Page. 7 ![Page Image](https://bcdn.docswell.com/page/LJLM8Y5NER.jpg) システム運用とAIエージェント 引用： https://www.youtube.com/live/y2kCoW4kYO0?si=NDNNUrUoghN9ot_v&t=1200 7 # Page. 8 ![Page Image](https://bcdn.docswell.com/page/47MY6N3Q7W.jpg) こんな感じでシステム運用にAIを取り入れる活動は進ん でいるが、、、、 うまくいっているところとそうでないところでバラバラ うまくできているところの代表例 ● Looker会話分析を使ったインシデント情報分析 ● テクニカルサポート用のサポートデータ検索システム 8 # Page. 9 ![Page Image](https://bcdn.docswell.com/page/P7R9PDQKE9.jpg) Looker会話分析を使ったインシデント情報分析 運用分析プラットフォーム 引用：「AI運用勉強会#2」登壇レポート： AMSとAIエージェントが切り拓くクラウド運用の未来 https://iret.media/185536 9 # Page. 10 ![Page Image](https://bcdn.docswell.com/page/PJXQ31557X.jpg) Looker会話分析を使ったインシデント情報分析 引用：アーカイブ配信中【事例から学ぶ！】データ定義が 9割—AI分析を正しく動かすための「データの整え方」 https://wake-career.jp/community/events/7d034711-c3d7-473d-9f69-6cb439078c29 10 # Page. 11 ![Page Image](https://bcdn.docswell.com/page/3JK9Y26RJD.jpg) サポートデータ検索システム サポートデスク担当チーム向けに生成 AI を活用した「問い合わせ要約・検索機能 （以下、cloudpack サポートデータ検索システム）」を開発。 引用：https://www.iret.co.jp/works/24-35.html 11 # Page. 12 ![Page Image](https://bcdn.docswell.com/page/LE3W946GE5.jpg) 有人対応、ルールベース、AIOps、それぞれの違い 特徴 有人対応 ルールベース AIOps 柔軟性 非常に高い（未知に対応可） 低い（定義済みのみ） 高い（推論による適応） コスト 非常に高い（人件費） 低い（開発・維持のみ） 中〜低（LLM利用料等） スピード 経験値・熟練度による 即時（スクリプト実行） 高速（分析・提案まで数分） 信頼性 ムラがある（人的ミス） 極めて高い（決定論的） 注意が必要（非決定論的） 12 # Page. 13 ![Page Image](https://bcdn.docswell.com/page/8EDKGQVN7G.jpg) 有人対応 メリット ● コミュニケーションの取りやすさ ● 未知の問題への対応 ● より高度なサポートができる（💰でサポートレベルを変えることも？） ○ ※サポートレベルで金額が異なることは運用ではよくある デメリット ● 人件費 ● 熟練度や経験値による対応レベルの差 ● 人的ミス 13 # Page. 14 ![Page Image](https://bcdn.docswell.com/page/V7PK3LVNJ8.jpg) ルールベース 決定論的な考え方で発生したインシデントを解決する。弊社の監視基盤はコレ メリット ● Runbookで解決方法がコードになる デメリット ● 決まったパターンにのみ効果を発揮する ● Runbookの運用（運用のための運用が必要） 14 # Page. 15 ![Page Image](https://bcdn.docswell.com/page/2JVV4QZYJQ.jpg) AIOps 機械学習をシステム運用に取り入れてインシデントを解決する （昔ながらに言われているもの、今のPagerDutyはこの延長線にある） メリット ● 高い推論力によるインシデントの解決（柔軟性） デメリット ● 対応力への信頼性（誤った判断で対応してしまわないか） ● AI自体の可用性（AIが動作するインフラが不全） 15 # Page. 16 ![Page Image](https://bcdn.docswell.com/page/5EGL1W4WJL.jpg) それぞれメリット・デメリットを見てきたところで やっぱ、システム運用でも積極的にAI使いたいよね？ →SRE エージェントの登場！だがちょっと待ってほしい。 16 # Page. 17 ![Page Image](https://bcdn.docswell.com/page/4JQYD3GQ7P.jpg) in my opinion: SREエージェントは〇〇 「SREエージェント」意味するところは あまりにも大きいのではないだろうか。 17 # Page. 18 ![Page Image](https://bcdn.docswell.com/page/K74WZ15YE1.jpg) SREとはなんだったか 引用：https://cloud.google.com/sre?hl=ja 信頼性の高い本番環境システムを実行するための職務 あるいはマインドセット/手法のこと 18 # Page. 19 ![Page Image](https://bcdn.docswell.com/page/LJ1YRGWNEG.jpg) SREの特徴を見てみると 引用：https://cloud.google.com/sre?hl=ja ● コードの記述/サービスの実行 ● トイルの削減 ● 問題の解決と信頼性 19 # Page. 20 ![Page Image](https://bcdn.docswell.com/page/GJWG1KRM72.jpg) Azure SREエージェントはSREなのか 結論： 今のところSREと呼ぶにふさわしくない（と考えられる） 理由 ● トイルの削減/システム運用だけをすることをSREと定義して いないから 20 # Page. 21 ![Page Image](https://bcdn.docswell.com/page/4EZLPZRM73.jpg) Azure SREエージェントはSREなのか 引用：https://learn.microsoft.com/ja-jp/azure/sre-agent/overview?tabs=task#what-is-sre-agent SREの特徴はあるがSREではない。 問題があったとき自らの考えとビジネス上の意思決定を元にエラーバジェットを意 識してサービスを改善するという本質が抜けている。 21 # Page. 22 ![Page Image](https://bcdn.docswell.com/page/Y76WMZR57V.jpg) Azure SREエージェントはSREなのか 機能面からも読み取れる。厳密には SREエージェント ではなく SRE Copilot 22 # Page. 23 ![Page Image](https://bcdn.docswell.com/page/G75MZW8G74.jpg) その裏でPagerDuty SREエージェントではどうか 〜PagerDuty Advancedの紹介〜 引用：https://iret.media/193920 23 # Page. 24 ![Page Image](https://bcdn.docswell.com/page/9J29RQKDER.jpg) 直近ではこんな話も 引用：https://atmarkit.itmedia.co.jp/ait/articles/2605/20/news015.html#utm_term=share_sp ● 真に恐ろしいのは一度の失望をきっかけに顧客が競合へと乗り換え、二度と 戻ってこない『信頼の喪失』というロングテールな損失 ● AIが各種運用プロセスを自動化できる今 「限られたコストの中でシステムを維持する」だけの運用は、もはや価値を 失っていく。「これからは全員がビルダー（作り手）になるべきだ」 24 # Page. 25 ![Page Image](https://bcdn.docswell.com/page/DEY4DWNMJM.jpg) 役割毎にAIエージェントが分かれている 名前 説明 SREエージェント インシデントのトリアージと解決を直接的に支援する エージェント Scribeエージェント インシデント対応中のコミュニケーションと記録の自動 化に特化 Shiftエージェント オンコールシフトの管理とスケジュールの競合解決を担 うAIアシスタント Insights エージェント システム運用のデータから、予防的なアプローチと改善 案を提示 Assistantエージェント SlackやTeams内でエンジニアが直接対話するための、汎 用インターフェースとしての役割を持つ 25 # Page. 26 ![Page Image](https://bcdn.docswell.com/page/VJNY69X378.jpg) PagerDuty SREエージェントは役割ベースのアーキテクチャ システム運用は”誰が” ”何を” “どのように” “どこまで”担当するかが重要 今は自律型運用ではない。 システム運用者が複数のエージェントをオーケストレーションする。 システム運用におけるエージェントを役割で分割して自律型運用を実現する 26 # Page. 27 ![Page Image](https://bcdn.docswell.com/page/YE9PL28PJ3.jpg) in my opinion: SREエージェントはSRE Copilot（現在地） SRE Agent is “SRE Copilot” とはいえ、それが結論だとさみしいところがある。 「こういうケース（インシデントの状況）を分けて話せば使えるよ」 ということを経験ベースでいくつかお伝えします。 27 # Page. 28 ![Page Image](https://bcdn.docswell.com/page/GE8DX58XED.jpg) インシデントの対応は3つの状態で分割できる インシデント発生前/発生中/発生後 AIまたはサービスで対応することを考えると？ 28 # Page. 29 ![Page Image](https://bcdn.docswell.com/page/LELM8YRN7R.jpg) インシデント発生前 システムの「平常時の振る舞い」を機械学習ベースでベースライン化し、人間で は気づけない静かな異常を検知して予防 ● ● ● ● メトリクスやログの傾向分析による予兆検知（AIOps） 静的しきい値の動的最適化（不要なアラートの削減） カオスエンジニアリングのシナリオ生成支援 潜在的な設定ミスや脆弱性の継続的スキャン 29 # Page. 30 ![Page Image](https://bcdn.docswell.com/page/4JMY6NRQJW.jpg) インシデント発生前に使えるAzure ● Azure Monitor (Dynamic Thresholds) ○ インシデントの元になるアラートを点ではなく線で捉える ● Application Insights ○ パフォーマンス低下や例外の急増の自動検知 ● Microsoft Sentinel ○ ログの相関分析による不審な振る舞いの検知 30 # Page. 31 ![Page Image](https://bcdn.docswell.com/page/PJR9PDRK79.jpg) インシデント発生中 いかにMTTR（平均修復時間）を短縮するかが焦点になる。 アラートのノイズを削り、エンジニアの初動をアシストするのがAIの役割 ● アラートストームの抑制 ○ 複数アラートの相関分析とインシデントのグルーピング ● 分散トレーシングやエラーログからの根本原因分析（RCA）の自動実行 ● Runbookに基づいた一次対応の提案、または自動実行（これは補足） ○ 安全なバージョンへの自動ロールバックなど 31 # Page. 32 ![Page Image](https://bcdn.docswell.com/page/PEXQ31R5JX.jpg) インシデント発生中に使えるAzure ● Azure Monitor (Smart Groups) ○ 複数アラートの相関分析と1つのインシデントへの圧縮 ● Copilot for Azure ○ RCA、原因調査 ● Logic Apps / Automation ○ 一次対応の自動化 32 # Page. 33 ![Page Image](https://bcdn.docswell.com/page/3EK9Y2RRED.jpg) インシデント発生後 対応の経緯を構造化してドキュメント化し、再発防止策をシステムの運用プロセ スにフィードバック ● Slack、Teams等の対応ログやシステムのメトリクス推移からのタイムライン自 動生成 ● ポストモーテム（障害報告書）のドラフト作成 ● 類似インシデントを防ぐためのIaC（Terraformやマニフェスト）の修正案提示 ● アラートのルールの見直し（検知漏れや過検知のフィードバックループ） 33 # Page. 34 ![Page Image](https://bcdn.docswell.com/page/L73W948G75.jpg) インシデント発生後に使えるAzure ● Copilot for Azure / Security ○ ドキュメント化 ■ インシデント対応時のエラーログを収集、質問、要約 ● GitHub Copilot ○ 再発防止策の提示 ■ エラーログやアプリケーションコードから原因を特定 34 # Page. 35 ![Page Image](https://bcdn.docswell.com/page/87DKGQMNJG.jpg) AIエージェントによるシステム運用の理想と現実 理想と現実の折衷案を見つける必要が出てくる。 自律型運用 vs 伴走型運用 ● AIエージェントにインシデント対応を任せる → 責任の所在が迷子 ● 逆に任せないとなるとルールベースで泥臭く立ち回る必要がある。ジリ貧 ● ルールベースだとシステム運用のためのシステム運用が必要 アプローチ： この業務/システム運用は人間じゃなくてもいいよねと勇気をもって発言すること 35 # Page. 36 ![Page Image](https://bcdn.docswell.com/page/VJPK3LRNE8.jpg) 理想：完全自律型運用（Zero-Touch Operations） 障害対応において、AIエージェントが検知から原因特定、コードの修正、デプロ イ、そして事後レポートの作成までをすべて自己完結する世界観 現実の壁（ブロッカー） ● 権限移譲のリスク ● 説明責任の欠如 ● 未知のコンテキストへの脆弱性: 36 # Page. 37 ![Page Image](https://bcdn.docswell.com/page/2EVV4QRYEQ.jpg) 現実：伴走型運用（Human-in-the-Loop / Copilot） AIエージェントを「高度な判断力を持ったオペレーターのバディ」として位置づ け、最終的な意思決定の権限と責任はエンジニアが持つアプローチ ● AIの役割 ○ ダッシュボードからのメトリクス抽出、ログのパースと相関分析、既知のラ ンブックに基づく解決策の提示、実行コマンドのドラフト作成 ● 人間の役割 ○ AIが提示したコンテキストとアクションプランの妥当性評価、実行の承認 （Approve） 37 # Page. 38 ![Page Image](https://bcdn.docswell.com/page/57GL1WMWEL.jpg) 補足：AIにコマンドは打たせないほうが良い理由 ルールベースと不変 レイテンシの問題 可用性と安全性 決まったコマンドを打つだけな 推論時間を待つよりも、スクリプ LLM自体の可用性リスクや、 ら、ルールベースのアラート処 ト実行の方が圧倒的に早く、障 誤ったコマンドによる「二次災 理で十分 害復旧を妨げない。 害」を考慮すべき。 38 # Page. 39 ![Page Image](https://bcdn.docswell.com/page/4EQYD3RQJP.jpg) まとめ ● これまでの運用実績からシステム運用とAIエージェントの話 ● SREとはそもそも何なのかを振り返りつつ対応方法の違いを振り返り AIエージェントに関すること（Azure SREとPagerDuty、GitHub Copilot） ● （今のところ）SRE エージェントは支援 ○ 厳密にはSRE Copilot ● インシデント発生時、AIがどのような役割を担うかを解説 今のところシステム運用におけるAIは自律型ではなく伴走型である。 頼もしい相棒ではあるが、任せたままにはできない。 39 # Page. 40 ![Page Image](https://bcdn.docswell.com/page/KJ4WZ18Y71.jpg) 次回予告 ● .NETラボ 勉強会 2026年6月 ○ https://dotnetlab.connpass.com/event/390843/ 40 # Page. 41 ![Page Image](https://bcdn.docswell.com/page/LE1YRG2N7G.jpg) おわり 41