2026年6月2日

アラート疲れを防ぐ監視設定｜通知を絞って本当の障害だけに反応する

アラート疲れ死活監視 quiet hours メンテナンスウィンドウ

アラートが多すぎると「オオカミ少年」状態になる

監視ツールを導入して最初に直面する問題のひとつが「アラート疲れ（alert fatigue）」です。誤検知・計画停止中の通知・深夜の瞬断アラートが続くと、エンジニアはやがて通知を無視するようになります。本当に重大な障害が発生したときに初動が遅れる——これがアラート疲れの最大のリスクです。

Webサイトを10件・20件と管理する制作会社では特に顕著です。クライアントごとにアラートが飛び交い、「また誤検知だろう」という意識が根付いてしまうと、SLAを守れない事態につながります。

本記事では、Miterlが提供する4つのアプローチを組み合わせて、本当に対応すべきアラートだけを届ける設定方法を解説します。

なぜアラート疲れが起きるのか

アラート疲れの原因は大きく4種類に分けられます。

原因	具体例
誤検知（瞬断）	ネットワーク瞬断による1回だけのエラー
計画停止中の通知	深夜メンテナンス中のアラート多発
深夜・休日の不要通知	夜間の軽微な警告でオンコール担当が起こされる
閾値の不適切設定	僅かなレスポンスタイム変動でアラート連発

これらを放置すると、担当者が通知をミュートしたり、アラートメールのフォルダを確認しなくなります。

対策1: リトライ設定で瞬断ノイズをカットする

最も手軽で効果の高い対策が**リトライ（確認回数）**の設定です。1回の失敗だけではアラートを発報せず、連続N回失敗したときのみ通知するように設定します。

# モニター作成時にリトライ回数を設定する
curl -X POST https://miterl.com/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "クライアントA - 本番サイト",
    "url": "https://client-site.example.com",
    "type": "http",
    "interval_seconds": 60,
    "confirmation_count": 2,
    "alert_contact_ids": [1]
  }'

confirmation_count: 2 の場合、2回連続でエラーになったときにアラートが発報されます。ネットワーク瞬断による1回限りのエラーはスルーされるため、誤検知が大幅に減ります。

推奨値の目安:

サイトの重要度	confirmation_count	実質的な障害検知時間
ECサイト・予約系（高）	1〜2	1〜2分
コーポレートサイト（中）	2〜3	2〜3分
開発・ステージング（低）	3〜5	3〜5分

重要度の高いサイトでは小さい値で素早く検知し、それ以外は多少の余裕を持たせることで全体のノイズを減らせます。

対策2: メンテナンスウィンドウで計画停止中のアラートを抑制する

深夜のサーバー移行やCMSアップデートのたびに大量のアラートが飛ぶのは典型的なアラート疲れの要因です。Miterlのメンテナンスウィンドウ機能を使えば、計画停止の時間帯だけ通知を抑制できます。

# Webhookでデプロイ前にメンテナンスウィンドウを開始する
curl -X POST https://miterl.com/api/v1/webhooks/maintenance/YOUR_TOKEN/start \
  -H "Content-Type: application/json" \
  -d '{
    "duration_hours": 2,
    "name": "CMSアップデート作業"
  }'

# 作業完了後にウィンドウを終了する
curl -X POST https://miterl.com/api/v1/webhooks/maintenance/YOUR_TOKEN/end

CI/CDパイプラインやデプロイスクリプトにこの呼び出しを組み込むことで、「メンテナンスウィンドウを設定し忘れた」というヒューマンエラーがなくなります。

ウィンドウ中も監視チェック自体は継続しているため、メンテナンスが想定以上に長引いた場合はウィンドウ終了と同時にアラートが発報されます。設定の詳細は「メンテナンスウィンドウの正しい使い方」をご覧ください。

対策3: quiet hours（静音時間）で深夜・休日の通知を制御する

「深夜に軽微なアラートでエンジニアが起こされる」という問題には、**quiet hours（静音時間）**機能が有効です。平日の就業時間外や週末の全時間帯など、会社単位でアラート通知を抑制するスケジュールを設定できます。

quiet hours の設定例（日本の制作会社の典型的な運用）:

{
  "enabled": true,
  "timezone": "Asia/Tokyo",
  "weekdays": {
    "enabled": true,
    "start": "22:00",
    "end": "07:00"
  },
  "weekends": {
    "enabled": true,
    "all_day": true
  }
}

この設定では平日22時〜翌7時と土日終日はアラート通知が抑制されます。静音中も監視チェックと障害ログは通常通り記録されるため、翌朝ダッシュボードで確認すれば夜間の状況を把握できます。

