第185号

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

AIに仕事を任せるには、まずその仕事がコードになっていなければならないというMetaの5年間の結論

AI・テック

アン・グァンソプ（Oswarld）· INLEVEL9 著者・編集者

Google の優先ソースに追加
Metaが障害調査の判断をAIに委ねない理由

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

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

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

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

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

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

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

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

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

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

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

⚠️ 論文第9章の教訓：診断をAIベースのシステムに過度に依存してはならない

ここまでは、よくある自動化のサクセスストーリーです。しかし、論文の第9章「得られた教訓（Lessons Learned）」に進むと、次のような小見出しが目に飛び込んできます。

「診断をAIベースのシステムに過度に依存してはならない」（Do not over-index on AI based systems for diagnosis）

地球上でも指折りの規模のAIインフラを運用している企業が、自社の障害調査に関する論文にこれを教訓として掲げているのです。

誤解のないよう、あらかじめ補足しておきます。MetaがAIを全く使っていないという意味ではありません。DrPのSDKには、異常検知、時系列相関分析、次元分析といった統計・機械学習ライブラリが一通り揃っています。コードや設定変更のイベント数千件をスキャンし、「これが原因である可能性が高い」と優先順位をつけるランキングモデルも稼働しています。

MetaがAIに委ねていないのは、判断の順序と条件です。何をどの順番で確認し、どのような条件なら次に何を見るべきかという決定木は、人間がコードで記述します。AIはその手順の中で、異常検知や原因候補の順位付けといった個々のステップを処理するツールとして使われています。

その理由も論文に記されています。純粋な機械学習システムの限界は、学習データの品質、調査時点で実際にアクセス可能なデータの構造、そしてチームごとにワークフローを調整することが難しい点にあります。そのため、彼らが辿り着いた結論は、コミュニティの専門性に基づくルールベースの提案に、AIを補材として組み合わせるアプローチでした。

論文を読み進める中で、その隣に並んでいたもう一つの教訓も目を引きました。タイトルは「支援か、それとも完全自動化か（Assistance vs. Full Automation）」です。

Metaの当初の目標は完全自動化でした。しかし、途中で方針を転換しました。理由は3つありました。第1に、システムが絶えず変化するため、アナライザーがすぐに陳腐化してしまうこと。第2に、統計や機械学習には必ず過検出（誤検知）や見落としが伴うこと。そして第3に、文化的な側面として、エンジニアやオンコール担当者が完全自動化されたシステムを常に信頼するとは限らないことでした。

前者の2つは技術の課題です。3つ目は人間の課題です。5年間、300チームで1日5万件を回し続けた結果、Metaが完全自動化を取り下げた背景には、単なる精度の問題だけでなく、エンジニアやオンコール担当者が自動化の結果をいつでも信じるわけではないという現実がありました。

論文に掲載されている自社アンケートがそれを裏付けています。「DrPはどれくらいの頻度でMTTRを短縮してくれますか？」という質問に対し、「常に」と答えた人は5.9%にとどまりました。最も多かった回答は「たまに」（47.1%）でした。論文ではこれを「80%以上が改善を報告した」と要約していますが、間違いではないにせよ、回答の重心が明らかに「たまに」側にあることは否めません。ちなみにパーセンテージから逆算すると、回答者数は17人規模です。300チームが使うシステムの調査としては標本が非常に小さいため、この数値は参考程度にとどめておくのが適切でしょう。

📉 平均20%と一部チームの80%を分けたのはアナライザーの数だった

Metaのエンジニアリングブログは、その成果を「MTTRを20〜80%短縮した」と記しました。範囲のように読めますね。普通なら「40〜50%くらいは出るのだろう」と受け流してしまいがちです。

しかし、論文のアブストラクト（要約）には異なる書き方がされています。平均20%。一部のチームでのみ80%以上。 同じ数字の並びであっても、意味合いは全く異なります。

論文の第7章を開くと、その理由が分かります。

  • アナライザー5個未満 → 10〜15%
  • 10個以上 → 50〜80%
  • 全社平均 → 20%

つまり、80%という数値はシステム自体のポテンシャルではなく、そのチームがアナライザーをどれだけ作り込んだかに依存していたのです。自チームの調査手順をどこまでコード化できたかが、成果の明暗を分けました。

論文7.2.4節のチーム別データを見ると、それはより鮮明になります。

  • チーム1：アナライザー136個、改善率82%
  • チーム2：92個、75%
  • チーム3：66個、84%
  • チーム4：48個、69%
  • チーム5：39個、58%
  • チーム6：29個、73%
  • チーム7：23個、56%
  • チーム8：12個、7%

