🚨

Devinさんもメンバーなのでエラー調査してくれますよね??

まるべいじ

2025/06/06に公開

 はじめに「エラー？ Devin君が勝手に片付けてくれるでしょ！」──そう思って Slack を開いたものの、通知の山を前に完全沈黙を貫く De​​vin さん。

AI なのに労働組合でも結成したのか、はたまたバケーション中なのか……。結局、人間がタスクを中断してトリアージに追われる羽目になった経験はありませんか？
エラー対応はソフトウェア開発の生命線ですが、集中している作業を遮られると生産性は一気に急降下します。本記事では、その「動かざること CPU のごとし」な Devin にムチを入れ、自ら一次調査を黙々と片付けてもらう仕組みを構築した事例を紹介します。Slack でスタンプを ポン と押すだけで、Devin が Sentry を駆け回り、わずか 3〜5 分後には丁寧なレポートが戻ってくる——そんな夢のようなワークフローの作り方をお届けします。

 背景：なぜDevinにエラー対応を任せるのか
 従来のエラー対応の問題点従来のエラー対応フローは以下のような流れでした
SentryからSlackに通知が来る
エンジニアが通知を確認してSentryを開く
エラー内容を確認し、原因を特定する
対応方法を検討して修正を実施する
Sentryでエラーを閉じる
このプロセスの最大の問題は、すべてが人間の手動作業であることです。エラーの原因調査には時間がかかり、別の作業中に割り込まれることで深刻なコンテキストスイッチが発生します。

 Devinの特性とエラー対応の相性Devinは自律的なAIソフトウェアエンジニアとして、コードの記述から実行、テストまでを自動で行うことができます。
特に以下の特性がエラー対応と相性が良いことが分かりました
コードベース理解による的確な分析：Devinはプロジェクトのコードベースを理解した上でエラーを調査できるため、単純なエラーメッセージの解析だけでなく、実際のコードと照らし合わせた分析が可能。
繰り返しタスクの自動化能力：エラー調査は定型的な手順が多く、Devinが得意とする繰り返しタスクの自動化に適している。
日本語での報告：コードレビューと比較すると、自然言語で書かれた短い報告書のレビューは格段に負担が少なく、管理コストを抑えられる。

 実装方法：Slack→Devin→Sentryの連携構築
 全体アーキテクチャ構築したシステムの全体像は以下のとおりです

 Slackワークフローの設定Slackのワークフロー機能を使用して、スタンプリアクションをトリガーとしたメッセージ送信を実装しました。
ポイントは以下の3つです

!sentry_error_check：DevinのPlayBookを起動するマクロキーワード

「PRの作成は不要」の明記：DevinのACUの消費を抑えるため

メンション指定：調査完了時に確実に通知が届くように

 DevinのPlayBook作成PlayBookは、Devinで繰り返し実行されるタスクを標準化するための機能です。今回は以下の内容でPlayBookを作成しました。
ライトに運用に乗せたかったため、あまりチューニングしてません。

プロンプト含めて改善やDevinのKnowledgeに分割したりしたら、さらに精度の高い調査報告ができるのではと思ってます。
テンプレート
 Sentryエラートリアージガイド
 目的このガイドは、Sentryで検知されたエラーを効率的に分析し、適切な対応を行うためのものです。新入社員の方でも手順に沿って進めることができるよう、詳細に記載しています。

 前提条件調査はSentryとコードベースのみで実施
SentryのエラーのURLは特定済み
以下の作業を行う
エラー内容の確認
障害レベルの判断
エラー原因の判定
攻撃的なリクエストによるエラーの場合はその旨を説明
システムの不備によるエラーの場合は改修案を提示

全ての情報を集めてからエラーの原因特定を始める

 Sentryの基本操作SentryのJSONビューを元にエラーの調査を行う。JSONビューにない情報を確認したい場合は、画面を操作して該当箇所を確認する。

