# ai-test-process-mcp [Health: Active]

**Category:** 💻 Developer Tools  
**Repository:** https://github.com/Hashi-Kazu/ai-test-process-mcp  
**GitHub Stars:** 0  
**npm Downloads (last month):** 5860  
**Views:** 0  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/ai-test-process-mcp

## Description
AI-assisted MCP server for JSTQB-based test planning, design, review, and analysis.

## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `npx` (confidence: high):

```json
"mcpServers": {
  "ai-test-process-mcp": {
    "command": "npx",
    "args": ["-y","@modelcontextprotocol/inspector"]
  }
}
```

## Documentation & README

# ai-test-process-mcp

**JSTQB/ISTQB Generic Test Process を AI で支援する MCP サーバー。**

テスト管理ツールの操作を目的とせず、Generic Test Process の各工程（Test Planning 〜 Test Completion）において、テスト成果物の作成・レビュー・分析を AI で支援することを目的とする。文書構成は JSTQB準拠の15章テンプレートに基づく。

**現在のスコープ（Phase 1〜3: Test Planning + Test Analysis + Test Design）**: テスト計画書（JSTQB準拠15章構成）の日本語ドラフト生成・JSTQB観点でのレビュー・修正支援・質問形式でのコンテキスト収集ガイド、要件分析・テスト条件抽出、境界値分析・同値分割・テストケース生成によるテスト設計技法、および探索的テストのチャーター設計を含む経験ベース技法。
**将来構想**: Test Analysis（要件分析・テスト条件抽出）、Test Design（テストケース生成・テスト仕様書レビュー）を経て、Generic Test Process 全7工程へ段階的に拡張する。詳細は [docs/roadmap.md](./docs/roadmap.md) を参照。

## インストール（利用者向け）

npmに公開済みのため、ビルド不要ですぐに使える。Claude Desktop / Claude Codeの設定に以下を追記する（Node.js 18以上が必要）。

```json
{
  "mcpServers": {
    "ai-test-process-mcp": {
      "command": "npx",
      "args": ["-y", "ai-test-process-mcp@latest"]
    }
  }
}
```

`@latest`を付けることで、新しいバージョンが公開されたときに手動でキャッシュを消さなくても自動的に反映される。

## セットアップ（開発者向け）

```bash
git clone https://github.com/Hashi-Kazu/ai-test-process-mcp.git
cd ai-test-process-mcp
npm install
npm run build
```

## 提供する機能

### Tool: `create_test_plan`

プロジェクト情報（`projectName`, `scope` は必須。`objectives`, `risks`, `scheduleConstraints`, `team`, `testItems`, `stakeholders`, `glossary` など多数の任意項目）を入力すると、JSTQB準拠の15章構成に沿った**日本語**Markdown形式のテスト計画書ドラフトを生成する。未入力の項目は `_未記入_`（必須項目は `_未記入（必須）_`）として明示される。テストタイプ説明・インシデントランク等の固定リファレンスは常に出力される。

### Tool: `review_test_plan`

テスト計画書のMarkdown本文を入力すると、JSTQB観点でレビューレポートを返す。二層構成: (1) 構造検査（15章の欠落・必須項目の未記入を決定的に検出）、(2) 意味的レビュー用チェックリスト（呼び出し側のLLMが内容の妥当性を判断するための指示形式）。

### Tool: `revise_test_plan`

既存のテスト計画書Markdownと修正指示（`instructions`、任意の文字列配列）を入力すると、修正結果レポートを返す。二層構成: (1) 機械的修正（欠落章の自動補完、`TBD`/`TODO`/`未定`等の未記入プレースホルダの `_未記入_` への正規化）を適用した修正後計画書、(2) 内容の書き換えを呼び出し側LLMに指示する箇条書き（ユーザー指定の修正指示、および修正後もなお残る必須未記入項目の一覧）。

### Prompt: `test_plan_interview`

質問形式でテスト計画書のコンテキストを収集するためのガイド。テンプレートの必須項目を中心に、ユーザーへ順に質問して回答を集め、`create_test_plan` を呼び出すようアシスタントを誘導する。任意引数 `projectName` を受け取る。

### Tool: `design_boundary_values`

変数の有効範囲（下限・上限・刻み・型）から2値/3値の境界値を決定的に列挙し、有効/無効判定付きのMarkdown表で返す。

### Tool: `design_equivalence_partitioning`

変数ごとの有効/無効同値クラスから代表値ベースのテストケースを決定的に生成し、全クラス被覆チェック付きのMarkdown表で返す。

### Tool: `design_decision_table`

条件項目（原因）とその取り得る水準・無効組合せ（ありえない組合せと理由）・ルール（条件セレクタ→動作）から、全組合せの決定的な列挙 → 無効組合せの除外 → 同一動作列の圧縮（don't care 導出）を行い、条件組合せ被覆・動作未定義組合せ（DTC-06）・食い違う動作の矛盾（DTC-07）・圧縮前後の列数と削減率をMarkdownで返す。圧縮後の各ルールは `DT:` プレフィックスの網羅対象IDとして `generate_test_cases` の `decisionTable` へそのまま渡せる。`analyze_cause_effect` の「デシジョンテーブルへの引き渡し」出力（`DecisionTableSpec` 形式。水準 `["T","F"]` の条件項目・動作項目、制約由来の無効組合せ、圧縮後ルールを含む）をそのまま入力にできる。

### Tool: `design_pairwise`

因子（`factors[]`: `id` / `name` / `levels`）・禁則（`forbiddenCombinations[]`: ありえない組合せと理由）・必ず含めたい既知の重要組合せ（`seedRows[]`）を入力すると、全ての水準ペアの正準順での列挙 → 禁則による到達不能ペアの判定 → ペアを被覆する組合せの決定的な貪欲法での生成、を行い、因子・水準表、禁則表、到達可否表、生成した組合せ表、行別の新規被覆ペア、決定的検査、網羅対象一覧、サマリの8節をMarkdownで返す。乱数・現在時刻を使わないため、同一入力からは常に同一の組合せ表が得られる。生成した各ペアは `PW:<setId>:P<n>` 形式の網羅対象IDとして出力され、そのまま `generate_test_cases` の `pairwise` へ渡すとペア被覆率を決定的にカウントできる。ペア被覆率の分母は「全ペア数 − 禁則により到達不能なペア数 − 探索上限により判定保留となったペア数」であり全ペア数ではない旨を明示する。削減率の分母は、全組合せを厳密列挙できたときは「禁則適用後の有効組合せ数」、列挙上限（`maxEnumerationCombinations`、既定4096）を超えるときは「禁則適用前の全組合せ数」であり、いずれを使ったかを出力に明記する。全組合せ数が安全整数を超える場合は削減率を推測値で出さず「未算出（理由）」と明記する。全ペア数が上限（`maxPairCount`、既定5000）を超える場合や入力に致命的な指摘がある場合は組合せ生成を行わず、算出できたカウントのみを返す。因子・水準は `testcondition://factor/ralph-frame` の因子表（`FHO-04`）からそのまま投入できる。判定区分と対処指針は `testdesign://pairwise/analysis-criteria` を参照する。

### Resource: `testdesign://pairwise/analysis-criteria`

`design_pairwise` の判定区分カタログ（`PWC-01`〜`PWC-12`、自作パラフレーズ）を構造化データ（JSON）として公開する。未宣言の因子ID・水準の参照、因子ID/水準の重複、組合せに寄与しない因子、因子数不足、禁則により到達不能なペア、有効な組合せが存在しない、冗長・到達不能な禁則、seed行の不正、ペア数の上限超過、到達可否の判定保留、ペア被覆率が100%未満、の各区分について重大度・定義・推奨アクションを含む。ペア被覆率・削減率それぞれの分母の定義と、本検査が渡された因子・水準・禁則に対してのみ成立するという限界も注記として持つ。

### Tool: `design_scenario_flows`

