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 > 4秒
- 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レポート — myapp.com — 2026-03-23 03:15 PST
### ステータス: 正常 ✓
| チェック | 結果 | ベースライン | 差分 |
|--------|--------|----------|-------|
| HTTP | 200 ✓ | 200 | — |
| コンソールエラー | 0 ✓ | 0 | — |
| LCP | 1.8秒 ✓ | 1.6秒 | +200ms |
| CLS | 0.01 ✓ | 0.01 | — |
| API /health | 145ms ✓ | 120ms | +25ms |
| 静的アセット | 42/42 ✓ | 42/42 | — |
| SSE /events | 接続済 ✓ | 接続済 | +80ms ハートビート |
### リグレッションは検出されませんでした。デプロイは正常です。
連携
以下と組み合わせて使用:
- デプロイ前検証には
/browser-qa - フック:
git pushの PostToolUseフックとして追加し、デプロイ後に自動チェック - CI: GitHub Actionsのデプロイステップ後に実行