Metaが障害調査の判断をAIに委ねない理由

1日5万件の障害調査、核心は人間が書いたコードだった

2026年の障害対応ツール市場は、次のような謳い文句で溢れています。「MTTR¹を最大70%短縮」「アラートが鳴れば数十秒で根本原因を特定」「眠らず、コンテキストを見逃さないシニアエンジニアを1人採用するようなもの」。

ところが、この約束を5年にわたり実際に検証し続けてきた企業があります。Metaです。300を超えるチームが利用し、1日に5万件の障害調査を自動で実行しています。昨年12月には、そのシステムの論文を公開しました。

論文が報告した平均的な成果は、MTTRの20%短縮でした。そして、このシステムを実際に動かしているのはAIエージェントではなく、エンジニア自身が作成した調査手順のコードなのです。

成果を阻んでいたのはモデルの性能ではありませんでした。組織内の調査に関する知見が、まだコードへと落とし込まれていなかった点がボトルネックだったのです。

---

🌙 1日に5万回走る調査手順、すべて人間がコードで書いた

Metaが公開したシステムの名は「DrP」です。役割は単純です。アラートが鳴ると、あらかじめ組んでおいた調査手順を自動で実行し、その結果をアラート画面に添付します。午前3時に叩き起こされたオンコール²担当エンジニアは、ダッシュボードを5つも立ち上げてログを漁る代わりに、すでに画面に表示されている分析結果を読むところから調査を始められます。

この「あらかじめ組んでおいた調査手順」を、Metaはアナライザー（analyzer）と呼んでいます。アナライザーは、人間がPythonやPHPで直接書いたコードです。条件分岐とデータ照会が延々と連なっており、障害が発生した際に何をどの順序で確認すべきかをあらかじめ記した手順書の役割を果たします。

その規模を見てみましょう。アナライザーは2,000件以上、利用チームは300以上、運用期間は5年、1日の自動分析は5万件に達します。30日換算で150万件、平均すると約1.7秒に1回アナライザーが実行されている計算になります。

これらのアナライザーが代替したのは、次の3つでした。誰も更新しないWikiドキュメント、各自のノートPCに散らばった個人用スクリプト、そしてシニアエンジニアの頭の中にしかなかった暗黙知³です。論文の表現をそのまま借りれば、彼らのアプローチは組織内に分散していた手動のプレイブックと暗黙知をコード化することでした。

効果は、調査が複雑であればあるほど大きくなりました。論文が3つのシナリオ（単純なサービスエラー、コンテナ障害、AIモデルの特徴量〈feature〉の問題）を取り上げて手動対応と比較したところ、オンコールエンジニアが踏むべきステップ数は4分の1から20分の1にまで減少しました。最も複雑なシナリオにおいて、エンジニアがすべき作業はたった1つに凝縮されました。アラート画面で結果を読むことだけです。

---