SREの仕事を自動化する際にやっておきたい5つのポイント

AEON TECH HUB #23でお話しした資料です
https://aeon.connpass.com/event/379256/

Transcript

1. SREの仕事を自動化する際に やっておきたい 5つのポイント PagerDuty Product Evangelist Kazuto Kusama @jacopen
2. Kazuto Kusama @jacopen Product Evangelist @PagerDuty Japan Organizer @Platform Engineering Meetup Founder @Cloud Native Innovators Association 先週末は延べ20時間くらいClawdbot触ってました おかげでこの資料が完成したのは 30分前です
3. 2025年 AIエージェント元年
4. 2026年 システム運用でも AIエージェントが普及
5. AI Agent for system operations - PagerDuty SRE Agent - Azure SRE Agent - AWS DevOps Agent 運用現場の「AIチームメイト」として機能する時代へ
6. PagerDuty AI エージェント - インサイトからアクションまで - エージェントがより良く、早く、スマートに業務を⽀援 PagerDuty AI エージェントに含まれるエージェント⼀覧 SRE エージェント 運⽤上の問題を特定して 分類し、関連する過去の インシデントなどの重要 なコンテキストを浮き彫 りにし、対応者に解決を 早めるための推奨事項を 提⽰することにより、業 務の中断によって引き起 こされるビジネスリスク を軽減し、顧客体験を向 上 Insight エージェント 組織内で使われているツー ル全体のデータを分析し、 戦略的な運⽤判断に必要な 情報を特定し、運⽤⼿順と ビジネスの効率を継続的に 改善 Shift エージェント オンコールシフトを動的 に調整して、スケジュー ルや空き時間の競合を未 然に防ぎ、インシデント 担当者のカバレッジを確 保することで、迅速なイ ンシデント解決を促進 し、運⽤コストの削減と 顧客影響の最⼩化を図る Scribe エージェント Web 会議での会話内容を リアルタイムに整理、分析 し、必要なアクションを特 定し、内容をサマリーして 提供することにより、イン シデント解決の迅速化と関 係者への情報共有を促進 インシデント 対応プロセスの改善 On-call 対応 スケジュールの調整 インシデント 対応中の右腕役 インシデント対応の 筆記担当者 ⽇本語対応済み ⽇本語対応予定 ⽇本語対応予定 ⽇本語対応済み
7. AIエージェントができること インシデント対応の高度化 - 過去の類似インシデント・変更履歴の自動提示 - 原因候補の分析・復旧策の提案 アラートの自動トリアージ - ノイズ低減・重要シグナルの抽出 - 関連アラートの自動グルーピング 復旧作業の自動化 - スケールアップ、再起動、ロールバック - 承認ベースの自動スクリプト実行
8. AIを入れれば全て解決？
9. そんな魔法はない
10. インシデントも AIで対処すればいい なんて考えは 甘え アーキテクチャ Conference資料より
11. 「システム障害で 混乱がおきる ので、AIで何とかしよう 」 (インシデントの元となる ) システム障害が起きると社内に混乱が起きるから、それを防ぐ為に AIを活用し たい。 ＝技術的な問題だから、技術で対応しようとしている CIO 一体 どうなってるんだ! 現状を 教えてください！ 今何が起きてるの！ スココン スココン アラート 動かない！ ユーザー担当 別チーム ユーザー システム障害で社内に混乱が起きている様子
12. 混乱が続くとどうなるか
13. 「システム障害で 混乱がおきる ので、AIで何とかしよう 」 (インシデントの元となる ) システム障害が起きると社内に混乱が起きるから、それを防ぐ為に AIを活用し たい ＝技術的な問題だから、技術で対応しようとしている CIO 一体 どうなってるんだ! 現状を 教えてください！ 今何が起きてるの！ スココン スココン アラート 動かない！ ユーザー担当 別チーム ユーザー システム障害で社内に混乱が起きている様子 混乱を起こしているのは誰？
14. 障害は技術的に、混乱は 構造的に生まれる • 技術的な障害（Failure）はシステムの 設計不備や未知の条件から発生 する。 • しかし“混乱”（Chaos）は、情報の流れ・ 意思決定の経路・責任の所在が曖昧な 組織構造から生じる。 • つまり障害そのものよりも対応中の構造が 組織全体を危機に陥れる。 CIO 一体 どうなってるんだ! 現状を 教えてください！ 今何が起きてるの！ スココン スココン アラート 動かない！ ユーザー担当 別チーム ユーザー 障害 = 技術の問題 混乱 = 組織アーキテクチャの問題
15. SREの仕事を自動化する際に やっておきたい 5つのポイント
16. ① 「見えていること」を前提とする オブザーバビリティは AI以前の必須条件 オブザーバビリティができていないと、 AIは "何も見えていない" - Traces - Metrics - Logs 観測可能にするには計装（ instrumentation）が必要で、コードが traces/metrics/logs を 出す必要がある
17. 例: PagerDuty SRE Agent が参照するデータ - 700以上のインテグレーションからのイベント /アラート - Grafana, New Relic, CloudWatch などからのログ・メトリクス - Confluence, GitHub からのドキュメント - 過去のインシデント履歴 オブザーバビリティがない場合 AIエージェントにとっての判断材料がない → 何もできない
18. ② アラートを減らしてから自動化 LLMは 「ノイズを消す魔法 」ではない アラート設計が悪いと、 AIは賢く混乱する
19. ② アラートを減らしてから自動化 ❌ 誤解 「アラートが多すぎて困っている」 ↓ 「AIを入れればノイズを消してくれる」 ⭕ 現実 AIは「パターン認識」と「相関分析」が得意 ↓ そもそもの設計が悪いと、 AIは "賢く" 間違った判断をする ↓ 誤ったアラートを誤って関連付ける
20. 例: PagerDuty AIOps Intelligent Alert Grouping - MLで関連アラートを単一のインシデント に集約 - チームの対応パターンから 継続的に学習 AIは魔法ではなく、人間の行動から学ぶ
21. 障害は技術的に、混乱は 構造的に生まれる • 技術的な障害（Failure）はシステムの 設計不備や未知の条件から発生 する。 • しかし“混乱”（Chaos）は、情報の流れ・ 意思決定の経路・責任の所在が曖昧な 組織構造から生じる。 • つまり障害そのものよりも対応中の構造が 組織全体を危機に陥れる。 CIO 一体 どうなってるんだ! 現状を 教えてください！ 今何が起きてるの！ スココン スココン アラート 動かない！ ユーザー担当 別チーム ユーザー 障害 = 技術の問題 混乱 = 組織アーキテクチャの問題
22. ③インシデント対応フローの確立 (ICS) 責任の所在 と 意思決定の経路 を明確にし 情報の流れ をコントロールする インシデントコマンダー (IC)を 中心とした命令指揮系統を構築 ICはインシデント対応の指揮者。 重大インシデントを解決に導く ことを目的とし、意思決定 を行う。 このフローがない場合 アラート検知 → ？？？ AIは「次に何をすべきか」を提案できず、 各人がバラバラに動く インシデントコマンダー 作業担当 CIO ユーザー担当 別チーム ユーザー
23. 平時(peacetime)と戦時(wartime)を分離 インシデントコマンダー 作業担当 CIO ユーザー担 当 別チーム ユーザー 平時は「ビジネスを回すこと」が最重要。戦時は「インシデントの解決」が最重要。 目的が異なるので、区別して組織構造を作る必要がある 平時: 社長が一番偉い 戦時: ICが最も位が高い (インシデント解決の文脈において )
24. 平時(peacetime)と戦時(wartime)を分離 インシデントコマンダー 作業担当 CIO ユーザー担 当 別チーム ユーザー 平時は「ビジネスを回すこと」が最重要。戦時は「インシデントの解決」が最重要。 目的が異なるので、区別して組織構造を作る必要がある 平時: 社長が一番偉い 戦時: ICが最も位が高い (インシデント解決の文脈において )
25. ④ インシデント中にコミュニケーションできる文化 インシデント対応 = 技術対応だけではない インシデント対応とは • システム復旧 • ステークホルダーとの適切なコミュニケーション • 組織の混乱を防ぐこと "Technical incidents can create chaos when stakeholder notifications are not effectively managed" — PagerDuty Stakeholder Communications Guide
26. 👔 経営層(エグゼクティブ ) 必要なのは「ビジネスインパクト」 • いくらの損失が出るのか • 法的リスクはあるのか • メディア発表は必要か 情報がなければ、適切な判断を下せません 📣 広報・マーケティング SNSでの炎上は秒単位で拡散します。 沈黙は「隠蔽」と受け取られかねません。 適切なタイミングでの発信が、ブランドイメージを 守る鍵となります。 🎧 カスタマーサポート 顧客との最前線にいる人たちです。システムが止ま ると、怒った顧客からの電話やチャットが殺到しま す。 彼らにとって凄まじいストレスであり、 離職の原因にもなり得ます。 技術面だけでなく、各ステークホルダーの不安を解消しなくてはいけない 
 💼 セールス・営業 商談中の顧客から「御社のサービス信頼して大丈 夫ですか？」と言われたらどうでしょう。 たった一度の障害が、数ヶ月かけて築いた 信頼関係を崩壊させ、契約を白紙に戻す可能性が あります。
