AIは危機対応を速くするか――自動トリアージの光と影

システム障害の初動においては、膨大なログ、アラート、メトリクス、トレースのうち、何が重要なのかを短時間で見極めなければならない。SRE（Site Reliability Engineering）の普及によって監視やインシデント対応の仕組みは大きく進歩したが、近年はさらにAIがこの領域に入り始めている。
2026年にはGoogleが、SRE業務においてAIエージェントを障害調査や一部の緩和措置に利用していることを公表している。Microsoftも、ログ、メトリクス、トレースなどを横断して原因候補を提示するAIベースのオブザーバビリティ機能を展開している。

AIが特に力を発揮するのは、初期のトリアージである。数千件のアラートから関連するものをまとめ、過去の障害との類似性を探し、原因候補を提示する。これまで複数の技術者が時間をかけて行っていた作業を短縮できることは、特に「待てない危機」において大きな意味を持つ。
しかし、ここに注意すべき罠がある。分析が速くなるにつれ、その結果を「事実」と受け取ってしまう危険も大きくなるからだ。

AIが提示するのは、多くの場合、観測されたデータから導かれたもっともらしい仮説であり、障害の原因そのものが確定できるわけではない。参照できるログが欠落していれば結論も偏るし、依存関係の情報が古ければ誤った箇所を原因として示す可能性もある。
AIがいくら優れていたとしても一般的なサイバー危機と同様、「現在もっとも可能性が高いこと」と「確認された事実」とは区別されなければならない。
さらに、自動復旧までAIに委ねる場合には問題が一段深くなる。原因推定が誤っていれば、自動操作によって障害を拡大する可能性がある。Google自身もAIをSREの「force multiplier」と位置づけながら、人間によるコントロールを維持する考え方を示している。

したがって、AI時代の危機対応で重要なのは、人間を意思決定から外すことではない。AIに「探す・まとめる・候補を出す」という高速処理を担わせ、人間が「確かめる・選ぶ・責任を持つ」という役割を担うことである。
AIによって危機対応は速くなる。しかし、速くなった分析から得られた情報をどの段階で事実として扱うか。その境界管理こそが、新しい危機修復の課題になるのだ。

トップは情報を「集めすぎない」――高速・高精度を両立する指揮系統

危機が発生すると、トップはできるだけ多くの情報を、直接集めようとすることがある。現場責任者に電話し、技術担当者に説明を求め、各部門から報告を受ける。これは一見すると積極的な危機対応に見えるもの、大規模なインシデントでは、この行動がかえって情報伝達を混乱させることがある。
過去のブログで扱った「情報と権限の分離」を解消することは重要である。しかし、その解決策は、トップがすべての情報源へ直接アクセスすることではない。重要なのは、情報と権限を結ぶ経路を明確にすることである。

この点で参考になるのが、災害対応で用いられてきたIncident Command System（ICS）という発想である。ICSの下では、指揮命令系統を明確にし、一人の担当者が複数の上司から異なる指示を受ける状態を避けることが重視される。また、事故の規模や複雑性に応じて組織を拡張できるよう設計されている。
GoogleがうみだしたSREにおいても、この考え方を取り入れたインシデント管理が採用されている。統括責任者(Incident Commander)とよばれる役職が全体を統括し、復旧対応責任者(Operations Lead)が技術的な復旧を、情報発信責任者(Communications Lead)が関係者への情報提供を担う。重要なのは、通常の組織上の役職と、危機時の指揮系統を必ずしも一致させないことであり、それらの役割は通常の組織において常置されているわけではない。

こうしたシステムが意味するところは、トップの役割を小さくするということではない。
トップが担うべきなのは、「ログに何が出ているか」を自ら確認することではなく、現在の影響範囲はどこまでか、何を優先して守るのか、どの時点でサービス停止や対外発表を決めるのか、といった経営判断、意思決定である。そのために必要な情報を、決められた経路から短時間で取得する必要がある。
トップが現場へ個別に問い合わせを始めると、担当者は復旧作業と経営的な説明を同時に求められる。さらに、異なる部署から微妙に異なる説明を受ければ、「どれが正しい情報なのか」という確認作業まで発生する。情報量は増えても、判断精度が上がるとは限らない。高速・高精度な情報収集とは、大量の情報を集めることではない。意思決定に必要な情報が、適切な粒度で一つの指揮系統に収束することなのである。

危機時のトップに必要なのは、「すべてを知ること」ではない。「誰が何を知っており、誰の情報を基準に判断するのか」が明確になっていることに尽きるのだ。

初動24時間の情報設計――Single Source of Truthをどう解釈するか

大規模な障害が発生すると、組織の中に複数の「事実」が生まれがちである。
技術部門のチャットには最新の調査結果が残されており、経営会議の資料では一時間前の状況が共有され、広報部門にはすでに承認された対外的な説明が準備されている。顧客対応部門は別の資料を参照しているかもしれない。どれも作成時点では間違いのないよう、細心の注意をもって共有されている。

しかし時間の経過とともに内容がずれ、結果として組織内で異なる説明が同時に存在していくようになる。そこで重要になるのが、Single Source of Truth(情報源の単一化、SSOT)とよばれる、参照先を一つにするという考え方である。
GoogleのSREにおけるインシデント管理でも、統括責任者(Incident Commander)の重要な役割として「インシデント状況管理文書(live incident state document)」を維持・管理することが挙げられている。インシデント状況管理文書とは、障害の状態、重要な変化、対応状況などを記録し、複数の関係者が同じ情報を参照できるようにするというものだ。

ただし、危機対応におけるSSOTを「唯一の正しい真実」と理解すると問題が生じる。危機時には事実そのものがリアルタイムで更新されていくからだ。午前10時には「影響範囲は国内のみ」と考えられていても、11時には海外にも影響していたことが判明するかもしれない。この場合、SSOTに必要なのは古い記述を消したり隠したりすることではなく、「10時時点の認識」と「11時に判明した新事実」を区別して残すことである。
つまり、初動24時間のSSOTには少なくとも、①確認された事実、②現在の仮説、③未確認事項、④顧客・事業への影響、⑤実施した意思決定、⑥担当者と次の確認時刻、を分けて記録する必要がある。

特に重要なのは、「事実」と「仮説」を同じ欄に書かないことである。「データベース障害が原因」と書くのではなく、「データベースの遅延との関連を調査中」と記録するだけで、その情報を受け取った経営層や広報部門による誤った断定を防ぎやすくなる。
また、SSOTを作るだけでは十分ではない。「誰が更新できるのか」「誰が確認するのか」「何分ごとに更新するのか」を決めておかなければ、すぐに資料は陳腐化し、混乱のもとになってしまう。

危機対応におけるSSOTとは、たった一つの真実を確定させる仕組みではない。変化する事実認識について、組織が「いま何を共通認識としているか」を同期し続ける仕組みである。
初動24時間で本当に必要なのは、情報を増やすことではない。組織の中に存在する情報のズレを小さくし、技術者、経営者、広報、顧客対応が同じ現在地から判断できる状態を作ることなのである。