障害予測 - yuuk1's Digital Garden

# 障害予測 ## 定義障害予測(failure prediction / proactive monitoring)は、障害が実際に発生し業務へ影響する**前に**、潜在的な障害を先回りして予測し、予防的な復旧を可能にする取り組み。障害発生**後**に検知・箇所特定・根本原因分析・緩和を行う事後対応型の [[AIOps]] とは対照的に、先回り型(preemptive)の立場を取る。[[PAGER]] は顧客データ基盤([[Adobe Experience Platform]])でこれを実装し、履歴エラーログから学習した分類器でワークフロー段階間ジョブの時間的重複(障害の予兆)を予測し、自然言語で説明する。([[@2026__AAAI__PAGER - Proactive Monitoring Agent for Enterprise AI Assistant]]) 歴史的には[[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)。([[A Survey of Online Failure Prediction Methods]]) ## 子概念 - [[agentic SRE]] - [[ソフトウェアエイジング]] - [[プロアクティブ障害管理]] - [[メモリ障害予測]] ## 横断的知見 - **先回り型予測と事後対応型ライフサイクルの対比**: [[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 ベースの障害予測・予防はサーベイ時点でほぼ空白だった**: [[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: [[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]], [[A Survey of Online Failure Prediction Methods]], [[A Survey of AIOps Methods for Failure Management]]) - **「予測 (online failure prediction) は pre-LLM 期から ML が主役で、対象別に SMART/HMM/SVM/LSTM の系譜が確立していた」**: Notaro et al. 2021([[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: [[A Survey of AIOps Methods for Failure Management]] §4.2, [[LLM4Log]]) - **ログベース障害予測は LLM4Log でも「sparse and heterogeneous」と独立に確認され、PAGER が予測本体を軽量 ML に任せる判断を裏づける**: [[LLM4Log]] はログベース障害予測を「将来の 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 依存という現実制約のもとで成立させること」。これは [[A Survey of AIOps in the Era of Large Language Models]] が「failure prediction は precursor なき障害が多く false negative が高い」と報告した観察と独立に整合し、本 wiki の [[PAGER]] が予測本体を random forest に任せ LLM を説明層に限定した設計判断(横断的知見の「LLM の役割の置き場所」)が、フィールド地図上でも妥当な選択であることを裏づける。(Source: [[LLM4Log]], [[@2026__AAAI__PAGER - Proactive Monitoring Agent for Enterprise AI Assistant]], [[A Survey of AIOps in the Era of Large Language Models]]) - **入力データ系統による taxonomy(Salfner+ 2010)が pre-AIOps 期から確立しており、現代の手法はそのいずれかの枝に位置づけられる**: [[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: [[A Survey of Online Failure Prediction Methods]] §4, [[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]]) - **Salfner+ 2010 の taxonomy(Figure 8)は「fault をどう可視化するか」という手段の違いで4主枝を切り、各枝を principal approach → category の3段階に分解する厳密な階層を持つ——本ページがこれまで「4主要枝」とだけ要約してきた構造の、下位段までの正確な内訳**: [[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods - Chapter 4 A Taxonomy of Online Failure Prediction Methods]] §4 は、fault が failure に至る過程を可視化する5手法(testing・auditing・monitoring・reporting・tracking)のうち runtime 中に実行できない testing を除いた4手法を taxonomy の軸に採用したと明言する。結果として (1) failure tracking は確率分布推定(→ Bayesian Predictors / Non-parametric Methods)と cooccurrence の2 principal approach、(2) symptom monitoring は function approximation(→ Stochastic Models / Regression / Machine Learning)・classifiers(→ Bayesian / Fuzzy / Other)・system models(→ Instance / Clustered Instance / Stochastic / Graph Models)・time series analysis(→ Regression / Feature Analysis / Time Series Prediction)の4 principal approach、(3) detected error reporting は rule-based・cooccurrence・pattern recognition・statistical tests・classifiers の5 category(この枝は principal approach を介さず直接 category に分割)、(4) undetected error auditing は該当文献なしで無分割、という非対称な木になる。この非対称自体が「研究の厚みの偏り」を可視化しており、symptom monitoring(4 principal approach)と detected error reporting(5 category)に手法が集中する一方、undetected error auditing が空白であるという本ページの既存観察(eBPF うんぬん)を taxonomy の構造そのものが裏付けている。(Source: [[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods - Chapter 4 A Taxonomy of Online Failure Prediction Methods]] §4 Figure 8) - **Salfner 2010 と Notaro 2021 は同じ online failure prediction を主題としながら、taxonomy を切る立場が根本的に異なる——前者は「予測そのものが本のテーマ」で入力データの系統(何を観測して予測するか)を主軸に据え、後者は「AIOps の障害管理ライフサイクルの1カテゴリとしての予測」を主題とし対象(hardware/system)を主軸に据える**: Salfner+ 2010 は全6章のうち taxonomy 章(本章 §4)を含む大半を online failure prediction 単体の分類体系に費やし、その内部構造は「fault をどう可視化するか」(failure tracking / symptom monitoring / detected error reporting / undetected error auditing)という、予測アルゴリズムの中身ではなく**入力データの取得経路**で最初に分岐する。対して [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.2 Online Failure Prediction]] は、online failure prediction を failure management ライフサイクル5カテゴリ(detection/RCA/prediction/prevention/remediation)の1つに位置づけたうえで、その内部を hardware failure prediction と system failure prediction という**予測対象**で二分する(本ページ既存の横断的知見「入力データ系統による taxonomy」参照)。11年隔たった2つのサーベイが同じ現象(online failure prediction)を分類する際、Salfner は「どうやって知るか(観測経路)」、Notaro は「何が壊れるか(対象)」を第一分岐に選んでおり、両者の taxonomy は互いに交差する直交軸になっている——例えば Notaro の「hardware failure prediction」の代表(HDD の SMART 監視)は Salfner の taxonomy では symptom monitoring の classifiers(2.2)に、Notaro の「system failure prediction」でログベース手法は Salfner の detected error reporting の pattern recognition(3.3)や classifiers(3.5)に、それぞれ対応づけられる。Notaro のサーベイがスコープを「予測」1カテゴリに圧縮した代償として観測経路の粒度(symptom vs error report の区別)は失われており、Salfner の taxonomy でしか可視化できない情報(detected error reporting が event-driven・discrete である一方 symptom monitoring は periodic・real-valued という §4.3 の対比)が、Notaro のハードウェア/システム二分では暗黙化されている。(Source: [[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods - Chapter 4 A Taxonomy of Online Failure Prediction Methods]] §4〜§4.3, [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.2 Online Failure Prediction]]) - **時間軸の 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([[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: [[A Survey of Online Failure Prediction Methods]] §2.2 §3.1, [[A Survey of AIOps Methods for Failure Management]] §4.2, [[LLM4Log]] §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: [[A Survey of Online Failure Prediction Methods]] §1.2 §6, [[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, [[A Survey of Online Failure Prediction Methods]] §3.1, [[LLM4Log]] §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]], [[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]], [[A Survey of Online Failure Prediction Methods]] §4) - **AirAlert の単純な特徴設計(アラート種別件数のみ)を、独立した後続研究(eWarn)が同じアラートベース予測タスク上で追試し、性能崩壊を実証した**: [[@2020__ESEC-FSE__Real-Time Incident Prediction for Online Service Systems|eWarn]](Zhao+, ESEC/FSE 2020)は AirAlert を比較手法として直接再実装し、大手商業銀行の 11 実サービスシステムで平均 F1 0.51 にとどまることを示した(eWarn 自身は F1 0.82)。AirAlert の一次論文([[@2019__WWW__Outage Prediction and Diagnosis for Cloud Service Systems]])は Microsoft クラウドの 1 年データでサービスレベル outage に対し F1 53.92-88.78% を報告しており、両者の性能ギャップは「同じ AirAlert 設計でもデータセット・ドメインが変わると性能が大きく崩れる」ことを示す独立再現実験になっている。eWarn は原因を「AirAlert はアラート種別件数のみに依存し複雑なアラートパターンを表現できず、ノイズアラートへの対処もない」と分析し、(a) LDA によるテキスト特徴の追加、(b) multi-instance learning によるノイズアラート抑制、の2点で AirAlert を上回ったと主張する。AirAlert が Bayesian network(FCI)で「特徴選択」を担っていたのに対し、eWarn は MIL のクラスタリングでノイズ instance への重み減衰という異なるノイズ対処の設計を採る——同じ「アラートベース予測+ノイズ対処」という問題設定に、2 つの異なる技術的解が独立に提案された形。(Source: [[@2020__ESEC-FSE__Real-Time Incident Prediction for Online Service Systems]], [[@2019__WWW__Outage Prediction and Diagnosis for Cloud Service Systems]]) - **テキスト特徴抽出は「大規模コーパス依存のニューラル手法」より「軽量な古典トピックモデル」が有利という逆説が、アラート予測ドメインで実証された**: eWarn は LDA(トピックモデル)による平均 F1 0.82 に対し、TextCNN(0.48)・FastText(0.51)という2つのニューラルネットワークベースのテキスト表現手法は明確に劣ると報告する。理由として、アラート文はドメイン固有(IT 運用)かつ半構造化の短文であり、自然言語処理向けに設計されたニューラル手法が要求する大規模学習コーパスを満たせない点を挙げる。本ページが蓄積してきた「予測本体は軽量 ML([[AirAlert]]・[[PAGER]])」という横断的知見に、「表現学習の段階でも軽量な古典手法が有利になりうる」という追加の軸を与える——アラート予測ドメインでは、モデル容量よりデータ量の制約が性能を支配する。(Source: [[@2020__ESEC-FSE__Real-Time Incident Prediction for Online Service Systems]]) - **予測結果の説明が「なぜ起きるか」の診断ヒントに転用できることを、LIME ベースの eWarn が具体的成功事例つきで実証した**: [[PAGER]] が Shapley 値ベースの寄与スコアで説明生成を LLM に担わせるのに対し、eWarn は LIME で特徴寄与度を算出し、最も寄与度の高い特徴(例: データベース関連トピックのキーワード)がインシデントの根本原因に近い低レベルコンポーネントを示唆すると論じる。実際の運用事例(Case I: スロー SQL による応答遅延)では、Topic#27 のキーワード「Oracle・AAS・SQL・lock」からデータベース起因と推測でき、診断の探索空間を絞り込めたと報告する。予測(prediction)と診断(RCA)を別々の能力として扱ってきた本ページの前提に対し、eWarn は「良い予測説明はそのまま診断の第一歩になりうる」という橋渡しの実例を加える。(Source: [[@2020__ESEC-FSE__Real-Time Incident Prediction for Online Service Systems]]) - **「疎で確率的な障害イベント」という共通の敵に対し、GPU 障害はランキングで、ログベース予測は生成 LLM で、異なる回避策を取る**: LLM4Log サーベイ([[LLM4Log]])が指摘する「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]], [[LLM4Log]]) - **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]], [[A Survey of Online Failure Prediction Methods]] §3.1) - **[[OptProphet]] が「Abstract のみ」で伏せていた光トランシーバー故障予測の具体的な予兆特徴を、同一著者系譜の先行実証研究(Notaro+ 2023, CCGrid)が定量的に埋める**: [[@2023__CCGrid__An Optical Transceiver Reliability Study based on SFP Monitoring and OS-level Metric Data]](Notaro・Cardoso・Gerndt——[[A Survey of AIOps Methods for Failure Management]] と同じ著者陣)は 350 万台超・15 か月の光トランシーバーを対象に、時系列自己相関・AFR 推定・運用範囲比較・パターン lift・ML 予測モデルという 4 独立軸すべてで「エラーレートの過去発生」が最強の故障予兆であること(lift 9.13x、特徴重要度で最上位、健全モジュールでは常に 0 pps)を示し、続いてバイアス電流高値(lift 6.24x、レーザー老朽化に起因)・温度/Rx/Tx パワーの高分散(lift 6-7x)が続くと定量化した。一方でパケットロスは lift 1.27-1.28x とほぼ無関係と結論づける。[[OptProphet]](2025, APNet)が「特徴量集約で時間的依存関係と物理的結合をモデル化する」と述べるにとどまり具体的な特徴を明示しなかったのに対し、本ソースは同じ物理ドメイン(光トランシーバー)で「どの DDM/OS 属性が予兆になるか」を先に定量化した先行研究であり、[[OptProphet]] の設計判断(時間的依存関係=エラーレートの自己相関、物理的結合=バイアス電流/温度/パワーの相互相関)を裏付ける実証的な基盤を提供する。(Source: [[@2023__CCGrid__An Optical Transceiver Reliability Study based on SFP Monitoring and OS-level Metric Data]], [[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]]) > [!note] 2026-08-10 追記: [[OptProphet]] の PDF 原本を取り込んだ結果、上記の「具体的な特徴を明示しなかった」という前提は訂正を要する。実際には Interpretable Feature Extraction(IFE: statistical/temporal/spectrum の 3 種)がメトリクス内の時間的依存関係を、Attention-Enhanced Feature Representation(AEFR: Transformer エンコーダの self-attention)がメトリクス間の物理的結合を担うと明記されていた。ただし Notaro+ 2023 のような「どの DDM/OS 属性が予兆として最も強いか」という lift 分析までは踏み込んでおらず、IFE/AEFR がバイアス電流・温度・Rx/Tx パワーの高分散といった Notaro+ 2023 の上位予兆特徴を暗黙に internalize しているのか、それとも別の統計特徴に依っているのかは OptProphet 本文からは確認できない。(Source: [[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]]) - **同一著者系譜内で「サーベイ(taxonomy 整理)→ 実証データ分析(特徴発見)→ 応用予測モデル(タスク統合)」という 3 段階の進化が追跡できる**: Notaro et al. は 2021 年に [[A Survey of AIOps Methods for Failure Management]] で online failure prediction の taxonomy(症状監視・function approximation 系統等)を整理し、2023 年には同じ著者陣(Notaro・Cardoso・Gerndt)が [[@2023__CCGrid__An Optical Transceiver Reliability Study based on SFP Monitoring and OS-level Metric Data]] で実データから予兆特徴(エラーレート・バイアス電流等)を発見し、Random Forest/XGBoost/Logistic Regression/閾値ベース推定器による予測(precision 72.8-95.7%、recall 21.2-50.0%)を評価した。この系譜は 2025 年の [[OptProphet]](別著者陣、Nankai University)が同じ光トランシーバー故障を予測「と」分類の統合タスクへ発展させる土台になっている——1 つの物理コンポーネント(光トランシーバー)に対し taxonomy → 実証 → 応用という研究の成熟過程が本 wiki 上で追跡可能になった。(Source: [[A Survey of AIOps Methods for Failure Management]], [[@2023__CCGrid__An Optical Transceiver Reliability Study based on SFP Monitoring and OS-level Metric Data]], [[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]]) - **2018年のSRE実務入門は、LSTM時系列予測をサービスレベルの短期予測(数時間先)として提示し、Salfner+ 2010が体系化する予測パラメータの明示や評価指標には触れない**: 『SREの探求』第18章は、数か月分のnginxリクエストデータからKeras/TensorFlowのLSTMで今後20時間のトラフィックを予測する実験的モデルを示し(§18.6.2.5)、「必要に応じて新規ハードウェアを実際にプロビジョニングし、サービス障害の問題を回避できる可能性が高まる」とキャパシティプランニング・インシデント対応への活用を述べる。本ページが基礎とするSalfner+ 2010の時間軸4パラメータ($t_d,t_l,t_p,t_w$)や評価指標(precision/recall)は明示されず、120日分の訓練データ・160時間の交差検証という具体的な比率のみが「最も優れた結果を返した」経験則として示される点が、当時の実務入門の性格を表している。同章はまた、時系列の異常検出による自動処理トリガー(§18.6.2.5)とDeepMindのデータセンター冷却PUE予測(§18.7、[[データセンター信頼性]]参照)を、いずれも「将来を予見して事前対応する」という同じ発想の異なる応用例として並べており、障害予測(サービス障害の回避)とキャパシティ予測(ハードウェアプロビジョニング)を明確に区別しない。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 18 SREのための機械学習入門]] §18.6.2.5, §18.7, [[A Survey of Online Failure Prediction Methods]] §2.2) - **1996年の静的メトリクスベース故障傾向予測(SDP の原型)は、Remil+ 2024 が「本 wiki 群で存在感が薄い」と指摘した空白を約28年遡って埋める先駆例である**: 本ページの横断的知見はこれまで online failure prediction(実行時テレメトリ・ログ・アラートからの予測)を中心に蓄積してきたが、*Handbook of Software Reliability Engineering* 第12章(Munson & Khoshgoftaar, 1996)は、コードの実行を一切観測せず、LOC・Halstead ソフトウェアサイエンス・McCabe 循環的複雑度という**静的メトリクス**だけから故障傾向モジュールを予測する。多重共線性を主成分分析で解消したドメインメトリクスを独立変数とする線形判別分析で、Medical Imaging System(390 モジュール、約40,000行)の高リスク/低リスク分類の誤分類率約12%(タイプ2誤り率約13%)を達成し、重回帰モデルでは変更数予測の平均絶対誤差5.32を報告する。これは [[@2024__arXiv__AIOps Solutions for Incident Management]] §3.3 が Prevention 能力に組み入れた SDP(Software Defect Prediction)——Eclipse/PROMISE/NASA データセット系列の古典 ML(SVM・DBN・CNN)研究——の直接の先祖にあたる、コードメトリクスと判別分析・重回帰という古典統計手法による定式化である。本ページが繰り返し確認してきた「予測本体は軽量 ML([[PAGER]]・[[AirAlert]])」という設計判断の系譜は、1996年の判別分析・重回帰までさかのぼれることになる。ただし対象は実行時の障害でなくソースコード上の欠陥(fault)であり、Salfner+ 2010 の taxonomy(§4)にも Notaro+ 2021 の proactive/reactive 軸にも位置づけられない、開発時点の静的予測という第五の系統(オフラインの SDP)として別枠で扱う必要がある。(Source: [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 12 Software Metrics for Reliability Assessment]], [[@2024__arXiv__AIOps Solutions for Incident Management]] §3.3) - **ch.17(Karunanithi・Malaiya)は、ch.12(Munson・Khoshgoftaar)が主成分分析・線形判別分析・重回帰で解いた「静的メトリクスからの故障傾向モジュール予測」と同じ問題(同じ Medical Imaging System データセット、同じ11複雑性メトリクス)を、分類器の選択という軸で再検証した**: ch.12 は多重共線性を主成分分析で除去し、直交ドメインメトリクス(サイズ系・制御フロー系)を独立変数とする線形判別分析で高リスク/低リスクモジュールを分類する(全体誤分類率約12%)。ch.17 は同じ390モジュール・11メトリクスのMISサブセットに対し、ガウス分類器(統計的な最小距離判別)・パーセプトロン(線形判別に相当するニューラルネットワーク)・カスケード相関による多層ネットワーク(非線形判別境界を学習できるニューラルネットワーク)の3分類器を比較した。両章は「多重共線性のある複雑性メトリクスをそのまま判別分析に投入すると不安定になる」という同じ課題認識を共有しつつ、異なる技術的解を与える——ch.12 は主成分分析による次元縮約で対応し、ch.17 はニューラルネットワークに非線形写像を直接学習させることで、次元縮約なしに複雑性メトリクス空間の非線形性に対応する。ただし閾値設定が異なる(ch.12 は変更数1件以下/2件以上の2値、ch.17 は0-1件/10件以上の3値・中位2-9件を分析から除外)ため、誤分類率を直接比較することはできない。ch.17 のパーセプトロンが訓練集合の75〜80%しか学習できなかった(=線形分離不可能なパターンが一定割合存在した)という報告は、ch.12 が主成分分析後もなお残る複雑性メトリクス空間の非線形性を、間接的に裏づける観察になっている。(Source: [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 12 Software Metrics for Reliability Assessment]] §12.4.1-§12.4.3, [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 17 Neural Networks for Software Reliability Engineering]] §17.5.1-§17.5.3) - **ch.17 の実験は、Type I/Type II 誤りという非対称な誤分類コストの観点から、単一の「最良の分類器」という問いそのものを退ける——ch.12 が単一モデル(線形判別分析)の誤分類率を単一の数値として報告するのに対し、ch.17 は分類器ごとの得意・不得意を訓練データ量にわたって定量化する**: ch.17 §17.5.7 は、低故障傾向(カテゴリI)モジュールの分類ではガウス分類器・パーセプトロンが訓練データの少ない開発初期段階で優位である一方、高故障傾向(カテゴリII)モジュールの分類では多層ネットワークが訓練集合サイズによらず一貫して優れることを示した(Table 17.4/17.5)。Type II error(高故障傾向モジュールの見落とし、低品質リリースにつながる)は Type I error(テスト資源の浪費)より信頼性の観点で深刻であると ch.17 自身が明言しており、これは ch.12 が単一の判別分析モデルの誤分類率(約12%)のみを報告する構成とは対照的である。ch.12 の統計的手法は「1つのモデルでどこまで正確に予測できるか」を問うのに対し、ch.17 のニューラルネットワーク実験は「どの分類器をどの誤りコストの状況で使うべきか」という、モデル選択自体を問いの対象にしている。(Source: [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 17 Neural Networks for Software Reliability Engineering]] §17.5.6-§17.5.7, [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 12 Software Metrics for Reliability Assessment]] §12.4.3) - **ハードウェア障害予測の「コンポーネント別に個別最適化された特徴表現」という共通パターンに、メモリ(DRAM)が新たな一例を加える**: 本ページが蓄積してきたハードウェア障害予測は、HDD([[ハードディスク信頼性]] の SMART カウンタ)・GPU(HeaRank のワークロード非依存メトリクス)・光トランシーバー([[OptProphet]] の DDM モニタリング特徴)と、いずれもコンポーネント固有の観測可能量から特徴を設計してきた。[[@2025__KDD__M2-MFP - A Multi-Scale and Multi-Level Memory Failure Prediction Framework for Reliable Cloud Infrastructure]](KDD 2025)は、DIMM の Correctable Error ログが持つ DIMM レベル(rank/device/bank 座標)・bit レベル(DQ×Beat 行列)という**階層的空間構造**を明示的に特徴表現へ落とし込む Binary Spatial Feature Extractor(BSFE)を提案し、対称性・汎用性・敏感性という設計原則を明文化した点で、既存のハードウェア障害予測(HDD の単純な閾値ベース SMART 特徴、GPU の集約統計量)より一段階抽象化された特徴設計の方法論を示す。ハードウェア障害予測は「どのコンポーネントも独自の物理的観測量から特徴を作る」という共通の出発点を持ちながら、特徴設計の抽象度(生の観測量 → 統計量 → 階層的空間表現)という軸で進化が続いている。(Source: [[@2025__KDD__M2-MFP - A Multi-Scale and Multi-Level Memory Failure Prediction Framework for Reliable Cloud Infrastructure]], [[@2007__FAST__Failure Trends in a Large Disk Drive Population]], [[@2026__arXiv__Don't Predict, Prioritize - Rethinking GPU Reliability Assessment]]) - **予測の「時間粒度を分けて相補的に統合する」設計が、GPU のランキング再定式化とは異なる形でメモリ障害予測にも現れる**: HeaRank(GPU 障害)が精密な時間予測を諦めランキングへ再定式化したのに対し、M2-MFP は時間予測のタスク設定自体は維持しつつ、time-patch(観測ウィンドウ内の集約特徴、レイテンシはあるがノイズに強い)と time-point(単発 CE イベントの即時判定、レイテンシは低いが単発ノイズに弱い)という**異なる時間スケールの二経路**を組み合わせることで精度を上げる。リード時間を 1 秒〜60 分まで振った実験(Figure 8)では両モジュールが全リード時間設定で相補的であり続けたと報告されている。「疎で確率的な障害シグナル」という同じ制約に対し、GPU はタスクの出力形式(絶対時刻 → 相対順位)を変え、メモリは時間粒度の異なる 2 モデルを並列運用するという異なる対応を取っている。(Source: [[@2025__KDD__M2-MFP - A Multi-Scale and Multi-Level Memory Failure Prediction Framework for Reliable Cloud Infrastructure]], [[@2026__arXiv__Don't Predict, Prioritize - Rethinking GPU Reliability Assessment]]) - **因果発見を LLM 推論の制約として組み込む設計が、障害予測に「解釈可能な伝播チェーン」という新しい出力形式をもたらした——本ページが蓄積してきた「予測本体は軽量 ML、LLM は説明層」([[PAGER]]・[[AirAlert]])という分業パターンとは異なる第3の軸**: [[@2026__ISSRE__ChainCraft - Bridging Causal Discovery and LLM Reasoning for Failure Prediction in Microservices]](ChainCraft)は、PCMCI([[因果発見]]の主要手法)で異常メトリクス間の因果グラフを構築し、この因果グラフを制約として LLM に異常伝播チェーンを生成させ、閉ループの構造/時間/意味検証で反復洗練する。PAGER が「予測は random forest、説明は LLM」と役割を分けるのに対し、ChainCraft は LLM 自体に因果制約下で予測**兼**説明(伝播チェーン)を生成させる。アブレーションでは PCMCI 除去(C1)が最大の F1・Recall 低下をもたらし(DeepSeek-V4 で F1 0.845→0.729)、[[因果発見]]の因果グラフが LLM の伝播チェーン生成の信頼性を担保する構造的足場として機能することを定量的に裏づけた。Alibaba 実運用データで F1=0.875(最良ベースライン比 +22%)を達成し、3か月間の産業デプロイで OCE が精度 80.8% を確認した。(Source: [[@2026__ISSRE__ChainCraft - Bridging Causal Discovery and LLM Reasoning for Failure Prediction in Microservices]], [[@2026__AAAI__PAGER - Proactive Monitoring Agent for Enterprise AI Assistant]]) - **[[LLMによる根本原因分析]]で蓄積されてきた「LLM の役割分化」パターン(外部知識制約・階層分解・反復多数決・事後検証)が、障害予測という異なる時間軸のタスクにも移植可能であることが ChainCraft で確認された**: [[LLMによる根本原因分析]]は RCA(post-hoc 診断)における Chain-of-Thought・反復多数決・外部知識制約によるハルシネーション抑制を蓄積してきたが、ChainCraft の Chain Critic(意味的妥当性評価)・Chain Refiner(最小局所編集)・決定論的 comparator(構造/時間/意味ペナルティの重み付き品質スコア)という閉ループ設計は、これらのパターンを障害予測(pre-hoc 予測)というドメインに適用した初の事例である。予測対象が「すでに起きた障害の原因」ではなく「まだ起きていない障害の伝播経路」である点が、両ドメインの LLM 活用パターンの相違点として今後の比較材料になる。(Source: [[@2026__ISSRE__ChainCraft - Bridging Causal Discovery and LLM Reasoning for Failure Prediction in Microservices]]) - **マイクロサービスの依存関係・障害伝播モデルを予測に組み込む発想は、Bayesian Network(2016)から LLM+因果発見(2026)へ10年かけて手法を入れ替えながら存続している**: Notaro et al. 2021 が§4.2.2で紹介する HORA [119](2016)は、コンポーネント依存・障害伝播モデルを Bayesian Network で表現し、これをシステムメトリクスからの自己回帰予測器と組み合わせてマイクロサービスの QoS違反・障害を予測する(モノリシック手法比で再現率 83.3% 対 69.2%、AUCROC 0.920 対 0.837)。ChainCraft(2026)は同じ「マイクロサービスの依存関係構造を予測に使う」という発想を、手動で設計する Bayesian Network から PCMCI による自動因果発見 + LLM 推論に置き換え、Alibaba 実運用データで F1=0.875 を達成した。10 年間で「アーキテクチャ知識をどう獲得するか」が人手設計から自動発見へ移った一方、「依存構造を予測の足場に使う」という設計思想自体は変わっていない。(Source: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.2 Online Failure Prediction]] §4.2.2, [[@2026__ISSRE__ChainCraft - Bridging Causal Discovery and LLM Reasoning for Failure Prediction in Microservices]]) - **job/task 単位の分類的予測(2018, Google)と host 単位のランキング的予測(HeaRank, GPU クラスタ)は、同じ「大規模計算クラスタのジョブ実行障害」という問題を異なる粒度・異なる出力形式で解いている**: Islam et al. [61](Notaro et al. 2021 §4.2.2 で紹介、Google ワークロードトレース)は LSTM で task レベル F1=0.87・job レベル F1=0.81 の二値分類予測を達成し、予測に基づく再投入でリソース浪費を12–20%削減した——これは精密な二値予測がそのまま運用上の行動(再投入)に直結する例である。一方 HeaRank は GPU 訓練クラスタで同種の精密な時間予測が F1 0.48 程度まで崩壊することを示し、host 単位のランキングへ再定式化した。両者を並べると、CPU クラスタの汎用ジョブ(Google)と GPU 訓練クラスタの同期ジョブでは障害シグナルの予測可能性が大きく異なり、精密な分類的予測が有効な領域とランキングへの再定式化が必要な領域を分けるのは対象クラスタの性質(ワークロード同期性・障害の伝播範囲)である可能性が示唆される。(Source: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.2 Online Failure Prediction]] §4.2.2, [[@2026__arXiv__Don't Predict, Prioritize - Rethinking GPU Reliability Assessment]]) - **ログベース障害予測の文献が疎な理由が、適応パラダイムの分類でも裏づけられた——5系統のうち実質2系統しか使われていない**: [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis - Chapter 6.3 Downstream Log Analysis Tasks - Failure Prediction and Root Cause Analysis]] は、LLM4Log第3章が定義する5つの適応・強化パラダイム(プロンプティング/ICL・検索によるグラウンディング・ファインチューニング・ツール拡張/エージェント型・検証/較正)のうち、既知の4論文(CrashEventLLM・FALL・shellログ+LLM・VMFT-LAD)で明示的に使われているのはプロンプティング/ICL(CrashEventLLMの生成的予測)とファインチューニング(FALLの識別的スコアリング)の2系統のみだと整理する。検索拡張・エージェント型・検証機構はいずれも未使用であり、本ページが既に確認してきた「ログベース障害予測はsparse and heterogeneous」という観察を、パラダイムの疎さという別角度から裏づける。ChainCraft(因果発見+LLM)やHeaRank(ランキング再定式化)がメトリクス/テレメトリ主体の予測タスクで多様な設計を試みているのと対照的に、ログ主体の予測はまだ設計空間の一部しか探索されていない。(Source: [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis - Chapter 6.3 Downstream Log Analysis Tasks - Failure Prediction and Root Cause Analysis]]) - **「ビジネス影響の予測」を出発点に、IT イベント予測が下流タスクとして副次的に達成される事例が加わった**: 本ページの既存事例(PAGER・OptProphet・HeaRank・ChainCraft 等)はいずれも「IT/インフラ障害そのもの」を第一の予測対象とするのに対し、[[AutoMixer]]([[@2023__arXiv__AutoMixer for Improved Multivariate Time-Series Forecasting on Business and IT Observability Data]])は逆向きの出発点を取る——第一の目的はビジネス KPI(スループット・レイテンシ等)の予測であり、IT イベント予測(§3.4 の下流タスクの1つ、TSMixer-CC 比で平均 3.2% MSE 改善)はチャネル圧縮事前学習済みモデルの汎化性を示す**副産物**として達成される。障害予測の既存事例が「障害 → ビジネス影響」という一方向の因果を前提に障害側から予測を試みるのに対し、AutoMixer は「ビジネス KPI と IT イベントを同一多変量空間の異なるチャネルとして扱う」ことで、どちらを予測対象にするかをタスク定義の選択に還元している。ダッシュボード(Figure 2)は予測された IT イベント影響を推定損失額・復旧時間としてビジネス言語に変換して提示しており、[[PAGER]] の「予測は軽量 ML、説明・提示は LLM/UI」という分業パターンに近い設計思想を、LLM を介さないダッシュボード UI で先取りしている。(Source: [[@2023__arXiv__AutoMixer for Improved Multivariate Time-Series Forecasting on Business and IT Observability Data]], [[@2026__AAAI__PAGER - Proactive Monitoring Agent for Enterprise AI Assistant]]) - [イベント形成の予測系への統合] Falcon は閾値・N-of-K持続性・クールダウンから成るイベントポリシーを後付けの後処理ではなく学習器と合わせて検証しており、持続性やクールダウンを外すと4障害すべてでF1が悪化することを定量的に示した(Remapping FailureはF1 0.500→0.409、クールダウン除去でF1 0.500→0.278)。既存事例([[@2026__AAAI__PAGER - Proactive Monitoring Agent for Enterprise AI Assistant]] 等)がウィンドウレベルの確率をそのまま出力するのに対し、Falconはイベント形成自体を検証対象に含める設計を明示的に採る。(Source: [[@2026__ISSRE__From Noisy Telemetry to Actionable Warnings - GPU Failure Prediction in Industrial Clusters]]) - [オフライン目的関数と本番展開の目的関数の分離] Falconはオフライン評価をイベントレベルF1で最適化する一方、ByteDanceでの本番展開では偽陽性1件あたりの運用コスト(ワークロード移行・診断・ストレステスト)を反映して適合率志向の運用点へ較正しており、展開時は分母(実際の障害総数)が非公開のため再現率を報告せず適合率のみを報告する。F1最適化と展開時のコスト関数を意図的に分離するこの設計は、[[@2019__WWW__Outage Prediction and Diagnosis for Cloud Service Systems]] 等の従来事例と同様、単一の統計指標では運用要件を代表できないという既存知見を、GPUハードウェア障害という新しい対象領域で裏付ける。(Source: [[@2026__ISSRE__From Noisy Telemetry to Actionable Warnings - GPU Failure Prediction in Industrial Clusters]]) - HPC ハードウェアエラーの**日次件数系列**予測は、故障そのものの予測ではなく早期信号の予測可能性評価である。Theta 7年ログでは Minor(規則的)のみ LSTM/Transformer(+時間特徴)が有効で、Intermediate/Major/Critical(疎・バースト)ではモデル間差が小さく、限界は主に信号の不規則性にあると報告される。配備可能な故障予測枠組みではない点が、本ページの多くの事例(イベント形成・偽陽性コスト較正を含む予測系)と対象が異なる。(Source: [[@2026__arXiv__Evaluating Forecasting Techniques for Hardware Errors on a Large-scale HPC System]]) ## 未解決の問い - eWarn の予測窓サイズ `t_p`(Salfner+ 2010 の `t_p` と同一パラメータ)はシステムごとに最適値が異なり(S2 は約70分、S8 は約90分)、検証セットでのチューニングが前提となる。この「システムごとに最適 `t_p` が異なる」という実証観察は、Salfner+ 2010 の `t_p → ∞` ゲーム可能性の警告と合わせ、`t_p` の自動選定手法をどう設計すべきかという問いを残す。汎用的な自動選定は eWarn 論文でも未提示。 - eWarn は「予兆のないインシデント(電源障害等)は予測できない」ことを自ら認め、学習時にはこれらを正例として扱いラベルノイズの一因としている(§5.3 の脅威分析)。これは [[A Survey of AIOps in the Era of Large Language Models]] の「precursor のない障害が多く false negative が高い」という指摘と独立に整合する実証データ点だが、eWarn 自身はこのノイズラベルを除去する具体策(インシデントチケットの詳細情報活用等)を将来課題に留めている。 - 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 やマルチモーダルなデータ統合で緩和できるのか、それとも稀事象予測の原理的限界か。予兆のある障害クラス(リソース漸増・依存劣化)と予兆のない障害クラス(突発的なハードウェア故障)で予測可能性はどこまで分かれるか。([[A Survey of AIOps in the Era of Large Language Models]]) - ~~[[OptProphet]] は不均衡なデータ分布を「自動的に処理」すると述べるが、その具体的な仕組みは出典(Abstract のみ)では確認できない。~~ → **2026-08-10 解決**: PDF 原本により、Information-Aware Undersampling(IAU、冗長な健全段階サンプルの削除)と Feature-Weighted Oversampling(FWO、分類難易度に基づく少数派リスクサンプルの合成)を組み合わせ、最適サンプリング比率を自動決定するとわかった(リサンプリング系の手法)。ただし IAU/FWO の内部アルゴリズム(どの特徴量で「難易度」を定義するか)は 3 ページの短編論文の紙幅内では数式化されておらず、稀な故障クラスの予測底上げに関する一般的な under/oversampling 手法(SMOTE 系等)との定量比較は本論文に無い。(Source: [[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]]) - [[OptProphet]] が特徴量集約でモデル化する「物理的結合」は、PDF 原本により Attention-Enhanced Feature Representation(AEFR、Transformer エンコーダの self-attention でメトリクス間の相互作用を捉える)と判明した。ただし GPU 訓練クラスタのレール最適化トポロジ([[R-Pingmesh]] 等が前提とする物理配線)を明示的な入力特徴として組み込むかどうかは論文本文でも触れられておらず、AEFR が学習する「結合」が物理配線トポロジと対応するのか、それとも同一デバイス内のメトリクス相互作用(温度・バイアス電流・パワー等)にとどまるのかは未確認のまま残る。故障予測の精度・先回り余裕(1.11 日)へのトポロジ情報の寄与も出典に現れない。 - LLM4Log サーベイが挙げる障害予測の核心課題「予測品質・適時性(lead time)・actionability の一貫評価が未確立」は、生成型(CrashEventLLM の ROUGE 評価が timestamp/causal の正しさを忠実に反映しない問題)と discriminative 型(FALL の AUC・pre-failure 窓のデータリーク制御)でどう統一できるか。structured 評価(障害種別/時刻 bin の exact match + 証拠 grounding)へ移れるか。([[LLM4Log]]) - Salfner+ 2010 §4.4 で「該当文献なし」とされた undetected error auditing(系統 4)の枝は、eBPF・kprobe・runtime audit が一般化した 2020 年代でも本当に空白なのか。runtime audit を input として障害を予測する研究が今でも希少なのは、(a) audit がコスト高で常時実行に向かない、(b) 検出されない error は定義上「現状の検出器の盲点」なので学習データのラベリングが難しい、のどちらが主因か。([[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, [[A Survey of AIOps Methods for Failure Management]] §4.1) - Salfner+ 2010 §3.1 末尾の警告 "`t_p → ∞` では「常に failure」戦略でも recall = 1 を達成してしまう" は、LLM 生成型予測の評価でどう守られているのか。CrashEventLLM 系のように自由文で時刻と原因を生成する設計では `t_p` を明示しないため、recall を測れているのか曖昧になる。出力に必ず予測窓を含める制約と、それを構造化評価する基盤が要る。([[A Survey of Online Failure Prediction Methods]] §3.1, [[LLM4Log]] §6.3) - HeaRank が示した「精密予測を諦めランキングへ再定式化する」路線は、GPU 障害以外のどの障害クラスに一般化できるか。本ページが蓄積してきた HDD([[@2007__FAST__Failure Trends in a Large Disk Drive Population]])・ログベース([[LLM4Log]])・サービスレベル 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 特有(高密度・高発熱・同期ジョブ依存)の現象か。 - [[@2023__CCGrid__An Optical Transceiver Reliability Study based on SFP Monitoring and OS-level Metric Data]] は著者ら自身がデバイスの経年(age)を分析に含めていないと明示する(§IX)。バイアス電流高値の予兆はレーザー老朽化に起因すると考えられており(§II-A)、経年を明示的な特徴量として組み込めば故障予測の recall(現状 21.2-50.0%)は改善するか。HDD 予測における「シグナルが出ない障害ドライブ 56% 超」問題(Pinheiro+ 2007)と同様、光トランシーバーにも予兆のない突発故障が一定割合存在するのか、経年データがあれば説明できるのかは未検証。 - [[@2023__CCGrid__An Optical Transceiver Reliability Study based on SFP Monitoring and OS-level Metric Data]] の 4 独立分析軸(自己相関・AFR・運用範囲・lift)がすべて一致してエラーレート最強と結論した一方、ML 予測モデルの recall は 21.2-50.0% にとどまる。単変量の統計的関連(lift 9.13x)と多変量 ML モデルの予測性能(recall 上限 50%)の間にあるギャップは、特徴量エンジニアリングの余地か、それとも稀事象予測の原理的限界(本ページが繰り返し確認してきた「予兆のない障害」問題)によるものか。 - 予測モデルだけを磨いても可用性は伸びないという Salfner+ 2010 §6 の結論(対策側の進化が要る)は、LLM 期に逆転するのか。LLM がスケジューリング・実行段に入れば end-to-end の PFM ループが回るはずだが、現実の [[PAGER]] や [[Bian Que]] は予測層・説明層・実行層を別モジュールに分けている。1 つの自律ループに畳む実装上の障壁は何か。([[プロアクティブ障害管理]] と連動) - ch.12 の主成分分析による次元縮約(直交ドメインメトリクスへの変換)を、ch.17 のニューラルネットワーク分類器の入力前処理として組み合わせた場合、パーセプトロンが学習できなかった約20〜25%の非線形分離不可能なパターンの割合は減るか。両章は独立した前処理パイプラインを使っており、組み合わせの効果は本ページのソースからは確認できない。 - ch.17 のカスケード相関による多層ネットワークが Type II error で一貫して優れる理由(非線形判別境界の学習能力)は、ch.12 の主成分分析後の2ドメイン(サイズ系・制御フロー系)構造とどう関係するか。もし高故障傾向モジュールの決定境界がこの2次元空間で本質的に非線形であるなら、ch.12 の線形判別分析が原理的に不利になる可能性があるが、本ページのソースだけでは検証できない。 - ChainCraft の故障事例リポジトリはわずか13件(頻出・運用上代表的なシナリオのみ)であり、稀少・新奇な障害パターンへの汎化性は評価されていない。本ページが蓄積してきた「予兆のない障害・稀事象予測の原理的限界」(Pinheiro+ 2007、LLM4Log)という問いは、ChainCraft のような少数事例からの構造的類似度検索アプローチでどこまで緩和されるか、あるいは同じ限界に直面するかは未検証。(Source: [[@2026__ISSRE__ChainCraft - Bridging Causal Discovery and LLM Reasoning for Failure Prediction in Microservices]]) - Notaro et al. 2021 §4.2 のレビュー対象の中で、実際に lead time(発生何時間/分前に検知できたか)を定量報告する研究は Wang et al.(20時間以上前56%)とログベースRNN(平均73分早期)のみで、大半は precision/recall/F尺度どまりだった。本ページが強調してきた Salfner+ 2010 の時間軸4パラメータ(`t_d, t_l, t_p, t_w`)の重要性に照らすと、2010年代の障害予測研究全体でこの報告不足はどれほど一般的か、また LLM 期の評価設計([[LLM4Log]])はこの慣行をどう是正しうるか。([[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.2 Online Failure Prediction]]) - HORA(2016)とChainCraft(2026)はいずれもマイクロサービスの依存構造を予測の足場にするが、依存グラフの構築コスト(HORA: アーキテクチャ知識の人手投入、ChainCraft: PCMCI因果発見の計算コスト)と予測精度の関係を同一ベンチマークで比較した研究はまだ本ページにない。自動因果発見は人手のアーキテクチャ知識をどこまで代替できるか、あるいは補完的に組み合わせるべきか。 - Salfner+ 2010(観測経路軸: failure tracking / symptom monitoring / detected error reporting / undetected error auditing)と Notaro+ 2021(対象軸: hardware / system)を交差させると、本ページが蓄積してきた LLM 期の手法群(PAGER・ChainCraft・OptProphet・HeaRank・LLM4Log 系)は Salfner のどの枝に集中し、どの枝(特に detected error reporting の rule-based approaches・statistical tests、failure tracking の cooccurrence)が空白のまま残っているか、体系的に棚卸しされていない。Notaro のオブジェクト軸だけでは見えない「観測経路の偏り」を可視化できれば、次に埋めるべき研究空白の候補が具体的に絞り込めるはず。(Source: [[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods - Chapter 4 A Taxonomy of Online Failure Prediction Methods]] §4, [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.2 Online Failure Prediction]]) - Salfner+ 2010 §6 はディペンダビリティが恒久的な課題であり続ける理由として、システムの複雑化・脅威の増大・非熟練ユーザー・サードパーティ/OSS/COTS コンポーネントへの依存・接続性と相互運用性の拡大・動的性(頻繁な設定変更・アップグレード・パッチ)・応用領域への浸透、の7点を挙げる。本ページが集めた LLM 期の手法群(PAGER・ChainCraft・OptProphet・HeaRank・LLM4Log 系)のうち、サードパーティ/COTS コンポーネント起因の障害や、頻繁な再設定・アップグレードによる分布変化(ドリフト)に明示的に追従する予測手法を扱ったものはまだない。この2つの要因(サードパーティ依存・動的性)は本ページの手法群が正面から扱えていない空白として残る。(Source: [[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods - Chapter 6 Summary and Conclusions]] §6) - AutoMixer の IT イベント予測(分類精度 77.82%、Application データセット)は Salfner+ 2010 の時間軸4パラメータ(`t_d, t_l, t_p, t_w`)や lead time を明示しない。予測ホライズン `H=24` ポイント(データセットのサンプリング間隔依存で数秒〜数時間相当)が実運用の warning time `t_w` を満たすかどうかは論文からは確認できない。BizITObs のようにビジネス KPI 予測を主目的としつつ副次的に IT イベントも予測する設計は、本ページの時間軸厳密性(Salfner の枠組み)とどう整合させるべきか。([[@2023__arXiv__AutoMixer for Improved Multivariate Time-Series Forecasting on Business and IT Observability Data]], [[A Survey of Online Failure Prediction Methods]] §2.2) - Falconは障害種別ごとに異なる学習器(CatBoost/Random Forest/LightGBM)を選択しているが、この障害固有モデル選択の枠組みは、GPU以外のハードウェア障害予測(ディスク・NIC等)や、既存の統一モデル志向の事例([[@2026__AAAI__PAGER - Proactive Monitoring Agent for Enterprise AI Assistant]] 等)にどこまで一般化できるか。 - ハードウェアエラー件数の時系列予測が「有用」とみなせる閾値(介入可能な lead time・許容偽陽性など)を、本ページの障害予測事例とどう接続して定義すべきか。著者自身も HPC 予測保全の標準指標が未定義だと指摘する。(Source: [[@2026__arXiv__Evaluating Forecasting Techniques for Hardware Errors on a Large-scale HPC System]]) ## 関連 - ソース: [[@2026__ISSRE__ChainCraft - Bridging Causal Discovery and LLM Reasoning for Failure Prediction in Microservices]] / [[@2021__OReillyJapan__SREの探求 - Chapter 18 SREのための機械学習入門]] / [[@2026__arXiv__Don't Predict, Prioritize - Rethinking GPU Reliability Assessment]] / [[A Survey of Online Failure Prediction Methods]] / [[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods - Chapter 4 A Taxonomy of Online Failure Prediction Methods]] / [[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods - Chapter 6 Summary and Conclusions]] / [[A Survey of AIOps Methods for Failure Management]] / [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.2 Online Failure Prediction]] / [[@2026__AAAI__PAGER - Proactive Monitoring Agent for Enterprise AI Assistant]] / [[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]] / [[@2023__CCGrid__An Optical Transceiver Reliability Study based on SFP Monitoring and OS-level Metric Data]] / [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]] / [[@2020__ESEC-FSE__Real-Time Incident Prediction for Online Service Systems]] / [[@2019__WWW__Outage Prediction and Diagnosis for Cloud Service Systems]] / [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 12 Software Metrics for Reliability Assessment]] / [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 17 Neural Networks for Software Reliability Engineering]] / [[@2026__ISSRE__From Noisy Telemetry to Actionable Warnings - GPU Failure Prediction in Industrial Clusters]] - 概念: [[プロアクティブ障害管理]] / [[プロアクティブ検証]] / [[グレイ障害]] / [[ソフトウェアエイジング]] / [[AIOps]] / [[異常検知]] / [[ログ解析]] / [[agentic SRE]] / [[SRE AI Autonomy Levels]] / [[GPUクラスタ運用]] / [[GPUレジリエンス]] / [[耐障害LLM訓練]] / [[AirAlert]] / [[アラート管理]] / [[ソフトウェア複雑性]] / [[主成分分析]] / [[因果発見]] / [[LLMによる根本原因分析]] / [[AutoMixer]] / [[多変量時系列予測]] - エンティティ: [[Felix Salfner]] / [[Miroslaw Malek]] / [[Humboldt University of Berlin]] / [[PAGER]] / [[Adobe Experience Platform]] / [[Detectr]] / [[Google]] / [[OptProphet]] / [[Difeng Ma]] / [[Changhua Pei]] / [[Nengwen Zhao]] / [[Dan Pei]] / [[Paolo Notaro]] / [[Jorge Cardoso]] / [[Michael Gerndt]] / [[John Munson]] / [[Taghi Khoshgoftaar]] / [[Nachimuthu Karunanithi]] / [[Yashwant Malaiya]] / [[Yongxin Zhao]] / [[Yongqian Sun]] - 関連 MOC: [[AIOps - Failure Detection - MOC]] / [[LLM4SRE - MOC]] - sources: [[@2026__arXiv__Evaluating Forecasting Techniques for Hardware Errors on a Large-scale HPC System]] ## 出典 - [[@2026__ISSRE__ChainCraft - Bridging Causal Discovery and LLM Reasoning for Failure Prediction in Microservices]](PCMCI 因果発見による因果グラフ制約下の LLM 伝播チェーン生成、閉ループ洗練、ハイブリッド検索、Alibaba 実運用評価・3か月間産業デプロイ) - [[@2021__OReillyJapan__SREの探求 - Chapter 18 SREのための機械学習入門]] §18.6.2.5, §18.7. - [[@2026__arXiv__Don't Predict, Prioritize - Rethinking GPU Reliability Assessment]](§3 Predictability Analysis: 5 モデル横断の予測限界実証・Kendall 相関/SNR/分布比較、§4 HeaRank の LTR 再定式化、§6 オンライン展開結果) - [[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 結論) - [[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods - Chapter 4 A Taxonomy of Online Failure Prediction Methods]](§4 taxonomy の設計原理・Figure 8 の階層構造・§4.1〜§4.4 各枝の principal approach/category 一覧) - [[@2026__AAAI__PAGER - Proactive Monitoring Agent for Enterprise AI Assistant]](Abstract, Introduction, System Overview, Results) - [[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) - [[@2023__CCGrid__An Optical Transceiver Reliability Study based on SFP Monitoring and OS-level Metric Data]](§VII-A 時系列自己相関、§VII-B AFR 推定、§VII-C 運用範囲比較、§VII-D パターン lift 分析、§VII-E ML 予測モデル評価、§IX 経年未考慮の限界) - [[LLM4Log]](§6.3 Failure Prediction: タスク定義/4 論文と sparse/heterogeneous, CrashEventLLM/FALL/shell ログ/VMFT-LAD, 評価未確立の課題) - [[A Survey of AIOps Methods for Failure Management]](§4.2 online failure prediction: HDD/system 別の代表手法、SMART/HMM/SVM/RNN/LSTM の系譜、lead/prediction/warning time の評価軸) - [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.2 Online Failure Prediction]](§4.2.1 Hardware Failure Prediction の手法別定量結果一覧、§4.2.2 System Failure Prediction の HORA・Islam et al. 等) - [[@2020__ESEC-FSE__Real-Time Incident Prediction for Online Service Systems]](§3 提案手法、§4.2 AirAlert 追試による性能崩壊の実証、§4.3.2 LDA vs TextCNN/FastText、§5.1 実運用成功事例と解釈可能性による診断転用) - John C. Munson, Taghi M. Khoshgoftaar, "Software Metrics for Reliability Assessment", in Michael R. Lyu (ed.), *Handbook of Software Reliability Engineering*, IEEE Computer Society Press / McGraw-Hill, 1996, Chapter 12, §12.4.2–§12.4.4(MIS ケーススタディ、判別分析・重回帰による静的メトリクスベース故障傾向予測) - [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 17 Neural Networks for Software Reliability Engineering]] §17.5.1-§17.5.7(同じ MIS データセットに対するガウス分類器・パーセプトロン・多層ネットワークの比較、Type I/II 誤り分析) - [[@2023__arXiv__AutoMixer for Improved Multivariate Time-Series Forecasting on Business and IT Observability Data]](§3.4 IT イベント予測・分類の下流タスク評価、Table 5)