「夜中に鳴らしてはいけないアラートの見分け方」
――“夜間ページング”は技術設定ではなく、運用の契約です
監視を作り込むほど、必ずぶつかる壁があります。
それが「夜中に鳴るアラート」です。
鳴ったけど、今できることがない
鳴ったけど、状況が分からない（ログも追えない）
鳴ったけど、結局“朝に確認”で終わる
鳴りすぎて、重要なものまで無視され始める
ここで大事なのは、「夜中に鳴らすかどうか」は重大度（Severity）だけで決めないことです。
夜間に鳴らしていいのは、乱暴に言えば次の条件を満たすものだけです。
夜中に鳴ったら“人が動く価値がある”
かつ
その人が“今この瞬間にできる止血”がある
逆に、これを満たさないアラートは、夜間に鳴らすほど監視全体を壊します。
この記事では、夜中に鳴らしてはいけないアラートを“設計上の特徴”から見分ける方法を、実務目線で整理します。（文中にリンクは置きません）
1. まず結論：夜中に鳴らしていいアラートは「止血できる」ものだけ
夜間ページング（人を起こす通知）は、アラートの種類で言うと “ページング” です。
ページングが成立するための最低条件は、次の3つです。
夜間ページングが成立する3条件
放置すると被害が拡大する（待てない）
30分以内にできる止血がある（今やる意味がある）
受け手が行動できる（権限・手順・エスカレーションがある）
このどれかが欠けるなら、そのアラートは夜中に鳴らすべきではありません。
“異常検知”としては正しくても、“夜間ページング”としては不適切です。
2. 夜中に鳴らしてはいけないアラートの見分け方（本質は5問）
「夜中に鳴らすべきか？」を判断するのに、細かいベストプラクティスより効くのが、次の5問です。
5問チェック（これでだいたい決まる）
Q1. 受け手は“最初の5分”で何をする？
具体的な行動が書けないなら夜中に鳴らさない。
「状況確認」だけのアラートは、基本“夜間ページング不適”です。
Q2. その行動は、夜間当番の権限で本当にできる？
できないなら、鳴らしても詰むだけです。
“権限が無いのに起こす”は、通知設計の失敗です。
Q3. それを朝まで放置すると、不可逆な損失が出る？
データ損失、長時間停止、外部影響拡大などが“夜間対応の理由”になります。
逆に、放置しても朝に直せば被害が限定的なら、夜中に起こす価値は薄い。
Q4. そのアラートは“高い確度で本当に異常”と言える？
誤検知が混ざるなら夜間ページングには向きません。
夜間ページングは「確度の高い少数精鋭」が鉄則です。
Q5. そのアラートは「止血の入口」になっている？
止血できないなら、夜間に鳴らしても復旧は進みません。
それなら“チケット化（営業時間対応）”が正解です。
3. 夜中に鳴らしてはいけないアラートの特徴（典型パターン12個）
ここからが具体論です。現場で“夜中に鳴らすと破綻する”アラートは、だいたい次の特徴を持っています。
特徴1：鳴っても「やること」がない（行動不能アラート）
何をすればよいか決まっていない
結局、朝に担当者へ連絡するだけ
その連絡すら夜間はできない（担当が寝ている／体制がない）
見分け方：
「鳴ったら何をする？」に対して、手順が“コマンドや画面レベル”で答えられない。
対処：
夜間ページングではなく、営業時間チケットへ落とす（傾向監視、改善、容量計画の領域）。
特徴2：一次対応者が“判断できない”情報しか出ない
「CPU 90%」だけ
「エラー増」だけ（どのエラー？どの操作？影響は？が不明）
対象が書かれていない（サービス名／環境／リージョン／リソースが不明）
夜中に起こす通知は、説明ではなく判断材料が必要です。
判断材料が無いなら、夜中に鳴らしても“詰む”だけ。
対処：
主アラート（起こす）はユーザー影響に寄せる（成功率、主要操作の遅延、外形）
“CPUが高い”などは、状況把握の補助へ格下げする
特徴3：スパイクと傾向が混ざっている（目的が違う）
夜中に鳴らしてはいけない典型がこれです。
じわじわ悪化（傾向）を、短い窓で閾値判定して鳴らす
逆に、スパイクを長い窓で拾って「過去の出来事」で起こす
見分け方：
「これは“今すぐ止血”のための通知か？それとも“予防保守”か？」が答えられない。
対処：
スパイク検知（夜間ページング）：短窓＋連続条件＋高確度
傾向監視（夜間は鳴らさない）：長窓＋レビュー／チケット化
特徴4：周期性（バッチ・月次・バックアップ）で必ず鳴る
夜間に鳴る代表格です。
毎晩バッチでCPUが上がる
バックアップでディスクI/Oが跳ねる
月末処理で遅延が増える
これを“異常”としてページングすると、監視は一気に信用を失います。
対処：
想定内の周期イベントは、夜間ページングから外す
どうしても見るなら「失敗したときだけ」に寄せる（例：バッチ失敗、完了しない等）
特徴5：固定しきい値で、成長・変化に追従できない
固定しきい値は、環境が変わると急に“うるさく”なります。
夜間ページングに固定しきい値を使うと、次の事故が起きやすいです。
事業成長で日常が閾値超え → 毎晩鳴る
しきい値を上げ続ける → そのうち“鳴らない穴”ができる
対処：
夜間ページングは「固定値」より、
率（成功率・失敗率）
主要操作のp95/p99
連続条件
複合条件（CPU高い＋成功率低下）
に寄せた方が破綻しにくいです。
特徴6：メトリックではなくログ集計で“即時通知”を作っている（遅延・バーストに弱い）
ログは証拠として強い反面、夜間ページングの“主役”にすると不安定になりがちです。
取り込み遅延で「今」のはずが「過去」を拾う
まとめて取り込まれて短時間に件数が跳ね、誤検知する
クエリが重くて評価が遅れる／落ちる
見分け方：
「鳴ったのに、実際の発生時刻は数時間前だった」が起きる。
対処：
夜間ページングはメトリックや外形（安定）へ寄せる
ログは“原因究明の入口”として使う（夜間ページングの補助）
特徴7：一発の揺れ（フラップ）で鳴る設計になっている
夜間の精神を削るのは、鳴る→戻る→鳴るのフラップです。
原因はだいたいこれです。
窓が短すぎる
集計がMax寄りで瞬間スパイクを拾う
連続条件がない
抑制（サプレッション）が設計されていない
対処：
夜間ページングは「連続条件（2〜3回連続）」や「デバウンス」を前提にします。
フラップするアラートは、夜中に鳴らすと破綻します。
特徴8：ディメンション分割が過剰で“同時多発ページング”になる
たとえば、インスタンス単位・Pod単位・パス単位でページングすると、障害時に通知が爆発します。
50台が同時にしきい値超え → 50件ページ
「結局どれが本体？」で現場が固まる
対処：
夜間ページングは「責任単位」までに止めるのが現実的です。
詳細な分割は“深掘り”で見る（ダッシュボード／ログ）に回します。
特徴9：重複アラートが多く、同じ障害で何度も起こされる
CPU高い
エラー率上昇
遅延増
依存先失敗率増
全部、同じ障害の“別の顔”であることが多いです。
夜間に全部ページングすると、対応者は通知処理に追われて止血が遅れます。
対処：
夜間に起こす“本体アラート”を1つ決める（多くはユーザー影響）
他は補助（ページングしない／FYI）に落とす
特徴10：「観測が死んだ」を「サービスが死んだ」と誤判定している
メトリック欠損、エージェント停止、収集経路の障害など。
これを“サービス障害”として夜間ページングすると混乱します。
対処：
観測経路の監視（監視基盤監視）を別に持つ
サービスの外形（ユーザー影響）と混ぜない
欠損は欠損として扱い、エスカレーション先を明確化する
特徴11：夜間の連絡先・権限・エスカレーションが整っていない
技術的に正しいアラートでも、運用体制がないなら夜間に鳴らしてはいけません。
オンコールがいない
委託先は夜間対応契約ではない
“誰に上げるか”が決まっていない
必要な権限がなく、調査すらできない
対処：
夜間ページングは「体制のある範囲」に限定し、それ以外はチケット化に落とす。
“体制が無いのに鳴らす”のが一番危険です。
特徴12：夜中に起こす必要がない“予防保守”がページングになっている
代表例はこれです。
ディスク使用率 80%
メモリ使用率 85%
CPU 70%
コスト増加
警告ログの増加
これらは、多くの場合「今すぐ止血」ではなく「明日直せる改善」です。
夜中に起こすと、監視は確実に嫌われます。
例外：
“朝までに確実に死ぬ”なら話が変わります。
ここで重要なのは、残り何時間で致命点に達するかで判断することです。
4. 例外処理の考え方：夜中に鳴らして良い“予防保守”もある
「予防保守は全部夜間NG」ではありません。
夜中に鳴らしてよい予防保守は、条件が明確です。
夜間に鳴らしてよい予防保守の条件
朝までに致命点へ到達する見込みが高い（例：ディスク満杯、証明書失効が数時間以内）
夜間に実施できる安全な止血手段がある（例：容量拡張、スケールアウト、フェイルオーバー）
止血しないと不可逆な損害が出る（例：ログ出力不能→障害時に調査不能、キュー溢れ→データ欠損）
“いつか困る”ではなく、“朝までに困る”が境目です。
5. 夜間に鳴らすべきアラートの“逆チェック”
「夜中に鳴らしてはいけない」を判断するだけだと、逆に“鳴らすべきもの”が曖昧になります。
そこで、夜間ページングに値するアラートの条件をまとめます。
夜間ページングに値するアラート（典型）
外形監視が失敗（主要機能が実際に通らない）
主要操作の成功率が急落
主要操作のp95/p99遅延が急激に悪化（かつユーザー影響が明確）
依存先障害でサービス影響が拡大している（DB接続不可、外部API全滅など）
データ欠損・破壊が進行する兆候（キュー溢れ、ストレージ書き込み不可）
セキュリティ上、即時封じ込めが必要な高確度事象（※体制がある場合）
ここで共通するのは、ユーザー影響または不可逆損失が明確で、止血の手段があることです。
6. 「夜中に鳴らしてはいけない」を設計に落とす方法
見分け方が分かっても、設定が整理されていないと再発します。
実務で効く落とし込みは次の3分割です。
① ページング（夜間に起こす）
少数精鋭
高確度
止血がある
受け手が決まっている
② チケット（営業時間内に処理）
傾向、予防保守
改善タスク
夜間は動けない依存の問題
③ FYI（共有のみ）
状況共有
復旧報告
デプロイなど“知っておく”通知
「全部ページング」にしない。
ここを分けるだけで、夜間の破綻は激減します。
7. すぐ使える「夜間ページング禁止」チェックリスト
アラートを追加・変更するとき、以下のどれかに該当したら、原則「夜間ページング禁止」にします。
鳴っても最初の5分で具体的行動が書けない
夜間当番の権限で対応できない
誤検知が一定割合で混ざる（フラップする）
目的が傾向監視（予防保守）である
固定しきい値で周期性に負けている
ログの取り込み遅延で“過去”を拾う可能性が高い
ディメンション分割が過剰で同時多発する
同じ障害で別アラートもページングされる（重複）
本番／非本番が混ざる可能性がある
受け手（責任者）が曖昧（大人数の共有先）
このチェックリストを通して残ったものだけが、夜間ページングの候補です。
山崎行政書士事務所の技術支援（広告）
夜中に鳴らしてはいけないアラートが鳴り続ける状態は、単に「しきい値が悪い」のではなく、次の“設計不足”が重なって起きることが多いです。
受け手（一次対応／二次対応／共有）が曖昧
ページング・チケット・FYIの区別がない
スパイク検知と傾向監視が混在している
メトリックとログの役割分担が崩れている
アクショングループが増えすぎて、責任線が消えている
「鳴ったら何をするか」が運用手順に落ちていない
山崎行政書士事務所では、Azure Monitor／Log Analytics を前提に、アラート・通知設計を「夜中に起こすべきもの」と「起こしてはいけないもの」に分け、運用として破綻しない形に整える技術支援が可能です。たとえば、
夜間ページングの基準策定（最初の5分の行動、権限、エスカレーション）
ページング／チケット／FYI の通知設計と、アクショングループの整理（増えすぎ問題の止血）
誤検知（フラップ・周期性・固定しきい値・ログ遅延）を減らす窓設計・連続条件・複合条件の導入
“本体アラート”を決めて重複通知を減らす棚卸し（少数精鋭化）
引継ぎ可能な運用台帳化（誰が何を見てどう動くかを文章に落とす）
「夜中に起こされるのに、何もできない」を放置すると、監視は必ず信用を失います。
夜間ページングは“正しい検知”より先に、“受け手が動ける設計”が必要です。