最後の行に注目してください。チーム8はアナライザーを12個作成しています。論文自らが定めた「10個以上」という基準を満たしているにもかかわらず、改善率は7%にとどまりました。論文が提示した基準が、自らの表の数値と食い違っているわけです。成果が大きく跳ね上がる境界線は、12個と23個の間のどこかに存在します。

ここで、私自身が試算してみたことがあります。2,000個のアナライザーを300チームで割ると、1チームあたり平均6〜7個になります。そして論文自身が、5個未満なら改善率は10〜15%にすぎないと述べていました。これが何を意味するでしょうか。Metaの社内であっても、中央値付近に位置するチームは依然として投資対効果の低い領域に留まっているということです。 全社平均が20%で頭打ちになっている理由はここにあります。

投じる時間も決して少なくありません。論文によれば、単純なアナライザーであれば1日で作れるものの、あるチームの調査ワークフローを過不足なく網羅するには数カ月を要します。ツールを購入する時間ではなく、知見をコードへと移し替えるための時間です。

最後に、MTTRの絶対値にも触れておきましょう。チーム1の場合、771時間から139時間へと短縮されました。32日かかっていたものが5.8日になった計算です。これはサービスがダウンしていた時間そのものではなく、事後レビューまでを経たインシデントの検知から解決に至るライフサイクル全体を指します。「MTTRの20%短縮」と聞くと小さく感じられるかもしれませんが、ベースラインがどれほど長大であるかも併せて見る必要があります。

一点付け加えると、この表のチーム7の行は、前後の数値から再計算すると36%になるのですが、論文には56.1%と記載されています。残り7つの行は小数点以下まで整合しているため、単なる誤植の可能性が高いといえます。もっとも、他者のまとめた表をそのまま鵜呑みにする前に、一度電卓を叩いてみるべき好例ではあります。

🔁 Metaが今になって「AIネイティブ」を語れる理由

Metaのブログの結びは、次のような文章で締めくくられています。今後はDrPをAIネイティブなプラットフォームへと進化させていく、と。

不思議に思いませんか。「AIに過度に依存するな」と書いておきながら、そのすぐ後の段落でAIネイティブを目指すと語っているのですから。

しかし、これは矛盾ではありません。AIを導入する前に、まず済ませておくべき地ならしがあったという意味です。

過去5年間にMetaが実際にやってのけたことを振り返ってみましょう。Wikiドキュメントや個人のスクリプト、シニアエンジニアの記憶の中に散乱していた調査ノウハウを、次のような形へと再編しました。

  • 型定義されたコードへ（調査手順が分岐と条件によって明示される）
  • 構造化された出力へ（結果が機械可読なフォーマットで出力される）
  • 実行履歴が残るデータへ（過去30日分の調査の入力と出力を蓄積）

とりわけ決定的だったのが3点目です。Metaはアナライザーを改修するたびに、過去の調査ログを再実行して挙動を検証するバックテスト4の仕組みを構築しました。元々の目的はバグの混入を防ぐことでした。しかし結果として、障害調査のプロセスそのものが正解ラベル付きのデータセットへと昇華したのです。

AIエージェントが障害調査を担うには、3つの要素が不可欠です。第1に、データにアクセスするためのツール群。第2に、何をどのような手順で確認すべきかを定めたプロトコル。第3に、過去にどのような判断が正しかったかを検証できるログ記録。DrPがこの5年間で作り上げてきたのは、まさにこの3点でした。

論文にはもう一つ、印象的な教訓が記されています。見出しは「データこそがすべて（Data is Key）」です。観測データの品質、そしてサービスの依存関係やデータの来歴（データリネージ）といった構造化されたメタデータ。これらが存在しなければ、相関分析そのものが成立しません。どれほど優れたモデルを調達してきたところで、接続する相手がいないのです。

したがって、タイトルの問いに対する答えは次のように整理できます。Metaが判断をAIに委ねてこなかったのは、AIが活用できるレベルの手順コードと調査ログがまだ十分に蓄積されていなかったからです。そして今、その準備がようやく整ったと判断したわけです。

AIに人間の仕事を代行させたいのなら、その業務はあらかじめコードになっていなければなりません。モデルがどれほど進化しようとも、組織のナレッジがWikiのドキュメントや誰かの頭の中に眠っている限り、AIの出番はどこにもないのです。

🇰🇷 韓国の組織は今どの段階にあるのか