quiet hours と重大障害の両立:

「静音中でも本当に重大な障害は通知してほしい」という場合は、静音時間を適用するアラート連絡先と、常時通知するアラート連絡先を分けて管理するアプローチが有効です。緊急度の高いモニターには静音を適用しないアラート連絡先を割り当て、その他は静音対象にします。

設定はダッシュボードの「静音時間」メニューから行います。タイムゾーンは会社ごとに個別設定できるため、海外クライアントのサイトを管理している場合も柔軟に対応できます。

対策4: 閾値とアラート連絡先の設計を見直す

アラートの量を減らすためには、「何を誰に通知するか」の設計も重要です。

閾値の設定指針

レスポンスタイム監視などで「少し遅くなった」程度でアラートが発報されると、ノイズが増えます。

# レスポンスタイム閾値付きのモニター設定例
curl -X POST https://miterl.com/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "クライアントA - 応答速度",
    "url": "https://client-site.example.com",
    "type": "http",
    "interval_seconds": 60,
    "response_time_threshold_ms": 5000,
    "confirmation_count": 3,
    "alert_contact_ids": [1]
  }'

response_time_threshold_ms: 5000 は5秒以上かかった場合にエラーとする設定です。通常のページ表示は2秒程度のため、5秒の閾値なら明らかな異常のみを検知できます。

アラート連絡先の分類

全通知を同じSlackチャンネルに流すと、重要なアラートが埋もれます。以下のような分類が効果的です。

連絡先グループ	対象モニター	通知先
緊急（常時通知）	ECサイト・基幹システム	Slack #critical + 担当者携帯
通常（静音あり）	コーポレートサイト群	Slack #monitoring
ログのみ	開発・ステージング	Slack #dev-monitoring

Slack・Chatworkへのアラート通知設定については「Slack・Chatworkへのアラート通知設定ガイド」で詳しく解説しています。

4つの対策を組み合わせた設定例

制作会社での典型的な設定パターンをまとめます。

# 本番サイト（高重要度）— リトライ少・常時通知
curl -X POST https://miterl.com/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "[ClientA] 本番 - HTTP",
    "url": "https://client-a.example.com",
    "type": "http",
    "interval_seconds": 60,
    "confirmation_count": 2,
    "alert_contact_ids": [1]
  }'

# ステージングサイト（低重要度）— リトライ多・業務時間のみ通知
curl -X POST https://miterl.com/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "[ClientA] ステージング - HTTP",
    "url": "https://staging.client-a.example.com",
    "type": "http",
    "interval_seconds": 300,
    "confirmation_count": 5,
    "alert_contact_ids": [2]
  }'

alert_contact_ids: [1] は常時通知グループ、[2] は静音時間が適用されるグループに対応させておくことで、重要度別の通知制御が実現します。

よくある質問（FAQ）

quiet hours 中に障害が発生した場合、翌朝に通知されますか？

quiet hours 中のアラートは抑制されますが、障害ログとインシデントは通常通り記録されます。翌朝ダッシュボードを確認すれば夜間に何が起きたかを把握できます。また、サイトがダウンしたままで quiet hours が終了すると、その時点でアラートが発報されます。

誤検知が多いサイトだけリトライ数を増やせますか？

はい、モニターごとに confirmation_count を個別に設定できます。誤検知の多いサイトだけ値を上げて、重要なサイトは低い値のままにする運用が可能です。

メンテナンスウィンドウ終了後にすぐ通常監視に戻りますか？

はい、ウィンドウ終了の瞬間から通常の監視・通知に戻ります。終了時点でサイトがダウンしていれば、即座にアラートが発報されます。

まとめ

アラート疲れは「監視ツールを導入した結果チームが疲弊する」という皮肉な状態です。しかし適切な設定で解消できます。

リトライ設定（confirmation_count）: 瞬断ノイズを排除
メンテナンスウィンドウ: 計画停止中のアラートを抑制
quiet hours: 深夜・休日の不要通知をシャットアウト
閾値と連絡先の分類: 重要度に応じた通知設計

4つを組み合わせることで、アラートが来たら「本当に対応が必要な障害だ」と確信できる環境を作れます。その状態になって初めて、監視ツールは本来の価値を発揮します。

設定の詳細はドキュメントをご覧ください。無料プランからすぐに試せます。インシデント発生時の対応フローは「サイト障害発生時の対応フロー完全ガイド」、監視の基本タイプは「非エンジニアでもわかるサーバー監視入門」も参考にしてください。他社の活用事例はユースケースページをご覧ください。