JSONビュー: エラー詳細ページの「JSON」リンクをクリックして、エラーの全データをJSON形式で表示
breadcrumbs: ユーザーの行動履歴やリクエストパラメータ（重要: パラメータ情報はここにしか表示されない場合がある）
request: リクエスト全体の情報（URL、HTTPメソッド、ヘッダー情報など）


 トリアージフロー
 調査対象の情報収集調査をするべきSentryのissue URLを確認する
情報の提供がない場合は、ユーザーに質問し確認する


 1. エラー内容の確認
 1.1 基本情報の確認
エラータイプ: エラーの種類（例：TypeError, NetworkError, DatabaseErrorなど）

発生頻度: 発生回数と時間間隔

影響範囲: 影響を受けるユーザー数や機能

初回発生時間: エラーが初めて検知された時間

最終発生時間: 最後にエラーが検知された時間

環境: 本番環境か開発環境か

 1.2 エラー詳細の確認
エラーメッセージ: エラーの具体的な内容

スタックトレース: エラーが発生した場所と呼び出し経路

リクエスト情報: 確認必須
URL
HTTPメソッド
パラメータ（JSONビューのbreadcrumbsセクションに表示されることが多い）
ヘッダー情報（JSONビューのrequestセクションに表示）


ユーザー情報: エラーが発生したユーザーの情報
id
email


ブラウザ・デバイス情報: 発生環境の詳細

 1.3 コンテキスト情報の確認
関連するコミット: 最近のデプロイやコード変更

関連するイベント: 同時期に発生した他のエラーや警告

ブレッドクラム: ユーザーの行動履歴

 2. 障害レベルの判断以下の基準に基づいて障害レベルを判断します。

 2.1 緊急度高（即時対応必要）サーバーがダウンしている（コンテナが自動で起き上がらない）
500エラー画面が頻繁に表示される
リード（顧客獲得）機能に影響がある
リリース直後に大量のエラーが発生している
複数ユーザーからの問い合わせがある
重要な業務機能が利用できない

 2.2 緊急度中（当日中に対応）一部の機能が正常に動作していない
特定の条件下でのみエラーが発生している
回避策が存在する
限定されたユーザーのみに影響がある

 2.3 緊急度低（計画的に対応）UIの軽微な不具合
パフォーマンスの低下
エラーは発生しているが機能は動作している
影響範囲が非常に限定的

 2.4 Sentryのissueのステータスを更新の判定基準エラー対応完了後にSentryのissueのステータスを変更する必要がある
ステータス変更ルール（参考：https://docs.sentry.io/product/issues/states-triage/#archive）
原因が不明で再現性が怪しい場合：10timesのarchive
修正が必要ない場合 : archived
エラーの検知は継続するが、一時的に通知を止めたい場合：一定期間のarchived

※ どれくらいの期間archivedするかは担当者に委ねますが、この期間が長いと気づくべきエラーに気づきにくくなるので、archiveの期間は段階的に上げていくのを推奨します （10times, 2hours, 1day, 10user）


 3. エラー原因の判定
 3.1 コードベースの確認エラーが発生している箇所のコードを確認
関連するコンポーネントやモジュールを特定
最近の変更履歴を確認

 3.2 よくある原因パターン
 3.2.1 システム側の問題
バグ: ロジックの誤り、境界条件の考慮漏れ

設定ミス: 環境変数、設定ファイルの誤り

リソース不足: メモリ不足、CPU高負荷、ディスク容量不足

依存関係の問題: ライブラリのバージョン不一致、API変更

パフォーマンス問題: N+1問題、非効率なクエリ

並行処理の問題: 競合状態、デッドロック

 3.2.2 外部要因
ユーザー入力: 予期しない形式のデータ、文字エンコーディングの問題

攻撃的なリクエスト: インジェクション攻撃、DDoS、スクレイピング

外部サービスの障害: サードパーティAPIのダウン、応答遅延