去る6月24日にソウルで開催されたカンファレンスにて、サムスン電子MX事業部のクラウドチームが自社のロードマップを公表しました。Samsung Pay、Bixby、Galaxy Storeを含む50以上の顧客向けサービスの信頼性を支える中央SRE5組織です。

彼らが提示した成熟度モデルは4段階でした。「事後対応」「自動対応」「予測運用」「自律運用」です。そして、自ら診断した現在の立ち位置は、最初のステップである「事後対応」でした。自律運用のターゲット時期は2028年としています。韓国国内でもトップクラスのSRE組織による自己評価がここにあるという事実は、その他の組織が現在どの座標にいるのかを雄弁に物語っています。

注目すべきは、ユ・ヒョンソングループ長が発表を締めくくった一言です。自動化の適用範囲を広げたとしても、最終的な責任と判断は人間の領域に残るということ。これはMetaの論文が導き出した「支援か、それとも完全自動化か」と寸分違わぬ結論です。

同じイベントで、KTのピョン・ウチョルPalantir事業本部長はより直言しました。経営陣の焦りから根本的な課題に手をつけることなくAIの導入ばかりを急ぎ、そのせいで成果が出ないのだと。彼が指摘した解決策は、データをAIが解読できる構造へと整理することでした。Metaの論文にある「データこそがすべて」と軌を一にする指摘です。

実際に成果を上げている韓国内の事例もあります。ヤノルジャ（Yanolja）は今年4月、6チーム14名が6週間にわたり6つの運用エージェントを構築したと発表しました。そのうち障害対応エージェントは、障害の発生からポストモーテム（事後レポート）の作成まで従来2週間を要していたプロセスを24時間にまで短縮しました。ただし、そのアーキテクチャを紐解いてみると、ここでもエージェントは社内のナレッジベースや文書を検索するインフラの上で稼働しています。体系化された知識が先行して存在して初めてエージェントが機能するという構図は、Metaの事例と全く同じです。

Oswarldの視点

論文第9章に並ぶ6つの教訓を改めて数え直してみました。その中に、モデルの精度や性能に言及したものはただの1行もありません。 そのすべてが現場への導入・定着（アダプション）に関する話でした。

コミュニティ自身に作らせること。ユーザーがいる場所へ赴くこと。すでに使われているワークフローの中に組み込むこと。とりわけ印象に残ったのは次のフレーズでした。アナライザーの開発は、大半のソフトウェアエンジニアにとって本職の業務ではないということ。だからこそMetaは、1日で作れるようにSDKを磨き込み、コードエディタの中から直接結果を確認できる開発体験を整えたのです。

20年以上にわたってGTM（市場投入）戦略を策定する中で、幾度となく目撃してきたパターンがあります。組織が新たなツールを検討する際、最初に発する問いは決まって「どれくらい正確なのか」です。しかし、実際の現場での定着率を左右するのは、ほぼ例外なく「どれくらい面倒でないか」なのです。精度が95%のツールであっても、それを使うためにウィンドウを余計に3つ開かなければならないとすれば、そのツールは使われません。精度が70%にとどまっていたとしても、普段から見ている画面に最初から結果が表示されていれば、それは使われます。 Metaが分析結果をアラート画面へダイレクトに貼り付けたのも、性能を高めるための決定というよりは、エンジニアが日常的に見ている画面の中で使わせるための決定でした。

それゆえに、多くの組織が「どのAIエージェントを導入すべきか」から検討を始めるのは、アプローチの順序が逆転していると私は考えています。まず点検すべきは、自分たちのチームが日々の現場で繰り返している判断手順のうち、いくつがコードとして書き起こされているかです。 その数がゼロに近いのなら、市場からどんなに優れたモデルを買い集めてきても、それを繋ぎ止める場所などどこにもありません。

おわりに

Metaが5年間にわたり1日5万件規模で回し続けた障害調査システム。それを実際にドライブしていたのは、華々しいAIエージェントではなく、現場のエンジニアたちが愚直に書き溜めた2,000個のアナライザーでした。成果の分水嶺となったのもモデルの性能ではなく、各チームがアナライザーをどれだけ作り込めたかという一点に尽きます。 今のMetaが「AIネイティブ」を語れるのも、5年という歳月をかけて現場の暗黙知を機械可読なフォーマットへと愚直に移植し終えたからにほかなりません。

さらに深掘りしてみたい方は、論文の第9章「Lessons Learned」だけでも目を通してみてください。わずか3ページの中に、5年分の試行錯誤のエッセンスが余すところなく凝縮されています。

