# Monitoring Alert Design

> 自動化フロー・システムの監視項目とアラート条件を設計する。障害を早期に検知し、適切な人間へ通知が届く仕組みを確定する。自動化フローのリリース前に使う。

- Skill: `thinkyou0714/monitoring-alert-design` (Agent Skill)
- Install (CLI): `npx skillmds@latest add thinkyou0714/monitoring-alert-design`
- Raw SKILL.md: https://api.skillmd.com/api/skills/thinkyou0714/monitoring-alert-design/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: thinkyou0714 (https://skillmd.com/u/thinkyou0714)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/thinkyou0714/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](../../../docs/CONTEXT.md) — 通知先・チャネルの技術スタック文脈
- [judgment-gates.md](../../../src/lab-core/rules/judgment-gates.md) — 自動化判断ゲート（GATE-2）