test-monitor: モニタリング基盤の構築支援

ISTQB/JSTQB のテストプロセス 7 活動のうち、テストモニタリング&コントロール （test monitoring and control）を担う単機能スキル。ただし担当は モニタリングの 「基盤構築」に限定 する。メトリクスを定義し、プロジェクトの CI/ツール構成を調査した上で、 計測を自動で回すための 基盤（CI 設定・集計スクリプト・バッジ等）の実装を支援 する。 成果物はメトリクス定義ドキュメント test-monitoring.md と、それを実現する実装物。

このスキルがやらないこと（重要）

• AI が継続的なモニタリングを代行しない。数値を継続的に眺めて報告するのは AI の仕事では なく、ここで構築する 計測基盤（CI・スクリプト）が自動で行う。このスキルは「基盤を作る」 ところまでで、実運用のウォッチはしない。
• 集まったデータの分析・傾向判断は対象外。「失敗率が上がっている原因は何か」「この傾向を どう解釈するか」といった分析は行わない。結果の評価・完了判定は test-report の担当。 ここで定義するメトリクスは、test-report が評価に使う 入力を用意する ためのもの。
• 単発のテスト作成依頼（単にユニットテストを 1 つ書きたいだけ）は対象外 — その場合は 通常のコーディング支援で対応する。

このスキルは モニタリング基盤の構築だけ を行う。テスト計画（test-plan）・条件識別 （test-analyze）・設計（test-design）・実装（test-implement）・実行（test-execute）・ 評価（test-report）は各専用スキルの担当で、ここでは呼び出さない。

このスキルが従う横断原則

testing-skills 全 8 スキル共通の原則。

1. ファイル規約 + 任意入力

• 成果物の既定パスは docs/test/<テスト対象名>/test-monitoring.md。実装物（CI 設定・ 集計スクリプト等）は プロジェクトの慣習に沿った場所（.github/workflows/・scripts/ 等）に置く。
• プロジェクト側（CLAUDE.md / AGENTS.md 等）に成果物・スクリプトの配置規約があれば そちらを優先する。着手前にリポジトリを調べ、既存の CI 構成・ツールチェーンに合わせる。
• 前工程の成果物 test-plan.md（test-plan） が規約パスにあれば 入力として読む。 メトリクスは計画の 完了基準（exit criteria） と紐づけて定義する。トレーサビリティ系 メトリクスを採用する場合は test-analysis.md・test-case.md も取得元の入力になる。
• 前工程の成果物が無ければ代作しない。完了基準の根拠が要るときは「先に /test-plan を 実行してください」と 提案するに留める。

2. 調査優先 + 決定のみ質問

• 事実はリポジトリ調査で埋める。CI プロバイダ（GitHub Actions 等）・テストランナー・ カバレッジツール・既存のバッジやレポート出力は、利用者に訊く前に自分で調べる。基盤の実装は この調査結果（実在するツール構成）に基づいて行う。
• 利用者にしか決められない判断だけ を AskUserQuestion で確認する。test-monitor では 主に どのメトリクスを採用するか・しきい値・可視化の手段（バッジ/PR コメント/ダッシュボード） が これに当たる（推奨案を先頭に添えて訊く）。
• 流れは 調査 → ドラフト提示 → 承認 → 規約パスへ書き込み・実装。承認前に確定ファイルや CI 設定を書かない。

3. 改善提案と仕様反映（early testing 原則）

