every Tech Blog

株式会社エブリーのTech Blogです。

トップ > AI > Devinでアラート初動対応爆速計画

Devinでアラート初動対応爆速計画

AI 挑戦WEEK Devin

はじめに

開発本部でデリッシュキッチンのアプリウェブグロース向けの開発を担当しているhondです！
今回は先日行われた第6回挑戦weekで私たちのチームが行ったDevinによるSentryアラートの改善について紹介します。
本記事はDevinの基本的な概念や使い方についてある程度理解している読者を対象としています。Devin自体の詳細な説明は省略し、実際の業務での活用事例に焦点を当てて解説します。
なお、今回の取り組みを検討する際に、私たちの目標と完全に一致したSMARTCAMPさんの記事を発見し、非常に参考になりました。私たちの環境や要件に合わせてカスタマイズを行いながら、同記事のアプローチを参考にさせていただきました！

前提

技術スタック

本記事で扱う技術スタックは以下の通りです。

項目 技術
エラー監視 Sentry
通知 Slack
AI開発支援 Devin
図表生成 Mermaid
バージョン管理 GitHub
インフラ AWS
アプリケーション Nuxt.js (フロントエンド)、Go (バックエンド)

監視の構成

デリッシュキッチンでは現在アプリケーションのエラー監視ツールとしてSentryを用いています。このSentryにはNuxt.jsで動作するデリッシュキッチンのウェブアプリケーション、およびGoのバックエンドサーバーで発生したエラーが送信される仕組みとなっています。Sentryに送信されたエラーはIntegrationを介してSlackのアラートチャンネルに通知されます。

現状の課題

このアラート運用に関して、主に以下の課題がありました:

  • 緊急度がわかりづらい：アラートの重要度が不明瞭で、対応の優先順位付けが困難
  • 解決に必要な情報が不明瞭：一部のエラーではSentryに送られる情報が不足しており、特にスタックトレースがない場合に問題解決に必要な情報を特定するのが困難
  • 調査手順が不明：AWSコンソール、Sentry、アプリケーションコード、Athenaなど、複数のリソースを横断して調査する際の明確な手順が確立されていない。
  • 放置されているアラートがある：これにより、開発者の心理的負担が増加。
  • アラート箇所の担当が不明瞭：どのエラーがどの開発チームの担当か不明確。

Devin選定理由

今回の課題解決において、私たちがDevinを選定した理由は大きく2つあります。

1. マルチRepository対応の容易さ

事前に他のメンバーがCursorやClaude Codeの検証を社内勉強会で行いました。しかし、どちらもRepositoryを跨いだ調査において以下の課題が発生しました。

  • 複数Repositoryの設定に追加作業が必要
  • 設定完了後もRepositoryを横断した処理の解釈が期待値を下回る

Devinでは、Workspace内に必要なRepositoryをcloneするだけで設定が完了し、フロントエンドとバックエンド、インフラのコードを横断した調査が効率的に行えました。
例えば、インフラのコードを解釈してフロントエンドがAWS上でどこに位置するかを理解し、どのバックエンドサーバーと関係があるかを意識したレスポンスを行えていました。

2. 自律型AIとしての運用効率

Devinの自律型特性により、以下の運用メリットを実現できました。

  • 並行処理: エンジニアが行うエラー発生時の一次対応と並行してDevinがエラー調査を自動実行
  • 履歴の可視化: 調査プロセスがDevinセッション内に記録され、チーム全体で共有可能
  • 手順の標準化: 人的要因に依存しない一貫した調査品質を担保

構成

最終的に構築したSentryアラート自動分析システムの構成は下記の通りです。

手順

  1. Devinの起動とSentryアラート情報の取得
  2. Devin Playbookの実行
    1. 関連情報の取得
    2. 分析
    3. 追加情報の取得
    4. 図表の作成
  3. Slackへ出力

Playbook

Sentry APIにCurlコマンドでアラートの情報を取得して、下記の分析結果を出力してください。

調査手順として以下の4ステップを順番に実施すること：

---------------

## 1. Sentry APIを叩いてレスポンスを取得


