# アラーティングの進歩 — 年代別レビュー ## 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) 機械学習によるノイズ抑制と重要度推定、(3) サービスレベル目標(SLO)を起点とする症状ベース呼び出し、(4) アラート同士を束ねる集約と動的グラフ表現、(5) 大規模言語モデル(LLM)による解釈と意思決定支援、そして (6) 自律エージェントへ受け渡す前段としての再定位、という順で意味論を変えてきた。 --- ## 2. 1980 年代から 2000 年代前半 — 理論的下地と ITSM の成立 アラーティングが研究分野になる前から、二つの土台が築かれていた。一つは Bainbridge "Ironies of Automation" (1983) ([[@1983__Automatica__Ironies of Automation]]) と Gray "Why Do Computers Stop and What Can Be Done About It" (Tandem 1985) ([[@1985__Tandem__Why Do Computers Stop and What Can Be Done About It]]) に代表される、自動化と障害分類の理論である。前者は「自動化されたシステムほど人間オペレータが異常状況で消耗する」逆説を示し、後のアラート疲労 / OCE バーンアウト議論の祖となった。もう一つは商用ネットワーク管理システム(HP OpenView, IBM Tivoli, BMC Patrol)が定着させた「SNMP トラップ + 静的閾値」の運用慣行で、これが少なくとも 2010 年代まで業界の事実上の標準として残った。 2000 年代前半には、Oppenheimer らの "Why Do Internet Services Fail" (USITS2003) ([[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]]) と Hamilton の "On Designing and Deploying Internet-Scale Services" (LISA2007) ([[@2007__LISA__On Designing and Deploying Internet-Scale Services]])、 Bahl の多層依存性推論 NetMedic (SIGCOMM2007) ([[@2007__SIGCOMM__Towards Highly Reliable Enterprise Network Services via Inference of Multi-level Dependencies]]) が、インターネットサービス特有の障害像と依存伝播を経験的に明らかにした。これらは「アラート」を主題に据えた研究ではないが、後のアラート集約・伝播研究の前提となる「依存トポロジ上の障害連鎖」という見立てを提供した。同じ時期に産業界では **ISA 18.2 / EEMUA 191** が「アラーム洪水 = 10 件/10 分/オペレータ」を標準化した。後年このしきい値は、IT サービスのアラートストームが「10 件/分」「数千件/15 分」と桁違いに大きい別問題であることを示す対照点として繰り返し引用される ([[@2024__JNCA__A survey on intelligent management of alerts and incidents in IT services|Yu+ JNCA2024]] §3.2)。 ## 3. 2009〜2014 — 機械学習が「ノイズの自動抑制」と「重要度ランキング」を担い始める 最初の独立した研究的進歩は 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 の許す範囲で遅延させ、一過性アラートは自然消滅させ、実アラートだけが通常通り発火する」というパラダイム転換を行い、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, position) タプル可視化で解決した点で、「機械が出す集約結果を OCE に読解可能な形に翻訳する責務」という設計圧力を明示した([[アラート集約]] §横断的知見)。 ## 4. 2015〜2018 — 時系列基盤、SLO 駆動アラーティング、実践者エコシステムの爆発 2015 年の Gorilla (VLDB2015) ([[@2015__VLDB__Gorilla - A Fast, Scalable, In-Memory Time Series Database]]) は、 [[Facebook]] におけるインメモリ時系列データベース(TSDB)で、後のアラーティングが「時系列クエリ上で評価されるルール」という形を取る前提を作った。 2020 年の ByteSeries (SoCC2020) ([[@2020__SoCC__ByteSeries - An In-Memory Time Series Database for Large-Scale Monitoring Systems]]) もこの流れを延長する。 業界規範として決定的だったのは 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 のすべてが暗黙の前提とする規範となった。 SRE Book が規範を打ち立てた 2016〜2017 年は、同時に実践者コミュニティが SREcon を舞台にアラート衛生(alert hygiene)の具体策を競い合った転換期でもあった。 [[Robert Treat]] (OmniTI CEO) は SREcon16 ([[@2016__SREcon16__Less Alarming Alerts]]) で、各アラートが「ビジネス影響・修復手順・通知先・予防可能性」の 4 問に答えられなければ削除・通知化・修正する**発火前ガバナンス**を提唱した。「OOM を人間に呼ぶのではなく自動修復チェーンを走らせ、全て失敗した場合のみページする」という自動化結合の初期形は、後の Google 自律ハンドラの思想的前駆に位置づけられる。同年 SREcon16 Europe では [[Björn Rabenstein]] (元 Google SRE、 [[Prometheus]] 共同開発者)が [[@2016__SREcon16 Europe__Alerting for Distributed Systems - A Tale of Symptoms and Causes, Signals and Noise]] で、「ページは症状・差し迫ったサービス問題に限り、原因はチケット・情報通知に回す」責務分離を [[Prometheus]] 実装と共に体系化した。Rabenstein はさらに「ページ用異常検知は単純・堅牢でなければならず、複雑な機械学習はページ経路に不向き」と明言し、後の SkyNet(2025)の LLM 不採用判断と共鳴する反自動化論の早期表出でもあった([[アクショナブルアラート]])。 2017 年には、地理的に散らばる 3 組織がほぼ同時に「アラート洪水の運用的解決」を報告した。 [[Baidu]] の [[Yu Chen (Baidu)|Yu Chen]] は SREcon17 Asia ([[@2017__SREcon17 Asia__Draining the Flood - A Combat against Alert Fatigue]]) で、内製監視 [[Argus (Baidu)|Argus]] の「1 人 1 日 100 件超・有効率 15% 未満」に対し、グルーピング・重要度キャリブレーション・エスカレーション・自動修復の 4 施策を組み合わせ **85% 削減**を達成した。独自の**アテンション率**(夜間のアラート詳細閲覧ログで「確認 vs 無視」を定義し重要度を客観補正する指標)は、 3 年後の AlertRank が提唱する resolution-record ベースの severity 自動ラベル付けを先行する着想である([[アラート疲労]])。 [[Zynga]] の [[Kishore Jalleda]] は SREcon17 Europe ([[@2017__SREcon17 Europe__Want to Solve Over-Monitoring and Alert Fatigue - Create the Right Incentives]]) で、アラート疲労の根本原因は技術ではなくインセンティブの不整合と断じ、**アラートバジェット**制(超過チームへの SRE サポート停止)で偽アラーム **90% 削減**・SRE 応答時間 5 分を達成した。技術的介入(Chen)と経済的介入(Jalleda)が同じ SREcon シリーズ・同じ年にいずれも 85〜90% 削減を達成した事実は、アラート衛生が「ツール vs 制度」の二面作戦であることを強く示唆する([[アラートポリューション]])。 [[Jamie Wilkinson]] も SREcon17 Americas ([[@2017__SREcon17 Americas__A Practical Guide to Monitoring and Alerting with Time Series at Scale]]) で「**監視の保守コストはサービス規模に対して劣線形に伸びなければならない**」を中心命題に据え、 SLI/SLO/SLA の 3 層定義に基づくアラート設計と [[Prometheus]] のラベル付き時系列による実装を提示した。ディスク満杯を「残量%」でなく「人間の修復時間 vs 枯渇までの時間の比較」で設計する原則の明示は、翌年の SLO 駆動アラーティング規範化の直接的な前駆となった。 大規模分散監視アーキテクチャの面では、 [[Cloudflare]] の [[Matt Bostock]] が SREcon17 Europe ([[@2017__SREcon17 Europe__Monitoring Cloudflare's Planet-Scale Edge Network]]) で、116 拠点のエッジネットワーク各 PoP に独立 [[Prometheus]] を配置しフェデレーションで集約する構成を報告した。「**監視対象と同じ障害ドメインに監視を置く**」という設計原則と、Alertmanager のゴシッププロトコルで「通知漏れより重複を選ぶ」フェイルセーフ設計は、 5 年後の同社 [[pint]] 開発(2022)——「ルールが静かに壊れていないか監視する」上流シフト——へ繋がる起点となった。 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) が「アラートだけで根本原因を取り出す」礎を築いた([[アラートランキング]])。 [[Alibaba Group]] では同年の SREcon18 Asia で [[Ren Xinchi]] が全社監視の 4 層構造(インフラ → システム/アプリ → ビジネス → 顧客フィードバック)を解説し ([[@2018__SREcon18 Asia__Introduction to Alibaba Monitoring System]])、 Google の 4 ゴールデンシグナルとは独立に **5 ゴールデンエレメント**(総数・成功数・成功率・応答時間・失敗数)を定義してビジネス層を最上位に位置付けた。独自 CMDB [[Hammurabi]] で KPI と P1〜P4 優先度を一元管理し、変更情報をグラフに重ね合わせること(障害の 70% が変更起因)で即時ロールバック判断を加速する実践は、後の ChangeLLM(2025)の motivation を先行的に示した。 ## 5. 2020 — 5 介入点が「各論」として揃う、LLM 前夜の集大成 2020 年は研究的に一つの結節点だった。 [[Tsinghua University]] / [[Tencent]] / [[Microsoft]] / [[Alibaba Group|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 段要約を行うことで、調査工数 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 に短縮した。これは「発火後フィルタリング」とも「ルール改善」とも独立な「**監視評価インフラ層**」の介入として、5 介入点の上流ゼロ番目を提示した([[アラート管理]] §横断的知見)。 [[Microsoft]] 系では DeepIP ([[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]]) がアテンション付き CNN で偶発的インシデントを判定し(AUC 0.808)、「全アラート = インシデント」設計を下流判定器で支えるという同社固有のアーキテクチャを成立させた。Tsinghua/Tencent 系統が「上流のルール改善で生成自体を抑える」のに対し、Microsoft 系統は「下流の偶発性判定で優先順位を後回しにする」という対照的な設計選択がこの時期に明示された([[アラート管理]] §横断的知見)。 ## 5.5. 2019〜2021 — 「通知先ルーティング」と「相関後フィルタリング」の各論化 §5 の研究系が 5 介入点を整備する前後で、産業界では既存介入点の隙間を埋める 2 つの独立した試みが報告された。 2019 年、 [[Zalando SE]] の [[Luis Mineiro]] が SREcon19 EMEA ([[@2019__SREcon19 EMEA__Are We All on the Same Page - Lets Fix That]]) で **Adaptive Paging** を提案した。マイクロサービス障害時に全サービスが同時発火する「クリスマスツリー効果」に対し、アラートルールは従来どおり症状側に置きつつ、**通知先の決定だけを分散トレーシングの因果関係で動的にルーティング**する設計である。OpenTracing のスパンタグ(`error=true`)を再帰的に辿りエラーパスの最深ノードを根本原因候補と推定することで、「誰を呼ぶか」を自動化した。これは既存の介入点(件数・重要度・内容の操作)に**通知先ルーティング**という直交する次元を追加した最初の本番実装であり、 FSF(IEEE CLOUD2022)が同型のスパンツリー動的因果推論を学術的に形式化する 3 年前の先行事例にあたる([[アラート管理]])。 2021 年、 [[LinkedIn]] の [[Nishant Singh]] が SREcon21 ([[@2021__SREcon21__Spike Detection in Alert Correlation at LinkedIn]]) で、アラート相関エンジンの出力に対する後段フィルタを報告した。外れ値にロバストな **MAD(中央絶対偏差)ベースの修正 Z スコア**(Iglewicz & Hoaglin)で一時的スパイクを分離し、 5 連続スパイク + グラフ 70% 同傾向のヒューリスティックで REAL ALERT / SPIKE を判定する。推奨 193 件中 36.4% をスパイクとして除去し、偽陽性率 1% 未満・トイル 30〜40% 削減を達成した。 ML 非依存の軽量統計手法が産業で選択される傾向は、後の AlertGuardian(2025)のノイズ除去段での Minder 採用とも一致する。入力段ノイズ除去(AlertGuardian)と出力段フィルタ(LinkedIn)の組み合わせ可能性は未検証のままである([[アラート相関]])。 ## 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)= 指示性 / 精度 / 処理容易性** の 3 軸自動評価枠組みを将来方向として提案した([[Quality of Alerts]])。Cascading Alerts は Zhao+ 2020 のアラートストームを集合アンチパターンとして再定式化したものに相当し、両者は同一現象に対する下流対処と上流防止の二面で補完関係に立つ([[アラートアンチパターン]] §横断的知見)。 同年、 QoA の別経路が産業側から独立に出現した。 [[Moshe Zadka]] は SREcon22 Americas ([[@2022__SREcon22 Americas__Modeling Alert Quality]]) で、アラート品質を **コスト**(アンチクオリティ = アラーティングコスト + 非アラーティングコスト)として定量化するフレームワークを提示した。アラームを真・偽・欠落の 3 種に分類し、とくに**欠落アラーム**を品質モデルに含める必要性を強調した(アラート追加・削除が欠落と真アラームを相互変換するため)。真アラームの解決レイテンシを「発生 → 検知 → 確認 → 診断 → 復旧」の 4 区間に分解する構造は、各介入点の投資対効果計算基盤として使える。Yang+ の QoA 3 軸が品質の構成を定義し、Zadka のコストモデルが各軸の改善効果を金銭換算する——同年に出た相補的な枠組みが、アラート品質を「主観的不満」から「測定可能な工学的対象」へ転換した([[Quality of Alerts]])。 同じく 2022 年、 [[Cloudflare]] は自社ブログ ([[@2022__Cloudflare-Blog__Monitoring-our-Monitoring]]) でオープンソースツール **[[pint]]** を公開し、 [[Prometheus]] アラートルールの「静かな故障モード」を体系化した。 Prometheus はクエリが何も返さないときエラーを出さないため、メトリクス名の廃止・ラベル変更・`rate()` の 2 点不足・recording rule チェーンの連鎖切断などで**アラートが来ない状態が正常か壊れているか区別できない**。 pint は CI モード(劣化の挿入を防ぐ)とデーモンモード(漸進的劣化を検出する)を組み合わせ、アラートの**発火前の健全性保証**という介入点を埋めた。Rabenstein(2016)が時系列クエリの強みを示した 6 年後に、同じ時系列クエリの壊れやすさを体系化した構造的逆説であり、「監視の監視」(meta-monitoring)という概念が事後的に必要になった好例である([[Prometheusルールリント]])。 [[Campspot]] の [[Kristin Smith]] も SREcon22 Americas ([[@2022__SREcon22 Americas__Dark Sky Camping - Reducing Alert Pollution with Modern Observability Practices]]) で、パンデミック期の急成長に伴いアラートとダッシュボードを増設し続けた結果「**アラートポリューション**(光害のアナロジー)」に陥った失敗事例を報告した。 OpenTelemetry 自動計装の移行コストは実際には約 4 時間だったが、認知バイアスにより 6 か月以上躊躇したこと、 SLO 導入時に非技術系ステークホルダーを巻き込まなかったことが組織摩擦を生んだことを開示した。「**モニタリングを増やす = 安全**」という心理的結合の診断は、 Jalleda(2017)のインセンティブ設計が処方にあたる相補関係を成す([[アラートポリューション]])。 同年、 [[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 のルール改善系統が本番に上げる「上流改善」の動機を経験論で支えた。 集約手法の面では、 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]]) を発表し、ランキングの目的関数を重要度から **影響 + 解釈可能性の 2 軸アクショナビリティ** へと拡張した。ExL(排他的レイテンシ)を基軸にパス粒度でトレースを集約し、半教師あり XGBoost に 10〜30 件のエンジニア評価をフィードバックすることで F1 0.74 を達成、本番 4 ヶ月運用で適合率 0.9068(従来手法の 2.38 倍)に達した([[アクショナブルアラート]])。これは [[Quality of Alerts]] の処理容易性軸を機械的に計算可能な指標に落とした最初の具体例と読める。 弱教師の系譜では、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 も同年に整備され、業界用語の合意形成が一区切りついた。 同じ 2023 年、技術的介入とは独立した**人間的・組織的介入**が複数の舞台で形を取った。 [[Chronosphere]] の [[Paige Cruz]] は SREcon23 Americas ([[@2023__SREcon23 Americas__Cognitive Apprenticeship in Practice with Alert Triage Hour of Power]]) で、アラートトリアージは生得的スキルではなく、**認知的徒弟制**(Modeling → Coaching → Scaffolding → Articulation → Reflection → Exploration の 6 段階)で体系的に伝達できると主張した。週 1 時間・4 ロール制(Facilitator / Driver / Scribe / Support)の構造化ミーティング「Alert Triage Hour of Power」を 3 年実施し、 KEEP / TUNE / DELETE の集団判定を通じてアラート衛生を組織文化に組み込んだ。スパムアラート削減率はゼロだったが「学習そのものが正当な目標」と結論づけた。これは §4 の Jalleda(インセンティブ設計)・Chen(技術的介入)に続く**第三のアプローチ——人間の判断能力の育成**——であり、AIM 分類(Yu+ JNCA2024)に含まれない「人間側のアラート衛生」介入点の提示でもある([[認知的徒弟制]])。 日本の SRE コミュニティでも、アクショナビリティを**発火後の調査準備**と**発火前の社会的合意**の二面で具体化する事例が報告された。 [[面白法人カヤック]] の [[池田将士]] は SRE NEXT 2023 ([[@2023__SRE NEXT__Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵]]) で、 Critical ほど即時対応でない **Warning アラート**の振り返り作業がトイル化する問題に対し、 OSS ツール [[prepalert]] で [[Mackerel]] Webhook → Lambda → CloudWatch Logs Insights / S3 / Redshift の自動証拠収集を実装した。 Warning 発火時点の文脈を保存することで低重要度アラートを放置せず調査可能な状態へ移す「**調査準備**」介入点は、既存の 5 介入点と直交する実装層を担う([[Warningアラート]])。 [[GREE, Inc]] の [[Sohei Iwahori]] は同じ SRE NEXT で ([[@2023__SpeakerDeck__Runbookに何を書き、どのようにアラートを振り分けるか]])、アラート追加時点で通知チャンネル・対応タイミング・スコープ・対応 Runbook を明示させる**上流統制**を報告した。 Runbook を「How(手順)」に限定せず「Why・背景・判断材料」を保存する器として再定義し、アラート追加前にアクションを合意させることでアラート自体の必要性を再検討させる設計は、 Treat SREcon16 の発火前ガバナンスを Runbook の形で制度化した継承例にあたる([[アクショナブルアラート]])。 ## 7. 2024 — LLM 第 1 波: 役割分化と「上流のルール改善」への回帰 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 解読器として使い、高頻度ペアは統計で即決し、低頻度・意味的不一致のペアだけを LLM が SOP のドメイン知識で因果推論するハイブリッド分業で 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 系統の進化として「数学的存在保証 → 経験的近似保証」「バッチデプロイ → オンライン学習」の遷移を象徴する事例となった([[アラート抑制]] §横断的知見)。 アラートのみで 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 アラート + 5 インシデント)で体系化した。アラート側は **correlation / storm handling / determination** の 3 プロセスで、インシデント側の上流に明示的に位置付けられる。本サーベイは本領域における初の包括的整理であり、後続研究の参照軸となる。 ## 8. 2025 — LLM 第 2 波: ライフサイクル全段化と severe failure の別系統化 2025 年は、 LLM をアラート生成からルール改善までの**ライフサイクル全段**に組み込む試みが進む一方、 LLM では扱いきれない領域が逆に明確化した年でもあった。 [[Sun Yat-sen University]] と [[Tencent]] の **AlertGuardian** ([[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]]) はノイズ除去 → 要約 → ルール改善のライフサイクル一括処理を実装した。とくにルール改善では 1,174 件のルール改善提案を生成し、 OCE による受容率 32%(375 件採用)を本番で達成した。これは Yang+ DSN2022 が指摘した「偽アラームを上流のルール設計で潰す」設計を、 LLM で実装した実例である。 別系統の [[The Chinese University of Hong Kong]] / [[ByteDance]] による **LogPilot** ([[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]]) は、意図認識型でスケーラブルなアラート診断を行い、 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 インシデントを分析し、「時間順最初のアラートが根本原因である」割合がわずか 45.34% だと実証否定した。代わりにシステム層 / 影響範囲 / 重要度の 3 因子で発端アラートを判定し、各因子で 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 トークンコンテキストをリアルタイム超過し、ハルシネーションのブラックボックス性が運用上許容できないため、深層学習ベースの DeepIP も適用できない。SkyNet は Failure / Abnormal / Root cause の 3 分類 × Region〜Cluster の 6 階層という構造化アプローチで 1.5 年運用に耐え、偽陰性 0% を達成した。これは「LLM 採用 / 不採用の境界」がコンテキストウィンドウ容量と重要度要件で動的に定義されることを明文化した最初の事例である([[アラート集約]] §横断的知見)。 Fudan 三部作の完結作 **ProAlert** ([[@2025__FSE__Alert Summarization for Online Service Systems by Validating Propagation Paths of Faults]]) は、教師なし設定で CMDB と歴史的アラートから障害伝播パターンを DBSCAN で学習し、S1 VCR 93.53% を 200+/1280+ alerts/sec の推論速度で達成した。本作は「トポロジの接続性対エッジのセマンティクス」という新軸を提示し、 DyAlert の「接続性のみ」を見る集約から「伝播のしやすさ」を学習で区別する段階へと進めた([[アラート集約]] §横断的知見)。 ## 9. 2026 — Agentic 第 1 波: 「閾値設計の不要化」と自律ハンドラへの受け渡し 2026 年に入って、アラーティングは「人間に通知する仕組み」から「**自律エージェントの入力**」へと意味論を変えつつある。 [[Google]] の "AI in SRE" ブログ ([[@2026__Google Cloud Blog__AI in SRE - Where Google is Deploying Agentic AI to Improve Operations]]) は、 3 段アーキテクチャを明示した。(1) 異常検知を時系列基盤モデル([[TimesFM]] が例示)に委ね、履歴シグナルから顧客指向 SLO を予測する。(2) 異常がアラートを起こすと、 **SRE AI alerting agent** がグループ化 / 前処理 / 文脈付与を行う。(3) 文脈付与されたアラートは **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 ネットワークの障害検知と迂回制御を統合した自律対応を本番運用した。 [[Datadog]] の [[Bits AI SRE]] は自律インシデント調査エージェントを商用サービスとして公開し([[@2026__Datadog__Building Bits AI SRE - Autonomous Incident Investigation Agent]])、 ASE2026 の OpsAgent はマイクロサービスのインシデント管理をマルチエージェントで扱う([[@2026__ASE__OpsAgent - An Evolving Multi-agent System for Incident Management in Microservices]])。 [[SREGym]]([[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]]) や Cloud-OpsBench([[@2026__arXiv__Cloud-OpsBench - A Reproducible Benchmark for Agentic Root Cause Analysis in Cloud Systems]]) などのライブベンチマークも 2026 年に整備され、評価インフラが本領域に追いついた。 ## 10. 通時的に観察される 5 つの大潮流 40 年弱の進歩を通して、5 つの潮流が見える。 第一に**介入点の細分化と上流シフト**である。 2007 年頃に「閾値 + 通知」として一体だったアラーティングは、 2024 年までに **監視評価 → 抑制 → フィルタリング → 集約 → ランキング → RCA → 自律ハンドラ** の 6+1 層に分解された。Ganatra+ ESEC/FSE2023 がさらに前置する「**そもそも監視は存在するか / 何を監視すべきか**」というメタ層を加えると、現在の研究地図は実質「**(0) 監視存在判定 → (0.5) ルール健全性保証 → (1) 監視評価 → (2) 抑制 → (3) フィルタリング → (3.5) 通知先ルーティング → (4) 集約 → (4.5) 相関後フィルタリング → (5) ランキング → (5.5) 調査準備 → (6) RCA → (7) 自律ハンドラ**」の 10 層超の構造を持つ。2022 年の pint がルール健全性保証(0.5 層)を、 2019 年の Adaptive Paging が通知先ルーティング(3.5 層)を、 2021 年の LinkedIn が相関後フィルタリング(4.5 層)を、 2023 年の prepalert が調査準備(5.5 層)をそれぞれ隙間として埋めた。また「発火後のノイズ削減 → 発火前のルール品質保証 → 追加前の社会的合意」という上流シフトが Cloudflare 単一事業者の 5 年間(Bostock 2017 → Rabenstein 型原則 → pint 2022)に凝縮して観察できる。各層で代表手法と評価指標が独立に成熟しており、 10 層超をエンドツーエンドの単一パイプラインとして本番運用した報告はいまだ存在しない([[アラート管理]] §未解決の問い)。 第二に**保証様式の変化**である。 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 系統が並走的に駆動した。「離散時刻のスナップショット」から「時間とグラフ構造の同時表現」、さらに「ラベル不要かつ伝播方向の意味抽出」へという軸シフトが連続している([[アラート集約]] §横断的知見)。 第四に **LLM の役割と境界**である。 2024 年の 3 役割分化(SOP 解読 / SDG マッパー / 多因子分析)は、 2025 年の SkyNet で「**重大障害では LLM を意図的に不採用**」という反例を生んだ。この境界は次世代 LLM のコンテキストウィンドウ拡張(Gemini 1.5 の 2M、潜在的に 100M 級)で動的に再定義され続けるため、 2026 年以降も再評価が必要となる([[アラートストーム]] §未解決の問い)。 第五に**人間的・組織的介入の独立軸化**である。技術的介入(ML・統計・LLM)と並行して、 2017 年に Jalleda のインセンティブ設計(アラートバジェット)と Chen の技術的 4 施策がいずれも 85〜90% 削減を達成した事実は、両者が互いに置換不可能な独立次元であることを示した。 2023 年には Cruz の認知的徒弟制(人間の判断能力の育成)が第三の次元として加わり、さらに Runbook ガバナンス(Iwahori)が「アラート追加前の社会的合意」として第四の面を追加した。Yu+ JNCA2024 の AIM 分類はこれらの非技術的介入を分類体系に含めておらず、「技術的介入 × インセンティブ設計 × 学習プログラム × 社会的合意」の 4 面を統合した運用事例は報告されていない([[アラート疲労]] §未解決の問い)。 ## 11. まだ答えのない問い 本領域には、 wiki の各 concept ページの「未解決の問い」節を横断して見ると、次の六点が重要な空白として残る。 **(a) エンドツーエンドパイプラインの本番運用報告がない**。 10 層超の介入点を直列で運用し、各層の精度寄与を分解した実証研究は、 2026 年時点で文献的痕跡が薄い。 **(b) ランキング 3 ルーツの定量比較がない**。 教師なし不変条件(Jiang+ 2009)・教師なし統一最適化(CAR 2018)・教師あり ML(AlertRank 2020)を同一データセットで比較した研究は未着手で、 どのルーツがどの障害タイプ・どの規模で優位かの系統的整理がない([[アラートランキング]] §未解決の問い)。 **(c) 「断続的ストーム」と「連続的アラート過負荷」の中間形態**——例えば商用クラウドの日中だけ高頻度になる周期的バースト——を統一的に扱う検知器が未提案である。 EVT は断続前提、 Apriori は持続前提で、両方を同時に処理するアーキテクチャが必要となる([[アラートストーム]] §未解決の問い)。 **(d) agentic SRE 時代における「アラート」の意味論再定義**が未整理である。 人間通知を目的とする従来のアラート設計と、自律ハンドラの入力を目的とする新世代の設計とでは、アクショナビリティの基準も評価指標も異なる可能性が高い。 Google の 3 段アーキテクチャ(2026)が示唆するこの変化を理論化する研究はまだ存在しない。 **(e) 検知失敗(監視不在)の予防が事業者横断で再測定されていない**。 Ganatra+ ESEC/FSE2023 が示した 6 カテゴリ分類(Missing monitor/alert 40.41% を筆頭)と 5 軸サービス特性相関(機能 / 成熟度 / 依存関係数 / SLA / SLI)は、 Microsoft の 300 超サービスを対象とした単一事業者データに基づく。同論文が将来展望として示した「依存共有サービス間での修正知見の自動転送」(intelligent monitoring framework)を本番運用した報告もまだない。 2025 年の AlertGuardian のルール改善が動機の一部を引き継いだが、 "missing monitor" を上流で予防する系統的フレームワークは未確立である。 **(f) 技術的介入 × 人間的・組織的介入の統合設計がない**。 2017 年の Jalleda(インセンティブ設計、90% 削減)と Chen(技術的 4 施策、85% 削減)、 2023 年の Cruz(認知的徒弟制)、 Iwahori(Runbook ガバナンス)がそれぞれ独立に効果を示したが、これらを単一組織で組み合わせた場合の効果加算性・相互作用・最適投入順序は未検証である。とくに、技術的介入で残った偽アラートを組織的介入がさらに削減できるのか、あるいは両者は同じプールを競合的に削減しているのかが不明である。 これらの空白は、本領域が「個別介入点の各論」から「介入点をまたぐ統合論」、さらに「アラートが存在する前提を疑う統合論」と「技術以外の介入次元を取り込む全方位論」へ移行する次の研究フェーズの輪郭を示している。 --- ## 関連 - 親概念群: [[アラート管理]] / [[アラート抑制]] / [[アラートフィルタリング]] / [[アラート集約]] / [[アラートランキング]] / [[アラートストーム]] / [[アクショナブルアラート]] / [[アラートアンチパターン]] / [[Quality of Alerts]] / [[アラートインシデント分析]] / [[アラート疲労]] / [[アラートポリューション]] / [[アラート相関]] / [[Prometheusルールリント]] - 上位文脈: [[AIOps]] / [[インシデント管理]] / [[オブザーバビリティ]] / [[agentic SRE]] - 関連 MOC: `structures/LLM4SRE - MOC` / `structures/000 Index` ## 出典 frontmatter の `sources` に列挙した一次・二次ソースに加え、 wiki/concepts の以下のページで横断的知見を確認した: - [[アラート管理]] §横断的知見(10 層超介入点の細分化、上流シフト、 IBM 系 12 年遷移、 Microsoft / Tsinghua 系統の対比) - [[アラート集約]] §横断的知見(LLM 役割 3 分化、 LLM 採用境界、 Fudan 三部作) - [[アラートストーム]] §横断的知見(SPOT/Zhao+ 連結、断続/連続の対比、重大障害の第三カテゴリ) - [[アラート抑制]] §横断的知見(IBM 系 12 年遷移、 X-out-of-Y の汎化失敗) - [[アラートフィルタリング]] §横断的知見(クリック弱教師、 DEAR の評価層介入) - [[アラートランキング]] §横断的知見(3 ルーツ対照) - [[アクショナブルアラート]] §横断的知見(影響 + 解釈可能性の 2 軸化、 Runbook 合意による発火前経路) - [[アラートアンチパターン]] §横断的知見(Yang+ 2022 の 6 分類、 A4 動的抑制、 A2 自動ランキング) - [[Quality of Alerts]] §横断的知見(3 軸自動評価、 Zadka コストモデルとの相補、 TraceArk による処理容易性の機械化) - [[アラートインシデント分析]] §定義(VOCE の独立タスク化) - [[アラート疲労]] §横断的知見(技術的介入 vs インセンティブ設計 vs 人間能力育成の 3 軸) - [[アラートポリューション]] §横断的知見(心理的バイアス診断と処方の補完関係) - [[アラート相関]] §横断的知見(入力段ノイズ除去と出力段フィルタの対比) - [[Prometheusルールリント]] §横断的知見(時系列クエリの壊れやすさ、 CI + デーモンの二重保証)