複数のプロダクトを横断的にインフラや開発環境の改善などプラットフォームエンジニアリングをしている Product Engineering チームです。
今回はシステム品質向上の一環として、直近の開発 Days でエラー対応の効率化に取り組みました。より技術的な詳細は別途こちらに公開しているので、よろしければそちらもご参照ください。
課題
社内では複数の Web サービスを運用しており、エラー監視は前回の開発 Days で Datadog Error Tracking に集約しました (参考エントリ)。おかげで本番のエラーは迅速に検知できています。
ただ、検知後の対応は人間頼みのままでした。通知を見て、Datadog の Issue でスタックトレースを読み、どのサービスで問題が発生したかを判別し、ソースコードを調査して原因を推測する、という作業が必要になります。
エラー自体は頻発しており、重大なものは多くないとはいえ、毎回この確認が必要でそれなりに時間を取られます。それ以上に厄介なのが開発業務への割り込みです。集中しているところに通知が飛んでくると、いま書いているコードのコンテキストを退避させ、確認後にまた戻る、というのを 1 日に何度も繰り返すことになり、失われる集中のコストが体感では大きいものでした。
休日に発生したエラーは現実的に週明けにまとめて見ることになり、未確認のエラーが積み上がって放置されることも常態化します。この状態では、問題のあるエラーを見逃す危険が常にありました。
実施した内容
一次調査や修正提案は Claude Code 上で Datadog MCP やローカルのソースコードを参照することで、精度の高い分析ができることが分かりました。そこで、この手動フローを自動化し、人間がエラーを確認する時点で分析済みになっている状態を作りました。AI が完璧に直す必要はなく、見た瞬間にある程度の状況が把握できれば、それだけで体験は大きく変わるという狙いです。
「買う」より「作る」を選んだ理由
Datadog 自身も Bits AI SRE という、アラートの一次調査から修正提案までする既製品を提供しています。ただ現時点では、社内のアラート流量に対して費用対効果が読めず、精度も流してみないと評価できないため、採用は保留しました。
代わりに、まず自前で同等のものを作って何が効くかを測る、という順番にしています。仮にあとから商用へ乗り換えるとしても、「どの情報を AI に渡せば当たるのか」というノウハウは評価基準づくりに役立つと思います。
結果
結果として、通知を読んだ瞬間に原因の仮説・影響範囲・修正のたたき台がそろい、エラー発生の初動が「調査作業」から「レビュー」に変わりました。さらに、AI が見当をつけてくれるおかげで実装に関する知識が少なくても取っ掛かりが作れるようになり、チーム全員でトリアージ担当を分担することができるようになりました。
一方で、AI が間違えるパターンは消せません。AI の判断はあくまで一次調査として扱う運用にし、必要に応じて改めて分析、修正をおこないます。
今後
エラー対応はチームの体力を地味に削ります。品質の維持だけでなく新たな価値創出を迅速にするためにも、AI 活用による効率化を進めていきたいと思います。
