---
name: conoha-vps-health-check
description: ConoHa VPS の稼働状況を CPU・ディスクIO の実測から診断する。低稼働サーバーを洗い出し、より小さいフレーバーへのリサイズ（サイズダウン）を提案する。「VPS 健康診断」「稼働状況」「使ってないサーバー」「低稼働」「リサイズ提案」「サイズダウン」「CPU使用率」「ディスクIO」「コスト最適化」などのキーワードで発動する。
---

# ConoHa VPS ヘルスチェック

サーバーの CPU・ディスクIO を実測し、低稼働のサーバーを洗い出して、より小さいフレーバーへのサイズダウンを提案する。過剰スペックの是正によるコスト最適化が目的。

## 前提条件

- MCP クライアントが ConoHa VPS MCP（`/vps/mcp`）に接続済みで、OAuth 認可が完了していること（`vps:read` 以上。リサイズ実行には `vps:write`）
- 実測は `/rrd/cpu`・`/rrd/disk`、スペックは `/flavors/detail`、対象列挙は `/servers/detail` を使う
- リサイズの実操作・制約は [conoha-vps-mcp](../conoha-vps-mcp/SKILL.md) の手順（resize → VERIFY_RESIZE 待機 → confirmResize）に委譲する

## 使用ツール

| 用途                                      | ツール                     | path              | param      |
| ----------------------------------------- | -------------------------- | ----------------- | ---------- |
| サーバー一覧・現行 flavor                 | `conoha_get`               | `/servers/detail` | —          |
| フレーバー一覧（vCPU/RAM/disk・料金比較） | `conoha_get`               | `/flavors/detail` | —          |
| CPU 実測                                  | `conoha_get_by_param`      | `/rrd/cpu`        | サーバーID |
| ディスクIO 実測                           | `conoha_get_by_param`      | `/rrd/disk`       | サーバーID |
| リサイズ実行                              | `conoha_post_put_by_param` | `/action`         | サーバーID |

## RRD レスポンスの読み方（重要）

MCP はクエリパラメータを送らないため、**既定＝直近約1日・mode=average** のデータが返る。

### `/rrd/cpu`

```json
{ "cpu": { "schema": ["unixtime", "value"], "data": [[1700833820, 233285714.29], ...] } }
```

- `value` は **CPU 使用時間（ナノ秒/秒, nsec/s）**。パーセントではない
- 1 コアの最大 = 1,000,000,000 nsec/s。**CPU使用率(%) = value ÷ (1,000,000,000 × vCPU数) × 100**
- vCPU 数は対象サーバーの flavor（`/flavors/detail` の `vcpus`）から取得する
- `data` 配列の全点から**平均**と**最大**の使用率を算出する（欠測は `null` になり得るので除外）

### `/rrd/disk`

```json
{ "disk": { "schema": ["unixtime", "read", "write"], "data": [[1700833820, 0, 453.83], ...] } }
```

- `read` / `write` は **IO スループット（B/s）**。**ディスク容量の使用率ではない**（あくまで IO 活動量の指標）
- 概算値であり実サーバー状況と差異が出得る（公式注記）

## 診断フロー

```text
1. conoha_get path="/servers/detail" → 診断対象サーバーの id と現行 flavor（flavorRef/名前）を把握
2. conoha_get path="/flavors/detail" → 各 flavor の vcpus/ram/disk を控える（%換算とサイズダウン候補選定に使う）
3. 各サーバーについて:
   a. conoha_get_by_param path="/rrd/cpu" param=<id>
      → data から CPU使用率(%) の平均・最大を算出（value ÷ (1e9 × vCPU) × 100）
   b. conoha_get_by_param path="/rrd/disk" param=<id>
      → read/write B/s の平均・最大を算出（IO 活動量の目安）
4. 判定基準で低稼働サーバーを分類
5. 低稼働サーバーに、一段小さい flavor へのサイズダウンを提案（下記）
6. ユーザー承認後、リサイズを実行（conoha-vps-mcp の手順に従う）
```

## 判定基準（低稼働の目安・調整可）

直近約1日・average のデータに対して:

| 区分         | CPU 平均使用率 | CPU 最大使用率 | 判定                             |
| ------------ | -------------- | -------------- | -------------------------------- |
| 明確に低稼働 | < 5%           | < 30%          | サイズダウンを積極提案           |
| やや低稼働   | < 10%          | < 50%          | 用途を確認のうえサイズダウン検討 |
| 通常         | それ以上       | —              | 現状維持                         |

