Sentryエラー調査をDevinに丸投げして生産性・開発体験向上した話

はじめに
従来のSentryエラー対応フロー
- 手動調査の流れ
- 課題点
Devin × Sentry × Slack 自動調査構築手順
- 全体アーキテクチャ
導入後の成果
まとめ

はじめに

こんにちは！MyReferフロントエンドエンジニアの佐藤です。
フロントエンド開発を行っていると、Sentryからのエラー通知が日々届きます。
通知からSentryエラー画面にアクセスし、様々な情報を読み解き、影響範囲の把握と原因を推測して対応方針を決める...
このプロセス全てを人間の手動作業により、10 ~ 15分程度かけて完了させた頃には、数分前に思いついていたベストアプローチを忘れているでしょう🫠
そんな致命的なコンテキストスイッチコストを削減し、開発生産性・開発体験を向上させたく、DevinによるSentryエラー調査の半自動化に取り組みました。

従来のSentryエラー対応フロー

Devinによるエラー調査フロー導入前はSentryエラーが発生すると以下のような流れで対応していました。

手動調査の流れ

1. Slackで通知を確認

専用チャンネルにエラー通知が届く
エラーメッセージとURLを確認

2. Sentryで詳細を確認（5分）

SentryのWebUIにアクセス
エラーの詳細画面を開く
スタックトレースを読み解く
発生頻度・影響ユーザー数・ブラウザ・OSなどを確認

3. 原因の推測（5分）

スタックトレースから該当コードを特定
リポジトリで該当ファイルを開く
最近の変更履歴（git log）を確認
再現性・類似エラーを確認

4. 対応方針の決定（5分）

緊急度の判断（即対応 or バックログ）
修正方法の検討
チームへの共有

合計所要時間: 10-15分/件

課題点

1. コンテキストスイッチのコスト

開発中に通知が来ると、手を止めてエラー調査に切り替える必要があります。単純に工数が割かれるだけではなく、差し込みの対応に追われ、開発体験が下がる要因になっていました。

2. 調査の属人化

エラーの種類によって、誰が調査するかで精度や速度、対応方針にバラつきが出ていました。

3. 深夜・休日のエラー対応

深夜にクリティカルなエラーが発生しても、翌朝まで初動調査が始まりません。影響範囲の把握が遅れることで、問題が大きくなるリスクがあります。

これらの課題を解決するため、Devin AIによる自動調査の仕組みを構築することにしました。

Devin × Sentry × Slack 自動調査構築手順

全体アーキテクチャ

1. エラー発生 → Slack通知

Sentryが検出したエラーは、Slackの専用チャンネルに通知されます。
※ 設定方法は割愛

2. スタンプ押下でワークフロー起動

担当者がエラー通知に専用の絵文字でリアクションすると、Slackワークフローが自動的に起動します。

ワークフローの設定内容

トリガー: 絵文字リアクション
アクション: スレッドでメッセージに返信する
メッセージ内容: @Devinメンション + プロンプト

（参考: Slackワークフロー設定ガイド）

3. Devinに調査依頼

ワークフローが下記メッセージをスタンプリアクションしたメッセージスレッドに送信します。

クリックでプロンプト詳細表示

@Devin

こちらのSlackメッセージ内にあるSentryのissue URLを確認して、エラーの原因調査と報告を行ってください。
PRの作成は不要です。

調査結果・原因をこのスレッド内に返信してください。

# Sentry エラートリアージ

## 概要

Sentryで検知されたエラーの調査・分析・対応を体系的に行い、適切な報告と対応策を策定する

## 手順 (Procedure)

### 1. 初期情報収集

1. ユーザーからSentry Issue URLを確認する（未提供の場合は質問して取得）
2. Sentryエラー詳細ページにアクセスし、「JSON」リンクをクリックしてJSONビューを表示
3. エラーの基本情報を収集：
   - エラータイプ
   - 発生頻度と時間間隔
   - 初回発生時間と最終発生時間
   - 影響を受けるユーザー数
   - 発生環境（本番/開発）

### 2. 詳細情報分析

1. エラーメッセージとスタックトレースを確認
2. JSONビューから以下を必ず確認：
   - `breadcrumbs`: ユーザー行動履歴とリクエストパラメータ
   - `request`: URL、HTTPメソッド、ヘッダー情報
   - ユーザー情報（id、email）
   - ブラウザ・デバイス情報
3. 関連するコミットや最近のデプロイ履歴を調査
4. 同時期の関連エラーや警告を確認

