ユーザー報告バグの監視と仕分けを行うAIエージェント

本番環境のバグは、都合の良いタイミングで報告されることは決してありません。誰もリアルタイムで見ていないログの流れの中に埋もれたエラーとして現れることもあれば、技術的な原因を知らない顧客が症状だけを説明して起票したサポートチケットとして現れることもあります。この両者の間には、自動的なつながりが存在しないことがほとんどです。エンジニアリングチームは、サポートが最終的にエスカレーションしてから、つまり最初のユーザーが問題に遭遇してから数時間後に、ようやく問題を発見することになります。両方のフローを同時に監視する自律型AIエージェントは、このギャップを埋めます。

課題

開発者が新しいコードの執筆ではなくバグ修正に費やす時間は、ソフトウェアエンジニアリングにおいて最もよく裏付けられた生産性の損失の一つです。Rollbarが950人の開発者を対象に実施した(Propeller Insights経由の)世界的な調査によれば、開発者の32%がコードを書くよりもバグ修正に週最大10時間を費やし、38%は労働時間の最大4分の1をこれに費やしているとされています(出典)。この調査は2021年のものであり、最新の測定値というより目安として読むべきですが、エンジニアリングの時間のかなりの部分が構築ではなく修正に吸収されているというこの調査結果自体は、より最近の開発者生産性に関する調査でも一貫して確認されています。

本当の争点は修正にかかる時間だけではなく、問題が発生してから検知されるまでの遅延です。DORA State of DevOps 2024レポートは、この点について明確な基準を示しています。最も成果の高いチームは劣化したサービスを1時間以内に復旧させ、非常に高い成果を出すチームは1日以内、中位のチームは1日から1週間、成果の低いチームは1週間から1か月かかることがあるとされています(出典)。この基準の上位と下位の差は数時間ではなく数週間にのぼり、この遅延は、異常が修正される前の段階で、いかに速く検知され正しく優先順位づけされるかに直接左右されます。

問題が本番環境に及ぶとき、この遅延には直接的なコストが発生します。2023年11月から2024年3月にかけて世界1,000社以上を対象に実施されたITIC 2024の調査によれば、中規模・大規模企業の90%以上でダウンタイム1時間あたりの平均コストが30万ドルを超え、大企業の41%はこの1時間あたりのコストを100万~500万ドルと見積もっているとされています(出典)。これらの数字は大規模障害に関するものであり、個々のバグすべてに当てはまるわけではありませんが、誰も継続的に監視していないログの流れに埋もれたまま、早期に検知できたはずの問題が長く見過ごされたときに何が懸念されるかを示しています。

似た用途を混同しないために、一点明確にしておくべきことがあります。デプロイが本番環境に届く前のビルドとテストの失敗を扱うCI追跡は、ここで扱う課題とは別物です。このページが扱うのはデプロイ後の監視、つまりユーザーの環境で実際に発生するエラーと、それを説明するために彼らが起票するサポートチケットという、しばしば同じインシデントを語りながら自動的には突き合わされない2つのフローです。

この突き合わせの欠如は、優先順位づけに具体的な影響を及ぼします。ログ上で目立たない5件の技術的エラーしか生まないバグでも、同じ内容の20件のサポートチケットを生んでいれば緊急対応に値します。逆に、100件の技術的エラーを生んでも顧客からのクレームが1件もないバグは、次のサイクルまで待てることが多いのです。両方の情報源を突き合わせなければ、エンジニアリングチームは技術的な発生量だけをもとに、実際のユーザー影響を必ずしも反映しない判断で優先順位を手探りで決めることになります。

エージェントが行うこと、そのステップ

エージェントは、本番環境のエラーフロー、レイテンシの指標、アプリケーションログを継続的に監視します。これは従来型の監視ツールと同じ原材料です。違いは次の段階から始まります。並行してユーザーが起票したサポートチケットを監視し、スタックトレースではなく日常的な言葉で技術的な異常を説明している報告を特定します。続いて、単純なアラートシステムのように個別の発生をそれぞれ処理するのではなく、同じ問題を説明しているエラーとチケットをまとめます。この集約結果をもとに、異常の発生頻度、推定されるユーザー影響、重大度を評価します。GitHubまたはLinearに、問題の説明、スタックトレース、影響の推定、そしてすでに設定済みの優先度を添えた構造化されたissueを作成します。この整理済みのコンテキストとともにSlackで関係チームに通知し、あらかじめ定めた重大度のしきい値を超えた場合にのみオンコール担当者へエスカレーションします。

活用しているインテグレーション

検知はDatadog、あるいはエラーとスタックトレースの追跡に特化したツールを好むチーム向けにはSentryを土台とします。ユーザー体験との突き合わせはIntercom、あるいは導入済みのサポートツールに応じてZendeskを介して行われ、起票されたチケットと監視側で検知された技術的エラーを照合します。issueの作成は、チームの追跡ツールに応じてGitHubまたはLinearで行われ、説明、スタックトレース、優先度がすでに記入された状態になります。Slackがチームへの通知を担い、定められたしきい値を超える重大度のインシデントについてはPagerDutyへのエスカレーションを発生させることもできます。

人間に残る役割

エンジニアリングチームは、エージェントの設定時に重大度のしきい値とエスカレーションルールを定義します。この初期設定が、その後何がオンコールへのアラートを発生させるかを左右します。チームは、スタックトレースと推定影響を含めてすでに仕分けと文脈付けが済んだissueを受け取り、生のログからコンテキストを再構築するのではなく修正の作成に専念できます。プロダクトが進化するのに応じて優先順位づけのルールを調整します。新しいモジュールや新しいインテグレーションが加われば、ある時点で何が重大とみなされるかは当然変わるからです。緊急のホットフィックスにすべきか計画的な修正にすべきかという修正そのものの判断は、完全に人間の意思決定であり続けます。

測定可能な成果

最も直接的な成果は、本番環境で問題が発生してから、対応可能なissueとして報告されるまでの遅延の短縮です。ログの流れに埋もれたり、同じ症状を説明しながら関連づけられていない複数のサポートチケットに散らばったりすることがなくなります。DORAレポートが示す、最も成果の高いチームの1時間以内の復旧と、中位チームの数日にわたる復旧との差を踏まえると、検知と仕分けの時間を短縮することは、平均に留まるのではなくこの基準の上位に近づく能力に直接効いてきます。第二の成果は、オンコール担当者への雑音の減少です。あらかじめ定めたしきい値を超える異常だけをエスカレーションすることで、些細なエラーによる不要な中断が減ります。これは、拡大されたオンコールのローテーションを持たない少人数チームにとって特に重要な点であり、夜間の呼び出し一つひとつが翌日の稼働能力と集中力に直接影響し、雑音の除去が不十分なまま数週間続けば累積的な影響も生じます。