# Health Check

> インフラメトリクスの定期調査を体系的に実施し、サービスの健全性を評価する。2層アプローチで11カテゴリのメトリクスを確認し、構造化レポートを作成する。定期的なサービス監視、障害予兆の検出、パフォーマンス評価に使用する。Do NOT use for 個別インシデントの根本原因分析（incident-rcaを使用すること）。

- Skill: `windschord/health-check` (Agent Skill, multi-file: 6 files)
- Install (CLI): `npx skillmds@latest add windschord/health-check`
- Raw SKILL.md: https://api.skillmd.com/api/skills/windschord/health-check/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: windschord (https://skillmd.com/u/windschord)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/windschord/health-check

---


# サービスヘルスチェックスキル

インフラメトリクスの定期調査を体系的に実施し、サービスの健全性を評価・レポートします。

## 概要

このスキルは以下の機能を提供します:
- 2層アプローチ（全体俯瞰→詳細深掘り）による体系的な調査
- 11カテゴリのメトリクス確認フレームワーク
- 5大原則に基づく分析手法
- 構造化されたヘルスチェックレポートの作成
- ナレッジベースの蓄積・参照

## このスキルを使用する場面

以下の状況でこのスキルを使用してください:

### 定期ヘルスチェック
- 日次/週次のサービスヘルスチェックを実施する場合
- 複数アカウント/サービスの健全性を一括で確認する場合
- 定期的なインフラメトリクス調査を体系化したい場合

### 異常の早期発見
- メトリクスの傾向変化を検知したい場合
- 閾値に達していないが注意すべき兆候を見つけたい場合
- 複数メトリクス間の相関から問題を予測したい場合

### 引き継ぎ・エスカレーション
- 前回の調査結果との差分を明確にしたい場合
- エスカレーション済み案件の経過を追跡する場合
- チーム間でヘルスチェック結果を共有する場合

## 基本的な使い方

「ヘルスチェックを実施したい」「サービスの状態を確認したい」「インフラメトリクスを調査したい」などと依頼されたら、以下の手順で進めます。

### ステップ1: 事前情報の収集

調査に入る前に、以下の情報をユーザーに確認します。**必ずAskUserQuestionツールを使用してください。**

```text
[health-check] ステップ 1/6: 事前情報の収集
```

#### 1-1. 調査対象の確認

```text
ヘルスチェックの対象について確認させてください:

- 対象のサービス/アカウント: どのサービスやアカウントを調査しますか？
- 監視ダッシュボードのURL: メトリクスを確認するダッシュボードはありますか？
- 調査対象期間: どの期間を確認しますか？（例: 直近24時間、直近1週間）
```

#### 1-2. コンテキスト情報の確認

以下の情報があれば収集します（不明な場合はスキップ可能）:

- 直近のインフラ変更（デプロイ、スケーリング、バージョンアップ）
- エスカレーション済み案件の有無と経過
- 商業イベント・キャンペーン情報
- 既知のクラウドプロバイダ/SaaS障害
- 前回のヘルスチェック結果（差分分析に使用）

#### 1-3. ナレッジベースの参照

調査対象のナレッジベースファイルが存在する場合は読み込みます:
- 既知のパターン（定期バッチ時刻、締め処理等）
- 既知の制約（対策不可と確定した問題）
- 依存関係マップ

### ステップ2: 全体俯瞰（レイヤー1）

```text
[health-check] ステップ 2/6: 全体俯瞰
```

**重要: ブラウザ自動化ツールでダッシュボードを確認する場合は `references/browser_automation_guide_ja.md` を参照してください。調査品質の保証、データ抽出の注意点、SPA固有の制約を記載しています。**

クロスアカウント/クロスサービスの一括ダッシュボードを確認し、異常のあるアカウント/サービスを特定します。

#### 確認の観点

ユーザーにダッシュボードの状態を確認しながら、以下を整理します:

1. **アラートの全体状況**
   - 現在ALERT/WARN状態のサービスはあるか
   - 直近の発火履歴に異常パターンはないか
   - 複数アカウント同時発火（共通基盤障害の兆候）はないか

2. **コストの全体傾向**
   - 前日比/前週比で大きな変動があるサービスはあるか
   - コストとリクエスト数の乖離はないか
   - 注意: 最新データポイントは集計遅延のため不正確な場合がある