アクター（`actors[]`）・ユースケース（`useCases[]`: 事前条件・主フロー・代替フロー/例外フロー）を入力すると、主フロー単独のシナリオと、各分岐を1件ずつ通過するシナリオを宣言順に決定的に展開し、アクター一覧、ユースケース・フロー一覧、シナリオ一覧、分類サマリ、機能ID被覆、テスト条件との突合、決定的検査、網羅対象一覧、サマリの9節をMarkdownで返す。シナリオの分類は分岐の終了状態（`outcome`）だけで決まり、主フロー単独は正常系、目的を達成する分岐は準正常系、目的未達で終わる分岐は異常系になる（分岐の種別 `kind` は分類に影響しない）。1シナリオは「主フロー＋高々1分岐」であり、複数分岐が同時に絡む経路は生成しない（必要なら `generate_test_cases` の `additionalCoverageTargets` で補う）。乱数・現在時刻を使わないため、同一入力からは常に同一のシナリオ一覧が得られる。各フローは `UC:<useCaseId>:<flowId>`、各シナリオは `SC:<useCaseId>:S<n>` 形式の網羅対象IDとして出力され、そのまま `generate_test_cases` の `scenarioFlows` へ渡すと主要・代替フロー被覆とシナリオ被覆を決定的にカウントできる。機能ID被覆率は機能ID母集団（`featureIds`）が宣言されているときだけ、宣言母集団を分母・ステップが実際に通過した機能IDを分子として算出し、未宣言なら数値を出さず「未算出（理由）」と明記する。入力に致命的な指摘がある場合や1ユースケースあたりのシナリオ数が上限（`maxScenariosPerUseCase`、既定200）を超える場合はシナリオ生成を行わず、指摘のみを返す。判定区分と対処指針は `testdesign://scenario-flow/analysis-criteria` を参照する。

### Resource: `testdesign://scenario-flow/analysis-criteria`

`design_scenario_flows` の判定区分カタログ（`SFC-01`〜`SFC-14`、自作パラフレーズ）を構造化データ（JSON）として公開する。未宣言アクターの参照、ユースケースID・分岐IDの重複、ステップ番号の不整合、分岐位置・復帰位置の不整合、分岐条件の未宣言、未宣言の機能IDの参照、例外フローの欠如、シナリオ分類の偏り、どのシナリオも通過しない機能ID、機能IDが1件も紐づかないフロー、テスト条件が求める機能IDの未通過、テスト条件に紐づかない通過機能ID、重複シナリオ、シナリオ数の上限超過、の各区分について重大度・定義・推奨アクションを含む。シナリオ展開の方針（主フロー＋高々1分岐）、分類が `outcome` だけで決まること、機能ID被覆率を母集団宣言時のみ算出すること、フロー被覆率とテストケースに対する実被覆の違い、および本検査が渡されたユースケース・フローに対してのみ成立するという限界も注記として持つ。

### Tool: `design_test_architecture`

テストコンテナ（`containers[]`: 責務・テスト目的・テストレベル・テストタイプ・優先度クラス・担当観点カテゴリ・テスト対象・実行環境・開始/終了基準）と、コンテナへの帰属先を指定したテスト条件（`testConditions[]`）、任意でテストケース（`testCases[]`）を入力すると、テストスコープ、テストコンテナ一覧、コンテナ階層図（mermaid）、テスト条件のコンテナ帰属、分布（コンテナ×テストレベル／コンテナ×テストタイプ／優先度クラス）、コンテナ別テストサイズ・テストレベル分布、条件→ケースのトレーサビリティ、決定的検査、サマリの9節をMarkdownで返す。テスト条件→テストケースの2段しかなかったパイプラインに、テスト条件群を束ねるテストアーキテクチャ層を足し、「どのコンテナが何を保証するか」の宣言と、実際にそこへ帰属したテスト条件・テストケースの実体を突き合わせる。判定は宣言と実体の照合を必ずセットにしており、担当を宣言した観点カテゴリに該当条件が1件も無い場合（宣言のみ）と、帰属条件の観点が宣言に含まれない場合（実体のみ）を双方向で検出し、宣言した分割軸（`decompositionAxisIds`）についても、テストレベル別を宣言したのに実際は1種類しか無いといった不一致を検出する。帰属率は「分母＝入力テスト条件数／分子＝既知コンテナへ1件以上帰属した条件数」を必ず併記し、未帰属条件IDを全件列挙する。分布の構成比の分母は帰属済み条件数であり、未帰属条件は分母から除かず別掲する。コンテナ別テストサイズ分布は `testCases` が渡されたときのみ算出し、未指定時は数値を出さず「未算出（理由）」と明記する。乱数・現在時刻を使わないため、同一入力からは常に同一の出力が得られる。未帰属条件・未知のコンテナID参照・コンテナIDの重複・親子関係の不整合・責務の未記入のいずれかがある場合、またはコンテナ数（`maxContainers`、既定200）・階層深さ（`maxDepth`、既定5）の上限を超える場合は構造の算出を行わず、指摘のみを返す。コンテナ間の実行順序・依存関係・クリティカルパス・リソース集計は対象外。判定区分と対処指針は `testarch://container/design-principles` を参照する。

### Resource: `testarch://container/design-principles`

`design_test_architecture` のテストコンテナ設計原則・判定区分カタログ（自作パラフレーズ）を構造化データ（JSON）として公開する。コンテナ分割軸8種（`TAX-01`〜`TAX-08`: テストレベル別／テスト対象・サブシステム別／テストタイプ別／品質特性別／リスク強度別／テストサイクル・フェーズ別／利用シナリオ・業務別／実行環境・構成別。各軸に「この軸で割るべきかの問い」「適する状況」「その軸だけで割ると何が見えなくなるか」を持つ）、コンテナが宣言すべき責務定義項目9種（`RFD-01`〜`RFD-09`、必須項目は責務・テストレベル・テストタイプ・優先度クラス）、優先度クラス3種（`TPR-01`〜`TPR-03`: 必須実施／条件付き実施／任意実施。各クラスが許容するテスト条件の優先度を持ち、この対応が判定データ源になる）、テストスコープ宣言項目3種（`TSC-01`〜`TSC-03`）、判定区分17種（`TAC-01`〜`TAC-17`）を含む。判定区分は、どのコンテナにも帰属しないテスト条件、未知のコンテナID参照、コンテナIDの重複、親子関係の不整合、責務・テスト目的の未記入、テスト条件の重複帰属、テスト条件が空の葉コンテナ、テストタイプの未宣言、優先度クラスと帰属条件の優先度の不整合、担当観点カテゴリの宣言と帰属実体の不一致、未知の観点カテゴリID参照、宣言テストレベルと帰属ケースの実レベルの不一致、テストスコープの宣言不足・実体との不一致、テストケースまで到達していないテスト条件、コンテナ数・階層深さの上限超過、分割軸の宣言と実体の不一致、の各区分について重大度・定義・推奨アクションを含む。構成比の分母の定義、テストケース未指定時に数値を出さないこと、実行順序・依存関係を対象外とすること、および本検査が渡されたコンテナ・テスト条件に対してのみ成立するという限界も注記として持つ。

### Tool: `design_test_data`

データ区分（`dataClasses[]`: ライフサイクル状態・状態間の遷移とイベント・準備担当・調達方法・共有方針・同一データとみなす鍵属性）、データ管理表の実体（`dataItems[]`）、テストケースが要求する前提データ（`testCases[]`: 区分・状態・実体・read/update）を入力すると、データ区分一覧、データ区分×ライフサイクル状態マトリクス、状態遷移一覧と通過ケース、データ実体一覧、データ×テストケース供給トレーサビリティ、排他・実行順序が必要な組合せ、決定的検査、網羅対象一覧、サマリの9節をMarkdownで返す。供給元の有無はIDの存在だけでなく初期状態から遷移グラフを辿った到達可能性（BFS）で判定し、本文裏付け（`TDC-11`）を通過した要求だけを状態/遷移被覆の分子に数える。同一データを更新する複数ケースは `dataItemId`、または `dataClassId` とキー属性（`keyAttributes`）の値の組で同定し、6節の排他表に列挙する。共有方針（`shared`/`exclusive`/`per-case`）を宣言した区分については、宣言と実際のアクセス実体の不一致（`TDC-14`/`TDC-15`）を検出する。乱数・現在時刻を使わないため、同一入力からは常に同一の出力が得られる。各状態は `DL:S:<dataClassId>:<stateId>`、各遷移は `DL:T:<dataClassId>:<transitionId>` 形式の網羅対象IDとして出力され、そのまま `generate_test_cases` の `testData` へ渡すと状態遷移被覆を決定的にカウントできる。ID重複・未宣言ID参照・初期状態の宣言不正・遷移イベントの未記入のいずれかがある場合、またはデータ区分数（`maxDataClasses`、既定100）・区分あたりの状態数（`maxStatesPerClass`、既定50）の上限を超える場合はマトリクス・被覆の算出を行わず、指摘のみを返す。実行順序（トポロジカルソート・クリティカルパス）・要員/リソースの集計は対象外（将来の `analyze_execution_order` の担当領域）。判定区分とデータ区分種別カタログは `testdesign://test-data/analysis-criteria` を参照する。

### Resource: `testdesign://test-data/analysis-criteria`

