ai-test-process-mcp

ai-test-process-mcp

使用 AI 支持 JSTQB/ISTQB 通用测试流程的 MCP 服务。

本项目并非用于操作测试管理工具，而是旨在使用 AI 支持通用测试流程各阶段（Test Planning 至 Test Completion）中测试工作产品的创建、评审和分析。文档结构基于符合 JSTQB 标准的 15 章模板。

当前范围（Phase 1〜3：Test Planning + Test Analysis + Test Design）：包括生成测试计划（符合 JSTQB 标准的 15 章结构）日文草稿、从 JSTQB 视角进行评审和修订支持、以提问形式收集上下文的指南、需求分析与测试条件提取、边界值分析、等价类划分、通过生成测试用例实现的测试设计技术，以及探索性测试的章程设计等基于经验的技术。 未来规划：经过 Test Analysis（需求分析与测试条件提取）、Test Design（生成测试用例与评审测试规格说明书），逐步扩展至通用测试流程全部 7 个阶段。详情请参阅 docs/roadmap.md。

安装（面向使用者）

已发布到 npm，无需构建即可立即使用。在 Claude Desktop / Claude Code 的配置中添加以下内容（需要 Node.js 18 或更高版本）。

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

添加 @latest 后，发布新版本时会自动生效，无需手动清除缓存。

设置（面向开发者）

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

提供的功能

工具：create_test_plan

输入项目信息（projectName、scope 为必填项；objectives、risks、scheduleConstraints、team、testItems、stakeholders、glossary 等还有许多可选项），即可生成符合 JSTQB 标准的 15 章结构的日文 Markdown 格式测试计划草稿。未填写的项目会明确标示为 _未填写_（必填项为 _未填写（必填）_）。测试类型说明、事件等级等固定参考信息始终会输出。

工具：review_test_plan

输入测试计划的 Markdown 正文后，会返回从 JSTQB 视角出发的评审报告。分为两层：(1) 结构检查（确定性地检测 15 章中缺失的章节和未填写的必填项）；(2) 语义评审检查清单（以指令形式引导调用方的 LLM 判断内容是否合理）。

工具：revise_test_plan

输入现有测试计划的 Markdown 和修订指示（instructions，可选字符串数组）后，会返回修订结果报告。分为两层：(1) 应用机械修订（自动补齐缺失章节，将 TBD/TODO/未定 等未填写占位符规范化为 _未填写_）后的测试计划；(2) 引导调用方 LLM 改写内容的项目列表，包括用户指定的修订指示，以及修订后仍未填写的必填项清单。

提示词：test_plan_interview

用于通过提问收集测试计划上下文的指南。主要围绕模板中的必填项，依次向用户提问并收集回答，引导助手调用 create_test_plan。可接收可选参数 projectName。

工具：design_boundary_values

根据变量的有效范围（下限、上限、步长、类型），确定性地枚举 2 值/3 值边界值，并以 Markdown 表格返回，同时标注有效/无效判定。

工具：design_equivalence_partitioning

根据每个变量的有效/无效等价类，确定性地生成基于代表值的测试用例，并以 Markdown 表格返回，同时检查是否覆盖所有等价类。

工具：design_decision_table

根据条件项（原因）及其可能取值、无效组合（不可能出现的组合及原因）和规则（条件选择器 → 动作），执行全组合的确定性枚举 → 排除无效组合 → 合并动作列相同的列（推导 don't care），并以 Markdown 返回条件组合覆盖情况、未定义动作的组合（DTC-06）、动作不一致的矛盾（DTC-07）、压缩前后的列数和削减率。压缩后的每条规则会以 DT: 前缀的覆盖目标 ID 输出，可直接传入 generate_test_cases 的 decisionTable。也可直接输入 analyze_cause_effect 的“传递至决策表”输出（DecisionTableSpec 格式，包含取值为 ["T","F"] 的条件项与动作项、由约束产生的无效组合，以及压缩后的规则）。

工具：design_pairwise