ネットワーク問題: タイムアウト、接続拒否

 3.3 攻撃的リクエストの判別以下の特徴があれば攻撃的なリクエストの可能性があります
短時間に同一IPから大量のリクエスト
一般的なWebアプリケーション攻撃パターンの存在
SQLインジェクション
XSS（クロスサイトスクリプティング）
CSRFパターン

通常ではありえないパラメータ組み合わせ
明らかに自動化されたリクエストパターン

 3.4 GTMやPTEngineのような外部スクリプトのエラーGoogle Tag ManagerやPTEngineを使って外部のスクリプトを実行することがあります
Chrome拡張機能をユーザーが使っている場合は、その拡張機能がエラーを発生させている可能性もあります
$(”hoge”)のようなコードは、プロジェクトで使用していない外部ツールの実行可能性がある
過去の対応や発生頻度を確認して対処案を考えてください

 4. 対応策の策定
 4.1 システムの不備によるエラーの場合
 4.1.1 一時的対応（即時実施可能）
パラメータ調整: 設定値の変更

再起動: サービスの再起動

容量増強: リソースの増強

機能の一時停止: 問題のある機能を一時的に無効化

 4.1.2 恒久的対応（計画的に実施）
バグ修正: コードの修正

リファクタリング: 問題箇所の再設計

監視強化: 同様の問題を早期に検知するための監視追加

テスト追加: 再発防止のためのテストケース追加

 4.2 攻撃的リクエストによるエラーの場合
レート制限: IPやユーザーごとのリクエスト制限

WAF設定: Web Application Firewallのルール追加

入力検証強化: バリデーションの追加

セキュリティパッチ: 脆弱性の修正

 5. 報告と記録
 5.1 Slackでの報告フォーマット◆ リクエスト概要
URL：[エラーが発生したリクエストURL]
HTTP Method：[エラーが発生したリクエストのHTTP Method]
params：[エラーが発生したリクエストのパラメータ（整形したJSON形式）]
User-Agent：[エラーが発生したリクエストのユーザーエージェント]
user_id：[リクエストを実行したユーザーのID（ない場合は「なし」と記載）]
user_email_domain：[リクエストを実行したユーザーのEmailのドメイン（ない場合は「なし」と記載）]

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

◆ 原因
[簡潔に原因を説明]

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

◆ SentryのIssueの更新案
[長期的な対応策]

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

◆ 備考
[その他重要な情報]

報告時には以下の情報も記載します:

担当者: アサインする担当者

期限: 対応すべき期限

優先度: チケットの優先度

詳細情報: 調査結果や必要な対応の詳細

 実践例
 例1: データベース接続エラー◆ エラー概要
- エラータイプ: DatabaseConnectionError
- 発生環境: 本番
- URL: <https://sentry.example.com/issues/123456>
- 発生頻度: 15回/10分間
- 障害レベル: 高

◆ 原因
データベースコネクションプールが枯渇し、新規接続ができない状態になっていた。
直前のリリースでコネクション解放処理に不具合が混入していた。

◆ 対応
1. アプリケーションサーバーを再起動してコネクションをリセット
2. コネクションプールの上限値を一時的に増加

◆ 恒久対応
1. コネクション解放処理のバグを修正（PR #1234）
2. コネクションリーク検知のモニタリングを追加

◆ 備考
再発防止のため、デプロイ前チェックリストにDB接続テストを追加


 例2: 不正リクエスト攻撃◆ エラー概要
- エラータイプ: SecurityError
- 発生環境: 本番
- URL: <https://sentry.example.com/issues/789012>
- 発生頻度: 200回/5分間
- 障害レベル: 中

◆ 原因
特定のIPアドレスから大量のSQLインジェクション攻撃パターンを含むリクエストが送信されていた。
WAFでブロックされているが、ログには記録されていた。

◆ 対応
1. 攻撃元IPをブラックリストに追加
2. 同様のパターンをブロックするWAFルールを強化

