サービス監視とアラートの設計：気づくべき異常と通知ルール

サービスの監視とアラートの設計で最初に決めるべきなのは、「何を測るか」ではなく「誰が、何に気づいて、何をするべきか」です。監視の目的は、ユーザーが困る前、あるいは困った直後に異常に気づき、影響を小さくすることにあります。そのため、まずユーザーにとっての異常（使えない、遅い、結果が間違っている）を定義し、それを捉える指標を選び、対応が必要なものだけを通知する、という順で設計します。

アラートの設計でよく起きる失敗は、測れるものを片っ端から測り、少しでも変化があれば通知する設定にしてしまうことです。通知が多すぎると、担当者は通知を見なくなり、本当に重要な異常を見逃します。いわゆるアラート疲れです。これを防ぐ原則は「通知するのは、人が何かをする必要があるときだけ」です。記録しておけばよい情報と、すぐに人を呼ぶべき情報を分けることが設計の中心になります。

この記事は、自社でWebサービスやSaaSを運営していて、障害に気づくのがユーザーからの問い合わせだった、通知が多すぎて誰も見ていない、といった課題を持つ事業責任者や開発・運用の担当者に向けています。監視の対象の選び方、閾値と通知先の決め方、通知ルールの設計、運用での見直し方を順に解説します。

監視とアラートの役割を整理する

監視とは、システムやサービスの状態を継続的に測り、記録し、異常を見つけられるようにすることです。用語の意味は監視（システムモニタリング）で解説しています。アラートは、監視で得た情報のうち、人の対応が必要なものを担当者に知らせる仕組みです。

この二つは混同されがちですが、役割が違います。監視は「後から調べられるように、広く記録しておく」もの、アラートは「今すぐ誰かが動くべきことを、絞って知らせる」ものです。監視の範囲は広くてもかまいませんが、アラートの範囲は狭くなければなりません。

三つの層で考える

監視の対象は、次の三つの層に分けて考えると漏れが少なくなります。

優先して整えるべきは、一番上のユーザー体験の層です。インフラの指標が正常でも、ユーザーが使えていなければ意味がありません。逆に、ユーザー体験の指標に異常が出ていなければ、インフラの指標の多少の変動は、すぐに人を呼ぶほどのことではない場合が多いです。

何を監視するか：気づくべき異常から逆算する

監視の対象を決めるときは、ツールで取れる指標の一覧から選ぶのではなく、「このサービスで起きたら困ること」を先に書き出します。

1. サービスの主要な利用の流れを書き出す（例：会員登録、ログイン、検索、購入、予約、データの登録）。
2. それぞれの流れについて、止まったら、遅くなったら、誤った結果を返したら、誰がどの程度困るかを考える。
3. 困る度合いが大きい流れから順に、その状態を検知できる指標を決める。
4. 定期的に動く処理（夜間の集計、メール配信、データ連携など）を一覧にし、成功・失敗と実行時間を記録する。
5. 期限がある資源（SSL証明書、ドメイン、外部サービスの契約、APIキー）を一覧にし、期限の前に気づける仕組みを用意する。
6. 資源の枯渇につながる指標（ディスク容量、データベースの容量や接続数）を選ぶ。

手順4と5は見落とされがちですが、実務ではよく問題になります。夜間の処理が数日前から失敗していたのに誰も気づかなかった、証明書の期限が切れてサービスに接続できなくなった、といった事態は、監視の対象に入れておくだけで防げます。

「正しく動いているか」も監視する

サービスが応答していても、中身が正しいとは限りません。たとえば、決済は成功しているのに注文データが作られていない、通知メールが送られていない、といった異常は、死活監視やエラーログだけでは見つかりません。注文件数、送信件数、新規登録数といった事業の数字が、普段と比べて急に減っていないかを見ることも、監視の一部として考えておくと安心です。事業の数字の急変に気づく仕組みはKPIの急変に気づく仕組み：異常検知とアラート通知の設計で詳しく扱っています。

閾値の決め方：誤報と見逃しのバランス

