CyberAgentがDevin Automationsで進めるアラート調査自動化の要点

編集: グリットアーツ編集部

公開日：2026年9月27日

3行解説

ニュースの概要

CyberAgent Developers Blogは2026年9月18日、ピグ事業部のSRE担当者による記事として、Devin Automationsを使ったAIによるアラート調査の運用ポイントを公開しました。記事では、DatadogのアラートやError Reportingの通知をきっかけにDevinを起動し、Slackスレッドへ調査結果を返す構成を説明しています。対象環境はGoogle Cloud、AWS、Azure、オンプレミスが混在しており、Cloud LoggingやDatadogなどを横断して切り分ける運用です。

何が新しいのか

新しい点は、AIに「調査の入口」だけを任せるのではなく、観測データの定義と調査環境の事前整備まで含めて運用設計していることです。記事では、AIが判断を誤る原因として、ログ不足やメトリクス不足があると整理しています。そのため、ログ件数、リクエスト追跡、APM、Error Reporting、GitHubの変更履歴など、何をどこで見るかを先に決めています。さらに、DevinはVM上で動くため、毎回の初期セットアップを避け、通知後すぐ調査に入れる状態を用意した点も実務的です。

グリットアーツ編集部の分析

この事例で重要なのは、AIの性能そのものよりも、AIが迷わない前提条件を整えた点です。Datadog、Cloud Logging、Error Reporting、GitHubを横断して調べるには、権限、接続先、観測項目の整理が欠かせません。逆に言えば、情報が散らばったままでは、AIを入れても初動の品質は安定しにくいとみられます。人手の判断を減らしたい企業ほど、まず監視データの定義と調査導線を標準化する必要があります。

日本の現場で考えると

日本企業では、クラウド単独ではなく、オンプレミスや複数クラウドが混在しているケースが少なくありません。この構成では、AIエージェントに何でも見せるのではなく、どの監視基盤を起点にし、どのログまで参照させるかを決めることが重要です。特に、夜間・休日の一次切り分けを軽くしたい現場には向きます。一方で、復旧操作まで自動化すると影響範囲が広がるため、まずは調査専任で始める方が安全です。制作、EC、SaaSなど、障害時の初動が遅れると損失が大きい現場ほど、導入効果を見込みやすいでしょう。

導入・検討時に確認したいこと

• どの通知を起点にAIを起動するか。Datadog、Error Reportingなどの対象を絞れるか。
• AIに見せるログ、メトリクス、変更履歴の範囲をどう定義するか。
• Slackへの返答粒度をどうするか。一次報告だけか、根拠や棄却仮説まで含めるか。
• VMの初期セットアップを省き、通知後すぐ調査できる状態を維持できるか。
• 復旧操作や監視設定変更をAIに許可しない場合の運用分界をどう決めるか。

現時点で分かっていないこと

記事からは、Devin Automationsの具体的な設定手順や、どの程度の精度で調査が安定したかは分かりません。また、対象サービス数やアラート件数、導入前後の工数削減量も明示されていません。ほかのAIエージェントや自前実装との比較も、定量的には示されていません。

アラート調査の自動化は、監視ツールだけでなく権限設計やログ整備まで含めて考える必要があります。既存の運用基盤をどうつなぐかを整理したい場合は、保守・運用の観点から見直す価値があります。

出典: CyberAgent Developers Blog