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 を決め、作成する全リソース名・一時ファイルパスに付与する。

# CI（GitHub Actions）では 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} のテンプレートとして扱う

テスト用リソース準備

テスト開始前に以下を実行する（既存ファイルがあってもプロンプトでハングしないよう、生成前に必ず削除する）:

1. SSHキー生成（Group M, N で使用）:

   # -f 先が既存だと ssh-keygen は "Overwrite (y/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
   

2. テスト用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キーペアは使用後に削除

想定外の例外時の扱い

テスト中に想定外の事態（ツールが想定外のエラー/形式を返す、状態遷移タイムアウト、ネットワーク断、前提リソース欠落 等）が起きた場合の共通ルート:

1. 記録: 当該テストを NG とし、「サブエージェント実行モデル」の原因特定情報（失敗No / ツール / パラメータ / レスポンス抜粋 / 期待・実際）を残す。
2. 後続判断: 失敗テストに依存する後続ステップ（例: サーバー作成失敗時のそのサーバーを使う操作）は中断する。依存しない他グループは続行してよい。
3. クリーンアップは必ず試みる: 例外発生時もそれまでに作成したリソース（サーバー/ボリューム/SG/SSHキー/一時ファイル）の削除を試みる。例外でクリーンアップを飛ばすと課金リソースが残留する。削除自体が失敗した場合は、残留リソースの種別とIDをレポートに明記する。
4. 返却: サブエージェントは「どのステップで何が起きたか」の例外サマリのみをメインに返す（スタックトレースや全文ログは返さずログファイルに残す）。

異常系テストの確認方法

異常系テスト（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 はテスト実行開始時の日時）

リファレンス

• テストケース詳細 - 全37テストケースの定義
• グループ定義 - 19グループの実行順序・依存関係
• レポートテンプレート - 結果レポートのフォーマット
• 実行ログテンプレート - 実行ログのフォーマット