観測は揃った。では、誰が気づくのか
前回のS-04では、一つのリクエストがたどった経路を追うトレースを学びました。ログ、メトリクス、トレースという観測の道具が、これで一通り揃いました。しかし、観測できることと、異常に気づけることは別の話です。データがどれだけ揃っていても、誰も見ていなければ、止まっていることには気づけません。この講義は、S-01で挙げた「気づかないうちに止まっていた」という失敗に、直接答えるための回です。
このスライドのポイント
- S-02〜S-04で、ログ・メトリクス・トレースという観測の道具が一通り揃った
- しかし「観測できること」と「異常に気づけること」は別
- データが揃っていても、誰も見ていなければ止まっていることに気づけない
- この講義は、S-01の「気づかず止まっていた」に直接答える回
三つの言葉を定義する
三つの言葉を定義します。監視とは、S-02からS-04で集めた観測データを、異常の条件と突き合わせ続けることです。アラートとは、その条件を満たしたときに人へ通知することを指します。通知先と手段まで決めて、初めてアラートは機能します。エスカレーションとは、最初に対応した人だけでは解決しないとき、次の人や次の手段へ引き上げる取り決めのことです。この三つが揃って、はじめて異常が放置されない仕組みになります。
このスライドのポイント
- 監視＝観測データ（S-02〜04）を、異常の条件と突き合わせ続けること
- アラート＝条件を満たしたときに人へ通知すること（通知先と手段まで決めて初めて機能する）
- エスカレーション＝一次対応で解決しないとき、次の人・手段へ引き上げる取り決め
- この三つが揃って、異常が放置されない仕組みになる
苦情が監視代わり、と、アラート疲れ
これらが無いとどうなるか。まず、利用者からの苦情が監視の代わりになります。これは最悪の検知手段です。使えないと気づいた利用者が連絡してくる頃には、業務はすでに止まっています。反対に、何でもかんでも通知するのも失敗です。通知が多すぎると、やがて人はアラートを無視するようになります。これがアラート疲れで、本物の緊急が鳴っても見過ごす原因になります。検知が遅すぎても、鳴りすぎても、どちらも危ういのです。
このスライドのポイント
- これらが無いと、利用者からの苦情が監視の代わりになる=最悪の検知手段
- 利用者が連絡してくる頃には、業務はすでに止まっている
- 反対に、何でも通知すると人はアラートを無視するようになる=アラート疲れ
- 検知が遅すぎても、鳴りすぎても、どちらも危うい
三点セットと、絞り込みの原則
監視の設計は、三点セットで考えます。何を検知するか、という条件。誰にどう知らせるか、という通知先と手段。そして、どうなったら引き上げるか、というエスカレーションの条件です。この三つを一組にして、異常ごとに決めていきます。ここで最も大切な原則があります。アラートにしてよいのは、人が今行動すべきものだけ、ということです。今すぐ動かなくてよいものは、アラートにはせず、S-02やS-03の記録に留めます。この線引きが、アラート疲れを防ぎます。
このスライドのポイント
- 監視の設計は三点セット: ①何を検知（条件）②誰にどう知らせる（通知先・手段）③どうなったら引き上げる（エスカレーション）
- 異常ごとに、この三つを一組で決める
- 原則: アラートにしてよいのは「人が今行動すべきもの」だけ
- 今すぐ動かなくてよいものは、S-02/S-03の記録に留める
経費アプリの最小監視——三本から始める
例として、社内50人が使う公開済みの経費アプリを考えます。最小の監視は、三本から始めます。一本目は死活監視で、アプリが応答するかを5分ごとに確認します。二本目はエラー率で、失敗の割合が決めた閾値を超えたら知らせます。三本目は、締め日に走るK-08の定期処理が失敗したときの通知です。この三本は、いずれも起きたら人が今すぐ動くべき異常です。多くを欲張らず、一人で運用しても回る規模から始めるのが要点です。
このスライドのポイント
- 例は社内50人が使う公開済みの経費アプリ（公開した後の物語）
- 最小の監視は三本: ①死活=アプリが応答するか5分ごと確認 ②エラー率=失敗の割合が閾値超え ③締め日のK-08定期処理の失敗
- いずれも「起きたら人が今すぐ動くべき」異常だけ
- 欲張らず、一人で運用しても回る規模から始める
サンプル: 三本のアラート設計表
サンプルは、先ほどの三本を設計表にしたものです。種別は表です。目的は、条件、通知先、一次対応、エスカレーションを、異常ごとに一枚で決めることです。読み方の要点は三つあります。まず、すべての行に通知先と手段が具体的に書かれていること。次に、一次対応がまず何をするかの一手に絞られていること。そして、解決しないときの引き上げ先まで決まっていることです。AIへの質問例はこうです。このアプリの監視を最小構成で設計してください、通知の閾値も提案してください。
このスライドのポイント
- 種別: table
- 目的: 死活・エラー率・定期処理の三本を、条件／通知先／一次対応／エスカレーションで一枚に設計する
「監視している」と「アラートが飛ぶ」は別
混同しやすいのは、監視しているという状態と、アラートが飛ぶという状態です。観測のグラフを用意しただけでは、監視しているとは言えても、人が気づけるとは限りません。見に行かないと分からない監視は、夜間と週末には無力です。担当者が画面を開いていない時間帯こそ、異常は起きます。だからこそ、条件を満たしたら人のほうへ通知が届く、アラートまで作り込む必要があるのです。
このスライドのポイント
- 監視している（観測はある）／アラートが飛ぶ（人が気づける）は別の状態
- 観測のグラフを用意しただけでは、人が気づけるとは限らない
- 見に行かないと分からない監視は、夜間と週末に無力
- 担当者が画面を開いていない時間こそ、異常は起きる
アラートは運用で育てる
バイブコーディングでの確認点です。アラートは、作って終わりではありません。鳴ったら記録し、月次で振り返って、鳴りすぎか鳴らなさすぎかを調整します。特に、対応が不要だったアラートは、閾値を見直すべきという合図です。放置すると、それがアラート疲れの入り口になります。AIへの質問例はこうです。先月のアラート履歴です、対応不要だった通知を分類し、閾値の見直し案を出してください。アラートも、運用の中で育てていくものです。
このスライドのポイント
- アラートは作って終わりではない。鳴ったら記録し、月次で振り返る
- 鳴りすぎか、鳴らなさすぎかを調整する
- 「対応が不要だったアラート」は、閾値を見直すべき合図
- 放置すると、それがアラート疲れの入り口になる
まとめと次回
最後に一問一答です。アラートにしてよいのは、どんな異常でしょうか。（間）答えは、人が今行動すべきものだけ、です。それ以外は、アラートにせず記録に留めます。30秒のまとめです。監視・アラート・エスカレーションの三点セットを、異常ごとに設計する。利用者の苦情を検知手段にせず、鳴りすぎも防ぐ。この二つが要点でした。次回のS-06では、では「どれだけ動いていれば合格か」という目標値の話に進みます。関連資料は、「通知・リマインド設計30」と「アプリ運用チェックリスト」です。
このスライドのポイント
- 一問一答:「アラートにしてよいのはどんな異常？」→ 人が今行動すべきもの（それ以外は記録に留める）
- 30秒まとめ: 監視・アラート・エスカレーションの三点セットを異常ごとに設計する／苦情を検知手段にせず、鳴りすぎも防ぐ
- 次回S-06: 「どれだけ動いていれば合格か」という目標値へ
- 関連資料: 「通知・リマインド設計30」「アプリ運用チェックリスト」
