# アラーティングの進歩 — 年代別レビュー ## 1. なぜアラーティングが研究対象になったのか アラーティング(alerting)は、運用システムの「異常」を検知してオンコールエンジニア(OCE)に通知する一連の機構を指す。一見すれば単純な仕組みだが、本番運用ではアラート過多による疲労、見逃しによる障害拡大、誤発火による誤った対応コスト、そしてオンコール体制の人的消耗が、サービスの可用性そのものを直接左右する。商用クラウドではモニタリングシステムが日次で数万件のアラートを生み、 [[Huawei Cloud]] では 2 年で 400 万件超のアラートが記録された ([[@2022__DSN__Characterizing and Mitigating Anti-patterns of Alerts in Industrial Cloud Systems|Yang+ DSN2022]])。 [[China EverBright Bank]] では単一のアラートストームが平均 55 分・6 名のエンジニアを消費する事例が観測された ([[@2020__ICSE-SEIP__Understanding and Handling Alert Storm for Online Service Systems|Zhao+ ICSE-SEIP2020]] §2.2)。 [[Microsoft]] の 300 超のサービスを 1 年間追跡した実証研究は、検知失敗(miss-detection)に陥ったインシデントの 27.25% がアウテージに発展し、顧客報告は TTD(Time-To-Detect)でモニタ報告比 10.7 倍、TTM(Time-To-Mitigate)で 3.75 倍長くなることを定量化した ([[@2023__ESEC-FSE__Detection Is Better Than Cure - A Cloud Incidents Perspective|Ganatra+ ESEC/FSE2023]])。「アラートをどう設計し、いかに賢く絞り、いかに自動で処理するか」、そして根本的に「**そもそも何を監視すべきか**」は、過去 40 年で順に積層されてきた研究テーマである。 本ノートは、wiki に蓄積された 300 本超のソースのうちアラーティング関連を横断し、年代別に「**当時の問題意識・代表的手法・残された遺産**」の三要素で連続的な進歩を描く。読み筋は単純で、アラーティングは (1) 静的閾値による単純通知、(2) 機械学習による noise 抑制と重要度推定、(3) サービスレベル目標(SLO)を起点とする症状ベース呼び出し、(4) アラート同士を束ねる集約と動的グラフ表現、(5) 大規模言語モデル(LLM)による解釈と意思決定支援、そして (6) 自律エージェントへ受け渡す前段としての再定位、という順で意味論を変えてきた。 --- ## 2. 1980 年代から 2000 年代前半 — 理論的下地と ITSM の成立 アラーティングが研究分野になる前から、二つの土台が築かれていた。一つは Bainbridge "Ironies of Automation" (1983) と Gray "Why Do Computers Stop and What Can Be Done About It" (Tandem 1985) に代表される、自動化と障害分類の理論である。前者は「自動化されたシステムほど人間オペレータが異常状況で消耗する」逆説を示し、後の alert fatigue / OCE burnout 議論の祖となった。もう一つは商用ネットワーク管理システム(HP OpenView, IBM Tivoli, BMC Patrol)が定着させた「SNMP トラップ + 静的閾値」の運用慣行で、これが少なくとも 2010 年代まで業界の事実上の標準として残った。 2000 年代前半には、Oppenheimer らの "Why Do Internet Services Fail" (USITS2003) と Hamilton の "On Designing and Deploying Internet-Scale Services" (LISA2007)、 Bahl の多層依存性推論 NetMedic (SIGCOMM2007) が、インターネットサービス特有の障害像と依存伝播を経験的に明らかにした。これらは「アラート」を主題に据えた研究ではないが、後のアラート集約・伝播研究の前提となる「依存トポロジ上の障害連鎖」という見立てを提供した。同じ時期に産業界では **ISA 18.2 / EEMUA 191** が「alarm flood = 10 件/10 分/オペレータ」を標準化した。後年このしきい値は、IT サービスの alert storm が「10 件/分」「数千件/15 分」と桁違いに大きい別問題であることを示す対照点として繰り返し引用される ([[@2024__JNCA__A survey on intelligent management of alerts and incidents in IT services|Yu+ JNCA2024]] §3.2)。 ## 3. 2009〜2014 — 機械学習が「noise の自動抑制」と「重要度ランキング」を担い始める 最初の独立した研究的進歩は 2009 年、 [[NEC Laboratories America]] の Jiang らによる ICAC 論文 ([[@2009__ICAC__Ranking the Importance of Alerts for Problem Determination in Large Computer Systems]]) に現れる。Jiang らは「不変条件ネットワーク」と NTV(Normal Traffic Value)ピアレビューを用いた**教師なし**ランキングを提案し、ARX モデルで等価閾値を計算することでメトリクス横断比較を可能にした。これは後にアラートランキング 3 ルーツ(教師なし不変条件 / 教師なし統一最適化 / 教師あり ML)の第一ルートとして整理される([[アラートランキング]])。 3 年後、 [[IBM]] T.J. Watson Research Center と [[Florida International University]] の Tang らが NOMS2012 ([[@2012__NOMS__Optimizing System Monitoring Configurations for Non-Actionable Alerts]]) で、商用 [[IBM Tivoli]] 本番に向けて「ルール条件と最適遅延時間」をオフラインで月次バッチ最適化する手法を提示した。重要なのは、Tang らがアラートを「真偽分類」するのではなく「SLA の許す範囲で遅延させ、transient は自然消滅させ、real だけが通常通り発火する」というパラダイム転換を行い、Theorem 1 で**リアル見逃しゼロを数学的に保証**した点である。本番運用で非アクション可能アラートを最大 75% 削減したこの研究は、12 年後の Bhukar+ ICSE-SEIP2024 に「動的オンライン版」として継承され、保証様式が「数学的存在保証」から「経験的近似保証」へと変化する 12 年の進化軸を作った([[アラート抑制]] §横断的知見)。 2014 年には [[IBM Research]] の Lin らが KDD2014 ([[@2014__KDD__Unveiling Clusters of Events for Alert and Incident Management in Large-Scale Enterprise IT]]) で、同一エンタープライズの 5M アラート + 67k インシデントに対し、半構造化アラートには Jaccard + connected components + graph-cut、非構造化インシデントには NMF + KD-tree + complete-linkage を使い分けるクラスタリング手法を示した。これは集約手法における「ペア類似度世代」の出発点であり、word cloud の「順序を失う」限界を (word, position) タプル可視化で解決した点で、「機械が出す集約結果を OCE に読解可能な形に翻訳する責務」という設計圧力を明示した([[アラート集約]] §横断的知見)。 ## 4. 2015〜2018 — 時系列基盤、SLO 駆動アラーティング、ストリーム統計 2015 年の Gorilla (VLDB2015) は、 [[Facebook]] における in-memory 時系列データベース(TSDB)で、後のアラーティングが「時系列クエリ上で評価されるルール」という形を取る前提を作った。 2020 年の ByteSeries (SoCC2020) もこの流れを延長する。 業界規範として決定的だったのは 2016 年の Google **SRE Book** である。とくに [[@2016__OReilly__SRE Book - Chapter 6 Monitoring Distributed Systems|Ch. 6 Monitoring Distributed Systems]] と [[@2016__OReilly__SRE Book - Chapter 10 Practical Alerting from Time-Series Data|Ch. 10 Practical Alerting from Time-Series Data]]、 そして [[@2016__OReilly__SRE Book - Chapter 4 Service Level Objectives|Ch. 4 Service Level Objectives]] が、「4 ゴールデンシグナル」「症状ベース呼び出し(symptom-based alerting)」「エラーバジェット」という三つの規範語彙を導入した。原因ベース(CPU 高負荷で呼ぶ)から症状ベース(ユーザに影響しているから呼ぶ)へという視点転換は、後続の TraceArk・AlertRank・SkyNet のすべてが暗黙の前提とする規範となった。 2017 年、Siffer らは KDD2017 ([[@2017__KDD__Anomaly Detection in Streams with Extreme Value Theory|SPOT/DSPOT]]) で、極値理論(Extreme Value Theory, EVT)による Peaks-Over-Threshold と一般化パレート分布(GPD)を組み合わせ、リスクパラメータ q ひとつだけで動作するストリーム異常検知器を提案した。分布仮定不要・閾値手動設定不要という性質は、3 年後の Zhao+ ICSE-SEIP2020 がアラートストーム検知器に採用することで、本領域の理論的基礎として定着する([[アラートストーム]] §横断的知見)。 2018 年は SLO 駆動アラーティングの規範化の年だった。 [[Jamie Wilkinson]] が SREcon18 Asia ([[@2018__SREcon18 Asia__A Theory and Practice of Alerting with Service Level Objectives]]) で「symptom-based alert = SLO が違反される危険にあるときのみ page する」設計を `Page if 15m rate over 70` といった具体パラメータと共に示し、 [[@2018__Google SRE Workbook__Alerting on SLOs|Google SRE Workbook]] が multi-window multi-burn-rate 呼び出しを業界規範に押し上げた。同じ年、Lin らが CIKM2018 で **CAR** ([[@2018__CIKM__Collaborative Alert Ranking for Anomaly Detection]]) を発表し、Pitman-Yor 階層ベイズとエンティティ埋め込みを統一凸最適化で同時に解くことで、個別アラート重要度と多段攻撃シナリオを同じ確率モデルで同時ランキングできることを示した(ROC-AUC 0.998)。これはランキング 3 ルーツの第二ルート(教師なし統一最適化)であり、後の AlertRCA(2024) が「アラートだけで根本原因を取り出す」礎を築いた([[アラートランキング]])。 ## 5. 2020 — 5 介入点が「各論」として揃う、LLM 前夜の集大成 2020 年は研究的に一つの結節点だった。 [[Tsinghua University]] / [[Tencent]] / [[Microsoft]] / [[Alibaba]] らがそれぞれ独立に研究を進めた結果、アラーティングを「抑制 → フィルタリング → 集約 → ランキング → RCA」という 5 つの介入点で系統的に整理できるようになった。 集約とストームの代表手法は **AlertStorm** ([[@2020__ICSE-SEIP__Understanding and Handling Alert Storm for Online Service Systems|Zhao+ ICSE-SEIP2020]]) である。China EverBright Bank の 3 年 300 万件超アラートに対し、SPOT 由来の EVT で「いまストーム中か」を検知し、テキスト類似度とトポロジ距離の重み付き組み合わせ(α=0.6)で 4 段要約を行うことで、 effort reduction 98% 超を達成した。同論文は後年 [[アラートアンチパターン]] の A6 Cascading Alerts の原典として位置付けられる。 ランキングの第三ルート(教師あり ML)は同じく Tencent の **AlertRank** ([[@2020__ISSRE__AlertRank - Automatically and Adaptively Identifying Severe Alerts for Online Service Systems]]) で実装された。Resolution Record(解決記録)の TF-IDF + k-means クラスタリングで severity を**自動ラベル付け**したのち、XGBoost の incremental learning で F1 = 0.89 を達成し、ソフトウェア変更後の劣化(F1 0.68)を 0.88 まで回復する適応性を示した。Resolution Record という暗黙のラベル源に依存する設計は、解決記録が未整備の組織での適用可能性という課題を後年に残す([[Quality of Alerts]] §横断的知見)。 抑制の系譜では、 [[University of Stuttgart]] の Mormul らが CLOUD2020 で **DEAR** ([[@2020__CLOUD__DEAR - Distributed Evaluation of Alerting Rules]]) を提案した。BET(Binary Expression Tree)中間表現でアラートルール評価を VM に自動分散し、TTI(Time-To-Insight)を集約間隔依存(最大 27 秒)から定値 ~370ms に短縮した。これは「発火後フィルタリング」とも「rule refinement」とも独立な「**監視評価インフラ層**」の介入として、5 介入点の上流ゼロ番目を提示した([[アラート管理]] §横断的知見)。 [[Microsoft]] 系では DeepIP ([[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]]) が attention 付き CNN で incidental incident を判定し(AUC 0.808)、「全アラート = incident」設計を下流判定器で支えるという同社固有のアーキテクチャを成立させた。Tsinghua/Tencent 系統が「上流の rule refinement で生成自体を抑える」のに対し、Microsoft 系統は「下流の incidental 判定で優先順位を後回しにする」という対照的な設計選択がこの時期に明示された([[アラート管理]] §横断的知見)。 ## 6. 2022〜2023 — アンチパターン経験論、動的グラフ、アクショナビリティ軸の登場 2022 年、 [[The Chinese University of Hong Kong]] の [[Michael R. Lyu]] と [[Huawei Cloud]] の連携で発表された Yang+ DSN2022 ([[@2022__DSN__Characterizing and Mitigating Anti-patterns of Alerts in Industrial Cloud Systems]]) は、研究と現場の対話を再定式化した。Huawei Cloud の 2 年・400 万件超アラートと 18 OCE 調査から、個別 4 種(Unclear Name, Misleading Severity, Improper Generation Rule, Transient and Toggling)と集合 2 種(Repeating Alerts, Cascading Alerts)の 6 アンチパターンを実証同定し、さらに **QoA(Quality of Alerts)= indicativeness / precision / handleability** の 3 軸自動評価枠組みを将来方向として提案した([[Quality of Alerts]])。Cascading Alerts は Zhao+ 2020 のアラートストームを集合アンチパターンとして再定式化したものに相当し、両者は同一現象に対する下流対処と上流防止の二面で補完関係に立つ([[アラートアンチパターン]] §横断的知見)。 同年、 [[Fudan University]] の Chen らが ICSE2022 で **OAS** ([[@2022__ICSE__Online Summarizing Alerts through Semantic and Behavior Information]]) を発表し、ASR(BERT)・ABR(LSTM)・ACT を統合する教師あり深層学習でアラート集約を行った。CMDB に依存せず、意味的に異なるアラートでも同一障害として集約できる性質は、後の Fudan 三部作(OAS → DyAlert → ProAlert)の出発点となる。 2023 年には、それまでの研究系譜と直交する別軸が **Microsoft** から登場した。 Ganatra らの ESEC/FSE2023 論文 ([[@2023__ESEC-FSE__Detection Is Better Than Cure - A Cloud Incidents Perspective]]) は、 Microsoft の 300 超サービス・1 年間・約 950 件の本番インシデントを精査し、 vote-k 選択 + GPT-3.5 疑似ラベリング + 手動検証で 579 件の修正項目(repair items)を分析する大規模実証研究を行った。発見は厳しい。これまでの本領域がほぼ全て「**既にあるアラートをどう良くするか**」(抑制・フィルタリング・集約・ランキング・RCA)を扱ってきたのに対し、 Ganatra らは「**そもそもアラートが無いこと**」が検知失敗の最大要因(全修正項目の **40.41%**)であることを示した。残りは Missing/improper signal 18.13%、 Incorrect alerting logic 12.78%、 Improper monitor coverage 10.02%、 Buggy monitor 5.87%、 Others (TSG 等)6.39% の 5 カテゴリに分解される。検知失敗の影響は前述の 27.25% アウテージ率 + 10.7 倍 TTD + 3.75 倍 TTM で定量化され、修正項目の 85% 超が High/Medium 優先度として運用に上がってくる。Ganatra らはさらに、サービス機能 / 成熟度 / 依存関係数 / SLA の有無 / SLI クラスタの 5 軸でカテゴリ分布が有意に変動することを chi 二乗検定(95%)で示し、「**サービス成熟度は『何を監視すべきか』を決め、依存関係数は『どう監視すべきか』を決める**」「**SLA はモニタの存在を保証するが、設定の適切さや網羅性は保証しない**」という設計指針に翻訳した。 Yang+ DSN2022 のアンチパターンが「既存アラートの 6 種の失敗形」を経験的に取り出したのに対し、 Ganatra+ 2023 は「アラートが**存在するかどうか**」というメタ層の失敗を独立軸として可視化した点で相補的である。同論文は併せて、依存関係を 40% 超共有するサービス間で「ある第 1 インシデントの修正情報を第 2 サービスへ自動推奨する」 intelligent monitoring framework を将来展望として例示し、 2 年後の AlertGuardian の rule refinement 系統が本番に上げる「上流改善」の motivation を経験論で支えた。 集約手法の面では、 2023 年は「ペア類似度世代」から「動的グラフ世代」へ世代交代した転換点だった。Fudan 三部作の第二作 **DyAlert** ([[@2023__ASE__Dynamic Graph Neural Networks-Based Alert Link Prediction for Online Service Systems]]) は、アラートストームを「アラート伝播が引き起こす現象」と再定義し、AMDG(Alert-Metric Dynamic Graph)を異種 k-GNN + GRU で表現してリンク予測タスクへ落とし込んだ。Alibaba 85 BU で F1 が 0.259 向上し、時系列情報の単独寄与が +5.6% であることをアブレーションで示した([[アラート集約]] §横断的知見)。 同年、 [[Microsoft]] Exchange チームの Zeng らが ICSE-SEIP2023 で **TraceArk** ([[@2023__ICSE-SEIP__TraceArk - Towards Actionable Performance Anomaly Alerting for Online Service Systems]]) を発表し、ランキングの目的関数を severity から **impact + interpretability の 2 軸 actionability** へと拡張した。ExL(排他的レイテンシ)を基軸にパス粒度でトレースを集約し、半教師あり XGBoost に 10〜30 件のエンジニア評価をフィードバックすることで F1 0.74 を達成、本番 4 ヶ月運用で適合率 0.9068(従来手法の 2.38 倍)に達した([[アクショナブルアラート]])。これは [[Quality of Alerts]] の handleability 軸を機械的に計算可能な指標に落とした最初の具体例と読める。 弱教師の系譜では、Voutsas らが JCC2023 ([[@2023__JCC__Filtering Alerts on Cloud Monitoring Systems]]) で **Netdata** の本番データを用い、OCE のクリック行動を弱教師信号にした Random Forest フィルタを提案した。精度 70%・推論 7.3ms。同年の [[@2023__arXiv__ESRO - Experience Assisted Service Reliability against Outages|ESRO]] は過去のポストモーテムレポートとアラートデータから CK グラフを構築し、リアルタイムアラートのみで根本原因と緩和手順を Rouge +27/+39% で推薦する経験ベース診断を示した。 [[CNCF]] の Observability Whitepaper も同年に整備され、業界用語の合意形成が一区切りついた。 ## 7. 2024 — LLM 第 1 波: 役割分化と「上流の rule refinement」への回帰 2024 年は、LLM がアラート系のどこに置かれるべきかが急速に分化した年である。同じ「LLM × アラート集約」というラベルでも、内実は三系統に分かれる([[アラート集約]] §横断的知見)。 第一に **COLA** ([[@2024__ICSE-SEIP__Knowledge-aware Alert Aggregation in Large-scale Cloud Systems - a Hybrid Approach|Kuang+ ICSE-SEIP2024]])(CUHK + Huawei Cloud)は LLM を SOP 解読器として使い、高頻度ペアは統計で即決し、低頻度・semantic 不一致のペアだけを LLM が SOP の domain knowledge で因果推論するハイブリッド分業で F1 0.9 超を達成した。第二に Zha+ Electronics2024 ([[@2024__Electronics__Leveraging Large Language Models for Efficient Alert Aggregation in AIOPs]]) は LLM を Service Dependency Graph(SDG)マッパーとして使い、時間 → 空間 → 因果の 3 段階集約を実現した。第三に **MonitorAssistant** ([[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]]) はクラウドサービス監視のオーサリング支援を LLM で簡素化した。 抑制の系譜では、 [[IBM Research]] の Bhukar らが ICSE-SEIP2024 ([[@2024__ICSE-SEIP__Dynamic Alert Suppression Policy for Noise Reduction in AIOps]]) で、教師なし統計学習(移動平均エンベロープ)で X-out-of-Y ポリシーを各メトリクス・サービスに個別最適化し、**教師あり上界に到達**する反直感的結果を示した。Industrial TcpRetrans 事例で 61.53% のノイズ削減を達成し、 12 年前の Tang+ NOMS2012 と同じ IBM 系統の進化として「数学的存在保証 → 経験的近似保証」「バッチ deploy → オンライン学習」の遷移を象徴する事例となった([[アラート抑制]] §横断的知見)。 アラートのみで RCA を行う系統では、Yu+ CCGrid2024 の **AlertRCA** ([[@2024__CCGRID__AlertRCA - Causality Enhanced Graph Representation Learning for Alert-Based Root Cause Analysis]]) が CPGAT + DAGNN を組み合わせ、トレースやメトリクス無しでも top-1 83.9% / top-3 96.8% を達成し、Groot を超えた。これは CAR(2018)の「アラートだけで攻撃シナリオを復元する」直系の発展形である([[アラートランキング]] §横断的知見)。 HPC ドメインでは、 [[National University of Defense Technology]] の Yuan らが ISSRE2024 で **SuperAgg** ([[@2024__ISSRE__Exploring Hierarchical Patterns for Alert Aggregation in Supercomputers]]) を発表し、「断続的アラートストーム」(クラウド)とは異なる「連続的アラート過負荷」(98 万〜211 万件/130 日)を独立カテゴリとして提示した。Apriori によるシステム層の主従関係マイニングと SOM ベースのセンサ層パターン抽出を組み合わせる 2 段階階層構造で、クラウド向け手法の単純流用では機能しないことを実証した([[アラートストーム]] §横断的知見)。 そして同年、 [[Tsinghua University]] の Yu らが JNCA サーベイ ([[@2024__JNCA__A survey on intelligent management of alerts and incidents in IT services]]) で、 AIM(Alert and Incident Management)を 8 プロセス(3 alert + 5 incident)で体系化した。Alert 側は **correlation / storm handling / determination** の 3 プロセスで、 incident 側の上流に明示的に位置付けられる。本サーベイは本領域における初の包括的整理であり、後続研究の参照軸となる。 ## 8. 2025 — LLM 第 2 波: ライフサイクル全段化と severe failure の別系統化 2025 年は、 LLM をアラート生成から rule 改善までの**ライフサイクル全段**に組み込む試みが進む一方、 LLM では扱いきれない領域が逆に明確化した年でもあった。 [[Tsinghua University]] と [[Tencent]] の **AlertGuardian** ([[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]]) は denoise → summary → rule refinement のライフサイクル一括処理を実装した。とくに rule refinement では 1,174 件のルール改善提案を生成し、 OCE による受容率 32%(375 件採用)を本番で達成した。これは Yang+ DSN2022 が指摘した「false alarm を上流のルール設計で潰す」設計を、 LLM で実装した実例である。 同じ Tsinghua 系の **LogPilot** (ASE2025) は intent-aware で scalable なアラート診断を行い、 LLM × SOP の応用を別角度から拡張した。 アラート集約の後段としての「**alert incident analysis**」を独立タスクとして定式化したのが **VOCE** ([[@2025__FASE__VOCE - A Virtual On-Call Engineer for Automated Alert Incident Analysis Using a Large Language Model]]) である。Chen らは Company A の 827 incidents を分析し、「時間順最初の alert が根本原因である」割合がわずか 45.34% だと実証否定した。代わりに system layer / impact scope / severity の 3 因子で originating alert を判定し、各因子で 93-95% の一致率を達成した([[アラートインシデント分析]])。 [[Alibaba Cloud]] の **SkyNet** ([[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures]]) は、本領域における重要な反例として **LLM を意図的に不採用**とした。 89 DC × 10⁵ デバイス規模での「severe failure(年間数回しか起きないが損失の大半を占める障害)」は Syslog 10M エントリ/15 分が既存 LLM の 20M トークン context をリアルタイム超過し、 hallucination のブラックボックス性が運用上許容できないため、 deep learning ベースの DeepIP も適用できない。SkyNet は Failure / Abnormal / Root cause の 3 分類 × Region〜Cluster の 6 階層という構造化アプローチで 1.5 年運用に耐え、 false negative 0% を達成した。これは「LLM 採用 / 不採用の境界」が context window 容量と severity 要件で動的に定義されることを明文化した最初の事例である([[アラート集約]] §横断的知見)。 Fudan 三部作の完結作 **ProAlert** ([[@2025__FSE__Alert Summarization for Online Service Systems by Validating Propagation Paths of Faults]]) は、教師なし設定で CMDB と歴史的アラートから fault propagation patterns を DBSCAN で学習し、S1 VCR 93.53% を 200+/1280+ alerts/sec の推論速度で達成した。本作は「トポロジの接続性 vs エッジのセマンティクス」という新軸を提示し、 DyAlert の「接続性のみ」を見る集約から「伝播のしやすさ」を学習で区別する段階へと進めた([[アラート集約]] §横断的知見)。 ## 9. 2026 — Agentic 第 1 波: 「閾値設計の不要化」と autonomous handler への受け渡し 2026 年に入って、アラーティングは「人間に通知する仕組み」から「**自律エージェントの入力**」へと意味論を変えつつある。 [[Google]] の "AI in SRE" ブログ ([[@2026__Google Cloud Blog__AI in SRE - Where Google is Deploying Agentic AI to Improve Operations]]) は、 3 段アーキテクチャを明示した。(1) 異常検知を時系列基盤モデル([[TimesFM]] が例示)に委ね、 historical signals から顧客指向 SLO を予測する。(2) anomaly が alert を起こすと、 **SRE AI alerting agent** が group / pre-process / enrich する。(3) enriched alert は **autonomous AI alert handlers** に流れ、その多くを自律処理・緩和する。これは「ルール改善で上流を狭くする」 AlertGuardian の方向に対し、「**閾値設計自体を不要にする**」異なる方向を示している([[アラート管理]] §横断的知見)。 ネットワーク監視の系譜では **Harp** ([[@2026__NSDI__Harp - Improving VPC Network Availability via Efficient Failure Detection and Rerouting in Tencent Cloud]])(Tencent NSDI2026)が VPC ネットワークの failure detection と rerouting を統合した自律対応を本番運用した。 [[Datadog]] の Bits AI SRE は autonomous incident investigation agent を商用サービスとして公開し、 ASE2026 の OpsAgent はマイクロサービスのインシデント管理を multi-agent で扱う。 [[SREGym]] や Cloud-OpsBench などのライブベンチマークも 2026 年に整備され、評価インフラが本領域に追いついた。 ## 10. 通時的に観察される 4 つの大潮流 40 年弱の進歩を通して、4 つの潮流が見える。 第一に**介入点の細分化**である。 2007 年頃に「閾値 + 通知」として一体だったアラーティングは、 2024 年までに **監視評価 → 抑制 → フィルタリング → 集約 → ランキング → RCA → autonomous handler** の 6+1 層に分解された。Ganatra+ ESEC/FSE2023 がさらに前置する「**そもそも monitor は存在するか / 何を監視すべきか**」というメタ層を加えると、現在の研究地図は実質「**(0) monitor 存在判定 → (1) 監視評価 → (2) 抑制 → (3) フィルタリング → (4) 集約 → (5) ランキング → (6) RCA → (7) autonomous handler**」の 8 層構造を持つ。各層で代表手法と評価指標が独立に成熟しており、 5 介入点を end-to-end の単一パイプラインとして本番運用した報告はいまだ存在しない([[アラート管理]] §未解決の問い)。 第二に**保証様式の変化**である。 Tang+ NOMS2012 の「数学的存在保証(Theorem 1)」から Bhukar+ ICSE-SEIP2024 の「教師あり上界に到達する経験的近似」へと、 12 年で保証の様式が緩んだ。これは教師あり機械学習が本領域で十分に成熟した結果として、保証の必要条件が「証明可能性」から「再現可能な近似性能」へとシフトしたことを意味する([[アラート抑制]] §横断的知見)。 第三に**集約アルゴリズムの世代交代**である。 ペア類似度(Jaccard + graph-cut, 2014)→ 動的グラフ表現学習(k-GNN + GRU, 2023)→ 教師なしトポロジセマンティクス(CMDB + DBSCAN + propagation path validation, 2025)という三段進化を Fudan 三部作と Microsoft / Tsinghua 系統が並走的に駆動した。「離散時刻のスナップショット」から「時間とグラフ構造の同時表現」、さらに「ラベル不要かつ伝播方向の semantics 抽出」へという軸シフトが連続している([[アラート集約]] §横断的知見)。 第四に **LLM の役割と境界**である。 2024 年の 3 役割分化(SOP 解読 / SDG マッパー / 多因子分析)は、 2025 年の SkyNet で「**severe failure では LLM を意図的に不採用**」という反例を生んだ。この境界は次世代 LLM の context window 拡張(Gemini 1.5 の 2M、潜在的に 100M 級)で動的に再定義され続けるため、 2026 年以降も再評価が必要となる([[アラートストーム]] §未解決の問い)。 ## 11. まだ答えのない問い 本領域には、 wiki の各 concept ページの「未解決の問い」節を横断して見ると、次の四点が重要な空白として残る。 **(a) end-to-end パイプラインの本番運用報告がない**。 5(+1)介入点を直列で運用し、各層の精度寄与を分解した実証研究は、 2026 年時点で文献的痕跡が薄い。 **(b) ランキング 3 ルーツの定量比較がない**。 教師なし不変条件(Jiang+ 2009)・教師なし統一最適化(CAR 2018)・教師あり ML(AlertRank 2020)を同一データセットで比較した研究は未着手で、 どのルーツがどの障害タイプ・どの規模で優位かの系統的整理がない([[アラートランキング]] §未解決の問い)。 **(c) 「断続的ストーム」と「連続的アラート過負荷」の中間形態**——例えば商用クラウドの日中だけ高頻度になる周期的バースト——を統一的に扱う検知器が未提案である。 EVT は断続前提、 Apriori は持続前提で、両方を同時に処理するアーキテクチャが必要となる([[アラートストーム]] §未解決の問い)。 **(d) agentic SRE 時代における「アラート」の意味論再定義**が未整理である。 人間通知を目的とする従来のアラート設計と、 autonomous handler の入力を目的とする新世代の設計とでは、 actionability の基準も評価指標も異なる可能性が高い。 Google の 3 段アーキテクチャ(2026)が示唆するこの変化を理論化する研究はまだ存在しない。 **(e) 検知失敗(monitor 不在)の予防が事業者横断で再測定されていない**。 Ganatra+ ESEC/FSE2023 が示した 6 カテゴリ taxonomy(Missing monitor/alert 40.41% を筆頭)と 5 軸サービス特性相関(機能 / 成熟度 / 依存関係数 / SLA / SLI)は、 Microsoft の 300 超サービスを対象とした単一事業者データに基づく。同論文が将来展望として示した「依存共有サービス間での修正知見の自動転送」(intelligent monitoring framework)を本番運用した報告もまだない。 2025 年の AlertGuardian の rule refinement が motivation の一部を引き継いだが、 "missing monitor" を上流で予防する系統的フレームワークは未確立である。 これらの空白は、本領域が「個別介入点の各論」から「介入点をまたぐ統合論」、さらに「アラートが存在する前提を疑う統合論」へ移行する次の研究フェーズの輪郭を示している。 --- ## 関連 - 親概念群: [[アラート管理]] / [[アラート抑制]] / [[アラートフィルタリング]] / [[アラート集約]] / [[アラートランキング]] / [[アラートストーム]] / [[アクショナブルアラート]] / [[アラートアンチパターン]] / [[Quality of Alerts]] / [[アラートインシデント分析]] - 上位文脈: [[AIOps]] / [[インシデント管理]] / [[オブザーバビリティ]] / [[agentic SRE]] - 関連 MOC: `structures/LLM4SRE - MOC` / `structures/000 Index` ## 出典 frontmatter の `sources` に列挙した一次・二次ソースに加え、 wiki/concepts の以下のページで横断的知見を確認した: - [[アラート管理]] §横断的知見(5 + 1 介入点の細分化、IBM 系 12 年遷移、 Microsoft / Tsinghua 系統の対比) - [[アラート集約]] §横断的知見(LLM 役割 3 分化、 LLM 採用境界、 Fudan 三部作) - [[アラートストーム]] §横断的知見(SPOT/Zhao+ 連結、断続/連続の対比、 severe failure 第三カテゴリ) - [[アラート抑制]] §横断的知見(IBM 系 12 年遷移、 X-out-of-Y の汎化失敗) - [[アラートフィルタリング]] §横断的知見(クリック弱教師、 DEAR の評価層介入) - [[アラートランキング]] §横断的知見(3 ルーツ対照) - [[アクショナブルアラート]] §横断的知見(impact + interpretability の 2 軸化) - [[アラートアンチパターン]] §横断的知見(Yang+ 2022 の 6 分類、 A4 動的抑制、 A2 自動ランキング) - [[Quality of Alerts]] §横断的知見(3 軸自動評価、 TraceArk による handleability の機械化) - [[アラートインシデント分析]] §定義(VOCE の独立タスク化)