ENECHANGE Developer Blog

ENECHANGE開発者ブログ

Sentry エラーを Slack、GitHub 連携で Cursor と共に解析する未来

AIエージェント活用リレーブログ

こんにちは、ENECHANGE で EV Dev チームのエンジニアをしている利廣です。

私は日々 EV充電 アプリの開発に携わっているのですが、アプリ開発において避けて通れないのが「エラーの解析」です。特に本番環境でのエラーは、迅速な対応が求められる一方で、調査に時間がかかるというジレンマを抱えています。

そこで、私が AI エージェントを活用して構築したエラー解析ワークフローについて、正直な体験談を交えながらご紹介します。

正直な話：エラー解析って面倒くさい

プロダクトエンジニアなら誰しも経験があると思うのですが、エラーの解析作業って本当に面倒です。

  • 同じようなエラーを以前にも調査したことがある気がするけど、どこに情報があったっけ？
  • Slack の過去の会話を遡って探すのに 30 分...
  • GitHub のコードを読み込んで、エラーの発生箇所を特定するのにまた 30 分...
  • 結局、「あ、これ前にも同じ調査してた」なんてことがザラにある

そんな非効率な状況を変えたくて、AI エージェントを活用した自動解析システムを構築しました。

システムの全体像：3 つのツールの連携

構成要素

  • Sentry: エラーの検知と詳細情報の保持
  • Slack: 過去の議論やナレッジの蓄積
  • GitHub: アプリケーションのソースコード
  • Cursor: AI エージェントによる自動解析

動作フロー

  1. Sentry からエラー URL を取得
  2. Slack で過去の類似エラーの議論を検索
  3. GitHub で該当するコードを調査
  4. 全ての情報を統合して Cursor で解析レポートを生成

実際の使い方：テンプレートで効率化

GitHub+Sentry テンプレート

### 現状
このレポジトリでFlutterアプリを管理しています。
https://github.com/enechange/mobile-ev-app/

### やりたいこと
エラーの解析をGithubと連携して行いたいです。
エラーの詳細は以下のSentryで報告されたIssueのURL先に記載されています。
<ISSUE_URL>

解析の際はGithubで該当する部分をMCPサーバーを使って特定して、
その際release/<APP_VERSION>のブランチを調査することを留意してください

### 同様のエラー
Sentry上に過去バージョンで同じ種別のissueが存在するか調査して、あればissueのURLも含めて情報をピックアップしてください（複数件可）
- 対象プロジェクトは `/mobile-ev-app-prod/?project=4505364297547776` になります
    - 検索ワードは絞り込みすぎないように注意してください

Slack の検索テンプレート

以下のスレッドでは、Flutterアプリで発生したエラーについて会話しています。
この会話の内容をMCPサーバーを使って取得して、要約してください。
また、このエラーについて過去にすでに対応済みであったり関連する会話があれば
MCPサーバーを使って収集してください。
<SLACK_THREAD_URL>

実際に使ってみた感想

良かった点

  • エラー調査の効率化: 以前は同じような調査を繰り返していた非効率を解消
  • 見落としの防止: 過去の議論を確実に拾い上げてくれる
  • 構造化された報告: エラーの原因、影響範囲、対策がきちんと整理される
  • 過去の知見の活用: Slack の会話を遡って確認する手間を自動化

正直な課題

  • Slack MCP サーバーの制限: 取得できるSlack上の会話件数に制限があるので、正直使い物にならなかった印象
  • 設定の複雑さ: 初期設定にはそれなりの時間が必要
  • 情報の完全性: 100%自動化は難しく、最終的には人間の判断が必要

運用のコツ

  1. 新しいエラーごとに会話をリセット: 同じ Cursor 会話で複数エラーを聞くと、中途半端な返答になりがち
  2. 段階的に質問: 一気に全てを聞くより、Sentry → Slack → GitHub と段階的に進める

今後の展望：自動化のその先へ

このワークフローを使って感じるのは、AI エージェントの真の価値は「人間の作業を代替する」ことではなく「人間の判断を支援する」ことだということです。

現在検討している改善案：

  • AWS を使った AI によるエラー解析を自動化: Slack に解析結果を通知の流れを作りたい！
  • 自作の MCP サーバーを作成: より柔軟なデータ取得

まとめ

このワークフローにより、Sentry でキャッチしたエラーを MCP サーバーを通じて GitHub と Slack の情報と連携し、Cursor で自動解析することが可能になりました。エラー調査の効率が大幅に向上し、過去の知見を活用しながら迅速な問題解決ができるようになっています。

明日は、また別の視点から AI エージェント活用についてお話しいただけると思います。お楽しみに！

この記事は、実際のプロダクト開発で構築したワークフローを基に執筆しています。ENECHANGE では、こうした AI エージェント活用の知見を日々蓄積し、より良いプロダクト開発を目指しています。