PLAY の AI 活用事例_ AIによる障害一次調査の自動化

Transcript

1. PLAY の AI 活用事例 障害の一次調査を、 AI に任せる。 Slack のエラー通知を起点に AI が調査し、 エラー通知 AI が一次調査 元のスレッドに報告 直せるものは修正 PR まで作る仕組み 株式会社PLAY 修正 PR（場合により）
2. WHY 障害の対応や調査における課題 障害の対応や調査が属人化してしまっていた 課題 1 課題 2 課題 3 通知の見分けが経験者頼 み 調べ方が人の頭の中にあ る 詳しい人に対応が集中する 影響 その人が通知に張りつく 影響 いないと調査が進まない 影響 負担が一部の人に偏る イメージ：チームの質問も調査も、いつも同じ人に集まる このエラー、調べたほうがいい？ どこから見ればいい？ 前にも起きてた？ 詳しい人 属人化をなくすために、 一次調査（最初の原因調査）を、手順書どおりに AI が行う仕組み を作った 02 PLAY の AI 活用事例｜障害調査の自動化
3. WHAT 通知を選び、 AI が調べて返す。直せるものは修正 PR まで いつ 通知が届いたら 調べる必要があれば すること ① 選別 → 課題 1 を解く 調べる必要がある通知かを見分ける ② 調査 → 課題 2・3 を解く AWS DevOps Agent が、手順書（ SKILL）どおりに調べる ③ 報告 調べ終わったら 元のスレッドに結果を返す。 Issue は必要なときだけ ④ 修正 直せる原因なら Issue を作り、 AI が修正 PR まで作る。取り込むかは人 どうするかを 判断し、対応するのは人 AWS DevOps Agent：障害の原因を調べる AWS の AI エージェント（自分で道具を使いながら作業を進める AI） 03 PLAY の AI 活用事例｜障害調査の自動化
4. ① 選別 FILTER 調べなくていい通知は、 AI に回さない 例はイメージ 01 02 03 04 不要な通知を除く 同じエラーはまとめる 呼び出し回数に上限 残りを AI が調べる 「夜間バッチが 成功しました」 時刻や ID だけ違う 同じエラー 調べずに、 一言返して終了 1 件にまとめ、 前の Issue を案内 AI が調べるのは、 本当に調べるべき通知だけ 04 PLAY の AI 活用事例｜障害調査の自動化 1 日の上限を 超えた通知 使いすぎを防ぐため、 調べずに知らせる 初めて見る エラー AI が 一次調査へ
5. ② 調査 SKILLS & TOOLS プロダクトごとの手順書 (SKILL)と、社内の道具を AI に持たせる 手順書（どう調べるか） 道具（何で調べるか） ログ・アラーム 調べる順番 監視データ Issue にする基準 よくあるノイズの見分け方 AWS DevOps Agent コード 社内のナレッジ 課題管理 過去の事例 手順書に沿って、 道具を使って調べる Slack への返信 手順書は STREAKS・GALLERY・TYPELINE など、自社のプロダクトごと に用意 05 PLAY の AI 活用事例｜障害調査の自動化
6. ② 調査 LEARNING 手順書は、 AI に実際に調べさせて磨く 1. 手順書だけを渡す セキュリティアラートの手順書で 4 回実施 テスト用の別の AI エージェントに、 実際のアラートを調べさせる 同じアラートの調査で、 AI が道具を呼び出した回数 1 回目 → 2 回目 2. 迷った所を見つける 空振りした検索や、手順にない回り道 3. 手順書を直して、もう一度 同じ条件で、テストし直す 結論が正しくても、 たどり方まで確かめて直す 06 PLAY の AI 活用事例｜障害調査の自動化 繰り返す 26 → 19 回
7. ARCHITECTURE 全体像：通知を受けて AI を呼び、結果を Slack に返す ※ 詳しくは別資料「 MCP 基盤」 07 PLAY の AI 活用事例｜障害調査の自動化
8. ③ 報告 REPORT 調査の経過と結論が、元のスレッドに届く スレッドに届く報告 イメージ（内容は架空） 1 通知を見た人が、そのまま結果を読める 元の通知 [ERROR] DB timeout が続いています AI 調査を開始しました 対象：sample-api 2 AI 元のスレッドに届く 原因の候補を特定しました 途中経過も届く 開始・候補・完了の 3 回で報告 接続数の上限が足りない可能性 AI 調査が完了しました 結論（有力）：アクセスが増えると接続数が上限に達する 直し方：上限と待ち時間を見直す Issue：#123 08 PLAY の AI 活用事例｜障害調査の自動化 3 確からしさも添える 結論に「確定・有力・推定」を付ける
9. ③ 報告 SCREENSHOT 実際の画面： Slack のスレッドに、開始から完了まで届く 実際の Slack スレッドの画面 09 PLAY の AI 活用事例｜障害調査の自動化
10. ④ 修正 AUTO FIX いま：原因を特定できたら、修正 PR まで AI がつなぐ PR（プルリクエスト＝コード変更の提案）：人がレビューしてから、本番のコードに取り込む フロントエンドが原因と特定できた場合（手順書に組み込み済み） AI が調査 Issue を作る AI が修正 修正 PR は、もう一つの取り組み「AI コードレビュー」の自動修正が作る。取り込むかは人がレビューして決める 通知から修正まで、 人は「判断」に集中できる流れ へ 10 PLAY の AI 活用事例｜障害調査の自動化 人がレビュー
11. WHAT'S NEXT これから：デプロイが原因なら、自動で切り戻す Blue/Green デプロイ：新旧 2 つの環境を用意し、通信の向き先を切り替えてリリースする方式 構想中 1. アラート 2. AI が判断 3. 自動で切り戻す 4. スレッドに報告 エラー率が上がる 直近のデプロイが原因か 向き先を前の版に戻す 人が確認して次を決める 切り戻しのイメージ 新しい版（Green） エラー率が上がった 向き先 利用者 11 PLAY の AI 活用事例｜障害調査の自動化 デプロイが原因なら、前の版に戻すのが早い。切り 戻す条件は人が決め、切り戻しは自動で行う 前の版（Blue） ここへ戻す あわせて進めること 効果を数字で追う ねらい 選別のルールを育てる
12. SUMMARY まとめ：選ぶ・調べる・返す・直す、そして磨く ① 選別：AI に回す前に選ぶ ② 調査：手順書（SKILL）と道具（MCP サーバー など）を持たせる ③ 報告：結果は元のスレッドへ ④ 修正：直せるものは修正 PR まで ＋ 手順書も磨き続ける 判断と対応は人。 通知を「読む」仕事から、結果を「判断する」仕事 12 PLAY の AI 活用事例｜障害調査の自動化 へ