k11 Release Gate

k11 リリースゲート — MCP サーバーと CI ゲート

すべての QA エビデンスから、読みやすいポリシーに基づいて一つのリリース判断を下し、監査証跡を残します。

チームにはすでにエビデンスがあります。UI テストの実行結果、API チェック、セキュリティスキャン、JUnit ファイルなどです。不足しているのは「リリースしてよいか」という一貫した判断です。現在、その判断は、期限に追われながら一人の担当者が複数のダッシュボードを確認して下しています。k11 Release Gate はエビデンスを読み取り、記述されたポリシーを適用して、判断の理由とその根拠となったファイルを添えた一つの判定を返します。

判定	意味
🟢 リリース可	ポリシーに抵触するものはありません
🟡 条件付きでリリース可	リリースできますが、誰かが何らかの対応を行う必要があります（例：ロケーター修復の PR を承認する）
🟠 人による判断が必要	指定された承認者のサインオフがある場合に限りリリースできます。リスクに応じたヒューマン・イン・ザ・ループです
🔴 ブロック	リリースしないでください。すべてのブロッカーとそのエビデンスを示します

決定論的です。 同じエビデンスと同じポリシーであれば、常に同じ判定になります。判定に LLM は使われないため、監査にも対応できます。各エビデンスファイルの SHA-256、タイムスタンプ、経過時間に加え、ポリシー自体のハッシュと git コミットも記録されます。

読み取るエビデンス

エビデンスの種類は、ファイルの内容から認識されます。

エビデンス	生成元
セルフヒーリング機能付き UI テスト（heal-report.json）	k11 Playwright QA または k11 Selenium QA の heal-ci
API コントラクト（contract-report.json）	k11 API Contract QA の contract-ci
API 機能テスト（api-test-report.json）	k11 API Functional QA の run
LLM レッドチームテスト（assessment.json）	LLM Assure
任意の JUnit XML	pytest、Maven Surefire、Gradle、Jest、Playwright など

この変更で必要なチェックは？

k11-release-gate-mcp plan --base origin/main

ゲートはブランチと --base を比較し、ポリシーの triggers（適切なデフォルト値が含まれています）を使って、変更されたファイルをエビデンスの種類に対応付けます。openapi.yaml の変更にはコントラクトと API のエビデンスが必要です。.tsx／.css／テンプレートには UI のエビデンスが必要です。prompts/** には LLM レッドチームテストが必要です。evaluate --base origin/main は、これらの種類のエビデンスを必須とします。そのため、CSS だけの変更でレッドチームテストが原因で遅れることはなく、API の変更はコントラクトチェックなしではリリースできません。この計画は判定記録に保存されるため、「なぜこのチェックが必要だったのか」という疑問には常に答えられます。

triggers:                     # override the defaults per kind
  llm: ["src/assistant/**", "prompts/**"]
  contract: ["api/openapi.yaml"]

エビデンスがない場合、決して合格として扱われません。必須の種類のエビデンスがない場合、デフォルトでブロックされ、エビデンスのない任意の種類は未テストとして一覧表示されます。

判断の様子を見る

demo/ には、5 つの K11 ツールを各自のデモに対して実際に実行した結果を証拠とする、2 つのリリース候補が含まれています。

rc1 → 🔴 ブロック。 ソースまで追跡できるブロッカーが 7 件あります。

• ロケーター以外の理由で UI テストが 1 件失敗（ui.real_failures）：ページタイトルが変更されました
• 壊れたロケーターが 2 件未解決（ui.unresolved_locators）：「Edit profile」はレビューが必要です。cart-btn の修正は元に戻されました
• API の変更により billing-svc、checkout-web、notification-svc が影響を受けます（contract.breaks_critical_consumer）：billing-svc は重要なコンシューマーで、担当者は @team-billing です
• API フローが 2 件失敗（api.flow_failed）：「注文合計は数量と価格の積」、POST /orders の異常系テスト
• API テストでサーバーエラー（5xx）が 2 件（api.server_error）：型が誤っている／items[0].qty がありません
• 重大な LLM の検出結果が 6 件、高深刻度の検出結果が 13 件（llm.critical、llm.high）：未検証の返金、他の顧客のレコード、間接的なプロンプトインジェクション、…

担当者の対応が必要です：コントラクトチェックでエスカレーションされました（3 件のコンシューマーに影響します）。条件：修正された view-orders ロケーターを承認すること。未使用の破壊的変更 3 件について、コンシューマーの一覧を確認すること。

rc2（修正後）→ 🟠 担当者の承認が必要：

リリース前に @qa-lead、@ai-safety-lead の承認が必要です。

• 担当者の対応が必要です：LLM プローブ 1 件の結果が不確定（llm.inconclusive）
• 条件：ロケーター 1 件を修正して検証済み：修正 PR を承認してください

すべてに合格していますが、セキュリティプローブの 1 件は自動判定できなかったため、ポリシーにより指定された担当者が確認する必要があります。黙って通過させることも、リリースを完全にブロックすることもありません。

QA_MCP_ROOT=demo/rc1 k11-release-gate-mcp evaluate --label rc1
QA_MCP_ROOT=demo/rc2 k11-release-gate-mcp evaluate --label rc2

ポリシー：.qa-mcp/release-policy.yaml

name: Order platform release policy
evidence:                                   # where each tool writes its report (globs inside the project)
  api_tests: [".qa-mcp/api-test-report/api-test-report.json"]
  junit: ["test-results/**/*.xml"]