### 3. 障害レベル判定

以下の基準で緊急度を判定：
- **緊急度高**: サーバーダウン、500エラー頻発、重要機能への影響、リリース直後の大量エラー
- **緊急度中**: 一部機能の不具合、特定条件下でのエラー、回避策が存在
- **緊急度低**: UIの軽微な不具合、パフォーマンス低下、影響範囲が限定的

### 4. 原因分析

1. エラー発生箇所のコードを確認
2. 以下の原因パターンを検討：
   - **システム側**: バグ、設定ミス、リソース不足、依存関係の問題
   - **外部要因**: ユーザー入力、攻撃的リクエスト、外部サービス障害
   - **外部スクリプト**: xxx
3. 攻撃的リクエストの特徴を確認：
   - 短時間での大量リクエスト
   - SQLインジェクション、XSSパターン
   - 自動化されたリクエストパターン

### 5. 対応策策定

1. 即時対応が必要な場合の一時的対応を検討
2. 恒久的対応策を策定
3. 必要に応じてSentry Issueステータス更新を判定

### 6. 報告書作成

指定されたSlackフォーマットで報告書を作成し、ユーザーの行動履歴をbreadcrumbsから自然言語で説明する

## 仕様 (Specifications)

### 完了条件

- エラーの原因が特定されている
- 適切な障害レベルが判定されている
- 具体的な対応策が策定されている
- Slackフォーマットでの報告書が作成されている
- 必要に応じてSentry Issueステータスが更新されている

### 品質基準

- JSONビューの情報を網羅的に分析済み
- ユーザーの行動履歴が詳細に把握されている
- 原因分析が論理的で根拠に基づいている
- 対応策が実現可能で効果的である

## アドバイス (Advice)

### Sentry操作のポイント

- **必ずJSONビューを確認**: 通常のUIでは表示されない重要な情報（パラメータ等）がbreadcrumbsやrequestセクションに含まれている
- **breadcrumbsの重要性**: ユーザーの行動履歴とリクエストパラメータの詳細情報が記録されている
- **requestセクション**: URL、HTTPメソッド、ヘッダー情報の完全な情報が含まれている

### 分析の観点

- **攻撃判別**: `$("hoge")`のようなコードはプロジェクト外のツールの可能性
- **外部スクリプト**: Google Tag ManagerやPTEngine、Chrome拡張機能が原因の場合は過去事例を参考に
- **パフォーマンス**: N+1問題や非効率なクエリの可能性を考慮
- **並行処理**: 競合状態やデッドロックの可能性を検討

### 報告のコツ

- **ユーザー行動**: breadcrumbsの技術的データを自然言語で分かりやすく説明
- **原因説明**: 技術的でない人にも理解できるよう簡潔に
- **対応優先度**: 障害レベルに基づいた明確な優先度付け

## 禁止事項 (Forbidden Actions)

- Sentryの通常UIのみでの分析（JSONビューを必ず確認すること）
- 憶測による原因判定（根拠に基づいた分析を行うこと）
- パラメータ情報の見落とし（breadcrumbsの詳細確認を怠らないこと）
- 攻撃的リクエストの軽視（セキュリティ影響を適切に評価すること）

## ユーザーからの必要情報 (Required from User)

- Sentry Issue URL（必須）
- エラー発生時の状況や追加情報（任意）
- 緊急度に関する要望（任意）

## 報告フォーマット

以下のフォーマットでSlackに報告してください：
```
📮 **リクエスト概要**
- **URL**: [エラーが発生したリクエストURL]
- **HTTP Method**: [HTTPメソッド]
- **params**: [パラメータをJSON形式で整形]
- **User-Agent**: [ユーザーエージェント]
- **user_id**: [ユーザーID（ない場合は「なし」）]
- **user_email**: [ユーザーのEmailアドレス（ない場合は「なし」）]

🚨 **エラー概要**
- **エラータイプ**: [エラーの種類]
- **発生環境**: [本番/開発]
- **Sentry URL**: [エラーのSentry URL]
- **発生頻度**: [回数/時間]
- **障害レベル**: [高/中/低]

👣 **ユーザーの行動**
[JSONのbreadcrumbsからユーザーの行動履歴を簡潔に説明]

🔍 **原因**
[簡潔に原因を説明]

🔧 **対応**
[実施した対応または対応計画を説明]

⚙️ **Sentry Issue更新案**
[ステータス変更の提案: 10times archive / archived / 期間限定archive]

🚧 **恒久対応**（必要な場合）
[長期的な対応策]

📌 **備考**
[その他重要な情報]
```