閾値は、アラートを出すかどうかの境目です。厳しすぎると誤報が増え、緩すぎると見逃しが増えます。完璧な値を最初から決めることはできないため、決め方の方針を持ったうえで、運用しながら調整します。

閾値を決めるときの考え方

• 過去の実績から決める：普段の値の範囲を確認し、その範囲を明らかに超えたら通知する。最初の一〜二週間は通知せずに記録だけを取り、普段の値を把握すると決めやすくなります。
• ユーザーへの影響から決める：応答時間がこれ以上になると操作が困難になる、エラー率がこれ以上だと多くのユーザーが失敗している、という目安から決めます。
• 一瞬の変動で鳴らさない：一回だけ値を超えたら通知するのではなく、一定時間続いたら、あるいは数回連続で超えたら通知する設定にすると、誤報が大きく減ります。
• 段階を分ける：注意の段階と、緊急の段階の二つの閾値を設け、注意はチャットに記録、緊急は担当者を呼び出す、と通知の仕方を分けます。

ディスク容量のように、時間とともに一方向に増える指標は、現在の値だけでなく「このペースだと何日後にいっぱいになるか」で通知する方が、余裕をもって対応できます。

通知ルールの設計：誰に、どの手段で、いつ

閾値を決めたら、次は通知のルールです。同じ異常でも、誰に、どの手段で知らせるかで、対応の速さとアラート疲れの度合いが大きく変わります。

重要度で通知の手段を分ける

緊急として呼び出すのは、ユーザーへの影響が大きく、すぐに人が動かなければ被害が広がるものに限ります。夜中に電話が鳴ったのに、翌朝に見れば十分だった、という経験が重なると、担当者は呼び出しを信用しなくなります。

チャットへの通知を設計するときは、通知用のチャンネルを分けること、通知の文面に必要な情報を含めることが大切です。通知の設計の勘所はSlack・Teams通知で業務を回す：通知設計と自動化の勘所も参考にしてください。

通知の文面に含めること

• 何が起きているか（どの指標が、どの値になったか）
• いつから起きているか
• 影響の範囲の目安（どの機能、どのユーザーに影響しそうか）
• 状況を確認する画面やログへの案内
• 最初に何をすべきかの手順書への案内

最後の項目は特に重要です。アラートごとに、最初の確認と対処の手順をまとめた手順書を用意しておくと、担当者が慣れていなくても初動を間違えにくくなります。手順書の考え方はRunbook（運用手順書）で解説しています。

誰が受けるかを決める

通知の受け手が「チーム全員」になっていると、誰かが見ているだろうと全員が思い、結果として誰も対応しないことがあります。緊急と高の通知は、当番の担当者を一人決めて名指しで知らせ、一定時間内に反応がなければ次の担当者に回す、という流れにしておくと確実です。少人数のチームでは、時間外の当番を回すのが難しいこともあります。その場合は、時間外に呼び出す対象を本当に重要なものだけに絞り、それ以外は翌営業日の対応とすることを事前に合意しておきます。

アラート疲れを防ぐ運用

設計がよくても、運用を続けるうちに通知は増えていきます。新しい機能に監視を追加するたびに通知が増え、誤報が放置されると、アラート疲れが起きます。

防ぐために、次のような運用の決まりを設けます。

• すべてのアラートに「受けたら何をするか」が決まっていること。何もしなくてよいアラートは、記録のみに変更するか削除する。
• 誤報が出たら、その週のうちに閾値か条件を見直す。誤報を放置しない。
• 月に一度、過去一か月のアラートの件数と内訳を振り返り、対応が必要だった割合を確認する。
• 同じ原因で複数のアラートが同時に鳴る場合は、まとめて一件として通知されるように設定する。

振り返りでは、「鳴ったが対応不要だった」アラートと、「鳴らなかったが本当は気づくべきだった」異常の両方を確認します。後者は、ユーザーからの問い合わせで初めて気づいた障害などです。これがあれば、監視の対象か閾値が足りていないことになります。