27. リエゾン リエゾン / Communication Leadの重要性 Customer Liaison Internal Liaison PagerDuty OpsGuides Communications Lead Google SRE Incident Management Guide ステークホルダーへの定期アップデート＆連絡窓口として明確に役割定 義されている 人間とのコミュニケーション は、インシデント対応の 必須要素 AIはこの役割を「支援」できるが、「代替」はできない
28. AIはコミュニケーションを「支援」する Scribe Agentの例 - 会議のリアルタイム文字起こし - ディスカッションポイント・アクションアイテムの自動抽出 - ステークホルダーへの報告書作成を支援 しかし、 AIにはできないこと - 顧客への謝罪の言葉選び - 経営層への影響度説明の「ニュアンス」 - 営業との商談影響の「調整」 「判断」と「合意形成」は人間にしかできない
29. インシデントコマンダー ICを中心とした、意思決定と指揮を 行う密な連携 レスポンダー 書記 リエゾン ステークホルダーとのコミュニケーションパス CIO Dev Support Sales 内部では密に、外部とはブロードキャスト型で連携
30. ⑤ その場しのぎではなく、次を楽にする視点 ✅ 直すだけで終わらない ✅ 次回どうするかを考える ✅ 手順や判断を残す Blameless Postmortem ❌ 「誰が悪かったか」を追求 → 問題が隠蔽される → 同じ失敗が繰り返される ⭕ 「何が起きて、どうすれば防げるか」を追求 → 問題がオープンに共有される → 組織の学習につながる
31. SRE Agentのメモリを活かす トリアージの精度向上 — 過去のパターンを認識 診断の加速 — 変更イベントと症状を関連付け ランブックの更新 — 成功した対処を次回に活かす
32. まとめ ① 「見えていること」を前提とする ② アラートを減らしてから自動化 ③インシデント対応フローの確立 ④ インシデント中にコミュニケーションできる文化 ⑤ その場しのぎではなく、次を楽にする視点をもつ AIエージェントは「チームメイト」 チームメイトが活躍できる環境を整えるのは人間の仕事
33. AIの導入と一緒に 体制作りもやっていきましょう
34. AI運用勉強会やってます 2/4 AI運用勉強会 #2 開催 AI運用勉強会は、AIをシステム運用に活かすための知見を共有・ 学習する場です。 開発でのAI活用が当たり前になった今、運用でも AIの重要性が 高まっています。しかし、運用では AIの誤動作が即座にユーザー 体験へ影響するため、開発とは異なるアプローチが必要です。 本勉強会は、そうした AI運用の知見を蓄積していくことを目的とし ています。