「AIを活用したインシデント対応の未来」のタイトルでLTをしました

こんにちは。Topotal 菱田です。

先日Youtrustが主催しているPRODUCT HISTORY CONFERENCE 2025でLTをしました。 イベントのコンセプトがAIが軸だったのでインシデント対応と組み合わせ、内容は「AIを活用したインシデント対応の未来」としました。

発表資料

speakerdeck.com

登壇資料を作る際にテキストで文章を書き起こしているので、今日のブログは書き出している内容を共有したいと思います。 共有する目的は、LTを作成する際にどのような観点を書き出すとよさそうかを知ってもらうことです。

では、本編をどうぞ。


タイトル : AIを活用したインシデント対応の未来

聴講者の状態

  • 発表前:障害対応に注力してしまって、恒久対応やそもそもの改善ってなかなかできないよね。そもそもインシデント対応辛いよね。AIの活用できそうだけど、どうやってやるといいんだろうね
  • 発表後:AIを活用すれば、障害対応がめっちゃ楽になる世界がくるのか〜

ストーリー

概略

よくある課題の提示 => 問題提起の具体化 => 解決方法の提示 && まとめ => 将来像の提示

要点単位の状態遷移

1. よくある課題の提示

疑問

それって共感できる問題・課題なのか?

疑問に対する回答

インシデント対応のプラクティスが浸透したことで、障害対応の属人化、障害対応フローが実行されない、障害対応中の情報共有が難しい、TTxのメトリクスの取得が難しい、、、、など具体的な課題感が出てきた それを解消するためのツールやAIの活用が進んでいる。AIの活用はインシデント対応では適用が一部にとどまっている。なぜだろうか?

キーメッセージ

なぜAIにインシデント対応が任せられないのか

ストーリー

プロダクト開発において、AIで解決できる領域が広がってきた。しかし、インシデント対応ではなかなか活用が進んでいない。それはなぜか。 現在、Topotalが開発しているWaroomが主に支援している部分は、事前準備や事後のドキュメントの自動生成が主。 Googleが提唱しているトラブルシューティングのプロセスに照らし合わせてみると、WaroomはTriage〜Test/Treatまでのインシデント対応プロセスにはAIが適用できていない。

SREBookChapter12-Effective-Troubleshooting
SREBookChapter12-Effective-Troubleshooting

AIの進化が進んでいる中で、任せることができないのはなぜ?

2. 問題提起の具体化

疑問

なんでAIが進化しているのに、インシデント対応では活用されてないの?

疑問に対する回答

直感的に、インシデント対応のプロセスを全部ひとでやるのも違うけど、全部AIに任せるのも何かおかしい。 任せきれない理由は、AIによる動作の結果が想定と異なることがあり、結果の影響がプラスにもマイナスにも働く。 マイナスに働いた時のコントロールができないことが任せきれない理由。

キーメッセージ

AIの結果による影響がコントロールできないのは困る

ストーリー

AIは、ソフトウェア開発の中にかなり浸透しているといえます。その中で、なぜインシデント対応で活用されないのか。 直感的に考えると、インシデント対応こそAIがやってくれるならAIに任せたい作業ですが、それができない。 理由は、AIの結果が想定と異なることがあり、コントロールがきかないからではないか。 特にインシデント対応は常にビジネスへの影響を考えなければならず、おいそれと人はAIにインシデント対応を任せることができない。

3. 解決方法の提示

疑問

それは、どうやったら解決できる?

回答

AIの活用において、結果の影響が少ないところから始めるのが一般的。 なので、インシデント対応も同様に少ないところから始めればよい。 影響が小さいインシデントは、重大度でいうと低いものと言える。 重大度が高いとインシデントの責任が現場から経営層に委譲されてしまうので適用しにくい。 さらに、AIが行なったプロセスに対して承認を挟み込むことで、AIに作業をまかせ人は承認(責任)を持たせるだけにできる。

キーメッセージ

ビジネスへの影響が限られた重大度の低い部分でAIを活用する。さらに人が責任を持てる構造にする

ストーリー

おいそれと人はAIにインシデント対応を任せることができないのであれば、ビジネスへの影響が少ない範囲をAIに任せていくのがよい。 一般的なインシデント対応では、Triageのタイミングでインシデントの重大度を定めている。 重大度は、ビジネスへの影響に応じて、緊急度が即応なのか、営業時間でよいのか、対応するためのオンコールは誰宛なのか、どこまで組織を巻き込むのか、などの指標に当たる。以下の表は一例である。

レベル 定義(影響度) 緊急度 オンコール対応 コミュニケーション
CRITICAL (P0) 全体または大多数の顧客に対して重要機能が停止、深刻な体験劣化が生じている 即時対応が必要(24h365d、即着手) 対応可能なすべての関係者にページング 経営幹部に通知。全顧客向けの公開コミュニケーションを検討
HIGH (P1) 大多数の顧客に対して明確に不便を感じさせる劣化が生じている 迅速な対応が必要(24h365d、15分以内着手) 該当エンジニアチームにページング 関連エンジニアチームのリーダーに通知。影響を受けた顧客へのコミュニケーションを検討
WARNING (P2) 一部の顧客に対して顧客体験の軽度な劣化が生じている 営業時間帯に他の業務よりも優先して対応 営業時間内のみページング 関連エンジニアチームのマネージャーに通知。重要顧客のみ対応検討
INFO (P3) 顧客体験に目立った劣化がないか、非常に軽微な影響が生じている 通常業務と並行して勤務時間内に対応 ページング不要 関連エンジニアチームのマネージャーに通知。顧客向け通知は不要

引用:インシデントの重大度(Severity)とは?組織的なインシデントレスポンスに役立つプラクティスのご紹介 - Topotal Blog

この指標の中で、重大度の低いINFOやWARNINGに対して、AIを活用するのが現実的である。 さらに、AIが行う修正に対して人による承認を入れることで、AIの活用がより広い範囲になるだろう。 実際、Topotalではこういったことを考えWaroomの開発を進めている。

4. まとめ

疑問

何が言いたかったんだっけ?

回答

近い将来、インシデント対応は人とAIの協働が実現される。 現状では影響範囲が限られた部分でAIを活用することで、インシデント対応の負担を減らせる。 特に多く発生する重大度の低いものをAIに任せるだけでも楽になる。

キーメッセージ

近い将来、「つらい」インシデント対応はなくなる

ストーリー

影響範囲が限られた部分でAIを活用することで、インシデント対応の負担を減らせる。 特に多く発生する重大度の低いものをAIに任せるだけでも楽になる。 近い将来、「つらい」インシデント対応はなくなる。

5. 人間とAIの協働するインシデントレスポンス(MCPの動画)

この章は時間がないので、動画を流さずブースにきてねという。

疑問

本当にそんな未来はくるの?

回答

動画をみせながら話をする。

www.youtube.com

Topotalでは、すでにWaroom MCPを利用したインシデント対応の研究開発を進めている。

この動画では、重大度が低いSentryのエラーを検知し、エラー内容をAIに問い合わせ、調査、修正、プルリクエストの作成、対応報告のドキュメント生成までを行う。 承認というプロセスだけを人が対応している。


いかがでしたでしょうか。

このドキュメントの発表時間は、動画のデモがない状態の内容で5分10秒〜15秒くらいです。5分なので少し駆け足の発表でした。

資料作りの要諦は発表前と発表後の状態を定義し、聴き手の疑問を解決していく階段を作っていくことと思っています。

みなさんの参考になれば幸いです。