Rethinking Incident Response: Context-Aware AI in Practice

Rethinking Incident Response: Context-Aware AI in Practice 株式会社 Topotal /
Ryota Yoshikawa ( @rrreeeyyy ) SRE NEXT 2025 | Ryota Yoshikawa ( @rrreeeyyy ) 1

Ryota Yoshikawa @rrreeeyyy CTO @ Topotal, Inc. SRE NEXT 2025
| Ryota Yoshikawa ( @rrreeeyyy ) 2

SRE NEXT 2025 | Ryota Yoshikawa ( @rrreeeyyy ) 3
× Diamond Sponsor

引用: https://x.com/mirakui/status/1943481221498933390

\ 半数以上が SRE, SRE 経験者!! / +3 名採用予定!

SRE のプロフェッショナルを、今すぐチームに。事業成長を続ける SRE の仕組みづくりをプロフェッショナルが並走サポート

SRE NEXT 2025 | Ryota Yoshikawa ( @rrreeeyyy ) Why
We Built Waroom © 自分のキャリアのスタートが 24h/365d のチームだっ¢ © インシデントレスポンスやオンコール対応にたくさん触れてき¢ © インシデントレスポンス領域の課題認| © ⁩ インシデントレスポンスやオンコールはつらいという認識が強l © 現状つらいところはつらいのだけど個人的には楽しいところも多l © サービスの信頼性という側面を考えると非常に重 © 特に SRE のコアの考え方がもっと適用可能⁩ な領域だと考えてい ¥ ソフトウェアエンジニアリングを行っているこx ¥ データドリブンな意思決定を行っているこx Ê ⁩ →こういった課題を解決するために IR SaaS が必要だと考えている 14

