# 異常検知 ## 定義 異常検知(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]])。 LLM 時代の異常検知手法は、サーベイの整理では 3 方向に分かれる(§4.1):(1) モデルの汎化向上(時系列・ログの基盤モデルの開発/fine-tuning)、(2) 大モデルで小モデルを強化(LLM がログの埋め込みを生成する等)、(3) モデル学習の回避(プロンプトで次のメトリクス/ログを直接予測する)。 ## 横断的知見 - **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]]) - **時系列基盤モデルが異常検知と予測を同じ土俵に載せた**: サーベイは 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]]) - **分散訓練メトリクスの統計的安定性を前提に教師なし手法が広く使われる**: [[@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]]) ## 未解決の問い - サーベイが指摘する「連続稼働の異常検知に 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]]) - [[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]]) ## 関連 - ソース: [[@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__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]] - 概念: [[AIOps]] / [[変化点検知]] / [[時系列基盤モデル]] / [[時系列質問応答]] / [[強化ファインチューニング]] / [[障害予測]] / [[Fault Localization]] / [[根本原因分析]] / [[ログ解析]] / [[ログパース]] / [[テレメトリ]] - エンティティ: [[AIOpsLab]] / [[Detectr]] / [[Toto]] / [[BOOM]] / [[Minder]] / [[Pulse]] / [[MetricSifter]] / [[TelecomTS]] / [[MonitorAssistant]] / [[LogPilot]] / [[ARFBench]] / [[RFT-FM]] / [[RFT-FaultBench]] / [[AlertGuardian]] / [[GraphGuardian]] / [[LogCleaner]] / [[PMF]] - 関連 MOC: [[異常検知 - MOC]] / [[AIOps - Failure Detection - MOC]] / [[AIOps - Log Analysis - MOC]] ## 出典 - [[@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 メトリクス重要度に基づくトップダウン周波数最適化)