Article by: Dhrumil Parekh（読了時間：6分）
これからは AI が大量のコードを生み出し、それにともなってバグも大量に生まれていきます。これはもう分かりきったことですし、これまでにも触れてきました。より大きな課題はエージェントが書いた不具合だらけのコードの修正に、時間をすべて奪われずに済むようにすることです。
そうした問題をより簡単に修正できる仕組みが必要になります。幸い、自動化ワークフローを構築するためのソリューションは、世の中にたくさんあります。
Sentry では最近、デバッグと Issue のトリアージのプロセスを自動化する方法を模索してきました。自分でも試してみたいという方のために、その過程で得たヒントや学びをいくつか共有できればと思います。
すべては「何が・なぜ壊れているか」を知ることから始まる
AI に問題を解決してもらうなら、まずは問題が発生したタイミングを把握する必要があります。当然ながら、Sentry では Sentry を大いに活用しています。アプリケーションをインストルメントして、あらゆるシグナルやメトリクスを出力できるようにしており、システムの稼働状況を詳細に把握できるようになっています。
ご想像のとおり、その分 Issues ページはかなり埋まりがちで、トリアージに多くの手作業が発生します。そこで登場するのが、AI を活用したデバッグエージェント Seer です。Seer の autofix は、コアの Sentry、ドキュメント、MCP サーバー、CLI ツールなど、いくつもの Sentry プロジェクトと、それぞれに対応する GitHub リポジトリに設定しています。
さらに Seer には、問題の根本原因を突き止め、修正計画を立て、PR（プルリクエスト）を自動で作成する権限も与えています。組織によっては、機械をそこまで信頼する準備が整っていないかもしれませんが、問題ありません。人間がプロセスに加わるまでに Seer をどこまで進ませるかは、自分で制御できます。自動化の目的はエンジニアの手作業を減らすことであり、エンジニアの人数を減らすことではありません。
PR の自動生成は便利ですが、ここで新たな疑問が生じます。レビューすべき PR があることを、どうやって知ればいいのか。そして、誰がレビューすべきなのか、という問いです。
レビューのためのルーティンをつくる
自動化で難しいのは、たいていタスクそのものの難易度ではなく、規模が大きくなるにつれてそれらのタスクをどう管理するかです。エージェントがコード修正のような小さな作業をこなせるのは便利ですが、その真価はシステム全体にもたらす効率にあります。私たちの場合、いまや Seer が大量の新しい PR を生成しています。では「最高委任責任者（Chief Delegation Officer）」のような新しい役職をつくらずに、それらをきちんと処理するにはどうすればいいのか。答えは「さらにエージェントを増やす」です。
このプロジェクトを始めたとき、注力した領域は2つありました。
1. 修正を作成するプロセスを自動化する
2. 対応すべきものが出てきたら、エンジニアを引き入れる
Seer が新しい PR を作成するたびに通知される Slack チャンネルを用意しています。これには、最近追加したばかりの新しいアラートトリガーを使っています。これは汎用的なフィードで、投稿の約90%は新規 PR の通知、ときおり会話が混ざる程度です。それを一つひとつ手作業で確認する代わりに Claude routine を使っています。私たちがどのように構築したのかについてご紹介します。
スケジュールで実行する
このルーティンは1時間ごとに実行され、Slack フィードに新しい PR がないかを確認します。ここでいう新しい PR とは、直近4時間以内に作成され、まだ対応されていない PR を指します。こうすることで、常に新しい PR だけを対象に作業できます。
レビュアーを特定する
まず Claude があらかじめ用意した Slack メッセージを Seer agent に送り、PR のレビューに最も適しているのは誰かを尋ねるプロンプトを投げます。Seer は GitHub リポジトリのコミット履歴を調べ、Seer の根本原因分析で指摘されたコードに最も深く関わってきた人物を見つけ出します。
PR が open かどうかを確認する
PR を割り当てる前に、まだ存在するか確認します。ステータスをチェックし、すでにマージ済み・クローズ済み、あるいはその他の理由で対象外になっていれば、何も言わずにスキップします。
レビュアーに通知する
PR が有効であれば、ルーティンは Seer が作成した PR のスレッド内でレビュアーをタグ付けし、次の対応で仕上げてほしいと依頼します。
- PR をマージまたはクローズする
- 一言フィードバックを残す
- これが Seer の有効な活用だったかどうかを記録する
また、ルーティンがプロンプト・質問・DM を二重に投稿しないようにも作り込みました。エージェントの目的は作業を効率化することであって、ノイズを増やすことではないからです。
念のため言っておくと、これは一発で完成した仕組みではなく、数週間かけて改良を重ねました。たとえば、エンジニアが週末に通知を受け取らないように、あるいは割り当て直後に通知が飛ばないようにする必要がありました。こうした点は試行錯誤の中でしか見えてこなかったもので、いまも全体のフローを改善する方法を探し続けています。すべての組織に当てはまる万能の解決策はありません。大事なのは、しっくりくるものをまず立ち上げ、そこから細かな不具合をつぶしながら改善していくことです。
初期の成果
ひとつ注意点があります。このワークフローを展開したのは7月半ばなので、実際の効果をきちんと判断するには、数か月後に改めて見直す必要があります。とはいえ、初期の兆候は良好です。現時点で見えている数字をいくつか挙げます。
- PR への対応率が約21%向上
- open な PR に対する48時間以内の応答率が約13%向上
- マージせずにクローズされた PR が約12.5%増加
この結果を見て、「マージせずクローズ」の増加は良い指標とは言えないのでは、なぜわざわざ共有するのか、と思うかもしれません。提案された修正が役に立っていない、あるいは問題の根本を解決できていない、という可能性もあるからです。そこでもう少し掘り下げて調べてみました。結果はそうではありませんでした。
マージせずクローズされた PR には、いくつか共通するパターンがありました。別の PR ですでにカバーされている重複した修正であるか、あるいはレビューを担当したエンジニアが、元の問題の範囲を超えたより包括的な修正を選んだというものです。どちらの場合も、ワークフローは役割を果たしています。エンジニアは修正が用意できたことを通知され、PR に対して行動を起こしています。手つかずの PR が山積みのまま放置されるより、はるかに良い状態です。
ここでひとつだけ持ち帰ってほしいことがあるとすれば、それはこうです。自動デバッグは実現可能であり、そして本当に役に立つ。その鍵は「適切な人を適切なタイミングで巻き込む仕組み」を作ることです。
Seer はこのワークフロー全体を動かすエンジンです。次のような場面で Seer に頼っています。
- 問題を診断する
- 修正を提案する
- PR を作成したら Slack チャンネルに通知する
- 関与すべき適切なエンジニアを特定し知らせる
そこに Claude で少し自動化を足していますが、基本的にはできる限り Seer を活用しています。この取り組みは、こうしたループを実現するために Seer へさらに機能を追加する動機にもなりました。現在は、Seer が最も関連性の高いユーザーに PR を割り当て、自動で通知する方法を模索しています。
自分でも試してみる
何よりうれしいのは、ここまで説明してきたことはすべて今日から試せるということです。次はあなたの番です。セットアップはこちらです。
- Slack 上の Seer agent
- プロジェクトで有効化した Seer autofix
- Claude routines または Cursor の自動化
- GitHub CLI
Seer autofix について、ひとつだけ補足です。すべての問題に対して自動で PR を作成するわけではありません。PR を作成する前に、Seer はその問題の修正可能性と深刻度を評価します。その基準の詳細は、ドキュメントに記載されています。
Seer autofix を初めて利用する方は、まずは 14日間の無料トライアルをお試しください。トライアルが終了しても自動で課金されることはなく、継続を決めた場合にのみ料金が発生します。その後は、アクティブコントリビューター1人あたり月額40ドルで、無制限に利用できます。
Original Page: How we built an automated debugging workflow at Sentry
IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談は「お問い合わせ」からお気軽にお問い合わせください。