SRE NEXT 2025 | Ryota Yoshikawa ( @rrreeeyyy ) Incident
Response: Survey View ¿ DORA / SRE Report 等のレポートも毎年インシデント対応関連の記載がある © ¿ DORA (2018~2024y ¿ MTTR | Failed-Deployment Recovery Time が常に指標にある (2018~y ¿ Elite ランクでは MTTR が 1h 未満などの基準がある (~2024y ¿ 復旧時間短縮は従業員バーンアウト率低下と統計的に有意(2021,2022y ¿ SRE Report (2025y ¿ インシデント件数とストレス係数の相関が掲Á ¿ 小規模チームでも 23 % は月 10 件程度の障害が発生してい ¿ ポストモーテム・改善フェーズでの孤立がストレス増幅要Y →インシデントレスポンスが開発チームやSREの成熟度を測る指標として重要 15

Response: Frontline View á ⁩ 数年前と比べると認知も広がり少し良くなってきたという感覚はあÃ È Incident Command System (ICS) のようなプラクティスが普及してき´ á 一方で以下のような課題は未だに残っていると感じÃ È 精神的負担の大きインシデントレスポンスは「つらい」「難しい」という認識が強 È 組織展開の難し一部のプロはインシデント対応が出来るが会社全体に広げるのが困¸ È ICS を適用することの難し ICS は素晴らしいフレームワークだが組織に適用するのがやや難し基本的に大きい組織・インシデントを想定した作りになっていÃ 小さいインシデントやそこから発展・判断するケースでは？ 16

Response & AI Ö 前述のような課題を解決するために AI / LLM を活用するケースが増えてき£ Ö 「難しい」「つらい」「大変」「職人芸」の部分を AI で支援すÚ Ö 例えば 2025/07 段階の Waroom では次のようなことが出来Ú Ö インシデント情報のサマライズ・ポストモーテムの自動生Í Ö 一方で AI / LLM の領域はどんどん進化を遂げていÚ Ö Model Context Protocol (MCPÞ Ö AI が様々なリソースにアクセスして情報を取得・更新可能になっ£ Ö Coding Agent (Claude Code, Devin, GitHub Copilot Agent, ...Þ Ö AI がタスク分解→コード生成→テスト実行→PR まで自律的に可能ã Ö → Incident Response 領域でもこれらを活用してより「楽に」なれそR Ö → AI と Incident Response 領域の現在地と今後はどうなっていくのか？ 17

Response / SAE Levels Map 自動運転レベル人の役割(運転) AI の役割(IR) IR レベル L0: No Driving Automation 完全手動運転なし IR0 L1: Driver Assistance 運転支援通知・記録補助 IR1 L2: Partial Driving Automation 部分的支援判断支援・提案 IR2 L3: Conditional Driving Automation 条件付自動運転実行・監視責任も AI IR3 L4: High Driving Automation 高度自動運転完全実行 (特定領域) IR4 L5: Full Driving Automation 完全自動運転あらゆる状況で AI IR5 出典: SA E J301 6™ “Levels o f Driving Automation ” ( SA E International , 2021) 18

Response / SAE Levels Map 自動運転レベル人の役割(運転) AI の役割(IR) IR レベル L0: No Driving Automation 完全手動運転なし IR0 L1: Driver Assistance 運転支援通知・記録補助 IR1 L2: Partial Driving Automation 部分的支援判断支援・提案 IR2 L3: Conditional Driving Automation 条件付自動運転実行・監視責任も AI IR3 u 今現在は IR0 ~ IR1, IR2 ぐらいまでは実現されてきていB u MCP, Coding Agent の力で IR2~IR3 相当の実現可能性が出てき6 G IR3 相当に行くためには AI に任せられる安全な操作の定義が必要 19

Response: Level IR 2+ 20 ® MCP や Coding Agent を用いて AI が対応の支援・提案・一部作業まで担z ® e.g ® 監視起因やユーザサポート起因からインシデントを起e ® Sentry MCP や Datadog MCP などで障害の原因を推f ® GitHub MCP で直近のコード変更履歴を取s ® Claude が推測された原因や特定された変更履歴から修正コードを生w ® GitHub MCP を用いて PR 化を行z ® 人間が PR のレビュー・本番デプロイを行z ® インシデント対応状況の逐次報告も MCP を用いて AI が行z ® 調査状況に応じて重篤度の更新やコマンダーの推薦・アサインも行z ® オンコールを受けた時に重要な重篤度の判断をアシストしてくれる

Response: Level IR 2+ Demo 21

` Waroom 上の対応ステータス・対応状況の更Y ` Slack に自動で連携される

対応後は自動的にインシデント詳細がまとめられます

Response: Toward IR3 33 ú 紹介したデモ以外の要素にも様々な MCP Server が公開され続けてい ú Amazon ECS, EKS, Serverless, CloudWatch & Application Signals, RDS, .. ú Google Cloud Run, GKE, Firebase, .. ú →AI がほぼすべてのリソースのコンテキストを入手して操作可能にな ú 一方で AI のインシデントレスポンスの「安全性」「精度」は大きな課q ë Claude くんにローカル環境壊されそうになったこと、ありますよね ë 今だと本番サーバのオペレーションは任せられない雰囲v ë コード生成に関しては莫大なデータセットがあって上手くいきがX ë 実際のオペレーションや障害緩和策はデータセットが少ないがX ë いい精度を出すのが今のところはコード生成に比べると難しい

SRE NEXT 2025 | Ryota Yoshikawa ( @rrreeeyyy ) Waroom:
Experimental Tracks 34

Experimental Tracks - 1 Agent とのインシデントレスポンスの  可能性についてモックレベルで検討中 35

Experimental Tracks - 2 ローカル MCP サーバを実装してインシデントレスポンスの体験がどう変わるかを検証 36

Experimental Tracks - 3 実際にアプリケーションで使えるように Remote MCP Server の実装を開始 37

Experimental Tracks - 4 í 複数人でのインシデント対応で AI を上手く活用可能なようにすº ¶ 現行の構成だと 1 人 1 人が AI と対話して個別に障害対応をしてい í 過去インシデントやポストモーテムを AI が検索できるよう MCP を拡張é ¶ AI が過去の対応やポストモーテムを参考に対応を進められる状態 ¶ AI が自身でインシデント対応をし学びを溜めていく状態を目指した ¶ インシデント情報を特定の場所に溜めて参照できることの価値を高めた í 障害緩和手順・復旧手順のナレッジp ¶ コード生成は莫大なデータセットがあるため上手く行きやす ¶ 障害緩和・復旧手順についてはデータセットが少なく上手く行きづら ¶ 社内の既知の障害であれば AI で対応が容易だが未知の障害では難し ¶ 障害緩和・復旧のナレッジを上手く集められないかS í オペレーションを AI に任せたときの安全性をどう担保していくか 38

SRE NEXT 2025 | Ryota Yoshikawa ( @rrreeeyyy ) Conclusion
¯ インシデントレスポンスの重要性と個人の課題感を整 ¡ 開発チームやSREの成熟度を測る指標として重 ¯ インシデントレスポンスと AI の現在地と将来図を整 ¡ MCP, Coding Agent の力で IR2~IR3 相当の実現可能性が出てき ¯ 現状の AI で可能なインシデントレスポンスの形態(IR2+)を提案・デk ¡ 生成 AI と共にインシデント対応が行える世界になってきたことを示し ¯ Waroom で検討しているインシデントレスポンスの方向性を共G ¯ つらいインシデント対応を楽に、学びに、そしてゼロにを引き続き目指 ¯ インシデント情報を特定の場所に溜めて参照できることの価値を高めたい 39

SRE NEXT 2025 | Ryota Yoshikawa ( @rrreeeyyy ) !!We
are hiring!! https://jobs.topotal.com/ ¯ 今日の話を聞いてインシデントレスポンスを SaaS で良くしたくなった i ソフトウェア・生成 AI の力でインシデントレスポンスを「楽にy i こういうアイデアがある、こうしてみるのはどうか？という話も歓 ¯ 様々な業界・領域の SRE のリアルな課題に挑戦したい i 業界・領域・会社それぞれに特色や挑戦があって面白いで¢ ¯ 様々な業界・領域の SRE の課題を実際に見て汎化して解決してみたい i OSS 化, SaaS 化, 内製ツール化など様々な選択肢で解決しましょうまずはカジュアル面談からで良いのでぜひ話しましょう!! 40

SRE NEXT 2025 | Ryota Yoshikawa ( @rrreeeyyy ) !!ブースを出しています!!
スポンサーブース入ってすぐ左のD-1 発表に対する意見・感想もぜひ聞かせてください!! 本発表に関係する Waroom のデモもやっています 41

Rethinking Incident Response: Context-Aware AI ...

Rethinking Incident Response: Context-Aware AI in Practice

More Decks by rrreeeyyy

Other Decks in Technology

Featured

Transcript