3. **主要メトリクスの異常値**
   - CPU/メモリ/ディスクで閾値超過しているサービスはあるか
   - エラー率が上昇しているサービスはあるか
   - レスポンスタイムが悪化しているサービスはあるか

#### 全体俯瞰の出力

確認した結果を以下の形式で整理します:

```markdown
## 全体俯瞰サマリー

| サービス/アカウント | ステータス | 主な所見 |
|---------------------|-----------|----------|
| サービスA           | 正常      | 特記なし |
| サービスB           | 注意      | CPU使用率上昇傾向 |
| サービスC           | 警告      | アラート発火中（5xx増加） |

→ 詳細深掘り対象: サービスB、サービスC
```

### ステップ3: 詳細深掘り（レイヤー2）

```text
[health-check] ステップ 3/6: 詳細深掘り
```

全体俯瞰で異常または注意と判定したサービスについて、11カテゴリのメトリクスを詳細に確認します。

**重要: メトリクスのリファレンスは `references/metrics_guide_ja.md` を参照してください。使用する直前に読み込みます。**

#### 11カテゴリの確認

各カテゴリの詳細は `references/metrics_guide_ja.md` に記載されています。以下は概要です:

| # | カテゴリ | 主な確認項目 |
|---|----------|-------------|
| A | コスト | 日次/週次/月次推移、前日比/前週比、リクエスト連動性 |
| B | アラート | トリガー状態、発火履歴、同時発火パターン |
| C | ロードバランサー | リクエスト数パターン、レスポンスタイム、エラー率、Unhealthy host |
| D | CPU | アプリコンテナ、EC2/VM、検索エンジン、3系統同時上昇 |
| E | メモリ | 空きメモリ率、使用量傾向（リーク疑い）、JVMヒープ特性 |
| F | データベース | RDS CPU、接続数、デッドロック、ストレージ |
| G | キャッシュ | メモリ余裕度、Eviction、CPU、接続数 |
| H | キュー/ストリーム | メッセージ滞留時間、DLQ、スループット |
| I | 検索エンジン | ディスク使用率、ノードCPU、インデクシング遅延 |
| J | 証明書・外形監視 | SSL残日数、レスポンスタイム、稼働率 |
| K | アプリケーション基盤 | GC、エラーログ、Lambda、SESバウンス率、CPUクレジット |

**対象サービスに該当しないカテゴリはスキップしてください。**

#### 各カテゴリの確認手順

1. ユーザーにダッシュボードの該当セクションを確認してもらう
2. 値や傾向をヒアリングする（数値、グラフの形状等）
3. 異常・注意・正常を判定する
4. 異常や注意の場合は、関連する他カテゴリとの相関を確認する

### ステップ4: 相関分析

```text
[health-check] ステップ 4/6: 相関分析
```

**分析原則のリファレンスは `references/analysis_principles_ja.md` を参照してください。使用する直前に読み込みます。**

収集したメトリクス情報に基づき、5大原則を適用して分析します:

1. **周期性の判断**: 検出したスパイクや変動は周期的か突発的か
2. **相関分析**: 時間的に一致する複数メトリクスの組み合わせパターンを確認
3. **依存関係の把握**: アカウント/テナント間の波及がないか確認
4. **閾値方向性の理解**: メトリクスごとの正常方向を正しく判断
5. **事前情報との照合**: ステップ1で収集した変更・イベント情報との関連

#### 相関分析の主要パターン

| パターン | メトリクスの組み合わせ | 示唆する状況 |
|----------|----------------------|-------------|
| インフラ障害 | アラート発火 + リクエスト変動 + コスト変動 | サービス影響あり |
| リソース逼迫 | CPU上昇 + レスポンスタイム悪化 + エラー増 | スケーリング要検討 |
| JVMヒープ枯渇 | GC頻発 + GCポーズ増大 + p95悪化 | ヒープサイズ/リーク調査 |
| メッセージ処理障害 | キュー滞留 + DLQメッセージ増加 | コンシューマ調査 |
| 正常スケーリング | コスト増 + リクエスト増（連動） | 需要増対応 |
| インフラ変更起因 | コスト増 + リクエスト横ばい（乖離） | 変更内容の確認 |
| キャッシュ破壊 | Eviction増加 + DB CPU上昇 + レスポンスタイム悪化 | キャッシュメモリ増設/戦略見直し |
| ストレージ逼迫 | ディスク使用率上昇 + DB CPU上昇 + レスポンスタイム悪化 | データクリーンアップ/ストレージ拡張 |

