# 異常検知 ## 定義 異常検知(anomaly detection)は、システムの正常な挙動から逸脱する異常な振る舞いやパターンを特定し、潜在的な問題や障害の早期指標とする取り組み。[[AIOps]] の障害認知(failure perception)段における中心タスクで、LLM 登場の前後を通じて障害認知の中で最も研究が活発な領域である。([[@2025__CSUR__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)に分かれる。点異常は個別データ点が残りのデータに対して異常な場合、文脈異常は同じ振る舞い属性でも時間・場所・ユーザーなどの文脈により異常性が変わる場合、集合異常は個々の要素ではなく関連するインスタンスの並びや集合として異常になる場合である。([[@2009__CSUR__Anomaly Detection - A Survey]] §2.2) LLM 時代の異常検知手法は、サーベイの整理では 3 方向に分かれる(§4.1):(1) モデルの汎化向上(時系列・ログの基盤モデルの開発/fine-tuning)、(2) 大モデルで小モデルを強化(LLM がログの埋め込みを生成する等)、(3) モデル学習の回避(プロンプトで次のメトリクス/ログを直接予測する)。 ## 横断的知見 - **Chandola 2009 の「異常の型」と「技法の仮定」は、後続 AIOps 異常検知を読むための基礎層である**: [[@2009__CSUR__Anomaly Detection - A Survey]] は、異常検知を点異常・文脈異常・集合異常に分け、技法を分類・近傍・クラスタリング・統計・情報理論・スペクトルの 6 群に整理した。重要なのは、各群を「どのような正常/異常仮定に依存するか」で比較する点である。[[@2015__CSUR__Performance Anomaly Detection and Bottleneck Identification]] はこの 3 分類に pattern anomaly を追加して性能異常検知へ拡張し、[[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey]] は汎用異常検知サーベイとして Chandola 2009 を参照する。つまり、現代のマイクロサービス/AIOps 文献に現れる「文脈なしの統計的逸脱では不十分」という議論は、Chandola 2009 の文脈異常の定義を運用ドメインへ移したものとして読める。(Source: [[@2009__CSUR__Anomaly Detection - A Survey]], [[@2015__CSUR__Performance Anomaly Detection and Bottleneck Identification]], [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey]]) - **異常検知の手法比較は、性能表より先に仮定の整合性を見る必要がある**: Chandola 2009 は、分類ベースはラベル、近傍/クラスタリングベースは意味ある距離尺度、統計ベースは分布仮定、情報理論ベースは情報量尺度、スペクトルベースは低次元射影での分離可能性に依存すると整理した。これは現代の [[TelecomTS]] や [[MonitorAssistant]] が示す偽陽性問題と同じ構造で、観測データの正常急変動やインシデント文脈を無視すると、どれほど高性能な判定器でも「実用的異常」を取り違える。古典的な「仮定とドメインの整合性」評価は、LLM/時系列基盤モデル時代にも消えていない。(Source: [[@2009__CSUR__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]]) - **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 は重い」という制約が、検知系の手法選択を分岐させている**: [[@2025__CSUR__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: [[@2025__CSUR__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: [[@2025__CSUR__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: [[@2025__CSUR__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]], [[@2025__CSUR__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)。サーベイ([[@2025__CSUR__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]], [[@2025__CSUR__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 は重すぎる」スレッド([[@2025__CSUR__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]], [[@2025__CSUR__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 の [[@2025__CSUR__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 の「情報を絞ってから推論する」骨格([[ログ解析]]・[[特徴量削減]])のログイベント版であり、[[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]] が整理する 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]], [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]], [[@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 へ移す」と地図が確定する**: [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]] はログ異常検知をサーベイ最大のタスクと位置づけ、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: [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]], [[@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]]) - **マイクロサービス異常検知では「データ源の統合」が常に性能改善を意味しない**: [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey]] は、ログ、分散トレース、監視メトリクスをデータ収集の 3 軸に整理し、ログベースが accuracy/precision/recall で高く、ログ+トレースが F1 で最も高い一方、ログ+トレース+監視の 3 種統合は accuracy/precision/recall が低いと報告する(§4.7)。これは [[LogPilot]] が「文脈なしにログを増やすと診断を悪化させる」と示した入力選別の観察、[[MetricSifter]]/[[PMF]] がメトリクスの不均等な重要度を利用して収集・分析を絞る観察と同型である。単純なマルチモーダル化より、障害クラスに合う信号源の選別と正規化が検知性能を律速する。(Source: [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey]], [[@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 軸に収束したが、手法選択はセットアップコストとのトレードオフである**: [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey]]（Soldani & Brogi 2021）は、マルチサービスアプリケーションの異常検知 25 手法を**データ源（ログ/分散トレース/監視メトリクス）× 検知方式（教師なし/教師あり/トレース比較/SLO チェック/ハートビート）**の 2 軸で整理した最初のサーベイである。中心的な知見は「SLO チェックは設定コスト最小だがアプリ全体粒度しか得られない」「教師あり学習は故障種別まで返せるが障害注入込みの訓練を要する」「トレース比較はオンライン用途では計算コストが高すぎる（Chen et al. を除く）」という設定コスト vs 粒度のトレードオフである。5 年後の [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey]]（Barata et al. 2026）が 117 件に拡張しても基本軸は同じ——「データソース × 手法種別」の枠組みの安定性を確認する。LLM 時代の 3 方向（汎化/小モデル強化/学習回避）は、この Soldani 分類で言う「教師なし学習」路線の延長として位置づく。(Source: [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey]], [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey]]) - **トレースを派生メトリクス時系列に落として古典外れ値検知を当てる経路は 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]], [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey]], [[@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: [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey]]) - **「常時稼働の検知に 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]], [[@2025__CSUR__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]], [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey]]) - **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]] サーベイ([[@2025__CSUR__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]], [[@2025__CSUR__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]]) - **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]], [[@2009__CSUR__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 倍異なる)。これは [[@2009__CSUR__Anomaly Detection - A Survey]] が後年整理する「統計ベース手法はデータの分布仮定に強く依存する」という一般論に、「分布の形そのものが環境非依存の不変量になりうる場合がある」という具体的な反例(あるいは精緻化)を与える——分布仮定への依存はリスクである一方、変換次第では分布形が汎化可能な足場になりうる。(Source: [[@2002__TOCS__Measuring System Normality]], [[@2009__CSUR__Anomaly Detection - A Survey]]) ## 未解決の問い - 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 や、MonitorAssistant の practical anomaly は、この分類へどう位置づけるべきか。(Source: [[@2009__CSUR__Anomaly Detection - A Survey]], [[@2015__CSUR__Performance Anomaly Detection and Bottleneck Identification]], [[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]]) - Chandola 2009 の文脈異常(contextual anomaly)と、運用現場でいう実用的異常(practical anomaly)は同じ「文脈依存性」を指しているのか。前者はデータ属性上の文脈、後者はインシデント裏付け・SLO・業務影響上の文脈であり、両者を分けた評価指標が必要ではないか。(Source: [[@2009__CSUR__Anomaly Detection - A Survey]], [[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]]) - サーベイが指摘する「連続稼働の異常検知に LLM は重すぎる(1 秒以内の推論が要る)」課題は、小規模モデル + LLM + OCE のハイブリッドで解けるか。検知は軽量モデル/計測で常時行い、異常時だけ LLM を呼ぶ二段構えはどこまで汎用化できるか([[AIOps]] の課題4「ツールチェーン統合」と接続)。(Source: [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models]]) - 異常検知([[異常検知]])と[[変化点検知]]はどう棲み分けるか。変化点検知は正常区間の事前指定が不要な点で異常検知と区別されるが、[[MetricSifter]] のように変化点検知を障害窓の局所化に使う設計は「検知」か「前処理」か。検知タスクの境界が手法によって曖昧になる。 - ログベース異常検知の多くは T5/GPT-2 等の小型前処理モデル依存で、単純なデータセットでは従来 ML と差が出にくい(サーベイ §7.2)。ログを LLM で活かす有効な道(prompt embedding 等)は本当に従来手法を超えるのか。評価データの単純さがゲインを過大評価していないか。(Source: [[@2025__CSUR__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]]) - 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 が重すぎる制約([[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models]] §7.1)と agentic 検知の重さは、どの障害クラスで割に合うか。HDFS/BGL 偏重のコーパスは agentic の優位を正しく測れているか。([[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]]) - 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%」のように手法群の平均性能を提示するが、対象データセット・故障種別・指標が揃っていない。異常検知の横断比較は、同一障害注入・同一テレメトリ・同一評価窓を持つベンチなしにどこまで意味を持つか。([[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey]]) - [[@2015__CSUR__Performance Anomaly Detection and Bottleneck Identification]] が整理した 4 検知戦略のうち「知識駆動(ベイジアンネット・因果グラフ)」路線は 2015 年時点で PAD 研究の少数派だった。この路線が現代では LLM プロンプティング・RAG を経由して LLM 時代の「学習回避(直接予測)」路線として復権しているとすれば、知識表現の形式(明示的グラフ 対 LLM の潜在知識)の違いが検知精度や説明可能性にどう影響するか。([[@2015__CSUR__Performance Anomaly Detection and Bottleneck Identification]], [[@2025__CSUR__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 年後の実装例は。([[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey]]) - [[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]]) ## 関連 - ソース: [[@2025__TSC__Bridging Edge and Cloud - A Knowledge-Enhanced Framework for Efficient Time Series Anomaly Detection]] / [[@2009__CSUR__Anomaly Detection - A Survey]] / [[@2025__CSUR__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]] / [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey]] / [[@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]] - 概念: [[AIOps]] / [[変化点検知]] / [[時系列基盤モデル]] / [[時系列質問応答]] / [[強化ファインチューニング]] / [[障害予測]] / [[Fault Localization]] / [[根本原因分析]] / [[ログ解析]] / [[ログパース]] / [[テレメトリ]] / [[アラート相関]] / [[ログベース異常検知]] / [[モデル圧縮]] / [[知識蒸留]] / [[Edge-cloud Collaboration]] - エンティティ: [[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]] - 関連 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]] ## 出典 - [[@2009__CSUR__Anomaly Detection - A Survey]](§1.4 Contributions、§2.2 Type of Anomaly、§4–§9 技法カテゴリ、§11 Relative Strengths and Weaknesses、§12 Future Work) - [[@2025__CSUR__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) - [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]](§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 メトリクス重要度に基づくトップダウン周波数最適化) - [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey]](§4.2 データ収集方法、§4.3 検知手法、§4.7 手法比較、§6 課題と将来方向) - [[@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%)