- ディスクIO も併せて低い（read/write ともに恒常的に小さい）ほど、サイズダウンの安全度が高い
- **制約**: MCP 経由では直近約1日・average 固定。スパイク検知や長期傾向は取得できない。定期的なバッチ処理やアクセスの少ない曜日・時間帯だけを見て誤判定しないよう、必要ならユーザーに利用パターンを確認する
- 閾値はデフォルト。ユーザー指定があればそれに従う

## サイズダウン提案ロジック

```text
1. `/flavors/detail` を vcpus/ram 昇順に並べる
2. 対象サーバーの現行 flavor の一段下（実測の平均・最大使用率を満たす最小 flavor）を候補にする
   - 例: 平均 CPU 3% / 最大 20% のサーバーが 2vCPU なら、1vCPU 相当へ
   - サイズダウン後の想定使用率は、実測 value（nsec/s。CPU 実仕事量で vCPU 数に依らない）を
     新 vCPU 数で割り直して求める: 想定使用率(%) = value ÷ (1e9 × 新vCPU数) × 100。
     この値が余裕（例: 最大でも 70% 未満）を持つ範囲で選ぶ
3. RAM も要件を割らないか確認（アプリの必要メモリを下回らない）
4. ダウン幅・想定コスト差・リスク（余裕度）を添えて提案する

**プラン制約（提案前に確認）**:
- リサイズはサーバー **SHUTOFF（停止）状態でのみ可能**。実行はダウンタイムを伴う
- メモリ **512MB プランはスケールアップ／ダウンの対象外**。512MB への／からの変更はプラン種別により不可
- 割引きっぷ／長期パス／まとめトク間などプラン種別をまたぐ変更には制限がある
```

## リサイズ実行（conoha-vps-mcp に委譲）

```text
1. conoha_get path="/flavors/detail" → 変更先 flavor の id を確定
2. conoha_post_put_by_param path="/action" param=<id> requestBody={"os-stop":null}
   → conoha_get path="/servers/detail" で status=SHUTOFF を確認（リサイズは停止状態が必須）
3. conoha_post_put_by_param path="/action" param=<id> requestBody={"resize":{"flavorRef":"<新flavorID>"}}
4. conoha_get path="/servers/detail" → status が VERIFY_RESIZE になるまで待機
5. conoha_post_put_by_param path="/action" param=<id> requestBody={"confirmResize":null}
   （問題があれば {"revertResize":null} で取消）
6. conoha_post_put_by_param path="/action" param=<id> requestBody={"os-start":null} → 利用再開
```

- リサイズは課金変更・ダウンタイム（停止→起動）を伴うため、必ずユーザーの明示承認を得てから実行する

## レポート例

```text
【VPS 稼働診断（直近約1日・average）】
対象: 3 台

server-web-01 (2vCPU/2GB)   CPU 平均 3.1% / 最大 18.4%   IO 低    → 🔻 サイズダウン推奨（1vCPU/1GB 相当）
server-api-02 (4vCPU/8GB)   CPU 平均 42%  / 最大 88%     IO 中    → ✅ 現状維持
server-batch-03 (2vCPU/4GB) CPU 平均 6.0% / 最大 61%     IO 高    → ⚠️ 用途確認（バッチのスパイクあり）

提案:
  - server-web-01: 1vCPU プランへリサイズ（想定 CPU 最大 ~37%、余裕あり）
```

## エラー対応ガイド

| エラー                | 原因                            | 対処                                                         |
| --------------------- | ------------------------------- | ------------------------------------------------------------ |
| 401 Unauthorized      | OAuth 認可切れ / scope 不足     | 再認可し `vps:read`（実行時は `vps:write`）を確認            |
| RRD の data が空/null | 起動直後でデータ未蓄積 / 停止中 | しばらく稼働後に再取得。停止中サーバーは稼働時間の実績で判断 |
| vCPU 数が不明         | flavor 情報未取得               | 先に `/flavors/detail` を取得して現行 flavor の vcpus を特定 |
| リサイズが進まない    | VERIFY_RESIZE で停滞            | 状態を再確認し、必要なら revertResize で取消                 |