thinkyou0714 Purpose
「知らない間にフローが止まっていた」「気づいたら大量のエラーが出ていた」を防ぐ。 監視すべき指標・アラート閾値・通知先・対応手順を設計し、障害を検知できる状態にする。
Use When
- 自動化フローのリリース前
- 新しいシステム統合（Stripe Webhook 等）を設計する場合
- failure-point-review の後に、検知手段を設計したい場合
- 「このシステム、止まったらすぐ気づけるか」を確認したい場合
Inputs
- 対象システム: 監視するフロー・サービス・APIの説明
- 許容障害時間: 何時間まで気づかなくてよいか
- 通知先: Slack / メール / ダッシュボード 等
- 既存の監視: 現在どのような監視が存在するか（ない場合は「なし」）
Output Contract
- 論点: このシステムで最も監視が重要な箇所
- 根拠: その論点をそう判断した理由
- 監視設計シート: 監視項目・閾値・通知先の定義
- 含意: 監視設計が示す運用負荷・アラート疲労リスク
- 改善案: 監視コスト・アラート精度を改善する工夫
- 代替案: 別の監視方式・ツールの可能性
- 判断材料: 監視設計の確定に必要な人間の意思決定事項
監視設計シート フォーマット
| 監視項目 | 正常値 | 警告閾値 | 危険閾値 | 通知先 | 対応手順 |
|---|---|---|---|---|---|
| （指標名） | Slack #channel |
Review Lens
- 目的妥当性: 監視項目が実際の障害検知に対して有効か
- 範囲の過不足: 重要なシステムが監視対象から漏れていないか
- 中長期リスク: アラートが多すぎて無視されるリスク（アラート疲労）
- LAB全体との整合性: 通知仕様（チャネル・重大度・宛先・初動手順）が定義されているか
- 非エンジニア理解可能性: 「何かおかしい時に通知が来る」を説明できるか
- 他LLM移植耐性: 設計が Slack 固有に過度に依存していないか
Instructions
- 監視対象を「フロー実行結果 / レスポンスタイム / エラーレート / データ整合性」に分類する
- 各項目の正常値・警告閾値・危険閾値を定義する
- 通知先（Slack チャンネル）と通知タイミングを設計する
- 「通知が来たら誰が何をするか」の初動対応手順を簡潔に定義する
- 自動復旧できる場合はその条件と手順を含める
- アラートの抑制条件（メンテナンス時間等）を定義する
- ヘルスチェックエンドポイントの有無を確認する
Guardrails
- アラートを「通知するだけ」で終わらせない。初動対応手順をセットにする
- 全エラーを同じ重要度で通知しない（警告と危険を区別する）
- ダッシュボードを「作って終わり」にしない。誰が・いつ・何を確認するかを明示する
- 「24時間気づかなくてもいい」障害でも記録は残す
LAB Cross-Check
| 観点 | 状態 | 備考 |
|---|---|---|
| 自動化フロー | — | n8n / Webhook の実行結果を監視しているか |
| データ / 認証 / ログ | — | DB 接続エラー・認証失敗を監視しているか |
| 実装 / 運用フロー | — | 通知を受け取った担当者の対応手順が存在するか |
| 非エンジニア理解可能性 | — | 監視の目的を非技術者に説明できるか |
| 会員共有 / 再利用耐性 | — | 監視設計が他システムにも転用できるか |
| 他LLM移植耐性 | — | 設計が Claude 固有に依存していないか |
状態は OK / 注意 / NG / 対象外 で記入すること。
Handoff Notes
- 要件: 監視項目・閾値・通知先・初動対応手順の仕様
- 成功条件: 障害発生から X 分以内に通知が届く状態
- 失敗条件: 監視自体が停止した場合の検知基準
- 実行範囲: 設定してよい監視ツール・Slack 連携・アラートルール
- 影響範囲: 監視追加が波及するシステム・パフォーマンス
- ロールバック方針: 監視設定変更が問題を起こした場合の戻し方
- コスト比較: 監視方式ごとの運用コスト・ツールコスト概算
Further Reading
failure-point-reviewskill — 何を監視すべきかの障害点特定trigger-action-mapskill — フローのどのステップを監視するか- docs/CONTEXT.md — 通知先・チャネルの技術スタック文脈
- judgment-gates.md — 自動化判断ゲート（GATE-2）