• 基盤構築中に見つけた テスト対象・仕様・テスタビリティの問題（メトリクスが取得できない 構造、計測不能な完了基準、CI に載せられないテストなど）は、成果物の「改善提案」セクションで 提示 する。
• 起票前に既決事項を照合する。前工程成果物（test-plan 等）とプロジェクトのメモリに同じ 問題が既に記録され、対応先（詳細設計送り・作業計画送り等）が確定しているものは改善提案に 再掲しない。必要なら「次のステップ」欄の参照 1 行に留める。改善提案には この工程で 新規に見つけた未解決の問題だけ を載せる。
• 仕様の穴は提示で終わらせない。基盤構築の過程で仕様の曖昧さ・矛盾が割れた場合は、利用者の 決定を AskUserQuestion で確認し、決定が出たら その内容を仕様書へ反映する作業まで行う （反映先の仕様書が規約パスにある場合）。メトリクスが取得できない構造・CI に載せられない テストのような実装レベルで解決すべき決定は、仕様書ではなく作業計画・メモリ等へ退避する。
• 反映が済んだ提案は「改善提案」セクションから削除する（「反映済み」注記で残さない。 決定の記録は仕様書の改訂履歴が担う）。全提案が解消したらセクションごと削除して番号を詰め、 未解決の提案が残っている間だけセクションを維持する。
• スキル自身がテスト対象のコードを修正しない。計測基盤の追加（CI・スクリプト）は行うが、 テスト対象そのものの改変はしない。

4. 単機能の堅持

• test-monitor は メトリクス定義と計測基盤だけ を作る。他スキルを呼び出さず、相互参照もしない。
• 計測結果の評価が必要になったら、成果物末尾で /test-report の実行を提案 するに留める （自分でデータ分析・評価を行わない。原則の「データ分析は対象外」と一致）。

5. Progressive disclosure

• 本文は簡潔に保ち、テンプレ・詳細は references/ に置く。
• テンプレ: references/template.md（test-monitoring.md の雛形）。
• mini サマリ雛形: references/mini-template.md （mini-test-monitoring.md の雛形。手順 5 で使う）。
• メトリクス早見表: references/metrics-catalog.md （進捗・カバレッジ・失敗率・flaky 率などの定義と取得元）。

6. 成果物の記述スタイル

Markdown 成果物（test-monitoring.md・改善提案等）に適用する。実装物（CI 設定・ 集計スクリプト）はプロジェクトのコード規約・既存 CI 構成の書き方に従う（手順 3）。

• 略号・コードネームを定義なしで使わない（例: 仕様書内の G3 のような社内略号）。 初出で正式名称・意味を併記するか、平易な表現に開く。成果物単体で読み返して意味が 取れることを基準にする。
• スキルの実行記録を成果物に含めない。利用者との Q&A ログ・フェーズ別実行時間などは 対話のテレメトリであって、レビュー対象の内容ではない。利用者との決定事項は本文の該当箇所 （根拠・凡例等）へ埋め込み、実行記録が必要なら scratchpad 等へ分離する。

手順

手順 0: テスト対象の確定

• 引数 <テスト対象名> があればそれを対象名とする。無ければ利用者に一言で確認する。 対象名は成果物パス docs/test/<テスト対象名>/ のディレクトリ名にも使う （英数字・ハイフンへ正規化）。

手順 1: CI/ツール構成の調査

原則 2 に従い、以下を 自分で調べる（実装はこの結果に基づく）:

• CI プロバイダ: .github/workflows/ 等の有無・既存のテスト実行ジョブ。
• テストランナー・カバレッジツール: 言語/フレームワーク（jest・pytest・go test・gradle 等）と、 カバレッジ・JUnit 形式レポートの出力可否。
• 既存の可視化: README のバッジ・PR コメント・外部ダッシュボード連携の有無。
• 完了基準: test-plan.md の exit criteria（メトリクスの紐づけ先）。
• 工程成果物の ID チェーン: docs/test/<テスト対象名>/ の test-analysis.md・ test-case.md の有無と ID 列（リスク R# / テスト条件 TC-# / ケース CASE-#）。 トレーサビリティ系メトリクスの取得元になる。仕様書に安定した項目 ID 体系があるかも ここで確認する（仕様項目→条件紐づけ率の採用可否）。

手順 2: メトリクスの定義

references/metrics-catalog.md を参照し、対象に適した メトリクスを 完了基準と紐づけて 選ぶ:

