# 障害予測 ## 定義 障害予測(failure prediction / proactive monitoring)は、障害が実際に発生し業務へ影響する**前に**、潜在的な障害を先回りして予測し、予防的な復旧を可能にする取り組み。障害発生**後**に検知・箇所特定・根本原因分析・緩和を行う事後対応型の [[AIOps]] とは対照的に、先回り型(preemptive)の立場を取る。[[PAGER]] は顧客データ基盤([[Adobe Experience Platform]])でこれを実装し、履歴エラーログから学習した分類器でワークフロー段階間ジョブの時間的重複(障害の予兆)を予測し、自然言語で説明する。([[@2026__AAAI__PAGER - Proactive Monitoring Agent for Enterprise AI Assistant]]) 歴史的には[[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods]]がこの領域の標準的な定式化を与えており、本ページの呼称「障害予測」はオンライン障害予測(online failure prediction)を指す。Salfner+ 2010 は設計時の長期 reliability prediction(Lyu 1996 等)および障害発生後の root cause analysis のいずれとも明確に区別し、「runtime monitoring に基づき current system state から数秒〜数分先の failure 確率を評価する短期予測」と定義した(§1.1)。時間軸は data window size `t_d`・lead time `t_l`・prediction period `t_p`・minimal warning time `t_w` の 4 パラメータで固定する(`t_l ≧ t_w` でなければ意味を持たない、§2.2)。([[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods]]) ## 横断的知見 - **先回り型予測と事後対応型ライフサイクルの対比**: [[AIOps]] 概念の主要ソース([[AIOpsLab]]・[[SREGym]])が定式化するインシデント管理は検知 → 箇所特定 → RCA → 緩和の4段階で、すべて障害が**起きてから**動く事後対応型のもの。[[PAGER]] はこの手前に「障害発生前の予測」という段階を置き、事後対応型の既存 enterprise AI assistant・RCA エージェント(RCACopilot・ReAct)を明示的に「障害が運用を混乱させた後にしか役立たない」と批判する。同じ AIOps 領域でも、評価・研究の軸が「起きた障害をどう捌くか」から「障害をどう未然に防ぐか」へ広がりつつある。(Source: [[@2026__AAAI__PAGER - Proactive Monitoring Agent for Enterprise AI Assistant]], [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]]) - **LLM の役割の置き場所**: agentic SRE 系([[Stratus]] 等)が LLM を診断・緩和の推論中核に据えるのに対し、[[PAGER]] は予測本体を古典的な random forest に任せ、LLM を Shapley 由来の寄与スコアからの説明生成・NL2SQL・RAG・会話 UI といったインターフェース層に限定する。障害予測では「予測の正確さは軽量 ML、人間への伝達は LLM」という分業が成立しうる。(Source: [[@2026__AAAI__PAGER - Proactive Monitoring Agent for Enterprise AI Assistant]], [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]]) - **「障害より前/早く動く」には予測・早期検知・事前検証の 3 経路がある**: [[PAGER]] が障害発生**前**の予測(事後対応型ライフサイクルの手前)を狙うのに対し、[[Google]] は同じ「先回り」を 2 つの別経路で実装する。(1) [[Detectr]] は障害発生**後**だがテレメトリより**早い** user feedback(SNS・サポート)で検知を前倒しする早期検知、(2) **Adaptive Progressive Rollouts** はデプロイ起因の障害が全面展開する前に機械速度の継続検証で食い止める事前検証。「障害の影響を抑える」目標に対し、予測(PAGER)・別モダリティの早期検知(Detectr)・デプロイ前検証(Google rollout)という相補的な前倒し戦略が並ぶ。(Source: [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]], [[@2026__AAAI__PAGER - Proactive Monitoring Agent for Enterprise AI Assistant]]) - **LLM ベースの障害予測・予防はサーベイ時点でほぼ空白だった**: [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models]](カットオフ 2024-12)は、failure prevention の LLM 研究は唯一 FAIL(ニュース記事を分析して依存関係の問題を先回りで扱う)のみ、failure prediction も「precursor のない障害が多く取りこぼし(false negative)が高い」ため LLM 研究は限定的だと報告する(§4.1)。事後対応型の検知/RCA/緩和に LLM 研究が集中する一方、先回り型の予測・予防は手薄——[[PAGER]](2026、予測本体は random forest で LLM は説明層)はこの空白を突いた格好で、サーベイの「予測はまだ LLM で解けていない」観察と、PAGER が予測を軽量 ML に任せる設計判断は整合する。(Source: [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models]], [[@2026__AAAI__PAGER - Proactive Monitoring Agent for Enterprise AI Assistant]]) - **予測(予防)と反応(即時/事後検知)は同じインフラ障害に対する時間軸の両極**: GPU 訓練クラスタの障害対処は、性能劣化を「起きた後」に捉える反応型が主流である。[[Guard]] はグレーノードのフェイルスローを学習ステップ時間の即時モニタリングで検知し、[[C4]] は集合通信の異常を実時間で検知、[[R-Pingmesh]] は RoCE ネットワークの劣化を継続診断する——いずれも障害発生後に動く反応型。これに対し [[OptProphet]] は光トランシーバーの故障を平均 1.11 日前にアラームで先回り検知し(予測 平均 F1 0.884)、故障が訓練ジョブを中断させる業務影響の**前**に予防を可能にする。同じ GPU クラスタ運用でも、障害予測は事後対応型 AIOps の対極に位置し、本 concept の「障害が業務へ影響する前に先回りする」定義と整合する。(Source: [[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]], [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]], [[@2025__HPCA__Enhancing Large-Scale AI Training Efficiency - The C4 Solution for Real-Time Anomaly Detection and Communication Optimization]], [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]]) - **物理層(光トランシーバー)の故障を予測の根因に据える**: 障害予測の既存ソース([[PAGER]] のワークフロー段階重複、サーベイの依存関係問題)はソフトウェア/サービス層の予兆を扱うのに対し、[[OptProphet]] は光トランシーバーという物理ネットワーク部品の故障を予測対象とし、特徴量集約で時間的依存関係と物理的結合をモデル化する。Guard/C4/R-Pingmesh 系が通信層の性能劣化を観測するのと同じ物理ドメインを、反応でなく**予測**の側から補完する位置づけになる。(Source: [[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]]) - **ハードウェア障害の実証的特性把握(2010 年)は「何を予測特徴に使うか」の問いに答えた先行ステップである**: [[@2010__SoCC__Characterizing Cloud Computing Hardware Reliability]](Vishwanath & Nagappan、SoCC'10)は CHAID 分類木で 50 超のメトリクスから障害予測因子を探索し、最も有意なのは**データセンター名**と**メーカー名**という環境/組織的メタデータであり、サーバー齢・ラック位置・ワークロードは有意でないことを示した。この結果は Salfner+ 2010 の taxonomy で「symptom monitoring → function approximation」枝の特徴選択に直結する — SMART カウンタのようなコンポーネント固有の信号より、どのデータセンター・どのメーカーかという「文脈情報」が障害予測に有効という逆説は、LLM 期の障害予測がテレメトリ以外のコンテキスト特徴量をどう組み込むかという設計課題に今も通じる。(Source: [[@2010__SoCC__Characterizing Cloud Computing Hardware Reliability]]) - **Pinheiro et al. 2007 は「SMART の個別障害予測限界」を定量化した先駆的実証研究で、予測精度の天井を測った初の大規模スタディである**: Google 本番環境 10 万台超の HDD を対象とした [[@2007__FAST__Failure Trends in a Large Disk Drive Population]] は、強い相関を持つ SMART パラメータ(スキャンエラー・再割り当てカウント等)を特定しつつ、障害ドライブの 56% 超がいかなる強 SMART シグナルも示さないという予測の「欠落率」を測定した。全 SMART パラメータを足しても 36% 超の障害ドライブはシグナルゼロのまま。この結果は Salfner+ 2010 が体系化する前から、symptom monitoring 系(SMART)単体での failure prediction がリコール 44% 程度に上限を持つという実証的なエビデンスを与えており、「精度の改善より SMART 以外の信号の発掘が必要」という方向性を先取りしていた。Notaro et al. 2021 が整理した「HDD 予測は SMART 属性 → HMM/SVM/RNN の系譜で recall 0.94+ まで進化した」という評価も、この「シグナルが出た後のドライブ」に限定した評価であることを念頭に置く必要がある。(Source: [[@2007__FAST__Failure Trends in a Large Disk Drive Population]], [[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods]], [[@2021__TIST__A Survey of AIOps Methods for Failure Management]]) - **「予測 (online failure prediction) は pre-LLM 期から ML が主役で、対象別に SMART/HMM/SVM/LSTM の系譜が確立していた」**: Notaro et al. 2021([[@2021__TIST__A Survey of AIOps Methods for Failure Management]] §4.2)は online failure prediction を hardware と system に二分し、HDD 予測は SMART 属性 → Hidden (Semi-)Markov / SVM / RNN の系譜で recall 0.33 → 0.94+、FAR 0.0067 → 0.004 まで進化、system 側は logs/KPI/metrics を入力に SVM・TAN・HSMM・LSTM・autoregressive・Bayesian Network が並ぶと整理した。LLM4Log・CSUR が「ログベース予測は sparse」と報告する LLM-era の手薄さは、pre-LLM の HDD/system 予測の蓄積が「予測本体は軽量 ML、LLM は説明層」という分業([[PAGER]])を支える素地になっている。lead time / prediction time / warning time(twarn < tlead)という時間軸の評価枠も Notaro et al. が §4.2 冒頭で整理しており、LLM-era の "適時性" 評価はこの枠組みの拡張として読める。(Source: [[@2021__TIST__A Survey of AIOps Methods for Failure Management]] §4.2, [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]]) - **ログベース障害予測は LLM4Log でも「sparse and heterogeneous」と独立に確認され、PAGER が予測本体を軽量 ML に任せる判断を裏づける**: [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]] はログベース障害予測を「将来の horizon $H$ 内に障害が起きる確率を予測する forward-looking タスク」と定義し(§6.3)、コーパス上わずか 4 論文と最小で「現状の文献は sparse で heterogeneous」と明言する。手法は (i) 生成予測(CrashEventLLM が先行ログから crash の時刻/原因を instruction-tuned LLaMA で生成)、(ii) LM 表現からの discriminative early warning(FALL の ELECTRA 系・AUC 評価)、(iii) アプリログ外の異種テレメトリ活用(shell ログ + バックアップ障害予測)、(iv) 異常検知から proactive fault tolerance へ(VMFT-LAD)に分かれる。中心課題は「予測品質・適時性(lead time)・actionability を一貫して測る評価が未確立で、ログ進化・partial observability・cross-component 依存という現実制約のもとで成立させること」。これは [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models]] が「failure prediction は precursor なき障害が多く false negative が高い」と報告した観察と独立に整合し、本 wiki の [[PAGER]] が予測本体を random forest に任せ LLM を説明層に限定した設計判断(横断的知見の「LLM の役割の置き場所」)が、フィールド地図上でも妥当な選択であることを裏づける。(Source: [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]], [[@2026__AAAI__PAGER - Proactive Monitoring Agent for Enterprise AI Assistant]], [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models]]) - **入力データ系統による taxonomy(Salfner+ 2010)が pre-AIOps 期から確立しており、現代の手法はそのいずれかの枝に位置づけられる**: [[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods]] は約 50 のオンライン障害予測手法を、入力データ系統で 4 主要枝 ((1) failure tracking、(2) symptom monitoring、(3) detected error reporting、(4) undetected error auditing) に分け、その下を principal approach・category の階層に分解した(§4 全体・Figure 8)。LLM 期の手法もこの軸に乗り、(i) [[OptProphet]] の光トランシーバー予測は symptom monitoring 系の function approximation(2.1.3 機械学習)の延長、(ii) [[PAGER]] のワークフローエラーログ予測は detected error reporting 系の classifiers(3.5)の延長、(iii) CrashEventLLM/FALL のログベース予測は detected error reporting 系の pattern recognition(3.3)の LLM 化、と読める。Notaro et al. 2021 の proactive/reactive 軸はこの 4 枝のうち「failure tracking + symptom monitoring + detected error reporting + 予防」を proactive に畳んだ再整理にあたる。Salfner+ 2010 のうち系統 4(undetected error auditing)は当時から該当文献ゼロで、2026 年時点でも実質的に空白の枝として残る(eBPF 等で runtime audit は技術的には可能になっているが、failure prediction に応用した研究は希少)。(Source: [[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods]] §4, [[@2021__TIST__A Survey of AIOps Methods for Failure Management]] §4.2, [[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]], [[@2026__AAAI__PAGER - Proactive Monitoring Agent for Enterprise AI Assistant]]) - **時間軸の 4 パラメータ(`t_d, t_l, t_p, t_w`)は今も AIOps の予測タスク評価で通用する共通通貨で、LLM 期の "適時性" 評価は本質的にこの枠組みの拡張**: Salfner+ 2010 §2.2 は data window size `t_d`(過去履歴の長さ)・lead time `t_l`(現在から予測対象窓の始まりまで)・prediction period `t_p`(予測有効窓の長さ)・minimal warning time `t_w`(対策に要する最小余裕)の 4 パラメータで予測の時間軸を固定し、`t_l ≧ t_w` を予測の存在条件とした。Notaro et al. 2021([[@2021__TIST__A Survey of AIOps Methods for Failure Management]] §4.2)が AIOps サーベイで `twarn < tlead` を採用しているのも本枠組みの継承で、LLM4Log が「適時性(lead time)・actionability の一貫評価が未確立」と指摘するのも本来は Salfner+ 2010 が `t_p` と評価指標の連動を 16 年前に既に整理していた問題の再燃と見える(`t_p → ∞` なら「常に failure」戦略でも recall = 1 を達成してしまうという指摘は §3.1 末尾)。LLM ベース予測の評価設計では、生成出力をどの `t_p` 窓で照合するかを明示しない限り precision/recall が定義できないので、本枠組みの再採用が必要。(Source: [[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods]] §2.2 §3.1, [[@2021__TIST__A Survey of AIOps Methods for Failure Management]] §4.2, [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]] §6.3) - **Cox-Time 生存解析は AI クラスタの incident prediction で「行動」と組み合わさったときに価値を出す**: [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]] の Selector は、Kvamme+ 2019 の Cox-Time モデル(時間依存ハザードを許す Cox 比例ハザードの NN 拡張)に「total up time / historical incident counts / 各カテゴリの MTBI / incident category」をノードステータスとして入れ、TBNI(time before next incident)の予測精度 93.13% を達成(指数分布系の 75.12%、件数別の 63.03% を大きく上回る、Table 3)。ただしこの予測は単体では Salfner+ 2010 の 4 段階のうち「予測」段にとどまり、価値は次段の「ベンチマーク部分集合の選択」と組み合わせて初めて実現する——フルセット検証比で MTBI 1.11×・検証時間 92.07% 削減という結果は、予測の品質だけでなく予測を**何に使うか**の設計が決定的だと示す。[[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]] の「予測 → 部品交換」と並ぶ、AI インフラの先回り型運用の代表例となる。(Source: [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]], [[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]]) - **予測精度の向上だけでは可用性は伸びず、後段の "対策の自動化" こそが PFM の残り 3 段階の本丸である**: Salfner+ 2010 §1.2 は予測が proactive fault management(PFM)4 段階のうち最初の 1 段に過ぎないと明示し、§6 末尾で「次の研究的飛躍は予測精度の改善でなく予測に基づく効果的な対策の自動トリガー」と結論する。Candea+ 2004 の引用「短い restart 時間ほど許容できる偽陽性率が高い」は、予測モデルだけ磨いても対策(microreboot)が速ければ偽陽性は問題にならない/逆に対策がコスト高なら予測モデルが完璧でも稼働しないという循環関係を示す。Notaro et al. 2021 が定量化した「remediation 2.5%」の研究の薄さは、15 年前の Salfner+ 2010 が見抜いたボトルネックが今も解消されていないことの定量証拠と読める。([[プロアクティブ障害管理]] の横断的知見と連動)(Source: [[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods]] §1.2 §6, [[@2021__TIST__A Survey of AIOps Methods for Failure Management]] §5.1) - **Remil+ 2024 の Prevention 能力は offline(SDP・fault injection)と online(rejuvenation・RUL・hardware/software failure prediction)を 1 つの能力として束ねる**: 本ページは Salfner+ 2010 と Notaro+ 2021 の online failure prediction を基準とし、PAGER・OptProphet 等を整理してきたが、[[@2024__arXiv__AIOps Solutions for Incident Management]] §3.3 は Prevention 能力に offline 系(SDP = Software Defect Prediction、fault injection)を組み入れている。これにより、コード解析ベースの defect prediction(Eclipse/PROMISE/NASA データセット系列)、stress-testing の fault injection、software rejuvenation、RUL 予測、本番モニタリングからの online failure prediction が「障害発生前の介入」という 1 つの能力名のもとに並び、それぞれが lifecycle のどこで効くか(開発時 / プレリリース / 運用初期 / 老化期 / 直前予兆)の時間軸が見える。本 wiki の障害予測は online 予測中心で SDP・rejuvenation・RUL の蓄積が薄いので、Remil+ 2024 の Prevention 能力枠で補完する余地がある。(Source: [[@2024__arXiv__AIOps Solutions for Incident Management]] §3.3 Incident Prediction) - **Remil+ 2024 は時間軸 4 パラメータ(`Δt_d, Δt_l, Δt_p, Δt_w`)を Salfner+ 2010 から踏襲しつつ、prediction period `Δt_p` を triage/緩和の時間制約と連結する点で前進している**: [[@2024__arXiv__AIOps Solutions for Incident Management]] §4.2(Figure 7・Table 3)は Salfner+ 2010 の 4 パラメータ枠組みを採用しつつ、「`Δt_p` は後段(triage・assignment・mitigation)が必要とする実効時間と整合させる」必要があると明示する。Salfner+ 2010 §3.1 が指摘した「`t_p → ∞` で recall=1 を達成できてしまう問題」は本サーベイで「`t_p` を運用設計と切り離すと評価がゲーム可能」という形に再定式化されており、本ページの未解決の問い「LLM4Log の適時性評価」が Remil+ 2024 で operational metric(MTTD/MTTE/MTTR/MTBF)と連結する形で補強された。(Source: [[@2024__arXiv__AIOps Solutions for Incident Management]] §4.2, [[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods]] §3.1, [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]] §6.3) - **AirAlert(Chen+ WWW2019)は Bayesian network + XGBoost のハイブリッドで「特徴選択」と「予測」を統合し、サービスレベル outage に対する単一信号閾値ルールの崩壊を補正する**: [[@2019__WWW__Outage Prediction and Diagnosis for Cloud Service Systems|AirAlert]] は Microsoft クラウドの 1 年データで、サービスレベルの Web Application Outage に対し Simple Spike(F1 7.72%)が崩壊する場面で F1 88.78%(AirAlert Related モード)を達成した。Salfner+ 2010 が detected error reporting 系の classifiers(3.5)に位置づけ、Notaro et al. 2021 が system level prediction の SVM/Bayesian Network の系譜に並べる路線で、本研究は (a) FCI による Bayesian network で「相関する信号集合」を抽出し、(b) その selected subset を XGBoost に通す 2 段構成を採用。これは [[PAGER]] が「予測は random forest、説明は LLM」と分業した PAGER 設計の 7 年前の前駆例で、AirAlert は「予測本体は XGBoost、診断・特徴選択は Bayesian network」という同型の分業構造を持つ。LLM 時代の AIOps 予測でも「予測本体は軽量 ML + 構造的依存学習」というアーキテクチャは生き続けている。(Source: [[@2019__WWW__Outage Prediction and Diagnosis for Cloud Service Systems]], [[@2026__AAAI__PAGER - Proactive Monitoring Agent for Enterprise AI Assistant]], [[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods]]) - **コンポーネントレベル vs サービスレベルの予測難易度差は「単一閾値ルールが効くか」で 1 桁以上の F1 差を生む**: AirAlert の Table 1/2 比較から、Simple Spike(単一信号閾値、人手 θ)はコンポーネントレベルの 3 outage で F1 70-76%(他手法とほぼ同等)を達成するが、サービスレベルの Web App / Cloud Network / MS Cloud Sys Op では F1 7.72%/8.39%/11.63% に崩壊する。これは [[アラート管理]] 横断的知見の「現行 4 対処の有効性は OCE 評価で全員肯定、しかし設定にドメイン知識を要する」と同質——単一信号で表現可能な障害クラスでは古典ルールが十分働き、複数サービス・複数信号の合成として現れる障害ではルール組合せ爆発が原理的に追いつかない。Bayesian network が「直接接続する信号集合」を学習する性質が、この組合せ爆発を機械的に解く役割を果たす。(Source: [[@2019__WWW__Outage Prediction and Diagnosis for Cloud Service Systems]], [[@2022__DSN__Characterizing and Mitigating Anti-patterns of Alerts in Industrial Cloud Systems]]) - **「精密な時間予測が破綻する領域では、ランキングへの再定式化が代替パラダイムになる」——GPU 障害という新しい反例が Salfner+ 2010 の taxonomy 全体に一石を投じる**: [[@2026__arXiv__Don't Predict, Prioritize - Rethinking GPU Reliability Assessment]](HeaRank)は、GPU の Double Bit Error・GPU Lost 障害に対し XGBoost・CNN・LSTM・Transformer・MoE の 5 モデル横断でオンライン障害予測(§3.1 の定式化そのもの、Salfner+ 2010 の symptom monitoring → function approximation 系統)を試みた結果、8 時間観測窓で F1 最大 0.4837 と実用に耐えない性能しか出ないことを実証した。原因は本ページが蓄積してきた「モデル容量不足」でも「特徴量不足」でもなく、Kendall 相関(ワークロード変化を跨ぐと相関が消失)・SNR(ワークロード直結メトリクスが著しく低い)・分布比較(障害前後でほぼ完全に重複)という**テレメトリそのものの統計的性質**にあると特定した。この上で、本論文は「いつ壊れるか」の精密予測を諦め「どのノードが相対的に危険か」という Learning-to-Rank(LTR)タスクへ再定式化し、AUC 0.834・上位 5% ノードで将来障害の 64% 捕捉(既存 Health Score システムは 21%)を達成した。Salfner+ 2010 の taxonomy(§4)は「入力データ系統」を軸に手法を分類するが、HeaRank は入力データではなく**出力の形(絶対時刻 vs 相対順位)**を変えることで予測不能性を回避する第 3 の軸を示しており、本ページが暗黙に前提としてきた「予測 = 二値/連続スコアでの時間軸判定」という枠組み自体に例外があることを明らかにした。(Source: [[@2026__arXiv__Don't Predict, Prioritize - Rethinking GPU Reliability Assessment]], [[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods]] §4) - **「疎で確率的な障害イベント」という共通の敵に対し、GPU 障害はランキングで、ログベース予測は生成 LLM で、異なる回避策を取る**: LLM4Log サーベイ([[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]])が指摘する「precursor のない障害が多く false negative が高い」根本制約と、HeaRank が実証した「pre-failure テレメトリが正常時と統計的に区別不能」という制約は独立に同じ現象(疎で低 SNR な障害シグナル)を異なるドメイン(ログ vs テレメトリ)で確認した形になる。ログベース予測はこの制約に対し生成 LLM(CrationEventLLM 等)で precursor を"埋める"方向に向かうのに対し、HeaRank は精密な時間予測というタスク設定自体を放棄し、ホスト単位の粗粒度(host-level)かつ長期(long-horizon)なランキングへ移行することで疎性を回避する。同じ制約に対する「タスクは維持してモデルを強化する」路線と「タスク自体を作り直す」路線という 2 つの対照的な応答が並ぶ。(Source: [[@2026__arXiv__Don't Predict, Prioritize - Rethinking GPU Reliability Assessment]], [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]]) - **Salfner+ 2010 の時間軸 4 パラメータ(t_d, t_l, t_p, t_w)は、ランキングパラダイムでは「予測ホライズン Δt」という 1 パラメータへ縮退し、t_p → ∞ でのゲーム可能性を積極的に利用する側に転じる**: 本ページが繰り返し警告してきた「t_p → ∞ なら『常に failure』戦略でも recall = 1 を達成してしまう」(§3.1 の指摘)という問題は、精密な時間予測を前提とする限り欠陥だが、HeaRank の RQ3(Table 2)ではこれを逆手に取る——予測ホライズン Δt を 3→30 日へ延ばすほど AUC・NDCG が単調に改善し、Δt → ∞ に近づくほどランキング精度が上がる(ただしリスク差別化自体が意味を失う限界がある)。ランキングタスクでは「起きた/起きなかった」の precision-recall ではなく「相対順序が正しいか」だけが問われるため、長いホライズンによる情報の希薄化が精度低下ではなくノイズ平滑化として働く。時間軸パラメータの意味がタスク定式化によって反転する具体例である。(Source: [[@2026__arXiv__Don't Predict, Prioritize - Rethinking GPU Reliability Assessment]], [[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods]] §3.1) ## 未解決の問い - Pinheiro et al. 2007 が予測限界の根拠とした「SMART シグナルが現れない 56% 超の障害ドライブ」という知見は、2020 年代の NVMe SSD・エンタープライズ SAS ドライブにも当てはまるか。媒体が変わって SMART シグナルの種類が増えた現在、欠落率は改善しているか。 - [[PAGER]] は障害を「段階間ジョブの時間的重複(overlap)」として定式化するが、これは AEP 固有のワークフロー前提に強く依存する。overlap 以外の障害種別(リソース枯渇・データ品質・外部依存)や、他プラットフォームへ予測対象をどこまで一般化できるか。 - セグメンテーションとジャーニー間の予測 F1 は 57.5 と中程度でベースラインの分散も大きい。障害予測の精度上限はデータの偏り(障害は稀事象)とどう関係するか。稀な障害クラスの予測をどう底上げするか。 - 予測 → 説明 → 予防的な復旧のループで、誤検知(偽陽性な予測)が support engineer の信頼と作業負荷に与える影響は。事後対応型の AIOps が報告する偽陽性問題([[AIOps]] 参照)は先回り型予測でどう現れるか。 - 先回り型予測と事後対応型の検知/RCA/緩和を1つのエージェントに統合できるか。予測が外れた(=実際に障害が起きた)ときに事後対応ループへ滑らかに引き継ぐ設計は。 - 予測([[PAGER]])・早期検知([[Detectr]])・デプロイ前検証([[Google]] の Adaptive Progressive Rollouts)はいずれも「障害影響の前倒し抑制」を狙うが、どの障害クラスにどの経路が効くかの切り分けは未整理。デプロイ起因の障害は rollout 検証で、外部要因・需要変動起因は予測で、新規・未知の障害は user feedback 検知で、という棲み分けは成り立つか。([[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]]) - サーベイが指摘する「precursor のない障害が多く予測は false negative が高い」という根本制約は、LLM やマルチモーダルなデータ統合で緩和できるのか、それとも稀事象予測の原理的限界か。予兆のある障害クラス(リソース漸増・依存劣化)と予兆のない障害クラス(突発的なハードウェア故障)で予測可能性はどこまで分かれるか。([[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models]]) - [[OptProphet]] は不均衡なデータ分布を「自動的に処理」すると述べるが、その具体的な仕組み(リサンプリング・損失重み付け・しきい値調整のいずれか)は出典(Abstract のみ)では確認できない。稀な故障クラスの予測を底上げする一般的手法と、本手法の自動処理がどう関係するかは未確認。 - [[OptProphet]] が特徴量集約でモデル化する「物理的結合」は、GPU 訓練クラスタのレール最適化トポロジ([[R-Pingmesh]] 等が前提とする物理配線)とどう対応するか。トポロジ構造を予測特徴に取り込むことが故障予測の精度・先回り余裕(1.11 日)をどこまで左右するかは出典に現れない。 - LLM4Log サーベイが挙げる障害予測の核心課題「予測品質・適時性(lead time)・actionability の一貫評価が未確立」は、生成型(CrashEventLLM の ROUGE 評価が timestamp/causal の正しさを忠実に反映しない問題)と discriminative 型(FALL の AUC・pre-failure 窓のデータリーク制御)でどう統一できるか。structured 評価(障害種別/時刻 bin の exact match + 証拠 grounding)へ移れるか。([[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]]) - Salfner+ 2010 §4.4 で「該当文献なし」とされた undetected error auditing(系統 4)の枝は、eBPF・kprobe・runtime audit が一般化した 2020 年代でも本当に空白なのか。runtime audit を input として障害を予測する研究が今でも希少なのは、(a) audit がコスト高で常時実行に向かない、(b) 検出されない error は定義上「現状の検出器の盲点」なので学習データのラベリングが難しい、のどちらが主因か。([[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods]] §4.4) - Remil+ 2024 が Prevention 能力に組み入れた SDP(Software Defect Prediction)は、LLM-era の本 wiki 群では存在感が薄い。Eclipse/PROMISE/NASA データセットでの古典 ML(SVM・DBN・CNN)研究と、LLM ベースのコード解析(コードLLM 系)の融合は AIOps の障害予測としてどこまで進展しているか。コード時系列(commit graph・bug report 履歴)を入力とする LLM 予測は本 wiki が追ってこなかった空白。([[@2024__arXiv__AIOps Solutions for Incident Management]] §3.3, [[@2021__TIST__A Survey of AIOps Methods for Failure Management]] §4.1) - Salfner+ 2010 §3.1 末尾の警告 "`t_p → ∞` では「常に failure」戦略でも recall = 1 を達成してしまう" は、LLM 生成型予測の評価でどう守られているのか。CrashEventLLM 系のように自由文で時刻と原因を生成する設計では `t_p` を明示しないため、recall を測れているのか曖昧になる。出力に必ず予測窓を含める制約と、それを構造化評価する基盤が要る。([[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods]] §3.1, [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]] §6.3) - HeaRank が示した「精密予測を諦めランキングへ再定式化する」路線は、GPU 障害以外のどの障害クラスに一般化できるか。本ページが蓄積してきた HDD([[@2007__FAST__Failure Trends in a Large Disk Drive Population]])・ログベース([[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]])・サービスレベル outage([[@2019__WWW__Outage Prediction and Diagnosis for Cloud Service Systems]])はいずれも「精密な二値/時間予測」の枠内で改善を図ってきたが、これらもテレメトリが低 SNR・分布重複という性質を持つなら、ランキングへの再定式化で同様の実用的ブレイクスルーが得られるか。([[@2026__arXiv__Don't Predict, Prioritize - Rethinking GPU Reliability Assessment]]) - HeaRank のホスト単位 Pareto 集中("lemon nodes")と、Vishwanath & Nagappan 2010([[@2010__SoCC__Characterizing Cloud Computing Hardware Reliability]])が特定した「データセンター名・メーカー名が最有意な予測因子」という発見は、どちらも個体差(host-level heterogeneity)が時系列信号より予測力を持つという共通構造を示す。この host-level 優位性は HDD・GPU 以外のハードウェア(NIC・光トランシーバー等)にも一般化するか、それとも GPU 特有(高密度・高発熱・同期ジョブ依存)の現象か。 - 予測モデルだけを磨いても可用性は伸びないという Salfner+ 2010 §6 の結論(対策側の進化が要る)は、LLM 期に逆転するのか。LLM がスケジューリング・実行段に入れば end-to-end の PFM ループが回るはずだが、現実の [[PAGER]] や [[Bian Que]] は予測層・説明層・実行層を別モジュールに分けている。1 つの自律ループに畳む実装上の障壁は何か。([[プロアクティブ障害管理]] と連動) ## 関連 - ソース: [[@2026__arXiv__Don't Predict, Prioritize - Rethinking GPU Reliability Assessment]] / [[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods]] / [[@2021__TIST__A Survey of AIOps Methods for Failure Management]] / [[@2026__AAAI__PAGER - Proactive Monitoring Agent for Enterprise AI Assistant]] / [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models]] / [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]] / [[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]] / [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]] - 概念: [[プロアクティブ障害管理]] / [[プロアクティブ検証]] / [[グレイ障害]] / [[ソフトウェアエイジング]] / [[AIOps]] / [[異常検知]] / [[ログ解析]] / [[agentic SRE]] / [[SRE AI Autonomy Levels]] / [[GPUクラスタ運用]] / [[GPUレジリエンス]] / [[耐障害LLM訓練]] - エンティティ: [[Felix Salfner]] / [[Miroslaw Malek]] / [[Humboldt University of Berlin]] / [[PAGER]] / [[Adobe Experience Platform]] / [[Detectr]] / [[Google]] / [[OptProphet]] / [[Difeng Ma]] / [[Changhua Pei]] - 関連 MOC: [[AIOps - Failure Detection - MOC]] / [[LLM4SRE - MOC]] ## 出典 - [[@2026__arXiv__Don't Predict, Prioritize - Rethinking GPU Reliability Assessment]](§3 Predictability Analysis: 5 モデル横断の予測限界実証・Kendall 相関/SNR/分布比較、§4 HeaRank の LTR 再定式化、§6 オンライン展開結果) - [[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods]](§1.1 オンライン障害予測の定義と root cause analysis との分離・§2 fault/error/symptom/failure 5 段階モデル・§3 評価指標・§4 4 系統 taxonomy・§5 約 50 手法のカタログ・§6 結論) - [[@2026__AAAI__PAGER - Proactive Monitoring Agent for Enterprise AI Assistant]](Abstract, Introduction, System Overview, Results) - [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models]](§4.1 Failure Prevention / Failure Prediction) - [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]](AI Across the SRE Lifecycle, The Future of SRE) - [[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]](Abstract: OptProphet の予測+分類統合・1.11 日前アラーム・平均 F1) - [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]](§6.3 Failure Prediction: タスク定義/4 論文と sparse/heterogeneous, CrashEventLLM/FALL/shell ログ/VMFT-LAD, 評価未確立の課題) - [[@2021__TIST__A Survey of AIOps Methods for Failure Management]](§4.2 online failure prediction: HDD/system 別の代表手法、SMART/HMM/SVM/RNN/LSTM の系譜、lead/prediction/warning time の評価軸)