输入因子（factors[]：id / name / levels）、禁则（forbiddenCombinations[]：不可能出现的组合及原因）和必须包含的已知重要组合（seedRows[]）后，会按规范顺序枚举所有水准对 → 判定因禁则而无法覆盖的水准对 → 通过确定性的贪心算法生成覆盖各水准对的组合，并以 Markdown 返回 8 个部分：因子与水准表、禁则表、可达性表、生成的组合表、各行新增覆盖的水准对、确定性检查、覆盖目标清单和摘要。由于不使用随机数或当前时间，相同输入始终会得到相同的组合表。生成的每个水准对会以 PW:<setId>:P<n> 格式的覆盖目标 ID 输出；传入 generate_test_cases 的 pairwise 后，即可确定性地统计水准对覆盖率。会明确说明，水准对覆盖率的分母为“水准对总数 − 因禁则而无法覆盖的水准对数 − 因搜索上限而暂缓判定的水准对数”，而非水准对总数。削减率的分母在可严格枚举所有组合时为“应用禁则后有效组合数”；超过枚举上限（maxEnumerationCombinations，默认为 4096）时则为“应用禁则前的全组合数”，并会在输出中注明采用了哪一种。如果全组合数超过安全整数范围，不会以估算值输出削减率，而会明确标示为“未计算（原因）”。如果水准对总数超过上限（maxPairCount，默认为 5000），或输入中存在致命问题，则不会生成组合，只返回可计算的计数。可直接输入来自 testcondition://factor/ralph-frame 的因子表（FHO-04）中的因子与水准。判定类别及处理指南请参阅 testdesign://pairwise/analysis-criteria。

资源：testdesign://pairwise/analysis-criteria

以结构化数据（JSON）形式公开 design_pairwise 的判定类别目录（PWC-01〜PWC-12，自创释义）。各类别包括未声明因子 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 を参照する。

Prompt: scenario_flow_interview

質問形式でシナリオフロー設計のコンテキストを収集するためのガイド。アクター・ユースケースと主アクター・事前条件/事後条件・主フロー（ステップ番号順）・代替フロー/例外フロー・分岐の起点/契機/復帰先・分岐の帰結（目的達成／中断）・機能ID母集団を確認し、design_scenario_flows を呼び出すようアシスタントを誘導する。任意引数 subjectName を受け取る。

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 を参照する。

Prompt: test_architecture_interview

質問形式でテストアーキテクチャ設計のコンテキストを収集するためのガイド。テストスコープ・コンテナ分解軸・テストコンテナの定義（ID/名称/親子/責務）・テストレベルとテストタイプ・実行必要性の優先度クラス・担当観点カテゴリ・環境と開始/終了条件・テスト条件のコンテナ帰属を確認し、design_test_architecture を呼び出すようアシスタントを誘導する。任意引数 subjectName を受け取る。

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への指示として出力される。既定（verbose 未指定/false）では呼び出し元LLMのcontextに載る規模に収めるため、ID重複・未解決参照の一覧（2.1節）・根拠位置（2.6節）・指摘表（3章、severity降順）に件数上限を適用し、打ち切った箇所には必ず全件数・省略件数・verbose: true で全件取得できる旨を明示する。全件が必要な場合は verbose: true を指定する。文書全文を受け取るツール（analyze_requirements / review_test_basis / audit_id_population / review_test_specification）は、投入されたテキストの規模と検出量（文字数・行数・見出し数・検出ID数・数値トークン数）を「入力ダイジェスト」表として先頭に出力し、検出IDが0件の文書やプレフィックスの検出が極端に少ない文書を抜粋投入の疑いとして [medium] で指摘する。見出しラベルが文書全体で1種類しかない大きな文書（Wordの新旧対照表のようにID体系も # 見出しも取れない実務文書）では、指摘の章節をパイプ表の行・列アンカー（表見出し行の要約＋データ行番号＋列＋行番号）で解決し、代替アンカーを使った事実とその解決方式を入力ダイジェストの [info] 指摘および注記行として明示する。見出しもパイプ表も無い箇所は (見出しなし) のまま残す。

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 は不満点のフォールバックとして引き続き有効）。

