AIに障害切り分けを全部やってもらった。 が。 。 。 The SRE Backlog: 蔵出し事例共有会 / 2026.06.30 株式会社estie 徳原 晋一 / SRE 

自己紹介 徳原 晋一 SRE / Platform Engineering Observability（O11y）改善、プロダクト基盤づくり、必要に応じてセキュリティと か 最近の関心：運用をAIでどうスケールさせるか X: @wh_choco © 2026 estie, Inc. 2 

AIに障害切り分けを全部任せてみた 効いた所と、変わらなかった所がわかっ てきた © 2026 estie, Inc. 

今日話すこと 1. 作ったもの: 障害の一次切り分けを全部 AI (AWS DevOps Agent) に任せる仕組み 2. 効いた所と変わらなかった所 3. 次に取り組むもの 仕組みそのものの詳細は ブログ にまとめています © 2026 estie, Inc. 4 

作ったもの 

作ったもの: アラートを起点に一次切り分けを自動化 アラート（Datadog Monitor / ECS の異常終了 など） ↓ EventBridge に通知経路を集約 DevOps Agent が一次切り分けを自動実行 ↓ 調査完了 Slack のスレッドに「調査の過程 ＋ 根拠」を投稿 これまで: 人 通知が来たら、自分で順に確認: CloudWatch（Metrics / ログ） Datadog（APM） GitHub（直近の更新） いま: AI アラート起点で AIが一次切り分け 原因が明確な障害は 調査工数ほぼ0 それ以外も 大幅に削減 © 2026 estie, Inc. 6 

こだわった2点 1. 調査の「根拠」を残す 原因候補だけでなく、何を見てそう判断したか も必ず出力 確認した Datadog Monitor / AWSリソース・ログ / GitHub のコード・PR 確度の高い判断と、弱い推測を切り分ける AIは "それらしい答え" を返す。=> 追跡可能にしないと真偽が不明 2. 無駄に調査を走らせない 同種アラートの連続発生は調査をスキップして無駄なコストを発生させない 通知はするが、最初の調査スレッドへリンクを張る © 2026 estie, Inc. 7 

① アラートが届くと、調査が自動で走り出す © 2026 estie, Inc. 8 

② 数分後、根拠つきの調査結果が返ってくる © 2026 estie, Inc. 9 

使ってみて、わかったこと 

効いた所：対応の「当たり前基準」が上がった ① すべてのアラートに、淡々と対応できるように これまで：忙しいとスルー / 復旧したら放置 → いまはAIが必ず一次切り分け コンテナ異常終了などは高精度で、修正に即つなげられる ② SRE以外が見ても、調査を追える 調査の流れ・使ったログ / コードへのリンクが残る（SREの調査フローを SKILL 化） 「どこに何があるか」の認知負荷がなくなり、属人性も下がった © 2026 estie, Inc. 11 

変わらなかった所：自動化できたのは「真ん中」だけ 気づく 人間 アラートを見るアンテナ はいまも人間頼み 調べる AI が自動化 今回できたのは ここだけ 直す 人間 修復までつなげるかは 見る人間次第 両端の「気づく」 「直す」は、いまも人間。 —— せっかくの変革期、全部 AI にやらせてみよう。 © 2026 estie, Inc. 12 

次は修復の自動化へ 一次切り分けの先 => 調査結果を起点に、修正まで繋げたい 例：調査結果を入力に、Claude Code / Devin に修正PR作成を依頼 ただし、プロダクト側と連携の設計が重要そう すべての障害でコード修正が要るわけではない（外部依存の一時失敗、瞬間的な逼 迫…） 雑にやると「レビューすべきノイズPR」が増えるだけ PRを作るべき状況の判断基準 と、どういう修正ならPRをAIがApproveしてMergeまで 可能かを設計すること © 2026 estie, Inc. 13 

まとめ 開発がAIでスケールするなら、運用も同時にスケール させたい でないと、組織のボトルネックが開発から運用に移るだけ SRE / Platform の 運用知をAIに移植 し、調べるを自動化 効いた所：認知負荷↓ / 当たり前基準↑ 変わらなかった所：気づく、直す は、まだ人間 境界線を見極めながら、人間に残った 直すの自動化 へ estieでは絶賛採用を進めてます！カジュ面もやってるよ! © 2026 estie, Inc. 14