◆ 備考
セキュリティチームに情報共有済み


 DevinのSentry認証設定Devinには内蔵ブラウザが搭載されており、人間と同じようにWebサイトを操作できます。
DevinがSentryの情報を確認するためには、以下の手順で設定します：
認証情報の登録
DevinのSecrets機能にSentryのログイン情報（メールアドレスとパスワード）を設定
この情報は暗号化されて安全に保管される
自動ブラウザ操作
Devinがブラウザを起動
登録された認証情報を使って自動的にログイン
エラー詳細ページまで自動でナビゲート
※ サイトによってプログラムを使用した自動操作が利用規約で制限されている場合があります。その場合は公開されているAPIを使用してアクセスするようにします

 Sentryの基本操作を指定Sentryの画面は多くの要素が散在しており、AIが正確に操作するのは困難です。そこで、JSONビューを活用する方法を採用しました。
AIは構造化データの処理が得意なため、JSONビューを使用することで精度の高い情報報告が可能になります。

 ステップバイステップのトリアージフローAIにステップバイステップで考えさせることで、より正確な回答を得られます。以下の5つのステップで構成しました：
エラーの基本情報確認
エラータイプ、発生頻度、影響範囲
初回発生時間、最終発生時間、環境
障害レベル判断
緊急度高：即時対応必要（サーバーダウンへの影響など）
緊急度中：当日中に対応（特定条件下でのエラー、回避策あり）
緊急度低：計画的に対応（UIの軽微な不具合、パフォーマンス低下）
エラー原因判定
システム側の問題（バグ、設定ミス、リソース不足など）
外部要因（攻撃的リクエスト、外部サービス障害など）
対応策策定
一時的対応と恒久的対応の区別
攻撃的リクエストの場合のセキュリティ対策
報告と記録
統一フォーマットでの報告
障害レベル判断は通知が来た時点で人間がある程度判断してしまいますが、ちょっと助かるくらいの意味合いで入れてます。

 コスト最適化のための制限事項PR作成まで自動化すると、ACUの使用量が増加します。そのため、以下の制限を設けました：
調査と報告に特化（コード修正は行わない）
PRの作成は明示的に禁止

 報告テンプレートの指定報告はテンプレートに沿ってしてもらうようにしました。

こうすることで、調査結果が過不足なく毎回同じフォーマットになるので内容の確認がしやすくなります。

 実際の動作フロー
 スタンプを押してから報告までの流れ
エラー通知受信：SentryからSlackにエラー通知が届く

スタンプ押下：エンジニアが特定のスタンプを押す

Devin起動：ワークフローが起動し、Devin専用チャンネルにメッセージ送信

自動調査：DevinがSentryにログインし、エラー詳細を調査

報告受信：約3-5分後に調査結果がスレッドに投稿される

 具体的な報告例◆ リクエスト概要
URL：/api/users/profile
HTTP Method：GET
params：{"user_id": "12345"}
User-Agent：Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)
user_id：12345
user_email_domain：example.com

◆ エラー概要
- エラータイプ: DatabaseConnectionError
- 発生環境: 本番
- URL: https://sentry.example.com/issues/123456
- 発生頻度: 15回/10分間
- 障害レベル: 高

◆ 原因
データベースコネクションプールが枯渇し、新規接続ができない状態になっていました。
直前のリリースでコネクション解放処理に不具合が混入していた可能性があります。

◆ 対応
即時対応として以下を推奨します
1. アプリケーションサーバーの再起動
2. コネクションプールの上限値を一時的に増加

◆ 恒久対応
コネクション解放処理のコードレビューと修正が必要です。

 所要時間とACU使用量
調査時間：平均3-5分

ACU使用量：1回の調査で0.5~1 ACU

 導入効果と成果
 エンジニアの作業効率向上導入後、以下の効果が確認できました

作業中断の削減：エラー通知による作業中断が

調査時間の短縮：一次調査にかかるエンジニアの対応時間が平均15分から1分に