Prompt: test_condition_interview

質問形式でテスト条件抽出のコンテキストを収集するためのガイド。要件ID母集団・テスト条件の本体（条件ID/対象/条件文）・導出系統（testbase/stakeholder/risk/guideword）・導出元ID・観点カテゴリ・優先度と判定基準・リスク3軸・ペルソナ/リスク一覧・テストベース内の出典位置を確認し、extract_test_conditions を呼び出すようアシスタントを誘導する。要件ID母集団を先に固めるよう促し、母集団を縮めると未カバー0件が見かけの値になることを明示する。任意引数 subjectName を受け取る。

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

以结构化数据（JSON）公开测试技术目录（自行改写，包含边界值分析、等价类划分、决策表、状态迁移、成对测试、用例/场景、CRUD/数据生命周期、竞争/时序、探索性测试/错误推测/基于检查表的测试，共 13 种技术），以及根据测试依据特征选择技术的决策表（10 行）。generate_test_cases / generate_exploratory_charters 使用该目录推荐技术并显示覆盖准则。

Resource: testsize://classification-criteria

以结构化数据（JSON）公开测试规模分类准则（自行整理，参考 Google Test Sizes 的理念并独立改写）。定义 8 项外部依赖判定轴（访问外部主机网络、持久化数据存储、文件系统、启动其他进程、并发执行、实际设备/外围设备、屏幕操作、实时等待），以及小型/中型/大型 3 种规模（执行时间上限为 60/300/1800 秒、允许的判定轴、适当的测试级别、推荐占比）。generate_test_cases 使用该准则检查测试级别分配是否合理。并不声称符合外部准则。

Tool: review_test_specification

以“测试规格说明是否足以覆盖测试依据”为评估标准，接收一组测试依据文档、测试规格说明正文（格式不限），以及可选的 testCases / testConditions / risks 作为输入。针对需求 ID、测试条件 ID、风险 ID 这 3 类 ID 建立双向覆盖关系（forward：未覆盖 ID；reverse：依据不明或疑似过度测试项），并以确定性方式检查 ID 表记是否一致（EH100 和 EH-100 等表记差异）、用例 ID 是否重复、预期结果是否为空、是否指定优先级及是否声明判定准则、前置条件中的占位符、步骤数与预期结果数是否平衡、主观用语、预期结果引用的措辞/ID 是否存在于测试依据中、是否声明覆盖准则。同时返回用于语义审查的检查清单（14 项）和改进建议。未指定 testCases 时，仅返回基于 ID 提取的简易检查结果。

Prompt: test_specification_review_interview

用于通过提问收集测试规格说明审查上下文的指南。确认一组测试依据文档、待审查的测试规格说明正文、结构化测试用例、需求 ID 总体集合、测试条件列表、风险列表、ID 表记规则，以及额外的模糊词/主观词，并引导助手调用 review_test_specification。未指定 testCases 时，只能得到基于 ID 提取的简易检查结果，因此必须确认是否可以准备结构化测试用例。接收可选参数 subjectName。

Resource: testspec://review/checklist

以结构化数据（JSON）公开测试规格说明审查用的语义检查清单，包含 14 项：覆盖完整性、可追溯性、预期结果一致性、技术适用性、可执行性、可观测性、可复现性、独立性、数据准备可行性、环境指定、对变更差异的加权、可复用性、术语一致性、技术选择依据；并附有改进行动和术语表的交叉引用。

Tool: generate_exploratory_charters