### ステップ5: レポート作成

```text
[health-check] ステップ 5/6: レポート作成
```

**レポートテンプレートは `assets/templates/health_check_report_template_ja.md` を参照してください。使用する直前に読み込みます。**

調査結果をレポートテンプレートに基づいて構造化します。

#### レポートの構成

| セクション | 内容 |
|-----------|------|
| 調査概要 | 調査日時、対象、調査者、調査期間 |
| エグゼクティブサマリー | 全体の健全性評価（1-2行）と即時対応が必要な事項 |
| 重大な異常 | サービス影響の可能性があるもの。優先度・内容・推奨アクションを明記 |
| 中程度の注意点 | 閾値内だが通常と異なる傾向。経過観察か予防的対応かを判断 |
| 正常範囲の項目 | テーブル形式で簡潔に。閾値方向が直感と逆のメトリクスは正常理由を補足 |
| 相関分析の結果 | メトリクス間の相関の有無を明示（なかった場合も記載 → 調査の網羅性を示す） |
| エスカレーション済み案件の経過 | 前回からの変化（悪化/改善/横ばい）を差分で明記 |
| 推奨アクション | 優先度・内容・対象をテーブルで整理 |

#### レポートの原則

- **差分を明確に**: 前回のヘルスチェックからの変化を明記する
- **相関の有無を明示**: 相関がなかった場合も記載し、調査の網羅性を示す
- **閾値方向の補足**: 直感と逆のメトリクスは正常理由を補足する
- **推測は明示する**: 事実と推測を明確に区別する。推測は「推測:」プレフィックスを付ける
- **アクションは具体的に**: 「確認する」ではなく「○○ダッシュボードの△△メトリクスを確認する」

### ステップ6: ナレッジベース更新

```text
[health-check] ステップ 6/6: ナレッジベース更新
```

**ナレッジベーステンプレートは `assets/templates/knowledge_base_template_ja.md` を参照してください。使用する直前に読み込みます。**

調査で得られた知見をナレッジベースに蓄積します。

#### 蓄積する情報

- アカウント/テナント固有の業務パターン（定期バッチ時刻、締め処理等）
- 商業イベントカレンダー（ブランド別の負荷増イベント）
- 既知の制約（対策不可と確定した問題は追跡対象外にする）
- 解決済み事例（再発監視期間を経て追跡終了）
- 依存関係マップ（サービス間・アカウント間）
- 閾値のカスタマイズ（デフォルトと異なる閾値を設定した場合）

#### ナレッジベースの管理

- ユーザーにナレッジベースファイルの保存先を確認する
- 既存のナレッジベースがある場合は差分更新する
- 新規の場合はテンプレートから作成する
- 更新内容はユーザーに確認してから保存する

## 保存先の管理

### レポートの保存

レポートの保存先はユーザーに確認します:

```text
ヘルスチェックレポートの保存先を確認させてください。
デフォルトでは以下のパスに保存します:
[プロジェクトルート]/health-check-reports/[YYYY-MM-DD]-health-check.md

このまま進めてよろしいですか？
別のパスを指定する場合は、パスをお知らせください。
```

### ナレッジベースの保存

ナレッジベースの保存先もユーザーに確認します:

```text
ナレッジベースファイルの保存先を確認させてください。
デフォルトでは以下のパスに保存します:
[プロジェクトルート]/health-check-reports/knowledge-base.md

既存のナレッジベースファイルがある場合は、そのパスを教えてください。
```

### ディレクトリ構造

```text
[プロジェクトルート]/
└── health-check-reports/
    ├── knowledge-base.md                    # ナレッジベース（蓄積型）
    ├── [YYYY-MM-DD]-health-check.md         # 日次レポート
    ├── [YYYY-MM-DD]-health-check.md
    └── ...
```

## 調査の2層アプローチ

### レイヤー1: 全体俯瞰

| 項目 | 内容 |
|------|------|
| 目的 | 異常のあるアカウント/サービスを特定 |
| 方法 | クロスアカウント一括ダッシュボード |
| 所要時間 | 5-10分 |
| 出力 | 詳細深掘り対象リスト |

### レイヤー2: 詳細深掘り

| 項目 | 内容 |
|------|------|
| 目的 | 特定アカウントの根本原因を調査 |
| 方法 | アカウント別フィルタダッシュボード |
| 所要時間 | サービスあたり10-20分 |
| 出力 | カテゴリ別メトリクス評価 |

