以前、カスタムスラッシュコマンドを提案するカスタムスラッシュコマンドを作った という記事を書きました。今回も、カスタムスラッシュコマンド の話です。
本記事は、リンクアンドモチベーション Advent Calendar 2025 の4日目になります。
Sentry エラー発生時のいくつかの課題
弊社では、エラー検知のため、Sentry を利用しています。本番環境でエラーが発生し、Sentry で検知した場合は、エラー通知用の Slack チャンネルがあり、そこに投稿があります。
このエラー発生時の対応には、いくつか課題があると考えていました。ざっとあげると、（毎回ではもちろんないですが）以下の場合があります：
- 調査者が明確でない（ので互いに様子を伺い、結果として対応までの時間が延びる）
- ドメイン知識や経験の長い人のみが事象を理解でき、彼らに依存する （歴の浅い人は、最初の一歩目さえ何をすればいいか見当がつかない）
- Sentry 画面から、情報を読み取りにくい
エラー通知が来るということは、想定していない事象が発生した可能性が高いわけで、緊急度高く対応する場面もあります。しかし、上記の理由により、迅速に対応しづらい場面がありました。
というか、正直言うと、エラー内容によっては、何したらいいかわからんとなることが私にはたびたびあります（慣れていない機能については特に）。
AI による調査の代替...？
そんな課題の打ち手として、AI を用いて、可能な限り調査や対応を遂行してくれる方向を考え始めました。そういった事例はいくつか出てきていますし、たとえ調査を完遂しなくても
- エラーの詳細を教えてくれる（→ 調べやすくなる）
- 調査したことをデータとして溜め込んで、今度の参考になる（→ ナレッジとして溜まると思えば、やる気もでる）
- それらしい調査者を自動でアサインしてくれる（機械に言われたら、まぁやるか、となる？）
といった内容でも価値があるでしょうと考えました。
実は、Sentry エラーを issue 化し、GitHub Actions により Claude Code が動いて調査するという仕組みはすでにあったのですが、こちらはどちらかといえば、トリアージの意味合いが強く、緊急度低いものを issue にすることで ignore するという運用を取っていました（事象把握 〜 緊急度の判断、および緊急度が高いものはそのまま人が対応）。
もう少し状況把握や対応方針を決める箇所で AI を利用できないかと考える中で、思いついたのが、CRE OASIS を使用するという案です。こちらは、手作業で行なっていた定常業務を、CLI ベースに置き換え、AI に業務を代替してもらうという社内で構築しているプラットフォームです（詳細はリンク先参照）。
この仕組みでは、何らかの課題解決から仕様調査まで、カスタムスラッシュコマンドで自動化されており、数時間の業務を、30分程度で解決することが可能です。裏側では、プロダクションコードへのアクセス、DB アクセス、アプリケーションログアクセスが可能なため、網羅的な調査が可能であること、またナレッジを貯めるという方向性でも有効なのではないかと考えました。
DB アクセスの課題
しかし CRE OASIS の仕組みを利用する際の課題として、DB アクセスがありました。CRE OASIS では、本番 DB とは別の、時間的にラグがありかつ一部マスクされている顧客情報データを用いています。一方で、Sentry エラーは、当然本番のエラーであり、リアルタイムなデータ状況をもとに、事象を把握する必要があります。
取るべき選択肢として
- CRE OASIS で、本番 DB へ readonly でアクセスする
- 別のなんらかのサービスを跨いだ上で、本番 DB に安全にアクセスする方法を構築する
- （ほぼ）リアルタイムで本番 DB と同期される別の環境を作る
があると考えました。
しかし、どれも一長一短で、1 については、セキュリティ上の懸念（readonly だとしても、agent が本番データへ直接アクセスすることは避けたい）があり、2 は一定の運用のコストや不自由度が発生する見込みで、3 はコスト（工数面・費用面）があると思いました。
DB アクセスは諦めた
他にも、ラグがありかつマスクされている DB を見るだとか、他社事例を調べつつ検討したのですが、いっそのこと、スパッと諦めるのがいいのでは、と思い至りました。結局のところ、完全に AI に全てを代替させるのはまだ難しく、人が介在するのならば、もはや DB アクセスはなくして、それ以外の情報からわかる限りの情報を、一次情報として提供してくれるのが良いと判断しました。
ひとまず解く問題を一次調査に制限し試してみて、本番データを見ながら安全に調査できる仕組みは、また別で考えていくことにしようかと。
その代わり、DB 調査のヒントを出力するようにし（DB のスキーマ情報は読み込めるので）、一次調査後に、人間が調べやすくするためのクエリの案をいくつか提示してもらうようにしました。
推奨対象者を出す
また、当初の課題感の、誰が対応するかというところで、git blame, git log から、推奨者を出すようにしました。意味合いとしては、この人お願いします、ではなく、直近手を入れた or 多く手を入れた方なので、質問するときに選択肢として上がるように、といういうものです。
カスタムスラッシュコマンドにした
と色々考えていくと、CRE OASIS や別のなんらかのシステムを作る必要は別になく、いつも開発しているリポジトリに、.claude/commands/sentry-investigation.md を加えたらいいじゃんと思うに至りました。
プロダクションコードへのアクセスは可能で、いつものリポジトリから、（GitHub と Sentry の MCP の接続は前提ですが）開発者なら誰でも実行できる。そして、プロンプトの改善もその場でできる。別のワークスペースを開く必要なく、別の開発をしている時でも、Claude のチャットを開いて
/sentry-investigation #{Sentry エラーのリンク}
とするだけです。
プロンプトの内容
前置きを随分書いてきましたが、実際のプロンプトに記載している項目を書きます。ここではプロンプトの内容を全ては記載せず、おおまかな項目のみ公開します（日々アップデートしているので、これくらいにしておく）。
### 目的
### 作業ルール
### フェーズ1: Sentryエラー情報の特定と理解
- Sentry Issue URL の抽出
- Sentry MCP からIssue情報を取得
### フェーズ2: DBスキーマ調査（静的）
- 関連しそうなテーブルの特定
- スキーマから推測される注意点・落とし穴の整理
### フェーズ3: コード調査
- 関連コードの特定
- 処理フロー・ビジネスロジックの把握
- 対応者候補の調査
### フェーズ4: 根本原因の仮説整理
- 原因候補の洗い出し
- 再現条件の推定
### フェーズ5: 影響範囲・リスク評価・DB調査のヒント
- 影響範囲の整理
- リスク評価
- DB調査の具体的なヒント（推奨SQLサンプル）
### フェーズ6: 最終レポート作成
実行して、最後に最終レポートを Markdown で出力してくれるので、それをコピーして、Sentry エラー通知の Slack 投稿に返信する形です。
実行してみての感想
まだ、使い始めたばかりですが、いくつか気づきがありました：
- 自然言語は、理解が容易（Sentry の画面を読み解くのに比べたら）
- 1画面で色々みれるのが良い（あっちこっち行きながら事象を整理しなくていい）
- DB 調査のヒントは参考にしない場合もある（エラー内容によっては、DB 関係ない）
- 一度、調査してコンテキストも持ってくれているので、重ねての質問がしやすい
この中で、使う前には想像できていなかったこととして、4 がありました。一度、このカスタムスラッシュコマンドを使うと、そのチャット上で
- この id は今の情報でわかりますか？
- 提案してくれている対応方法の副作用はありますか？
- 別の対応方法を選んだ場合、最悪何が起こりますか？
などを重ねて質問することができます。
通常であれば、これらの質問をするまでに何ターンか必要そうですが、その辺をスキップできるのがとても楽でした。
つまり、このカスタムスラッシュコマンドは、Sentry エラー一次調査であり、同時に、詳細調査のためのコンテキスト渡しでもありました。
当初は、Devin のような形で、Slack 上で調査や会話をし、そのまま PR 作るくらいまでやってくれるのがスマートじゃないかも考えていたのですが、結局、人間がコードを見たりすることを考えると、エディタ上の方が都合良いかもと思っています（これもあくまで今のところは）。
今後
今回の仕組みで、事象把握もわかり、修正内容もかなりいい線まで出してくれてハッピーとなりました。なりましたが、根本原因や修正方針へのアクセスがしやすくなると、今度は、（修正した後の）動作確認がめんどくさくなってきました。緊急度は高くないが、またエラー通知くるの嫌だし、修正入れたいな〜、いやでもこれ入れたら、動作確認や試験で数時間くらいかかりそうだ... うーん、保留しとくか、みたいな。
そんなわけで、次は、E2E（やそれと同等なデグレ確認）のコストを、限りなく0に近づけることの重要性を感じました。ザ・ゴールではないですが、あるボトルネックがなくなってくると、次のボトルネックが見つかるもんだなぁということを、AI の進化とともに実感しました。
まだまだいくつか課題はあるので、使いつつ update していくつもりです。