`design_test_data` のデータ区分種別カタログ（`TDK-01`〜`TDK-06`: マスタ系／トランザクション系／カウンタ・連番系／認証・権限系／外部連携・決済系／時刻・期限依存、自作パラフレーズ）と判定区分カタログ（`TDC-01`〜`TDC-18`、自作パラフレーズ）を構造化データ（JSON）として公開する。判定区分は、ID重複、未宣言ID参照、初期状態の宣言不正、遷移イベントの未記入、到達不能な状態、デッドエンド状態、どのケースからも要求されない状態/データ区分、どのケースの update も通過しない遷移、供給元不在、本文裏付けなし、供給過剰、同一データを更新する複数ケース、共有方針(shared)と update要求の不一致、共有方針(exclusive)と共有実体の不一致、不正遷移の要求、上限超過、状態変化前提の区分にupdate要求が無い、の各区分について重大度・定義・推奨アクションを含む。同一データの同定方法（`dataItemId` 優先、無ければ `dataClassId`＋キー属性）、被覆率は本文裏付けを通過した要求だけを分子に数えること、実行順序・依存関係・クリティカルパスを対象外とすること、および本検査が渡されたデータ区分・実体・テストケースに対してのみ成立するという限界も注記として持つ。

### Resource: `testplan://template/standard`

テスト計画書テンプレート（JSTQB準拠15章構成）の構造データ（JSON）を公開する。各セクションの見出し・必須フラグ・入力マッピング（`fieldKey`）に加え、固定リファレンス（テストタイプ・カタログ、インシデントランク、判定ステータス、標準メトリクス等）を含む。

### Resource: `jstqb://glossary/core`

JSTQB（ISTQB）用語のパラフレーズ集（テストレベル・テストタイプ・開始基準/終了基準・テスト条件/テスト観点・レビュータイプ等）を構造化データ（JSON）として公開する。

### Resource: `testplan://review/checklist`

テスト計画書の意味的レビュー用チェックリスト（JSTQB観点、用語集への相互参照付き）を構造化データ（JSON）として公開する。

### Tool: `review_test_basis`

テストベース（要件・仕様）のMarkdown文書一式を入力すると、ID重複・未解決参照・プレフィックス逸脱・曖昧語・数量表現を決定的に検査し、意味的チェックリスト・依頼元への質問状雛形・改善提案を併せて返す。

### Resource: `testbasis://review/checklist`

テストベース（要件・仕様）レビュー用の意味的チェックリスト（改善アクション・用語集への相互参照付き）を構造化データ（JSON）として公開する。

### Tool: `analyze_requirements`

複数のテストベース文書を横断分析し、要件ID体系・数量表現の全文書横断集約・境界値候補（`design_boundary_values` 連携）・用語定義と本文使用の照合・曖昧語検出を決定的に行い、根拠位置必須の指摘表付きMarkdownとして返す。要件ID→文書名・行範囲・引用ラベルの根拠位置（`requirementSources`）もJSON付きで出力し、`extract_test_conditions` / `generate_test_cases` にそのまま引き継げる。品質特性マッピング・ステークホルダー別影響・変更差分4区分は呼び出し側LLMへの指示として出力される。文書全文を受け取るツール（`analyze_requirements` / `review_test_basis` / `audit_id_population` / `review_test_specification`）は、投入されたテキストの規模と検出量（文字数・行数・見出し数・検出ID数・数値トークン数）を「入力ダイジェスト」表として先頭に出力し、検出IDが0件の文書やプレフィックスの検出が極端に少ない文書を抜粋投入の疑いとして `[medium]` で指摘する。

### Prompt: `requirements_analysis_interview`

質問形式で要件分析のコンテキストを収集するためのガイド。開発背景・分析対象文書・スコープ・ステークホルダー・変更差分等を確認し、`analyze_requirements` を呼び出すようアシスタントを誘導する。任意引数 `subjectName` を受け取る。

### Resource: `quality://characteristics/product`

製品品質特性モデル（自作パラフレーズ、機能適合性・性能効率性・互換性・使用性・信頼性・セキュリティ・保守性・移植性の8特性）を副特性・着眼点・関連テストタイプ付きの構造化データ（JSON）として公開する。

### Resource: `testbasis://id-patterns`

要件ID・機能IDの表記ゆれに対応する正規表現パターン集を構造化データ（JSON）として公開する。`analyze_requirements` / `review_test_basis` の `idPatterns` 引数にそのままコピーして使える。`idPatterns` に渡すパターンはキャプチャグループ数で解釈が変わる（1グループ＝group 1 全体をIDとして扱う／2グループ＝`prefix-number` として再構成／0グループ＝マッチ全体）。数値のみ・ドット区切り・アンダースコア区切りのIDは1グループのパターンで指定すると原本と同じ表記のIDになる。

### Tool: `extract_test_conditions`

テスト条件を「テストベース／ステークホルダー／リスク／ガイドワード」の4系統から導出させ、導出元（`source` + `derivedFrom`）を必須メタデータとして検査する。要件ID×テスト条件の双方向カバレッジマトリクス・未カバー要件ID・観点カテゴリの未使用・条件IDの重複/欠番・優先度未設定・`derivedFrom` の未解決参照・未知の推奨技法IDを決定的に検出し、リスクスコア（影響度×発生可能性×変更差分重み）からの優先度導出と宣言優先度の逸脱判定を添えたMarkdownを返す。`derivedFrom` は ID 文字列に加えて `{kind, id}` 形式（`requirement` / `risk` / `stakeholder` / `guideword`）で種別を明示でき、種別ごとに対応する母集団と照合する。`analyze_requirements` の `requirementSources` を渡すか条件ごとに `sourceRefs` を指定すると、条件表に文書名・行番号の根拠位置が表示され、未特定の条件も検出される。観点カタログ・ガイドワード辞書・リスク分析フレームに基づく追加洗い出しは呼び出し側LLMへの指示として出力される。`personas` は「属性（`demographics`）／発言・思考（`saysAndThinks`）／目標（`goals`）／不満点（`painPoints`）」の4象限で記述でき、ペルソナ表は4象限の列で出力され、未記入の象限があるペルソナは決定的に検出される（旧形式の `concerns` は不満点のフォールバックとして引き続き有効）。

### Resource: `testcondition://perspectives/catalog`

テスト観点カタログ（自作パラフレーズ、機能・境界・同値・状態遷移・並行競合・障害回復・性能負荷・セキュリティ・リグレッション等の18カテゴリ）を、観点・着眼点例・関連品質特性・推奨技法付きの構造化データ（JSON）として公開する。

### Resource: `testcondition://guidewords/dictionary`

着目点語彙（12件）・ガイドワード語彙（16件）・質問テンプレート・運用手順を構造化データ（JSON）として公開する。着目点1×着目点2×ガイドワードを掛け合わせ、テストベースに書かれていないテスト条件を機械的に洗い出すために使う。

### Resource: `testcondition://risk/frame`

リスク分析フレーム（影響度軸・発生可能性軸・変更差分軸・ステークホルダー別影響枠・リスクスコア算出式・スコアから優先度への写像）を構造化データ（JSON）として公開する。任意軸として、重篤度4サブ軸（直接影響・波及影響・短期金銭・長期金銭、`RA-SEV-01`〜`RA-SEV-04`）とS/A/B重篤度区分、発生頻度2サブ軸（利用頻度・発生しやすさ係数、`RA-USAGE`／`RA-PRONENESS`、係数調整要因`RA-PF-01`〜）、およびリスク×ステークホルダ影響行列を含む。これらは未記入でも既存の影響度×発生可能性×変更差分の3軸スコアで評価が完結する（`extract_test_conditions` の 4.5節・8節に反映）。

### Resource: `testcondition://factor/ralph-frame`

因子分解フレーム（自作パラフレーズ）を構造化データ（JSON）として公開する。因子の4分類（`FC-01`〜`FC-04`、信号因子・誤差因子・状態因子・制御因子）の定義・問い・水準の割り当て方、水準ヒューリスティック6件（`FLH-01`〜`FLH-06`、範囲型・列挙型・有無型・数量型・時間型・劣化型）、因子ID/水準IDの採番規約、洗い出し漏れの自己点検、および `design_boundary_values` / `design_equivalence_partitioning` / `design_decision_table` / `design_pairwise` への引き渡し規約（`FHO-01`〜`FHO-04`、いずれも `available`）を含む。組合せ技法の入力となる因子・水準を体系的に洗い出すために、技法適用の前段で使う。

### Tool: `generate_test_cases`

