Sentry エラーの優先度判断を自動化して運用を楽にした話

はじめに

『スタディサプリ』高校開発グループの @y0n3yama です。 AI を組み込んだ生徒向けのプロダクトの開発や運用に関わっています。

前回、Sentry MCP を活用した Sentry エラーの調査という記事を書きました。エラーを中心にアプリケーションを監視するツール Sentry の MCP を使うと、Claude Code から直接エラー情報を参照しながら、個別のエラーの一次調査が楽になるという話です。

ただ、日々のトリアージ運用を回していると、エラーを調査する前の段階にもう一つのコストが残っていることに気づきました。「発生しているエラーのうち、どれから見ればいいのか」を判断するコストです。

この記事では前回の続きとして、そのトリアージ作業を楽にする仕組みを紹介します。

Sentry エラーの一次調査の自動化

本題の前に、土台となっている「Sentry エラーの一次調査の自動化」の仕組みをざっと紹介します。

前回の記事では Sentry MCP を使った調査を手動で実行していましたが、その後はエラー発生をきっかけに調査が自動で走るようにしました。流れは以下の通りです。

Sentry がエラーを検知する
調査用ラベル付きの GitHub Issue を自動作成する
ラベルを検知して Claude Code Action が起動する
Sentry MCP でエラーの詳細を取得し、ソースコードも参照する
原因の仮説を Issue にコメントする

スタックトレースから該当コードを特定し、「ここでこういう条件が成立すると問題になります」といった調査レポートがエラーごとに自動で投稿されます。

実際の調査レポートはこのような様子です（内容はサンプルです）。

自動調査の結果コメントの例。エラー概要・推測原因・推奨アクション・DB 確認事項が並ぶ

自動調査自体はうまく動いていましたが、運用してみると別の問題が見えてきました。

トリアージの難しさ

自動調査は個別のエラーへの対応に役立ち、特に急ぎのものは調査レポートで概要をつかめるので、すばやく対応できるようになりました。

一方で、現実の運用では、緊急度は低いが数多く発生するエラーの対応方針をどう決めるかが問題になります。調査レポートは Issue 単位に分散していて、全体としてどれが対応必須か、どれが想定内で対応不要かを棚卸しする必要があります。

個人的な話にはなりますが、4月から現在のチームに異動してきました。そのチームでは4月に新しいプロダクトをリリースしたばかりで、検知されるログやエラーの棚卸しの負荷が高いという課題がありました。緊急度が高いと分かるものは随時対応していましたが、その一方で確認を後回しにしているエラーが日々積み重なっている状況でした。

Sentry ではプロジェクトごとにエラーの一覧を参照できますが、1件ずつタイトルが並んでいるだけで、全体像の把握が困難です。各々がどんなエラーで優先度が高いものはどれか、ぱっと見ではわかりません。また、重要度の低そうなエラーに見えても、詳しく調べると迅速に対応が必要なエラーだったということも珍しくありません。

ここで気づいたのは、自動調査の仕組みを作っただけで終わりではなく、その手前に「全体を見渡して、それぞれの対応順位を決める」トリアージ作業が残っているということでした。

トリアージサマリを自動で作る

そこで作ったのが、トリアージ用の「サマリ」を自動で作る仕組みです。

GitHub Actions で担当チームの Sentry プロジェクトの未解決エラーを定期的にスキャンし、対応の優先度別に整理した一覧を 1 つの GitHub Issue として自動で投稿します。

成果物

投稿される Issue は、こんな構成になっています。

タイトル: [Sentry トリアージ] <チーム名> <日付>
本文: 🔴 High / 🟠 Medium / 🟡 Low の 3 つのセクションに振り分けられたエラー一覧
各エラーには、概要、原因、推奨アクション、注意点が書かれている

実際に投稿される Issue はこのような様子です（プロダクト名やリンクはサンプル用に置き換えています）。

トリアージサマリ Issue の例。緊急度別に振り分けられ、各エラーに原因と推奨アクションが並ぶ

この仕組みの良いところは 2 つあります。

緊急度順に並ぶ: 上から見ていけばよく、「どれから？」がなくなる
個別の調査結果も参照済み: 土台として紹介した自動調査のレポートを照らし合わせているので、「何が起きているか」もその場でわかる

つまり、「どれから見るか」と「何が起きているか」を 1 つの Issue で同時に解決できます。

仕組み

中身は、前述した自動調査の仕組み（Claude Code Action + Sentry MCP）と同様です。

定期実行により GitHub Actions のワークフローがトリガーされる
Sentry MCP で、対象プロジェクトの未解決エラー一覧を取得する
過去に投稿された個別の調査レポート（調査用ラベルの付いた Issue）を検索し、エラーと照らし合わせる
緊急度別に振り分けて、1 つの Issue にまとめて投稿する

実際に Claude Code Action へ渡しているプロンプトは、要点だけ抜き出すとこんな指示です。

あなたは Sentry のトリアージを担当するアシスタントです。
以下の手順で、対応優先度別のサマリを 1 つの GitHub Issue にまとめてください。

1. Sentry MCP で、対象プロジェクトの未解決エラーを取得する（1 プロジェクトあたり最大 30 件）
2. 各エラーについて、調査用ラベルの付いた既存の調査 Issue を検索し、
   原因の仮説があれば紐づける
3. エラーを緊急度で 🔴 High / 🟠 Medium / 🟡 Low に振り分ける
   - 影響範囲（件数・ユーザー数）と、継続中かどうかを基準にする
4. 振り分けた一覧を Markdown でまとめ、新しい Issue として投稿する
   - 各エラーに「概要」「原因」「推奨アクション」「該当の調査 Issue リンク」を書く

このプロンプトはチームやプロダクトごとに調整でき、たとえば「データ不整合が発生している可能性がある場合は Medium 以上にする」といった振り分けルールを足せます。共通部分は使い回せるので、他のチームも対象プロジェクトと振り分けルールを指定するだけで導入できます。

自動調査の結果を活かして、より精度の高いトリアージができるようになりました。

運用フロー

上記の仕組みは、次のような運用フローでチームに取り入れています。

トリアージ Issue が定期実行により自動で作成される
チームで Issue を上から見て、各エラーに対応方針を記録する
- 解決したものは Sentry で resolve してチェックを入れる
- 対応が必要なものは「修正対応の Issue を作る」などとコメントする
最後に、コメントを読み取って後続作業を実行する

最後の後続作業もプロンプト 1 つで対応可能にしています。具体的には「対応が必要」とコメントしたものを GitHub Issue として起票し、すでに解決済みとマークしたエラーについては対応する調査 Issue をクローズするという定型作業です。

こちらも要点だけ抜き出すとこんな指示です。

Sentry トリアージの後続作業を行ってください。
対象のトリアージ Issue: <トリアージ Issue の URL>

1. トリアージ Issue の本文とコメントを読み、次の 2 つを整理する
   - 「対応が必要」とコメントされたエラー
   - 解決済みとしてチェックが付いたエラー
2. 「対応が必要」とされたものを、課題管理用のリポジトリに Issue として起票する
   - タイトルと本文はコメントの内容からまとめ、元の Sentry エラーへのリンクを添える
3. 解決済みのエラーに紐づく調査 Issue をクローズする
4. 実施した内容（起票した Issue とクローズした Issue の一覧）を、
   トリアージ Issue にまとめのコメントとして投稿する

チームで行うのは「どう対応するかの判断」だけで、その前後の手作業は仕組み化しました。結果として、週次でのトリアージ作業後に滞留するエラーはほぼゼロになりました。