通知の受け手を決めるときは、時間外の対応に関する負担も考えておきます。夜間や休日に呼び出しを受ける担当者には、当番の時間に応じた手当や代休の扱いを決め、当番が特定の人に偏らないように回します。負担が偏ると、その担当者が疲弊し、結果として対応の質が下がります。仕組みと同じくらい、人の体制の持続性も監視の設計の一部です。

架空の例：予約サービスの監視の見直し

ある予約サービスを例に考えます。これまではサーバーのCPU使用率とディスク容量にだけアラートを設定しており、負荷が少し上がるたびにチャットに通知が流れていました。担当者は通知を見なくなり、ある日、外部の決済サービスとの連携が失敗していたことに、ユーザーからの問い合わせで気づきました。

見直しでは、まず「予約ができない」「決済ができない」「予約確認の通知が届かない」という三つを最も困る事態として定義しました。そのうえで、外部からの予約画面の死活確認、予約完了の件数の急減、決済の失敗率、通知の送信失敗を監視の対象に加え、緊急と高の重要度を割り当てました。CPU使用率の通知は記録のみに変え、一定時間高い状態が続いた場合だけ中の重要度で通知するようにしました。

その結果、チャットに流れる通知の件数は大きく減り、残った通知はすべて何らかの確認が必要なものになりました。担当者が通知を見る習慣も戻り、異常に気づくまでの時間が短くなることが期待できます。

段階的に整える進め方

監視とアラートを一度に完璧に整えようとすると、設計の議論だけで時間がかかり、いつまでも始まりません。サービスの規模や体制に合わせて、段階的に整えるのが現実的です。

第一段階：止まったことに気づける

最初に整えるのは、サービスが止まったことに確実に気づける状態です。外部から主要な画面を定期的に確認し、応答がなければ担当者に通知する。定期処理が失敗したら通知する。証明書とドメインの期限が近づいたら通知する。この三つだけでも、ユーザーからの問い合わせで障害に気づく事態の多くは防げます。設定の手間も比較的小さく、数日で整えられることが多いはずです。

第二段階：遅い・失敗が増えたことに気づける

次に、止まってはいないが品質が落ちている状態に気づけるようにします。主要な画面の応答時間、エラー率、ログインや決済など主要操作の成功率を監視し、普段の範囲を超えたら通知します。この段階では、最初の一〜二週間は記録だけを取り、普段の値を把握してから閾値を決めると、誤報を抑えられます。

第三段階：中身の異常と予兆に気づける

最後に、応答はしているが結果が正しくない状態や、近い将来の問題の予兆に気づけるようにします。登録件数や注文件数の急減、外部連携の失敗の増加、容量が埋まるまでの日数の予測などです。この段階では、事業の数字と技術の指標を同じ画面で見られるようにすると、異常の原因を探りやすくなります。

各段階の終わりに、一か月ほど運用してからアラートの件数と内訳を振り返り、誤報と見逃しを確認してから次の段階に進みます。段階を踏むことで、通知の数が急に増えてアラート疲れを招くことも避けられます。

よくある失敗とその避け方

インフラの指標だけを監視する

サーバーの資源の指標は取りやすいため、監視がそこに偏りがちです。しかし、ユーザーが使えているかは、サーバーの指標からは分かりません。外部からの確認や、主要な操作の成功率を必ず監視の対象に入れます。

通知先が個人のメールになっている

構築した担当者のメールアドレスに通知が届く設定のまま、その担当者が異動や退職をすると、誰にも通知が届かなくなります。通知先は個人ではなく、チームのチャンネルや当番の仕組みに設定します。

アラートが鳴った後の対応が決まっていない

アラートを受けても何をすればよいか分からないと、確認に時間がかかり、対応が遅れます。重要度の高いアラートから順に、初動の手順と連絡先を文書にしておきます。障害時の連絡体制や復旧の手順はシステム障害時の対応フロー：連絡体制と復旧手順の事前の決め方で整理しています。