テスト条件からテストケース仕様を導出する。二層構成: (1) 決定的層は、境界値分析・同値分割・状態遷移の各入力から網羅対象一覧を機械的に構築し、網羅率カウント・未充足の網羅対象・テスト条件×テストケーストレーサビリティ・ケースIDの重複/欠番/プレフィックス不一致・由来メタデータの未解決参照・期待結果の主観語/空欄・手順の粒度・閾値の直値埋め込みを決定的に検査する。さらに、宣言された網羅対象IDがケース本文（タイトル・前提条件・手順・事後条件）から裏付けられるかを照合して「裏付けあり充足率」を宣言ベースの網羅率と並べて出し（網羅対象IDの流用だけで網羅率が緑になる状態を検出する）、任意入力 `testBasisDocuments`（テストベース全文）を渡すと期待結果の引用文言・IDがテストベースに実在するかを照合する（未指定時は「未実施(要確認)」と明示する）。加えて、`testCases[].testLevel` / `externalDependencyIds` / `estimatedDurationSeconds` / `declaredTestSize`（いずれも任意）を渡すと、`testdesign://testsize/classification-criteria` の客観的基準（外部依存の有無・実行時間上限）でテストサイズを分類し、宣言サイズとの不一致・テストレベルとサイズの不整合・サイズ構成比の偏り・テストレベル間の網羅対象重複を検査する（判定入力が無い場合は「判定不可」を明示する）。(2) 意味的層は、テストケース本文（前提条件・手順・期待結果）の組み立てのみを呼び出し側LLMへの指示として返す。`testCases` が未指定・空の場合は「生成指示のみ」の出力になる。`derivedFrom` は ID 文字列に加えて `{kind, id}` 形式（`requirement` / `risk` / `stakeholder` / `guideword`）で種別を明示でき、`riskIds` / `personaIds` を渡すと種別ごとに対応する母集団と照合する。`requirementSources` / `testConditions[].sourceRefs` / `testCases[].sourceRefs` を渡すと、対象テスト条件表・ケース詳細・トレーサビリティ表に根拠位置（文書名・行番号）が引き継がれる。

### Prompt: `test_design_interview`

質問形式でテスト設計のコンテキストを収集するためのガイド。対象テスト条件・テストベースの特徴・境界値/同値クラス・状態遷移・因子水準・前提条件・閾値パラメータ等を確認し、`generate_test_cases` を呼び出すようアシスタントを誘導する。任意引数 `subjectName` を受け取る。

### Resource: `testdesign://techniques/catalog`

テスト技法カタログ（自作パラフレーズ、境界値分析・同値分割・デシジョンテーブル・状態遷移・ペアワイズ・ユースケース/シナリオ・CRUD/データライフサイクル・競合/タイミング・探索的テスト/エラー推測/チェックリストベースドテストの13技法）と、テストベースの特徴からの技法選定決定表（10行）を構造化データ（JSON）として公開する。`generate_test_cases` / `generate_exploratory_charters` が技法推奨と網羅基準表示に利用する。

### Resource: `testdesign://testsize/classification-criteria`

テストサイズ分類基準（自作整理、Google Test Sizes の考え方を参考にした独自パラフレーズ）を構造化データ（JSON）として公開する。外部依存の判定軸8件（外部ホストへのネットワークアクセス・永続データストア・ファイルシステム・別プロセス起動・並行実行・実機/周辺機器・画面操作・実時間待ち）と、スモール/ミディアム/ラージの3サイズ（実行時間上限 60/300/1800秒、許容する判定軸、妥当なテストレベル、推奨構成比）を定義する。`generate_test_cases` がテストレベル配分の妥当性検査に利用する。外部基準への適合を主張するものではない。

### Tool: `review_test_specification`

「テストベースに対してテスト仕様書が十分か」を評価軸に、テストベース文書一式とテスト仕様書本文（フォーマット不問）、任意の `testCases` / `testConditions` / `risks` を入力として受け取る。要件ID・テスト条件ID・リスクIDの3系統について双方向カバレッジ（forward: 未カバーID、reverse: 根拠不明・過剰テスト候補）を構築し、ID表記の同期（`EH100` と `EH-100` の表記ゆれ）・ケースIDの重複・期待結果の空欄・優先度の付与状況と判定基準の宣言有無・前提条件のプレースホルダー・手順数と期待結果数のバランス・主観語・期待結果の引用文言/IDのテストベース実在照合・網羅基準の宣言有無を決定的に検査する。意味的レビュー用チェックリスト（14項目）と改善提案を併せて返す。`testCases` 未指定時はID抽出ベースの簡易チェックのみを返す。

### Resource: `testspec://review/checklist`

テスト仕様書レビュー用の意味的チェックリスト（網羅性・トレーサビリティ・期待結果の整合・技法の適切さ・実行可能性・観測可能性・再現性・独立性・データ準備可能性・環境指定・変更差分への重み付け・再利用性・用語一貫性・技法選定根拠の14項目）を、改善アクション・用語集への相互参照付きの構造化データ（JSON）として公開する。

### Tool: `generate_exploratory_charters`

探索的テスト（エラー推測・チェックリストベースドテストを含む経験ベース技法）のチャーター表を生成する。二層構成: (1) 決定的層は、観点区分カタログを基にチャーターIDの重複/欠番/プレフィックス不一致・未知の観点区分ID・由来メタデータ（`derivedFrom`）の未解決参照・観点区分の未使用・高優先度テスト条件/リスクの未カバー・タイムボックスと時間予算の超過・ミッション文の主観語を決定的に検査する。(2) 意味的層は、ミッション文（何を確認し、どう揺さぶるか）の言語化のみを呼び出し側LLMへの指示として返す。`charters` が未指定・空の場合は「生成指示のみ」の出力になる。既存のチャーター表を `charters` に渡せば、既存成果物のレビューとしても機能する。任意の `deterministicallyCoveredConditionIds`（境界値分析・同値分割等の決定的技法で既にテストケース化済みのテスト条件ID）を渡すと、探索的テストは決定的技法の補完という位置づけに沿って、その条件を高優先度テスト条件の未カバー検査から除外する。

### Prompt: `exploratory_charter_interview`

質問形式で探索的テストのチャーター設計のコンテキストを収集するためのガイド。対象領域・テスト条件・既存テストケースで手薄な箇所・過去障害/経験上の勘所・観点区分・セッション時間予算・実施者/スキル・記録方法・停止条件を確認し、`generate_exploratory_charters` を呼び出すようアシスタントを誘導する。任意引数 `subjectName` を受け取る。

### Resource: `testdesign://exploratory/charters`

探索的テストチャーターカタログ（自作パラフレーズ、機能横断・状態/中断・データ整合・運用/例外・環境/構成・時刻境界の6観点区分）を、確認観点・操作観点・関連観点区分・推奨タイムボックス・停止の目安・チャーター表の固定列構成付きの構造化データ（JSON）として公開する。`generate_exploratory_charters` が観点区分カタログとチャーター表の列構成に利用する。

### Tool: `audit_id_population`

`extract_test_conditions` 等の「未カバー0件／網羅率100%」が、入力として宣言された母集団にしか効かない問題に対応する。テストベース文書一式（`documents`）から抽出した定義済みID全量と、各ツール呼び出しに実際に渡された母集団（`declaredPopulations`）を突き合わせ、どの母集団にも一度も渡されていないID（未宣言ID）・除外宣言されたID・母集団にのみ存在しテストベースに定義が無いID・文書別の母集団反映率・未投入文書（`expectedDocumentNames`）・母集団間の差分（工程間の縮退）を決定的に検出する。網羅率100%が母集団の縮退（一部のIDだけが繰り返し使われる状態）による見かけの値でないかを検証するために使う。`design_*` 系ツールが発行するコロン区切りの網羅対象ID（`BV:` `EP:` `ST:` `DT:` `PW:` `SC:` `UC:` `DL:` `CFG:`）も既定（`includeCoverageTargetIds: true`）でID索引に含めるため、要件IDだけでなく網羅対象IDの失効参照・未宣言も検出できる。判定区分と対処指針は `testbasis://population/audit-criteria` を参照する。

### Resource: `testbasis://population/audit-criteria`

ID母集団監査の判定区分カタログ（自作パラフレーズ、未宣言ID・除外宣言ID・テストベース未定義ID・未投入文書・工程間の母集団縮退・文書単位の反映率低下の6区分）を、重大度・説明・対処指針付きの構造化データ（JSON）として公開する。`audit_id_population` が判定表の生成に利用する。

### Tool: `audit_cross_matrix`

