AIに原因調査を頼む前に、見る材料を三つ決める

サービスの調子が悪いときほど、AIに「原因を調べて」と投げたくなります。画面が重い、購入できない、昨日の午後からエラーが増えた。そういう報告は、言葉だけでそれらしい原因候補を出せてしまいます。

つらいのは、原因候補がそれっぽいほど安心してしまうことです。実際には、見たログ、見たメトリクス、関係しそうなコード、発生時刻がそろっていないと、ただの説明上手な仮説で止まっているかもしれません。

AIを使わないほうがいい、という話ではありません。むしろ、焦っている場面ほど壁打ち相手は助かります。ただし、AIに渡す前に「何を証拠として見るか」を先に分けておくと、答えを鵜呑みにしにくくなります。

元になった研究は、一般的なコード修正ではなく、オンコールでの原因分析に近い設定を作っています。ユーザーからのあいまいな報告を起点に、Prometheus のメトリクス、OpenSearch のログ、Jaeger の分散追跡情報、ソースコードを見ながら、原因を特定できるかを評価しています。

結果はかなり慎重に読む必要があります。5種類のagentを比べても、現実寄りのMedium条件で最良のRCA Accuracyは25.3%、Hard条件では10.0%でした。GLM-5では、incident task全体で根拠の薄い原因を挙げた割合が40.2%と報告されています。

ここから日常へ借りられる見方は、AIに任せる範囲を小さくすることです。AIに「原因を決めて」と渡す前に、「起きた症状」「見る材料」「人間に戻す条件」を三行で残します。原因の断定ではなく、調査の地図を作る使い方に寄せます。

次に不具合調査や原因確認でAIを使う前に、5分だけ三行メモを作ります。

一行目に「ユーザーに見えている症状と時刻」を書きます。二行目に「最初に見る材料」を書きます。ログ、メトリクス、分散追跡情報、関連しそうなコードのうち、今回はどれを見るのかを三つまでに絞ります。三行目に「人間へ戻す条件」を書きます。

たとえば、「昨日15時ごろからcheckoutで500が増えた」「checkout APIのログ、決済まわりのメトリクス、直近deploy差分を見る」「原因がログ行や時刻に結びつかないなら仮説扱いで止める」と残します。この形なら、AIの出した答えを確認する順番も決めやすくなります。

この論文が直接示しているのは、特定の実験環境で、現行のcoding agentが本番風の原因分析をかなり苦手としていることです。三行メモの効果を検証した研究ではありません。

ただ、AIに調査を手伝ってもらうときほど、人間側の意図と証拠の置き方が大事になります。AIの答えが速く返ってくるほど、「その原因は何を見て言っているのか」をこちらが持っておきたいところです。

慣れてきたら、AIの仮説ごとに「見た材料」「採用した理由」「保留した理由」を一つだけ残します。障害対応の本番ルールを置き換えるのではなく、調査の入口を少し整える。小さな記録が、次の焦りを少し減らしてくれます。