AWS DevOps Agentで インシデント対応をAIに任せたい

2026/09/09 に開催された [SRE AI活用事例] 減らせ！TOIL削減大作戦！ の登壇資料です。
https://mixi.connpass.com/event/403987/

Transcript

1. AWS DevOps Agentで インシデント対応をAIに任せたい [SRE AI活⽤事例] 減らせ！TOIL削減⼤作戦！ @HonMarkHunt #BIZREACH_MIXI ©MIXI 1
2. 株式会社MIXI みてねプラットフォーム部 SREグループ マネージャー 本間 匡晃(ホンマークハント) ・6歳と3歳の娘がいます ・スニーカー収集・筋トレ・キャンプ ・子供の成長の次に 男磨きハウス2 を楽しみにしている @honmarkhunt @HonMarkHunt ©MIXI 2
3. サービス紹介 ©MIXI 3
4. 家族アルバム みてね(以下、みてね)はスマホで撮った⼦どもの写真や動画を 家族と共有し、コミュニケーションして楽しむ家族アルバムサービスです。 ©MIXI 4
5. 2015年4⽉リリース • • 7⾔語‧175の国と地域でサービスを提供 2026年8⽉に利⽤者数が3,000万⼈を突破 家族アルバム みてね 事業紹介 / Our Business(https://speakerdeck.com/familyalbum/our-business?slide=12) ©MIXI 5
6. みてね事業のMVV | Mission 世界中の家族のこころのインフラをつくる ©MIXI 6
7. みてねの組織構成 ©MIXI • 機能開発を⾏うドメインチーム(ストリームアラインドチーム) • 組織横断のプラットフォームチーム • SREが24/7のオンコール対応を受け持つ ◦ 『家族アルバム みてね』を⽀えるオンコールエンジニア制度 ◦ オンコール⼊⾨〜ページャーが鳴る前に、あなたが備えられること〜 7
8. みてねのシステム構成 • サービスはほぼAWS上で稼働 • Amazon EKSを⽤いたマルチクラスタ構成 『世界中の家族のこころのインフラ』を⽬指して”次の10年”へ (https://speakerdeck.com/kohbis/towards-the-next-decade-enhancing-global-service-reliability-through-sre?slide=24) ©MIXI 8
9. みてねSREの課題 組織‧サービスの拡⼤によるアーキテクチャの複雑化‧コードベースの拡⼤による認知負荷向上 SREのオンコールの1次対応が遅れることでユーザーの満⾜度‧信頼性が低下してしまう可能性 他にも考えていたこと ©MIXI • インシデントを全て無くすのは不可能 • しかし、オンコール時の切り分けを早くできればユーザーの満⾜度へ寄与することができる • そもそもオンコール対応が⾟い • 即時対応が必要ないもの(調⼦が悪いEC2を引いてしまった等)であればSREの調査を無くせると⾟くない 9
10. みてねSREの課題 組織‧サービスの拡⼤によるアーキテクチャの複雑化‧コードベースの拡⼤による認知負荷向上 SREのオンコールの1次対応が遅れることでユーザーの満⾜度‧信頼性が低下してしまう可能性 他にも考えていたこと • インシデントを全て無くすのは不可能 • しかし、オンコール時の切り分けを早くできればユーザーの満⾜度へ寄与することができる • そもそもオンコール対応が⾟い • 即時対応が必要ないもの(調⼦が悪いEC2を引いてしまった等)であればSREの調査を無くせると⾟くない Toil削減チャンス！ ©MIXI 10
11. AWS DevOps Agent • AWSが提供する⾃律型AIエージェント(フロンティアエージェント) ◦ re:Invent 2025で発表された、数時間〜数⽇単位の仕事を⼈の介⼊なしに⾃律的にこなすAIエージェント群 • アラートを起点にインシデントを⾃律調査し、根本原因分析と対応の提案まで⾏ってくれる • CloudWatch/Datadog/New Relic等のオブザーバビリティツールや、 GitHub、PagerDuty‧Slackと連携し、調査結果をSlackに届けてくれる ©MIXI DevOps Agent Security Agent FinOps Agent 役割 インシデント調査・根本原因分析・予防的改 善提案・オンデマンドタスク 自律ペネトレーションテスト・脅威モデリング・ コード/設計/レビュー コスト分析・最適化提案・コスト異常の自動調 査 プレビュー 2025年12月（re:Invent） 2025年12月（re:Invent） 2026年6月9日 GA 2026年3月31日 2026年3月31日(一部のみ) 未GA（プレビュー中） 料金 $0.0083/エージェント秒 ≒ 約 $30/時間 $50/タスク時間 プレビュー中は無料 時給($1ドル＝160円換算) 約4,781円 8,000円 0円(プレビュー中) 11
12. 改めてやりたいこと オンコール発⽣時にAWS DevOps Agentに1次調査を実施させて インシデント発⽣時のユーザー影響を最⼩にしたい その過程でオンコール時の調査が簡略化されToil削減もできると嬉しい SREは様々な領域で活動があり、ふとした時に目的・目標を見失ってしまうことがあるように思います みてねのSREではチームで取り組む目標に関しては、最終的にやることが同じであっても 事業目線、ユーザー目線の目標設定することを大切にしています ©MIXI 12
13. ⽬次 1. AWS DevOps Agentの導⼊ a. 概要 b. みてねでの導⼊アーキテクチャ 2. 実運⽤をしてみての感想 a. 良かった点 b. 課題点 3. 今後やっていきたいこと ©MIXI 13
14. 1. AWS DevOps Agentの導⼊ ©MIXI 14
15. Agent Space • • DevOps Agentのスコープと構成を定義する論理コンテナ この単位でエージェントが稼働し、調査対象のAWSアカウント‧連携ツール‧権限が定義されている。 ベストプラクティスによると「Agent Spaceの境界 = オンコールの責任範囲」で分割する ◦ • AWS DevOps Agent を本番環境にデプロイするためのベストプラクティス 複数のAgent Spaceを作る場合はきめ細かなアクセス制御を保つため、 専⽤AWSアカウントをプライマリにしてアプリケーション⽤のアカウントをセカンダリとして接続する 構成が公式ドキュメントで案内されている ◦ DevOps エージェントスペースとは 悩む点は2点 1. Agent Spaceの分割単位 2. DevOps Agentを設定するAWSアカウント みてねの事例を紹介します ©MIXI 15
16. みてねで採⽤した構成(1/3) Q1. Agent Spaceの分割単位 • みてねはSREがプロダクト全体のオンコールを持つ体制のため、チーム別分割は不要と判断 • 検証環境と本番環境でAWSアカウントがわかれているので計2つのAgent Spaceを作成 Q2. DevOps Agentを設定するAWSアカウント • DevOps Agent専⽤アカウントを新設し、2つのAgent Spaceを配置 • 調査対象の既存の検証環境と本番環境⽤のAWSアカウントには Agent Spaceを置かず、 各Agent Spaceにセカンダリアカウントとして接続 ©MIXI 16
17. みてねで採⽤した構成(2/3) • 連携ツール : GitHub, PagerDuty, Slack • アカウント作成‧Agent Space‧各連携はTerraformでIaC管理 ◦ • ©MIXI aws-samples/sample-aws-devops-agent-terraform New Relic, Grafanaは連携を⾒送り 17
18. みてねで採⽤した構成(3/3) これでオンコール時に DevOps Agentが自動で 調査してくれるように！ 調査結果は随時スレッドに書き込んでくれます ©MIXI 18
19. 2. 実運⽤をしてみての感想 ©MIXI 19
20. 良かった点 1. DevOps Agent Web appが便利 「DevOps エージェントウェブアプリとは」 より引⽤ (https://docs.aws.amazon.com/ja_jp/devopsagent/latest/userguide/about-aws-devops-agent-what-is-a-devops-agent-web-app.html) ©MIXI 20
21. 良かった点 1. ©MIXI DevOps Agent Web appが便利 • おなじみの対話型のチャットUIで、⾃然⾔語で調査を依頼できる • オンコールトリガーやインシデント調査以外にも広くAWSの調査を実施可能 21
22. 良かった点 2. • Support Caseがシームレスに作成できる DevOps Agentの調査は「Investigation」という構造化された単位で残る ◦ • ©MIXI 1インシデント = 1 Investigationが作られ、その中に調査の全過程が蓄積される Web app上のInvestigationからそのままAWS Supportへエスカレーションできる 22
23. 良かった点 2. • • Support Caseがシームレスに作成できる Support Case作成は地味にめんどくさい ◦ 必要な情報を収集し⼊⼒ ◦ サポートの⽅から追加の情報確認 ひょんなことからToil削減成功！ 必要な情報はDevOps Agentが収集済みなので⼿間0でケース作成可能 Agent用に専用のAWSアカウントを作成することが公式でも1つのパターンとして紹介されています。 What are DevOps Agent Spaces? 一方でこの構成を採用するとAgentが存在するアカウント上でSupport Caseが作成されるので、 「調査対象のリソースがあるアカウントで問い合わせしてください」と回答されてしまうことがあります。 以前はGitHubと連携できるのが1つの「AWSアカウント×リージョン」の組み合わせのみで、 2つ目以上のアカウントからは連携ができなかった。(ので専用アカウントを作るメリットがあった) しかし、こちらは現在解消済みなのでAgentを作成する際はアカウントについて一考しましょう。 ©MIXI 23
24. 改めて、やりたかったことのおさらい オンコール発⽣時にAWS DevOps Agentに1次調査を実施させて インシデント発⽣時のユーザー影響を最⼩にしたい 結局これは実現できたのか？ ©MIXI 24
25. 結論 ©MIXI 25
26. 結論 (まだ) できていません。 ©MIXI 26
27. Q. なぜか？ ©MIXI 27
28. Q. なぜか？ A. 俺の⽅が早いから ©MIXI 28
29. 課題点 • インシデント発⽣時のユーザー影響を少なくするなら、 1次調査の結論をオンコール担当者より早く出す必要がある。Toil削減の⽂脈でも同じ。 ©MIXI • 発⽣したオンコールとDevOps Agentの結論を出すまでの速度を計測しました • DevOps Agentが結論を出すまでの平均値は 約24分 調査開始まで 結論まで 1 40秒 15分17秒 2 33秒 12分41秒 3 24秒 34分23秒 4 36秒 20分44秒 5 32秒 23分13秒 6 35秒 25分02秒 7 37秒 29分51秒 8 33秒 27分04秒 調査開始まで 結論まで 平均 34秒 23分32秒 中央値 34秒 24分08秒 最短 24秒 12分41秒 最長 40秒 34分23秒 29
30. 課題点 • 24分あれば原因を特定してもはや解消まで終わってるケースがほとんど • 今の所⼈間の⽅がほとんどのケースで先に調査を終えています • ⼀⽅で速度では負けるが、⼈間が⾒落とす‧スルーしがちな事象も毎回調査され 結果が蓄積されていく網羅性と記録には⼀定のメリットを感じています なぜか調査開始とともに応援され始めるDevOps Agentの図 みてねは過去の改善の蓄積やランブックの整備により、未知のパターンのオンコール対応自体が少ない 速度は環境・連携ツール次第。あくまでみてねでの事例の参考値として捉えてください ©MIXI 30
31. 3. 今後やっていきたいこと ©MIXI 31
32. 今後やっていきたいこと 改善案1. Skillの活⽤ • 他のAIツールと同じく様々なコンテキスト情報をSkillとして保存しておくことができる • 導⼊時はWeb appのUIもしくはzipによるアップロードしか⽅法がなかったため、 メンテナンス性が悪く採⽤していなかった • 現在はGitHub repo経由でSyncして登録することができるようになった ◦ ©MIXI ⾃動同期はされないので都度UI上から⼿動でSyncするか、CIを構築する必要がある 32
33. 今後やっていきたいこと 改善案2. Directed Actionsの活⽤ • DevOps Agentの権限は基本的にはReadOnly ◦ • • まとめた調査結果をもとに⼈間が実施する必要は残り続けている 2026年8⽉のアップデートでDevOps Agentが変更操作を⾏える Directed Actionsが発表された ◦ 変更に関しては都度WebUIから承認が必要 ◦ 削除操作は⼀切⾏わない ◦ 他にもいくつか制約があるので 公式ドキュメント を確認してください 定型的なフローがあればSkillを整備した上でAgentが改善提案までしてくれるのは、 Toil削減の⽂脈でも活⽤できるポイントがありそう 「Working with directed actions」 より引⽤ (https://docs.aws.amazon.com/ja_jp/devopsagent/latest/userguide/working-with-devops-agent-working-with-directed-actions.html) ©MIXI 33
34. まとめ ©MIXI 34
35. まとめ DevOps Agentの導⼊ • • ⽬的 : オンコール時の1次調査のAI化によるユーザー影響の最⼩化とToil削減。 構成 : オンコールの責任範囲でAgent Spaceを分割。みてねはDevOps Agent 専⽤AWSアカウントを作成 検証‧本番環境⽤Agent Spaceを配置し、IaC（Terraform）で管理。 実運⽤の所感 • • 利点: ◦ Web appでの⼿軽な調査依頼 ◦ Support Case作成の効率化 ◦ ⼈間が⾒落としがちな事象の根本調査と結果の蓄積 課題: 結論が出るまでの速度 今後の展開 • • Skill活⽤: GitHub経由でランブックを連携し、調査精度と速度を向上。 Directed Actions活⽤: 承認プロセスを経て対応の実⾏まで任せ、⾃動化範囲を拡⼤。 ご清聴ありがとうございました ©MIXI 35