Canary Watch — デプロイ後監視
使用タイミング
- 本番環境またはステージング環境へのデプロイ後
- リスクの高いPRをマージした後
- 修正が実際に機能していることを確認したい場合
- リリース期間中の継続的な監視
- 依存関係のアップグレード後
動作の仕組み
デプロイされたURLの回帰を監視します。停止するか監視期間が終了するまでループ実行されます。
監視項目
1. HTTPステータス — ページが200を返しているか？
2. コンソールエラー — 以前にはなかった新しいエラーはないか？
3. ネットワーク障害 — API呼び出しの失敗、5xxレスポンスはないか？
4. パフォーマンス — LCP/CLS/INPがベースラインと比較して劣化していないか？
5. コンテンツ — 重要な要素（h1、ナビゲーション、フッター、CTA）が消失していないか？
6. APIヘルス — 重要なエンドポイントがSLA内で応答しているか？
7. 静的アセット — JS、CSS、画像、フォントのリクエストが2xx/3xxで期待されるコンテンツタイプを返しているか？
8. SSEストリーム — イベントストリームエンドポイントに接続でき、最初のイベントまたはハートビートを受信しているか？
監視モード
クイックチェック（デフォルト）：1回実行し、結果を報告
/canary-watch https://myapp.com
サステインドウォッチ：N分ごとにチェック、M時間継続
/canary-watch https://myapp.com --interval 5m --duration 2h
差分モード：ステージングと本番を比較
/canary-watch --compare https://staging.myapp.com https://myapp.com
アラートしきい値
critical: # 即時通知
- HTTPステータス != 200
- コンソールエラー数 > 5（新しいエラーのみ）
- LCP > 4s
- APIエンドポイントが5xxを返す
- 静的アセットが4xx/5xxを返す
- SSEエンドポイントに接続できない、または最初のハートビート前に切断
warning: # レポートにフラグ
- LCPがベースラインから500ms以上増加
- CLS > 0.1
- 新しいコンソール警告
- 応答時間がベースラインの2倍以上
- 静的アセットのコンテンツタイプが予期せず変更
- SSEハートビートレイテンシがベースラインの2倍以上
info: # ログのみ
- 軽微なパフォーマンスのばらつき
- 新しいネットワークリクエスト（サードパーティスクリプトの追加？）
通知
クリティカルなしきい値を超えた場合：
- デスクトップ通知（macOS/Linux）
- オプション：Slack/Discord Webhook
~/.claude/canary-watch.logにログ出力
出力
## Canary Report — myapp.com — 2026-03-23 03:15 PST
### ステータス: HEALTHY ✓
| チェック項目 | 結果 | ベースライン | 差分 |
|-------|--------|----------|-------|
| HTTP | 200 ✓ | 200 | — |
| コンソールエラー | 0 ✓ | 0 | — |
| LCP | 1.8s ✓ | 1.6s | +200ms |
| CLS | 0.01 ✓ | 0.01 | — |
| API /health | 145ms ✓ | 120ms | +25ms |
| 静的アセット | 42/42 ✓ | 42/42 | — |
| SSE /events | connected ✓ | connected | +80ms heartbeat |
### 回帰は検出されませんでした。デプロイは正常です。
連携
以下と組み合わせて使用：
/browser-qaデプロイ前検証用- フック：
git pushのPostToolUseフックとして追加し、デプロイ後に自動チェック - CI：デプロイステップ後にGitHub Actionsで実行