AIはオンコールの判断を置き換えない

最近、何人かの人から、AIがインシデント対応を置き換えるかどうか、実際に試したかどうか、そして効果はあったかどうかを尋ねられました。ここでは、私が実際に構築し、実際のインシデントで実行したツールに基づく正直な回答を述べます。

短い答え：判断の置き換えは行いません。判断を下す前に行う30〜90分の下準備（アラートの確認、ログの取得、デプロイ履歴の確認、変更記録の検索、タイムラインの構築）を自動化します。これらの作業はインシデントごとに繰り返され、判断ではなく偵察であり、そのような境界が明確で反復可能なタスクは自動化に適しています。

そこで、Claude Codeスキル「/incident-investigate」を構築しました。インシデントチャンネルを指定すると、次の処理を行います：スレッドを読み取り、重要なエンティティ（サービス、エラークラス、クラスター、実行ID）を抽出；可観測性バックエンドを照会してエラーパターンを特定；デプロイ履歴をチェックし時間的な相関を確認；関連する変更記録を検索；引用付きの構造化仮説を返します。構築には約2時間（2セッション）かかりましたが、実行は3分で、手動で行う30〜90分を置き換えます。

重要なのは1つのルール：少なくとも1つの独立したデータソースで確認できない限り、仮説を立てないことです。ログが不確定でデプロイ履歴に一致するものがない場合、ツールは推測せず「証拠不十分」と答え、次に確認すべきことを正確に指示します。このルールは、以前の経験から追加しました。初期のバージョンでは、未検証の仮説をライブチャンネルに投稿し、インシデントコマンダーが誤ったリードを追跡する時間を無駄にしました。時々優れ、時々自信満々で間違えるツールは、どちらの状態か判断できないため、ツールがないより悪いです。「わかりません、理由はこれです」と言うツールは、人々が使い続けるものです。

効果を検証するため、根本原因が既知の3つの実際のインシデントでリプレイテストを実施しました：

1. タイムアウトカスケード：根本原因はタイムアウトしきい値とトラフィック変動。正しく特定（中程度の確信度）。
2. 不良デプロイ：根本原因は最近のPRの誤ったルーティング。正しく特定（高い確信度）。
3. 上流の停止：根本原因は外部DNS障害。正しく「自分たちではない」と判断。

3件すべて成功。誤った主張はなく、外部原因を内部デプロイのせいにすることもありませんでした。3件目が特に重要です。デプロイは常に行われているため、もっともらしい間違った答えが常に存在します。最近のデプロイを指摘するのは最も怠惰な失敗モードです。「これは自分たちではない、理由はこれ、上流プロバイダを確認して」と正しく言うことは、時間を節約するツールと、誤ったリードを否定するという新たな作業を生み出すツールの違いです。

そのうちの1件のインシデントでは、影響を受けるエンドポイントで持続的なエラーが検出されるまでに10時間のギャップがありました。その10時間の任意の時点でこのツールを実行すれば、3分で根本原因を特定できたでしょう。これは生産性の数字ではなく、発生しなくてもよかった10時間の顧客影響です。

では、インシデントコマンダーを置き換えるのでしょうか？いいえ。コマンダーは依然として、何を伝えるか、いつエスカレーションするか、ロールバックするか様子を見るか、誰を召集するかを決定します。これらはすべて偵察ではなく判断であり、自動化するつもりはまったくありません。変わるのは、その判断が行使されるタイミングです。手動で証拠を再構築した後の45分ではなく、証拠を手にした3分後です。

このパターンはインシデント以外にも一般化できます。人の最初の30〜90分が「同じ3〜4のシステムを同じ順序で照会し、同じ種類のシグナルを探す」ことであれば、それは仕事の説明ではなく関数シグナチャです。関数を自動化し、実際の判断部分は人間に残しましょう。

同様のツールを構築する場合：スキルのコードを書く前に、実際に照会できるデータソースを特定するのに十分な時間を費やしてください——そこに行き止まりがあります。コードに触れる前に「なぜこの設計で、他ではないのか」を一文で書き留めてください。そして、既知の答えを持つ実際の履歴でリプレイテストするまでは、ライブ環境で使用しないでください。これらはAI固有のアドバイスではなく、締め切りプレッシャーの下で省略しがちで、AIツールが十分に安価にしたから実行できることです。

グラウンディングゲート、Claude Codeスキル、インシデント対応ツールについて意見交換したい方は、GitHub、Hachyderm、またはswamp-clubでお会いしましょう。