深夜アラートの一次調査をAIに任せる｜読み取り専用で回す設計

深夜2時、スマホの通知で起こされる。ノートPCを開き、ダッシュボードにログインしてログを追う。30分かけて分かったのは「すでに自動で復旧していた」という事実だけ。運用・監視チームに配属された人なら、一度は経験があるのではないでしょうか。

この記事では、障害対応の一次調査をAIに任せる動きを、実際の運用事例をもとに整理します。どこまで任せられるのか、任せる前に人間側で何を整えるべきかが分かります。

結論から言うと、一次調査は今の技術で十分に任せられます。ただし条件が二つあります。AIの権限を読み取り専用に絞ること、そしてアラートそのものを先に減らしておくことです。

障害対応の一次調査をAIに任せるとは?深夜にPCを開かない運用

一次調査をAIに任せるとは、アラートが鳴った直後の「何が起きたかを調べる」部分だけを自動化することです。復旧の操作は人が行い、AIは状況をまとめて報告する係に徹します。

この切り分けが有効なのは、一次調査のほとんどが情報を集める作業だからです。集めるだけなら、システムを壊す心配がありません。

サイバーエージェント傘下のAJAでは、実際にこの形が動いています。監視ツールのDatadogから月に十数件から数十件のアラートが飛び、その大半は自動で復旧するものの、たまに危険なものが混ざる。そのため一次調査に毎回10分から1時間かかっていました。そこで、GitHubのIssueに「ai-investigate」というラベルを付けるとGitHub Actionsが動き、AIがDatadogとGitHubを読んで調査結果を書き込む仕組みを作っています。

結果として、オンコール担当は深夜にPCを起動する必要がなくなり、AIの回答を待つあいだ仮眠を取れるようになったと報告されています。一次調査は「人が起きて手を動かす作業」ではなくなりつつあります。

なぜ障害対応でAIが効くのか｜手順が毎回ほぼ同じだから

障害対応でAIが効くのは、一次調査の手順が毎回ほとんど同じだからです。

アラートを受けたときにやることを思い出してください。該当サービスのダッシュボードを開き、発生時刻の前後でログを絞り込み、直近のデプロイや設定変更を確認し、似たインシデントが過去になかったかを探す。順番まで含めてほぼ固定されています。

料理でいえば、下ごしらえに当たる部分です。野菜を洗って切る工程は誰がやっても同じで、味を決める工程だけが腕の見せどころになります。一次調査は下ごしらえで、「どう復旧するか」の判断が味付けにあたります。

だからこそ、手順が固まっている部分から渡すのが近道です。判断まで一気に任せようとすると、かえって信用できない仕組みになります。

障害対応AIの権限設計は読み取り専用から始める

障害対応にAIを使うときの大原則は、権限を読み取り専用に絞ることです。

理由は単純で、書き込みを許すと調査の誤りがそのまま二次被害になるからです。AIが「このプロセスを再起動すれば直る」と判断して実行し、それが的外れだった場合、元の障害より深い穴が空きます。

先ほどの事例でも、AIに許したのは情報を読む操作だけでした。使えるコマンドをghやgcloud、bqといった参照系に限定し、監視ツールへの接続も読み取りのみ。本番環境への書き込みは最初から禁止しています。この線引きは、AIエージェントの暴走を4層で止める考え方とも重なります。

読み取り専用なら、最悪の失敗は「見当違いの仮説が書かれる」で済みます。人が読んで捨てればよいだけです。

障害対応にAIを載せる前に｜例外と障害を分けてアラートを減らす

AIを載せる前にやるべきことがあります。アラートの定義を見直し、鳴る数を減らすことです。

アラートが多すぎる現場では、通知の基準が「例外が発生したか」になっていることがよくあります。例外とは、プログラムが失敗を呼び出し元に伝えるための仕組みです。入力ミスでも一時的な通信断でも発生するため、例外の有無は人が動くべきかどうかの基準になりません。

この点について、通知すべきなのは「復旧作業が必要な事象」だけだと整理した技術記事があります。リトライやフェイルオーバーで自力回復したものは障害と呼ばない、という線引きです。この基準で棚卸しすると、通知の多くは消えます。

この線引きは個人の思いつきではなく、監視の世界では以前からの原則です。GoogleのSRE本は呼び出し（ページ）の条件として「すべての呼び出しは対応可能であること」「すべての呼び出しへの対応には知性が要ること」を挙げ、機械的な対応で済むものは呼び出しにすべきではない、と明記しています。あわせて「緊急感を持って反応できるのは1日に数回までで、それを超えると疲弊する」という前提も書かれています。AIに渡してよいのは、この基準を通ったあとに残る通知だけです。

数が減らないままAIを載せると、今度はAIの調査レポートが大量に積み上がります。オオカミ少年が人からAIに替わるだけで、読まれない報告が増えるだけです。まずアラートを絞り、それからAIに渡す。この順番は逆にしないでください。

運用1〜3年目が障害対応AIから学ぶべきこと

ここからは筆者の考えです。一次調査が自動化される流れは、若手にとって不利ではないと見ています。

先ほどの事例では、AIを入れたあとにジュニアメンバーの参加が増えたと報告されています。仕事の中身が「ゼロから調べる」から「AIが出した仮説を検証する」に変わったためです。調査の出発点が用意されている分、経験が浅くても議論に入りやすくなります。

ただし、検証には土地勘が要ります。AIが「デプロイ直後に応答時間が伸びています」と書いたとき、それが本当に原因かを疑えるかどうかは、自分でログやメトリクスを追った経験に左右されます。分散トレーシングの基本やアクセスログの読み方を一度は手で確かめておくと、AIの出力を鵜呑みにせずに済みます。

つまり、これから伸びるのは調べる速さではなく、疑う精度です。AIが仮説を出す係になるほど、検証する側の価値は上がります。

判定そのものをAIに任せる道具も出てきています。文章を書かずに確率つきの判定だけを返すモデルについては、文章を書かないAI「Jev」の記事で整理しました。

鳴ったり鳴らなかったりするアラートの見分け方は、テストの世界のFlaky Testの4つの原因と同じ考え方で整理できます。

コマンドの出力を読んで判断する自動化は、OS側の変化で黙って壊れることがあります。UbuntuのlsがRust製になった影響もあわせて確認してください。

AIにチケットや監視ツールをつなぐMCPサーバーの危険と確認項目は、MCPサーバーの4つの危険と接続前の7確認にまとめました。

AIの調査結果を受け取ったあと、人がどう動くかはインシデント初動で新人がやる5つのことで整理しています。

AIに任せない手作業の部分も、手順と結果を同じ場所に残しておくと後から検証できます。考え方は手順書のコピペ運用をやめる｜実行できる手順書LC4RIの考え方で整理しました。

まとめ｜障害対応をAIに任せる前に押さえる3点

• 一次調査は手順が定型なのでAIに任せやすく、深夜のPC起動をなくせる
• 権限は読み取り専用に絞る。書き込みを許すと調査ミスが二次被害になる
• 先にアラートを「復旧作業が必要か」で絞り込み、数を減らしてから渡す

まずは自分のチームのアラートを一覧にして、直近1か月で人が実際に手を動かしたものが何件あったかを数えてみてください。AIに渡す準備は、その1件から始まります。

参考リンク

• MVP から始める、障害対応における AI 活用 | CyberAgent Developers Blog
• Monitoring Distributed Systems – Google SRE Book（呼び出しの原則。アラートを絞る基準の一次情報）
• エラー対応設計: 例外と障害を区別しよう – Qiita（例外と障害の切り分けを整理した個人の技術記事。棚卸しの手順の参考にした）