重要エラーの見落とし防止：Devinの報告により優先度判断が容易に

 社内のAI活用意識の変化Devinがコード作成以外の業務でも活用できることが証明され、さまざまな業務にAIが入ってくることで、他のメンバーもAI活用に積極的になりました。

「AIにどんな仕事を任せられるか」という議論が活発化し、新しいアイデアが生まれています。

 管理コストの観点特筆すべきは、この仕組みの管理コストの低さです
PlayBookの更新は月1回程度
Slackワークフローは一度設定すれば変更不要
Devinの精度はKnowledgeが育つほど向上

 注意点と今後の展望
 AIの調査結果の扱い方Devinの調査結果はあくまでAIによる分析です。以下の点に注意が必要です

最終判断は人間が行う：ビジネス的な影響や優先度の最終判断は人間の責任

コンテキストの限界：過去の対応履歴や社内事情は考慮されない

 人間の責任範囲の明確化以下は必ず人間が行うべきタスクです
エラーの最終的な対応判断
修正内容のレビューと承認
ステークホルダーへの報告
インシデント対応の指揮

 まとめDevinを活用したエラー調査の自動化により、エンジニアの生産性向上と精神的負担の軽減を実現できました。重要なのは、AIを「代替」ではなく「協働」のパートナーとして活用することです。
この仕組みは、エラー対応以外にも応用可能です。例えば
タスクのプランニング
問い合わせの調査対応
AIエンジニアの可能性は、私たちの想像以上に広がっています。まずは小さな自動化から始めて、徐々に適用範囲を広げていくことをお勧めします。
皆さんの開発現場でも、Devinを活用した業務効率化にチャレンジしてみてはいかがでしょうか。
参考リンク
Devin公式ドキュメント
Slackワークフロー設定ガイド
Sentry公式サイト

SMARTCAMP Engineer BlogPublication

SMARTCAMPに所属するエンジニアの個人記事を集めています。記事の内容は個人の見解であり、社内でのレビュー等は行っておりません。

はじめに

背景：なぜDevinにエラー対応を任せるのか

従来のエラー対応の問題点

Devinの特性とエラー対応の相性

実装方法：Slack→Devin→Sentryの連携構築

全体アーキテクチャ

Slackワークフローの設定

DevinのPlayBook作成

Sentryエラートリアージガイド

目的

前提条件

Sentryの基本操作

トリアージフロー

調査対象の情報収集

1. エラー内容の確認

1.1 基本情報の確認

1.2 エラー詳細の確認

1.3 コンテキスト情報の確認

2. 障害レベルの判断

2.1 緊急度高（即時対応必要）

2.2 緊急度中（当日中に対応）

2.3 緊急度低（計画的に対応）

2.4 Sentryのissueのステータスを更新の判定基準

3. エラー原因の判定

3.1 コードベースの確認

3.2 よくある原因パターン

3.2.1 システム側の問題

3.2.2 外部要因

3.3 攻撃的リクエストの判別

3.4 GTMやPTEngineのような外部スクリプトのエラー

4. 対応策の策定

4.1 システムの不備によるエラーの場合

4.1.1 一時的対応（即時実施可能）

4.1.2 恒久的対応（計画的に実施）

4.2 攻撃的リクエストによるエラーの場合

5. 報告と記録

5.1 Slackでの報告フォーマット

実践例

例1: データベース接続エラー

例2: 不正リクエスト攻撃

DevinのSentry認証設定

Sentryの基本操作を指定

ステップバイステップのトリアージフロー

コスト最適化のための制限事項

報告テンプレートの指定

実際の動作フロー

スタンプを押してから報告までの流れ

具体的な報告例

所要時間とACU使用量

導入効果と成果

エンジニアの作業効率向上

社内のAI活用意識の変化

管理コストの観点

注意点と今後の展望

AIの調査結果の扱い方

人間の責任範囲の明確化

まとめ

Discussion