生成探索性测试（包括错误推测、基于检查表的测试等经验型技术）的测试章程表。采用两层结构：(1) 确定性层基于关注点类别目录，以确定性方式检查章程 ID 是否重复/缺号/前缀不一致、是否包含未知的关注点类别 ID、来源元数据（derivedFrom）是否引用未解析、关注点类别是否未使用、高优先级测试条件/风险是否未覆盖、时间盒和时间预算是否超限，以及任务说明中是否包含主观用语。(2) 语义层仅返回针对调用方大模型的指示，要求用文字说明任务说明（要确认什么，以及如何施加扰动）。未指定 charters 或其为空时，输出内容将仅包含“生成指示”。将现有章程表传入 charters，也可用于审查现有成果。传入可选参数 deterministicallyCoveredConditionIds（已通过边界值分析、等价类划分等确定性技术转换为测试用例的测试条件 ID）后，将根据探索性测试用于补充确定性技术的定位，在检查高优先级测试条件是否未覆盖时排除这些条件。

Prompt: exploratory_charter_interview

用于通过提问收集探索性测试章程设计上下文的指南。确认目标领域、测试条件、现有测试用例覆盖薄弱之处、过往故障/经验心得、关注点类别、会话时间预算、执行者/技能、记录方法和停止条件，并引导助手调用 generate_exploratory_charters。接收可选参数 subjectName。

Resource: testdesign://exploratory/charters

以结构化数据（JSON）公开探索性测试章程目录（自行改写，包含功能横向、状态/中断、数据一致性、运维/异常、环境/配置、时间边界 6 种关注点类别），并附有确认关注点、操作关注点、相关关注点类别、推荐时间盒、停止参考标准，以及章程表的固定列结构。generate_exploratory_charters 使用该目录确定关注点类别和章程表的列结构。

Tool: audit_id_population

用于解决 extract_test_conditions 等工具的“未覆盖 0 项／覆盖率 100%”仅对作为输入声明的总体集合有效这一问题。将从一组测试依据文档（documents）中提取的所有已定义 ID，与实际传递给各工具调用的总体集合（declaredPopulations）进行比对，以确定性方式检测从未传入任何总体集合的 ID（未声明 ID）、声明排除的 ID、仅存在于总体集合中而测试依据未定义的 ID、各文档的总体反映率、未纳入的文档（expectedDocumentNames），以及总体集合之间的差异（流程间的缩减）。用于验证覆盖率 100% 是否只是总体集合缩减所造成的表面结果（仅重复使用部分 ID 的状态）。默认（includeCoverageTargetIds: true）也会将 design_* 系列工具发出的冒号分隔覆盖目标 ID（BV: EP: ST: DT: PW: SC: UC: DL: CFG:）纳入 ID 索引，因此不仅能检测需求 ID，也能检测覆盖目标 ID 的失效引用和未声明情况。判定类别和处理指南请参阅 testbasis://population/audit-criteria。

Prompt: id_population_audit_interview

用于通过提问收集 ID 总体审计上下文的指南。确认待审计的测试依据文档、预期需要审计的文档列表、实际传入各工具调用的总体集合、同一工具多次调用的识别标签、有意排除的 ID 及其理由，以及 ID 表记模式，并引导助手调用 audit_id_population。要求询问实际传入的总体集合，而非理想值。接收可选参数 subjectName。

Resource: testbasis://population/audit-criteria

以结构化数据（JSON）公开 ID 总体审计判定类别目录（自行改写，包含未声明 ID、声明排除的 ID、测试依据未定义的 ID、未纳入的文档、流程间的总体集合缩减、文档级反映率下降，共 6 类），并附有严重程度、说明和处理指南。audit_id_population 使用该目录生成判定表。

工具：audit_cross_matrix