任意の2軸以上（プロダクトリスク／テスト観点カテゴリ／ペルソナ／機能ID／シナリオ／テストコンテナ／パラメータ／テストタイプなど）を汎用の軸データ（`axes`）として受け取り、軸ペアの直積表を決定的に生成して、**空行・空列（片側にしかない要素）**を列挙する。3軸以上を渡した場合は全組合せの軸ペア（`axisPairs` 省略時は宣言順の `i<j` 全組合せ）を1回の呼び出しで一括報告する。紐づけ（`items[].links`）は無向として扱い、a→b と b→a のどちらか一方の宣言でセルは埋まったとみなし、片方向のみの宣言は別区分として報告する。充填率は分母（`行数 × 列数`）を明示して算出し、行被覆率・列被覆率の分母は除外宣言（`exclusions`）された要素を除いた対象要素数とする。加えて、`declaredCoverage` に宣言された充填率と実測値の照合、`expectedAxisPopulations` による軸母集団の縮退検出、`documents` 本文との双方向の裏付け照合（本文に裏付けの無い軸要素／本文に定義があるのにどの軸にも載っていないID）まで行うため、母集団を縮めたことによる見かけの高充填率を検出できる。`documents` との照合では、`design_*` 系ツールが発行するコロン区切りの網羅対象ID（`BV:` `EP:` `ST:` `DT:` `PW:` `SC:` `UC:` `DL:` `CFG:`）も既定（`includeCoverageTargetIds: true`）で対象に含める。判定区分と対処指針は `testdesign://cross-matrix/audit-criteria` を参照する。

### Resource: `testdesign://cross-matrix/audit-criteria`

多軸マトリクス監査の判定区分カタログ（自作パラフレーズ、`CMX-01`〜`CMX-17` の17区分。未宣言IDへの紐づけ・軸ID/要素IDの重複・空行・空列・自軸内要素への紐づけ・片方向のみの紐づけ・除外理由の未記入・宣言充填率と実測値の不一致・軸母集団の縮退・テストベース本文に裏付けの無い軸要素・テストベースに定義があるのに軸に載っていないID・直積に寄与しない軸・セル数の上限超過・未宣言軸IDの参照/同一軸ペアの指定・完全孤立要素・リンク根拠の未記入・本文に裏付けの無いリンク根拠）を、重大度・説明・対処指針付きの構造化データ（JSON）として公開する。`audit_cross_matrix` が判定表の生成に利用する。

### Tool: `audit_test_design_notations`

ASTER OPENクラス参加要項が成果物2の例として公式に挙げる3記法（FV表・NGT・ゆもつよマトリクス）を、宣言と実体の照合で決定的に検査する。FV表（`fvTable`、機能×検証内容のリスト）はID重複・欠番・検証内容の未記入や定型語のみでの実質未記入・機能母集団（`expectedFunctionIds`）との双方向照合・宣言済み機能被覆率と実測値の一致を検査する。NGT（`ngt`、テスト観点の階層構造）はノードID重複・親子関係の循環・ルート0件/2件以上・テスト条件に落ちない葉ノード・縮退枝や粒度不揃い・葉の深さの偏り・`testcondition://perspectives/catalog` の観点カテゴリIDとの双方向照合・宣言済み葉ノード数と実測値の一致を検査する。ゆもつよマトリクス（`yumotsuyoMatrix`、テストタイプ×テスト観点のマトリクス）は行列ID重複・除外宣言のない空セル・空行/空列・除外理由の未記入・テスト条件母集団との双方向照合・宣言済み充填率と実測値の一致を検査する。加えて、FV表の `ngtNodeId` / ゆもつよマトリクスの行列の `ngtNodeId` を介したNGTとの相互参照、3記法が参照するテスト条件ID集合と入力 `testConditionIds` 母集団との差分など、記法をまたいだ整合まで1回の呼び出しで検出する。網羅率・充填率の宣言（`claimedFunctionCoveragePercent` / `claimedLeafCount` / `claimedFillRatePercent`）は分母を明示して実測と照合し、母集団未宣言時は算出せず「裏付け不能」として指摘する。各記法が未投入の場合は検査を行わず生成指示のみを返す。判定区分と対処指針は `testdesign://notation/catalog` を参照する。

### Resource: `testdesign://notation/catalog`

ASTER参加要項が例示するFV表・NGT・ゆもつよマトリクスの3記法について、「何を表現する記法か」「必須要素」「既存resource/toolとの対応」「出典」を保持する構造化データ（JSON、自作パラフレーズ）。あわせて `audit_test_design_notations` が用いる判定区分カタログ（`TDN-01`〜`TDN-25` の25区分）を、重大度・説明・対処指針付きで公開する。

### Tool: `audit_deliverable_consistency`

テスト計画書・テスト分析書・テスト設計書のように**工程をまたいだ複数成果物**（`deliverables`、2件以上）を突き合わせ、成果物間の不整合を決定的に検出する。検査は4系統: (1) 参照テストベース文書リストの突き合わせ（2桁の文書番号をキーに読了／未読を成果物別のマトリクスへ展開し、成果物間での読了状態の食い違い・同一成果物内の自己矛盾・片側にしか現れない文書を検出。`declaredReferencedDocuments` を渡せば宣言リストと本文実体を、`idPrefixOwners` を渡せば未読宣言文書が所有するIDプレフィックスの実参照まで照合する）、(2) IDの成果物間相互参照（レンジ表記 `R-01〜R-04` を展開したうえで、どの成果物にも定義が無い参照ID・「他成果物の当該節と対応する」という主張の裏付け欠落・後続成果物から一度も参照されない定義済みIDを検出）、(3) 章節参照の実在性（`N.M節` 形式の参照先番号が参照先成果物の見出しに実在するか、併記されたラベルが当該節の見出し・本文に現れるか、参照先成果物が未投入で解決できないかを検出）、(4) 同一項目・同一IDの記述差分（同一単位で異なる値、2-gram 包含率が閾値未満の記述乖離、スコープ／対象外／前提条件／制約／テストレベル／テストタイプの列挙の片側欠落）。加えて「N件」「N/M（X%）」のような件数・網羅率の宣言を、同一箇所に列挙されたIDの実数・分子分母から算出した率・`countClaimSubjects`（未指定時は既定主語カタログ）で解決したプレフィックスの定義済みID実数（＝母集団）と照合し、分母が母集団の実数と一致しない見かけの網羅率と、分子分母の根拠を伴わない裸の達成度%主張を区別して検出する。任意入力（`declaredReferencedDocuments` / `idPrefixOwners` / `countClaimSubjects`）が未指定の検査は合格ではなく「検査不能（要確認）」として出力する。ID索引には `design_*` 系ツールが発行するコロン区切りの網羅対象ID（`BV:` `EP:` `ST:` `DT:` `PW:` `SC:` `UC:` `DL:` `CFG:`）も既定（`includeCoverageTargetIds: true`）で含まれるため、これらのIDについても成果物間の失効参照・後続工程での取りこぼしを検出できる。判定区分と対処指針は `testdesign://deliverable/consistency-criteria` を参照する。

### Resource: `testdesign://deliverable/consistency-criteria`

成果物間整合性監査の判定区分カタログ（自作パラフレーズ、`DCC-01`〜`DCC-17` の17区分。参照文書の読了状態の成果物間不一致・同一成果物内の自己矛盾・片側にしか現れない参照文書・宣言リストと本文実体の不一致・未読宣言文書由来IDの実参照・未解決の成果物間ID参照・対応主張の裏付け欠落・後続成果物から一度も参照されない定義済みID・実在しない章節参照・章節参照の見出しラベル不一致・参照先成果物の未投入・同一IDの同一単位異値・記述文言の乖離・共通項目列挙の片側欠落・件数/網羅率宣言と本文列挙実体の不一致・網羅率宣言の分母が本文定義ID実数と不一致（母集団の縮退検出）・分子分母の根拠を伴わない達成度%の主張）と、共通項目種別カタログ（`DSI-01`〜`DSI-06`）・読了状態語彙・網羅率宣言の既定主語カタログ・達成度語彙を、重大度・説明・対処指針付きの構造化データ（JSON）として公開する。`audit_deliverable_consistency` が判定表の生成に利用する。

### Tool: `audit_coverage_balance`

生成済みテストケース群（`testCases`、`generate_test_cases` の入力をそのまま流し込める項目名）を軸ごとに集計し、**観点カテゴリ別／技法別／テストレベル別のケース数分布**と観点カテゴリ×テストレベルのクロス表を決定的に提示する。本ツールは望ましい分布の基準を持たず、分布そのものには合否を付けない。合否は「宣言と実体の食い違い」に対してのみ付ける: 観点カタログにも技法カタログにも存在しない区分IDの宣言（`CBC-01` / `CBC-02`）、分布軸の未宣言（`CBC-03`、分布表には必ず「未指定」行を出す）、`declaredDistributions` に宣言した区分別件数と実集計の不一致（`CBC-04`）、分布に計上したケースIDが `deliverables` 本文のどこにも出現しない水増し（`CBC-05`）、本文に出現するのに集計対象へ投入されていないケースID（`CBC-06`、母集団の縮退）。割り当て0件の区分（`CBC-07`）と分布の集中度（`CBC-08`、最大区分の占有率・上位2区分の合計）は観測値として `info` でのみ提示する。あわせて成果物中の**独自用語**を4種の規則（鉤括弧語・カタカナ連続・英大文字略語・太字強調語）で機械的に抽出し、用語集セクション不在のままの独自用語使用（`CBC-09`）、どの成果物にも定義が無い用語（`CBC-10`）、定義済みだが本文で未使用の用語（`CBC-11`）、定義文が一致しない重複定義（`CBC-12`）、既知カタログ用語との表記ゆれ候補（`CBC-13`）を検査する。`deliverables` 未指定時は `CBC-05` / `CBC-06` / `CBC-09`〜`CBC-13` を、`declaredDistributions` 未指定時は `CBC-04` を、合格ではなく「検査不能（要確認）」として出力する。構成比(%)は観測値であり達成度ではないため、達成度として提示する場合は `audit_deliverable_consistency` の網羅率検査を併用すること。判定区分と対処指針は `testdesign://balance/coverage-balance-criteria` を参照する。

