# 異常検知 ## 定義 異常検知(anomaly detection)は、システムの正常な挙動から逸脱する異常な振る舞いやパターンを特定し、潜在的な問題や障害の早期指標とする取り組み。[[AIOps]] の障害認知(failure perception)段における中心タスクで、LLM 登場の前後を通じて障害認知の中で最も研究が活発な領域である。([[A Survey of AIOps in the Era of Large Language Models]] §4.1) failure prediction が「precursor のない障害が多く取りこぼしが多い」という限界を抱えるのに対し、異常検知は「逸脱の検出」に焦点を絞ることで実用的な障害認知の主軸になっている。主にログとメトリクスを入力とし、近年は設定データ等のソフトウェア情報も併用される。AIOps の 4-level taxonomy では Level 1 の Detection に対応する([[AIOpsLab]])。 古典的には、異常検知は「期待される振る舞いに適合しないデータ中のパターンを見つける問題」と定義され、異常の型は点異常(point anomaly)、文脈異常(contextual anomaly)、集合異常(collective anomaly)に分かれる。点異常は個別データ点が残りのデータに対して異常な場合、文脈異常は同じ振る舞い属性でも時間・場所・ユーザーなどの文脈により異常性が変わる場合、集合異常は個々の要素ではなく関連するインスタンスの並びや集合として異常になる場合である。([[Anomaly Detection - A Survey]] §2.2) LLM 時代の異常検知手法は、サーベイの整理では 3 方向に分かれる(§4.1):(1) モデルの汎化向上(時系列・ログの基盤モデルの開発/fine-tuning)、(2) 大モデルで小モデルを強化(LLM がログの埋め込みを生成する等)、(3) モデル学習の回避(プロンプトで次のメトリクス/ログを直接予測する)。 現在の理解を要約すると、異常検知の理論的基礎(Chandola 2009 の 3 分類・6 技法カテゴリの仮定)は今なお有効な足場だが、産業実装は「常時稼働の検知には LLM が重すぎる」という制約のもとで軽量な統計/機械学習手法へ収束し、LLM は検知器そのものよりも説明・検証・メタ判断の層に限定して使われる傾向が強い。マイクロサービス異常検知サーベイの「データ源 × 検知方式」という運用寄りの分類軸は 5 年間安定している一方、説明可能性・信頼性(公平性・頑健性・効率性)への関心は 2021 年の「未解決課題」から 2025 年の形式的要件へと徐々に具体化してきた。争点として残るのは、「何を異常と見なすか」——統計的逸脱かインシデント裏付けかエージェント実行ドメイン固有の意味的失敗か——の定義がドメインごとに割れている点、および正常性の文脈依存性(ホスト間比較・訓練ダイナミクス・ビジネストレンド)がどこまで一般化できるかという点である。 ## 子概念 - [[カーネル密度推定]] - [[グラフベースRCA]] - [[変化点検知]] - [[密度ベースクラスタリング]] - [[時系列分解]] - [[最近傍法]] ## 異常の型と検知技法が置く仮定 - **点異常・文脈異常・集合異常という Chandola 2009 の 3 分類は、後続研究の pattern anomaly 拡張を集合異常の一般化として吸収してもなお枠組みを保つ。** - 根拠: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 2 Different Aspects of an Anomaly Detection Problem]] §2.2.3 — 集合異常の定義とインスタンス間関係の必須性 - 根拠: [[@2015__CSUR__Performance Anomaly Detection and Bottleneck Identification]] — pattern anomaly を「集合異常の一般化」と明記 - **技法群は 6 カテゴリに分かれ、それぞれ異なる統計的仮定に依拠する。分類はラベル可用性、近傍は意味ある距離尺度、クラスタリングは 3 段階のクラスタ構造(前段の仮定の破れを後段が自己修正的に吸収する)、統計は生成確率分布、情報理論はデータ集合全体の情報量、スペクトルは低次元での分離可能性である。** - 根拠: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 4 Classification Based Anomaly Detection Techniques]] §4 — ラベル可用性 - 根拠: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 5 Nearest Neighbor-Based Anomaly Detection Techniques]] §5 — 距離尺度、次元の呪いによる仮定の破れ - 根拠: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 6 Clustering-Based Anomaly Detection Techniques]] §6 — 3 仮定の自己修正的構造 - 根拠: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 7 Statistical Anomaly Detection Techniques]] §7 — 生成分布への依存 - 根拠: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 8 Information Theoretic Anomaly Detection Techniques]] §8、[[@2009__CSUR__Anomaly Detection - A Survey - Chapter 9 Spectral Anomaly Detection Techniques]] §9 — 集合レベルの複雑性と低次元分離可能性 - **サーベイ自身の第 11 章は、6 カテゴリの仮定を統一表にまとめず、計算量(訓練/検証コスト)・ラベル要求・距離尺度への依存・異常の希少性仮定という運用指向の 4 軸で横断比較するにとどめる。** - 根拠: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 11 Relative Strengths and Weaknesses of Anomaly Detection Techniques]] §11 — 仮定の統一表を作らず計算量の二分法を主軸に据える - **マイクロサービス異常検知サーベイの「教師なし/教師あり」2 分法は、Chandola 2009 の半教師あり(正常クラスのみラベルあり)を教師なし側へ暗黙に統合したものであり、同じ「教師なし」という語が文献間で異なる訓練データの中身を指す。** - 根拠: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 2 Different Aspects of an Anomaly Detection Problem]] §2.3 — 教師あり・半教師あり・教師なしの 3 モード - 根拠: [[Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications]] — 「教師なし学習」「教師あり学習」の 2 モードのみに分類 - **技法比較は性能表より先に仮定とドメインの整合性を見る必要があるという古典的洞察は、LLM/時系列基盤モデル時代にも消えていない。** - 根拠: [[@2026__ICML__TelecomTS - A Multi-Modal Observability Dataset for Time Series and Language Analysis]] — 正常な急変動を無視した誤判定 - 根拠: [[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]] — 観測データの正常/異常の弁別自体の不得意さ - **応用ドメインの性質(大量データへの偽陽性の不寛容、文脈設計がドメイン知識を要すること)は 2009 年の侵入検知・不正検知の分析に始まり、現代クラウド運用ドメインにそのまま再現する。** - 根拠: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 3 Applications of Anomaly Detection]] §3.1・§3.2.1 — 偽陽性への不寛容とクレジットカード不正検知の by-owner/by-operation 文脈 - 根拠: [[@2026__ICML__TelecomTS - A Multi-Modal Observability Dataset for Time Series and Language Analysis]]、[[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]] — 現代クラウド運用ドメインでの再現 - **文脈異常への対処は「還元(reduction)」と「構造利用(structure utilization)」の 2 アプローチに分かれ、産業実装の多くは文脈ごとに正常データを切り出して外れ値検知を当てる還元系に属する。** - 根拠: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 10 Handling Contextual Anomalies]] §10.1・§10.2 — 還元と構造利用の計算量トレードオフ - 根拠: [[@2017__SREcon17 Asia__Smart Monitoring System for Anomaly Detection on Business Trends in Alibaba]]、[[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]] — 還元系の産業実例 - **説明可能性は Chandola 2009 の技法比較軸には存在しない観点で、2021 年のマイクロサービスサーベイで「未解決課題」と明言され、2025 年の Trustworthy AI レビューでようやく EU 7 要件由来の技術要件として定式化された。** - 根拠: [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey - Chapter 3.4 Discussion (Anomaly Detection)]] §3.4.4 — 未解決課題としての明言 - 根拠: [[@2025__ACMCSUR__Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications - A Review - Chapter 2 Trustworthiness Requirements and Performance Diagnosis Systems]] §2.1・§2.3 — 公平性・頑健性・説明可能性・効率性の 4 要件への定式化 ## マイクロサービス異常検知サーベイの分類軸 - **Soldani & Brogi 2021 はデータ源(ログ/分散トレース/監視メトリクス)× 検知方式(教師なし/教師あり/トレース比較/SLO チェック/ハートビート)の 2 軸taxonomyを最初に整理し、5 年後の Barata 2026(117 件に拡張)も基本軸を維持する。** - 根拠: [[Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications]] §3.4.1 — セットアップコストと粒度のトレードオフ - 根拠: [[Anomaly detection and root-cause identification in microservices]] — 5 年後も同じ 2 軸が有効 - **データ源の統合は常に性能改善を意味しない。ログ+トレース+監視の 3 種統合は、ログ単体やログ+トレースより accuracy/precision/recall が低い場合がある。** - 根拠: [[Anomaly detection and root-cause identification in microservices]] §4.7 — データ収集の 3 軸比較 - 関連: [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]] — 文脈なしのログ増量が診断を悪化させる観察と同型 - **動的に変化するマイクロサービス(新サービス追加・既存サービス置換・季節性)は、大半の手法が置く「訓練時と同じ条件でアプリが動く」前提を崩す構造的な「訓練問題」を生む。** - 根拠: [[Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications]] §3.4.3 — Seer(定期再訓練)・DLA・PreMiSE それぞれの緩和戦略と再訓練コストのトレードオフ - **Barata 2026 は検知アルゴリズムを教師なし/教師あり/強化学習/トレース比較/統計分析の 5 分類に整理し、強化学習は言及手法 1 件のみという極端な非対称性を持つ。** - 根拠: [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey - Chapter 4.3 Methods to identify anomalies in microservices]] §4.3.1〜§4.3.5 - 留保: 探索キーワード(Table 4)が RL 関連文献を十分に捕捉できていない可能性があり、実際の研究蓄積の薄さと切り分けられない - **定量的な手法間比較の方法論は、Soldani & Brogi 2021 が明示的に範囲外としたのに対し、5 年後の Barata 2026 はデータセット・障害注入・評価指標が揃わないまま平均性能を提示しており、方法論的な後退がある。** - 根拠: [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey - Chapter 3.4 Discussion (Anomaly Detection)]] §3.4.3 — 数値比較の意図的な保留 - 根拠: [[Anomaly detection and root-cause identification in microservices]] §4.7 — データセット・指標が揃わない平均性能の提示 > [!contradiction] 採択論文の総数が既存記述(117 件)と担当章 §4.1 本文(143 件)で食い違う。§4.1 は段階的フィルタ(10485 件 → 837 件 → 306 件 → 171 件 → 143 件)と出版年別内訳(Figure 4 の合計 143)の両方で 143 件を裏づける。「117 件」がどの章のどの数値に基づくかは §4.2・§4.3 からは確認できず、担当章(§4.7 等)側での裏取りを要する。(Source: [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey - Chapter 4.1 Anomaly detection in a microservices environment - Overview]] §4.1.4, Fig. 4) ## 常時稼働の検知とLLMコストの緊張 - **「常時稼働の検知には LLM が重すぎる」という制約が検知系の手法選択を分岐させ、産業は非 LLM の軽量統計/機械学習手法に収束する。** - 根拠: [[A Survey of AIOps in the Era of Large Language Models]] §7.1 — 計算オーバーヘッド問題に十分対処した LLM 研究はまだ無いとの明言 - 根拠: [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]]、[[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]] — 秒〜マイクロ秒級の非 LLM 検知 - 根拠: [[@2025__IWQoS__eACGM - Non-instrumented Performance Tracing and Anomaly Detection towards Machine Learning Systems]]、[[@2025__DSN__LLMPrism - Black-box Performance Diagnosis for Production LLM Training Platforms]] — GMM・k-σ 則という単純な統計則 - **Borgmon の宣言型ルール評価は、この制約を LLM 以前から解いていた先例である。** - 根拠: [[@2016__OReilly__SRE Book - Chapter 10 Practical Alerting from Time-Series Data]] — 多次元時系列モデル・代数的アグリゲーション・for 節によるフラッピング防止 - **LLMAD はサンプリング周波数を 1 分粒度以上に緩めることで、LLM 直接判定をコスト($65.70/年)とレイテンシ(17 秒/リクエスト)の両面で実用域に押し上げた。ただし GPT-4 級でないと性能が出ない(Llama-3-70B・GPT-3.5 では届かない)。** - 根拠: [[@2025__KDD__Large Language Models can Deliver Accurate and Interpretable Time Series Anomaly Detection]] — TFAD・Informer・Anomaly Transformer を上回る Best F1 - **解釈性は検知精度と背反でなく協働しうる。LLMAD の AnoCoT(判定ルール・異常タイプ定義・段階推論)は標準 CoT 比 Best F1 +6.2%、人手評価 usefulness +13.4% を同時に達成した。** - 根拠: [[@2025__KDD__Large Language Models can Deliver Accurate and Interpretable Time Series Anomaly Detection]] §5 — Microsoft DevOps エンジニア 5 名の評価 - **AlertGuardian は denoise 段を LLM なしの軽量グラフモデル(GraphGuardian)+ 属性値の匿名化で実装し、summary 段だけ LLM(RAG+DeepSeek V3)を使う段階別の使い分けを採る。** - 根拠: [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]] §II-C・§III — コスト・遅延(<200ms)・削減率(93.82〜95.50%)の同時達成 - **ソフトウェア性能異常検知でも、訓練済みの軽量ベースライン(VAE・LSTM-AD・Isolation Forest)がゼロショット時系列基盤モデル(Chronos・TSPulse)を上回るという産業選好が実験的に再確認された。ただし精度が並ぶ場面ではゼロショットが運用コストで有利になりうる。** - 根拠: [[@2026__ICPE Companion__Leveraging Time Series Foundation Models to Detect Performance Anomalies in Software Systems]] — AIOPS・MSCloud データセットでの比較 - **USAD の訓練コスト 1/547 削減(F1 は OmniAnomaly と同等)は、「検知精度を維持しつつ計算コストを削る」という産業選好パターンの学術側の先行例(2021 年)である。** - 根拠: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.3 Failure Detection]] §4.3.1 — 敵対的学習ベースのオートエンコーダ ## 正常性の文脈依存性 - **固定閾値は文脈で機能しない。Alibaba のビジネストレンド検知(N-シグマ則)とストレージデバイス向け PERSEUS(2023 年)は、同一企業内の別チームが独立に同じ教訓に到達した。** - 根拠: [[@2017__SREcon17 Asia__Smart Monitoring System for Anomaly Detection on Business Trends in Alibaba]] — 時間セグメント×トレンドごとに N を個別決定 - 根拠: [[@2023__loginonline__Detecting Fail-Slow Failures in Large-Scale Cloud Storage Systems]] — レイテンシ対スループット分布への多項式回帰による適応的しきい値 - **MAD のロバスト性は、過去インシデントが標準偏差を膨張させるという同一の問題に対し、LinkedIn と Booking.com が独立に収束的に選択した。** - 根拠: [[@2021__SREcon21__Spike Detection in Alert Correlation at LinkedIn]] — 修正 Z スコア(閾値 3.5)でアラート相関のスパイクを分離、偽陽性率 1% 未満 - 根拠: [[@2024__SREcon24 EMEA__Anomaly Detection in Time Series from Scratch Using Statistical Analysis]] — 過去インシデント混入時の標準偏差(78% 増)と MAD(31% 増)の膨張率の定量比較 - **RFT-FM の Normal-Profile Calibration は、訓練ダイナミクス(reward/KL/entropy 等)という新ドメインで「正常は絶対値でなく文脈相対のプロファイル」という原理を再確認した。Calibration を外すと recall が崩壊する(F1 87.96%→21.23%)。** - 根拠: [[@2026__arXiv__Towards Robust LLM Post-Training - Automatic Failure Management for Reinforcement Fine-Tuning]] - 関連: [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]] — マシン間類似度という同型の「正常は文脈相対」設計 - **ホスト間の正常性比較は、2005 年の実証(37 ホストの単一クラスタ)では統計的優位性を示せなかったが、2025 年の Minder のような均質・大規模な訓練クラスタでは機能する。均質性と規模のどちらが分岐点かは未検証の留保として残る。** - 根拠: [[@2005__Machine Learning__Principle Components and Importance Ranking of Distributed Anomalies]] — PCA・固有ベクトル中心性で優位性を見出せず - 反証: [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]] — マシン間類似度が実際に機能する事例 - **2002 年の統計力学的研究(Burgess+)は、長期の統計的正常性測定と短期の逸脱シグナル検知の二段構えを、20 年以上先立って定量的に立てていた。** - 根拠: [[@2002__TOCS__Measuring System Normality]] — 安定したフィットに最大 2 か月要する一方、15 分規模の疑似攻撃はエントロピー変化として検知不可能 - **低頻度な正常パターン(祝日等)は統計手法・NN の両方を破綻させる。Baidu は日次トラフィック CDF の k-means クラスタリングで類似日を発見し、リアルタイム比率補正で対処した。** - 根拠: [[@2017__SREcon17Americas__Anomaly Detection in Infrequently Occurred Patterns]] p.7–8 — 中央値補正・時間補正・Holt-Winters・BP NN の 4 手法がいずれも破綻 ## 実用的異常の再定義 - **MonitorAssistant は「実用的異常(practical anomaly)= 統計的逸脱かつインシデントで裏付けられた逸脱」と定義し、深層学習モデルが検知する統計的外れ値の一部が業務上無関係であることを事例で示した。** - 根拠: [[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]] §3.1・図 3 - **LogPilot は文脈なしのログ異常検知を「alert-agnostic」として診断に不十分と退け、産業側は検知出力をアラート/インシデントの文脈で絞り込む立場で一貫する。** - 根拠: [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]] §III-A — anomaly detection を log scoping から外し PromQL intent ベースの filtering に置換 - 関連: [[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]] — 「統計的外れ値の一部は業務上無関係」という同型の立場 - **ARFBench は異常検知の評価が抱える境界の曖昧さ・ラベルの主観性を、異常理解を多肢選択の単一クラス分類へ落とすことで回避する。VLM は異常の有無(Presence)は得意だが性質判定(Magnitude 等)で人間に劣る。** - 根拠: [[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]] - **AgentOps サーベイは、エージェント実行ドメイン固有の異常タクソノミー(Intra-Agent × Inter-Agent の 2 軸 8 種)を提示し、統計的逸脱が出ないまま意味的タスク失敗を起こす「推論異常」という従来の検知が原理的に扱えない異常種を定義する。** - 根拠: [[@2026__arXiv__Agent System Operations - Categorization, Challenges, and Future Directions]] - **EventADL は、メトリクス・ログとは異なる第 3 のシグナル源(クラウド監査イベント)を提示し、決定論的かつ解釈可能なルールベース検知(ESP/EFP)を 520 件の実インシデント分析で裏づけた。** - 根拠: [[@2026__ACM FSE__EventADL - Open-Box Anomaly Detection and Localization Framework for Events in Cloud-Based Service Systems]] §3・§4.2・§4.3 — Event Type(21%)・Value(68%)・Frequency(67%)の 3 次元 - 留保: 分析対象が単一プロバイダー(UKW)のクラウド監査イベントに限定される - **Matrix Profile の形状(shape)重視設計は離散イベント頻度時系列に不適合であり、大きさ(magnitude)重視の再設計により F1 が 0.155→0.741、実行速度が 9 倍向上した。** - 根拠: [[@2026__ACM FSE__EventADL - Open-Box Anomaly Detection and Localization Framework for Events in Cloud-Based Service Systems]] §5.8.2 - **正規化(z-score・Min-Max・Unit-length)は振幅駆動型異常(スパイク)の判別信号を圧縮しうる。40 データセット規模の統計的検証(Friedman+Nemenyi)で「非正規化」が一貫して VUS-PR 中央値最高という結果が得られた。** - 根拠: [[@2026__SIGMOD__HYDRA - A Multi-Level Hierarchy-Driven Approach for Robust Anomaly Detection in Time Series]] §5.4 ## LLMの検知器・メタ層としての役割分岐 - **産業側の複数事例(MonitorAssistant・AlertGuardian・LogPilot)は、LLM を検知器でなくメタ判断層(設定推奨・解釈・denoise 以外の要約等)に限定する設計に収束する。** - 根拠: [[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]]、[[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]]、[[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]] - **LLM4Log はログ異常検知の 6 ファミリを整理し、最強システムは異常を evidence-grounded な不整合として扱い LLM を主に説明/検証/軽量検知器のエンリッチに使うと総括する。LLM は何が異常かの曖昧さを除去せず、努力を feature 設計から normality curation・context 選択・運用ガードレールへ移す。** - 根拠: [[LLM4Log]] §6.2 — HDFS/BGL/Thunderbird/Spirit への依存が顕著という留保つき - **LLMAD は LLM を検知器そのものとして直接使う対照的な路線であり、Microsoft 内で LLM 異常検知の 2 路線(検知器 vs メタ層)が併走している。** - 根拠: [[@2025__KDD__Large Language Models can Deliver Accurate and Interpretable Time Series Anomaly Detection]] - 関連: [[@2023__ESEC-FSE__Detection Is Better Than Cure - A Cloud Incidents Perspective]] — 共著者(Chetan Bansal)が共有する問題意識 - **ChatTS は多変量メトリクスを 1 モダリティとして渡し自然言語クエリで根本原因まで掘る初の TS-MLLM で、text-only ablation は多変量を真に統合するにはネイティブモダリティが要ることを示す。** - 根拠: [[@2025__VLDB__ChatTS - Aligning Time Series with LLMs via Synthetic Data for Enhanced Understanding and Reasoning]] Fig. 14 - **RFT-FM はサービス運用のテレメトリでなく訓練ダイナミクス(reward/KL/entropy/return/response length)を異常検知の入力に拡張し、TranAD/OmniAnomaly/AT のような系列ベース手法を比較対象にすることで、運用と訓練が同じ多変量時系列異常検知の道具立てを共有することを示した。** - 根拠: [[@2026__arXiv__Towards Robust LLM Post-Training - Automatic Failure Management for Reinforcement Fine-Tuning]] - **APEX は複数の検知手法(単変量 4 手法・多変量 4 手法)のコンセンサス(3 手法以上一致)で擬似正解ラベルを得る設計を、時系列基盤モデル時代に再登場させた。Alibaba の単一手法へのオペレータフィードバック(2017 年)とは異なり、手法間の多数決で単一手法の癖に起因する偽陽性を減らすことを狙う。** - 根拠: [[@2026__arXiv__APEX - A Network-Native Time-Series Foundation Model for Forecasting and Anomaly Detection for Wireless Edge Operations]] ## 検知精度を決めるデータ設計とシグナル源 - **検知のシグナル源はシステム生成テレメトリ(メトリクス・ログ・トレース)から、user feedback(Detectr)や時系列基盤モデルの予測残差へ多様化している。** - 根拠: [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]] — support ticket・SNS を一次シグナルにする Detectr - 根拠: [[@2026__Google Cloud Blog__AI in SRE - Where Google is Deploying Agentic AI to Improve Operations]] — 時系列基盤モデル([[TimesFM]])による顧客指向 SLO 予測 - **ストレージ層のデータモデル制約が、検知可能な異常の空間を根本から制限する。汎用 TSDB が数値スカラー型しか扱えないため、ログ型データ(`lsof`・`strace`)の相関クエリが原理的にできなくなる。** - 根拠: [[@2017__FAST__Chronix - Long Term Storage and Retrieval Technology for Anomaly Detection in Operational Data]] §3・§5 — ファイルハンドルリークの根本原因特定に必須だった相関クエリ - **ミス検知の最大要因はアルゴリズムの精度不足でなく、必要なモニタの欠如(40.41%)とシグナルの欠如(18.13%)である。Microsoft 300 超サービスの分析でこれが定量的に裏づけられた。** - 根拠: [[@2023__ESEC-FSE__Detection Is Better Than Cure - A Cloud Incidents Perspective]] - 関連: [[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]] — 「実用的異常」定義の背景にある同じ知見 - **トレースを派生メトリクス時系列に落として古典外れ値検知を当てる経路は 2021 年時点で実用化されていたが、検知の天井はモデルでなく入力データの品質(トレース計装の完全性)にあった。** - 根拠: [[@2021__J Grid Computing__Automated Analysis of Distributed Tracing - Challenges and Research Directions]] — Huawei Cloud OpenStack 本番データへの Isolation Forest 適用と work-flow 計装欠落による限界 - **SLO 違反の二値分類は 2004 年から実証されており、「単一メトリクスルールは不十分」もその時点で定量化されていた。アプリサーバ CPU 利用率のみでは、ワークロードが変わると balanced accuracy が 56–63% まで急落する。** - 根拠: [[@2004__OSDI__Correlating Instrumentation Data to System States - A Building Block for Automated Diagnosis]] — TAN による balanced accuracy 87–94%、3–8 個のメトリクスの組み合わせが必要 - **2015 年の PADBI サーベイが整理したクラウド固有の 4 課題(スケール・マルチテナンシー・複雑アーキテクチャ・動的リソース管理)は、2025–2026 年の研究群でもそれぞれ一面しか解決されておらず、課題識別自体は今なお有効である。** - 根拠: [[@2015__CSUR__Performance Anomaly Detection and Bottleneck Identification]] - 関連: [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]]、[[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]] - **メトリクスの重要度は不均等であり、この不均等性は分析段の特徴量削減だけでなく収集段の周波数最適化としても活用できる相補的な設計パターンである。** - 根拠: [[@2024__IEEE Access__MetricSifter - Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications]] — 無関係メトリクスの削減による箇所特定の改善 - 根拠: [[@2024__IEEE CLOUD__Enabling Programmable Metric Flows]] — 重要メトリクスへの高周波数割り当てで WRE を約 600 倍削減 - 関連: [[@2024__ESEM__Reducing Events to Augment Log-based Anomaly Detection Models - An Empirical Study]] — ログイベント側でも同型の「入力の大半が検知に無関係」という構造 - **エッジデバイスへの検知モデル圧縮は、多変量時系列異常検知(MTSAD)の新しい実用課題である。単純な教師出力模倣による知識蒸留では時系列の時間依存構造を十分転写できず、再構成損失と蒸留損失のバランス(ベル型の性能曲線)が必要になる。** - 根拠: [[@2025__TSC__Bridging Edge and Cloud - A Knowledge-Enhanced Framework for Efficient Time Series Anomaly Detection]] §IV-C・§V-C ## 未解決の問い - **統計ベース技法の欠点(3)「ヒストグラムベースは属性間の相互作用を捉えられない」を、多変量ログ異常検知([[@2024__KDD__Multivariate Log-based Anomaly Detection for Distributed Database]])のノード間相関捕捉や GMM 系(k-σ 則)はどこまで克服しているか**: 直接比較した研究は Chandola 2009 および後続の多変量手法のいずれにも見当たらない。属性ごとの独立なヒストグラムという単純化を捨てて多変量の相関を明示的にモデル化する現代手法が、統計ベースの仮定破れをどの程度緩和しているかは未検証。(Source: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 7 Statistical Anomaly Detection Techniques]] §7末尾) - Chandola 2009 の還元/構造利用という2分類は、現代の産業異常検知(LLMAD の直接判定、TFC の曲率視点、HYDRA の階層的代表選抜等)をどこまで分類できるか。LLM を検知器として直接使う路線(LLMAD)は、文脈からの期待挙動予測という点で構造利用に近いが、プロンプトによる文脈指定は還元の「文脈特定」段階にも対応しうる——2分類が LLM 時代の技法にそのまま適用できるかは未検証。(Source: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 10 Handling Contextual Anomalies]], [[@2025__KDD__Large Language Models can Deliver Accurate and Interpretable Time Series Anomaly Detection]]) - **TFC・EventADL・TSLoc・Minder 等の検知手法のうち、コスト考慮学習による公平性対応、post-hoc 説明可能性(SHAP/LIME 相当)、モデル枝刈りによる効率性のいずれかを明示的に満たすものはどれだけあるか**: [[Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications]] が示す4要件(公平性・ロバスト性・説明可能性・効率性)をこれらの手法群に個別に当てはめた棚卸しは未着手。特に不均衡データへのコスト考慮学習は、「異常は少数派」という前提と直結するが、検知精度の議論に埋もれて明示的に評価されていないことが多い。(Source: [[Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications]]) - **EventADL の ESP・EFP は決定論的かつ解釈可能だが、520件のインシデント分析対象がクラウド監査イベント(単一プロバイダー UKW)に限定される。異なるクラウドプロバイダー・異なるイベントスキーマ(OCSF 以外)でも、Event Type/Value/Frequency の3分布(21%/68%/67%)は同様の比率で再現されるか、それともイベントスキーマの設計(粒度・命名規則)に強く依存するか**: サーベイが整理する検知手法の多くがベンチマークデータセットの偏り(HDFS/BGL 偏重等)を課題として抱えるのと同型の問題が、イベントベース ADL にもそのまま持ち込まれている可能性がある。(Source: [[@2026__ACM FSE__EventADL - Open-Box Anomaly Detection and Localization Framework for Events in Cloud-Based Service Systems]]) - Burgess+ 2002 が示した「Planck 分布の温度が複数サイト間で不変」という観察は 3 台の WWW サーバーという小サンプルに基づく限定的なものだった。現代の大規模テレメトリ(数千ホスト・数百サービス)で同種の尺度変換(周期性除去 + 局所標準偏差スケーリング)を適用した場合、分布形の不変性は成立するか。もし成立するなら、[[時系列基盤モデル]]のゼロショット予測が捉える「正常プロファイル」と、この統計力学的な最大エントロピー分布はどう関係するか。([[@2002__TOCS__Measuring System Normality]]) - RefinedEdge のエッジクラウド協調型モデル圧縮は、EdgeNode(ドリフト乏しい)では更新戦略の有無で性能差が出ないが、概念ドリフトのある SMD/SMAP では相互更新が有意な改善(F1 +0.06〜+0.19)をもたらすと報告する。この「ドリフトが無ければ継続更新は不要」という知見は、ログ・トレースベースの異常検知(Borgmon 型の宣言的ルールや LLM 判定器)にも一般化できるか、時系列 MTSAD 固有の現象か。(Source: [[@2025__TSC__Bridging Edge and Cloud - A Knowledge-Enhanced Framework for Efficient Time Series Anomaly Detection]]) - Chandola 2009 の点異常・文脈異常・集合異常という分類は、現代のログ・メトリクス・トレース・LLM 判定器・エージェント実行ログを同じ粒度で比較する軸としてまだ十分か。pattern anomaly は集合異常の一般化として位置づけられることが分かったが([[@2015__CSUR__Performance Anomaly Detection and Bottleneck Identification]])、MonitorAssistant の practical anomaly はこの3分類のどこに位置づけるべきかは未解決である。(Source: [[Anomaly Detection - A Survey]], [[@2015__CSUR__Performance Anomaly Detection and Bottleneck Identification]], [[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]]) - マイクロサービス異常検知サーベイ([[Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications]])の「教師なし学習」が実質的に Chandola 2009 の半教師あり(正常データのみで訓練)を指す用語の食い違いは、他の異常検知サーベイ・システムの「教師なし」表記にも同様に潜んでいるか。技法横断比較のベンチマーク設計では、この用語の食い違いをどう解消すべきか。(Source: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 2 Different Aspects of an Anomaly Detection Problem]], [[Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications]]) - Chandola 2009 の文脈異常(contextual anomaly)と、運用現場でいう実用的異常(practical anomaly)は同じ「文脈依存性」を指しているのか。前者はデータ属性上の文脈、後者はインシデント裏付け・SLO・業務影響上の文脈であり、両者を分けた評価指標が必要ではないか。(Source: [[Anomaly Detection - A Survey]], [[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]]) - サーベイが指摘する「連続稼働の異常検知に LLM は重すぎる(1 秒以内の推論が要る)」課題は、小規模モデル + LLM + OCE のハイブリッドで解けるか。検知は軽量モデル/計測で常時行い、異常時だけ LLM を呼ぶ二段構えはどこまで汎用化できるか([[AIOps]] の課題4「ツールチェーン統合」と接続)。(Source: [[A Survey of AIOps in the Era of Large Language Models]]) - 異常検知([[異常検知]])と[[変化点検知]]はどう棲み分けるか。変化点検知は正常区間の事前指定が不要な点で異常検知と区別されるが、[[MetricSifter]] のように変化点検知を障害窓の局所化に使う設計は「検知」か「前処理」か。検知タスクの境界が手法によって曖昧になる。 - ログベース異常検知の多くは T5/GPT-2 等の小型前処理モデル依存で、単純なデータセットでは従来 ML と差が出にくい(サーベイ §7.2)。ログを LLM で活かす有効な道(prompt embedding 等)は本当に従来手法を超えるのか。評価データの単純さがゲインを過大評価していないか。(Source: [[A Survey of AIOps in the Era of Large Language Models]]) - トレースデータを使った異常検知は LLM 研究で皆無(サーベイ §7.2)。トレースの複雑性・volume をどう LLM が扱える表現にするか。[[分散トレーシング]] の path-oriented データを検知に活かす道は。 - [[MonitorAssistant]] の統一類似度(時系列シェープレット + LLM 記述類似度)は LLM をメタ層として使う実装例だが、数百万メトリクスへのスケーラビリティと LLM 呼び出しコスト(Top N 事前スクリーニングが必須)のトレードオフは定量的に未評価。この設計パターンは他の AIOps タスク(箇所特定・RCA)のメタ推奨にも適用可能か。([[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]]) - [[TelecomTS]] が示すオブザーバビリティデータの偽陽性問題は、マルチモーダルモデル(Toto+Qwen-3-4B、F1 0.487)では Toto 単体(F1 0.615)より悪化する。時系列＋言語の早期融合は検知タスクでは逆効果になりうるのか、それとも学習方法(LoRA 等)の限界か。([[@2026__ICML__TelecomTS - A Multi-Modal Observability Dataset for Time Series and Language Analysis]]) - ログ異常検知(LogRobust/LogAnomaly)を「alert-agnostic だから log scoping に使えない」とする [[LogPilot]] の立場と、異常検知を障害認知(Level 1)の主軸とするサーベイの整理は両立するか。検知(アラート発火前の precursor 検出)と scoping(アラート発火後の関連ログ絞り込み)で異常検知の役割が分かれ、後者ではアラート intent ベースの filtering が異常検知を代替するのか、それとも両者を組んだ二段検知が要るのか。([[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]]) - [[ARFBench]] の多肢選択化は異常境界の曖昧さを回避するが、時間範囲を精密に出力する従来の異常検知タスク(VUS 等で評価)とは下流価値が異なる。インシデント対応では「正確な時間範囲」より「異常の有無・種別・系列間の関連」が重要という ARFBench の前提は、緩和の自動化(リソース増強・ロールバック)が時間範囲の精度を要求する場面でも成立するか。([[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]]) - [[RFT-FM]] の検知は CA(Credit Assignment)系障害で全手法が最難(easy でも F1 53.17%)。単一信号でなく多信号の構造化シグネチャでしか区別できない「微妙な異常」を、運用テレメトリの偽陽性問題([[TelecomTS]])や常時稼働の計算制約と両立する形で、訓練を止めずに実時間検知できるか。運用ドメインと訓練ドメインで「微妙な異常」の難しさは同根か。([[@2026__arXiv__Towards Robust LLM Post-Training - Automatic Failure Management for Reinforcement Fine-Tuning]]) - [[AlertGuardian]] の属性値匿名化による denoise は、どの程度の属性基数・ドメインまで一般に効くか。匿名化は属性組合せ爆発を回避する一方で属性値の固有情報を捨てるため、稀少だが重要なアラート(低頻度だが高重要度の障害シグナル)を「ノイズ」として取りこぼすリスクはないか。AlertGuardian の停止条件に「重要アラート保持」が明示的に組み込まれている事実は、この取りこぼしが現実の懸念であることを示唆するが、匿名化のどの設定でどれだけの重要アラートが失われるかの感度分析は未着手。([[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]]) - 白箱/灰箱/黒箱の 3 方向の推論異常検知手法が AgentOps の中で最も多く整理されているが(SPALMA / OPERA / Honesty / LURE / Conformal / Debate / CoK)、これらは相互に独立で統一評価が未整備。セキュリティ異常検知(GUARDIAN / SentinelAgent)はグラフ依存であり、通信異常や終了異常の検知手法は著しく少ない。これはサーベイが示す「既存研究は Intra-Agent 異常に偏る」という評価とも一致する。([[@2026__arXiv__Agent System Operations - Categorization, Challenges, and Future Directions]] Table IV/VIII) - [[LogCleaner]] のイベント 3 類型（anti/duplicative/key）はラベル付きデータに依存して判定される。教師なし設定やラベルが乏しい実運用環境でこの分類を維持できるか。また、コード変更によるログイベントの追加・消滅に対し再プロファイリングで追従する設計の実際の遅延・コストはどの程度か。HDFS/BGL/Thunderbird 以外の動的な運用データセットでの検証が未着手。([[@2024__ESEM__Reducing Events to Augment Log-based Anomaly Detection Models - An Empirical Study]]) - [[TFC]] の曲率視点(離散二階差分)は単変量時系列を前提に設計・評価されている(§Appendix C、系列ごとに個別モデルを訓練)。メトリクス・ログ・トレースを横断する多変量 AIOps 運用データ([[MultiLog]]・[[ChatTS]] が扱う領域)へ曲率の視点を拡張した場合、変数間の力学的相関(ヤコビ行列的な二階の交差項)をどう扱うべきか。単純な各変数独立の二階差分では、変数間の位相ずれで生じる異常(例: あるメトリクスの曲がりが別メトリクスに遅延して伝播するケース)を捉え損ねる可能性がある。([[@2026__KDD__Rethinking Time Series Anomaly Detection from a Dynamic Perspective - Temporal–Frequency–Curvature Fusion]]) - [[TFC]] は曲率という高感度シグナルを周波数較正とエキスパートルーティングという二段階の学習可能な機構で緩和するが、この較正は訓練データの分布(6ベンチマークの正常/異常比)に依存する。LinkedIn の修正 Z スコアや Alibaba の STL のように**閾値・パラメータを明示的な統計量として持つ軽量手法**と比べ、TFC の較正機構は本番運用でのドリフト(RefinedEdge が指摘する概念ドリフト)にどう追従するか、再訓練なしで長期運用できるかは論文内で直接検証されていない。([[@2026__KDD__Rethinking Time Series Anomaly Detection from a Dynamic Perspective - Temporal–Frequency–Curvature Fusion]], [[@2025__TSC__Bridging Edge and Cloud - A Knowledge-Enhanced Framework for Efficient Time Series Anomaly Detection]]) - GMM の時間窓内定常性や k-σ 則は、非定常ワークロード・概念ドリフト・漸進劣化下でどの種の異常を取りこぼすか。([[@2025__IWQoS__eACGM - Non-instrumented Performance Tracing and Anomaly Detection towards Machine Learning Systems]], [[@2025__DSN__LLMPrism - Black-box Performance Diagnosis for Production LLM Training Platforms]]) - サーベイが整理する 6 ファミリのうち、agentic 異常検知(Audit-LLM/LogRESP-Agent)は解釈性を上げ analyst 負荷を下げる一方レイテンシ/コスト増を伴う。常時稼働の検知に LLM が重すぎる制約([[A Survey of AIOps in the Era of Large Language Models]] §7.1)と agentic 検知の重さは、どの障害クラスで割に合うか。HDFS/BGL 偏重のコーパスは agentic の優位を正しく測れているか。([[LLM4Log]]) - AgentOps が提案するモデルデータ(アテンションマップ・トークンロジット)をモニタリングシグナルとして使う方向は、「推論異常は統計的テレメトリに現れない」という問題への解答として有望だが、クローズドソース LLM(GPT-4o 等)ではモデル内部状態にアクセスできない。オープンソース LLM のローカル展開を前提とする白箱異常検知は、クローズドモデル依存のシステムでは構造的に適用不能——どの入力シグナルがモデルを問わず機能するブラックボックス推論異常検知の基盤になりうるか。([[@2026__arXiv__Agent System Operations - Categorization, Challenges, and Future Directions]] §IV Future Directions) - LinkedIn の修正 Z スコアによるスパイク分離は 5 日間・193 件の評価で偽陽性率 1% 未満を報告するが、長期運用での季節変動・デプロイ起因の偽陰性率、30 分ウィンドウのサンプリング間隔の影響は未検証。「5 連続スパイク + 70% 同傾向 = REAL ALERT」というルールの閾値感度分析が公開されていない。他のアラート相関システムへの移植可能性——特にサービス規模や依存グラフ密度が異なる環境での有効性——も開いた問いである。([[@2021__SREcon21__Spike Detection in Alert Correlation at LinkedIn]]) - Alibaba の STL ベース異常検知でオペレータラベルを N 調整に使うフィードバックループは「人間の判断基準に自動収束する」とされるが、ビジネストレンドが大きく変化した際(新サービス開始・施策変更・急成長)にどう再収束するかの詳細が不明。ラベルの誤りへの許容(tolerant)の具体的な実装も未開示。またこの 2017 年の設計は「祝日効果」を課題と認識しつつ解決策を示しておらず、Baidu が k-means クラスタリングによる類似日発見で解こうとした同じ問題への Alibaba の答えが残されている。([[@2017__SREcon17 Asia__Smart Monitoring System for Anomaly Detection on Business Trends in Alibaba]]) - マイクロサービス異常検知サーベイは「統計手法の accuracy 99.2%」「トレース比較の recall 99.0% / F1 98.2%」のように手法群の平均性能を提示するが、対象データセット・故障種別・指標が揃っていない。異常検知の横断比較は、同一障害注入・同一テレメトリ・同一評価窓を持つベンチなしにどこまで意味を持つか。([[Anomaly detection and root-cause identification in microservices]]) - [[@2015__CSUR__Performance Anomaly Detection and Bottleneck Identification]] が整理した 4 検知戦略のうち「知識駆動(ベイジアンネット・因果グラフ)」路線は 2015 年時点で PAD 研究の少数派だった。この路線が現代では LLM プロンプティング・RAG を経由して LLM 時代の「学習回避(直接予測)」路線として復権しているとすれば、知識表現の形式(明示的グラフ 対 LLM の潜在知識)の違いが検知精度や説明可能性にどう影響するか。([[@2015__CSUR__Performance Anomaly Detection and Bottleneck Identification]], [[A Survey of AIOps in the Era of Large Language Models]]) - Soldani & Brogi 2021（§3.4.3）が指摘する「継続的変化するマイクロサービスでの訓練問題」に対し、定期再訓練や大量データ収集以外のアプローチ——たとえばコンセプトドリフト検知を組み込んだオンライン学習、LLM の in-context learning による zero-shot 異常定義、あるいは運用者フィードバックループ——はどこまで訓練問題を解消できるか。サーベイは 2021 年時点で continual learning を研究方向として挙げるが、5 年後の実装例は。([[Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications]]) - [[LLMAD]] の「LLM を直接判定器として使う」路線は、検知精度・解釈・コストで実用域に届いたが、(i) 窓長 400 を超える長期持続異常への対応、(ii) GPT-4 級でないと性能が出ない問題、(iii) 単変量のみ対応、を抱える。これらは [[Minder]]/[[Pulse]] のような軽量・常時稼働路線との二段構え(常時は軽量モデル、異常時のみ LLMAD で深掘り)で解消できるか。([[@2025__KDD__Large Language Models can Deliver Accurate and Interpretable Time Series Anomaly Detection]]) - [[ChatTS]] の多変量 TS-MLLM 路線は、Oracle DB の根本原因推論を rulebook ベースで実現するが、実運用では rulebook の整備自体が運用者の負担になる。[[LLMAD]] が要求する「データセット背景知識の一度きりの記述」と、ChatTS が要求する「rulebook 整備 + textual queries」のどちらが運用上負担少ないか。両者を統合し、AnoCoT 型のプロンプトで rulebook を内包する設計は可能か。([[@2025__VLDB__ChatTS - Aligning Time Series with LLMs via Synthetic Data for Enhanced Understanding and Reasoning]], [[@2025__KDD__Large Language Models can Deliver Accurate and Interpretable Time Series Anomaly Detection]]) - LLMAD の人手評価が依拠する「DevOps エンジニア 5 名の usefulness/readability 評価」は、解釈付き検知器の評価のデファクトとなりうるか。[[MonitorAssistant]] が「実用的異常 = 統計的逸脱 + インシデント裏付け」と定義した評価軸と、LLMAD の「説明の usefulness/readability + Acc(any-hit)」は同型に統合できるか、それとも別軸として併用すべきか。([[@2025__KDD__Large Language Models can Deliver Accurate and Interpretable Time Series Anomaly Detection]] §5) - Begnum & Burgess (2005) の負の結果(ホスト間比較の統計的優位性なし)は 37 ホストの単一クラスタでの手作業解釈に基づく。Minder(2025)のようにマシン間類似度が実際に機能する大規模訓練クラスタとの違いは、クラスタの均質性(同一ジョブ・同一ハードウェア)なのか、規模(数千 GPU vs 37 ホスト)なのか、それとも 20 年間の統計手法・特徴量設計の進歩なのか。同一データに現代的手法(ランク相関の実装可能な近似、ロバスト統計)を再適用したら結論は変わるか。([[@2005__Machine Learning__Principle Components and Importance Ranking of Distributed Anomalies]], [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]]) - TRANSOM の TEE(2023 年、LOF+KNN Matrix Profile+DTW の多数決)から Minder(2025 年)への 2 年間で、LLM 訓練クラスタの異常検知手法はどう進化したか。両者はともに非 LLM の軽量統計/ML 手法を選ぶが、TEE の「2/3 多数決」と Minder の「マシン間類似度」は異なる設計思想であり、評価データセットの規模(TEE は正常13件・異常11件と小規模)の違いが手法選択にどう影響したかは未検証。([[@2023__arXiv__TRANSOM - An Efficient Fault-Tolerant System for Training LLMs]], [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]]) - [[@2026__ICPE Companion__Leveraging Time Series Foundation Models to Detect Performance Anomalies in Software Systems]] はゼロショット基盤モデルが訓練シーケンスを一切利用しない設計で評価されている。訓練シーケンスを履歴コンテキストとして活用したりファインチューニングに用いたりした場合、[[Minder]]・TRANSOM の TEE のような軽量統計/ML 手法との性能差はどこまで縮まるか、あるいは逆転するか。また評価は単変量ソフトウェア運用メトリクスに限定されており、多変量(複数メトリクスの相関を伴う)障害検知でも同様にゼロショット基盤モデルが軽量ベースラインに劣後するかは未検証。([[@2026__ICPE Companion__Leveraging Time Series Foundation Models to Detect Performance Anomalies in Software Systems]], [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]]) - HYDRAは代表選抜の階層的純化により、discordの twin-freak問題とクラスタリングの汚染問題を「参照集合をどう純化するか」という統一設計で同時に解消したが、運用テレメトリの異常検知(ログ・イベント・メトリクスの混在、低ラベル品質、常時稼働のコスト制約)にこの設計をそのまま持ち込めるか。HYDRAは静的なオフライン部分列集合を前提とするが、ストリーミング設定(逐次到着するウィンドウに対しリアルタイムで階層を更新)への拡張は論文内で示されておらず、TRANSOM・Minder・LinkedInの修正Zスコアのような常時稼働アルゴリズムとの統合可能性は未検証。([[@2026__SIGMOD__HYDRA - A Multi-Level Hierarchy-Driven Approach for Robust Anomaly Detection in Time Series]] §6 Conclusion) - HYDRAは低振幅・高周波ジッタ型の異常と、正常挙動自体が高い異質性を持つデータで失敗すると明記している(§5.7)。これは「平滑化バイアスが弱い幾何逸脱を減衰させる」という[[TFC]]の指摘や、運用テレメトリの偽陽性問題([[TelecomTS]])と同根の失敗モードか、それとも時間領域・距離ベース手法に固有の別の限界か。周波数領域の乖離尺度(TFCの曲率視点)をHYDRAの階層的集約機構に組み込む具体的な統合設計は、両論文とも将来課題として言及するのみで未着手。([[@2026__SIGMOD__HYDRA - A Multi-Level Hierarchy-Driven Approach for Robust Anomaly Detection in Time Series]] §5.7, [[@2026__KDD__Rethinking Time Series Anomaly Detection from a Dynamic Perspective - Temporal–Frequency–Curvature Fusion]]) - Chandola 2009 は結論として、異なる手法が正常・異常挙動について置く仮定を統一的な統計的・機械学習的枠組みへ統合することを今後の研究課題に挙げ、Knorr and Ng [1997] の距離ベース異常と統計的異常の関係づけを限定的な試みとして紹介するにとどめる(§12)。異常検知が集積してきた統計的手法・機械学習的手法(GMM の k-σ 則、LSTM-VAE、TFC の曲率視点等)を横断して、こうした仮定の統一的な枠組みは 2009 年以降どこまで実現したか、それとも各手法が個別の仮定に依拠したまま並立する状況は変わっていないか。(Source: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 12 Concluding Remarks and Future Work]]) - Chandola 2009 は今後の有望な方向として、分散環境向けの分散異常検知技術とそれに付随するプライバシー保護異常検知技術、センサーネットワークを想定したオンライン(逐次到着データに対する)異常検知技術、複数コンポーネントが相互作用する複雑システム(航空機システム等)への適用を挙げる(§12)。大規模分散訓練クラスタの異常検知([[Minder]] 等)やエッジ-クラウド協調([[RefinedEdge]])は、このうちどの方向にどこまで応えているか。特にプライバシー保護異常検知([Vaidya and Clifton 2004])に相当する設計はこれらの手法群にほとんど見当たらず、空白領域として残る。(Source: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 12 Concluding Remarks and Future Work]]) - Chandola 2009 はノベルティ検知を「検出後に正常モデルへ組み込まれる新規パターン」、異常検知を「検出後も継続して異常のまま扱われる逸脱」として概念上区別する(§1.1)。時系列基盤モデルのゼロショット予測が示す「訓練時に見ていない未知パターンへの適応」は、この境界のどちら側に位置づくのか——モデルが未知パターンを内部的に「新しい正常」として吸収するなら novelty detection 的であり、常に逸脱として検知し続けるなら anomaly detection 的である。基盤モデル系の手法群([[時系列基盤モデル]]、TFC 等)がこの境界のどちらの挙動を示すかは、個別に検証されていない。(Source: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 1 Introduction]] §1.1) - Chandola 2009 §3 の「応用ドメイン別4側面(異常の型・データ性質・課題・技法)」という整理軸は、クラウド運用・AIOps ドメインに直接持ち込めるか。運用ドメインは §3 が扱う7分野のどれに最も近いか——大量データとオンライン性の制約は侵入検知に近く、異常を見逃すコストの非対称性は医療ドメインに近いが、いずれも運用ドメイン固有の「動的に変化するシステム構成」(マイクロサービスの継続的デプロイ等)には対応しない。運用ドメインを既存7分野の変種として位置づけるべきか、独自の第8分野として整理し直すべきか。(Source: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 3 Applications of Anomaly Detection]] §3) - Chandola 2009 §3.2.1 の by-owner/by-operation という2種類の文脈設計(クレジットカード不正検知)は、現代の「文脈設計」の事例(マシン間類似度・ビジネストレンドの時間セグメント・訓練ダイナミクスの正常プロファイル)と比べて明示的な分類軸を持たない。「文脈をどう設計するか」自体を横断的に分類する軸(文脈の粒度・更新頻度・参照集合の選び方)は、Chandola 2009 のどの後続章にも見当たらない——第4〜9章の技法比較でこの軸が扱われるかは今後の担当章の検証課題である。(Source: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 3 Applications of Anomaly Detection]] §3.2.1) - 情報理論ベースの仮定破れ(大量の異常が無いと検知できない)とスペクトルベースの仮定破れ(低次元埋め込みで分離可能でないと機能しない)は、どちらも「集合・部分空間全体レベルでの偏りの不足」に帰着すると整理できるが、この「集合レベルの脆さ」を実際に定量化した実験(異常の混入率を段階的に変えて情報理論的/スペクトル的技法の検知性能がどう劣化するかを測る研究)は Chandola 2009 および後続研究のいずれにも見当たらない。現代手法(GMM の k-σ 則、HYDRA 等)のうち、この混入率依存の脆さを明示的に評価しているものはどれだけあるか。(Source: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 8 Information Theoretic Anomaly Detection Techniques]], [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 9 Spectral Anomaly Detection Techniques]]) - Notaro 2021 の Table 6 が長所として一貫して「教師なし・ラベル不要」を挙げる一方、Opprentice・TAN(Cohen et al.)・Lo et al. の SVM のように高精度・高解釈性を狙う手法は教師ありに依拠する。この「教師なし優先の建前」と「高精度化には教師ありが要る現実」の緊張は、Chandola 2009 が整理した「分類ベースの仮定=ラベル可用性」というより一般的な緊張の AIOps 障害検知版だが、2021年から現在までにこの緊張がどう解消(あるいは維持)されているかは未整理である。(Source: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.3 Failure Detection]], [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 4 Classification Based Anomaly Detection Techniques]]) - Notaro 2021 は ITC(Internet Traffic Classification)を「ネットワーク異常検知の一種と見なせるが方法論とデータソースの違いから独立に議論する」と位置づける。マイクロサービス異常検知サーベイ(Soldani & Brogi 2021、Barata 2026)のデータソース分類(ログ・トレース・メトリクス)には、ネットワークトラフィック自体を独立データソースとして扱う軸が見当たらない——ITC で使われる特徴量(ペイロードサイズ・TCPポート・フロー統計)は、クラウドネイティブ異常検知のデータソース分類にどう接続するか、あるいは別ドメインとして扱い続けるべきかは未検証。(Source: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.3 Failure Detection]], [[Anomaly detection and root-cause identification in microservices]]) - **Barata 2026 の検知アルゴリズム5分類における強化学習カテゴリの言及手法が1件のみである事実は、実際に研究蓄積が薄いことを反映するのか、それとも探索キーワード(Table 4)がRL関連文献を十分に捕捉できていないためか**: §4.3.3の記述からはこの切り分けができない。RLベースの異常検知(Belhadi et al.のマルチエージェント枠組み以外)がマイクロサービス文脈でどの程度存在するかは、本サーベイの探索範囲(2012年以降・6データベース)を超えた文献調査を要する。(Source: [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey - Chapter 4.3 Methods to identify anomalies in microservices]]) - Soldani & Brogi 2021(§3.4.4)がSeerを例に提示した「検知結果をサーキットブレーカ/バルクヘッドの先回り型作動につなげる」という対処策(countermeasure)の方向は、当時「最初の試み」に過ぎないと位置づけられていた。2024–2026年の産業システム(AlertGuardian・MonitorAssistant・LogPilot等)は検知/denoise/診断の高度化に注力する一方、検知結果から自動的に緩和アクション(サーキットブレーカ作動・リソース増強)へつなげる設計はほとんど見当たらない——2021年にSeerが示した「検知から対処策への自動連携」という研究方向は、5年後の産業実装でどこまで具体化されたか、あるいは依然として未解決のままか。(Source: [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey - Chapter 3.4 Discussion (Anomaly Detection)]]) - **ログパーサが決まった構造を前提にしている限り、システム更新によるメッセージ構造の変化は異常検知系全体の障害を引き起こしうる**という課題は、Barata+ 2026 が具体的な緩和策を示さないまま指摘するにとどまる。ログベース異常検知手法(LogCleaner のイベント3類型、LogPilot の intent-aware フィルタリング等)のうち、パーサ設定自体の構造変化を検知・追従する仕組み(スキーマドリフト検知)を明示的に備えるものはどれだけあるか。ログイベントの追加・消滅への再プロファイリング遅延という [[LogCleaner]] の問いと同根だが、Barata+ 2026 が指摘するのは「パーサ設定という前提そのものの脆さ」であり、イベント分類の再学習コストとは別の層の課題である。(Source: [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey - Chapter 6 Challenges, open issues, and directions to future investigations]]) - **TEE(Trusted Execution Environment)によって異常検知モデル自体の実行を改竄不可能にするという方向(Barata+ 2026 §6.1)は、検知手法群の統計的頑健性(ノイズ・不完全テレメトリへの耐性)とは異なる脅威面——実行環境自体の完全性——を扱う**。敵対的・マルチテナントなクラウド環境でモニタリングエージェント・検知モデルの改竄を防ぐという Barata+ 2026 の提案は、頑健性(概念ドリフト・ノイズ劣化への統計的耐性)や公平性(コスト考慮学習)とは独立した軸であり、TFC・EventADL・Minder 等の検知手法群のいずれも実行環境の完全性を明示的な設計目標としていない。TEE 下での推論はレイテンシオーバーヘッドを伴うと想定されるが、常時稼働の検知に LLM が重すぎるという課題([[A Survey of AIOps in the Era of Large Language Models]] §7.1)と同種のコスト制約が TEE 導入にも生じるかは未検証。(Source: [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey - Chapter 6 Challenges, open issues, and directions to future investigations]] §6.1) - Alibaba のオペレータフィードバックループ(2017年)は N-シグマ則のしきい値調整という単純な統計的検知器を対象にしていた。サーベイが定式化する HITL(専門家フィードバックによる教師なし検知器の精度改善)は、TFC・HYDRA・時系列基盤モデルのような複雑な深層学習/基盤モデル系の検知器にも同様に有効か、それともモデルの複雑さがフィードバックの解釈・反映を難しくするか。LLMAD のような LLM 判定器の human evaluation(usefulness/readability)は説明の質を評価するものであり、Alibaba 型の「フィードバックをモデル/しきい値へ反映するループ」とは異なる——両者を統合した HITL 設計は見当たらない。(Source: [[@2025__ACMCSUR__Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications - A Review - Chapter 2 Trustworthiness Requirements and Performance Diagnosis Systems]] §2.3, [[@2017__SREcon17 Asia__Smart Monitoring System for Anomaly Detection on Business Trends in Alibaba]], [[@2025__KDD__Large Language Models can Deliver Accurate and Interpretable Time Series Anomaly Detection]]) - HPC クラスタ全体への異常検知モデル展開で、連合に参加できない多数ノードへの知識転移は、中央再訓練やノード個別のゼロからの訓練と比べていつ優位か。FTL 実証は単一 Tier-0 に閉じ、他クラスタや異世代混在での一般化は未検証である。 - IQR 由来の統計ベースラインと利用者定義ベースラインのどちらが、ラベル無し HPC 異常の再現率・偽陽性を実務で支配するか。 - OSレベルの非参加型な構成監査(LiveOps系)と、現代のログ/メトリクス/トレースベースの異常検知は、検知できる障害クラスがどの程度排他的か。組み合わせた場合の相補性は測定されているか。 - Holt-Winters予測に基づく信頼帯異常検知(RRDtool/Cricket 実装)は、後年のLLM/時系列基盤モデル時代の検知手法とどのように定量比較されるか(本論文は定量評価を行っていない)。 - 1997年のベイジアンネットワーク型検知が到達した検知率(1時間学習ウィンドウで10件中7件)は、現代の時系列基盤モデルベース手法と比べどの程度の改善が見られるか(直接比較可能なベンチマークが存在しない)。 ## 未編纂の観察 > [!note]- 編纂前の観察 2026-09 > - **PAD サーベイの pattern anomaly は、Chandola 2009 の文脈異常ではなく集合異常の一般化として位置づけられる**: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 2 Different Aspects of an Anomaly Detection Problem]] は集合異常(collective anomaly)を「関連するデータインスタンスの集合が全体に対して異常であり、個々のインスタンスは単独では異常でなくてよい」と定義し、成立条件としてインスタンス間の関係(系列・グラフ・空間データ)を必須とする(§2.2.3)。[[@2015__CSUR__Performance Anomaly Detection and Bottleneck Identification]] が追加した pattern anomaly(性能メトリクス曲線の形状が典型パターンから逸脱する異常。例: レイテンシの漸近増大パターンの消失)は「Collective anomaly の一般化」と明記されている。両サーベイを重ねると、Chandola 2009 の「点異常・文脈異常・集合異常」という3分類の枠組み自体は保たれたまま、集合異常の内部に「個々の値は正常でも集合として異常」という基本形と「曲線形状そのものが逸脱」という発展形の2階層があると整理できる。(Source: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 2 Different Aspects of an Anomaly Detection Problem]], [[@2015__CSUR__Performance Anomaly Detection and Bottleneck Identification]]) > - **マイクロサービス異常検知サーベイの「教師なし/教師あり」2モードは、Chandola 2009 の半教師あり(semisupervised)モードを教師なし側へ暗黙に統合したものである**: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 2 Different Aspects of an Anomaly Detection Problem]] はラベル可用性を教師あり(正常・異常両クラスにラベルあり)・半教師あり(正常クラスのみラベルあり。異常挙動からの乖離でモデル化する中間形態)・教師なし(訓練データなし。テストデータ中の正常が異常より多いという仮定のみに依拠)の3モードに分ける(§2.3)。一方 [[Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications]] は25手法を「教師なし学習(故障フリーの実行データのみで訓練・セットアップコスト低)」「教師あり学習(故障注入込みの訓練を要し、故障種別まで返せる・セットアップコスト高)」の2モードにのみ分類する。マイクロサービスサーベイの「教師なし学習」は、正常データのみを使って訓練する点で Chandola の半教師あり(正常クラスのみラベル)に相当し、Chandola が教師なしに割り当てる「訓練データを一切用いない」モードとは異なる。同じ「教師なし」という語がサーベイ間で指す訓練データの中身が食い違っている点は、技法比較時に見落としやすい。(Source: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 2 Different Aspects of an Anomaly Detection Problem]], [[Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications]]) > - **Chandola 2009 の「異常の型」と「技法の仮定」は、後続 AIOps 異常検知を読むための基礎層である**: [[Anomaly Detection - A Survey]] は、異常検知を点異常・文脈異常・集合異常に分け、技法を分類・近傍・クラスタリング・統計・情報理論・スペクトルの 6 群に整理した。重要なのは、各群を「どのような正常/異常仮定に依存するか」で比較する点である。[[@2015__CSUR__Performance Anomaly Detection and Bottleneck Identification]] はこの 3 分類に pattern anomaly を追加して性能異常検知へ拡張し、[[Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications]] は汎用異常検知サーベイとして Chandola 2009 を参照する。つまり、現代のマイクロサービス/AIOps 文献に現れる「文脈なしの統計的逸脱では不十分」という議論は、Chandola 2009 の文脈異常の定義を運用ドメインへ移したものとして読める。(Source: [[Anomaly Detection - A Survey]], [[@2015__CSUR__Performance Anomaly Detection and Bottleneck Identification]], [[Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications]]) > - **異常検知の手法比較は、性能表より先に仮定の整合性を見る必要がある**: Chandola 2009 は、分類ベースはラベル、近傍/クラスタリングベースは意味ある距離尺度、統計ベースは分布仮定、情報理論ベースは情報量尺度、スペクトルベースは低次元射影での分離可能性に依存すると整理した。これは現代の [[TelecomTS]] や [[MonitorAssistant]] が示す偽陽性問題と同じ構造で、観測データの正常急変動やインシデント文脈を無視すると、どれほど高性能な判定器でも「実用的異常」を取り違える。古典的な「仮定とドメインの整合性」評価は、LLM/時系列基盤モデル時代にも消えていない。(Source: [[Anomaly Detection - A Survey]], [[@2026__ICML__TelecomTS - A Multi-Modal Observability Dataset for Time Series and Language Analysis]], [[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]]) > - **2018年のSRE実務者向け入門は、異常検知をノイズ低減・外れ値特定・セキュリティ自動化という3つの独立した運用課題として並列に位置づけ、単一の理論的定義を与えない**: 『SREの探求』第18章は、SREが機械学習で解決したい課題として「ノイズの低減を自動化して特定のストリームをフィルタで除去する」「異常検出で外れ値を特定する(例: クラスタの機能不全)」を挙げ、成功事例(§18.7)では「異常検出はクレジットカード不正の検出や他の多くのアプリケーションに使われており、外れ値を検出することでセキュリティの自動化を飛躍的に改善している」と述べる。本ページが基礎として蓄積するChandola 2009の点異常・文脈異常・集合異常という理論的分類や、AIOpsの4-level taxonomyにおけるDetection段への位置づけとは異なり、SRE章は運用課題の列挙という形で異常検知を語る。時系列(§18.6.2.5)でも「異常検出を使って自動処理の必要性を発見し、即座にトリガーする」ことを予測と並ぶ活用例として挙げるが、具体的な検知アルゴリズムは示さない。(Source: [[Anomaly Detection - A Survey]], [[@2021__OReillyJapan__SREの探求 - Chapter 18 SREのための機械学習入門]] §18.2.1, §18.6.2.5, §18.7) > - **Borgmon の宣言型ルール評価は、「常時稼働には LLM が重すぎる」制約を LLM 以前から解いていた先例である**: [[@2016__OReilly__SRE Book - Chapter 10 Practical Alerting from Time-Series Data]] は Google の内部モニタリングシステム Borgmon がラベルセットによる多次元時系列モデルと代数的アグリゲーションで異常検知のルールを宣言的に記述し、for 節によるフラッピング防止と Alertmanager による重複排除・抑制を実現したことを記述する。ホワイトボックスモニタリング（内部状態の計装）とブラックボックスモニタリング（外部観測）の区別は、検知の観測点設計として本ページのシグナル源多様化の議論と接続する。この設計思想はそのまま Prometheus に受け継がれ、本 wiki のサーベイが「常時稼働の検知には LLM が重すぎる」と指摘する制約を、宣言型ルール評価が 10 年前から解いていたことを示す。(Source: [[@2016__OReilly__SRE Book - Chapter 10 Practical Alerting from Time-Series Data]]) > - **「異常検知に LLM は重い」という制約が、検知系の手法選択を分岐させている**: [[A Survey of AIOps in the Era of Large Language Models]] は、障害認知は理論上ソフトウェア稼働中ずっと連続実行が必要で実時間性が高い(例: 検知窓 10 秒なら 1 秒以内に推論を返す必要)が、この計算オーバーヘッド問題に十分対処した LLM 研究はまだ無いと明言する(§7.1)。これは本 wiki の訓練クラスタ監視の一次ソースが LLM を**あえて使わない**設計理由と表裏一体——[[Minder]]([[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]])は秒単位のメトリクス類似度、[[Pulse]]([[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]])はマイクロ秒級のトラフィック計測で、いずれも軽量・実時間の検知を LLM なしで達成する。サーベイが指摘する「常時稼働の検知には LLM が重すぎる」という課題に、検知レイヤの一次研究は非 LLM の統計/計測手法で答えている。(Source: [[A Survey of AIOps in the Era of Large Language Models]], [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]]) > - **検知のシグナル源そのものが多様化している**: サーベイの異常検知はシステム生成データ(メトリクス・ログ・トレース)を入力にするが、[[Google]] の [[Detectr]] は support ticket・SNS の **user feedback** を一次シグナルにしてテレメトリが見逃す outage を検知し、[[時系列基盤モデル]]([[Toto]]/[[BOOM]])は観測メトリクスのゼロショット予測から逸脱を測る。検知能力を上げる方向が「より良い検知アルゴリズム」だけでなく「シグナル源の多様化(人間の声・予測残差・ネットワークトラフィック)」へ広がっている([[AIOps]] の「検知の入力モダリティの拡張」と同じ観察)。(Source: [[A Survey of AIOps in the Era of Large Language Models]], [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]]) > > - **静的閾値の脱却と「顧客指向 SLO の予測」という新しい設計目標**: Google SRE は静的閾値が機能しない多様な顧客ワークロード(Google Cloud 製品が典型)に対し、**(1) シグナル収集はエージェント、(2) 異常検知は時系列基盤モデル([[TimesFM]] が例示)**、**(3) historical signals から「顧客指向 SLO」を予測**、**(4) サービス外シグナル(顧客フィードバック)を検知の入力に追加**、の 4 点の構成で対処する。これは [[MonitorAssistant]] が問うた「何を異常と見なすか」(統計的逸脱 vs インシデント裏付けの逸脱)に対する別解で、**顧客指向 SLO 自体を予測対象とする**ことで「業務上無関係な統計的逸脱を弾く」設計を時系列基盤モデルの予測能力に委ねる。検知層に LLM を置かず時系列基盤モデルに置く点は、本ページが整理する「常時稼働には LLM が重すぎる」制約への産業実装解の一例として位置づけられる。(Source: [[@2026__Google Cloud Blog__AI in SRE - Where Google is Deploying Agentic AI to Improve Operations]], [[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]], [[TimesFM]]) > - **時系列基盤モデルが異常検知と予測を同じ土俵に載せた**: サーベイは decoder-only(Lag-Llama・TimesFM・Timer)・encoder-decoder(TimeGPT・SimMTM)等の時系列基盤モデルを異常検知/障害種別分類の主要手法として整理する(§5.1)。本 wiki の [[時系列基盤モデル]] 概念([[Toto]]・[[Falcon-X]])はこの系譜の 2025–2026 年の先端で、予測精度の向上が下流の異常検知・[[障害予測]]にどう波及するかを開いた問いにしている。サーベイ(〜2024)が「予測ベースの異常検知」を 1 路線として挙げた延長に、観測データ特化 TSFM が現れた構図。(Source: [[A Survey of AIOps in the Era of Large Language Models]], [[@2025__NeurIPS2025__This Time is Different - An Observability Perspective on Time Series Foundation Models]]) > - **観測データの「正常な急変動」が異常検知の偽陽性を構造的に生む**: [[TelecomTS]]([[@2026__ICML__TelecomTS - A Multi-Modal Observability Dataset for Time Series and Language Analysis]])は、5G 通信のオブザーバビリティデータにおいて LLM(GPT-4.1・Claude 3.7 Sonnet)が再現率 0.84–1.0 だが適合率 0.17–0.26 に陥り、正常なストリーミング起因のスパイクを異常と誤判定する偽陽性バイアスを報告した。「データは本来不規則」というコンテキストを与えても改善は限定的。時系列基盤モデルでも [[Toto]] F1 0.615、Mantis F1 0.800 にとどまる。この結果は、サーベイが指摘する「常時稼働の検知に LLM が重すぎる」課題の手前に、**LLM は観測データの正常と異常の弁別自体が不得意**という精度面の限界があることを示す。一方、スケール情報を保持した Mantis(NME 搭載)が Toto を上回る点は、検知精度の向上がアーキテクチャのスケール意識に依存することを示唆する。(Source: [[@2026__ICML__TelecomTS - A Multi-Modal Observability Dataset for Time Series and Language Analysis]], [[A Survey of AIOps in the Era of Large Language Models]]) > - **「何を異常と見なすか」自体に学術—産業の構造的乖離がある**: [[MonitorAssistant]]([[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]])は「実用的異常(practical anomaly)」を「統計的逸脱**かつ**インシデントで裏付けられた逸脱」と定義し、深層学習モデルが検知する統計的外れ値の一部は業務上無関係だと事例で示す(§3.1, 図 3)。サーベイ([[A Survey of AIOps in the Era of Large Language Models]])が整理する LLM 時代の異常検知 3 方向(汎化/小モデル強化/学習回避)はいずれも**検知精度の向上**に注力するが、MonitorAssistant はその手前の「何が検知に値するか」を問い直し、LLM を検知器でなく**メタ判断層**(設定推奨・解釈・フィードバック仲介)に限定する。これは「検知自体に LLM を使う」路線と「LLM で検知を支援する」路線の分岐を具体化した初の産業投入事例であり、「常時稼働には LLM が重い」制約への実践的回答でもある。(Source: [[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]], [[A Survey of AIOps in the Era of Large Language Models]]) > - **ログ異常検知は「alert-agnostic だから診断には不十分」と産業側が一貫して退ける**: [[LogPilot]]([[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]])は、ログの正常パターンからの逸脱を統計的に捉えるログ異常検知(LogRobust の attention 付き Bi-LSTM、LogAnomaly の template2Vec など)を「alert-agnostic でアラート固有の文脈を欠くため、無関係ログで圧倒するか重要証拠を取りこぼす」と批判し、anomaly detection を log scoping から外して PromQL intent ベースの filtering に置換する。これは [[MonitorAssistant]] が「統計的外れ値の一部は業務上無関係」として実用的異常を「統計的逸脱 + インシデント裏付け」に再定義したのと同型——**産業側は「文脈なしの異常検知だけでは診断に不十分」という立場で一貫し、異常検知の出力をアラート/インシデントの文脈で絞り込む**(詳細は [[ログ解析]])。検知精度の向上(サーベイの 3 路線)とは別軸の、検知をどう診断に橋渡しするかへの産業の関心。(Source: [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]], [[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]]) > - **異常検知を「時間範囲予測」から「多肢選択の推論問題」へ組み替える流れ**: [[ARFBench]]([[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]])は、異常検知の評価が抱える「正解境界の曖昧さ・ラベルの主観性・専用指標(VUS 等)の難しさ」を、異常理解を多肢選択の単一クラス分類([[時系列質問応答]])に落とすことで回避する。これは [[MonitorAssistant]] の「実用的異常 = 統計的逸脱 + インシデント裏付け」、[[LogPilot]] の「文脈なし検知は診断に不十分」と同じ問題意識——「何を異常と見なし、どう評価するか」を業務文脈へ寄せる——を、評価形式の側から実装したもの。さらに ARFBench は VLM が異常の有無(Presence)は得意だが性質判定(Magnitude/Categorization 等)で人間に劣ると示し、[[TelecomTS]] の偽陽性バイアスと同様、観測データの文脈依存性が異常の弁別を難しくする構図を TSQA でも確認した。(Source: [[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]], [[@2026__ICML__TelecomTS - A Multi-Modal Observability Dataset for Time Series and Language Analysis]]) > - **異常検知の入力が「運用テレメトリ」から「訓練ダイナミクス」へ拡張され、"正常は絶対値でなく相対プロファイル" が再確認される**: [[RFT-FM]]([[@2026__arXiv__Towards Robust LLM Post-Training - Automatic Failure Management for Reinforcement Fine-Tuning]])は、サービス運用のメトリクス/ログ/トレースでなく、[[強化ファインチューニング]] の訓練信号(reward/KL/entropy/return/response length)を異常検知の入力にする。注目すべきは、健全な normal-profile を較正して「絶対量でなく健全プロファイルからの逸脱」で異常を測る設計が必須だった点——Normal-Profile Calibration を外すと recall が崩壊(F1 87.96%→21.23%)する。これは本 wiki の [[MetricSifter]] が正常区間を事前指定せず[[変化点検知]]で逸脱を捉える設計、[[Minder]] がマシン間のメトリクス類似度(他マシン基準の相対偏差)で故障を検知する設計と同じ「正常は文脈相対」という原理を、訓練ダイナミクスという新ドメインで再確認したもの。RFT-FM が系列ベース異常検知 TranAD/OmniAnomaly/AT を比較対象にする点で、運用と訓練で同じ多変量時系列異常検知の道具立てが共有されることも示す。(Source: [[@2026__arXiv__Towards Robust LLM Post-Training - Automatic Failure Management for Reinforcement Fine-Tuning]], [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]]) > - **アラート denoise を LLM でなく軽量グラフで解く産業選択**: 本 wiki の「常時稼働の検知に LLM は重すぎる」スレッド([[A Survey of AIOps in the Era of Large Language Models]] §7.1、[[Minder]]/[[Pulse]] の非 LLM 検知)に対し、[[AlertGuardian]]([[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]])は denoise 段を**LLM を使わず**軽量グラフモデル(GraphGuardian=LINE+Transformer)+ 仮想ノイズノード + 高基数属性の匿名化で実装し、コスト・遅延(<200ms)・精度(削減率 93.82〜95.50%)を同時に満たす。注目すべきは AlertGuardian が summary 段(RAG+DeepSeek V3)では LLM を使う一方、検知/ノイズ除去の段だけは軽量識別モデルを選ぶ段階別の使い分けで、これは [[MonitorAssistant]] が LLM を検知器でなくメタ判断層に限定したのと同型——**検知/denoise の段は LLM より軽量識別モデルが本番で有利**という産業の収束した選択を、アラートライフサイクルの実装として具体化する。(Source: [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]], [[A Survey of AIOps in the Era of Large Language Models]]) > - **既存 denoise の属性組合せ爆発を匿名化で回避**: 既存のアラート denoise(UHAS/OAS)は固定属性・ペアワイズ共起を前提にするため、属性の組合せが爆発し高基数属性に弱い([[AlertGuardian]] §II-C1)。AlertGuardian は属性値そのものを匿名化することでこの前提を外し、属性組合せに依存しない一般化された denoise を実現する。検知精度の向上(サーベイの 3 路線=汎化/小モデル強化/学習回避)とは別軸の、**denoise の前処理表現(属性の扱い方)を変えて一般性を稼ぐ**設計であり、[[LogPilot]] が「文脈なし検知は診断に不十分」として検知の出力を絞り込む立場と並べると、産業側が検知/denoise の入出力表現を運用文脈に合わせて作り替える流れの一例として読める。(Source: [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]], [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]]) > - **エージェントシステム固有の異常タクソノミーが従来の「テレメトリ逸脱」定義を拡張する**: 従来の異常検知は「メトリクス・ログ・トレースの統計的逸脱」を異常と見なしてきた。本 wiki の [[A Survey of AIOps in the Era of Large Language Models]] が整理する 3 方向(汎化/小モデル強化/学習回避)はこの枠内にある。これに対し AgentOps サーベイ([[@2026__arXiv__Agent System Operations - Categorization, Challenges, and Future Directions]])は、エージェントシステムの異常を Intra-Agent(推論異常・行動異常・メモリ異常・セキュリティ異常)× Inter-Agent(タスク仕様異常・オーケストレーション異常・通信異常・終了異常)の 2 軸 8 種で定義し直す。「推論異常」は統計的逸脱が出ないまま意味的タスク失敗を起こす——つまり従来のメトリクス/ログ異常検知が原理的に検知できない異常が存在する。この拡張は異常検知の「何を異常と見なすか」という定義問題を、サービス運用ドメインからエージェント実行ドメインへ持ち込む最初の体系的試み。[[MonitorAssistant]] の「実用的異常 = 統計的逸脱 + インシデント裏付け」定義と並べると、エージェント推論異常は「インシデント裏付け」が来てから初めて「異常だった」と判定される後付け性を持つ——リアルタイム検知をさらに困難にする。(Source: [[@2026__arXiv__Agent System Operations - Categorization, Challenges, and Future Directions]]) > - **分散訓練メトリクスの統計的安定性を前提に教師なし手法が広く使われる**: [[@2025__IWQoS__eACGM - Non-instrumented Performance Tracing and Anomaly Detection towards Machine Learning Systems]] は GMM(密度 < δ)で全スタックを扱い 6 ベースラインを上回り、[[@2025__DSN__LLMPrism - Black-box Performance Diagnosis for Production LLM Training Platforms]] は閾値不要の k-σ 則(k=3)という極端に単純な統計則を本番運用の単純さ優先で採り、[[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]] の LSTM-VAE と対極をなす。(Source: [[@2025__IWQoS__eACGM - Non-instrumented Performance Tracing and Anomaly Detection towards Machine Learning Systems]], [[@2025__DSN__LLMPrism - Black-box Performance Diagnosis for Production LLM Training Platforms]], [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]]) > - **ログ異常検知の入力イベント自体が大半不要で、70% 超を削減しても性能が低下しないどころか向上する**: [[@2024__ESEM__Reducing Events to Augment Log-based Anomaly Detection Models - An Empirical Study]] は 6 モデル×3 データセットの実証で、ログイベントの 55%〜99.9% を削減可能と示し、イベントを anti-event(ラベルと無相関でモデルを誤導)・duplicative-event(情報が他と重複)・key-event(相互補完的で不可欠)の 3 類型に分類する。削減後にほぼ全モデルで F1 が向上——RobustLog は Thunderbird で 69.2%→100%——し、「ノイズログの除去が検知を改善する」ことを定量的に裏づけた。これは本 wiki の「情報を絞ってから推論する」骨格([[ログ解析]]・[[特徴量削減]])のログイベント版であり、[[LLM4Log]] が整理する 6 ファミリの前処理層として位置づく。さらに [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]] が「alert-agnostic なログ異常検知は文脈なしで不十分」と退ける立場の手前で、そもそも**入力イベント自体の大半が検知に無関係**という構造的問題を実証した点が本研究の独自の貢献。(Source: [[@2024__ESEM__Reducing Events to Augment Log-based Anomaly Detection Models - An Empirical Study]], [[LLM4Log]], [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]]) > - **メトリクスの異常検知への貢献度の不均等性が、収集周波数の最適化という経路で異常検知の精度向上に還元される**: [[@2024__IEEE CLOUD__Enabling Programmable Metric Flows]] は複数の多変量時系列異常データセットで COPOD を用い、上位 20% の重要メトリクスのみの AU-ROC が下位 20% を大きく上回ることを実証した（図 1）。この不均等性を利用し、帯域制約下で重要メトリクスに高周波数を割り当てることで、固定周波数の Prometheus と同一帯域で WRE を約 600 倍削減する。これは [[MetricSifter]]([[@2024__IEEE Access__MetricSifter - Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications]])が「無関係メトリクスを減らすと箇所特定が改善する」と示した[[特徴量削減]]の骨格を、収集側（データ生成の手前）で周波数最適化として実装したもの。分析段の特徴量削減と収集段の周波数最適化は、同じ「メトリクスの不均等な重要度」を別の層で活用する相補的な設計パターンとして接続する。(Source: [[@2024__IEEE CLOUD__Enabling Programmable Metric Flows]], [[@2024__IEEE Access__MetricSifter - Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications]]) > - **ログ異常検知は LLM4Log 最大のタスク(71 論文)で、「LLM は何が異常かの曖昧さを消さず努力を feature 設計から normality curation へ移す」と地図が確定する**: [[LLM4Log]] はログ異常検知をサーベイ最大のタスクと位置づけ、6 ファミリ——encoder ベース discriminative(HitAnomaly/SwissLog/HilBERT)、MLM 自己/半教師の正常モデリング(LogBert/LAnoBERT)、decoder 生成予測(LogGPT)、prompting/ICL(LogPrompt/OWL)、RAG(RAPID/RAGLog)、hybrid 協調(LLMeLog/LogLLM/AdaptiveLog の小モデル + 大モデル)、agentic(Audit-LLM/LogRESP-Agent)——に整理する(§6.2)。中心観察は「最強システムは異常を期待挙動との evidence-grounded な不整合(retrieved 正常からの逸脱・明示ルール違反・較正済み高スコア)として扱い、LLM を主に説明/検証/軽量検知器のエンリッチに使う。LLM は何が異常かの曖昧さを除去せず、努力を feature 設計から **normality curation・context 選択(windowing/retrieval)・誤報/コストを抑える運用ガードレール**へ移す」こと。これは本 wiki の [[MonitorAssistant]](LLM を検知器でなくメタ層に限定)・[[AlertGuardian]](denoise 段は LLM でなく軽量グラフ)・[[LogPilot]](文脈なし検知は診断に不十分)が産業側から個別に到達した「検知/denoise の段は LLM より軽量識別 + 文脈絞り込みが有利」という結論の、サーベイ全体での裏づけ。ただしサーベイのコーパスは HDFS/BGL/Thunderbird/Spirit への依存が顕著で(Table 6–7)、運用現実を部分的にしか反映しない。(Source: [[LLM4Log]], [[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]], [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]]) > - **ストレージ層のデータモデル制約が非自明な異常の探索性を根本から制限する**: [[Chronix]]（[[@2017__FAST__Chronix - Long Term Storage and Retrieval Technology for Anomaly Detection in Operational Data]]）は 2017 年に、汎用 TSDB が数値スカラー型しか扱えないため `lsof`（開放ファイルハンドル）・`strace`（システムコール系列）等のログ型データをタグ/タイムスタンプに強制エンコードせざるを得ず、ナノ秒精度の消失・クエリ意味の歪み・追加実装コストを招くことを産業 5 プロジェクトで実証した。実際、ファイルハンドルリークの根本原因特定（Grizzly のセレクタリーク）には「CPU メトリクス + `lsof` のグループサイズ + `strace` の特定ファイルハンドル ID の相関クエリ」が必須で、ストレージ層が多型データをネイティブに保持できる場合にのみ可能な分析だった。これは、[[@2023__ESEC-FSE__Detection Is Better Than Cure - A Cloud Incidents Perspective]] が「ミス検知の最大要因は必要なモニタの欠如」と示した問題意識と同型——**「どう検知するか（アルゴリズム）」より「何を保存・相関できるか（ストレージのデータモデル）」が検知可能な異常の空間を決める**という 2017 年の先行実証。(Source: [[@2017__FAST__Chronix - Long Term Storage and Retrieval Technology for Anomaly Detection in Operational Data]] §3・§5, [[@2023__ESEC-FSE__Detection Is Better Than Cure - A Cloud Incidents Perspective]]) > - **ミス検知タクソノミは「検知アルゴリズムの前に設計の問題がある」ことを大規模実証で確認した**: [[@2023__ESEC-FSE__Detection Is Better Than Cure - A Cloud Incidents Perspective]] は Microsoft 300 超サービスを分析し、ミス検知の最大要因がアルゴリズムの精度不足でなく「必要なモニタが存在しない（40.41%）」と「シグナルが欠如している（18.13%）」であることを示した。これは本 wiki の異常検知研究が扱う「どう検知するか（アルゴリズム）」以前に、「何を検知すべきか（モニタ設計）」という問題が実運用では主要ボトルネックであることを大規模データで裏づける。[[MonitorAssistant]] の「実用的異常 = 統計的逸脱 + インシデント裏付け」定義がこの研究の知見に基づいて設計されたと解釈でき、「アルゴリズム精度向上」と「モニタ設計支援」という二つの研究路線の分岐を経験的に正当化する。(Source: [[@2023__ESEC-FSE__Detection Is Better Than Cure - A Cloud Incidents Perspective]], [[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]]) > > - **マイクロサービス異常検知では「データ源の統合」が常に性能改善を意味しない**: [[Anomaly detection and root-cause identification in microservices]] は、ログ、分散トレース、監視メトリクスをデータ収集の 3 軸に整理し、ログベースが accuracy/precision/recall で高く、ログ+トレースが F1 で最も高い一方、ログ+トレース+監視の 3 種統合は accuracy/precision/recall が低いと報告する(§4.7)。これは [[LogPilot]] が「文脈なしにログを増やすと診断を悪化させる」と示した入力選別の観察、[[MetricSifter]]/[[PMF]] がメトリクスの不均等な重要度を利用して収集・分析を絞る観察と同型である。単純なマルチモーダル化より、障害クラスに合う信号源の選別と正規化が検知性能を律速する。(Source: [[Anomaly detection and root-cause identification in microservices]], [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]], [[@2024__IEEE Access__MetricSifter - Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications]]) > - **マイクロサービス異常検知の古典的タクソノミは「データ源 × 学習方式」の 2 軸に収束したが、手法選択はセットアップコストとのトレードオフである**: [[Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications]]（Soldani & Brogi 2021）は、マルチサービスアプリケーションの異常検知 25 手法を**データ源（ログ/分散トレース/監視メトリクス）× 検知方式（教師なし/教師あり/トレース比較/SLO チェック/ハートビート）**の 2 軸で整理した最初のサーベイである。中心的な知見は「SLO チェックは設定コスト最小だがアプリ全体粒度しか得られない」「教師あり学習は故障種別まで返せるが障害注入込みの訓練を要する」「トレース比較はオンライン用途では計算コストが高すぎる（Chen et al. を除く）」という設定コスト vs 粒度のトレードオフである。5 年後の [[Anomaly detection and root-cause identification in microservices]]（Barata et al. 2026）が 117 件に拡張しても基本軸は同じ——「データソース × 手法種別」の枠組みの安定性を確認する。LLM 時代の 3 方向（汎化/小モデル強化/学習回避）は、この Soldani 分類で言う「教師なし学習」路線の延長として位置づく。(Source: [[Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications]], [[Anomaly detection and root-cause identification in microservices]]) > - **トレースを派生メトリクス時系列に落として古典外れ値検知を当てる経路は LLM 時代以前から実用化されていた**: [[@2021__J Grid Computing__Automated Analysis of Distributed Tracing - Challenges and Research Directions]] は Huawei Cloud OpenStack の本番 OpenTracing データに [[OpenTracing Processor]] で「サービスごとの incoming/outgoing 呼数 + 平均応答時間 + dependency graph の morphology」を抽出し、解像度 10 分の時系列に Isolation Forest を当てて異常な時間枠とサービスを位置づけた。これは Soldani & Brogi 2021 の「トレースを用いた教師なし異常検知」路線の具体実装にあたる(同サーベイは distributed tracing を独立のデータ源として整理)。注目すべきは Bento+ の結論で、「検知はできたが Why は work-flow 計装欠落で深追いできない」——つまり**異常検知の天井はモデルでなく入力データの品質**([[トレース品質]])にあるという診断。[[MonitorAssistant]] の「実用的異常 = 統計的逸脱 + インシデント裏付け」が運用観点で同型を述べ、[[@2023__ESEC-FSE__Detection Is Better Than Cure - A Cloud Incidents Perspective]] が「ミス検知の最大要因は必要なモニタの欠如」と統計で示したのと、トレースデータ側で同じ「データ設計が検知の上限を決める」観察を 2021 年時点で立てていたことになる。(Source: [[@2021__J Grid Computing__Automated Analysis of Distributed Tracing - Challenges and Research Directions]], [[Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications]], [[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]]) > - **「動的に変化するマイクロサービス」は訓練問題を構造的に生む**: Soldani & Brogi 2021（§3.4.3）は、大半の手法が「訓練時と同じ条件でアプリが動く」前提を持つと指摘する。実際には新サービス追加・既存サービス置換・同居アプリのリソース競合・ワークロード季節性が頻繁に起き、これが偽陽性/偽陰性を生む構造的原因になる。Seer（定期再訓練）・DLA（k8s 展開前提）・PreMiSE（大量訓練データで季節性を網羅）はそれぞれこの「訓練問題」への異なる緩和戦略だが、いずれも再訓練コストとの更新周期のトレードオフを免れない。本 wiki の [[MonitorAssistant]] が「実用的異常 = 統計的逸脱 + インシデント裏付け」と定義し直す背景には、同じ「訓練問題」——何が正常かがアプリとともに変化する——がある。(Source: [[Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications]]) > - **「常時稼働の検知に LLM は重すぎる」という制約に対し、LLMAD はサンプリング周波数を 1 分粒度以上に寛容化することで実用域へ突き抜けた**: [[@2025__KDD__Large Language Models can Deliver Accurate and Interpretable Time Series Anomaly Detection]] の [[LLMAD]] は GPT-4-1106-preview を直接 TSAD の判定器に使い、リクエストあたり 17 秒・年間運用コスト約 $65.70(1 分粒度サンプリング × 24 時間運用)で TFAD・Informer・Anomaly Transformer を平均 Best F1 で上回る。本ページの中心観察「常時稼働の検知に LLM が重すぎる(検知窓 10 秒なら 1 秒以内の推論)」(サーベイ §7.1)は、サンプリング周波数を 1 分以上にすれば**コストとレイテンシの両方で実用域**になることを定量化した。[[Minder]]/[[Pulse]] が秒〜マイクロ秒級の非 LLM 検知で前提条件を回避するのに対し、LLMAD は「検知周期を運用上許容される粒度に緩める」ことで LLM 直接判定路線を実装した。同論文は GPT-4 級でないと性能が出ない(Llama-3-70B・GPT-3.5 では実用域に届かない)ことも示し、「強い指示追従」が直接判定路線の必要条件であることを明らかにする。(Source: [[@2025__KDD__Large Language Models can Deliver Accurate and Interpretable Time Series Anomaly Detection]], [[A Survey of AIOps in the Era of Large Language Models]]) > - **解釈性が検知精度と背反でなく協働する**: [[LLMAD]] は AnoCoT(判定ルール・8 種の異常タイプ定義・3 段階のアラームレベル定義 + 大域 → 局所 → 再評価の段階推論)で、平均 Best F1 を標準 CoT 比 +6.2% かつ人手評価 usefulness を +13.4% 同時に改善した。Microsoft 5 名の DevOps エンジニア(平均 3 年の TSAD 経験)による評価で usefulness ≥4 を 72.37% / readability ≥2 を 97.11% 達成する。これは本ページの [[MonitorAssistant]] が「LLM を検知器でなくメタ判断層に限定」したのと対照的に、LLM を**検知器そのもの**として使いつつ解釈性を同時に出すアプローチで、Microsoft 内の異常検知 LLM 化研究の 2 路線(検知器 vs メタ層)が併走している事実を示す。「ミス検知の原因はモニタの欠如(40.41%)/シグナルの欠如(18.13%)」とした [[@2023__ESEC-FSE__Detection Is Better Than Cure - A Cloud Incidents Perspective]](Chetan Bansal が両論文の共著者)の問題意識を、LLMAD は「LLM が解釈可能な検知器を低コストで提供することで、運用者がモニタ追加判断を下せるようにする」方向で延長する。(Source: [[@2025__KDD__Large Language Models can Deliver Accurate and Interpretable Time Series Anomaly Detection]], [[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]], [[@2023__ESEC-FSE__Detection Is Better Than Cure - A Cloud Incidents Perspective]]) > - **多変量・自然言語クエリ駆動の異常検知は TS-MLLM が射程に入れる新領域**: [[@2025__VLDB__ChatTS - Aligning Time Series with LLMs via Synthetic Data for Enhanced Understanding and Reasoning]] の [[ChatTS]] は Oracle DB 6 メトリクスの障害シナリオで、(i) どのメトリクスが異常か、(ii) rulebook(「LogFile/DBFile/Cache/GC の最大振幅メトリクスが根本原因」)に基づきどれが根本原因か、(iii) どう伝播するか、を自然言語の多ターン対話で返す(Fig 14)。これは本ページが [[LogPilot]]・[[ARFBench]] で議論した「異常検知の出力をアラート/インシデントの文脈で絞り込む」流れの延長で、**多変量メトリクスを 1 つのモダリティとして渡し自然言語クエリで掘る**ことを実現する初の TS-MLLM。[[LLMAD]] が単変量 GPT-4 ベースで検知 + 解釈に集中するのに対し、ChatTS は多変量の相関分析と根本原因推論まで踏み込む。本ページの「マイクロサービス異常検知では『データ源の統合』が常に性能改善を意味しない」(Barata 2026 サーベイ)という観察に対し、ChatTS の text-only ablation(MTS で text-only がほぼ回答不能)は「**多変量を真に統合するにはネイティブモダリティが要る**」と示唆する。(Source: [[@2025__VLDB__ChatTS - Aligning Time Series with LLMs via Synthetic Data for Enhanced Understanding and Reasoning]], [[@2025__KDD__Large Language Models can Deliver Accurate and Interpretable Time Series Anomaly Detection]], [[Anomaly detection and root-cause identification in microservices]]) > - **SLO 違反を二値分類として定式化する手法は 2004 年から実証されており、「単一メトリクスルールは不十分」もその時点で定量化されていた**: [[@2004__OSDI__Correlating Instrumentation Data to System States - A Building Block for Automated Diagnosis]]（Cohen et al., OSDI 2004）は 3 層ウェブサービスの 124 メトリクスから SLO 違反（平均応答時間の閾値超過）を二値分類するタスクを定式化し、TAN（ツリー拡張ナイーブベイズネットワーク）で balanced accuracy 87–94%、検知率 90%+ を達成した。重要なのは「アプリサーバ CPU 利用率のみ（ルール・オブ・サム）」ではワークロードが変わると BA が 56%（STEP）・63%（BUGGY）へ急落し、3–8 個のメトリクスの組み合わせが必要なことを定量化した点である。これは本 wiki の [[クラウドモニタリング]]・[[MetricSifter]] が「複数メトリクスの組み合わせでしか違反を捉えられない」という観察と、2004 年の時点で一致する。SLO 違反分類の定式化と「単一ルール限界」の定量化は、現代 AIOps の「異常検知は多変量解析が必要」という前提の実験的起点になっている。(Source: [[@2004__OSDI__Correlating Instrumentation Data to System States - A Building Block for Automated Diagnosis]]) > - **2015 年の PADBI サーベイが整理した「4 検知戦略 × 統計/ML 手法」の枠組みは LLM 時代の分類とどう接続するか**: [[@2015__CSUR__Performance Anomaly Detection and Bottleneck Identification]] は性能異常検知の手法をシグネチャベース・観測ベース・知識駆動・フロー&依存関係解析の 4 戦略に分類し、統計手法(Gaussian/GMM・回帰・SPC)と機械学習(SVM/LOF/k-means)の両系譜を整理した。現代の [[AIOps]] サーベイ([[A Survey of AIOps in the Era of Large Language Models]])の「汎化/小モデル強化/学習回避」という LLM 時代の 3 方向は、2015 年の「観測ベース + ML」路線の延長であり、「知識駆動」路線がベイジアンネット・因果グラフから LLM プロンプティングへと具体化した系譜として読める。2015 年時点では分類の 53% が PAD のみを扱い統合(PADBI)が 18% にとどまったという知見は、10 年後の現代でも「検知のみで根本原因特定を含まない手法が多い」という同型の批判と構造的に重なる。(Source: [[@2015__CSUR__Performance Anomaly Detection and Bottleneck Identification]], [[A Survey of AIOps in the Era of Large Language Models]]) > - **クラウド固有の課題(スケール・マルチテナンシー・動的リソース管理)が PAD/PBI の適用を困難にするという 2015 年の指摘は、現代の産業実装でどこまで解消されたか**: [[@2015__CSUR__Performance Anomaly Detection and Bottleneck Identification]] はクラウド環境の 4 課題(スケール・マルチテナンシー・複雑アーキテクチャ・動的リソース管理)を未解決の研究課題として整理した。本 wiki が記録する 2025–2026 年の研究群——[[Minder]](マシン間類似度)・[[eACGM]](非計装トレーシング)・[[MonitorAssistant]](実用的異常の定義)——はそれぞれこの課題の一面を解決しようとしているが、これらを俯瞰すると「スケールと動的性への対応」が依然として各研究の設計制約を律速しており、2015 年の課題識別が今なお有効であることが分かる。(Source: [[@2015__CSUR__Performance Anomaly Detection and Bottleneck Identification]], [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]], [[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]]) > > - **ビジネストレンドへの N-シグマ則では N を固定しないことが Alibaba の産業知見である**: 2017 年に [[Zhaogang Wang]] が報告したビジネストレンド異常検知([[@2017__SREcon17 Asia__Smart Monitoring System for Anomaly Detection on Business Trends in Alibaba]])では、N=3 固定の標準 N-シグマ則が「時間セグメントやビジネストレンドによってシグマが変わる」ため機能しないと結論づけ、時間セグメント × ビジネストレンドごとに N を個別決定する設計を採った。これは本 wiki の LinkedIn の修正 Z スコア([[@2021__SREcon21__Spike Detection in Alert Correlation at LinkedIn]]、MAD ベース・固定閾値 3.5)が「統計パラメータは文脈によって変わる」という同型の観察を持つ一方、LinkedIn はシグナルを固定閾値で分離し Alibaba はビジネストレンドごとに適応するという実装上の対照が際立つ。「正常は文脈相対」という本 wiki の中心観察の最も早い産業事例の一つ。(Source: [[@2017__SREcon17 Asia__Smart Monitoring System for Anomaly Detection on Business Trends in Alibaba]], [[@2021__SREcon21__Spike Detection in Alert Correlation at LinkedIn]]) > - **時系列分解(STL)を検知手法として選ぶ理由は「ロバスト性」への要求である**: [[Zhaogang Wang]] の Alibaba 実装では、LSTM や Holt-Winters より STL(Seasonal Trend LOESS)を選んだ理由として「周期性・ドリフトに適合・局所ノイズにロバスト」の 3 点を挙げる([[@2017__SREcon17 Asia__Smart Monitoring System for Anomaly Detection on Business Trends in Alibaba]])。[[Baidu]] の [[Dong Wang]] が低頻度パターン(祝日)問題で Holt-Winters と BP NN の破綻を報告した([[@2017__SREcon17Americas__Anomaly Detection in Infrequently Occurred Patterns]])のと比較すると、両社ともビジネストレンドの異常検知で「単純な統計モデルや NN が季節性・周期性の複雑さを扱えない」という同じ課題に直面しながら、解法が異なる——Alibaba は STL + ヒューマンフィードバック、Baidu は k-means クラスタリングによる類似日発見——点が対照的である。ビジネストレンドの異常検知は「汎用手法の直接適用が困難」という領域であることを 2017 年の段階で 2 つの産業事例が確認した。(Source: [[@2017__SREcon17 Asia__Smart Monitoring System for Anomaly Detection on Business Trends in Alibaba]], [[@2017__SREcon17Americas__Anomaly Detection in Infrequently Occurred Patterns]]) > > - **アラート相関の後段でスパイクを分離する修正 Z スコアは「ML なしの統計的外れ値判定が産業で有効」な最小限実装である**: LinkedIn の [[Nishant Singh]] は、アラート相関システムの推奨結果に MAD ベースの修正 Z スコア（$M_i = 0.6745(x_i - \tilde{x})/MAD$、閾値 3.5）を適用し、一時的スパイクと真のアラートを分離した([[@2021__SREcon21__Spike Detection in Alert Correlation at LinkedIn]])。約 5 日間で 193 件中 71 件（36.4%）をスパイクと判定し偽陽性率 1% 未満、トイルを 30–40% 削減。この「ML を使わない単純な統計手法で十分」という結論は、[[AlertGuardian]] が denoise 段に軽量グラフモデルを選ぶ判断、[[Minder]] がメトリクス類似度で故障を検知する判断、[[LLMPrism]] が k-σ 則（k=3）を本番運用で採用する判断と同型——**検知/denoise の段は軽量統計手法が産業で繰り返し選択される**パターンの最も単純な実例である。修正 Z スコアは Iglewicz & Hoaglin（1993 年）に由来し、MAD の外れ値ロバスト性が標準偏差ベースの Z スコアに対する優位をアラート相関の文脈で実証した。(Source: [[@2021__SREcon21__Spike Detection in Alert Correlation at LinkedIn]], [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]], [[@2025__DSN__LLMPrism - Black-box Performance Diagnosis for Production LLM Training Platforms]]) > - **「固定閾値は文脈依存で機能しない」という Alibaba 自身の 2017 年の知見(N-シグマ則)を、同社の別チームがストレージデバイス単位で 2023 年に再発見している**: [[PERSEUS]]([[@2023__loginonline__Detecting Fail-Slow Failures in Large-Scale Cloud Storage Systems]])は、ドライブのフェイルスロー検知に固定レイテンシ閾値(例: 45µs)を使うと「緩ければ正常な負荷変動を誤検知し、厳しければ検知漏れが増える」というジレンマに直面したと報告する。これは 2017 年に同じ Alibaba 内の別チームが報告した「N=3 固定の標準 N-シグマ則はビジネストレンドで機能しない」という知見([[@2017__SREcon17 Asia__Smart Monitoring System for Anomaly Detection on Business Trends in Alibaba]])と同型である。両者の解法は異なる——ビジネストレンド検知は時間セグメント×トレンドごとに N を個別決定するのに対し、PERSEUS はレイテンシ対スループット分布への多項式回帰で**同一ノード内のピアとの相対比較**によって適応的しきい値を導出する。「固定閾値が文脈で破綻する」という同一企業内の教訓が、ビジネスメトリクスとハードウェアテレメトリという全く異なるドメインで独立に(おそらく互いを知らずに)再発見されている点が興味深い。(Source: [[@2023__loginonline__Detecting Fail-Slow Failures in Large-Scale Cloud Storage Systems]], [[@2017__SREcon17 Asia__Smart Monitoring System for Anomaly Detection on Business Trends in Alibaba]]) > - **MAD のロバスト性は Booking.com・LinkedIn の独立した産業事例で「過去インシデントが標準偏差を膨張させる」という同一の問題に対して収束的に選択された**: [[Ivan Shubin]] の Booking.com 実装（[[@2024__SREcon24 EMEA__Anomaly Detection in Time Series from Scratch Using Statistical Analysis]]）は、過去インシデントが 1 件混入しただけで標準偏差が 17.6→31.4（78% 増）に膨張するのに対し MAD は 15.6→20.5（31% 増）にとどまることを定量化した。LinkedIn の修正 Z スコア（[[@2021__SREcon21__Spike Detection in Alert Correlation at LinkedIn]]、MAD ベース・閾値 3.5）はアラート相関の後段でスパイクを分離する用途で MAD を選択しており、用途（ビジネスメトリクスの異常帯 vs アラート相関の偽陽性除去）は異なるが「外れ値が標準偏差を歪める」という動機が共通する。さらに Shubin は Graphite の `stddevSeries()`・`averageSeries()`・`diffSeries()` でモニタリングツール内に Z スコアパイプラインを閉じ込め、40 分スライディングウィンドウ + 5 パーセンタイル除外で過去インシデント週を自動排除する Granomaly を構築した。この「既存モニタリング基盤上に統計検知を構築する」設計は、Alibaba が STL + ヒューマンフィードバックを選び、Baidu が k-means クラスタリングで類似日を発見した 2017 年の設計選択と対照的に、2024 年時点でも AI/ML なしの軽量統計手法が産業で有効であることを確認する。(Source: [[@2024__SREcon24 EMEA__Anomaly Detection in Time Series from Scratch Using Statistical Analysis]], [[@2021__SREcon21__Spike Detection in Alert Correlation at LinkedIn]], [[@2017__SREcon17 Asia__Smart Monitoring System for Anomaly Detection on Business Trends in Alibaba]]) > - **「正常パターンが低頻度」かつ「季節性が非固定」という条件は、統計手法・NN の両方を破綻させる産業上の盲点である**: [[Baidu]] の [[Dong Wang]] は、中国の祝日トラフィック（春節・端午節・中秋節）では (1) 祝日が低頻度で訓練データが不足し、(2) 太陰暦に基づく日付が毎年変動するため時系列の季節性が使えず、中央値補正・時間補正・Holt-Winters・BP NN の 4 手法がいずれも破綻することを報告した([[@2017__SREcon17Americas__Anomaly Detection in Infrequently Occurred Patterns]] p.7–8)。解決策として日次トラフィック CDF の k-means クラスタリング（K=3）で平日・週末・祝日を分離し、リアルタイム比率補正で予測値を逐次調整する 2 段階手法を本番投入した。これは本 wiki が整理する「正常は文脈相対」（[[Minder]] のマシン間類似度、[[RFT-FM]] の Normal-Profile Calibration）の最も初期かつ単純な産業事例で、「正常パターンが存在するが稀にしか出現しない」という Chandola 2009 の文脈異常の変種に対し、クラスタリングで類似日を発見して正常プロファイルを構成する方法を示した。(Source: [[@2017__SREcon17Americas__Anomaly Detection in Infrequently Occurred Patterns]], [[Anomaly Detection - A Survey]], [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]]) > - **KPI ペアの不変条件崩壊を検知する TS-InvarNet はシステムトポロジ不要・モデルサイズ 292KB の超軽量異常検知を実現した**: TS-InvarNet（Hu+ ICWS 2022）は KPI ペア間の安定相関を SARIMAX で学習し、残差のクラスタリング（HDBSCAN）で不変条件崩壊を検出、グランジャー因果検定の出次数で障害ノードを箇所特定する。OmniAnomaly 4.9GB に対し 292KB（1/17,000）で精度は同等以上。「正常時の相関パターンが壊れたこと」を検知するため、新種の障害にも対応できる教師なし設計だが、KPI ペア間に安定相関が存在しない環境（完全疎結合サービス群）では適用上限がある。本ページの「多変量解析が必要」という知見に対し、TS-InvarNet は「全メトリクス一括」でなく「ペア単位の軽量モデル × 多数」で多変量を扱う分解戦略をとる。(Source: [[@2022__ICWS__TS-InvarNet - Anomaly Detection and Localization based on Tempo-spatial KPI Invariants in Distributed Services]]) > > - **分散 DB における多変量ログ異常検知は「単一ノード依存」と「Single-Point Classification の偽陽性」という二重の課題を持つ**: [[@2024__KDD__Multivariate Log-based Anomaly Detection for Distributed Database|MultiLog]]([[@2024__KDD__Multivariate Log-based Anomaly Detection for Distributed Database]])は、既存の Loghub ベースのログ異常検知(RobustLog・LogAnomaly・PLELog)を [[Apache IoTDB]] の分散 DB 環境に適用したときに生じる 2 つの問題を実証した。(1) 異常が注入されたノード自身よりも周辺ノードの方が異常を高精度に検知できる「影響ノードの自己検知の困難さ」——エクスポート操作を Node 1 に注入した実験で Node 1 の F1 が 56.66% に留まる一方 Node 6 は 90.73% を達成。(2) 各ノードの予測を OR 結合する Single-Point Classification では偽陽性が急増し、Low Speed Query 実験で LogAnomaly の F1 が 58.74% に急落。MultiLog は LSTM+セルフアテンション(Standalone Estimation)で系列・定量・意味の 3 種情報を各ノードから抽出し、オートエンコーダ+メタ分類器(Cluster Classifier)で全ノードを統合することで Multi2Multi F1 99.82%(既存 SOTA 比 +16 ポイント)を達成した。この「多変量ログの統合が偽陽性削減に直結する」という知見は、[[ログ解析]]・[[ログベース異常検知]]の分野において、分散環境固有の多ノード設計が不可欠であることを KDD 2024 の実証で確立した。(Source: [[@2024__KDD__Multivariate Log-based Anomaly Detection for Distributed Database]]) > > - **SLO 延長概念（SLF）による次元付き異常局所化は「どの次元のどの SLI が原因か」を自動絞り込む**: Ant Group の SLX フレームワーク（Ding+Zhang, SREcon21）は、SLO 違反を検知した後にどの次元（DC・API ラベルの組み合わせ）が原因かを絞り込む段階に SLF（Service Level Factor）を用いる。SLF は SLI を詳細ラベル次元でスライスした概念で、Observation → Prediction（統計回帰または機械学習）vs. Threshold（確率分布または経験値から算出）という二段構えの動的閾値（±3σ バンド）を使い時系列異常を検知する。本ページが整理する「ビジネストレンドへの N-シグマ則では N を固定しないことが産業知見」（Alibaba 2017）や「MAD のロバスト性が産業で収束的に選択される」（LinkedIn/Booking.com）と同型の「統計的動的閾値」路線だが、SLX は SLI 全体ではなく SLF 粒度で適用することで次元の呪い（高カーディナリティラベルが爆発する問題）との対立を「有用な粒度を維持しながら SLF の定義を絞る」という設計判断で扱う。SLO 違反の検知から SLF 次元の局所化へのパイプラインは、[[Fault Localization]] と[[根本原因分析]]の中間段階にあたる (Source: [[@2021__SREcon21__SLX - An Extended SLO Framework to Expedite Incident Recovery]])。 > > - **2021〜2024 年の SLR で異常検知はマイクロサービス AI アシスタントの最大研究目標(41.9%)かつ Detect フェーズの主要タスクである**: [[Dahlia Ziqi Zhou]]・[[Marios Fokaefs]]([[@2024__arXiv__AI Assistants for Incident Lifecycle in a Microservice Environment - A Systematic Literature Review]])の SLR では、31 一次研究のうち 13 件(41.9%)が異常検知を主目標とし、Detect フェーズ(54.8%)の主力タスクとなっている。手法面では LLM ベース(ChatGPT によるログ処理 Qi+・インコンテキスト学習 + CoT の LLMAD)・深層学習(グループベーストレース異常検知 Xie+・教師なしトレース異常検知 Liu+)の双方が活発に研究されている。データソースはログ(48.4%)が最多で、トレース(29%)・メトリクス(25.8%)が続く。LLM を使った異常検知の急増(手法全体の 38.7%)は 2023 年以降に集中しており、本 wiki の他の横断的知見が整理する「常時稼働には LLM が重い」という制約と正面から衝突するが、SLR が評価した研究のほとんどが本番デプロイではなくベンチマーク評価にとどまる。(Source: [[@2024__arXiv__AI Assistants for Incident Lifecycle in a Microservice Environment - A Systematic Literature Review]] RQ1・RQ2・RQ3) > > - **「異常検知モデルをエッジ配置可能な水準へ圧縮する」ことが、多変量時系列異常検知(MTSAD)の新しい実用課題として顕在化している**: [[RefinedEdge]]([[@2025__TSC__Bridging Edge and Cloud - A Knowledge-Enhanced Framework for Efficient Time Series Anomaly Detection]], IEEE TSC 2025)は、エッジデバイス(2.6GHz 6 コア CPU)が実験的に「0.15M パラメータ未満のモデルしか効果的に扱えない」と報告し、この制約の下で多変量時系列異常検知モデルを配備する課題を定式化した。クラウド側で集約データから大型教師モデルを訓練し、多戦略アンサンブルプルーニング + 知識蒸留で 0.12M パラメータまで圧縮した学生モデルが、EdgeNode/SMD/MSL/SMAP の 4 データセットで F1=0.9588/0.9274/0.8827/0.8580 を達成し、SMD ではパラメータ比 1.7% の下で 7M パラメータのクラウド訓練モデルを上回った。従来の異常検知研究の多くが精度最大化を主目標としてきたのに対し、本論文は「精度を維持したまま資源制約下に収める」という別の最適化軸を明示的に扱う。(Source: [[@2025__TSC__Bridging Edge and Cloud - A Knowledge-Enhanced Framework for Efficient Time Series Anomaly Detection]]) > - **知識蒸留による異常検知モデル圧縮は、単純な教師出力模倣では時間依存構造を十分転写できない**: RefinedEdge は予備実験で「従来の知識蒸留アプローチは時系列異常検知に適用すると性能が低下する」ことを確認し、再構成損失(自己学習)と蒸留損失(教師模倣)を係数 λKD でバランスさせる設計に至った。λKD 0〜1 のグリッドサーチではベル型の性能曲線(最適点 λKD=0.6、両極端で劣化)が観測され、「教師に依存しすぎても、自己学習に依存しすぎても異常検知精度が落ちる」という中間点の存在を実証している。これは異常検知モデルの圧縮が単なる汎用モデル圧縮の応用ではなく、時系列固有の時間依存構造の保存を要する設計問題であることを示す一次サンプルである。(Source: [[@2025__TSC__Bridging Edge and Cloud - A Knowledge-Enhanced Framework for Efficient Time Series Anomaly Detection]] §IV-C, §V-C) > > - **分散異常検知における「正常性の場所間比較」は、2005 年の時点ですでに実証的に否定的な結論が出ていた**: [[@2005__Machine Learning__Principle Components and Importance Ranking of Distributed Anomalies]](Begnum & Burgess, 2005)は、37 ホストの本番 [[cfengine]] クラスタで PCA と固有ベクトル中心性の 2 手法を用い、「ホスト間で正常性を統計的有意性をもって比較できるか(=集中型異常検知が分散型より優位か)」を検証した結果、明確な優位性を支持する証拠を見出せなかった。理由として、見かけ上同等なホストでも周辺ユーザー・クライアントとの相互作用が異なるため環境が本質的にノイズを含むこと、共分散が仮定する分布の対称性がリソース制約由来の skew で崩れることを挙げる。これは本ページが 20 年後に整理する「正常は文脈相対」という中心観察([[Minder]] のマシン間類似度、[[RFT-FM]] の Normal-Profile Calibration)の裏返しであり——**Minder 等がマシン間の相対比較を検知の武器として使うのに対し、Begnum & Burgess は同じ発想(ホスト間の相対比較)を試みて統計的な有意性を得られなかった**。この対照は、ホスト間比較が有効になる条件(訓練クラスタのような均質・大規模環境 vs 汎用ネットワークの多様なワークロード)を分ける要因が何かという問いを残す。(Source: [[@2005__Machine Learning__Principle Components and Importance Ranking of Distributed Anomalies]], [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]]) > > - **「異常検知は長期の統計的正常性測定と短期の逸脱シグナルの二段構えが要る」という構図は、2002 年の統計力学的ホスト正常性研究がすでに定量的に立てていた**: [[@2002__TOCS__Measuring System Normality]](Burgess+, ACM TOCS 2002)は、ホストのトランザクション時系列(接続数・プロセス数等)を局所標準偏差でスケーリング変換すると揺らぎの分布が最大エントロピー分布(Planck 分布)に収束することを示す一方、統計的に有意な状態判定には最低でも 1〜2 週間、安定したフィットには最大 2 か月ほどのデータが必要であり、15 分規模の疑似攻撃を挿入してもエントロピー変化は無視できるほど小さく検知不可能だったと定量的に報告する。したがって長期的な「正常」を定義する分布ベースの統計と、短期の侵入・攻撃を捉える手法(時間依存標準偏差 σ(t) とその勾配、あるいはパターンベースの別手法)は原理的に別物であり、二段構えが必要だと結論づける。この構図は、本ページが整理する「常時稼働の検知には LLM が重すぎる」制約への対処として [[Minder]]/[[Pulse]] が採る「秒〜マイクロ秒級の軽量指標で常時検知」路線、および LinkedIn の修正 Z スコア・Alibaba の STL・Booking.com の MAD が採る「軽量統計量で高頻度に判定する」路線と同型の分業を、20 年以上前の統計力学的アプローチがすでに定量実験で裏づけていたことを示す。(Source: [[@2002__TOCS__Measuring System Normality]], [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]], [[@2021__SREcon21__Spike Detection in Alert Correlation at LinkedIn]]) > - **「正常」を定義する分布の形自体が複数サイトで不変になりうるという観察は、Chandola 2009 の「統計ベース手法は分布仮定に依存する」という整理に先立つ実証例である**: Burgess+ 2002 は、日次・週次周期を除去する尺度変換後、地理的に離れた 3 台の WWW サーバーの揺らぎ分布(Planck 分布)の「温度」パラメータが驚くほど近い値を取り、周期と自己相関長の無次元比 P/Λ に支配される不変量である可能性を実測で示した(ログイン型トランザクション対ネットワーク型トランザクションでは温度が約 2 倍異なる)。これは [[Anomaly Detection - A Survey]] が後年整理する「統計ベース手法はデータの分布仮定に強く依存する」という一般論に、「分布の形そのものが環境非依存の不変量になりうる場合がある」という具体的な反例(あるいは精緻化)を与える——分布仮定への依存はリスクである一方、変換次第では分布形が汎化可能な足場になりうる。(Source: [[@2002__TOCS__Measuring System Normality]], [[Anomaly Detection - A Survey]]) > > - **LLM 訓練クラスタの本番異常検知は 2023 年時点で「LOF+KNN Matrix Profile+DTW クラスタリングの多数決」という非 LLM ハイブリッドで実運用に投入されていた**: [[@2023__arXiv__TRANSOM - An Efficient Fault-Tolerant System for Training LLMs]] の TEE は、ランク間統計的一貫性(DTW+KNN)・個別ランクの周期性(KNN Matrix Profile)・タイムスタンプごとの多次元外れ値(LOF)という 3 種の軽量古典手法を組み合わせ、2 つ以上が異常と判定したタスクのみを異常とする多数決アンサンブルで、月次実データの異常タスク 11 件すべてを検知したと報告する。著者らは深層ニューラルネットの解釈性の乏しさとログ量の急変動(平常時は少量、エラー時は大量)というデータ品質の課題を理由に、あえて解釈性の高い古典的統計/機械学習手法を選んだと明記する。これは本ページの中心スレッド「常時稼働の検知には LLM が重すぎる」への 2023 年時点の先行解であり、[[Minder]]・[[Pulse]]・LinkedIn の修正 Z スコア・Alibaba の STL と同じ「検知/denoise の段は軽量統計/ML 手法が産業で選ばれる」という収束的パターンに、LLM 訓練クラスタというドメインから 2023 年の実例を追加する。ただし TRANSOM の TEE は GPU 使用率・ネットワークトラフィックが高いタスクにしか適用できないという適用範囲の限定を著者ら自身が認めており、評価データも正常13件・異常11件と小規模である。(Source: [[@2023__arXiv__TRANSOM - An Efficient Fault-Tolerant System for Training LLMs]], [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]], [[@2021__SREcon21__Spike Detection in Alert Correlation at LinkedIn]]) > - **ソフトウェア性能異常検知でも「AR・Isolation Forest・LSTM-AD・VAE のような軽量な古典/浅い深層モデルが訓練コストを払ってでも最良になる」という産業選好パターンが実験的に再確認された**: [[@2026__ICPE Companion__Leveraging Time Series Foundation Models to Detect Performance Anomalies in Software Systems]] は AIOPS・MSCloud データセットで Chronos・TSPulse をゼロショット評価し、両データセットとも最良性能は訓練済みベースライン(AIOPSはVAE/LSTM-AD、MSCloudはIsolation Forest)であることを示した。これは本ページが繰り返し観察してきた「検知/denoise の段は軽量統計/ML 手法が産業で選ばれる」パターン(LinkedIn の修正 Z スコア・Alibaba の STL・TRANSOM の TEE)を、時系列基盤モデルという最新の選択肢との直接比較で定量的に裏づける新しい実証である。ただし基盤モデルは訓練データ・訓練段階が不要という運用上の利点を持ち、精度で並ぶ場面(MSCloudでのChronos)では総所要時間の観点からゼロショットが有利になりうる——「軽量統計手法が最良」という従来の結論に、「ゼロショット基盤モデルは次点かつ運用コストで代替になりうる」という留保が加わる。(Source: [[@2026__ICPE Companion__Leveraging Time Series Foundation Models to Detect Performance Anomalies in Software Systems]], [[@2023__arXiv__TRANSOM - An Efficient Fault-Tolerant System for Training LLMs]], [[@2021__SREcon21__Spike Detection in Alert Correlation at LinkedIn]]) > > - **STL の「単一季節成分」限界を、複数周期モデルの明示的な逐次分離で解く経路がある**: 本ページが繰り返し参照する Twitter・Meta の STL 利用([[@2026__arXiv__Cloud Performance Decomposition for Long-Term Performance Engineering - A Case Study]] §IX が言及)は、性能回帰検知の前処理として季節性を単一成分として除去するに留まる。同論文は、STL が週次・月次・四半期を単一の季節成分に混在させてしまい、パブリッククラウド特有の非定常性・断続性(signal intermittency)によるモードミキシングに弱いことを実証し、[[時系列分解]] の観点から複数周期を明示的に逐次分離するハイブリッド/EEMD 手法を提案した。異常検知の前処理として季節性除去を行う既存実装(Alibaba の STL 含む)は、この「単一季節成分しか除去できない」限界を共有している可能性があり、複数周期分離が異常検知の偽陽性(季節性の残差を異常と誤検知)を減らせるかは未検証の接続点である。(Source: [[@2026__arXiv__Cloud Performance Decomposition for Long-Term Performance Engineering - A Case Study]]) > - **古典的な差分によるトレンド除去(定常化)を逆転させ、二階差分を判別的シグナルとして明示的に増幅する路線が現れた**: 本ページが整理してきた STL・EEMD ベースの前処理(Alibaba の STL、[[@2026__arXiv__Cloud Performance Decomposition for Long-Term Performance Engineering - A Case Study]] の複数周期分離)はいずれも「季節性・トレンドを除去してから残差を見る」設計である。これに対し [[TFC]]([[@2026__KDD__Rethinking Time Series Anomaly Detection from a Dynamic Perspective - Temporal–Frequency–Curvature Fusion]])は、古典的な時系列モデリングが定常性制約のために差分でトレンド・曲率を除去するのに対し、逆に離散二階差分(曲率 κ_t = (y_{t+1}-2y_t+y_{t-1})/Δt²)を**判別的構造として明示的に強調**する設計を取る。理論的には、二階差分は二階微分を O(Δt²) で近似し(命題2.1)、傾き変化点で局所インパルスを生み(命題2.2)、離散時間フーリエ変換では高周波成分を選択的に増幅するフィルタ H(ω)=-4sin²(ω/2) として振る舞う(命題2.3)。これは Chandola 2009 の3分類(点・文脈・集合異常)や本ページが整理する「pattern anomaly」拡張([[@2015__CSUR__Performance Anomaly Detection and Bottleneck Identification]])が主に値の逸脱を前提にしてきたのに対し、**値そのものでなく「値の曲がり方(二階の力学的シグネチャ)」を新しい観測次元として異常検知に導入する**という、シグナル設計そのものの方向転換である。6ベンチマークで SOTA(強いベースライン比平均 +10.8%)を達成した点は、この方向転換が実証的にも有効であることを示す。(Source: [[@2026__KDD__Rethinking Time Series Anomaly Detection from a Dynamic Perspective - Temporal–Frequency–Curvature Fusion]], [[@2026__arXiv__Cloud Performance Decomposition for Long-Term Performance Engineering - A Case Study]], [[Anomaly Detection - A Survey]]) > - **「平滑化バイアス」が深層 TSAD の共通の弱点として異なる文献から繰り返し指摘されている**: [[TFC]] は、global attention・重い時間集約・周波数領域再構成に依存する既存の深層 TSAD アーキテクチャが、ノイズ抑制と学習安定化のための平滑化(smoothing)によって shapelet 変形やトレンドシフトのような弱い幾何レベルの逸脱まで減衰させてしまうと指摘する。これは本ページが整理する「常時稼働の検知に LLM が重すぎる」制約への対処として非 LLM の軽量統計手法が選ばれる産業パターン(LinkedIn の修正 Z スコア・Alibaba の STL 等)とは異なる軸の課題――**モデルの表現力・平滑化機構自体が検知感度を殺す**――であり、TSFM のゼロショット予測([[@2026__ICPE Companion__Leveraging Time Series Foundation Models to Detect Performance Anomalies in Software Systems]])が示す「訓練済み軽量ベースラインが最良」という産業選好パターンとも接続しうる。曲率という新しい観測量が平滑化に対して頑健なのは、二階差分演算子が高周波成分を選択的に増幅するため(命題2.3)であり、平滑化フィルタとは逆の周波数応答特性を持つことが理論的根拠になっている。(Source: [[@2026__KDD__Rethinking Time Series Anomaly Detection from a Dynamic Perspective - Temporal–Frequency–Curvature Fusion]], [[@2026__ICPE Companion__Leveraging Time Series Foundation Models to Detect Performance Anomalies in Software Systems]]) > > - **メトリクスの異質性(連続利用率 vs 疎なエラーカウンタ)への対処として、メトリクスごとに独立モデルを持つ代わりに単一の共有 MoE を「メトリクス非依存」に運用する設計が現れた**: TSLoc([[@2026__KDD__TSLoc - Self-Supervised Faulty Node Localization Framework in Large-scale Training Clusters]]、KDD 2026)は、各メトリクスストリームを普遍的な時間的過程の独立インスタンスとみなし、LSTM ゲーティング + KAN-AD([[KAN-AD]])エキスパートからなる単一の共有 Mixture-of-Experts エンコーダに通す。これは本ページが繰り返し観察する「メトリクスごとに個別モデル(one-metric-one-model)」対「全メトリクス共通1モデル(all-metrics-one-model)」という二分法に対し、共有パラメータ内でゲーティングにより両者の利点(共有パターンとメトリクス固有パターンの両方の学習)を両立する第三の道を示す。オフライン訓練時のみ用いる再構成デコーダを推論時に完全に破棄し埋め込みのみをフィンガープリントとして使う設計は、[[時系列基盤モデル]]のゼロショット予測とも異なる、タスク特化型の教師なし表現学習の一例である。(Source: [[@2026__KDD__TSLoc - Self-Supervised Faulty Node Localization Framework in Large-scale Training Clusters]]) > - **異種メトリクス間で外れ値スコアを統合する際、生の距離や z-score 正規化より「順位の逆数(reciprocal rank)」の和が頑健であることが定量的に確認された**: TSLoc は、埋め込み距離をそのまま合算する DirectSum(Acc@5=0.7959)・正規化後合算する NormSum(Acc@5=0.7142)がいずれも 1/rank 集約(Acc@5=0.9082)に劣ると報告する。これは「メトリクスごとにスケールが大きく異なる外れ値スコアをどう統合するか」という異常検知の集約問題に対し、スケール不変な順位ベース集約が有効であるという具体的なアブレーション結果を与える。(Source: [[@2026__KDD__TSLoc - Self-Supervised Faulty Node Localization Framework in Large-scale Training Clusters]] §5.4) > > - **イベントデータ(アクター・操作・リソース・時刻)は、メトリクス・ログとは異なる第3のシグナル源として、検知精度と解釈可能性を同時に得られることを 520 件の実インシデント分析が定量的に示した**: 本ページが整理してきた異常検知手法(統計手法・深層学習・時系列基盤モデル)は主にメトリクスやログを入力とするが、[[@2026__ACM FSE__EventADL - Open-Box Anomaly Detection and Localization Framework for Events in Cloud-Based Service Systems|EventADL]](Pham+, ACM FSE 2026)は AWS CloudTrail 等のクラウド監査イベントを対象に、520件の実インシデント分析から「異常は Event Type(21%)・Event Value(68%)・Event Frequency(67%)の3次元に現れる」という知見を得た上で、ルールベースの Event Semantic Pattern(ESP、jsonLogic 式による意味パターン)と統計的な Event Frequency Pattern(EFP、Matrix Profile の大きさ重視版)という2つの解釈可能なパターンで異常を検知する。深層学習ベース手法(DeepSVDD・DIF・ICL・RCA)が「訓練データがクリーン」という仮定に依存し頑健性を欠くのに対し、EventADL は分布非依存の仮説検定によりノイズを含む訓練データにも頑健(§5.9.2)で、かつ決定論的(標準偏差=0)な結果を返す。これは本ページが繰り返し観察する「常時稼働の検知には LLM/深層学習が重すぎる」制約への回答を、メトリクス・ログとは異なる第3のシグナル源(構造化イベント)とルールベース設計の組み合わせで示した新しい実証例である。(Source: [[@2026__ACM FSE__EventADL - Open-Box Anomaly Detection and Localization Framework for Events in Cloud-Based Service Systems]]) > - **Matrix Profile の「形状(shape)重視」設計は、離散イベント頻度時系列には不適合であり、大きさ(magnitude)重視の再設計で 9 倍の高速化と大幅な精度向上が得られる**: 本ページが整理する統計/軽量手法群(LinkedIn の修正 Z スコア、Alibaba の STL 等)とは異なる系譜として、EventADL の EFP は Matrix Profile を初めて離散イベント時系列へ適応させた。Matrix Profile 本来の形状ベース部分列比較は「1〜3 rps の既知パターンが 5 rps でも正常に見えるが 100 rps への急上昇は明確に異常」という magnitude(大きさ)の逸脱を捉え損ねる。EventADL がユークリッド距離による直接比較に置き換えたところ、OUT データセットで F1 スコア 0.741(shape-based は 0.155)、ランタイムは 74.98ms(shape-based は 664.08ms、9倍高速)を達成した(§5.8.2)。これは、時系列異常検知手法の「形状か大きさか」という設計選択が、対象データの性質(連続値信号 vs 離散イベントカウント)に強く依存することを示す具体的な定量比較であり、[[TFC]] が指摘する「値そのものでなく値の曲がり方(曲率)を見る」という別の設計転換とも並ぶ、シグナル設計そのものの見直しの一例である。(Source: [[@2026__ACM FSE__EventADL - Open-Box Anomaly Detection and Localization Framework for Events in Cloud-Based Service Systems]], [[@2026__KDD__Rethinking Time Series Anomaly Detection from a Dynamic Perspective - Temporal–Frequency–Curvature Fusion]]) > > - **異常検知の「信頼性」は検知精度だけでなく、公平性・ロバスト性・説明可能性・効率性という4つの独立した技術的要件に分解できる**: [[Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications]](Xin+, ACM Comput. Surv. 2025)は、性能異常検知の信頼性要件を4つに整理する——公平性はコスト考慮学習(誤分類コストの非対称設定)で不均衡データへの偏りに対処し、ロバスト性は頑健表現学習(OmniAnomaly の再構成確率)・アンサンブル学習・敵対的防御(APAE・PLS)の3系統で達成され、説明可能性は interpretable-by-design(決定木・KNN・ARIMA)と post-hoc(LIME・SHAP・Integrated Gradients)の2系統に分かれ、効率性はモデル枝刈り(KNN の近傍数削減、IForest の木の数・深さ削減、深層学習の訓練前/訓練中/訓練後の3タイミングでの枝刈り)で達成される。本ページが蓄積してきた検知手法(TFC の曲率視点、EventADL の EFP、TSLoc の共有 MoE 等)は主に検知精度・頑健性を軸に評価されているが、これらの手法がコスト考慮学習・post-hoc 説明・枝刈りにどこまで対応済みかは個別には未整理であり、本サーベイの4分類は既存手法群を「信頼性のどの軸をまだ満たしていないか」で棚卸しする横断的な物差しを与える。(Source: [[Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications]]) > - **正規化の効果は「形状か大きさか」だけでなく「非正規化が既定として優れる」という具体的な回答が、40データセット規模の統計的検証で得られた**: [[@2026__ACM FSE__EventADL - Open-Box Anomaly Detection and Localization Framework for Events in Cloud-Based Service Systems|EventADL]]が示した「形状(shape)か大きさ(magnitude)か」というMatrix Profileの設計軸に対し、[[@2026__SIGMOD__HYDRA - A Multi-Level Hierarchy-Driven Approach for Robust Anomaly Detection in Time Series|HYDRA]](Huang+, SIGMOD 2026)は別の軸として、z-score・Min-Max・Unit-lengthのいずれの正規化も振幅駆動型異常(スパイク)の判別信号を圧縮しうることを示し、TSB-ADベンチマーク40データセット上でHYDRA自身を含む複数ベースライン(KMeansAD・Matrix Profile・Sub-KNN・NormA・Sub-PCA)すべてで「非正規化(No-Norm)」がVUS-PR中央値最高という一貫した傾向を、統計的有意性(Friedman+Nemenyi, α=0.05)とともに実証した。これは本ページが繰り返し観察する「常時稼働の検知には軽量な古典手法が選ばれる」という産業的知見に、「その古典手法の前処理(正規化)自体も既定を疑うべきである」という具体的な設計指針を加える。(Source: [[@2026__ACM FSE__EventADL - Open-Box Anomaly Detection and Localization Framework for Events in Cloud-Based Service Systems]], [[@2026__SIGMOD__HYDRA - A Multi-Level Hierarchy-Driven Approach for Robust Anomaly Detection in Time Series]] §5.4) > - **Matrix Profileの「1-NN距離ベースdiscord」設計が持つ「繰り返し異常(twin-freak)」という弱点が、HYDRAの階層的定式化により初めて構造的に説明された**: [[@2023__arXiv__TRANSOM - An Efficient Fault-Tolerant System for Training LLMs|TRANSOM]]のTEEはKNN Matrix Profileを解釈可能性ゆえに3手法の1つとして採用したが、[[@2026__SIGMOD__HYDRA - A Multi-Level Hierarchy-Driven Approach for Robust Anomaly Detection in Time Series|HYDRA]]は、類似した異常同士が互いの最近傍になり距離が縮小して検知を逃す「twin-freak問題」を定式化し(§3.2.1)、これがTSB-AD上のmultiple_duplicate(繰り返し異常)データセット群での具体的な精度劣化として現れることを実証した(Fig. 10b)。TRANSOMのように複数の古典手法を多数決で組み合わせる設計はこの種の単一手法の系統的弱点を経験的に緩和する一方、HYDRAは代表選抜を階層的に純化するという設計変更でtwin-freak問題そのものを構造的に解消する点で異なるアプローチを取る。同様に、クラスタリングベース(NormA・KMeansAD)がセントロイドという単一の集約点への依存ゆえに異常集中でクラスタごと汚染される弱点も、HYDRAは「代表ウィンドウ集合への参照距離」という第三の固定点と階層的純化で回避する(§4.3)。(Source: [[@2023__arXiv__TRANSOM - An Efficient Fault-Tolerant System for Training LLMs]], [[@2026__SIGMOD__HYDRA - A Multi-Level Hierarchy-Driven Approach for Robust Anomaly Detection in Time Series]] §3.2.1, §4.3, Fig. 10) > - **Chandola 2009 は「異常検知」をノイズ除去・ノイズ許容・ノベルティ検知という隣接分野から明示的に切り分け、かつサーベイ自身の技法比較を「カテゴリごとの仮定の名指し」という記述様式で行うと第1章で宣言する**: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 1 Introduction]](§1.1)は、ノイズ除去(分析前に不要な対象を除去)・ノイズ許容(統計モデル推定を異常観測から免疫化する[Huber 1974])・ノベルティ検知(検出後に正常モデルへ組み込まれる新規パターンが対象)を異常検知と概念的に区別しつつ、これら関連問題の解法はしばしば異常検知に流用されると述べる。この定義的厳密さは、『SREの探求』第18章がノイズ低減と外れ値特定を単一の理論的定義なしに並列の運用課題として挙げる姿勢(本ページ既出)と対照的である。さらに Chandola et al. は「本サーベイの貢献」(§1.4)として、6つの技法カテゴリ(分類・クラスタリング・近傍・統計・情報理論・スペクトル)それぞれについて「正常/異常を区別するために技法が置く仮定」を明示し、基本技法を1つ定めて既存手法をその変種として説明するという記述様式そのものを方法論として宣言する。本ページが技法カテゴリを「どのような仮定に依存するか」で比較して積み上げてきた既存の横断的知見(前掲)は、Chandola et al. が §1.4 で自ら述べるこの記述様式を踏襲したものである。(Source: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 1 Introduction]] §1.1, §1.4, [[@2021__OReillyJapan__SREの探求 - Chapter 18 SREのための機械学習入門]] §18.2.1) > - **「大量データ+偽陽性への不寛容」という制約は、応用ドメインの性質であって技法の性質ではない**: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 3 Applications of Anomaly Detection]](§3.1)は、侵入検知が大量の入力データ(数百万件)を扱うため「数%の偽陽性でも分析者を圧倒する」という制約を明示し、これが正常ラベルのみを使う半教師あり/教師なし技法の選好につながると述べる。この「データ量が偽陽性への不寛容を生む」という構図は、2009年当時の侵入検知に限らず、本ページが記録する現代クラウド運用ドメインの観測([[TelecomTS]] の適合率 0.17–0.26 という偽陽性バイアス、[[MonitorAssistant]] の「統計的外れ値の一部は業務上無関係」という practical anomaly 定義)にそのまま再現している。応用ドメインが変わっても「データ量に比例して偽陽性のコストが増す」という制約自体は不変であり、Chandola 2009 の応用章はこの制約が技法選択(半教師あり優先・教師なし優先)を規定する最初期の体系的整理として読める。(Source: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 3 Applications of Anomaly Detection]] §3.1, [[@2026__ICML__TelecomTS - A Multi-Modal Observability Dataset for Time Series and Language Analysis]], [[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]]) > - **「正常を決める文脈」の設計自体が応用ドメイン固有の知識を要するという観察は、侵入検知・不正検知からクラウド運用・訓練クラスタまで一貫する**: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 3 Applications of Anomaly Detection]](§3.2.1)は、クレジットカード不正検知における文脈異常の「文脈」が by-owner(ユーザ単位のプロファイル)か by-operation(地理的位置単位のプロファイル)かで検知対象・コストが変わると述べ、文脈設計それ自体がドメイン知識を要する意思決定であることを示す。この観察は本ページが集積してきた「正常は文脈相対」というスレッド——[[Minder]] のマシン間類似度(文脈=同一ジョブの他マシン)、Alibaba のビジネストレンド検知(文脈=時間セグメント×トレンド)、[[RFT-FM]] の Normal-Profile Calibration(文脈=訓練ダイナミクスの健全プロファイル)——の**文脈をどう定義するか自体が応用ドメインごとに異なる設計問題である**という一段抽象的な形での先行例にあたる。Chandola 2009 の応用章は、この「文脈の定義はアルゴリズムでなくドメイン知識の産物である」という論点を侵入検知・不正検知の初期の事例で示した。(Source: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 3 Applications of Anomaly Detection]] §3.2.1, [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]], [[@2017__SREcon17 Asia__Smart Monitoring System for Anomaly Detection on Business Trends in Alibaba]], [[@2026__arXiv__Towards Robust LLM Post-Training - Automatic Failure Management for Reinforcement Fine-Tuning]]) > > - **産業事例の「正常は文脈相対」設計は、Chandola 2009 が定式化した「還元」と「構造利用」の2アプローチのいずれかに機械的に対応づけられる**: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 10 Handling Contextual Anomalies]] は、文脈異常検知を(1) 文脈を特定してから既知の点異常検知技法を適用する還元(reduction to point anomaly detection)と、(2) 文脈から期待挙動を予測するモデルを学習する構造利用(utilizing the structure in data)の2カテゴリに分ける(§10.1, §10.2)。本ページで蓄積してきた「正常は文脈相対」の産業実装をこの軸に当てはめると、Alibaba のビジネストレンドごとの N-シグマ則調整([[@2017__SREcon17 Asia__Smart Monitoring System for Anomaly Detection on Business Trends in Alibaba]])と Minder のマシン間類似度比較([[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]])は「文脈(ビジネストレンド/マシン群)ごとに正常データを切り出し、その中で統計的外れ値検知を適用する」という**還元**の系譜に属する一方、Alibaba の STL 時系列分解や Scott 2001/Ihler et al. 2006 型のポアソン過程+マルコフ遷移モデルは「文脈から期待挙動を予測するモデルを学習し、そこからの乖離を測る」という**構造利用**の系譜に属する。Chandola 2009 が指摘する両者の計算量トレードオフ(還元は訓練が速く検証が高コスト、構造利用は訓練が高コストで検証が高速)は、Minder のような常時稼働システムがなぜ還元寄りの軽量比較(マシン間類似度)を選ぶかを説明する一つの理論的根拠になりうる。(Source: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 10 Handling Contextual Anomalies]] §10.1, §10.2, [[@2017__SREcon17 Asia__Smart Monitoring System for Anomaly Detection on Business Trends in Alibaba]], [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]]) > - **技法カテゴリごとに「置いている仮定」が異なり、それが適用可能な状況を決める——分類ベースの仮定はラベルの可用性である**: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 4 Classification Based Anomaly Detection Techniques]] は、分類ベース異常検知が「正常クラスと異常クラスを区別できる分類器が、与えられた特徴空間上で学習可能である」という仮定に依拠すると明示する(§4 Assumption)。この仮定は多クラス設定では「複数の正常クラスについて正確なラベルが利用可能であること」という強い前提に具体化され、章が明示する欠点(1)「正確なラベルの取得が難しいことが多い」がこの仮定の破れそのものを指す。したがって分類ベース技法は、ラベル付き訓練データが豊富に得られる応用(侵入検知の既知攻撃分類、疾病アウトブレイクの既知パターン分類など)には適するが、正常挙動が未知・変化するドメイン(新規サービス追加が頻発するマイクロサービス環境、ラベルを人手で用意できない大規模訓練クラスタ監視)では前提から外れる。本ページが既に記録する「Chandola 2009 の『異常の型』と『技法の仮定』は後続 AIOps 異常検知を読むための基礎層である」という観察の具体化として、分類ベースの仮定=ラベル可用性を最初のカテゴリとして立てる。近傍ベース(距離尺度)・クラスタリングベース・統計ベース(分布仮定)・情報理論ベース・スペクトルベースそれぞれの仮定は、対応する章の担当が同じ軸で積み増す。(Source: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 4 Classification Based Anomaly Detection Techniques]] §4) > - **近傍ベースの仮定は「近さ」そのものであり、ラベル可用性という分類ベースの仮定と直交する**: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 5 Nearest Neighbor-Based Anomaly Detection Techniques]] は、最近傍ベース異常検知が「正常インスタンスは密な近傍に存在し、異常インスタンスの近傍は疎である」という仮定に依拠すると明示する(§5 Assumption)。分類ベースの仮定(ラベルで正常/異常を区別できる分類器が学習可能)がラベルという教師情報の可用性に依存するのに対し、近傍ベースの仮定は意味のある距離・類似度尺度の存在にのみ依存し、ラベルを一切要求しない——両者は「何が入手困難になると仮定が破れるか」という軸で対照的である。近傍ベースの仮定が破れる状況は2種類ある。(1) 正常データ自身が疎な領域を含む場合(章の Figure 7 の例——低密度クラスタ C1 の正常インスタンス q は、高密度クラスタ C2 の異常インスタンス p2 より最近傍距離が大きくなり、大域的な k 番目近傍距離ベースの基本技法は q と p2 を取り違える)。(2) 高次元空間で距離尺度の意味が希薄化する場合(本 wiki の [[最近傍法]] が整理する「次元の呪い」——サンプリング密度が $N^{1/p}$ に比例して低下し、近傍が「伸びる」——と同型の破れであり、Chandola 2009 が §5.2 末尾で明示する O(N^2) の計算量制約とは別に、次元数の増加そのものが仮定の妥当性を掘り崩す)。相対密度ベース技法(LOF)は(1)の破れを、局所密度の比という設計で局所化して緩和する一方、(2)の破れには対処しない。(Source: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 5 Nearest Neighbor-Based Anomaly Detection Techniques]] §5, §5.1, §5.2, [[最近傍法]]) > - **クラスタリングベースだけが単一の仮定でなく3つの仮定に分かれ、各仮定は前の仮定の破れへの対処として順に導入される**: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 6 Clustering-Based Anomaly Detection Techniques]] は、分類ベース(ラベル可用性)・近傍ベース(近さ)がそれぞれ単一の仮定を置くのと異なり、クラスタリングベース技法を(1)「正常はクラスタに属し、異常はどのクラスタにも属さない」(2)「正常は最近傍クラスタ重心に近く、異常は遠い」(3)「正常は大きく密なクラスタに属し、異常は小さいか疎なクラスタに属する」という3つの仮定に分ける(§6)。破れる状況も仮定ごとに異なる:(1)は基盤とするクラスタリングアルゴリズムの主目的があくまでクラスタ発見であり異常発見に最適化されていない点で技法として弱く、(2)は異常自身がクラスタを形成する場合に検知できず、(3)はこの(2)の弱点そのものへの対処として導入される(クラスタのサイズ・密度という閾値で(2)が見逃す「異常のクラスタ」を捉える)。分類ベース・近傍ベースが「仮定が破れたら技法が機能しない」という単純な構造を持つのに対し、クラスタリングベースは「後続の仮定が前の仮定の破れを吸収する」という自己修正的な構造を持つ点が、本ページの仮定比較スレッドに新たに加わる観察である。さらに本章は「クラスタリングと異常検知は目的が根本的に異なる」ことを明示する——クラスタリングアルゴリズムの評価基準はクラスタの発見(質)であり、異常の発見はその副産物にすぎない。これは近傍ベース(第5章)が距離尺度という単一の仮定を異常スコアに直結させるのと対照的で、クラスタリングベースが構造的に「転用」の性質を持つことを示す。統計ベース・情報理論ベース・スペクトルベースそれぞれの仮定は、対応する章の担当が同じ軸で積み増す。(Source: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 6 Clustering-Based Anomaly Detection Techniques]] §6) > - **統計ベースの仮定は「正常インスタンスは確率モデルの高確率領域に、異常は低確率領域に生じる」であり、分類・近傍・クラスタリングベースが「データ間の関係性」(ラベル・近さ・クラスタ構造)に依存する仮定を置くのに対し、「データの生成過程」そのものに依存する仮定である**: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 7 Statistical Anomaly Detection Techniques]] は、統計ベース異常検知が「正常データは確率モデルの高確率領域に、異常は低確率領域に生じる」という仮定に依拠すると明示する(§7 Assumption)。分類ベース(ラベル可用性)・近傍ベース(近さ)・クラスタリングベース(クラスタ構造)がいずれも教師情報や距離・グループといったインスタンス間の関係性に依存するのに対し、統計ベースの仮定は個々のインスタンスを生成する確率分布という生成過程そのものに依存する点で異質である——「低密度な場所が異常」という発想自体は近傍ベース(局所的な近傍密度)と共有するが、近傍ベースが経験的な距離でこれを近似するのに対し、統計ベースは明示的な確率モデルで表現する。仮定が破れる状況は技法の細分ごとに異なる。パラメトリック技法では、仮定した分布(ガウス等)が実データの真の分布と一致しない場合に破れる(章が明示する欠点(1)「高次元の実データセットではしばしば成立しない」)。仮定が妥当な場合でも、複数の仮説検定統計量のうち最良のものを選ぶことが自明でない(欠点(2))。ノンパラメトリック技法(ヒストグラム・カーネル関数)は分布の知識を仮定しない分だけこの破れを回避するが、ヒストグラムベースは属性間の相互作用を捉えられないという別種の限界を持つ(欠点(3))。情報理論ベース・スペクトルベースそれぞれの仮定は、対応する章の担当が同じ軸で積み増す。(Source: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 7 Statistical Anomaly Detection Techniques]] §7, §7末尾) > - **情報理論ベースの仮定は「異常はデータの情報量に不規則性をもたらす」、スペクトルベースの仮定は「正常/異常が顕著に異なって現れる低次元部分空間へ埋め込める」であり、両者は分類・近傍・クラスタリング・統計ベースのいずれとも異なる軸で仮定を置く最後の2カテゴリである**: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 8 Information Theoretic Anomaly Detection Techniques]] は情報理論ベース異常検知が「異常はデータ集合の情報量に不規則性をもたらす」という仮定に依拠すると明示し(§8 Assumption)、[[@2009__CSUR__Anomaly Detection - A Survey - Chapter 9 Spectral Anomaly Detection Techniques]] はスペクトルベース異常検知が「データは正常/異常が顕著に異なって現れる低次元部分空間へ埋め込める」という仮定に依拠すると明示する(§9 Assumption)。これまでの4カテゴリ——分類(ラベル可用性)・近傍(近さ)・クラスタリング(3段階のクラスタ構造)・統計(確率モデルの生成過程)——がいずれも個々のインスタンスやインスタンス間の関係性に着目するのに対し、情報理論ベースはデータ集合**全体**の複雑性という集合レベルの量に着目し、スペクトルベースはデータの**表現(座標系)そのものの変換**に着目する点で、双方とも「個々のインスタンスを直接評価しない」という共通の性質を持つ。両者の違いは、情報理論ベースが複雑性という単一のスカラー量の増減で異常を判定するのに対し、スペクトルベースは低次元部分空間という多次元の表現へ変換したうえで、その空間内での位置(射影値・距離)を異常スコアとする点にある。なお情報理論ベースの仮定の破れ(「多くの場合、大量の異常が存在しないと検知できない」)とスペクトルベースの仮定の破れ(「正常/異常が低次元埋め込みで分離可能な場合にのみ有効」)は、どちらも「少数の異常では検知に必要な統計的・幾何学的な偏りが集合全体・部分空間全体に十分現れない」という共通の弱点に帰着し、分類・近傍・クラスタリング・統計ベースが個別インスタンスの仮定の破れを議論するのとは異なる粒度の脆さを持つ。これで技法カテゴリごとの仮定比較(分類・近傍・クラスタリング・統計・情報理論・スペクトルの6カテゴリ)が出そろった。(Source: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 8 Information Theoretic Anomaly Detection Techniques]] §8, [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 9 Spectral Anomaly Detection Techniques]] §9) > - **サーベイ自身が最後に置く横断比較の軸は「仮定の文言」ではなく、計算量(訓練/検証コスト)・ラベル要求・距離尺度への依存・異常の希少性仮定の4軸である——第4章が立てた「仮定を同じ形式で並べる」という問いに対し、サーベイ本体はそれを完遂しない**: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 11 Relative Strengths and Weaknesses of Anomaly Detection Techniques]] は、第4〜9章が積み上げた「カテゴリごとの仮定」を並べた統一表を作らない。代わりに、分類・クラスタリング・統計ベースは訓練が高コストで検証が高速、近傍・情報理論・スペクトルベースは訓練フェーズを持たず検証が高コスト、という計算量の二分法を横断比較の主軸に据える(§11、原本PDF p.43冒頭)。ラベル要求の軸では、分類ベースが正常・異常両方のラベルを要求し(取得困難・クラス不均衡が課題)、近傍・クラスタリングベースは正常ラベルのみで半教師あり運用が可能で分類ベースより有効になりうると明示する一方、情報理論ベース・スペクトルベースのラベル要求は本章に明記がない——これは第4章の問いが期待した「6カテゴリを同一形式で並べる」網羅性に対する明確な欠落である。距離尺度への依存(近傍・クラスタリングベースの弱点、有効な距離尺度が特定しづらい場面では分類・統計ベースの方が良い選択になりうる)、異常の希少性という共通仮定とその破れ(コンピュータワーム検知のようにワームトラフィックが正常トラフィックより高頻度になるバルク異常には教師あり・半教師あり技法が必要)も同じ横断比較に含まれる。したがって第4章の問いへの答えは「サーベイは仮定の統一表ではなく、計算量・ラベル要求・希少性仮定という運用指向の軸で比較する」であり、仮定そのものの網羅的な突き合わせ(第4〜9章担当が積み上げた6カテゴリの仮定比較)は本ページ側の観察が担っている。(Source: [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 11 Relative Strengths and Weaknesses of Anomaly Detection Techniques]] §11) > - **Notaro 2021 は障害検知を「運用タスクの分解」で切り、Chandola 2009 は「手法が置く仮定」で切る——両者は直交する軸である**: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.3 Failure Detection]] は failure detection を異常検知・ITC(Internet Traffic Classification)・log enhancement の3運用タスクに分解し、さらに異常検知内部をデータソース(KPI単変量/多変量・ログ・トレース・その他)×アルゴリズム(TAN・Random Forest・Autoencoder・FSM・RNN・PCA・Clustering/PCFG・Causal Inference・SVM等)の2軸で整理する(Table 6)。これは本ページが Chandola 2009 から積み上げてきた「技法カテゴリが置く仮定(ラベル可用性・近さ・クラスタ構造・分布仮定等)」という軸とは切り口が異なる——Notaro の軸は「どのデータが手元にあり、どのアルゴリズムを選ぶか」という運用者視点の意思決定表であるのに対し、Chandola の軸は「その手法がいつ機能しなくなるか」という理論的な脆弱性の分析である。両者を重ねると、たとえば FSM(Fu et al./CSight)は Table 6 では「RCA を可能にする/テンプレート発見ステップが必要」という運用上の長短で語られるが、Chandola の枠組みでは近傍ベース・分類ベースいずれとも異なる系列パターンマッチングという第3の仮定系統に位置づく——本ページはこの系列パターンマッチング系の仮定をまだ独立カテゴリとして整理していない。(Source: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.3 Failure Detection]], [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 4 Classification Based Anomaly Detection Techniques]]) > - **USAD の「精度を維持しつつ訓練コストを1/547に削減」という選択は、本ページが繰り返し観察する「検知/denoise の段は軽量手法が産業で選ばれる」収束パターンの学術側の先行例である**: USAD [7](Notaro 2021 §4.3.1、[[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.3 Failure Detection]])は、OmniAnomaly と同等の F1=0.791 を保ったまま敵対的学習ベースのオートエンコーダで訓練時間を平均547倍削減したと報告される。これは本ページが LinkedIn の修正 Z スコア・Alibaba の STL・TRANSOM の TEE・LLMPrism の k-σ 則で確認してきた「検知精度を維持しつつ計算コストを削る」という産業選好パターンと同型で、USAD の場合は「訓練コスト」という異なるコスト軸(推論レイテンシでなく再学習頻度)でこのパターンを実証する。異常検知研究の評価軸が精度一辺倒からコスト効率へ広がりつつあることを、2021年時点の学術サーベイがすでに定量的に記録していたことになる。(Source: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.3 Failure Detection]], [[@2023__arXiv__TRANSOM - An Efficient Fault-Tolerant System for Training LLMs]], [[@2025__DSN__LLMPrism - Black-box Performance Diagnosis for Production LLM Training Platforms]]) > - **Chandola 2009 の「手法の仮定」軸と Soldani & Brogi 2021 の「データ源とセットアップコスト」軸は直交し、同じ M class(監視ベース)の内部にも粒度の分岐が入れ子になっている**: Chandola 2009 は技法群を、ラベル可用性(分類ベース)・距離尺度(近傍/クラスタリング)・分布仮定(統計)・情報量尺度(情報理論)・低次元分離可能性(スペクトル)という「データに対する統計的仮定」で分ける(§2.3, §4–9)。これに対し Soldani & Brogi 2021 の Table 1(§3.4.1)は、25 手法を class(ログ/分散トレーシング/監視)×method(教師なし学習・教師あり学習・トレース比較・SLOチェック・ハートビート)で分け、型・粒度(A=アプリ全体/S=サービス)・必要 artifact をセットアップコストの代理指標として整理する——これは「どんな統計的性質を仮定するか」ではなく「何を配備・計装しなければ動かないか」という運用上の軸であり、Chandola の軸とは問うている問題が異なる。さらに、監視ベース(M class)の内部でも同じ入れ子の分岐が起きる: SLO チェック(CauseInfer・MicroScope・ε-diagnosis)とハートビート(M-MFSA-HDA)は機械学習を一切使わず、SLO チェックはアプリケーション全体粒度(A)にとどまるのに対し、教師なし/教師あり学習を使う監視ベース手法(Gulenko et al.・LOUD・MicroRCA・Wu et al.・DLA・Hora・ADS・PreMiSE)の大半はサービスレベル粒度(S)に達する(Table 1)。つまり「データ源が粒度を決める」という一段目の軸の下に、「同じデータ源でも method(学習を使うか否か)が粒度を左右する」という二段目の軸が入れ子になっており、Chandola の仮定軸では捉えられない運用固有の階層構造である。(Source: [[Anomaly Detection - A Survey]], [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey - Chapter 3.4 Discussion (Anomaly Detection)]]) > - **Soldani & Brogi 2021 は手法間の定量的な精度比較を明示的にサーベイの範囲外とするが、5 年後の Barata 2026 はデータセット・障害注入が揃わないまま平均精度を提示しており、両者の間に方法論的な後退がある**: Soldani & Brogi 2021(§3.4.3)は、与えられたアプリケーション・文脈における各手法の精度を定量的に比較する研究があればサーベイを補完できると述べつつ、そのような比較は「サーベイの範囲外であり将来の研究方向」と明言し、あえて数値による手法間比較を行わない。これに対し [[Anomaly detection and root-cause identification in microservices]](Barata et al. 2026)は本ページが既に記録した通り、「統計手法の accuracy 99.2%」「トレース比較の recall 99.0% / F1 98.2%」のように手法群の平均性能を提示するが、対象データセット・故障種別・評価指標が手法間で揃っていない(§4.7)。Soldani & Brogi が「比較不能」と判断して明示的に保留した数値比較を、Barata 2026 は保留せず提示してしまっており、5 年間でサーベイの方法論的な厳密さがむしろ後退した可能性を示唆する。この対比は、[[@2009__CSUR__Anomaly Detection - A Survey - Chapter 11 Relative Strengths and Weaknesses of Anomaly Detection Techniques]] が技法群の強み・弱みを定性的にしか論じない(定量比較を試みない)姿勢とも整合し、「仮定・評価環境が異なる技法群を数値だけで比較することの危うさ」を古典サーベイと 2021 年サーベイの双方が共有していたことを示す。(Source: [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey - Chapter 3.4 Discussion (Anomaly Detection)]], [[Anomaly detection and root-cause identification in microservices]], [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 11 Relative Strengths and Weaknesses of Anomaly Detection Techniques]]) > - **Barata 2026 の検知アルゴリズム分類(教師なし/教師あり/強化学習/トレース比較/統計分析の5分類)は、本ページが Chandola 2009 から積み上げてきた「手法が置く統計的仮定」の軸とも、Soldani & Brogi 2021 の「データ源×学習方式」の軸とも異なる第三の切り口であり、強化学習という独立カテゴリを立てる点で他の2軸にない粒度を持つ**: [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey - Chapter 4.3 Methods to identify anomalies in microservices]](§4.3)は、マイクロサービス異常検知の検知アルゴリズムを教師なし学習(§4.3.1、本節言及手法約24件)・教師あり学習(半教師あり含む、§4.3.2、約16件)・強化学習(§4.3.3、1件のみ)・トレース比較(§4.3.4、約10件)・統計分析(§4.3.5、約13件)の5分類に整理する。Chandola 2009 の6技法カテゴリ(分類・近傍・クラスタリング・統計・情報理論・スペクトル)がデータに対する統計的仮定を軸に取るのに対し、Barata 2026 の5分類は「ラベルの有無」(教師なし/教師あり)と「対象データの性質」(トレース比較)、さらに「学習パラダイム」(強化学習)を混在させた運用寄りの分類であり、Soldani & Brogi 2021 の class×method 2軸表(本ページ既出)とも異なる第三の切り口である。特筆すべきは強化学習を独立カテゴリとして立てながら言及手法が1件(Belhadi et al. のマルチエージェント枠組み)のみという極端な非対称性であり、これは Chandola 2009・Soldani & Brogi 2021 のいずれの分類にも存在しない「強化学習」という軸が、2026年時点でもなお実証研究の蓄積が薄い新興カテゴリであることを示す。(Source: [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey - Chapter 4.3 Methods to identify anomalies in microservices]], [[Anomaly Detection - A Survey]], [[Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications]]) > > > [!contradiction] 採択論文の総数が本ページの既存記述(117件)と第4.3章担当分の§4.1本文(143件)で食い違う。§4.1は「7初期クエリで10485件→重複除去等で837件→スクリーニングで306件→本文確認で171件→包含基準適用で143件(PRISMA直接141件+他手法2件)」という段階的フィルタと、Figure 4の出版年別内訳(1+6+11+17+27+18+25+36+2=143)の両方で143件を裏づける。本ページの「117件に拡張」という既存記述がどの章のどの数値に基づくか([[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey - Chapter 4.7 Methods comparison]]等、Table 5/6実収載数の可能性)は本ページ担当範囲(§4.2・§4.3)からは確認できず、担当章(§4.7等)側での裏取りを要する。(Source: [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey - Chapter 4.1 Anomaly detection in a microservices environment - Overview]] §4.1.4, Fig. 4) > > - **説明可能性は Chandola 2009 の分類軸には存在しない観点で、Soldani & Brogi 2021 が 2021 年時点で「未解決課題」と明言してから 4 年後の Trustworthy AI レビューでようやく形式的要件として定式化された**: Chandola 2009 の技法比較軸(§2.3, §4–9)はラベル可用性・距離尺度・分布仮定など「異常をどう検知するか」にのみ向けられ、「なぜ異常と判定したかを説明できるか」という observability 側の要件を扱わない。Soldani & Brogi 2021(§3.4.4)は、異常検知の大半が機械学習ベースである以上これは explainable AI の問題と不可分であり、説明があればオペレータは偽陽性を直接除外したり根本原因を調査したり対処策を設計できると指摘しつつ、これを「現在も未解決の課題」と明言する。本ページが既に記録する [[Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications]] は、信頼性を公平性・ロバスト性・説明可能性・効率性の 4 要件に分解し、説明可能性を post-hoc 手法(SHAP/LIME 相当)で満たすべき明示的な技術要件として定式化する。つまり、2009 年の古典サーベイには存在しなかった説明可能性という観点が、2021 年のマイクロサービス異常検知サーベイでは「未解決課題」として言語化され、2025 年のレビューでようやく検証可能な要件へ形式化された——この 16 年間の変遷は、異常検知研究の関心が「何が異常か」の判定精度から「なぜ異常なのか」の説明責任へ広がってきたことを示す。(Source: [[Anomaly Detection - A Survey]], [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey - Chapter 3.4 Discussion (Anomaly Detection)]], [[Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications]]) > - **説明可能性が「技術的要件」の1つとして数えられるのは、EU の7つの主要要件のうち Transparency(透明性)がその由来だからであり、同じく非技術的側面を持つ Human agency and oversight や Accountability とは選別の理由が異なる**: [[@2025__ACMCSUR__Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications - A Review - Chapter 2 Trustworthiness Requirements and Performance Diagnosis Systems]](§2.1)は、EU AI HLEG の7要件(データガバナンス、多様性・非差別・公平性、技術的頑健性・安全性、透明性、人間の主体性と監督、社会的・環境的幸福、説明責任)のうち、透明性から説明可能性を、データガバナンスからデータプライバシーを、多様性・非差別・公平性から公平性を、技術的頑健性・安全性から頑健性を、それぞれ技術的要件として直接抽出する一方、人間の主体性と監督は技術的側面(人間の介入)だけを切り出し、社会的・環境的幸福は「効率性研究が発展している」という理由で事後的に技術側へ組み入れ、説明責任は非技術的要件のまま残す。つまり説明可能性は透明性の直接の技術的翻訳であり、人間の介入・効率性のような「研究蓄積を理由にした選択的な技術化」を経ていない点で、6要件の中でも定式化の経路が異なる。ch2 §2.3 はさらに、説明可能性をデータ観点(有用な特徴量の選択)とモデル観点(決定木・KNN のような解釈可能設計、CNN の中間特徴量検査のような事後解釈)の2経路で実現するとし、本ページが既に記録する post-hoc(SHAP/LIME)・interpretable-by-design(決定木・KNN・ARIMA)という2系統の定式化(第3.3章由来)と整合する——両章は独立に同じ2分法へ収束している。(Source: [[@2025__ACMCSUR__Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications - A Review - Chapter 2 Trustworthiness Requirements and Performance Diagnosis Systems]] §2.1, §2.3, [[Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications]]) > - **サーベイのフレームワークが定義する「人間の介入」要件(HITL に絞った専門家フィードバックによる検知精度改善)は、本ページが既に記録する Alibaba のオペレータフィードバックループに、8年越しの理論的位置づけを与える**: [[@2025__ACMCSUR__Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications - A Review - Chapter 2 Trustworthiness Requirements and Performance Diagnosis Systems]](§2.3)は、人間の介入を HITL(あらゆる意思決定サイクルへの人間の関与)・HOTL(設計・監視での監督)・HIC(利用可否の決定)の3機構に分け、性能診断システムでは主に HITL——データラベリングと、教師なし異常検知器への専門家フィードバックによる検知精度改善——に焦点を当てると明示する。本ページが既に記録する Alibaba のビジネストレンド異常検知([[@2017__SREcon17 Asia__Smart Monitoring System for Anomaly Detection on Business Trends in Alibaba]]、2017年)は、オペレータラベルを N-シグマ則のしきい値調整に使うフィードバックループを実装しており、これはサーベイが2025年に定式化した「HITL による検知精度改善」の具体的な先行実装(8年先行)にあたる。本ページの「常時稼働の検知には LLM/深層学習が重すぎる」というスレッドが非 LLM の軽量検知を選好する産業実装群を集めてきたのと同様に、産業側の HITL 実装(Alibaba のフィードバックループ)は、trustworthy AI レビューが要件として抽象化するより何年も前から存在していたことになる。(Source: [[@2025__ACMCSUR__Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications - A Review - Chapter 2 Trustworthiness Requirements and Performance Diagnosis Systems]] §2.3, [[@2017__SREcon17 Asia__Smart Monitoring System for Anomaly Detection on Business Trends in Alibaba]]) > > - **複数の検知手法の多数決による擬似正解ラベリングは、ラベル付き異常データセットの構築コストが高い領域での実用的な回避策として、時系列基盤モデル時代にも再登場する**: [[Cisco]] の [[@2026__arXiv__APEX - A Network-Native Time-Series Foundation Model for Forecasting and Anomaly Detection for Wireless Edge Operations|APEX]] は、単変量4手法(MC-dropout区間・Z-score・Isolation Forest・SARIMA 信頼区間)と多変量4手法(APEX joint 予測区間・VAR-Mahalanobis・SARIMAX 信頼区間・汎用 TSFM アンサンブル)を走らせ、3手法以上が一致した時刻のみを異常ラベルとするコンセンサス方式で「高コストな手動アノテーションなしに頑健な擬似正解を得る」ことを明示的な動機とする。本ページが記録する Alibaba のオペレータフィードバックループ(N-シグマしきい値調整、2017年)が単一手法へのフィードバックだったのに対し、APEX のコンセンサス方式は「単一手法の癖に起因する偽陽性を減らす」ために手法間の多数決を使う点で異なるアプローチをとる。(Source: [[@2026__arXiv__APEX - A Network-Native Time-Series Foundation Model for Forecasting and Anomaly Detection for Wireless Edge Operations]]) - [常時稼働の検知とLLMコストの緊張] CoLMAD (Nankai/Microsoft Research/Tsinghua) は LLMAD と同じ「LLM を検知に使うと高コスト」という制約に対し、サンプリング頻度を緩める LLMAD のアプローチとは異なる解を示す。軽量検知器を常時稼働の候補生成に残し、LLM は疑わしい候補窓の 0.5% だけを検証する設計により、推定日次コストを LLMAD の 87.92 USD から 0.08 USD へ約 1000 分の1に削減し、1 呼び出しの入力トークンも 4100→1100 に圧縮した。同じ産業制約に対して「サンプリング頻度を緩める」路線と「検知器とLLMを役割分離する」路線という異なる解が並立することを示す。(Source: [[@2026__ISSRE__CoLMAD : Cost-Efficient LLM-Assisted Time Series Anomaly Detection for Industrial Monitoring]]) - [LLMの検知器・メタ層としての役割分岐] CoLMAD は LLMAD(LLM を検知器そのものとして直接使う路線)と同じ Microsoft Research が関わりながら、軽量検知器を常時稼働の一次検知器として残し LLM を選択的検証・説明生成層として使う設計を採る。「検知器 vs メタ層」の二分法に対し、常時稼働の軽量検知器と選択的LLM検証を直列につなぐハイブリッド構成が第三の位置取りとして提案されている。(Source: [[@2026__ISSRE__CoLMAD : Cost-Efficient LLM-Assisted Time Series Anomaly Detection for Industrial Monitoring]]) - [常時稼働の検知とLLMコストの緊張] THXInLog(スーパーコンピュータ本番ログ異常検知)は LLM を per-log 推論経路の外(アラートトリアージのみ)に置き、エキスパート検証済みフィードバックのみでクローズドループ適応する設計により、LLM ベース手法(LogPrompt: 0.5s/log・GPU 83%)に対し 5.82×10^-4 s/log・GPU 18% 未満という 3 桁近い効率差を保ちつつ F1=0.9082 を達成しており、「常時稼働の検知には LLM が重すぎる」制約への一解として非 LLM 軽量手法側に位置づく。(Source: [[@2026__nkcs.iops.ai__THXInLog - Robust Semantic-Temporal Framework for Log Anomaly Detection in Production Supercomputers]]) - **Tier-0 本番 HPC では、連合学習で得た表現を非参加ノードへ転移しデコーダのみ微調整する FTL が、教師なし〜教師ありの全域で異常検知 F1 を押し上げる**: [[@2026__ESWA__Federated Transfer Learning for Anomaly Detection in HPC Systems]] は Marconi100 の 100 ノード実テレメトリ(D1/D2)で検証し、半教師ありの ΔF1 が最大 +0.50、教師なしでも +0.47 級の利得を報告する。ラベル 1/4 の教師ありでも改善し、Cohen's d は多くが大効果。デコーダのみ微調整はフル微調整よりわずかに F1 は劣るが資源コストを大幅に削減する。(Source: [[@2026__ESWA__Federated Transfer Learning for Anomaly Detection in HPC Systems]]) - [HPC監視] ラベル無しノード監視では、教師あり検出よりクラスタベース VA + ベースライン相対 z スコアが運用検証と相性が良い: [[@2026__ISC__Understanding Large-Scale HPC System Behavior Through Cluster-Based Visual Analytics]] は MulTiDR で挙動群を切り、mrDMD z スコアで群内逸脱を示し、ジョブログ・ログブックで検証した。合成異常注入やラベル前提手法が実データで効きにくいという問題設定に対する代替経路。(Source: [[@2026__ISC__Understanding Large-Scale HPC System Behavior Through Cluster-Based Visual Analytics]]) - [LLMの検知器・メタ層としての役割分岐] ViTs は時系列を折れ線グラフ画像として VLM(Vision-Language Model)に入力する TS-VLM 方式を提案し、テキスト化する TS-LLM や専用時系列エンコーダを使う PTSE-LLM(ChatTS 等)より TSAD で明確に優れることを実証する。VLM の一般画像理解能力が時系列画像の解釈に転移し、Qwen2.5-VL-7B ベースで SFT 前から一定の検知能力を示す一方、テキスト化した TS-LLM は SFT 前ほぼ無力である([[@2026__WWW2026__ViTs - Teaching Machines to See Time Series Anomalies Like Human Experts]])。 - [検知精度を決めるデータ設計とシグナル源] ViTs は STL(季節性・トレンド・ノイズ分解)理論に基づく合成時系列生成器で学習データを自動生成し、固定長(200)で学習・画像リスケーリングで任意長へ適応する推論スキーマにより、合成データのみの学習で KPI/Yahoo/WSD の3公開データセットにゼロショット汎化する(平均 F1 約0.81、SOTA の TimesNet を上回る)。これは「検知のシグナル源・学習データの多様性が精度の上限を決める」という同節の論点に、時系列を画像として表現し直すことで汎化を得るという新しい角度を加える([[@2026__WWW2026__ViTs - Teaching Machines to See Time Series Anomalies Like Human Experts]])。 - [常時稼働の検知とLLMコストの緊張] Borgmon の宣言型ルール評価をさらに約20年遡る先例として、1993年の swatch(Stanford EECF)は syslog ストリームに対する正規表現パターン・アクション・時間間隔抑制という宣言的4フィールド設定で、常時稼働のログ監視と自動通知(ベル・メール・ページャ呼び出し・任意スクリプト実行)を実現していた。時間間隔による重複通知の抑制は、現代のアラート重複排除・デデュープの発想を1993年時点で先取りしている。(Source: [[@1993__LISA__Automated System Monitoring and Notification With Swatch]]) - [実用ギャップ] Splunkの実運用クエリログ20万件超の分析では、製品にクラスタリング・異常検知機能が実装されているにもかかわらず、スケジュールクエリの実利用はフィルタリング(99%)・集約(42%)・データ整形が支配的で、機械学習的な異常検知はほとんど観測されなかった。著者らは、人間の直観とドメイン知識を伴う単純なフィルタ・集約が解釈可能性の点で高度な手法と競合しうること、および高度な分析はSplunk外のカスタムツールチェーンで行われ観測できていない可能性を挙げている (Source: [[@2014__LISA__Analyzing Log Analysis - An Empirical Study of User Log Mining]])。 - 非参加型のOSレベルPS監査は、ログ・メトリクス依存の異常検知とは異なる検知系譜に属する: [[@2006__LISA__LiveOps - Systems Management as a Service]]のLiveOpsは、アプリケーションのログ出力やAPI利用に依存せず、レジストリ・ファイル・バイナリ・プロセス生成へのOSレベルの全アクセスを記録することで、開発者が事前に想定しなかった構成起因の障害(削除された設定ファイル、部分的にしか適用されなかったパッチ)を検知する。34台の本番サーバの1か月分のトレースでは1660万件の変更を160万distinctなPSエントリへ集約し、プロセスインスタンス単位でO(10^2)まで確認項目を削減できたと報告する。この非参加型アプローチは、本ページが蓄積してきたログ/メトリクス/トレースベースの異常検知(データ源で分類する2軸)とは異なる第3の監視対象(構成状態そのもの)を扱う先例であり、2000年代半ばの構成管理研究の系譜として詳細は[[永続状態相互作用監査]]に集約する。(Source: [[@2006__LISA__LiveOps - Systems Management as a Service]]) - **Holt-Winters予測(指数平滑の3成分拡張)に基づく信頼帯(confidence band)逸脱の移動窓カウント**は、2000年時点で「固定閾値ルールは静的すぎる」という後年の教訓を先取りしていた、ネットワーク監視ドメインでの動的な正常性モデルの初期実例である。ベースライン・線形トレンド・季節係数の3成分予測+移動窓での違反数カウントという設計は、後年の統計的異常検知(N-シグマ則・MAD等)や「単純な閾値超過より頑健な機構が要る」という繰り返し現れる教訓の先例にあたる。(Source: [[@2000__LISA__Aberrant Behavior Detection in Time Series for Network Service Monitoring]]) - [正常性の文脈依存性]**1998年のDECプロキシサーバ研究は、時間帯ごとに異なる「正常」を推定してから逸脱を判定するという設計を、固定閾値批判(Alibaba N-シグマ則・PERSEUS)より四半世紀早く実践していた**: [[@1998__PER__Internet Service Performance Failure Detection]]は、リクエスト率の日内パターン(朝の上昇・日中の高止まり・夕方の下降)を前提に、単一の固定閾値ではなく時間帯ごとの平均・標準偏差を推定してZスコア化し、非対称な閾値(急増と急減で異なる基準)で逸脱を判定した。本ページが記録する「固定閾値は文脈で機能しない」という教訓([[MAD]]・PERSEUS等)の、現存する中でも最も早期の実証例の一つである。(Source: [[@1998__PER__Internet Service Performance Failure Detection]]) - [正常性の文脈依存性] 1997年のベイジアンネットワーク型プロアクティブ検知(RPIネットワーク、7ヶ月・10障害)は、障害の事前仕様を持たずAR(2)特徴量とベイジアンネットワークで正常挙動を学習する設計を、統計力学的研究(2002年)やホスト間正常性比較(2005年)に5〜8年先立って実証していた。ファイルサーバ無応答の約12分前に異常検知でき、1週間学習ウィンドウの閾値法は情報を持たないという結果は、学習ウィンドウ長の選択が閾値法・学習法の両方に影響する初期の定量的観察である。(Source: [[@1997__IM__Automated Proactive Anomaly Detection]]) - 1999年の[[アラーム相関]]研究(TASA)は、[[頻出エピソードマイニング]]で発見したエピソードルール(時間窓付き条件付きルール)が異常検知に応用可能だと示唆しており、統計的手法ベースの異常検知が2000年代以降のML/LLMベース手法に先立つ古典的系譜として、テレコミュニケーションアラーム相関の文脈にも存在したことを示す。(Source: [[@1999__JNSM__Rule Discovery in Telecommunication Alarm Data]]) ## 関連 - ソース: [[@2026__ICPE Companion__Leveraging Time Series Foundation Models to Detect Performance Anomalies in Software Systems]] / [[@2025__TSC__Bridging Edge and Cloud - A Knowledge-Enhanced Framework for Efficient Time Series Anomaly Detection]] / [[Anomaly Detection - A Survey]] / [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 5 Nearest Neighbor-Based Anomaly Detection Techniques]] / [[A Survey of AIOps in the Era of Large Language Models]] / [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]] / [[Anomaly detection and root-cause identification in microservices]] / [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey - Chapter 4.3 Methods to identify anomalies in microservices]] / [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey - Chapter 6 Challenges, open issues, and directions to future investigations]] / [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]] / [[@2025__NeurIPS2025__This Time is Different - An Observability Perspective on Time Series Foundation Models]] / [[@2026__ICML__TelecomTS - A Multi-Modal Observability Dataset for Time Series and Language Analysis]] / [[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]] / [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]] / [[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]] / [[@2026__arXiv__Towards Robust LLM Post-Training - Automatic Failure Management for Reinforcement Fine-Tuning]] / [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]] / [[@2025__IWQoS__eACGM - Non-instrumented Performance Tracing and Anomaly Detection towards Machine Learning Systems]] / [[@2025__DSN__LLMPrism - Black-box Performance Diagnosis for Production LLM Training Platforms]] / [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]] / [[@2024__ESEM__Reducing Events to Augment Log-based Anomaly Detection Models - An Empirical Study]] / [[@2024__IEEE CLOUD__Enabling Programmable Metric Flows]] / [[@2026__arXiv__Agent System Operations - Categorization, Challenges, and Future Directions]] / [[@2015__CSUR__Performance Anomaly Detection and Bottleneck Identification]] / [[@2021__J Grid Computing__Automated Analysis of Distributed Tracing - Challenges and Research Directions]] / [[@2026__ACM FSE__EventADL - Open-Box Anomaly Detection and Localization Framework for Events in Cloud-Based Service Systems]] / [[Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications]] / [[@2026__SIGMOD__HYDRA - A Multi-Level Hierarchy-Driven Approach for Robust Anomaly Detection in Time Series]] / [[@2023__loginonline__Detecting Fail-Slow Failures in Large-Scale Cloud Storage Systems]] / [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.3 Failure Detection]] / [[@2026__ISSRE__CoLMAD : Cost-Efficient LLM-Assisted Time Series Anomaly Detection for Industrial Monitoring]] / [[@2026__nkcs.iops.ai__THXInLog - Robust Semantic-Temporal Framework for Log Anomaly Detection in Production Supercomputers]] / [[@2026__ESWA__Federated Transfer Learning for Anomaly Detection in HPC Systems]] / [[@2026__ISC__Understanding Large-Scale HPC System Behavior Through Cluster-Based Visual Analytics]] / [[@2026__WWW2026__ViTs - Teaching Machines to See Time Series Anomalies Like Human Experts]] / [[@1993__LISA__Automated System Monitoring and Notification With Swatch]] / [[@2014__LISA__Analyzing Log Analysis - An Empirical Study of User Log Mining]] / [[@2000__LISA__Aberrant Behavior Detection in Time Series for Network Service Monitoring]] / [[@1998__PER__Internet Service Performance Failure Detection]] / [[@1999__JNSM__Rule Discovery in Telecommunication Alarm Data]] - 概念: [[AIOps]] / [[変化点検知]] / [[時系列基盤モデル]] / [[時系列質問応答]] / [[強化ファインチューニング]] / [[障害予測]] / [[Fault Localization]] / [[根本原因分析]] / [[ログ解析]] / [[ログパース]] / [[テレメトリ]] / [[アラート相関]] / [[ログベース異常検知]] / [[モデル圧縮]] / [[知識蒸留]] / [[Edge-cloud Collaboration]] / [[グラフベースRCA]] / [[構造化イベント]] / [[連合学習]] / [[ビジュアルアナリティクス]] / [[永続状態相互作用監査]] / [[アラーム相関]] - エンティティ: [[AIOpsLab]] / [[Detectr]] / [[Toto]] / [[BOOM]] / [[Minder]] / [[Pulse]] / [[MetricSifter]] / [[TelecomTS]] / [[MonitorAssistant]] / [[LogPilot]] / [[ARFBench]] / [[RFT-FM]] / [[RFT-FaultBench]] / [[AlertGuardian]] / [[GraphGuardian]] / [[LogCleaner]] / [[PMF]] / [[@2024__KDD__Multivariate Log-based Anomaly Detection for Distributed Database|MultiLog]] / [[Apache IoTDB]] / [[RefinedEdge]] / [[SenseTime Research|SenseTime]] / [[PERSEUS]] / [[Marconi100]] / [[Dan Pei]] / [[Changhua Pei]] / [[ChatTS]] / [[Jake D. Brutlag]] - 関連 MOC: [[異常検知 - MOC]] / [[AIOps - Failure Detection - MOC]] / [[AIOps - Log Analysis - MOC]] 追加ソース: [[@2005__Machine Learning__Principle Components and Importance Ranking of Distributed Anomalies]](PCA・固有ベクトル中心性による分散異常検知の 2005 年の先駆的な負の実証結果) / 追加概念: [[PageRank]] / 追加エンティティ: [[Mark Burgess]] / [[Kyrre Begnum]] / [[cfengine]] 追加ソース(2026-08-15): [[@2026__SIGMOD__HYDRA - A Multi-Level Hierarchy-Driven Approach for Robust Anomaly Detection in Time Series]](discord/クラスタリング両パラダイムを階層的代表選抜で統合し、TSB-AD 40データセット横断でVUS-PR最良を達成。twin-freak問題・クラスタ汚染問題の構造的解消、正規化の二面性の統計的実証) / 追加エンティティ: [[Mingyi Huang]] / [[Qinghua Liu]] / [[Paul Boniol]] 追加ソース(2026-08-23): [[@2023__loginonline__Detecting Fail-Slow Failures in Large-Scale Cloud Storage Systems]](Alibaba のストレージデバイス向けフェイルスロー検知 PERSEUS。ノード単位のレイテンシ対スループット分布への多項式回帰で適応的しきい値を自動導出し、固定閾値の文脈依存的破綻という同社 2017 年の知見をハードウェアテレメトリで再確認) / 追加エンティティ: [[PERSEUS]] 追加ソース(2026-08-25): [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 8 Information Theoretic Anomaly Detection Techniques]](情報理論ベース異常検知——複雑性 C(D)−C(D−I) の最大化を求めるパレート最適化。コルモゴロフ複雑性・エントロピーを尺度とし、厳密解は指数時間だが近似は線形時間) / [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 9 Spectral Anomaly Detection Techniques]](スペクトルベース異常検知——PCA・ロバスト PCA・グラフ時系列の主要特異ベクトル/CMD で低次元部分空間に射影し、分離可能性に依拠する) 追加ソース(2026-08-25): [[@2025__ACMCSUR__Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications - A Review - Chapter 1 Introduction]](trustworthy な性能診断システムを扱うサーベイの不在という研究ギャップと3つのサブクエスチョンの提示) / [[@2025__ACMCSUR__Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications - A Review - Chapter 2 Trustworthiness Requirements and Performance Diagnosis Systems]](EUの7要件から6つの技術的信頼性要件を抽出し、フレームワークの各構成要素——データ収集・データ前処理・異常検知・根本原因箇所特定・システム全体・意思決定プロセス——へ対応づける章。異常検知は公平性・頑健性・説明可能性・効率性の4要件、人間の介入はHITLとして異常検知器へのフィードバックという形で関わる) ## 出典 - [[@2026__SIGMOD__HYDRA - A Multi-Level Hierarchy-Driven Approach for Robust Anomaly Detection in Time Series]](Huang+, SIGMOD 2026 — §3.2.1 twin-freak/クラスタ汚染の定式化、§4.3 参照集合の階層的純化、§5.4 正規化の二面性とNo-Norm優位の統計検証、Fig. 10 anomaly multiplicity別性能) - [[@2026__ACM FSE__EventADL - Open-Box Anomaly Detection and Localization Framework for Events in Cloud-Based Service Systems]](Pham+, ACM FSE 2026 — §3 520件の実インシデント分析、§4.2 Event Semantic Pattern、§4.3 Event Frequency Pattern、§5.8.2 magnitude-based vs shape-based EFP のアブレーション) - [[Anomaly Detection - A Survey]](§1.4 Contributions、§2.2 Type of Anomaly、§4–§9 技法カテゴリ、§11 Relative Strengths and Weaknesses、§12 Future Work) - [[@2009__CSUR__Anomaly Detection - A Survey - Chapter 5 Nearest Neighbor-Based Anomaly Detection Techniques]](§5 Assumption、§5.1 k 番目近傍距離ベース技法、§5.2 相対密度ベース技法・LOF/COF/ODIN/MDEF) - [[A Survey of AIOps in the Era of Large Language Models]](§4.1 Failure Perception/Anomaly Detection, §5.1 Foundation Model, §7.1 Time-Efficiency, §7.2 Data Sources) - [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]](Table 1, Level 1 Detection) - [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]](Detectr による user-feedback 検知) - [[@2025__NeurIPS2025__This Time is Different - An Observability Perspective on Time Series Foundation Models]](予測ベースの観測データ異常検知) - [[@2026__ICML__TelecomTS - A Multi-Modal Observability Dataset for Time Series and Language Analysis]](Table 2: 異常検知の偽陽性バイアス、Table 7: スケールアブレーション) - [[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]](§3.1 実用的異常の定義、§4 LLM メタ層アーキテクチャ、§5 ケーススタディ) - [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]](§III-A alert-agnostic なログ異常検知の限界、§IX Related Work のログ異常検知の系譜) - [[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]](§2/§3.2 異常検知を多肢選択の推論問題へ再定式化、§4 Tier 別の VLM/人間性能) - [[@2026__arXiv__Towards Robust LLM Post-Training - Automatic Failure Management for Reinforcement Fine-Tuning]](§V-A RFT-Feature-Based IVS Scoring, §VI-D Anomaly Detection の Table III, §VI-G アブレーション Table VI) - [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]](§II-C 既存 denoise の属性組合せ爆発、§III Alert Denoise の GraphGuardian と匿名化、削減率 93.82〜95.50%/<200ms、表 II/図 12) - [[LLM4Log]](§6.2 ログ異常検知の 6 ファミリ/Table 6–7, 「努力を feature 設計から normality curation へ移す」まとめ, HDFS/BGL 依存) - [[@2024__ESEM__Reducing Events to Augment Log-based Anomaly Detection Models - An Empirical Study]](§5 RQ1–RQ3 イベント削減の定量効果・3 類型, §6 LogCleaner, §7 評価, §9.1 Apache IoTDB 産業応用) - [[@2024__IEEE CLOUD__Enabling Programmable Metric Flows]](§I 図 1: メトリクスの異常検知への貢献度の不均等性(上位/下位 20% の AU-ROC 差)、§IV メトリクス重要度に基づくトップダウン周波数最適化) - [[Anomaly detection and root-cause identification in microservices]](§4.2 データ収集方法、§4.3 検知手法、§4.7 手法比較、§6 課題と将来方向) - [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey - Chapter 4.3 Methods to identify anomalies in microservices]](§4.3.1〜§4.3.5 検知アルゴリズムの5分類——教師なし学習・教師あり学習・強化学習・トレース比較・統計分析——と各節の代表手法) - [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey - Chapter 6 Challenges, open issues, and directions to future investigations]](§6 冒頭: ログパーサの構造依存・機械学習手法の再学習コスト、§6.1 TEE によるモニタリングパイプライン保護、§6.2 TDAI と Table 10 信頼次元) - [[@2015__CSUR__Performance Anomaly Detection and Bottleneck Identification]](§2 PADBI 分類体系、§3 検知戦略の 4 分類、§4 統計/ML 手法サーベイ、§5 クラウド固有課題、§6 研究ギャップ) - [[@2021__J Grid Computing__Automated Analysis of Distributed Tracing - Challenges and Research Directions]](§3 OTP・§4.1 Isolation Forest による Huawei Cloud OpenStack 本番トレースの異常時間枠/サービス検知・§5 検知の天井としてのトレース品質) - [[@2025__KDD__Large Language Models can Deliver Accurate and Interpretable Time Series Anomaly Detection]](§3 LLMAD 設計、§4 KPI/WSD/Yahoo の Best F1 評価と ablation、§5 5 名 DevOps エンジニア人手評価、§6 コスト分析) - [[@2025__VLDB__ChatTS - Aligning Time Series with LLMs via Synthetic Data for Enhanced Understanding and Reasoning]](§3 属性ベース合成データ + Context-Aware Encoding、§4 alignment/reasoning 評価、§5 Oracle DB の RCA 等のケーススタディ) - [[@2021__SREcon21__Spike Detection in Alert Correlation at LinkedIn]](p.19 修正 Z スコア、p.24 判定ルール、p.28 評価結果——ML なし統計手法で 36.4% のスパイクを分離し偽陽性率 1% 未満) - [[@2017__SREcon17 Asia__Smart Monitoring System for Anomaly Detection on Business Trends in Alibaba]](page-007 手法比較、page-008 STL 選択理由、page-011 カスタム前処理 4 段階、page-013 N-シグマ則の課題、page-014 適応 N 決定法、page-015 人間フィードバックループ、page-016 評価——適合率・再現率各 80%) - [[@2023__arXiv__TRANSOM - An Efficient Fault-Tolerant System for Training LLMs]](§IV-B TEE 設計: ログベース+メトリックベースのハイブリッド検知、LOF/KNN Matrix Profile/DTW クラスタリングの選択理由、§VI-C 月次実データでの検知評価) - [[@2026__ICPE Companion__Leveraging Time Series Foundation Models to Detect Performance Anomalies in Software Systems]](Table 1/2: AIOPS・MSCloudでのChronos・TSPulseゼロショット評価とベースライン(AR/IF/LSTM-AD/VAE)比較、Figure 3: 推論・総所要時間) - [[@2021__OReillyJapan__SREの探求 - Chapter 18 SREのための機械学習入門]] §18.2.1, §18.6.2.5, §18.7. - [[@2023__loginonline__Detecting Fail-Slow Failures in Large-Scale Cloud Storage Systems]](3 つの失敗した先行試行(閾値フィルタリング・ピア評価・IASOベースモデル)、ノード単位LvT分布への多項式回帰、DBSCAN+PCAによる外れ値除去、リスクスコアマトリクス、既存手法比較評価) - [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.3 Failure Detection]](§4.3.1 Anomaly Detection: クラスタリング/次元削減/オートエンコーダの3手法系統、Table 6 データソース×アルゴリズムの2軸分類、USAD/OmniAnomaly/MSCRED 等の定量結果) - [[@2025__ACMCSUR__Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications - A Review - Chapter 2 Trustworthiness Requirements and Performance Diagnosis Systems]](§2.1 EU 7要件から6技術的信頼性要件への抽出過程・Figure 1、§2.3 6要件のフレームワーク構成要素への対応づけ——公平性→データ収集、頑健性・説明可能性・効率性→データ前処理/異常検知/根本原因箇所特定、データプライバシー→システム全体、人間の介入→意思決定プロセス(HITL)) - [[@2025__ACMCSUR__Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications - A Review - Chapter 1 Introduction]](§1.1 既存サーベイが trustworthy AI 一般要件・特定要件・性能診断技術詳細のいずれかに偏り、両者を統合するサーベイが不在という研究ギャップ) - [[@2026__ESWA__Federated Transfer Learning for Anomaly Detection in HPC Systems]](Tier-0 実機での FTL 異常検知と ΔF1)