アラートメールが届いても誰も対応できていない中小企業に向けて、監視ツールの設定から通知フローの整備、初動対応の仕組みまでを実践的に解説します。
こんな悩み、ありませんか？
アラートメールが深夜に届いていたのに、翌朝まで誰も気づかなかった。「サーバー監視はしているつもり」なのに、実際には形だけで運用が回っていない——そんな状態に心当たりはないでしょうか。
当社がこれまで関わってきたクライアントの多くも、同じ課題を抱えていました。監視ツールは導入済み、アラートメールの設定もある、でも「誰が・何をするか」が決まっていないため、いざ障害が起きたときに右往左往してしまう。
この記事では、中小企業のWeb担当者やエンジニアが「監視を実際に機能させる」ための仕組みを、設定例を交えながら具体的に解説します。ツールの導入だけで終わらせず、対応フローまで整備することが目的です。
なぜ「誰も見ていない」状態が生まれるのか
アラートメールが届いても誰も動かない——この問題の根本は、技術的な問題ではなく運用設計の問題です。よくある原因を整理すると、以下のような構造が見えてきます。
- 通知先が共有メールアドレス（info@〜）になっている：全員に届くと誰も自分事として受け取らない「責任の分散」が起きる
- アラートの閾値が雑で「狼少年」化している：些細なことで頻繁に通知が届き、慣れてしまって本当の異常を見逃す
- 「何をすべきか」が書かれていない：「サーバーCPU使用率90%超過」とだけ届いても、担当者がエンジニアでなければ何をすればいいか分からない
- 夜間・休日対応のルールがない：誰も責任を持っていないので、発見が翌営業日になる
あるクライアント（従業員15名ほどの製造業、ECサイト運営）では、監視ツールとしてMackerelを導入していたものの、アラートメールの宛先がweb-team@という5人共有のアドレスになっていました。月に数十件のアラートが飛んでいたにもかかわらず、「誰かが見ているはず」という思い込みで放置が常態化。あるとき決済ページがダウンして4時間気づかず、数十万円規模の売上損失が発生するという事態になりました。
問題は監視ツールの性能ではなく、「誰が・どのタイミングで・何をするか」の設計がなかったことです。
監視体制を「実際に機能させる」ための4ステップ
ステップ1：アラートを「個人宛て」に再設計する
最初にやるべきことは、通知先の見直しです。共有メールへの通知を廃止し、担当者個人のメールアドレスまたはSlackの個人チャンネルへ直接通知する設計に変えます。
重要なのは「役割を明確にすること」です。たとえば、
- 平日昼間（9:00〜18:00）：Web担当者のAさんに通知
- 夜間・休日：外部の保守委託先またはオンコール担当に転送
このローテーションを、監視ツール側の設定で自動化します。MackerelやDatadogであれば、通知チャンネルにオンコールスケジュールを設定できます。
# Mackerelのmkr CLIでアラートチャンネルを確認・設定する例
mkr channels
# 既存チャンネルの一覧が出力される
# Slack連携チャンネルを追加する場合は管理画面から設定
ステップ2：アラートに「初動アクション」を添付する
アラートメール・Slack通知の文面に、「このアラートが来たらまずこれをやる」という初動手順をURLリンクで添付します。社内Notionや社内Wikiに手順書を作成し、そのURLをアラート通知のメッセージテンプレートに埋め込むのが最も手軽です。
# mackerel-agent.conf の monitors設定例（CPU監視）
[plugin.metrics.cpu]
command = "mackerel-plugin-cpu"
# アラートメッセージのカスタマイズはMackerel管理画面の
# 「モニター設定 > 通知メッセージ」から行う
# 例: 「CPU使用率が90%を超えました。初動手順: https://notion.so/xxxx」
Laravelで構築されたWebアプリケーションの場合、ログの確認先も合わせて記載しておくと対応が格段にスムーズになります。
# Laravelアプリのエラーログ確認コマンド（手順書に記載しておく）
tail -n 100 /var/www/html/storage/logs/laravel.log
# 直近のエラーだけ抽出
grep "\[ERROR\]" /var/www/html/storage/logs/laravel.log | tail -n 50
ステップ3：閾値を「意味のある水準」に調整する
アラート疲れを防ぐには、閾値の見直しが不可欠です。初期設定のまま使い続けると、軽微な変動でも通知が飛びすぎて「狼少年」状態になります。
CPU使用率: WARNING 70% / CRITICAL 90%
メモリ使用率: WARNING 75% / CRITICAL 90%
ディスク使用率: WARNING 80% / CRITICAL 90%
HTTPレスポンス: 3秒超でWARNING / タイムアウトでCRITICAL
決済機能を持つサイトはより厳しめに設定し、かつSSL証明書の期限監視を必ず追加してください。Let's Encryptの自動更新が失敗していても、設定がなければ気づかないまま証明書が切れてしまいます。
ステップ4：週次で「アラート履歴のレビュー」を習慣化する
仕組みを作っただけで満足しがちですが、週に一度、先週のアラート履歴を5分だけ眺める習慣がじわじわと効いてきます。頻発しているアラートがあればそれは改善のサインですし、全く通知がないなら監視が正常に機能しているかの確認にもなります。
flowchart TD
A[アラート発火] --> B{重要度判定}
B -->|CRITICAL| C[担当者へ即時Slack通知 + SMS]
B -->|WARNING| D[担当者へSlack通知]
C --> E[初動手順書URLを確認]
D --> E
E --> F{自己対応できる?}
F -->|Yes| G[対応 → ログに記録]
F -->|No| H[保守委託先へエスカレーション]
G --> I[週次レビューで振り返り]
H --> Iよくある失敗パターンと対処法
失敗①「Slack通知にしたら逆に見なくなった」
Slackに切り替えたはいいものの、チャンネルのメッセージが流れてしまって見逃すケースがあります。対処法はCRITICALアラートだけはSlackのメンション（@担当者名）を必ずつけることです。MentionなしのSlack通知は、チャンネルによっては埋もれてしまいます。
失敗②「保守委託先を決めたが連絡先が古かった」
「緊急時は○○社に電話」と決めていたのに、担当者が退職していて繋がらなかったという話は珍しくありません。保守委託先の緊急連絡先は四半期に一度は疎通確認する運用ルールを入れてください。
失敗③「監視対象を増やしすぎてコストが膨らんだ」
MackerelやDatadogはホスト数・メトリクス数に応じて費用が変わります。最初から全部を監視しようとせず、まずHTTP死活監視・ディスク・CPU・メモリの4点だけから始めるのが現実的です。慣れてきたらDB接続数やエラーレート監視を追加する段階的なアプローチを推奨します。
失敗④「アラートは届いていたが手順書が古かった」
サーバーのディレクトリ構成が変わったり、Laravel側のログパスを変更したりしたあとに手順書を更新し忘れていると、いざというときに役に立ちません。デプロイやサーバー変更のたびに手順書の該当箇所を必ず更新することをチェックリストに含めましょう。
冒頭のクライアントのその後
先ほど紹介した製造業ECサイトのケースでは、以下の対応を実施しました。
- 通知先を担当者個人のSlackへ変更し、CRITICALはメンション付き
- HTTPレスポンス監視と決済ページ限定のURL死活監視を追加
- 「決済エラー検知時の初動5ステップ」をNotionに作成し、アラートメッセージに埋め込み
- 夜間は当社の保守プランで一次対応を受け持つ体制に変更
結果として、障害発生から担当者が初動対応を開始するまでの平均時間が約4時間から15分以内に短縮されました。ツールは変えず、運用設計だけを変えた成果です。
サーバー管理、丸ごとお任せください
サーバー保守・運用
監視・障害対応・パフォーマンス改善まで、安定稼働をサポートします
※ 通常1営業日以内にご返信します
まとめと次のステップ
サーバー監視を「機能させる」ために必要なのは、高価なツールの追加ではありません。通知設計・初動フロー・閾値の見直しという、地味だけれど確実な運用設計の見直しです。
自社内でここまで整備するのが難しいと感じた場合は、外部の保守・運用サポートを活用することも一つの選択肢です。Fivenine Designでは、LaravelやWordPressで構築されたWebサービスの監視設計・保守対応を承っています。「今の監視体制に不安がある」という段階でのご相談でも歓迎です。
