この記事は GLOBIS アドベントカレンダー 19日目の記事です
はじめに
「できるエンジニアは当たり前にやっているのに、組織全体には広がらない」という課題を感じたことはありませんか？
この記事では、Sentryのエラー対応にAIエージェントを組み込んでみて気づいたことを書きます。結論からいうと、できる人がやっている「ひと手間」をAIに常にやらせることで、ワークフロー全体の質を上げられるという発見がありました。
AIエージェントの技術的な実装方法ではなく、組織の暗黙知をどう形式知化し、ワークフローに組み込むかという視点で書いています。
きっかけ：影響範囲の認識ミス
ある日、Sentryからエラー通知が飛んできました。
スタックトレースを見ると、特定のユーザーの処理がこけているように見えたため、「影響範囲は限定的」と判断し、優先度を下げて対応を後回しにしました。
ところが実際には、そのエラーでバッチ処理が止まっていて、該当ユーザー以降の全ユーザーの処理が停止していました。忙しいときの通知は見落としがちです。
後日、SentryのJSONをClaude Codeに食わせてみたら、こんな回答が返ってきました。
| 影響 | 詳細 |
|---|---|
| 直接的影響 | 該当ユーザーの登録が失敗する |
| 波及的影響 | Workerがエラーで中断し、そのユーザー以降が処理されない |
| 永続的影響 | last_converted_atが更新されないため、次回実行時も同じレコードから再処理 → 無限ループ状態 |
初動では「特定のユーザーがこけた」という認識だったのに、AIは「波及的影響」「永続的影響」まで指摘できていました。
スタックトレースのJSONを丁寧に分析するという「ひと手間」をかけていれば、もっと早く気づけたかもしれません。でも忙しいときにそのひと手間は省略されがちです。
このひと手間を、AIに常にやらせればいいのでは——これがAIエージェントを開発ワークフローに組み込むきっかけになりました。
問題：細かいところが属人化している
いろいろなチームと働いていると、エラー対応の基本的なフローは共有されていても、細かい動きが人によって違うことに気づきます。
Sentryのエラーを見るとき、スタックトレースのJSONをClaude Codeに解析させる人もいれば、UIで見える範囲だけで対処する人もいます。ライブラリのアップデートでも、GitHubのissueまで確認する人もいれば、リリースノートだけ見る人もいます。
優れた振る舞いをしている人は「ひと手間加えて仕事の質を上げている」という感覚がありますが、このひと手間が属人化していて、組織全体には広がっていませんでした。
アプローチ：ひと手間をAIに常にやらせる
この問題に対するアプローチは、属人化している「ひと手間」をAIエージェントに移植するというものです。
人間がひと手間を加えるのはコストがかかります。忙しければ省略されるし、人によってやったりやらなかったりします。でもAIなら安いので、ひと手間を常にかけるワークフローとして組み込みやすい。
できる人がやっているひと手間を、AIに常にやらせれば、人によるばらつきがなくなり、ワークフロー全体の質が底上げされます。
設計の順番としては、「最終的にAIで完結できるかを先に考え、人間が必須なところを当てはめていく」 としています。AIはスケールしやすいけど人間はスケールしないため、人間起点で設計すると、スケールしないボトルネックを残すことになるからです。
事例：Sentryエラー対応のワークフロー
1つのプロダクトでトライアル運用中です。現在は6までを運用に載せています。
- エラー通知が飛ぶ
- Sentry issueがGitHub issueに連携（Sentryの機能）
- issue作成をトリガーにエージェント起動
- AIがSentry MCPを叩いてエラーのJSONを取得
- AIがトリアージ（優先度、影響範囲、担当チームを予測）
- AIがエラー内容を分析し、issueにコメント
- AIが修正PRを立てる
- 人間がレビュー
ポイントは、4〜6の「ひと手間」をAIが常にやるようになっていることです。人間がやると省略されがちなスタックトレースの詳細分析や影響範囲の予測を、AIがワークフローとして毎回実行します。
最終的に人間が入るのはレビューだけにする予定です。AIは確率的に動くのでばらつきが出るため、プロダクションコードへの修正は人間の確認でクオリティを担保したい。ここが「人間が必須」と判断した箇所です。
issueへのコメントは、エンジニアがレビューしやすくするためだけでなく、後続のAIが参照したり、人間にバトンタッチする際の経過ログとしても機能します。
スタックトレースから既存コードを検索して判断するので、一定の精度が出ています。AIが間違えても人間が引き継げば良いため、間違いを前提にワークフローを設計しています。
運用してみての手応え
数週間運用した体感として、AIのトリアージ判断は「問題ない」と判断したケースで精度が高いです。実際にAIが問題ないと判断したissueに対して、後からエンジニアが確認して「問題ない」とコメントしているケースがいくつもあります。
一方で、頻度は低いものの、人間が見たときより重く判断する場合もあります。ただ、エラー対応において「見逃し」より「過剰反応」のほうがリスクが低いので、この傾向は許容範囲と捉えています。
発見：AIを入れるために形式知化が必要になる
一番の発見は、AIを入れるために形式知化が必要になるということでした。
「ひと手間」をAIにやらせるには、そのひと手間を言語化しなければなりません。「できる人はなんとなくやっている」では、AIに移植できないからです。
その過程で、組織に眠っていた暗黙知が炙り出されていきます。スタックトレースの扱い方の差も、ライブラリアップデート時のissue確認の有無も、AIのワークフロー設計の過程で見えてきた差分です。
形式知化は簡単ではありませんでした。人の挙動はログに残らないし見えないため、一緒に仕事をしたり、エラー対応に入ったりして「優れた振る舞い」を観察し、ワークフローに落とし込みました。
結果として、AIのやり方が組織の標準になり、ベストプラクティスが可視化されました。AIエージェントにワークフローを寄せることで、ひと手間が「たまにやる人がいる」から「常に実行される」に変わりました。
振り返れば、AIを入れる前に人間同士で共有しておくべきことも多かったです。形式知になっていなかったことで、作業フローがばらついてエラーや手戻りにつながっていました。AIエージェント導入は、そうした負債を返済する機会にもなっています。
おわりに
開発組織には、得意不得意がある人たちが集まっています。できる人がやっている「ひと手間」をAIエージェントに移植することで、その動きを組織全体に届けることができます。
業務フローにAIエージェントを組み込むなら、まずチームの中で「この人はひと手間かけているな」と感じるエンジニアを観察してみてください。その動きを言語化できれば、AIエージェントに移植する第一歩になります。
Discussion