Devin Playbook

DevinにはPlaybook機能があります。
Playbookとは、繰り返し実行されるタスクの手順を標準化するための機能で、一度作成すれば再利用できる「定型作業の手順書」のようなものです。

通常、PlaybookはDevin Webアプリで作成・保存し、セッション開始時に選択して使用します。
また、マクロキーワード（例: !sentry_error_check）を設定することで、Slackから簡単に呼び出せる仕組みも用意されています。そのため、この機能を活用しSlackから!sentry_error_checkのようなマクロキーワードでPlaybookを起動する方法を試しましたが、Slackの通常メッセージからマクロが認識されませんでした。

Devinの公式リリースノートには以下の記載がありエージェントバージョンによってサポートされないケースがあるようです。

New Agent Preview using Sonnet 4.5 This agent is in beta, so not all functionality is supported at this time; it will not suggest knowledge, use cloud IDEs, or respect macros starting with ! (such as playbooks).

従来のエージェントでは動作する可能性がありますが、環境やエージェントバージョンによって動作が異なるため、確実に動作する「Playbook内容を直接プロンプトに埋め込む」方式を採用しました。

この方式であれば

エージェントバージョンに依存しない
Playbook選択の手間が不要
Slackワークフローで完全に自動化できる

というメリットがあります。

4. Devin調査実行

Devinは以下の手順で調査を実行します。

4-1. 認証情報の安全な取得

DevinにはSecrets機能が搭載されており、APIキーやパスワードなどの機密情報を暗号化して安全に保管できます。

Sentryの認証情報をSecretsに登録することでセッション開始時に、これらのSecretsから認証情報を自動的に取得します。

SENTRY_EMAIL: Sentryログイン用メールアドレス
SENTRY_PASSWORD: Sentryログイン用パスワード

4-2. Devin内蔵ブラウザによる自動ログイン

Devinには人間と同じようにWebサイトを操作できる内蔵ブラウザが搭載されていて、この内蔵ブラウザとSecretsに登録した認証情報を用いて、Devinは以下の操作を自動で実行します。

Sentryのログインページにアクセス
Secretsから取得したSENTRY_EMAILとSENTRY_PASSWORDを入力
ログインボタンをクリック
エラー詳細ページまで自動でナビゲート

4-3. Playbookに従った調査実行

ログイン後、Devinはプロンプトに埋め込まれたPlaybookの手順に従って調査を実行します。

5. 結果報告

調査完了後、DevinがSlackスレッドに結果を返信します。担当者は結果を確認し、対応方針を決定します。

導入後の成果

エンジニアの作業時間を大幅削減し生産性向上

従来は1件あたり15分程度のエラー調査工数がかかっていましたが導入後はスタンプを押下するだけで、5分後にはDevinが調査結果レポートを提出してきます。
その間、エンジニアは別の作業を継続できるため、実質的なコンテキストスイッチや調査工数はほぼゼロになりました。

差し込み対応、コンテキストスイッチがなくなり開発体験向上

前述した通り、自身のタスクと並列でDevinのSentryエラー調査が行えるため、Sentryエラーによる差し込み対応、コンテキストスイッチは最小限になりました。

調査速度、精度の属人化解消

共通のプロンプトテンプレートを使い回しDevinに依頼することにより、調査精度や速度のばらつきがなくなりました。

エラー内容、影響範囲の迅速な把握

スタンプ押下さえすれば、自身がすぐにエラー調査できない状況であっても迅速なエラー内容と影響範囲の把握が行えるようになりました。

まとめ

今回はDevinを用いたSentryエラーの半自動調査手順を紹介しました。特に、ACU削減のためにJira起票や、バグ修正は明示的に行わせない点や、Playbookの代替案としてSlackワークフローに直接プロンプトを埋め込んで、誰でも使い回しや編集可能にした点など、ACUや管理コスト削減を工夫しました。
抱えていた課題を解決できたという成果のみならず、コード生成以外にもAIを用いた生産性向上の一例を構築できたことで、日々の業務を構造分解すれば実は多くのことがAIに任せられるのでは？とAI活用への意識が変化しました。

TalentXでは、各チームでAIを用いた業務改善や自動化を積極的に策定・導入しています！
カジュアル面談も行っていますので気になる方はぜひご応募いただければ幸いです。

i-myrefer.jp

TalentX Tech Blog

Tech Blog