読者の皆さんのチームで、毎回同じ順序で繰り返している判断手順を一つ思い浮かべてみてください。それが今もWikiや誰かの頭の中だけに留まっているとしたら、なぜ今までコードになれなかったのでしょうか。時間が足りないからでしょうか、それとも手順が人によって違うからでしょうか。最大のボトルネックをぜひコメント欄でお聞かせください。今後のテーマ設定の参考にさせていただきます。

💬 上記の問いに関するご自身の経験を、ぜひコメント欄でお聞かせください。次回の配信で取り上げさせていただきます。 📨 運用の自動化やAIの導入に頭を悩ませている同僚がいらっしゃいましたら、ぜひこの記事をシェアしてください。

私は毎週火・木・日曜日に、テクノロジー、経済、そして人文知を交差させながら、その接点で見出した考察をお届けしています。今日のように、1本の論文をじっくりと読み解いて整理する日もあります。

あなたの視点が次の号をつくります

この号で最も共感した点、あるいは違う経験をした点はどこですか。

読者アカウントがあれば無料でコメントできます。

参考資料と関連リンク

主要出典

  • Shubham Somani ほか13名、“DrP: Meta’s Efficient Investigations Platform at Scale”, arXiv:2512.04250 [cs.SE], 2025年12月：7.2節（MTTR評価）と9節（得られた教訓）が本稿の主要な論拠です。お時間がない場合は9節の3ページを読むだけでも十分な価値があります。
  • Meta Engineering, “DrP: Meta’s Root Cause Analysis Platform at Scale”, 2025年12月19日：論文の公式サマリー記事です。ただしMTTRを「20〜80%」と圧縮して表記しているため、原典とはニュアンスが異なります。数値を引用される際は論文の記述を参照することをお勧めします。

背景知識

アン・グァンソプ（Oswarld）のイラスト

著者 アン・グァンソプ（Oswarld） は世宗大学校 兼任教授、INLEVEL9 戦略コンサルタントです。経歴、研究、著書、最近の活動は著者紹介で更新しています。 最近の活動 · 2026年7月：HEMA-2: A Consolidation-Aware Tri-Memory Architecture with Multi-Channel Scheduling for Lifelong Conversational AI。

📝 用語解説

각주

  1. MTTR（Mean Time To Resolution）：障害の検知から解決に至るまでにかかった平均時間のことです。Metaの論文では事後レビューまで完了したインシデントのみを対象に算出しているため、単にサービスが停止していた時間ではなく、原因の究明から恒久対応の完了までを含むライフサイクル全体を指している点に留意する必要があります。 ↩

  2. オンコール（On-call）：システム障害の発生時に即時対応できるよう、あらかじめ当番を決めて待機する制度のことです。午前3時にアラートが鳴った際に起き上がらなければならない担当者が、その日のオンコールです。 ↩

  3. 暗黙知（Tribal Knowledge）：公式のドキュメントとして残されておらず、組織内の特定の人物の間で口伝のように共有されている知見のことです。「あのサーバーがおかしくなったときは、まずあそこを確認する」といった類のノウハウを指します。 ↩

  4. バックテスト（Backtesting）：過去のデータを再度投入し、修正後のコードが意図通りの結果を出力できるかを検証するテスト手法のことです。Metaでは直近30日分の調査ログを保管しており、アナライザーに手を加えるたびに自動でこのテストを実行しています。 ↩

  5. SRE（Site Reliability Engineering）：サービスの信頼性や安定性をソフトウェアエンジニアリングのアプローチによって担保・運用する職務、またはその組織のことです。2003年にGoogleで発祥し、オンコールの運用や障害対応はその中核業務に位置づけられています。 ↩

あわせて読みたい過去の号

第184号

ボットに名前とウォレットを与えたCloudflare

ウォレットに入金して使う機能は予告段階にとどまり、今できるのはcloudflare.payアドレスの先取りです。

AI・テック
第179号

「バグ修正だけに専念する」と言えるチームリーダーはなぜいないのか

GitClearの集計でリファクタリング比率は3.8％に激減、重複コードは81％増加。「修正する作業」が評価されない構造的な問題を読み解きます。

AI・テック
第178号

重みは公開されても個人では動かせないオープンウェイト

Kimi K3は重みだけで1.5TBを超えます。演算に一部のパラメータしか使わないMoEモデルでも、自前で動かすには巨大なメモリが必要となる理由を掘り下げます。

AI・テック