• 代表例: テスト進捗（消化率）・カバレッジ・失敗率・flaky（不安定）率・実行時間・ トレーサビリティ（リスク→条件カバー率・条件→ケース化率）。
• 各メトリクスに 定義・取得元（どのツール出力から得るか）・しきい値・完了基準との対応 を与える。
• 採用メトリクス・しきい値・可視化手段は利用者判断を含むので、必要なら AskUserQuestion （推奨案先頭）で確認する。

手順 3: 計測基盤の実装支援

手順 1 の調査で判明した 実在するツール構成に基づいて 基盤を実装する:

• CI 設定: テスト・カバレッジ集計ジョブの追加/拡張（既存構成を壊さない差分で）。
• 集計スクリプト: ランナー出力（JUnit XML・カバレッジレポート等）や工程成果物 （test-analysis.md・test-case.md の ID 列。トレーサビリティ系の場合）からメトリクスを 算出するスクリプト。プロジェクトの言語・慣習に合わせる。
• 可視化: バッジ・PR コメント・成果物アップロード等、承認された手段を設定する。
• 実装物は動作確認できる範囲で検証する（構文・ドライラン等）。継続的な数値のウォッチや 傾向分析はしない（このスキルの範囲外。原則で明記のとおり）。

手順 4: ドラフト提示 → 承認 → 書き込み・実装

• references/template.md の構成で test-monitoring.md のドラフトと、 実装（CI 設定・スクリプト）の差分方針を 本文で提示して承認を得る（原則 2）。
• 承認後、規約パスへ test-monitoring.md を書き込み、実装物を配置する。
• 手順 1〜3 で見つけた問題は「改善提案」セクションに記載（原則 3）。
• 計測結果の評価が必要になったら、末尾で /test-report の実行を提案 する（原則 4）。 データ分析・評価はこのスキルでは行わない。

手順 5: mini サマリの作成（レビュー収束後）

• 本編 test-monitoring.md と実装物への利用者フィードバックが出なくなり、確認が完了したら、 同ディレクトリに初見者向けサマリ mini-test-monitoring.md を作成する。レビュー中は 作らない（フィードバックのたびに本編と同期し直すことになるため、収束後に一度だけ作る）。
• 構成は references/mini-template.md に従う。対象ドメインに 詳しくない人へ「何を測っていて、どこで見られるか」を短時間で説明できる状態を目指す。

手順 6: 終了条件の確認と完了宣言

モニタリング基盤構築の終了条件は以下。利用者に「終わりか」と訊かれる前に、 スキル側で判定して宣言する:

1. 採用メトリクスが定義・取得元・しきい値つきで test-plan の完了基準と紐づけて定義済み（手順 2）。
2. 計測基盤（CI 設定・集計スクリプト・可視化）が実装され、構文・ドライラン等で 動作確認済み（手順 3）。
3. 承認済みの test-monitoring.md と実装物が規約パスへ配置済み（手順 4）。
4. 改善提案が空（各提案が仕様反映・対応先確定のいずれかで解消済み）。
5. test-review ゲート: /test-review <テスト対象名> monitor の判定が「通過」または 「条件付き通過」（記録 test-review-monitor.md）になっている、もしくは利用者がゲートの スキップを明示している。未実施なら完了宣言せず、利用者へ実行を促す （test-review は明示起動のみで、本スキルからは起動できない）。
6. mini サマリ作成済み（手順 5）。

• 全て満たしたら 「モニタリング基盤の構築は完了」と明言 して閉じる。以降の計測は基盤が 自動で行い、数値の評価が必要になったら /test-report <テスト対象名> を提案する（原則 4）。
• 満たしていない項目があれば、何が残っているかを列挙して先へ進めない。

用語（JSTQB 訳語 / 初出英語併記）

• テストモニタリング&コントロール（test monitoring and control）: テスト進捗を計測し、 計画との差異に応じて是正する活動。本スキルはこのうち計測基盤の構築に限定する。
• メトリクス（metric）: テストの状態を定量化する指標（進捗・カバレッジ・失敗率 等）。
• flaky（不安定）率: 同一条件で合否が揺れるテストの割合。基盤の信頼性を測る指標。
• カバレッジ（coverage）: テストがテスト対象のどれだけを実行したかの割合。