AI Test Process MCP

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

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

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

提供する機能

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: :P 形式の網羅対象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: : 、各シナリオは SC: :S 形式の網羅対象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: : 、各遷移は DL:T: : 形式の網羅対象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_requ