Sentry APIは、下記コマンドを実行してください。アラート全体はissue, イベント詳細はissue and event を叩いてください。secretはSENTRY_API_TOKENを参照してください。
issue:"""
curl https://sentry.io/api/0/organizations/{organization_id_or_slug}/issues/{issue_id}/ \
-H 'Authorization: Bearer {sentry_api_token}'
"""
issue and event:"""
curl https://sentry.io/api/0/organizations/{organization_id_or_slug}/issues/{issue_id}/events/{event_id}/ \
-H 'Authorization: Bearer {sentry_api_token}'

## 2. 対象となるGit Repositoryの特定

エラーのスタックトレースや関連情報から、問題が発生しているRepositoryを特定します。フロントエンド（Nuxt.js）、バックエンド（Go）、インフラ（Terraform）のいずれかを判断し、適切なRepositoryに焦点を当てます。

## 3. 関連するGit Repositoryが他にないか調査

特定されたRepository以外にも、エラーに関連する可能性があるRepositoryがないかを調査します。例えば、フロントエンドエラーがバックエンドAPIの変更に起因する場合や、インフラ設定の変更が影響している場合などを考慮します。


## 4. エラーの詳細に関する調査と結果の出力

下記「分析結果フォーマット」に従い、必要な情報を調査してください。

### 4-1. インフラ構成図やアーキテクチャ図が必要な場合は出力

エラー箇所や原因、全体像を把握できるよう、A. AWSのインフラ構成図, B. システム概要図 の2つを添付してください。

出力方法は以下の通りで、A, Bそれぞれに対して順番に実行してください。

1. mmdファイルを出力
(mmdファイル名はA: infra.mmd, B: system.mmd とする)
2. 次のコマンドを実行：mmdc -i <mmdファイルパス> -o <出力ファイル名(PNG)>
(出力ファイル名はA: infra.png, B: system.png とする)
3. 出力画像を添付


### 4-2. 関連Commitの検索

gh コマンドまたはgit コマンドを使用して、アラートの根本原因となるコードがどのcommit, PRで追加・変更されたのかを特定してください。

-------------------------

実装は行わずに、「分析結果フォーマット」「コード提示ルール」に従ってレポートを出力してください。

分析結果フォーマット:"""
📕エラーの基本情報確認
・エラータイプ
・環境
・発生頻度
・影響範囲
・発生時間(yyyy-mm-dd HH:MM:SSの形式、JST変換必須)
・初回(yyyy-mm-dd HH:MM:SSの形式、JST変換必須)
・最終(yyyy-mm-dd HH:MM:SSの形式、JST変換必須)
🧑‍⚕️ 障害レベル判断
・🚨緊急度高：即時対応必要（サーバーダウンへの影響など）
・🟡緊急度中：チケット切って今週中に対応（特定条件下でのエラー、ユーザー影響なし）
・🔵緊急度低：チケット切って時間ある時に対応（軽微な不具合、パフォーマンス低下）
🔬 エラー原因判定
・システム側の問題（バグ、設定ミス、リソース不足など）
・外部要因（攻撃的リクエスト、外部サービス障害など）
🦎 関連のあるCommit,PR
・根本原因となるコードがどのcommit, PRで追加・変更されたのか
🧑‍💻 エラーの再現方法
・ローカル環境や開発環境でエラーの再現方法の提示
🚒 対応策策定
・一時的対応と恒久的対応の区別
・攻撃的リクエストの場合のセキュリティ対策
"""

コード提示ルール：

関連コードを示す必要があれば、以下のようにコードとGitHubのパーマリンクを含める形で出力してください

[delishkitchen_file_name](https://github.com/delishkitchen_file_name#L92-L98)

\```
          Sentry.withScope(function (scope) {
            scope.setTag('method', method)
            scope.setTag('url', path)
            scope.setTag('query', queryString)

            Sentry.captureException(err)
          })

\```

---------------

この手順に従って段階的に調査を進めること。

You only need to look in the following repos: {backend_repository}, {infra_repository}, {frontend_repository}

以降、詳細について解説します。

1. Devinの起動とSentryアラート情報の取得

Devinの起動にはSlack workflowを用いました。DevinとSlackを連携することで、@DevinでDevinをSlackのスレッドやチャンネルで会話を開始できます。これにより、同時にセッションも開始されます。そのため、今回は解決したいSentryのメッセージに:help-me-devin:とリアクションすることでそのスレッドに下記の文章が出力されるようにしました。!sentryanalyzerは前述のDevin Playbookのマクロとなっています。

@Devin
!sentryanalyzer

@user_name によって依頼されました。
依頼者はDevinのレポートが終わり次第、sleep と入力してDevinを休ませてあげてください。

2. Devin Playbookの実行

手順1までの処理でDevin sessionの起動とSlackメッセージの紐付けが完了しているため、ここから実際にDevinの処理が開始されます。

2-1. 関連情報の取得

次に下記操作で関連する情報の取得を行います。

  • Sentry APIの実行
  • 対象となるGit Repositoryの特定、関連するGit Repositoryが他にないか調査

Sentry APIは事前にDevin SecretにSentry API Tokenを追加しているのでそれとSlackのメッセージからSentry issue_idを取得してRetrieve an IssueとList an Issue's Eventsを実行してissueの詳細を取得します。
Repositoryの特定、調査は事前にDevin's Workspaceに紐付けてあるRepositoryを探索するようにしています。

2-2. 分析

次にこれらの情報をもとにエラーの原因の分析を行わせます。ここまででSentryの詳細と対象のコードの目星がついているのでそれをもとに分析を行わせています。
分析の内容としては最終的な出力に含まれるSentryをもとにした発生頻度などのエラーの基本情報、障害レベル、エラーの原因、エラーの再現方法、対応策になります。

2-3. 追加情報の取得

2-2の結果をもとに原因となるcommitの特定をghコマンドを使って取得します。

2-4. 図表の作成

エラーの理解を深めるため、Mermaidを使用してAWSインフラ構成図とシステム概要図を自動生成します。これにより、エラーが発生している箇所とシステム全体の関係性を視覚的に把握できます。

  • インフラ構成図（infra.mmd → infra.png）: AWSリソース間の関係性とデータフローを表示
  • システム概要図（system.mmd → system.png）: アプリケーション層とインフラ層の相互作用を表示

3. Slackへ出力

2までの情報をもとにPlaybookに記述されている下記の形で情報を整理し、スレッドに返信を行ってもらいます。

📕エラーの基本情報確認
・エラータイプ
・環境
・発生頻度
・影響範囲
・発生時間(yyyy-mm-dd HH:MM:SSの形式、JST変換必須)
・初回(yyyy-mm-dd HH:MM:SSの形式、JST変換必須)
・最終(yyyy-mm-dd HH:MM:SSの形式、JST変換必須)
🧑‍⚕️ 障害レベル判断
・🚨緊急度高：即時対応必要（サーバーダウンへの影響など）
・🟡緊急度中：チケット切って今週中に対応（特定条件下でのエラー、ユーザー影響なし）
・🔵緊急度低：チケット切って時間ある時に対応（軽微な不具合、パフォーマンス低下）
🔬 エラー原因判定
・システム側の問題（バグ、設定ミス、リソース不足など）
・外部要因（攻撃的リクエスト、外部サービス障害など）
🦎 関連のあるCommit,PR
・根本原因となるコードがどのcommit, PRで追加・変更されたのか
🧑‍💻 エラーの再現方法
・ローカル環境や開発環境でエラーの再現方法の提示
🚒 対応策策定
・一時的対応と恒久的対応の区別
・攻撃的リクエストの場合のセキュリティ対策

結果

運用してみた結果

実際に運用してみて以下の効果を確認できました。

  • Sentryアラートの一時対応についてはDevinに任せられるようになった
  • アラート発生から約3分で初期調査〜原因特定まで完了するようになった
  • フロントエンド・バックエンド・インフラの各Repositoryを跨いだ調査が自動で実行されるため、調査漏れがなくなった
  • Mermaidで生成される図表が分かりやすく、エラー箇所の把握が圧倒的に楽になった

個人的には、特に調査の一貫性が保たれるようになったのが一番良いポイントだと感じています。人によって調査の深さにばらつきがあったのが、Devinを使うことで毎回同じレベルの調査が担保されるようになりました。
これによりアラート対応のハードルが下がったので、属人化も防げるのではないかと考えています。

運用してみて見えてきた課題

一方で、いくつか課題も見えてきました。

  • AWSのログやモニタリング情報と連携した調査はまだできていない
  • GitHubのパーマリンク出力や関連リポジトリの把握で、結果にばらつきが出ることがある
  • 複雑な指示を一度に出すより、段階的に指令を出した方が精度が上がる傾向がある

特に3つ目については、最初は全部まとめて指示していたのですが、段階的に指示を出すことで明らかに結果の品質が向上したので、運用のコツとして覚えておきたいポイントでした。

まとめ

私自身、普段CursorやClaude Codeを使う際はAIとの会話を往復することを前提に雑なプロンプトを投げたりするので、自立できるように十分なプロンプトを与える必要がある点で自立型AIエージェントの扱いに苦労しました。Playbookのようなテンプレート機能があるので、繰り返しを伴うタスクでは効力を発揮することは分かりつつも、普段の業務で使うイメージは少しわきにくかったです。
その点、アラート対応は決まった動きをすることが多いので、今回のPlaybookに加えてアラート対応が得意なメンバーの普段の動きを共有いただくことで、さらに精度のいい対応ができるのではないかと感じました。
また、この実装を行った後にDevin MCP Marketplaceが公開されたので、これを用いてさらにコンテキスト量を増やすことで性能がどうなるかは今後試してみたいです。
ここまで読んでいただきありがとうございます。Devinでアラート初動対応を爆速化しようとしている方の参考になったら幸いです。