| name | conoha-vps-mcp-test |
| description | ConoHa VPS MCPサーバーの動作確認テストを自動実行するスキル。 「ConoHa テスト」「MCP動作確認」「動作検証」「conoha-test」「MCPテスト」 「VPSテスト」「検証項目」などのキーワードで発動する。 |
ConoHa VPS MCP 動作確認テストスキル
概要
ConoHa VPS MCPサーバーの全機能（37項目）を一括テストし、結果をMarkdownレポートとして出力する。
前提条件
- ConoHa VPS MCP サーバーが接続済みであること
- MCP ツール（
conoha_get, conoha_post, conoha_post_put, conoha_post_put_by_param, conoha_post_by_header_param, conoha_get_by_param, conoha_delete_by_param, conoha_head, encode_base64, fetch_url）が利用可能であること
実行 ID（RUN_ID）
並列実行時のリソース名衝突を防ぐため、テスト実行ごとに一意な RUN_ID を決め、作成する全リソース名・一時ファイルパスに付与する。
RUN_ID="${GITHUB_RUN_ID:-$(date +%Y%m%d%H%M%S)-$RANDOM}"
- ネームタグ:
test-${RUN_ID}
- SSHキー名:
ssh_key_${RUN_ID} ／ SSHキー生成パス: /tmp/test_ssh_key_${RUN_ID}
- HTMLファイル:
/tmp/test_index_${RUN_ID}.html
- セキュリティグループ等その他の作成リソース名も
<名前>-${RUN_ID} とする
references/test-cases.md 内の固定名（test / ssh_key / web-server-secgroup 等）は、上記に倣い <固定名>-${RUN_ID} のテンプレートとして扱う
テスト用リソース準備
テスト開始前に以下を実行する（既存ファイルがあってもプロンプトでハングしないよう、生成前に必ず削除する）:
-
SSHキー生成（Group M, N で使用）:
rm -f "/tmp/test_ssh_key_${RUN_ID}" "/tmp/test_ssh_key_${RUN_ID}.pub"
ssh-keygen -t ed25519 -f "/tmp/test_ssh_key_${RUN_ID}" -N "" -q
-
テスト用HTMLファイル作成（Group S で使用）:
cat > "/tmp/test_index_${RUN_ID}.html" << 'EOF'
<!DOCTYPE html>
<html><head><title>Test</title></head>
<body><h1>ConoHa MCP Test Page</h1></body></html>
EOF
実行ルール
サブエージェント実行モデルとメインへの返却
各グループは独立したサブエージェント（Agent/Task）で実行してよい。グループ間は下記の依存順を守り、依存のないグループは並列実行できる（並列時は前述の RUN_ID でリソース名衝突を防ぐ）。
サブエージェントがメインに返す情報は最小限にする（全応答を返さない。コンテキスト肥大と読み取り負荷を防ぐため）:
- グループ内各テストの OK / NG 判定一覧（テストNo. と結果のみ）
- NG のときだけ、原因特定に必要な情報を返す:
- 失敗テストNo.
- 使用したMCPツール名
- 渡したパラメータ（path / param / body）
- レスポンス抜粋（エラー該当部、または先頭〜数百字。全文は返さない）
- 期待した挙動 と 実際の挙動
- 各ツール呼び出しの全文レスポンスや成功時の詳細ログはサブエージェント内でログファイルに書き出す（「実行ログ記録」参照）。メインには返さない。
- メインは各サブエージェントの OK/NG サマリのみを集約し、最終レポート（
references/report-template.md）を生成する。
グループ実行順序
全グループを実行する場合は Group A → B → C → D → E → F → G → H → I → J → K → L → M → N → O → P → Q → R → S の順に実行する。
単一グループのみ実行する場合の依存解決: 各グループは自グループ内でサーバー作成（No.1）等の前提を内包する自己完結構成だが、グループ外の「テスト用リソース準備」前提は単独実行時に明示的に先行実行する:
RUN_ID の決定は常に最初に行う。- Group M / N: SSHキー（
/tmp/test_ssh_key_${RUN_ID}）生成を先に実行（references/test-groups.md の各グループ「前提」を参照）。
- Group S: テスト用HTMLファイル（
/tmp/test_index_${RUN_ID}.html）作成を先に実行。
- 前提リソースが見当たらない場合は、該当グループの実行前に「テスト用リソース準備」の該当手順だけを実行してから本体に入る。
共通パラメータ
- パスワード:
vG7#kLp9zX!q
- ネームタグ:
test-${RUN_ID}
- セキュリティグループ:
default（基本）
状態遷移の待機
サーバーの状態遷移が必要な場合（起動/停止/リサイズ等）は、conoha_get で path="/servers/detail" を呼び出してステータスを確認し、目的の状態になるまで待機する。
- ACTIVE: 起動完了
- SHUTOFF: 停止完了
- VERIFY_RESIZE: リサイズ確認待ち
- BUILD: 構築中（待機が必要）
無限待機の禁止: 待機にはタイムアウト（目安: 1グループあたり最大10分）と最大ポーリング回数を設ける。超過した場合、または ERROR ステータスを観測した場合は、そのテストを NG（後述の原因特定情報付き）として打ち切り、クリーンアップへ進む。
クリーンアップ
各グループ完了後、作成したリソースを必ず削除する:
- サーバー削除 → ボリューム削除 の順序で実行
- セキュリティグループは最後に削除
- SSHキーペアは使用後に削除
想定外の例外時の扱い
テスト中に想定外の事態（ツールが想定外のエラー/形式を返す、状態遷移タイムアウト、ネットワーク断、前提リソース欠落 等）が起きた場合の共通ルート:
- 記録: 当該テストを NG とし、「サブエージェント実行モデル」の原因特定情報（失敗No / ツール / パラメータ / レスポンス抜粋 / 期待・実際）を残す。
- 後続判断: 失敗テストに依存する後続ステップ（例: サーバー作成失敗時のそのサーバーを使う操作）は中断する。依存しない他グループは続行してよい。
- クリーンアップは必ず試みる: 例外発生時もそれまでに作成したリソース（サーバー/ボリューム/SG/SSHキー/一時ファイル）の削除を試みる。例外でクリーンアップを飛ばすと課金リソースが残留する。削除自体が失敗した場合は、残留リソースの種別とIDをレポートに明記する。
- 返却: サブエージェントは「どのステップで何が起きたか」の例外サマリのみをメインに返す（スタックトレースや全文ログは返さずログファイルに残す）。
異常系テストの確認方法
異常系テスト（No.24〜No.30）では、MCPツール呼び出し前にバリデーションで拒否されることを確認する。実際にAPIが呼ばれてエラーになるのではなく、ツール側でバリデーションエラーとなることが期待される。
Prompt実行テスト（No.21, No.30）— スキップ禁止
create_server はMCPプロンプトであり、MCPツールとして直接呼び出すことはできない。
しかし、プロンプトの実質的な動作はMCPツールで代替検証できるため、これらのテストをスキップしてはならない。
- No.21（正常系）:
create_server プロンプトはサーバー作成をMCPツールで行うよう指示するものである。
そのため、No.1と同じ手順（conoha_get でフレーバー・イメージ・ボリュームタイプ取得 → conoha_post でボリューム作成 → conoha_post path=/servers でサーバー作成）を
adminPass=vG7#kLp9zX!q、Ubuntu 24.04、メモリ1GB、サーバー名 test-${RUN_ID} で実行し、サーバーがACTIVEになることを確認する。
- No.30（異常系）:
create_server プロンプトの rootPassword バリデーションは conoha_post path=/servers の adminPass バリデーションと同一の正規表現を使用している。
そのため、conoha_post path=/servers でサーバー作成を試み、adminPass=aaa を指定してバリデーションエラーになることを確認する。
No.24と同様にMCPツール呼び出し前のバリデーション拒否を確認すればよい。
結果記録
各テスト実行後、references/report-template.md のフォーマットに基づき結果を記録する。
実行ログ記録
各MCPツール呼び出しの後、以下の情報をログファイルに記録する:
- ツール名: 呼び出したMCPツール（例:
conoha_get）
- パラメータ: ツールに渡した全パラメータ（path, param, bodyなど）
- レスポンス: ツールから返されたレスポンス内容（JSON）
ログは references/report-log-template.md のフォーマットに基づき、グループ・テストNo.・ステップごとに時系列で記録する。
この全文ログはファイルにのみ書き出し、サブエージェントからメインへは返さない（メインへの返却は「サブエージェント実行モデル」の OK/NG サマリと NG 時の原因特定情報に限る）。サブエージェントで並列実行する場合、ログファイルは RUN_ID とグループ名でファイル名を分け、書き込み衝突を避ける。
出力
テスト結果は以下のパスに出力する:
- 結果レポート:
./test-results/YYYY-MM-DD_HH-MM.md
- 実行ログ:
./test-results/YYYY-MM-DD_HH-MM_log.md
（YYYY-MM-DD_HH-MM はテスト実行開始時の日時）
リファレンス