### Resource: `testdesign://balance/coverage-balance-criteria`

網羅バランス・用語定義監査の判定区分カタログ（自作パラフレーズ、`CBC-01`〜`CBC-13` の13区分。未知の観点カテゴリID宣言・未知の技法ID宣言・分布軸の未宣言・宣言分布件数と集計実体の不一致・計上ケースIDの本文実在性欠落・本文にあるが未投入のケースID・1件も割り当てられていない区分・分布の集中度の観測値・用語集セクション不在のままの独自用語使用・独自用語の定義欠落・定義済みだが本文未使用の用語・同一用語の重複定義・既知カタログ用語との表記ゆれ候補）を、重大度・説明・対処指針付きの構造化データ（JSON）として公開する。あわせて用語集見出しキーワード・汎用語ストップリスト・独自用語候補の抽出規則（`CBT-01`〜`CBT-04`）を保持する。分布は観測値としてのみ扱い、望ましい分布の基準値・目標比率は一切保持しない。`audit_coverage_balance` が判定表の生成に利用する。

### Tool: `generate_user_story_map`

上流の利用状況モデリング（ドメイン分析 → ペルソナ立案 → ユーザーストーリーマップ5階層 → テスト要求導出）を支援する。二層構成: (1) 決定的層は、アクティビティ/タスク/ユーザーストーリー/テスト要求のID重複・欠番・プレフィックス不一致、階層参照（`personaIds` / `activityId` / `taskId` / `storyIds`）の未解決、ユーザーストーリーが1件も紐づかないペルソナ、テスト要求0件のペルソナ、ペルソナ4象限の未記入、テスト要求行（現状(Before)/将来(After)/テスト要求）の欠落、ドメイン分析観点の被覆状況を決定的に検査する。(2) 意味的層は、フレームの質問例に基づく深掘り指示のみを呼び出し側LLMへ返す。`activities` / `tasks` / `stories` / `testRequirements` が未指定・空の場合は「生成指示のみ」の出力になり、既存成果物を渡せばレビューとして機能する。導出したテスト要求は `source="stakeholder"` のテスト条件として `extract_test_conditions` へ引き渡す対応表付きで出力される。

### Prompt: `persona_journey_interview`

質問形式で上流の利用状況モデリングのコンテキストを収集するためのガイド。ドメイン分析（提供サービス・利用者/従業員の構成・業務フロー・IT化傾向・法規制・季節性）→ ペルソナ4象限（属性・発言・思考・目標・不満点）→ プロダクトゴール → アクティビティ・タスク → ユーザーストーリー → テスト要求（Before/After）を順に確認し、`generate_user_story_map` を呼び出すようアシスタントを誘導する。任意引数 `subjectName` を受け取る。

### Resource: `testcondition://persona/journey-frame`

上流の利用状況モデリング用フレーム（自作パラフレーズ）を構造化データ（JSON）として公開する。ドメイン分析の観点（`DOM-xx`、提供サービス・利用者/従業員構成・業務フロー・IT化傾向・法規制・季節性）、ペルソナ4象限の定義（`PQ-01`〜`PQ-04`、質問例・避ける書き方付き）、ユーザーストーリーマップの5階層（`USM-01`〜`USM-05`、粒度の目安付き）、現状(Before)/将来(After)/テスト要求の3列定義と `extract_test_conditions` への引き渡し規約に加え、ステークホルダー2軸評価フレーム（影響力 `SW-INFLUENCE` ／関心度 `SW-INTEREST` の4段階定義、4段の分析ステップ `SWS-01`〜`SWS-04`、扱いクラス `SWC-01`〜`SWC-03`（重点／通常／参考）と4×4・全16組合せの対応表、`extract_test_conditions` への引き渡し規約）を含む。`generate_user_story_map` が利用する。

### Tool: `analyze_cause_effect`

仕様文（セクション単位）の論理関係を原因・結果・制約としてモデル化した入力を受け取り、そのモデルの整合性と「仕様文本文による裏付け」を決定的に検査する。モデル化そのもの（意味的層）は呼び出し側LLMに委ね、決定的層が (1) 未知ノード参照・ID重複・IDプレフィックス不一致・グラフの循環、(2) どの結果にも接続しない孤立原因、(3) どの原因からも導かれない結果、(4) 中間ノードの片側未接続、(5) 制約の指定不正（対象種別・要素数・重複）・制約の矛盾・制約による原因値の固定・冗長な制約、(6) 原因の真偽組合せ数（理論上限 2^n・制約充足後・圧縮後のデシジョンテーブル列数）、(7) 常に偽の結果／原因に依存しない結果、(8) 引用（`quote`）の仕様文実在照合と引用未指定、(9) どのノードにも紐づかない未モデル化仕様文の全件列挙とモデル化率、(10) 論理接続語（かつ／または／ただし／以外 等）のモデル未反映、(11) 宣言列数（`expectedRuleCount`）と算出列数の不一致、(12) 生成したデシジョンテーブル入力を `design_decision_table` の算出ロジックへ通した結果との突き合わせ、を検査する。制約は `exclusive` / `inclusive` / `onlyOne` / `requires` / `masks` の5種、辺は `identity` / `not`、中間ノードは `and` / `or` を指定できる。出力は mermaid の原因結果グラフ、圧縮後ルール表、および `design_decision_table` へそのまま渡せる引き渡しJSONを含む。原因数が上限（既定12件、`maxEnumerationCauses` で変更可）を超える場合やモデルに致命的な構造指摘がある場合は全列挙を行わず、制約充足後の列数・圧縮後の列数を推測値で出さずに「未算出（理由）」と明記する。判定区分と対処指針は `testbasis://cause-effect/analysis-criteria` を参照する。

### Resource: `testbasis://cause-effect/analysis-criteria`

原因結果グラフ分析の判定区分カタログ（自作パラフレーズ、`CEG-01`〜`CEG-20` の20区分。未知ノード参照・ID重複・プレフィックス不一致・孤立原因・導出されない結果・中間ノードの片側未接続・グラフの循環・制約の指定不正・制約の矛盾・原因値の固定・冗長な制約・常に偽の結果・原因に依存しない結果・仕様文に存在しない引用・引用未指定・未モデル化仕様文・論理接続語の未反映・曖昧語の残存・宣言列数と算出列数の不一致・デシジョンテーブル引き渡しの不整合）を、重大度・説明・対処指針付きの構造化データ（JSON）として公開する。`analyze_cause_effect` が判定表の生成に利用する。

### Tool: `generate_business_requirement_model`

業務側から見た「システム化の目的 → 業務ユースケース → 業務フロー → 駆動する情報」の4層モデルを、機能IDの章立てに従属せずに再構成する。決定的層（`BRC-01`〜`BRC-15`）は、目的/業務ユースケース/フロー工程/駆動データのID重複・欠番・プレフィックス不一致・未解決参照（由来目的ID・担い手ロールID・所属ユースケースID・駆動データID）、目的と業務ユースケースの相互紐づけ（孤立目的／目的未紐づけ業務ユースケース）、機能ID母集団との双方向照合（母集団のうち未参照の機能ID／母集団に無い機能IDの参照）、業務フローの工程0件の業務ユースケース・担い手未記入の工程、どの工程からも読み書きされない駆動データ・どの駆動データにも触れない業務ユースケース、`hasStates` 宣言と `states` 実体の一致、目的の達成判定指標・測定方法の未記入、例外時の業務運用（`BUC-06`）の未記入、宣言した機能ID被覆率（`claimedFeatureCoveragePercent`）と算出値の一致（母集団未宣言時は `featureCoverageBasis="unavailable"` として被覆率を算出せず、宣言値があれば裏付け不能として指摘）、業務ユースケース必須観点（`useCaseAspects` の `required:true`）の空欄を検査する。`businessUseCases` が未指定・空の場合は生成指示のみを返す。`design_scenario_flows` / `design_test_data` / `audit_cross_matrix` への引き渡し表（`BRH-01`〜`BRH-03`）と、テスト目的の導出フレーム（`BRH-04`、`available: false`。#85未実装のため自動接続は行わない）への申し送り、`testcondition://persona/journey-frame` との役割分担表を併せて出力する。