required: [api_tests, contract, ui_heal, llm]
max_age_hours: 24                           # older evidence → evidence.stale
critical_consumers: [critical, high]        # their breakage blocks
approvers: ["@qa-lead", "@ai-safety-lead"]  # named on a needs_human verdict
rules:                                      # override any rule: block | needs_human | conditional | info | off
  llm.medium: needs_human
  ui.healed: info

k11-release-gate-mcp init はコメント付きのポリシーのひな形を書き込みます。k11-release-gate-mcp rules はすべてのルールを一覧表示します。

ルール

ルール	デフォルト	発動条件
evidence.missing	ブロック	必須の種類の証拠がない場合
evidence.unreadable	担当者の対応が必要	証拠ファイルを解析できない場合
evidence.stale	条件	証拠が max_age_hours より古い場合
api.server_error	ブロック	機能テスト中に API が 5xx を返した場合
api.flow_failed	ブロック	API フローが失敗した場合
api.flow_not_run	担当者の対応が必要	フローがガードレールによってブロックされたか、エラーが発生し、何も証明できなかった場合
contract.breaks_critical_consumer	ブロック	API の変更が critical_consumers のコンシューマーに影響する場合
contract.breaks_consumer	担当者の対応が必要	別のコンシューマーに影響する場合
contract.escalation	担当者の対応が必要	コントラクトチェックで担当者の対応が求められた場合
contract.breaking_unused	条件	既知のコンシューマーがない破壊的変更がある場合
ui.real_failures	ブロック	ロケーター以外の理由で UI テストが失敗した場合
ui.unresolved_locators	ブロック	壊れたロケーターが元に戻された、レビューが必要、または見つからなかった場合
ui.healed	条件	ロケーターを修正して検証済みの場合。修正 PR を承認してください
ui.suggested	条件	ドライランで修正が提案された場合
llm.critical、llm.high	ブロック	該当する深刻度の LLM セキュリティ検出結果がある場合
llm.medium	条件	中程度の検出結果がある場合
llm.inconclusive	担当者の対応が必要	レビューが必要、またはエラーが発生したプローブ
llm.low	注記	低深刻度の検出結果
junit.failures	ブロック	いずれかの JUnit ファイルに失敗またはエラーがある場合
junit.skipped	注記	スキップされたテストがある場合

ツール

ツール	機能
evaluate_release	判定、根拠を含むすべての指摘、テストされなかった内容を提示します。base_ref を指定した場合は、変更によって必要となる根拠も提示します。release-decision.md / .json を書き出します。
plan_checks	git の参照以降に変更されたファイルとポリシーのトリガーに基づいて、この変更に必要な根拠を提示します。
collect_evidence	存在する根拠の種類、ファイル、経過時間、SHA-256、主要な数値、必須の種類のうち不足しているものを提示します。
list_rules	すべてのルールと、そのデフォルト値およびポリシーに基づく結果を提示します。
init_policy	コメント付きのポリシーのスターターファイルを書き出します（確認なしで上書きすることはありません）。

Claude Code プラグインには /release-check が追加されます。これは根拠を収集し、不足分を生成するツールを案内して評価と説明を行い、判定を決して緩和しません。

CI での使用

k11-release-gate-mcp evaluate --label v2.4.0 --base origin/main

release-decision.md（PR コメント）と release-decision.json（監査記録）を書き出し、GitHub Actions の出力（verdict、blockers、needs_human、conditions、report）を設定します。また、--fail-on block | needs-human | conditions | never に従ってゼロ以外の終了コードを返します。docs/release-gate.yml を参照してください。

インストール

/plugin marketplace add K11-Software-Solutions/k11techlab-release-gate-mcp
/plugin install release-gate@k11-release-gate

MCP サーバーのみをインストールする場合：claude mcp add release-gate -- uvx k11-release-gate-mcp。CI 用には pip install k11-release-gate-mcp を実行します。

背景

これは、K11 による自律型 CI/CD 品質保証の研究（IJECS、2026 年）における、リスクに応じたヒューマン・イン・ザ・ループの考え方を実践に移すものです。明確なケースは自動化し、不確実なケースは根拠を添えて担当者を指定し、その人に判断を委ねます。これは独立した実装であり、研究コードには依存しません。

開発

python -m venv .venv && .venv/Scripts/pip install -e ".[dev]"   # bin/pip on macOS/Linux
pytest   # real evidence from all five tools, policy, determinism, diff-aware planning, CLI, MCP (15)

ロードマップ

• ルールごとの注釈を付けた GitHub Check
• 規制対象のリリース向けに、署名付きの判定記録（Sigstore）
• 判定に対する承認の記録（needs_human 判定に誰がいつ承認したか）
• Release Readiness Agent：plan_checks が要求するチェックを K11 サーバー経由で実行し、このゲートに判定を問い合わせる Claude Code プラグイン

---

K11 Software Solutions が開発。K11 Tech Lab のエージェント型 QA シリーズの一部です。MIT ライセンスです。