## AskUserQuestionツールの活用

**【重要】質問が必要な場合は必ずAskUserQuestionツールを使用する**

### 基本方針
- 不明な点は推測せず、必ず質問する
- 質問する時は常にAskUserQuestionツールを使って回答させる
- ダッシュボードの値はユーザーに確認してもらう（Claudeがダッシュボードに直接アクセスできない場合）

### 使用場面

1. **調査対象の確認**: サービス/アカウントの選択
2. **メトリクス値の確認**: ダッシュボードに表示されている値のヒアリング
3. **コンテキスト情報の収集**: デプロイ履歴、イベント情報等
4. **異常判定の確認**: 検出した異常がユーザーの認識と一致するか
5. **アクション方針の決定**: 推奨アクションの優先度や実施判断

## 制約事項

### 実施すること
- ユーザーから提供された情報に基づいて分析する
- 事実と推測を明確に区別する
- 閾値方向の違いを考慮して正しく判定する
- 相関がなかった場合も明示する（網羅性の証明）
- ナレッジベースの既知パターンを考慮する

### 実施しないこと
- 推測のみに基づいた異常判定を行わない
- ユーザーが提供していないメトリクス値を捏造しない
- 閾値方向を考慮せずに一律に「高い=異常」と判断しない
- 前回の調査結果なしに「悪化した」と断定しない
- レポートに絵文字を使用しない
- **効率化を理由にスクロール量を増やしたり、セクションの確認を省略しない**
- **テキスト抽出のみでセクションの調査を完了としない（グラフの視覚的確認が必須）**

### タイムアウト防止

- ステップ2（全体俯瞰）完了時点で中間結果をユーザーに報告する
- 詳細深掘りは対象サービスごとに区切って報告する
- 11カテゴリすべてを一度に確認しようとしない。対象サービスに関連するカテゴリのみ確認する
- リファレンスファイルは使用する直前に1つずつ読み込む

### 調査品質の均一化

> **前提**: スクロール量やチェックリスト手順はブラウザ自動化ガイド（`references/browser_automation_guide_ja.md`）で定義済み。ユーザーから調査対象URL・サービス・閾値が提示されない場合は、調査開始前に確認する。

- **全てのURL・全てのセクションで同一の調査手順を適用する**。後半のURLで手順を省略しない
- ブラウザ自動化時のスクロールは **ダッシュボードで800px以下、テキスト中心ページで1200px以下** とし、3000px以上のジャンプは禁止（詳細は `references/browser_automation_guide_ja.md` セクション2を参照）
- チェックリストは作成するだけでなく、**セクション確認のたびにリアルタイムで更新する**。全項目が埋まるまでレポート作成に進まない
- 時間が不足する場合は、**手順の省略ではなく調査範囲の縮小**（URLやサービスの分割）で対応し、ユーザーに中間報告する

## ベストプラクティス

### 1. 調査の再現性

同じ手順で調査すれば同じ結論に至ることを目指します:
- 確認したダッシュボードとフィルタ条件をレポートに記録
- 判定基準を明示する（何をもって「異常」「注意」「正常」としたか）
- 数値はできるだけ具体的に記録する

### 2. 差分の重視

単発の値よりも変化を重視します:
- 前回のヘルスチェックとの差分を明記
- トレンド（上昇/下降/横ばい）を記載
- エスカレーション済み案件の経過を追跡

### 3. 周期性の考慮

定期バッチや業務サイクルによるスパイクを誤検知しないようにします:
- ナレッジベースの既知パターンを事前に確認
- スパイクを見つけたら「周期的か突発的か」を判断
- 不明な場合は過去データとの比較をユーザーに依頼

### 4. 相関分析の徹底

単一メトリクスではなく、複数メトリクスの組み合わせで判断します:
- 時間的に一致する異常を探す
- 主要な相関パターンに当てはめて確認
- 相関がなかった場合も記録する

### 5. アクションの具体性

推奨アクションは具体的に記載します:
- 誰が（対象チーム/担当者）
- 何を（具体的な確認項目/操作）
- いつまでに（優先度に応じた目安）
- どのように（確認方法やツール）

## 今後の拡張

- 自動メトリクス取得（API連携）によるダッシュボード確認の自動化
- 過去レポートの自動差分分析
- アラートルール提案機能
- カスタム閾値の設定と自動判定
- レポートのSlack/Teams自動投稿