監視の仕組みそのものが止まっていることに気づかない

監視のツールやスクリプトが止まると、異常があっても通知が来なくなり、「何も鳴らないから正常」と誤解してしまいます。監視の仕組みが動いていることを、外部から定期的に確認する仕組みも用意しておきます。

監視・アラート設計のチェックリスト

• サービスの主要な利用の流れと、止まったときの影響を書き出したか
• ユーザー体験の層の指標（外部からの確認、主要操作の成功率、応答時間）を監視しているか
• 定期処理の成否と実行時間を記録し、失敗を通知しているか
• 証明書やドメインなど、期限のある資源を一覧にし、期限前に通知されるか
• 閾値を過去の実績やユーザーへの影響から決め、一瞬の変動では鳴らない設定にしたか
• アラートに重要度を付け、重要度ごとに通知の手段を分けたか
• 通知の文面に、何が・いつから・影響範囲・確認先・初動の手順が含まれているか
• 通知先が個人ではなく、チームや当番の仕組みになっているか
• 時間外に呼び出す対象を合意しているか
• 誤報の見直しと、月次のアラートの振り返りの場があるか
• 監視の仕組み自体が止まっていないかを確認できるか

よくある質問

Q. 監視ツールは何を使えばよいですか？

クラウド事業者が提供する監視の機能、外部からの死活確認のサービス、ログやエラーを集めるサービスなど、選択肢は多くあります。まずは今使っているクラウドやホスティングに付属する機能で、この記事のユーザー体験の層とインフラの層を最低限カバーし、足りない部分を外部のサービスで補うのが現実的です。ツールの機能や料金は変わりやすいため、導入前に最新の情報を確認してください。

Q. 少人数で時間外の当番を回せません。どうすればよいですか？

時間外に呼び出す対象を、サービス停止や決済の失敗など、本当に放置できないものだけに絞ります。それ以外は翌営業日の対応とし、ユーザー向けにもサポートの対応時間を明示しておきます。保守を外部に委託している場合は、時間外の一次対応を含めるかどうかを契約で確認しておきます。

Q. 閾値はどのくらいの頻度で見直すべきですか？

誤報が出たときはその都度、それに加えて月に一度の振り返りで見直すのが目安です。新機能のリリースやユーザー数の大きな増加があった後は、普段の値が変わるため、閾値も合わせて確認します。

Q. 開発会社に保守を任せている場合、発注側は何をすればよいですか？

監視の具体的な設定は開発会社に任せても、「何が起きたら困るか」と「どの程度の重要度で、誰に知らせてほしいか」は発注側が決めるべきことです。事業として最も困る事態を伝え、どの指標で検知しているか、通知がどこに届くか、時間外の対応はどうなっているかを一覧で出してもらいましょう。月次の報告に、アラートの件数と対応の内容を含めてもらうと、監視が機能しているかを発注側でも確認できます。

Otsumuに相談できること

サービスの構成が比較的シンプルで、利用しているクラウドの監視機能で主要な指標が取れ、開発・運用の担当者が社内にいる場合は、この記事の手順に沿って自社で監視とアラートを整えることは十分可能です。まずは最も困る事態を三つほど定義し、それを検知する監視から始めるだけでも、障害への気づきは早くなります。

一方で、外部サービスとの連携が多く異常の種類が複雑、障害にユーザーからの問い合わせで気づくことが続いている、通知が多すぎて整理の仕方が分からない、運用の担当者がいない、といった場合は、外部の手を借りた方が早く安定することがあります。

Otsumuでは、サービスの主要な利用の流れの整理から、監視の対象と閾値の設計、通知ルールと初動の手順書の整備、定期処理の監視の自動化までを支援しています。運用業務全体の見直しと合わせて進めることもできます。詳しくは自社サービス運用の自動化コンサルティングや、既存システムの運用を継続的に支える保守・運用のページをご覧ください。

監視の何から手を付ければよいか、現状の通知の整理から相談したい場合も歓迎しています。30分の無料相談からお気軽にご連絡ください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01