Monitoring alert design

Purpose

「知らない間にフローが止まっていた」「気づいたら大量のエラーが出ていた」を防ぐ。 監視すべき指標・アラート閾値・通知先・対応手順を設計し、障害を検知できる状態にする。

Use When

• 自動化フローのリリース前
• 新しいシステム統合（Stripe Webhook 等）を設計する場合
• failure-point-review の後に、検知手段を設計したい場合
• 「このシステム、止まったらすぐ気づけるか」を確認したい場合

Inputs

• 対象システム: 監視するフロー・サービス・APIの説明
• 許容障害時間: 何時間まで気づかなくてよいか
• 通知先: Slack / メール / ダッシュボード 等
• 既存の監視: 現在どのような監視が存在するか（ない場合は「なし」）

Output Contract

1. 論点: このシステムで最も監視が重要な箇所
2. 根拠: その論点をそう判断した理由
3. 監視設計シート: 監視項目・閾値・通知先の定義
4. 含意: 監視設計が示す運用負荷・アラート疲労リスク
5. 改善案: 監視コスト・アラート精度を改善する工夫
6. 代替案: 別の監視方式・ツールの可能性
7. 判断材料: 監視設計の確定に必要な人間の意思決定事項

監視設計シート フォーマット

監視項目	正常値	警告閾値	危険閾値	通知先	対応手順
（指標名）				Slack #channel

Review Lens

• 目的妥当性: 監視項目が実際の障害検知に対して有効か
• 範囲の過不足: 重要なシステムが監視対象から漏れていないか
• 中長期リスク: アラートが多すぎて無視されるリスク（アラート疲労）
• LAB全体との整合性: 通知仕様（チャネル・重大度・宛先・初動手順）が定義されているか
• 非エンジニア理解可能性: 「何かおかしい時に通知が来る」を説明できるか
• 他LLM移植耐性: 設計が Slack 固有に過度に依存していないか

Instructions

1. 監視対象を「フロー実行結果 / レスポンスタイム / エラーレート / データ整合性」に分類する
2. 各項目の正常値・警告閾値・危険閾値を定義する
3. 通知先（Slack チャンネル）と通知タイミングを設計する
4. 「通知が来たら誰が何をするか」の初動対応手順を簡潔に定義する
5. 自動復旧できる場合はその条件と手順を含める
6. アラートの抑制条件（メンテナンス時間等）を定義する
7. ヘルスチェックエンドポイントの有無を確認する

Guardrails

• アラートを「通知するだけ」で終わらせない。初動対応手順をセットにする
• 全エラーを同じ重要度で通知しない（警告と危険を区別する）
• ダッシュボードを「作って終わり」にしない。誰が・いつ・何を確認するかを明示する
• 「24時間気づかなくてもいい」障害でも記録は残す

LAB Cross-Check

観点	状態	備考
自動化フロー	—	n8n / Webhook の実行結果を監視しているか
データ / 認証 / ログ	—	DB 接続エラー・認証失敗を監視しているか
実装 / 運用フロー	—	通知を受け取った担当者の対応手順が存在するか
非エンジニア理解可能性	—	監視の目的を非技術者に説明できるか
会員共有 / 再利用耐性	—	監視設計が他システムにも転用できるか
他LLM移植耐性	—	設計が Claude 固有に依存していないか

状態は OK / 注意 / NG / 対象外 で記入すること。

Handoff Notes

• 要件: 監視項目・閾値・通知先・初動対応手順の仕様
• 成功条件: 障害発生から X 分以内に通知が届く状態
• 失敗条件: 監視自体が停止した場合の検知基準
• 実行範囲: 設定してよい監視ツール・Slack 連携・アラートルール
• 影響範囲: 監視追加が波及するシステム・パフォーマンス
• ロールバック方針: 監視設定変更が問題を起こした場合の戻し方
• コスト比較: 監視方式ごとの運用コスト・ツールコスト概算

Further Reading

• failure-point-review skill — 何を監視すべきかの障害点特定
• trigger-action-map skill — フローのどのステップを監視するか
• docs/CONTEXT.md — 通知先・チャネルの技術スタック文脈
• judgment-gates.md — 自動化判断ゲート（GATE-2）