こんにちは。スマートバンクでEMをしている mitani です。
最近は、AIにコードを書かせるだけでなく、Sentry などのエラー調査を Claude Code や Devin といった AI Agent に任せる事例も増えてきました。また、最近ではSentry SeerというAIデバッグエージェントも出ています。
本記事では、そこから一歩進めて 「エラー調査を行う社内 AI Agent」 を自作し、運用を始めた話を紹介します。
エラー調査 AI Agent — Guardie
「Guardie」は、Sentry のエラー（Issue）を起点に、原因の調査から対応アクションの提案までを自律的に行う AI Agent です。
プロダクトの守護者という意味の「Guardian（ガーディアン）」と、ポケモンの「ガーディ」が好きなことから、「Guardie（ガーディ）」と名付けました。
Guardie は独立した Web アプリケーションとして動作していて、Sentry の Webhook でエラー発生を検知し、複数のデータソースから情報を収集しながら原因調査を進めてくれます。
簡単なイメージ図はこんな感じで、Chat UIでエラー調査を行ってくれます。
なぜ AI Agent を自作したのか？
AI 時代の開発と障害対応
AI が大量かつ高速にコードを書けるようになった今、開発のボトルネックは「コードを書くこと」から別の場所に移りつつあるなと感じています。その一つがコードレビューで、AI が生成した低品質なコードが混入する「AI Slop」問題も最近は話題になっています。
レビューの仕組みを改善していけば、コードの品質は一定の水準を保てるようにはなっていくと思います。ただ、どれだけレビューを厳格にしても、障害をゼロにするのは現実的ではありません。
だからこそ重要なのは、リリース後の障害にいち早く気づき、最短時間で復旧する仕組みなのだと思っています。それさえあれば、AI にコードを書かせるスピードを活かしつつ、リリースサイクルをより安心して加速するためのハーネスとして機能するはずです。
この考えを実現するためのFirst Stepとして、エラーの自動解消に取り組み始めました。
人手によるエラー対応の限界
昨年、上記の記事で紹介したように、日々増えていくエラーを効率よく対応するために、アラートのルール設計や当番制による運用を続けてきました。
ただ、人手での対応にはやっぱり限界があります。特に、自分が実装を把握していない領域のエラーだと、コードを読み解くところから始める必要があって、どうしても時間がかかってしまいます。
Devin による一次調査の試み
そこでまず試したのが、Devin を使った効率化です。Sentry のエラーが Slack に通知されたタイミングで Devin を呼び出し、一次調査を走らせるという方法でした。
これだけでも調査の取っ掛かりとしては有効だったのですが、運用を続ける中で次の課題が見えてきました。
- 過去の知見を活かしづらい — 過去の調査ログを Devin に渡しづらく、類似エラーが再発したときにゼロから調査し直すことになりやすい
- 複数データソースの横断が難しい — CloudWatch Logs、New Relic のメトリクス、エラー発生前後のリリース情報など、調査に必要な情報を Devin に揃えて渡すのが難しい
- 調査後のアクションまで繋がらない — 調査結果を踏まえた Sentry Issue のステータス変更や、修正 PR の作成まで一気通貫で進められない
普段自分たちがやっているエラー対応って、単にコードを読むだけではないんですよね。過去の対応履歴を参照し、複数のモニタリングツールを横断して情報を集め、判断し、アクションまで実行する。この一連の流れを AI に任せるには、Devin だけでは不十分でした。
なので、エラー調査に必要な 情報収集・記録・アクション実行 を一気通貫で行える AI Agent を自作することにしました。
Guardie の仕組み
Guardie は Sentry の Webhook を起点にエラー情報を集約し、Devin / New Relic / GitHub などの外部サービスを tools として組み込みながら、自律的に原因調査と対応アクションの提案を行います。
技術スタック
| レイヤー | 技術 | 用途 |
|---|---|---|
| インフラ | Cloudflare（Workers / D1 / KV / Durable Objects / Queues / Cron Triggers） | サーバーレス実行環境 |
| 言語 | TypeScript (strict mode) | 全コード共通 |
| フレームワーク | Hono | API ルーティング・ミドルウェア |
| フロントエンド | React SPA (Vite) | 管理画面・チャット UI |
| AI Agent 基盤 | Cloudflare Agents SDK + AI SDK (Vercel) | Agent ライフサイクル管理・ストリーミング |
| AI モデル | Anthropic Claude（AI SDK @ai-sdk/anthropic） | エラー調査・分析・チャット |
| 外部ツール連携 | MCP（Devin / New Relic / GitHub） | コード調査・メトリクス取得・リリース情報 |
エラー検知の流れ
Sentry の Custom Integrations を利用して、Issue 発生時に Webhook で Guardie に通知しています。Guardie は Webhook を受け取ると、以下の処理を実行します。
- Sentry API から追加情報を取得 — Webhook のペイロードだけでなく、取得できる情報は可能な限り集める
- Issue の起票ステータスを記録 — トリアージの起点として DB に保存
- 担当者への Slack 通知 — アサイン者がいる場合は Slack DM で通知
エラーの原因調査（Workflow）
Guardie の中核となるのが Workflow 機能です。エンジニアが Guardie の Web 画面からエラーを選んで調査の開始を指示すると、AI Agent がフェーズに沿って自律的に調査を進めてくれます。
Workflow は以下の 4 つのフェーズで構成しています。
| フェーズ | 目的 | やること |
|---|---|---|
| Triage | 状況把握・トリアージ判断 | 過去のナレッジや類似事例を確認し、既知の問題か新規の問題かを判断する |
| Investigation | 原因究明 | Devin でコード調査、New Relic でメトリクス分析、GitHub で関連 PR を確認するなど、複数のデータソースを横断して根本原因を特定する |
| Record | 記録・アクション実行 | 調査レポートの生成、Sentry へのコメント投稿、ステータス変更、必要に応じて Devin で修正 PR を作成する |
| Closed | 完了 | 追加の質問や調査に対応するモード |
このフェーズ設計にはいくつか意図があります。
- 段階的に情報を集める — いきなりコードを読みに行くのではなく、まず過去の知見を確認することで無駄な調査を減らす
- 人間が介入できるポイントを作る — 各フェーズの遷移時にエンジニアが判断を確認・修正できる
- AI の暴走を防ぐ — フェーズごとに使えるツールを制限し、トリアージ段階では詳細調査ツールは使わせないなど、スコープを制御する
特に 3 つ目は結構大事で、AI に全ツールを一気に渡すと意図しない方向に調査が進んでしまうことがあります。フェーズで区切ることで「今はこれだけやってね」というガードレールになっています。
Tools の組み合わせによる調査
Guardie のいいところは、複数の外部サービスを tools として組み込んで、AI が自律的に使い分けながら調査を進めるところです。DevinやSentry Seerだけで調査するよりも、情報量を増やしながら正確な調査ができます。
現在、以下の外部サービスと連携しています。
| 連携先 | 接続方式 | やること |
|---|---|---|
| Devin | MCP | エラーのスタックトレースを渡してコードベースを調査。発生箇所の実装、関連する設定値、呼び出し元のコードなどを自律的に探索してくれる |
| New Relic | MCP | 本番環境のメトリクス・ログ・トランザクションを分析。エラー発生前後のパフォーマンス変化やエラーパターンを調べる |
| GitHub | API | 直近の PR を確認し、エラーに関連する変更がないか調べる。diff の内容まで見に行く |
| Sentry | API | Issue のステータス変更（Resolve / Archive）やコメント追加を実行する |
Devin と New Relic は MCP（Model Context Protocol）で接続しています。MCP 経由だと、サブエージェントが相手側のツールを自律的に複数回呼び出せるので、たとえば Devin に「このエラーのコードを調べて」と投げるだけで、エラー発生箇所 → 関連設定 → 呼び出し元と芋づる式に調査してくれます。
親の Agent は「コード面は Devin」「メトリクス面は New Relic」「最近の変更は GitHub」とそれぞれに調査を委託して、結果を総合して根本原因を特定します。人間のエンジニアが複数のツールを行き来しながら調査するのに近いフローを実現できています。
ナレッジの蓄積
同じようなエラーが再発したときに対応を速くするため、調査の成果物を DB に保存するようにしています。
- 調査報告書 — エラーの概要、根本原因、対応策をまとめたレポート
- 調査 Tips — 調査の中で得られた、今後に活かせる小さな知見
蓄積されたナレッジは、次回以降の Triage フェーズで AI のシステムプロンプトに自動で埋め込まれます。なので、類似エラーが再発したときに「過去にこういう原因で発生して、こう対応した」という情報を踏まえたトリアージができるようになります。これが地味に効いてきていて、調査を重ねるほど Guardie が賢くなっていく感覚があります。
その他の便利機能
Devin Session の作成
調査報告書の内容をもとに、修正 PR の作成を Devin に依頼できます。調査で特定した根本原因と修正方針が Devin のプロンプトに含まれるので、ゼロから依頼するよりも精度の高い修正が期待できます。
Guardie の自己改善機能
原因調査から対応アクション提案までの一連の流れの中で、うまくいかなかった点や改善できそうな点を Guardie 自身が分析して、改善案を提案してくれます。自分自身を自律的に改善していくアプリケーションは見ていて未来感があります。
運用してみての成果
Guardie を運用し始めて数ヶ月が経ち、いくつかの変化が見えてきました。
- MTTR（平均復旧時間）の短縮 — エラーの検知から対応完了までの時間を短縮できています
- ナレッジの蓄積による精度向上 — 調査を重ねるごとにナレッジが蓄積されて、類似エラーへの対応がより速く正確になっています
- 調査過程の透明性 — Agent の思考過程をチャットで一緒に辿れるので、調査結果の妥当性を確認しやすくなりました
- 柔軟なカスタマイズ — 自前で作っているからこそ、自社の開発フローや使用ツールに合わせた最適化ができています
一方で、Webhook の取り逃がしによる検知遅れに気を遣うなど、自前のシステムを維持する分の運用負荷は考慮する必要があります。ここはトレードオフだなと感じつつ、それでも自作してよかったと思える場面の方が多いです。
これから先
冒頭で述べたように、AI がコードを高速に書ける時代だからこそ、障害にいち早く気づき、最短時間で復旧する仕組みの重要性は増していくと思っています。
Guardie はまだまだ発展途上ですが、より速く、より正確にエラーを分析し、対応アクションの実行まで自律的に行えるよう進化させていきたいです。