### Resource: `testcondition://business/requirement-frame`

業務ユースケース・要件モデル・フレーム（自作パラフレーズ）を構造化データ（JSON）として公開する。4層の定義（`BRL-01`〜`BRL-04`、システム化の目的・業務ユースケース・業務フロー・駆動する情報）、目的階層（`BPL-01`〜`BPL-03`、業務ゴール・システム化目的・達成判定指標）、業務ユースケース観点（`BUC-01`〜`BUC-06`、必須フラグ付き）、業務フロー観点（`BFL-01`〜`BFL-05`）、駆動データ観点（`BDA-01`〜`BDA-05`、推奨 `DataClassKind` 付き）、`testcondition://persona/journey-frame` との役割分担（業務フロー・役割/担い手・目標の3トピックについて、どちら側に正を書くかの規約）、下流ツールへの引き渡し規約（`BRH-01`〜`BRH-04`）を含む。`generate_business_requirement_model` が利用する。

### Tool: `select_regression_suite`

テスト条件・テストケースの母集団と、それに対する選択(include/exclude)判定・前バージョンスイート・削除理由から、リグレッションスイートとして何を残し何を落としたかを決定的に検査してMarkdownで返す。母集団外の選択判定参照・選択判定の重複矛盾・選択理由の未記入・高リスク項目(`riskScore >= highRiskMinScore` または `priority: "高"`)の非選択・選択/非選択未決定の母集団項目・変更差分区分(`RA-CHANGE`)の未宣言・影響を受けない(existing-unaffected)項目の選択・影響範囲条件の非選択/未決定・前バージョンから削除された項目の削除理由未記入とその逆(削除されていない項目への削除理由宣言)・前バージョンスイートの母集団外参照・ラージサイズ偏重・推定実行時間の予算超過・選択項目のサイズ判定入力欠落・影響範囲被覆率(`TTC-COV-18`)の宣言と算出値の不一致・選択基準IDの未宣言参照・選択条件に対応するケース欠落・選択基準の未宣言、を判定区分`RSC-01`〜`RSC-20`で決定的に検査する。加えて、`reexpand_threshold_changes` の「成果物別の影響判定」行を `computedImpactVerdicts` としてそのまま渡すと、影響判定実体(`ownerKind`/`ownerId`/`verdict`)と `changeCategory` 申告を照合し、影響ありと算出された条件が `existing-unaffected` と申告されている(`RSC-21`)・影響ありと算出されたケースが非選択になっている(`RSC-22`)・影響なしと算出された条件が過大申告されている(`RSC-23`)・影響判定入力が母集団外を参照または重複宣言されている(`RSC-24`)を検出したうえで、影響範囲被覆率の分母を申告と実体の和集合で補正する。`computedImpactVerdicts` を渡さない場合は被覆率を `basis: "declared-only"`（申告のみ）として算出し、実体照合していない旨を`RSC-25`で明示する。テストサイズ分類・リスクスコア算出は既存の共有純関数(`src/testSizeAnalysis.ts` / `src/testConditionAnalysis.ts`)を再利用する。閾値・パラメータ変更に伴う設計自体の再展開は `reexpand_threshold_changes` の担当であり対象外。技法カタログ `TTK-17`(regression-selection) をこのツールへ決定的にルーティングする。

### Resource: `testdesign://regression-selection/analysis-criteria`

リグレッションスイート選択の判定区分カタログ（自作パラフレーズ、`RSC-01`〜`RSC-25` の25区分。母集団外参照・選択判定の重複矛盾・理由未記入・高リスク項目の非選択・未決定項目・変更差分区分の未宣言・影響を受けない項目の選択・影響範囲条件の非選択/未決定・削除理由の未記入とその逆・前バージョンの母集団外参照・ラージ偏重・実行時間予算超過・サイズ判定入力欠落・影響範囲被覆率の宣言不一致・選択基準IDの未宣言参照・対応ケース欠落・選択基準の未宣言・前バージョン差分未算出・母集団件数上限超過に加え、影響判定実体との申告矛盾（影響あり→existing-unaffected申告）・影響ありと算出されたケースの非選択・影響なしと算出された条件の過大申告・影響判定入力の母集団外参照/重複宣言・影響判定実体の未連携）を、重大度・説明・対処指針付きの構造化データ（JSON）として公開する。`select_regression_suite` が利用する。

### Tool: `analyze_execution_order`

テストコンテナ(またはテストスイート／ケース群)の依存関係・所要時間・必要リソースから、実行順序(トポロジカルソート)・循環依存・クリティカルパス・リソース競合・依存未定義コンテナを決定的に検査してMarkdownで返す。Kahn法によるトポロジカルソートと実行順序・並列実行グループ(wave)の確定、循環依存の検出と代表閉路の提示(検出時は実行順序・スケジュール以降を未算出とする)、CPM(クリティカルパス法)によるES/EF/LS/LF・スラック・クリティカルパス・総所要時間の算出、最早開始スケジュール上の同一リソースの競合(`capacity`超過)・並列度上限(`maxParallelism`)超過の検出、依存関係(`dependsOn`)が未宣言のノードの全件列挙、依存根拠(成果物・リソース・データ項目)の宣言と実体の双方向照合、品質目標(SLO)・合格基準(`exitCriteria`)の測定可能性とSLO参照の双方向照合、モニタリングチェックポイント(`monitoringCheckpoints`)の宣言・範囲・指標接続の点検、`design_test_architecture` のコンテナ母集団(`architectureContainerIds`)との計画被覆率の算出と宣言値照合、クリティカルパス・総所要時間・計画被覆率の宣言値と算出値の照合を、判定区分`EOC-01`〜`EOC-27`で決定的に検査する。テストコンテナへの分割・責務定義は `design_test_architecture` の担当で本ツールは対象外。SUT内部の処理順序・タイミングのテスト(技法カタログ`TTK-10`)とは別概念であり、技法カタログの決定的カウント可否は変更しない。

### Resource: `testdesign://execution-order/analysis-criteria`

テスト実行順序・依存関係分析の判定区分カタログ（自作パラフレーズ、`EOC-01`〜`EOC-27` の27区分。ノードID重複・依存先の母集団外参照/自己依存・循環依存・依存関係の未宣言・依存根拠の未記入/実体不一致・依存の重複宣言・所要時間の未申告・必要リソースの未宣言/母集団外参照・リソース競合・並列度上限超過・宣言リソースの未使用・孤立ノード・クリティカルパス/総所要時間宣言の不一致・アーキテクチャ母集団の未計画コンテナ/母集団外ノード・合格基準の測定不能・SLO参照の実体不一致・モニタリング計画の未宣言/範囲外/指標未接続・計画被覆率の宣言不一致・ノード件数の上限超過・スケジュール未算出）を、重大度・説明・対処指針付きの構造化データ（JSON）として公開する。`analyze_execution_order` が利用する。

### Tool: `analyze_data_flow_timing`

システム構成要素間のデータフローとタイミング（送信周期・送信契機・伝送時間・ACK・タイムアウト・再送）から、同一データが末端へ到達するまでの**最大伝播遅延（遅延窓）**と、同一データが複数経路で伝播するときの**最大乖離時間（乖離窓）**を決定的に算出してMarkdownで返す。データ項目ごとの部分グラフ上で起点から各到達コンポーネントへの単純パスを全列挙し、辺ごとの最大遅延（送信待ち＝周期系は`intervalSeconds`／`event`は0、＋伝送時間＋タイムアウト×再送回数）と最小遅延（伝送時間）を合算して遅延窓を算出する。タイミングが未定義の通信（`kind:"undefined"`／周期系なのに`intervalSeconds`未指定／`event`なのに`trigger`未記入）は latency 不定として扱い、0秒で代替せずその辺を含む経路を「未算出」として区別する。宣言された伝播先（`propagationTargets`）の到達性照合、宣言値（最大伝播遅延・最大乖離時間・遅延窓被覆率）と算出値の照合、即時反映を期待するテスト条件と算出遅延の矛盾検出、ACK・タイムアウト・根拠位置の未宣言検出、同一データ項目を運ぶ周期系通信の周期不揃いの列挙、決定的な mermaid シーケンス図の生成、`extract_test_conditions` へのテスト条件候補（提案条件ID・条件文雛形・`source=testbase`・`derivedFrom`・`timing-order-test`・対応窓ID）の引き渡しを、判定区分`DFT-01`〜`DFT-20`で決定的に検査する。本ツールが扱うのは**SUT内部の構成要素間の通信タイミング**であり、**テスト作業そのものの実行順序**を扱う `analyze_execution_order` とは別概念である。技法カタログ`TTK-10`(timing-order-test) をこのツールへ決定的にルーティングする。

