この記事では、Mackerel SRE チームが取り組んでいる、AI エージェントフレームワークを活用したアラート調査の自動化事例をご紹介します。アラート発生時の初動調査を AI に任せることで、運用の負担をどう軽減し、チームの動きがどう変化したのか。実装の全体構成や、精度を高めるための具体的な工夫、そして運用を通じて見えてきた新たな課題について解説します。
こんにちは。SRE の 
id:heleeen です。
アラートは時を選ばず発生しますが、対応には監視設定の背景理解や調査方法の把握が必要で、それらがないと時間がかかってしまうといった課題があります。一方で、慣れてくるといつも同じ調査をしていることもあります。この定型的な初動調査を AI に任せることができないか、という考えからアラート調査への AI 導入に取り組んでみました。
この記事では、「突撃！となりのSRE - 現場で試したAI活用事例」にて、「アラートと運用知見から始める、自律的なインシデント調査への第一歩」というテーマで登壇した際の内容をベースに、その後の改善や変化についてご紹介します。
- アラート調査の大変さ
- アラート調査の初動パターン
- インシデント調査の自律化へ
- 利用した技術：Mastra
- 全体構成の紹介
- 運用していくために行った改善
- AI がアラート調査をするようになってからの変化
- まとめと今後の展望・課題
アラート調査の大変さ
アラート調査には、特有の性質がいくつかあります。
時を選んではくれない
アラートは予測不可能なタイミングで発生します。作業中でも会議中でも深夜でも、容赦なく届きます。そのたびに進行中の作業や睡眠を中断して対応することになります。
事前知識が必要
アラートが発生したときに、ログを見るべきか、メトリックを確認するべきか、それとも設定を見直すべきかなど、初動の調査方法を知らないと対応に時間がかかってしまいます。
また、監視ルールは過去の障害や運用知見をもとに設定されています。その背景を理解していないと、なぜこのアラートが発生したのか、本当に対応が必要なのかの判断が難しくなってしまいます。
慣れてしまえばいつも同じ調査をしている
何度もアラート対応を経験すると、初動でやることはだいたい同じパターンの繰り返しとわかってきます。トイル（手作業による定型業務）になりがちな作業なので、自動化して AI を活用しやすい仕事と考えられます。
アラート調査の初動パターン
アラート調査の初動では、以下のような定型的な作業を繰り返し行い、原因が把握できたら対応しています。
- アラートが発生したメトリックの推移を確認する
- エラーログや関連するトレース情報を調査する
- Runbook（アラートごとの対応手順ドキュメント）を参照し、過去の対応手順や運用知見を確認する
- 依存するコンポーネントや影響が発生しうるコンポーネントなど、他のメトリックを確認する
このように、調査で確認したいものは基本的に毎回同じであることから、アラート発生時の状況把握で AI に頼ることができないかと考え実現してみました。
インシデント調査の自律化へ
AI を活用してアラート調査を自動化できれば、初動調査の時間短縮ができることを期待していました。一方で、AI による調査結果の精度を最初から高いものにするのは難しいとも考えていました。そのため、アラート調査の結果の精度はそれほど高くないことを許容し、まず動く状態を作り徐々に改善していく方針にしました。
目指した方向性
AI にアラートを自動調査させるにあたり、具体的には以下の方向性を最初に作るものとして定めました。
いつでも AI による調査ができる状態を作る
AI によるアラート調査が、自分たちのサービス運用にどの程度有用なものかを体験し、将来的にはユーザーへの機能提供にも活かすことを考え、まずは AI による調査ができる状況を作っておくことを目的としました。
また、調査したいアラートを人間が指定する手間もなくしたかったため、アラートの連携による自動調査も最初から想定していました。
最初の調査対象はログと Runbook
アラートが発生したときはログを見ることが多いので、ログを AI が見られるようにしました。また、Runbook にはこれまでの障害調査やアラート対応の知見がまとまっているため、Runbook も AI が利用できるようにすることを目指しました。
利用した技術：Mastra
今回の実装では、Mastra1 という TypeScript ベースの AI エージェントフレームワークを採用しました。
Mastra にはコンソールがあり、コンソールからプロンプトの実行ができます。
Workflow を実行すると、実行結果を JSON 形式で取得できます。
Mastra では Amazon CloudWatch Logs に保存しているログと Amazon S3 に置いた Runbook を参照できるようにしました。また、調査結果は Slack へ投稿し、Mastra へアクセスしなくても手軽に見られるようにしました。
全体構成の紹介
AI を活用したアラート調査システムの実際の全体構成を、実行パターンごとに紹介します。
Mackerel のアラートを連携して実行する場合
Mackerel のアラート発生時には、以下の流れで自動的に調査が実行されます。
- Mackerel でアラートが発生
- アラートを EventBridge の通知チャンネルで連携し、Amazon Simple Queue Service へエンキュー
- エンキューをトリガーにして Lambda が起動し、Mastra へリクエストしてアラートを調査
- 調査結果を Slack へ投稿
SQS を経由することで、Lambda のタイムアウトを超える可能性がある長時間の調査にも対応できるようにしています。
プロンプト実行の場合
Slack ボット経由でプロンプトを入力すると、以下の流れで処理が実行されます。
- Slack ボットへプロンプトを入力
- Amazon API Gateway でリクエストを受け取り SQS へエンキュー
- アラート連携と同様に、エンキューをトリガーにして Lambda が起動し、Mastra へリクエストしてプロンプトで指示された内容を調査
- 調査結果を Slack へ投稿
「この状況について調査して」といった自然言語での指示に対して調査を実行できます。
運用していくために行った改善
AI を活用したアラート調査を実装していく中で、いくつかの工夫を行いました。
ワークフロー進行状況の可視化
AI の調査がどこまで進んでいるかをスレッドに逐次投稿することで、今何をしているかがわかり、安心して結果を待つことが多いです。
必要なツールのみ実行させる
AI エージェントにすべてのツールを常に実行させると、エージェントはツールの調査結果を正しいと重要と判断しがちなので、正しくない調査結果が返ってくることがありました。そこで、プロンプトで「必要な調査のみを実行する」ように指示し、Mastra のワークフローの仕組みで機械的に調査をスキップしています。
たとえば、ログ調査や Runbook は必要な場合のみ実行するように制御を行うことで、関係ない結果を返しにくくなりました。
3 行サマリと詳細の分離
AI の調査結果は、常にその量に目を通すのは難しいほどに情報量が多いものでした。そこで、ぱっと把握できるように3行のサマリを投稿し、スレッドには詳細を投稿するようにしました。
サマリには、問題の概要や推奨されるアクションを簡潔にまとめています。素早く状況を把握でき、必要に応じて詳細を確認できるようになりました。
わからないことはわからないと言わせる
AI は確実でない情報を確信的に返答することがあります。調査結果の妥当性が低い状態が続くと、利用されなくなってしまいかねません。これを防ぐため、プロンプトでわからないことはわからないと言わせるようにしました。
下記はそのプロンプトからの抜粋です。
調査結果をまとめています。ユーザー入力にある、解決すべき問題について分析してください **分析における厳格なルール:** ...... 解決対象の問題を特定できなかった場合は、「提供された情報だけでは、解決すべき問題の特定ができません。」という旨と特定できなかった理由を回答し、終了する。
これにより、AI が不確実な推測で調査結果を返すことを防ぎ、信頼性を保っています。
アラート大量発生時の調査を抑制
障害によっては同じ内容のアラートが大量に発生する場合もあります。不要な調査をさせないために、同じアラートの調査が続いたときには調査しないようにしました。
AI がアラート調査をするようになってからの変化
アラートの通知ではなく AI のアラート調査の結果の通知で動き出すことも増えました。さまざまなログと Runbook を人間が確認するよりも AI のほうが素早いと感じています。一方で、不要なログが出ないようにしたり Runbook をメンテナンスしたりしていないと結果の精度が下がってしまうので、自分たちが注力するポイントが移動したようにも思います。
調査結果をとりあえず待つ暮らしに変わった
これまでは、アラートが来るたびに何かを中断して調査していましたが、手間であった定型調査の実施に時間が取られることが減り、自分の作業時間が増えたように感じます。
また、Mastra の実行環境を用意したことで、自分たちのシステムと連携した AI の利用基盤が入手できたため、いろいろなことを AI に任せやすくなりました。
ログの出力改善とRunbook 充実への意欲向上
AI がログを解析するようになったことで、不要なエラーログを解消したいという意識を持つようになりました。一方で、アラートとは関係のないエラーログが偶然調査結果に出たことで、別件の不具合に気づけたということもあります。
また、AI が Runbook を参照することで、Runbook の重要性を再認識しました。今後は、障害対応後に AI に Runbook を書かせてより効率的に再発防止ができればと考えています。
不慣れなコンポーネントでも調査のヒントを得られる
人間はすべてのコンポーネントに詳しいわけではありません。不慣れな領域のアラートでも、AI が初動調査のヒントを提供してくれることで、対応の糸口が見つけやすくなりました。
まとめと今後の展望・課題
この記事では、AI を活用したアラート調査の自動化について、Mackerel SRE チームでの実装内容と効果をご紹介しました。
AI による完全自動化ではなく、人間が最終判断と責任を持ち、AI が定型作業を肩代わりする役割分担を維持しながら、継続的に改善を進めていきたいと考えています。
＼Mackerelを無料で体験／
Mackerelは、サーバーやアプリケーションの状態を可視化し、システム全体の状況を把握できるサービスです。
トライアルでは、メトリックやアラート、ダッシュボードなどの機能を実際の画面で確認しながら、Mackerelによる監視や可視化を体験できます。
14日間無料で、全機能をご利用いただけます。