接收任意两个或更多轴作为通用轴数据（axes）（例如产品风险／测试观点类别／角色／功能 ID／场景／测试容器／参数／测试类型等），确定性地生成轴对的笛卡尔积表，并列出空行、空列（仅存在于一侧的元素）。传入三个或更多轴时，会在一次调用中批量报告所有轴组合对（省略 axisPairs 时，按声明顺序取所有 i<j 组合）。关联关系（items[].links）按无向关系处理，只要声明了 a→b 或 b→a 中任意一个，单元格就视为已填充；仅单向声明的情况会单独报告。计算填充率时会明确列出分母（行数 × 列数）；行覆盖率和列覆盖率的分母则是排除通过排除声明（exclusions）排除的元素后，剩余的目标元素数。此外，还会核对 declaredCoverage 中声明的填充率与实测值，利用 expectedAxisPopulations 检测轴母集缩减，并与 documents 正文进行双向佐证核对（轴元素在正文中没有佐证／正文中有定义但未列入任何轴的 ID），因此能够检测因缩减母集而产生的虚高填充率。在与 documents 核对时，默认（includeCoverageTargetIds: true）也会将 design_* 系列工具发布的、以冒号分隔的覆盖目标 ID（BV: EP: ST: DT: PW: SC: UC: DL: CFG:）纳入目标范围。判定类别和处理指南请参阅 testdesign://cross-matrix/audit-criteria。

资源：testdesign://cross-matrix/audit-criteria

多轴矩阵审计判定类别目录（自行改述，共 17 个类别，CMX-01 至 CMX-17：关联到未声明的 ID；轴 ID／元素 ID 重复；空行；空列；关联到自身轴内的元素；仅单向关联；未填写排除理由；声明的填充率与实测值不一致；轴母集缩减；轴元素在测试依据正文中没有佐证；测试依据中有定义但未列入轴的 ID；对笛卡尔积没有贡献的轴；单元格数量超出上限；引用未声明的轴 ID／指定相同的轴对；完全孤立的元素；未填写关联依据；关联依据在正文中没有佐证），以包含严重度、说明和处理指南的结构化数据（JSON）形式公开。audit_cross_matrix 使用此目录生成判定表。

工具：audit_test_design_notations

通过核对声明与实际内容，确定性地检查 ASTER OPEN 课程参与指南在成果物 2 示例中官方列出的 3 种表示法（FV 表、NGT、Yumotsuyo 矩阵）。FV 表（fvTable，功能×验证内容列表）会检查 ID 重复、编号缺失、未填写验证内容或仅填写模板用语导致实质上未填写、与功能母集（expectedFunctionIds）进行双向核对，以及声明的功能覆盖率是否与实测值一致。NGT（ngt，测试观点的层级结构）会检查节点 ID 重复、父子关系循环、根节点为 0 个／2 个或更多、无法落实为测试条件的叶节点、缩减分支或粒度不一致、叶节点深度的偏差、与 testcondition://perspectives/catalog 中的观点类别 ID 进行双向核对，以及声明的叶节点数量是否与实测值一致。Yumotsuyo 矩阵（yumotsuyoMatrix，测试类型×测试观点矩阵）会检查行列 ID 重复、未声明排除的空单元格、空行／空列、未填写排除理由、与测试条件母集进行双向核对，以及声明的填充率是否与实测值一致。此外，还会在一次调用中检测跨表示法的一致性问题，例如通过 FV 表的 ngtNodeId／Yumotsuyo 矩阵行列的 ngtNodeId 与 NGT 交叉引用，以及 3 种表示法引用的测试条件 ID 集合与输入的 testConditionIds 母集之间的差异。覆盖率／填充率声明（claimedFunctionCoveragePercent / claimedLeafCount / claimedFillRatePercent）会明确列出分母并与实测值核对；未声明母集时不会计算，而会指出“无法佐证”。未提供某种表示法时，不会执行检查，只返回生成指示。判定类别和处理指南请参阅 testdesign://notation/catalog。

资源：testdesign://notation/catalog

关于 ASTER 参与指南中作为示例列出的 FV 表、NGT、Yumotsuyo 矩阵这 3 种表示法，公开其用途、必备要素、与现有 resource/tool 的对应关系、出处等信息的结构化数据（JSON，自行改述）。同时，还会公开 audit_test_design_notations 使用的判定类别目录（TDN-01 至 TDN-25，共 25 个类别），并附上严重度、说明和处理指南。

工具：audit_deliverable_consistency