### Resource: `testdesign://data-flow-timing/analysis-criteria`

データフロー・タイミング分析の判定区分カタログ（自作パラフレーズ、`DFT-01`〜`DFT-20` の20区分。ID重複・母集団外参照・自己通信・タイミングの未定義・ACKの未定義・タイムアウト値の未宣言・伝播遅延の算出不能・最大伝播遅延の宣言不一致・宣言した終端の到達不能・遅延窓／乖離窓に対応するテスト条件の欠落・即時反映の期待と算出遅延の矛盾・運ばれないデータ項目・データ項目を運ばない通信・孤立した構成要素・根拠位置の未特定・周期の不揃い・最大乖離時間の宣言不一致・件数上限の超過／列挙の打ち切り・遅延窓被覆率の宣言不一致）を、重大度・説明・対処指針付きの構造化データ（JSON）として公開する。遅延の算出式・未定義辺の扱い・mermaid 矢印記法の対応も注記として含む。`analyze_data_flow_timing` が利用する。

### Tool: `derive_test_purposes`

テスト目的を「依頼者の期待 → テスト要求（マネジメント的／エンジニアリング的の2系統） → テスト戦略 → テスト目的 → 優先順位」という導出チェーンで整理させ、決定的層（`PDC-01`〜`PDC-17`）が連鎖の貫通性を双方向に検査する。未解決参照・ID重複/欠番/プレフィックス不一致・どのテスト要求からも参照されない依頼者の期待とその逆・どのテスト目的からも参照されないテスト要求とその逆・テスト要求の系統（マネジメント的／エンジニアリング的）の欠落・どのテスト目的にも紐づかないテスト条件とその逆（どのテスト条件からも参照されないテスト目的）・テストタイプ選択とテスト目的の不整合（選定なのに目的/理由が無い、非選定なのに目的がある）・どのテストタイプにも紐づかないテスト目的・達成判定基準（`successCriterion`）の未記入・優先順位の未設定/重複/根拠未記入・品質特性の未割当/未知ID（製品品質`QC-*`・利用時品質`QU-*`の両モデルを既知IDとして扱う）・依頼書本文に裏付けの無い期待（`requestDocuments` 指定時。IDも文言も本文に出現しないか、`sourceRef` の文書名/行番号が実在しない）・宣言した被覆率・記入率（テスト目的への紐づけ率／テストタイプ選定理由の記入率）と実測値の不一致を検出する。前者は`testConditions[].purposeIds`の宣言有無だけで算出する構造上の紐づけ率であり、後者は目的IDが1件以上あり選定理由(`reason`)が実質記入(定型語のみ・正規化後8文字未満を除く)である選定タイプの割合であって、いずれも内容の妥当性までは検査しない。理由が実質未記入の選定タイプはPDC-10で個別に指摘する。カタログ外のテストタイプ名を検出する。目的IDが `extract_test_conditions`（`testConditions[].purposeIds` / `testPurposes`）と `create_test_plan`（`testPurposes` / `testTypeSelections`）へ貫通しているかのマトリクス（4.1 目的×条件／4.2 目的×テストタイプ／4.3 目的×品質特性）を出力する。4.3 は関連する品質特性IDを製品品質（`QC-*`）・利用時品質（`QU-*`）・未知IDの3列に分けて示す。既存のテスト目的一覧を `purposes` に渡せば、既存成果物のレビューとしても同じ決定的検査を実行できる。

### Resource: `testplan://purpose/derivation-frame`

テスト目的の導出フレーム（自作パラフレーズ）を構造化データ（JSON）として公開する。導出段5段（`PDS-01`〜`PDS-05`：依頼者の期待の把握・テスト要求の整理・テスト戦略の適用・テスト目的の決定・目的/タイプの優先順位付け）、テスト要求の2系統（`PRL-01` マネジメント的／`PRL-02` エンジニアリング的）、テスト目的の質を点検する規則（`PQR-01`〜`PQR-05`）、優先順位付けの3軸（`PPA-01`〜`PPA-03`）、判定区分カタログ（`PDC-01`〜`PDC-17`）を含む。`derive_test_purposes` が利用する。

### Resource: `toolchain://next-tools/catalog`

全ツールの出力末尾に付く「次に実行すべきツール」節が参照する静的カタログを構造化データ（JSON）として公開する。実行元ツール名ごとの後続ツール候補（後続ツール名・提示理由・提示条件となるシグナルキー。`always` は常に提示）と、本MCPが登録する全ツール名の一覧（`registeredToolNames`）、各ツールの出力見出し署名テーブル（`toolOutputSignatures`）を含む。各ツールは自身の後続表と生成物の内容から機械的に導いたシグナルを突き合わせ、未実施の後続ツールを列挙する。呼び出し側は `completedTools`（`toolName` と証跡 `evidence`、実出力の抜粋 `outputExcerpt`）で実施済みを申告できるが、証跡が参照形式（ファイルパスまたは `#` から始まる見出し）でない申告・`registeredToolNames` に無いツール名の申告は実施済みと認めず、警告付きで未実施のまま残す。証跡が参照形式であっても、`outputExcerpt` に当該ツール自身の出力見出し（`toolOutputSignatures`）が実在しない申告は「実施済み(証跡未照合)」として未実施件数に含める。

## テストベースの投入（バイナリ形式のテキスト化）

MCPツールはフォーマット不問の自由テキストを受け取るため、Word / Excel / PDF は呼び出し側でテキスト化して投入する。
何を保ち何を落とすかの規約と参照実装は [docs/ai/testbase-ingestion.md](./docs/ai/testbase-ingestion.md) を参照。

```bash
bash scripts/extract-testbase-text.sh 2025            # PDF（pdftotext -layout 固定）
node scripts/extract-testbase-xlsx.mjs <in.xlsx> --out <out.txt>   # Excel（図形内テキストを独立セクションで出力）
node scripts/extract-testbase-docx.mjs <in.docx> --out <out.txt>   # Word（目次・削除履歴を除去し見出しを # へ）
```

## コマンド

```bash
npm run dev       # tsc --watch
npm start         # node dist/server.js（stdio transport）
npm test          # vitest run
npm run inspect   # build後、MCP Inspectorを起動して動作確認
```

## 動作確認（CLI）

```bash
npx @modelcontextprotocol/inspector --cli node dist/server.js --method resources/list
npx @modelcontextprotocol/inspector --cli node dist/server.js --method tools/list
npx @modelcontextprotocol/inspector --cli node dist/server.js --method prompts/list
npx @modelcontextprotocol/inspector --cli node dist/server.js --method tools/call \
  --tool-name create_test_plan \
  --tool-arg projectName="ECサイト" \
  --tool-arg scope="決済とログイン機能"
npx @modelcontextprotocol/inspector --cli node dist/server.js --method prompts/get \
  --prompt-name test_plan_interview --prompt-args projectName="ECサイト"
```

## 実クライアントへの登録例（Claude Desktop / Claude Code）

```json
{
  "mcpServers": {
    "ai-test-process-mcp": {
      "command": "node",
      "args": ["<repo-path>/dist/server.js"]
    }
  }
}
```

npm公開後は、リポジトリをローカルにcloneしなくても `npx` 経由で起動できる（`.vscode/mcp.json` の例）。

```json
{
  "servers": {
    "ai-test-process-mcp": {
      "command": "npx",
      "args": ["-y", "ai-test-process-mcp"]
    }
  }
}
```

## 公開手順（メンテナ向け）

1. `npm login`（npmjs.comのアカウントで認証）
2. `npm run build`（`npm publish` 実行時は `prepublishOnly` フックにより自動実行されるため、手動実行は任意）
3. `npm publish`

公開後の接続方式（stdio）は変わらない。MCPレジストリ（`server.json` / `mcp-publisher`）への登録は本手順の対象外で、将来の別タスクとして扱う。

## 将来機能の追加方法

新しい機能（Test Analysis・Test Design ほか Generic Test Process 各工程の tool）を追加する際は、以下のパターンに従う：

1. `src/resources/<name>.ts` — 必要な参照データ（構造化データ）を定義
2. `src/tools/<name>.ts` — zod入力スキーマ + 純粋なレンダリング関数 + `registerXxxTool()`
3. `src/resources/index.ts` / `src/tools/index.ts` にそれぞれ1行登録を追加
4. `test/<name>.test.ts` でレンダリング関数を単体テスト

`server.ts` 本体は変更不要。プラグインローダーやレジストリのような抽象化は、モジュール数が増えて明示的な登録リストが煩雑になるまで導入しない。

詳細は [AGENTS.md](./AGENTS.md) と [docs/ai/project-overview.md](./docs/ai/project-overview.md) を参照。