# アラート疲労 ## 定義 アラート疲労(alert fatigue)は、大量のアラート（特に偽陽性や低品質なもの）に繰り返し曝されることでオペレータの応答性が低下し、重要なアラートへの対応が遅延または見落とされる状態を指す。[[Kishore Jalleda]] は SREcon17 Europe で ICU（集中治療室）のモニタリング過剰をアナロジーとして提示した—— ECG モニターアラームの 72〜99% が偽またはクリニカルに無意味であり、2010 年にマサチューセッツ州の病院で患者死亡事故が発生、ECRI Top 10 Health Technology Hazards には 2007 年以降毎年リストされている。IT 運用でも同じ構造的問題が発生し、Zynga では月間 10 万件超のアラートに対してヘッドカウント追加（NOC 1→13 名）が追いつかなかった。(Source: [[@2017__SREcon17 Europe__Want to Solve Over-Monitoring and Alert Fatigue - Create the Right Incentives]]) ## 横断的知見 - **アラート疲労と[[アラートポリューション]]は同一問題の裏表だが介入点が異なる**: Jalleda SREcon17 はアラート疲労をオペレータ側の応答劣化として扱い、インセンティブ設計（アラートバジェット + SRE サポート停止）で**アラートの送り手**を制御した。一方 [[Kristin Smith]] SREcon22 はアラートポリューション（信号対雑音比の低下）として扱い、オブザーバビリティへの移行で**受信チャネル自体**を再設計した。両者は「ノイズ削減」という同じ目標に、それぞれ「送り手のインセンティブ」と「受け手の観測手段」から迫る補完的アプローチ。Smith が「モニタリング増設 = 安全」の心理的結合を抵抗の根源と指摘したのに対し、Jalleda はその心理的抵抗をインセンティブ構造で構造的に無効化した（バジェット超過 → SRE サポート喪失のコストが心理的抵抗を上回る）。(Source: [[@2017__SREcon17 Europe__Want to Solve Over-Monitoring and Alert Fatigue - Create the Right Incentives]], [[@2022__SREcon22 Americas__Dark Sky Camping - Reducing Alert Pollution with Modern Observability Practices]]) - **技術的介入の 4 施策同時投入（Baidu 2017）は、アラート疲労に対する最初期の体系的産業対応**: [[@2017__SREcon17 Asia__Draining the Flood - A Combat against Alert Fatigue|Chen SREcon17 Asia]] は、[[Argus (Baidu)|Argus]] で 1 人 100 件超/日・有効率 15% 未満という定量的なアラート疲労状態を示し、アラートグルーピング・重要度キャリブレーション・オンコールエスカレーション・自動修復の 4 施策で **85% 削減**を達成した。Jalleda SREcon17 Europe（同年）がインセンティブ設計で 90% 削減を達成したのと対照的に、Chen は純粋に技術的介入の組み合わせで同等の削減率を示した。両者を並べると、同じ 2017 年の同じ SREcon シリーズで、アラート疲労に対するインセンティブ設計アプローチ（Jalleda/Zynga）と技術的介入アプローチ（Chen/Baidu）が独立に報告されたことになる。特に Chen の「アテンション率」（エンジニアがアラートを実際に確認したかを監視ログで測定し、重要度キャリブレーションに使う）は、疲労の定量計測に基づく校正という点でユニーク。(Source: [[@2017__SREcon17 Asia__Draining the Flood - A Combat against Alert Fatigue]], [[@2017__SREcon17 Europe__Want to Solve Over-Monitoring and Alert Fatigue - Create the Right Incentives]]) - **組織的介入（インセンティブ・文化）と技術的介入（自動化・ML）は並行して進化してきたが統合事例が少ない**: Jalleda の Clean Room イニシアティブ（2013 年頃）はアラートバジェットという組織的介入で 90% 削減を達成し、同時期以降の技術的介入（AlertGuardian の rule refinement、Bhukar+ の動的抑制、Adaptive Paging の通知先ルーティング）は自動化で介入する。[[Cruz SREcon23]] の Alert Triage Hour of Power は「人間のアラート判断能力の育成」というさらに別の介入軸である。3 つのアプローチ（インセンティブ設計 / 技術的自動化 / 人間の能力育成）を統合的に運用した事例報告は薄い。(Source: [[@2017__SREcon17 Europe__Want to Solve Over-Monitoring and Alert Fatigue - Create the Right Incentives]], [[@2023__SREcon23 Americas__Cognitive Apprenticeship in Practice with Alert Triage Hour of Power]], [[@2022__SREcon22 Americas__Dark Sky Camping - Reducing Alert Pollution with Modern Observability Practices]]) - **偽陽性が応答性を壊すという行動モデルは 2016 年時点で明確に提示されていた**: [[@2016__SREcon16__Less Alarming Alerts|Treat SREcon16]] は、無視したアラートや人間の行動を必要としなかったアラートを問い、過剰な偽陽性がアラーム無視につながると述べる。医療 ICU、車の警報、虚偽緊急通報、航空管制の偽警報研究を並べ、これは IT 運用固有ではなく「泣いた狼」型の汎用的な注意劣化であると位置づける。Jalleda/Baidu の 2017 年事例が定量削減を示す前に、Treat は疲労の発生機構を「アクションできないページが多すぎると反応しなくなる」として表現していた。(Source: [[@2016__SREcon16__Less Alarming Alerts]], [[@2017__SREcon17 Europe__Want to Solve Over-Monitoring and Alert Fatigue - Create the Right Incentives]], [[@2017__SREcon17 Asia__Draining the Flood - A Combat against Alert Fatigue]]) - **ML 監視における入力データドリフトアラートは IT 運用のアラート疲労と同一構造の問題を再現する**: [[@2023__SREcon23 EMEA__Symptom-based Alerting for Machine Learning|Weichbrodt SREcon23 EMEA]] は、ある金融会社のデータサイエンティストが ML オブザーバビリティツール導入後「入力フィールドの分布変化アラートが週に複数届くが、上流のビジネス変更か自然変動か分からず一切対処しなかった」と報告した事例を紹介する。これは Jalleda/Zynga の IT 運用アラート疲労（月間 10 万件超、有効率不明）と構造が同一——大量の低信頼アラートに曝され応答性が低下する——だが、ML 固有の要因として (a) 入力データの自然変動が大きく偽陽性率が高い、(b) データサイエンティストがオンコール文化を持たない、(c) データ品質問題の修正責任がデータ所有チームにあり優先順位が低い、という 3 点が重なる。Weichbrodt の対処方針は「入力監視を Priority 3 に下げ、出力分布監視を優先する」ことで実質的にアラート総数を絞るもので、Chen/Baidu の技術的削減ともJalleda のインセンティブ設計とも異なる「**監視対象の優先順位付けによるノイズ回避**」という第四の介入軸を示す。(Source: [[@2023__SREcon23 EMEA__Symptom-based Alerting for Machine Learning]], [[@2017__SREcon17 Europe__Want to Solve Over-Monitoring and Alert Fatigue - Create the Right Incentives]], [[@2017__SREcon17 Asia__Draining the Flood - A Combat against Alert Fatigue]]) - **2026 年時点の産業統計はアラート疲労が「AI 統合後も改善していない」ことを示す**: [[Eddie Redick]] が SREcon26 Americas（2026-03-25）で引用した産業調査(AI SOC Market 2025, Ponemon/Databahn)によると、組織平均アラート数は **960+/日**、大企業では **3,000+/日**、**30% が未調査のまま消える**。さらに 2026 SRE Report では Toil が 5 年ぶりに増加し、中央値 34% の業務時間が Toil に費やされ、70% がオンコールストレスによる燃え尽きを経験している。重要な視点は Redick が「アラート疲労は**アラート量を減らす**のではなく、**入力（シグナル品質）を修正する**システム問題」と再フレーミングした点で、Jalleda/Baidu の「削減」アプローチに対する質的な転換を提示する。AI が増やすのはアラート判断のスループットではなく、未調査のまま消えるアラートの「許容度」かもしれないという懸念が背景にある。(Source: [[@2026__SREcon26Americas__Human Factors in the Age of AI Ops]]) - **アラーム疲労は 2,600 年前のイソップ寓話に起源を持つ汎用問題であり、ユーザー視点の単一 SLI への集約が IT 運用での解法となった**: [[Alex Hidalgo]] は SREcon19 EMEA で「None of this is new」として歴史的文脈を示した——アラーム疲労はヘルスケア・鉱業・建設・原子力産業で研究が蓄積され、イソップ寓話「嘘をついた少年」（約 2,600 年前）にも見出せる「泣いた狼」問題だと述べる。Squarespace ELK スタックでは Logstash プロセス・Logstash-to-Kafka 接続・Logstash-to-Elasticsearch 接続・スループット・Elasticsearch プロセス・Elasticsearch クラスタブロックの 6 種アラートが「ノイジー・既知の未知だけ・ユーザー視点なし」という 3 欠点を持っていた。これを「Kafka 積み残し数 ÷ Logstash 処理レート = エンドツーエンドレイテンシ（秒）」という単一 SLI に集約することで、ユーザー体験の悪化を直接捉える 1 つのアラートに置き換えた。Jalleda SREcon17 のインセンティブ設計・Chen SREcon17 の技術的削減と並ぶ第三の軸として「**多数コンポーネント監視→単一ユーザー体験 SLI への置換**」を示す事例。(Source: [[@2019__SREcon19EMEA__How to SRE When Everything is Already on Fire]]) - **オンプレ由来アラートルールのクラウド流用がアラート疲労の定番構造的原因である**: [[Sohei Iwahori]] SRE NEXT 2020 は、[[GREE, Inc]] が 2015 年のオンプレ→AWS 移行時にアラートルールをそのまま踏襲した結果、2018/09 に月 300 件超のオンコールアラートがピークに達した事例を示す。根本原因はオートスケーリングによる台数調整の激しさ・スケールイン/アウト時の一時的事象であり、オンプレ環境では想定外だった「一時的なしきい値超過」が高頻度で発生した。この結果「静観」（復旧アクション不要で事象が収まる）対応が主流になり、ページャーへの応答が形骸化した。SRE Book Chapter 6 の「Every time the pager goes off, I should be able to react with a sense of urgency. I can only react with a sense of urgency a few times a day before I become fatigued.」という引用がこの問題意識の動機として示される。クラウドへの移行が大規模アラート疲労を誘発することは Baidu（技術的介入、Chen SREcon17 Asia）でも報告されており、移行期のアラートルール見直しが必要であることが独立に確認される。(Source: [[@2020__SRENext2020__Practices for Making Alerts Actionable]], [[@2017__SREcon17 Asia__Draining the Flood - A Combat against Alert Fatigue]]) - **マルチウィンドウ・マルチバーンレートアラートは非同期パイプラインにおけるアラート疲労の実践的な解法として提示された**: [[Gabriela Medvetska]] は SREcon25 Americas で自身の受信箱（Metric Alerts 1936 件・Maintenance Alerts 13,108 件）を示し、eBay での過剰アラートを実例化した。対処として Google SRE Workbook のマルチウィンドウアラート設計を非同期パイプラインに適用し、Critical（1h+5m/6h+30m）と Warning（1d+2h/3d+6h）の 4 レベルでバーンレートとウィンドウを明確に分離することで「過剰アラートと検知漏れのバランス」を取った。これは Jalleda の「インセンティブでアラートバジェットを設定する」という組織的アプローチとは異なり、**アラート条件自体を時間ウィンドウ対比で精密設計する**技術的アプローチとして分類できる。(Source: [[@2025__SREcon25Americas__Beyond Sequential - A Recipe for Async Pipeline Observability and Alerting]], [[@2018__Google SRE Workbook__Alerting on SLOs]]) - **「オオカミ少年アラート問題」は SRE の実践者が工学的未解決課題として明示的に位置づけた**: [[坪内佑樹]] は SRE NEXT 2024「工学としての SRE 再訪」において、アラート疲労の典型症状である「誤検知が多く対応者がアラートを無視するようになる現象」を**6 つの SRE オープンチャレンジの 1 つ**として提示した。SREcon コミュニティが 2016〜2026 年にわたって多様な技術・組織的解決策を報告してきた一方で、SRE の実践コミュニティでは 2024 年時点でも「解決済み」とは認識されていないことを意味する。学術的・産業的な知識が蓄積されているにもかかわらず、個々の組織内での適用・定着が依然として難題であることが示唆される。(Source: [[@2024__yuuk.io__SRE-NEXT-2024]], [[@2017__SREcon17 Europe__Want to Solve Over-Monitoring and Alert Fatigue - Create the Right Incentives]], [[@2026__SREcon26Americas__Human Factors in the Age of AI Ops]]) - **最小限の技術変更+コミュニケーション過剰投資+定量的バイイン可視化の組み合わせは、「統合事例が薄い」という既存の観察に対する具体的な反例を提供する**: [[Tony Lykke]] (Hudson River Trading) はSREcon19 Americasで、高urgencyページを6年間の71,317件から4か月で1,015件へ削減した事例を報告した。技術的変更はMaster NagiosとPagerDutyの間にdrop/downgrade/groupフィルタ層を追加するだけに留め、「9 Really Hard Steps」の大半をオーディエンス理解・許可取得・コミュニケーションという組織的プロセスに割いた。さらに`git shortlog`によるコミット貢献の推移(懐疑的だった同僚が5コミットから765コミットへ転じた)を提示し、心理的バイインの変化を定量指標で裏付けた。インセンティブ設計([[Kishore Jalleda]])と技術的介入([[@2017__SREcon17 Asia__Draining the Flood - A Combat against Alert Fatigue|Chen]])が「統合事例が薄い」と評されていたのに対し、Lykkeの事例は両者を意図的に組み合わせ、かつ組織的バイインを可視化した点で独自である。(Source: [[@2019__SREcon19 Americas__Fixing On-Call When Nobody Thinks It's (Too) Broken]], [[@2017__SREcon17 Europe__Want to Solve Over-Monitoring and Alert Fatigue - Create the Right Incentives]], [[@2017__SREcon17 Asia__Draining the Flood - A Combat against Alert Fatigue]]) - **アラート削減自体が「沈黙への不安」という新たな心理的抵抗を生むことがあり、これは Smith の「モニタリング増設 = 安全」の心理的結合と対をなす**: [[@2019__SREcon19 Americas__Fixing On-Call When Nobody Thinks It's (Too) Broken|Lykke]] は、ページ数を一晩でほぼ半減させた際、チームが安堵するのではなく不安になったと報告する。理由は「ページャーからの沈黙は歴史的に監視スタック自体が壊れている兆候だった」という連想であり、単なる「モニタリングを増やすほど安全」という信念の裏返しとして、モニタリングを減らすと「壊れているのに気づけていない」という不安を生む。Lykkeはこれを、サイレンス・ダウングレード処理を自動投稿するミュート可能なSlackログチャンネルで緩和した——鳴らないことと「何も起きていないこと」を区別できる受動的可視性を提供する解決策であり、[[Kristin Smith]] のオブザーバビリティ再設計([[@2022__SREcon22 Americas__Dark Sky Camping - Reducing Alert Pollution with Modern Observability Practices]])とは異なる角度から同じ心理的抵抗に対処した事例と言える。(Source: [[@2019__SREcon19 Americas__Fixing On-Call When Nobody Thinks It's (Too) Broken]], [[@2022__SREcon22 Americas__Dark Sky Camping - Reducing Alert Pollution with Modern Observability Practices]]) - **[[Mark Burgess]] の「タイムスケール分離」原則は、アラート疲労の産業的解決策群がすべて共有する暗黙の前提——「アラート量を絞れば解決する」——のさらに一段上流にある構造的原因を指摘する**: 本 concept に蓄積された事例(Jalleda/Zynga のインセンティブ設計、Chen/Baidu の技術的削減、Hidalgo の単一SLI集約等)は、いずれも「大量の低品質アラートを人間が処理しきれない」という現象への対処に焦点を当てる。一方 Burgess は「マイクロ秒スケールで発生するエラーを分〜時間スケールで応答する人間にそのまま渡すこと自体が構造的に誤りであり、アラート量を絞ってもこのタイムスケールの不一致自体は解消されない」と、より根源的な設計原則を提示する([[タイムスケール分離と監視粒度]])。この観点では、[[アラートポリューション]] の「監視対象の優先順位付け」や Hidalgo の「単一ユーザー体験 SLI への集約」は、結果的にタイムスケールの一致に近づく設計変更として再解釈できる。(Source: [[@2014__markburgess.org__Infrastructure Management Timescales]]) ## 未解決の問い - Jalleda の「アラートバジェット」と Google SRE Book の「[[エラーバジェット]]」の構造的類似性は指摘できるが、アラートバジェットの数値設定基準や消費計測方法の詳細は本発表では開示されていない。アラートバジェットの具体的な設計パターンを体系化した後続研究はあるか。 - Clean Room のインセンティブ設計は SRE サポートという「報酬の撤回」に依存するが、SRE チームが存在しない組織や SRE の位置づけが異なる組織ではどのような代替インセンティブが機能するか。 - 医療分野のアラート疲労研究（ECRI、Joint Commission）と IT 運用のアラート疲労研究は、Jalleda が冒頭でアナロジーとして引いた以上に交差しているか。医療の MAUDE データベース等に蓄積された知見の IT 転用可能性。 - Lykke の `git shortlog` コミット数はあくまで代理指標であり、コミット数の増加が実際の心理的バイイン(懐疑から信頼への転換)とどの程度相関するかは検証されていない。組織的信頼の変化を定量化する、より妥当性の高い指標はあるか。 - 「沈黙への不安」の緩和策(ミュート可能なSlackログチャンネルによる受動的可視性)は、HRTのような少人数(~300名)のエンジニア組織に特有の解決策か、それとも大規模組織でも同様に機能するか。 ## 関連 - [[アラート管理]] — アラート疲労は管理の失敗状態。介入点の分類で対処方法が整理される。 - [[アラートポリューション]] — 同一問題の裏表。ポリューション = 信号対雑音比の低下、疲労 = オペレータ側の応答劣化。 - [[アクショナブルアラート]] — アラート疲労の根本対策として「アクションに値するアラートだけを鳴らす」設計。 - [[Quality of Alerts]] — QoA の低下がアラート疲労を誘発する因果構造。 - [[エラーバジェット]] — アラートバジェットはエラーバジェットの構造的アナロジー。 ## 出典 - [[@2017__SREcon17 Europe__Want to Solve Over-Monitoring and Alert Fatigue - Create the Right Incentives]] - [[@2017__SREcon17 Asia__Draining the Flood - A Combat against Alert Fatigue]] - [[@2019__SREcon19 Americas__Fixing On-Call When Nobody Thinks It's (Too) Broken]]