死活監視の誤検知を減らす4つの基本設定とフラッピング対策の実践ガイド

誤検知（False Positive）とは

誤検知とは、サービスは正常に動いているのに、監視ツールが「ダウンした」と判定してアラートを飛ばしてしまうことです。深夜3時に叩き起こされてサイトを確認すると、何ごともなく動いている。これが数回続けば、チームはアラートを信用しなくなります。

誤検知の怖さは、単に煩わしいことではありません。「どうせまた誤検知だろう」が前提になった瞬間、本物の障害アラートまで無視されるようになることです。監視は「鳴ったら動く」という合意があって初めて価値を持ちますが、誤検知はその土台を静かに崩していきます。

通知の量が多すぎてチームが消耗する問題は「アラート疲れを防ぐ方法」で扱っています。この記事は裏返しのテーマ、つまり**鳴ったアラートが本当に正しいのかという「精度」**に焦点を当てます。

なぜ誤検知が起きるのか

誤検知の多くは、サービス本体ではなく監視経路上の一時的なノイズから生まれます。よくある原因は次のとおりです。

これらはほぼすべて数秒で自然に回復します。つまり、1回の失敗をそのまま真に受けて即座にアラートを出せば、その大半は誤検知になります。

誤検知を減らす4つの基本設定

誤検知対策の本質は、「1回失敗した」と「本当にダウンしている」を切り分けることです。特別なツールは要りません。次の4つを正しく設定するだけで、誤検知のほとんどは消えます。

1. 失敗しきい値（1回の失敗で確定しない）

最も効果が大きいレバーです。1回のチェック失敗ではアラートを出さず、N回連続で失敗したときだけ「ダウン」と確定する設計にします。一瞬の断は連続しては起きないため、この設定だけで瞬断由来の誤検知はほぼ無くなります。

# 最悪ケースの検知遅延 = 間隔 × (失敗しきい値 − 1)
# 例: 5分 × (3 − 1) = 10分
interval_min=5
threshold=3
echo "検知遅延（最悪ケース）: $(( interval_min * (threshold - 1) )) 分"

しきい値を上げるほど誤検知は減りますが、本物の障害の検知も遅くなるというトレードオフがあります。一般的なWebサイトなら、連続3回あたりが実用的な出発点です。

2. 間隔とタイムアウトを適切に取る

タイムアウトが短すぎると、正常だが遅いだけの応答が失敗扱いになります。通常の応答時間に対してタイムアウトに余裕を持たせ、間隔は「どれだけ早く障害を捕まえたいか」とサーバー負荷・誤検知率のバランスで決めます。「稼働率の計算とSLA目標の決め方」で扱う許容ダウンタイムから逆算すると考えやすくなります。

3. 計画メンテナンスを除外する

デプロイや定期メンテナンス中の計画的なダウンは障害ではありません。メンテナンスウィンドウを事前に登録してその間のアラートを抑止すれば、想定内のダウンで呼び出されることはなくなります。運用の型は「メンテナンスウィンドウの設計と運用」にまとめています。

4. 静音時間で深夜の非緊急通知を抑える

すべての通知が「今すぐ起きて対応せよ」を要求するわけではありません。深夜帯は最優先チャンネルだけに絞り、残りは翌朝まとめて受け取るようにすれば、誤検知で叩き起こされる事態を構造的に減らせます。通知の振り分けは「Webhookで監視通知をDevOpsツールに連携する」を参照してください。

Miterlでの誤検知対策

Miterlはこれらの基本設定を最初から組み込んでいます。

失敗しきい値はデフォルトで3回です。1回のチェック失敗ではインシデントを作らず、連続失敗カウントを進めるだけです。カウントがしきい値（既定3）に達したときにはじめて「ダウン確定」となり、インシデントが作成されてアラートが送られます。途中で1回でも成功すれば、カウンタはゼロに戻ります。

チェック間隔はデフォルトで5分です（プランに応じて1分まで短縮可能）。チェックのたびに次回実行時刻が更新され、間隔とタイムアウトの組み合わせが「ただ遅いだけ」の一時的なゆらぎを吸収します。

現在のステータスとチェック履歴はAPIから確認できます。

# モニターの現在のステータスを取得
curl -s "https://miterl.com/api/v1/monitors/1" \
  -H "Authorization: Bearer YOUR_API_KEY" | jq '{name, status, uptime_30d}'

インシデントは失敗しきい値に達してはじめて作成されるため、瞬断由来の「ノイズインシデント」が記録に混入することはありません。確定したインシデントだけを一覧できます。

# 確定したインシデントを一覧（解決済みを含む）
curl -s "https://miterl.com/api/v1/incidents?monitor_id=1&per_page=20" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  | jq '.data[] | {started_at, resolved_at, cause}'

さらに、計画されたメンテナンスウィンドウ中のダウンは除外され、深夜の非緊急通知は静音時間で抑止されます。これらを組み合わせることで「鳴ったら本物」に近づきます。

フラッピングへの対処

フラッピングとは、対象が「ダウン→復旧→ダウン→復旧」と短時間で往復し、そのたびに通知が飛ぶ状態です。負荷のしきい値付近で揺れているサーバーや、断続的なネットワーク障害でよく起こります。

フラッピングに対する第一の防御線も、やはり失敗しきい値です。ダウン確定に連続失敗を要求すれば、1回の往復がアラートになることはありません。そのうえで、次の運用が効きます。

• 根本原因を直す: フラッピングは監視設定の誤りではなく、対象が本当に不安定であるサインのことが多いです。「障害対応の進め方」を使ってリソース枯渇や断続的な障害を切り分けます。
• 通知の振り分けを分ける: 確定したインシデントは即時チャンネルへ、頻繁な状態変化のサマリーは低優先度チャンネルへ送ります。
• 何を監視するか見直す: トップページだけでなく、「シナリオ監視（Synthetic Monitoring）」で実際のユーザー動線を検証すると、表層的なゆらぎと本当の問題を区別しやすくなります。

誤検知を減らすチェックリスト

設定時と見直し時に、次を確認してください。

• 失敗しきい値を設定しているか（1回目の失敗で確定していないか）
• タイムアウトは通常の応答時間に対して余裕があるか
• 間隔は検知速度と誤検知率のバランスで決めたか
• 計画メンテナンスは監視から除外されているか
• 深夜の非緊急通知は静音時間で抑止されているか
• フラッピングしているものは根本原因を調査したか
• 「本物のアラートには必ず対応する」というチームの合意はあるか

まとめ

誤検知は監視への信頼を静かに削っていきます。しかしその対策の大半は、特別なツールではなく基本設定を正しく行うことから得られます。

• 誤検知の多くは監視経路上の一時的なノイズが原因
• 失敗しきい値が「1回失敗した」と「本当にダウン」を切り分ける最も効果的な手段
• 間隔・タイムアウト・メンテナンス除外・静音時間を組み合わせて精度を上げる
• フラッピングはしきい値で抑えつつ、対象側の根本原因を潰す

「鳴ったら本物」に近づくほど、チームはアラートを信頼し、本物の障害に集中できるようになります。設定の考え方はドキュメントにまとめており、失敗しきい値やメンテナンス除外の挙動は無料プランで実際に試せます。

通知の量も気になる場合は「アラート疲れを防ぐ方法」もあわせてお読みください。精度と量の両方を調整することで、監視は本来あるべき「信頼できる土台」に戻ります。