对照跨越多个流程阶段的多个成果物（deliverables，至少 2 项），例如测试计划书、测试分析书和测试设计书，并确定性地检测成果物之间的不一致。检查分为 4 类：（1）对照引用的测试依据文档列表（以两位数文档编号为键，将已读／未读状态展开为按成果物区分的矩阵，检测成果物之间已读状态不一致、同一成果物内自相矛盾，以及只出现在一侧的文档。传入 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 索引默认（includeCoverageTargetIds: true）也包含 design_* 系列工具发布的、以冒号分隔的覆盖目标 ID（BV: EP: ST: DT: PW: SC: UC: DL: CFG:），因此也能检测这些 ID 在成果物之间的失效引用，以及后续流程阶段的遗漏。判定类别和处理指南请参阅 testdesign://deliverable/consistency-criteria。

资源：testdesign://deliverable/consistency-criteria

成果物间一致性审计判定类别目录（自行改述，共 17 个类别，DCC-01 至 DCC-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 が利用する。

Prompt: threshold_change_interview

質問形式で閾値変更影響の再展開のコンテキストを収集するためのガイド。変更前/変更後の閾値パラメータ表（名前・値・単位・出典）・変更前後の仕様書本文・抽出候補の承認・既存のテスト条件/テストケース・境界値変数および同値クラスとパラメータの束縛を確認し、reexpand_threshold_changes を呼び出すようアシスタントを誘導する。未承認の抽出候補で有効なパラメータ表を書き換えないことを明示する。任意引数 subjectName を受け取る。

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) をこのツールへ決定的にルーティングする。

Prompt: data_flow_timing_interview

質問形式でデータフロー・タイミング分析のコンテキストを収集するためのガイド。構成要素（機器/サービス/クラウド/ストア/人）・論理データ項目・通信経路（送信元/宛先/運ぶデータ項目）・送信タイミング（種別/周期/契機）・遅延/ACK/タイムアウト/リトライ・伝播の起点と終端・主張する最大スキュー・遅延窓被覆率の宣言を確認し、analyze_data_flow_timing を呼び出すようアシスタントを誘導する。任意引数 subjectName を受け取る。

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）が実在しない申告は「実施済み(証跡未照合)」として未実施件数に含める。

Resource: testbasis://coverage/inspectability

原文入力口を持つ11ツール（review_test_basis / analyze_requirements / review_test_specification / generate_test_cases / audit_id_population / audit_basis_contradictions / audit_cross_matrix / audit_test_design_notations / audit_coverage_balance / audit_deliverable_consistency / reexpand_threshold_changes）の出力末尾に付く「検査実行状況(実行された検査 / 検査不能な検査)」節が参照する静的カタログを構造化データ（JSON）として公開する。決定的検査が成立するための入力上の前提（前提ID・日本語名・実測方法・算出元の入力・不成立を解消する入力上の手当て）、入力ダイジェスト由来の共通検査（IQC-01〜IQC-05）、ツールごとの原文依存な決定的検査（既存判定区分ID・出力節ラベル・必要な前提ID）を含む。新規の判定区分ID体系は作らず、既存カタログの区分ID（PAC-* / BC-* / CMX-* / TDN-* / CBC-* / DCC-* / TCE-* / IQC-*）をそのまま参照する。

各ツールはこのカタログと、投入された原文から算出した前提の実測値（定義ID件数・表セル件数・章節アンカー解決可否など）を突き合わせ、各検査を「実行」か「検査不能」かに分けて実測値付きで列挙する。指摘0件が「入力が合格した」のか「検査そのものが成立していない」のかを呼び出し側が判別できるようにするための節であり、検査可能率などの百分率は出さない（達成度の主張ではないため）。

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

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

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（目次・削除履歴を除去し見出しを # へ）

コマンド

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

動作確認（CLI）

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）

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

npm公開後は、リポジトリをローカルにcloneしなくても npx 経由で起動できる（.vscode/mcp.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 と docs/ai/project-overview.md を参照。