Ai 測試大師 / Mcp Test Runner

Name: Ai 測試大師 / Mcp Test Runner
Author: kao273183

ローカル

github.com/kao273183開発ツール3721 週間前に更新

リポジトリ

Ai 測試大師 / Mcp Test Runner について

MK QA Master は、pytest、Jest、Cypress、Go、Maestro などのテストを実行する MCP サーバーです。Web、モバイル、API を対象とし、AI クライアントで QA 作業を行うチーム向けに、実行ごとに優先度付きのアクションプランを生成します。

主な機能

01複数フレームワークを扱う共通のMCPツール
02Web・モバイル・API テストへの対応
03失敗時のスクリーンショット、動画、トレース収集
04実行履歴と HTML のトレンドレポート
05analyze_url によるページ分析と generate_test によるテスト生成
06CI 連携向けの JUnit XML 出力

活用シーン

01MCP クライアントから pytest や Jest のテストを実行し失敗を確認
02OpenAPI スキーマや Postman コレクションによる API テストの実行
03iOS シミュレーターや Android エミュレーター上での Maestro フローの実行

MCP 対応

本プロジェクトは MCP サーバーとして、テスト実行、ページ分析、テスト生成、レポート参照などのツールを Claude Desktop や Cursor などの MCP クライアントに提供します。

設定

ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。

インストール方法は未掲載です

このサーバーのパッケージやリモートエンドポイントはまだ取得できていません。プロジェクトの README の手順に従ってください。

リポジトリ

ツール

ツール一覧はまだ取得されていません

ローカルサーバーのツールはマシン上で起動して初めて取得できます。メンテナーはまだツール一覧を提供していません。

詳細

MK QA Master

AI テストマスター — 分析からアドバイスまで、AI による QA のサイクルを実現します。

英語 · 繁体字中国語

pytest／Jest／Cypress／Go でテストを実行できる汎用 MCP サーバーです。 DOM アナライザー、実行履歴、自己改善コーチを内蔵しています。 v1.0.0 以降、安定版です（2026-06-02） — 詳細は以下の安定性の保証をご覧ください。

Claude Desktop／Cursor／任意の MCP クライアントからテストスイートを最初から最後まで操作できる Model Context Protocol サーバーです。テストの実行、失敗の調査（スクリーンショット＋動画＋トレース）、稼働中の URL の分析によるテストケースの作成に加え、各実行後に優先順位付きのアクションプランを作成し、次に修正または作成すべき内容を具体的に提示します。

`QA_RUNNER`	フレームワーク	言語	対象
`pytest` / `pytest-playwright` / `playwright`	pytest + Playwright	Python	Web
`jest`	Jest	JavaScript	Web
`cypress`	Cypress	JavaScript	Web
`go` / `go-test`	`go test`	Go	バックエンド
`maestro` / `mobile`	Maestro	YAML	iOS + Android
`schemathesis` / `api`	Schemathesis	OpenAPI 3.x / Swagger 2.0	API（v0.6.0 以降）
`newman` / `postman`	Newman	Postman collection v2.x	API（v0.6.1 以降）

設計の詳細については、docs/framework.mdをご覧ください。

同梱内容

複数のフレームワーク（Web＋モバイル＋API）にわたって、単一の MCP インターフェースからテストを実行
Maestro によるモバイルテスト（v0.3.0 以降）：同じ MCP ツールで、iOS Simulator／ Android Emulator／実機に対応。YAML フローを使い、書き換えなしでクロスプラットフォームに対応
ネイティブ API テスト — 2 つのランナー（v0.6.0／v0.6.1 以降）：2 つのランナーが API テスト枠を共有し、チームがすでに管理しているアーティファクトをそれぞれ利用します。
- Schemathesis（QA_RUNNER=schemathesis、v0.6.0 以降）：OpenAPI 3.x／Swagger 2.0 の URL または file:// スキーマを指定すると、ステータスコード、レスポンススキーマ、コンテンツタイプ、およびファジング時の 5xx 違反を対象とした、プロパティベースのファジングテストを実行します。
- Newman（QA_RUNNER=newman、v0.6.1 以降）：エクスポートした Postman 2.x コレクション（任意で環境ファイル／グローバルファイルも指定可能）を指定すると、 Newman がすべてのリクエストを再生し、埋め込みの pm.test(...) アサーションを実行して、アサーションごとに 1 つの mk-qa-master nodeid を返します。Newman は システム要件（npm install -g newman）です。npm パッケージであり、pip パッケージではないため、Python の追加依存関係としては含まれていません。
どちらも Web／モバイルのランナーと同じ MCP ツールインターフェースに追加され、同じ report.json／履歴／フレーク／最適化パイプラインにデータを渡します。 pytest＋httpx、Jest＋supertest、Cypress の cy.request()、Go の net/http/httptest で書かれた既存の API テストは、引き続き既存のランナーで実行できます。移行は不要です。Pact プロバイダー検証は、条件付きで v0.7.0 のロードマップに残っています。
失敗時のアーティファクト：スクリーンショット（base64 をインラインで埋め込み）、動画、Playwright の trace.zip／Maestro の記録
実行履歴：実行のたびにスナップショットを保存し、HTML レポートにスパークラインの傾向を表示
DOM／画面アナライザー — Web 用の analyze_url（フォーム／ナビゲーション／ダイアログ／ CTA と、ページが呼び出す API エンドポイント）と、モバイル用の analyze_screen （maestro hierarchy → フォーム／CTA／tab_bar モジュール）
スマートなテスト生成（generate_test）：アナライザーモジュールを渡すと、# TODO のスタブではなく、具体的なセレクターを使った実行可能な Playwright .py または Maestro .yaml を生成
フレークを自動再試行 — pytest 側では pytest-rerunfailures、Maestro 側ではカスタムの再試行ラッパーを使用（ネイティブの --reruns はありません）。不安定なテストを実際の失敗とは分けて表示
自己改善コーチ（get_optimization_plan）：実行後に 3 つの観点から分析 — テストスイートの品質、MCP の使いやすさ、AI による生成の有効性
CI 連携（GitHub Actions／Jenkins／GitLab）向けの JUnit XML 出力

インストール

2 つの方法があります。用途に合った方法を選んでください。

A. `uvx` で実行（インストール不要。エンドユーザーに推奨）

グローバルに何もインストールせずに、クライアント設定に mk-qa-master を追加します。uv がセッションごとに一時環境へ取得して実行します。

{
  "mcpServers": {
    "mk-qa-master": {
      "command": "uvx",
      "args": ["mk-qa-master"],
      "env": { "QA_RUNNER": "pytest", "QA_PROJECT_ROOT": "/path/to/your-test-project" }
    }
  }
}

これでセットアップは完了です。初回の呼び出し時にパッケージがダウンロードされ、その後の呼び出しではキャッシュが使われます。バージョンを切り替えるには、uvx [email protected] ... を使います。

B. プロジェクトの venv にインストール（コントリビューター／開発向け）

pip install mk-qa-master       # or: pip install -e . from a clone
playwright install                # only if you use pytest-playwright
pip install pytest-rerunfailures  # optional, enables auto-retry

次に、同じ Python インタープリターをクライアント設定で指定します。

"command": "/path/to/.venv/bin/python",
"args": ["-m", "mk_qa_master.server"]

インストールを確認する（v1.4 以降）

mk-qa-master doctor          # human-readable check report
mk-qa-master doctor --json   # for CI gates / host-LLM consumption

Python のバージョン、PATH 上の ffmpeg と mediamtx、コア依存関係、[edge] の追加依存関係、ランナーレジストリ、MCP ツールのインターフェースを順に確認します。重大な不足がなければ 0 で終了します（未使用機能に関する警告では失敗しません）。mk-qa-master が正常に実行できない場合は 1 で終了します。新規インストール後、または MCP ツールが missing_extras を返したときに実行してください。

ランナー固有の前提条件

`QA_RUNNER`	必要なもの
`pytest` / `pytest-playwright`	`pip install pytest-playwright` + `playwright install chromium`
`jest`	`jest` をインストールした Node プロジェクト（`npm i -D jest`）
`cypress`	`cypress` をインストールした Node プロジェクト（`npm i -D cypress`）
`go`	PATH 上に Go ツールチェーン
`maestro`	Maestro CLI + 起動済みのシミュレーター／エミュレーター／デバイス（または `adb connect` で接続可能な BlueStacks）
`schemathesis` / `api`	`pip install 'mk-qa-master[api]'`（`schemathesis>=3.0,<4` がインストールされます）
`newman` / `postman`	`npm install -g newman`（Newman は npm パッケージであり、pip ではありません。追加のインストールは不要です）

API テスト（`QA_RUNNER=schemathesis`）

ランナーに任意の OpenAPI 3.x / Swagger 2.0 スキーマを指定すると、Schemathesis が各オペレーションのプロパティベースのテストケースを生成します。レスポンススキーマへの準拠、ステータスコードへの準拠、コンテンツタイプのチェック、ファジング時の 5xx を網羅します。結果は、UI テストと同じ report.json／履歴／フレーク／オプティマイザーパイプラインに送られます。

手順を追った解説は docs/walkthrough-api.md にあります。自己完結型の 3 エンドポイントのサンプルは examples/sample_api_project/ にあります。

5 行の設定

"env": {
  "QA_RUNNER": "schemathesis",
  "QA_OPENAPI_URL": "https://api.example.com/openapi.json"
}

環境変数

変数	必須	デフォルト	説明
`QA_OPENAPI_URL`	はい	—	OpenAPI URL。ライブスキーマには `http(s)://...`、ローカルファイルには `file://...` を指定します。通常のファイルシステムパスは受け付けません — `file://` プレフィックスが必要です。
`QA_SCHEMATHESIS_CHECKS`	いいえ	`all`	カンマ区切りで指定するサブセット：`response_schema_conformance,status_code_conformance,not_a_server_error,content_type_conformance,response_headers_conformance`。
`QA_SCHEMATHESIS_AUTH`	いいえ	—	Authorization ヘッダーの値。`-H "Authorization: <value>"` として送信されます。ログには記録されず、アーカイブされたレポートではマスキングされます。
`QA_SCHEMATHESIS_MAX_EXAMPLES`	いいえ	`20`	オペレーションごとの Hypothesis の例数。値を大きくするとファジングがより詳細になる一方、実行時間が長くなります。
`QA_SCHEMATHESIS_DRY_RUN`	いいえ	`0`	`1` に設定すると、HTTP リクエストを実行せずに計画します。本番環境に対する安全性の事前確認や、スキーマのみの成果物を使った CI のスモークテストに役立ちます。
`QA_NO_REDACT`	いいえ	`0`	アーカイブされたレポートのシークレットのマスキングを無効にします。デフォルトでは `Authorization: Bearer …`、`"password": …`、`"token" / "api_key" / "secret" / "access_token" / "refresh_token": …` がマスキングされます。

標準の QA_TIMEOUT_SECONDS も引き続き適用されます（デフォルトは 600s）。

API テスト（`QA_RUNNER=newman`）

ランナーに任意のエクスポート済み Postman 2.x コレクションを指定すると、Newman 6.x がすべてのリクエストを再実行し、埋め込みの pm.test(...) アサーションを実行します。各アサーションが mk-qa-master の 1 つの「テスト」として返されます。結果は、Schemathesis や UI のランナーと同じ report.json／履歴／フレーク／オプティマイザーパイプラインに送られます。

システム要件：Newman は pip ではなく npm で提供されています。次のコマンドを一度実行してインストールしてください。

npm install -g newman

pip install 'mk-qa-master[postman]' という追加機能はありません — ランナーは PATH 上の newman バイナリを呼び出すだけです。見つからない場合、ランナーは npm でのインストールを示す行を明記した、分かりやすい ImportError を発生させます。

OpenAPI サンプルが対象とするのと同じ 3 エンドポイントの Library API は、Postman コレクションとして examples/sample_api_project/postman-collection.json にも用意されています。これを prism mock examples/sample_api_project/openapi.yaml と組み合わせると、完全に自己完結した開発ループを利用できます。または、独自のステージングサーバーを指定してください。

5 行の設定

"env": {
  "QA_RUNNER": "newman",
  "QA_POSTMAN_COLLECTION": "/absolute/path/to/your-collection.json"
}

環境変数

変数	必須	デフォルト	説明
`QA_POSTMAN_COLLECTION`	はい	—	Postman 2.x コレクション JSON の通常のファイルシステムパスです。`file://` プレフィックスは付けないでください。コレクションは常にローカルの成果物なので、Newman でスキームを区別する必要はありません。
`QA_POSTMAN_ENVIRONMENT`	いいえ	—	Postman 環境ファイルの通常のパスです（`-e <path>`）。コレクション内の `{{var_name}}` プレースホルダーに値を指定します。
`QA_POSTMAN_GLOBALS`	いいえ	—	Postman グローバルファイルの通常のパスです（`-g <path>`）。環境ファイルと同じ形式で、グローバルスコープに適用されます。
`QA_POSTMAN_ITERATIONS`	いいえ	`1`	コレクション全体を N 回再実行します（`-n <N>`）。長時間負荷テストや不安定性の検出に役立ちます。
`QA_POSTMAN_FOLDER`	いいえ	—	実行対象を絞り込む Postman フォルダー名の CSV です（`--folder` フラグを繰り返し指定します）。失敗が特定のフォルダーに集中している場合、`run_failed` でもフォルダーで絞り込みます。
`QA_POSTMAN_TIMEOUT_REQUEST_MS`	いいえ	`30000`	リクエストごとの HTTP タイムアウトをミリ秒で指定します（`--timeout-request`）。サブプロセス全体の上限を設定する `QA_TIMEOUT_SECONDS` とは別です。
`QA_NO_REDACT`	いいえ	`0`	Schemathesis ランナーと同じマスキングポリシーです。短時間のデバッグセッションでのみ無効にしてください。

標準の QA_TIMEOUT_SECONDS も引き続き適用されます（デフォルトは 600s です）。

AI ビジュアルチャレンジソルバー（v0.7.0）

バックエンドでの回避ができない場合：Claude が CAPTCHA を見て、mk-qa-master がクリックします。

reCAPTCHA v2（v0.7.0 以降）と hCaptcha（v0.7.1 以降）をサポートしています。

この機能群で初めて、AI クライアントのビジョン機能が任意ではなく、不可欠となっています。2 つの新しい MCP ツール（inspect_visual_challenge と solve_visual_challenge）が、アクティブな Playwright ページ上の reCAPTCHA v2 または hCaptcha の画像グリッドチャレンジを検出し、マルチモーダル AI クライアント用にスクリーンショットを撮影し、AI が返したタイル選択を受け取り、クリック操作を実行します。ランナーは目と手を担い、 AI クライアント（Claude / Cursor / Gemini / GPT-4o）が実際のソルバーとなります。

使うタイミング — Tier 1 と Tier 3

組み込みの QA ナレッジレイヤー（get_qa_context section="CAPTCHA"）では、3 つのティアが定義されています。以下の順に検討してください。

Tier	アプローチ	タイミング
1 — 回避	reCAPTCHA テストキー、機能フラグ、IP 許可リスト、テストモードヘッダー	デフォルトです。約 90% のケースに対応します。
2 — 影響を軽減	`external_dependency` としてマークし、後続のアサーションをスキップする	バックエンドを変更できないものの、テスト対象が CAPTCHA 自体ではない場合です。
3 — AI によるビジュアル判定	この機能です。	1 と 2 が適さない場合に限ります（バックエンドへのアクセスはないものの許可を得ているクライアントサイト、本番環境の CAPTCHA を再現するステージング環境、IP 許可リストに到達できないモバイル WebView など）。

同意の確認

明示的にオプトインするまで、ソルバーは何もしません。次の 2 つの環境変数で制御します。

変数	必須	デフォルト	説明
`QA_VISUAL_CHALLENGE_CONSENT`	はい	`false`	いずれかのツールを機能させるには、`true` に設定する必要があります。設定されていない場合、両方のツールは法的免責事項全文を含む `consent_required` エラーを返します（AI クライアントがこれをユーザーに表示します）。
`QA_VISUAL_CHALLENGE_AUTHORIZED_DOMAINS`	いいえ（推奨）	—	ツールの使用を許可するドメインのカンマ区切り許可リストです。設定すると、リストにないドメインでの使用を拒否します。未設定の場合は警告のみで処理を続行し、設定を促す警告をレスポンスに付加します。共有 CI／マルチテナント環境では推奨です。
`QA_VISUAL_CHALLENGE_TIMEOUT`	いいえ	`120`	検査から解決までのサイクルに使う実時間の上限を秒で指定します。ハード上限として `QA_TIMEOUT_SECONDS` を尊重します。

クイックスタート

"env": {
  "QA_RUNNER": "pytest",
  "QA_PROJECT_ROOT": "/path/to/project",
  "QA_VISUAL_CHALLENGE_CONSENT": "true",
  "QA_VISUAL_CHALLENGE_AUTHORIZED_DOMAINS": "client-staging.example.com"
}

その後、run_tests の呼び出しで CAPTCHA を指す external_dependency の失敗が表面化した場合、AI クライアントは次のようにエスカレーションできます。

mk-qa-master.inspect_visual_challenge()  # screenshot + tile grid
→ AI vision picks tiles [0, 4, 7]
mk-qa-master.solve_visual_challenge(
    challenge_id="...", selected_tile_indices=[0, 4, 7], confirm=true,
)
→ status: "passed", token: "...", hint: "CAPTCHA verified. Resume your test."

詳しい手順は docs/walkthrough-visual-challenge.md をご覧ください。 PRD：docs/prd-v0.7-visual-challenge.md。

ハードストップ対象のドメイン

同意の有無や許可リストにかかわらず、ソルバーは既知のサードパーティーの ID プロバイダー（accounts.google.com、 login.microsoftonline.com、id.apple.com、facebook.com、 login.live.com など）に対する操作を拒否します。他者のログインポータルで CAPTCHA ソルバーを使うことが正当化される QA シナリオはありません。

プライバシー

スクリーンショットは、実行中の検査→解決サイクルを超えて保持しません。テレメトリーに記録されるのは結果の真偽値のみです。スクリーンショット、チャレンジのテキスト、タイルの選択内容は一切記録しません。5 分間の LRU キャッシュは、プロセスあたり最大 10 件の未処理チャレンジを保持し、ディスクには一切触れません。

成功率に関する注意

実際の判定は AI クライアントのビジョンモデルが行います。Claude Sonnet 4、GPT-4o、Gemini 2.5 はいずれも標準でビジョン機能を搭載していますが、3x3 の reCAPTCHA に対する精度はさまざまです。チャレンジごとに少なくとも 1 回の再試行を想定してください（reCAPTCHA ではロックアウトされるまでに 3 回試行できます）。get_telemetry では最終的に合格率の集計値が表示されるため、クライアントごとにその想定を調整できます。

対象範囲：v0.7.0 では reCAPTCHA v2 の画像グリッドのみです。hCaptcha は v0.7.1 で追加されます。reCAPTCHA v3 と Cloudflare Turnstile は対象外です。検査可能な可視チャレンジが表示されないため、今後も対象に含まれません。

OWASP API Security のスキャン（v0.8.0）

Schemathesis は正確性の乖離を検出します。v0.8.0 では、スキーマに合格した裏に潜むセキュリティの乖離を検出するレイヤーを追加します。

v0.8.0 では、新しい MCP ツールとしてOWASP API Security Top 10 (2023) ルールベーススキャナーの run_api_security_scan を提供します。OpenAPI 3.x の仕様を読み込み、各（パス × メソッド）を走査して、HTTP から観測可能な次の 5 つのルールを実行します。

OWASP #	ルール	該当時の重大度
API1	BOLA / IDOR — パス ID の改ざんにより、alice のトークンで bob のオブジェクトを読み取る	CRITICAL
API2	認証の不備 — サーバーが `alg:none`、不正な形式、または署名が誤った JWT を受け入れる	プローブに応じて MEDIUM / HIGH / CRITICAL
API3	マスアサインメント — サーバーが `role: admin`、`is_verified: true` などの危険な追加フィールドを保存する	HIGH
API5	機能レベルの認可 — 管理者以外のユーザーが管理者向けのエンドポイントにアクセスする	HIGH
API8	セキュリティ設定の不備 — HSTS/CSP/X-Frame ヘッダーの欠落、認証情報を許可するワイルドカード CORS	LOW / MEDIUM / HIGH

API4（レート制限による DoS リスク）、API6（ビジネスフローのモデル化）、API7 （SSRF コールバック用インフラ）、API9（本番環境の偵察）、API10 （上流 API）は延期されています。§3 の docs/prd-v0.8-api-security.md を参照してください。

同意と認可のゲート

v0.7 のビジュアルチャレンジにおける同意モデルを踏襲しています。

変数	必須	機能
`QA_API_SECURITY_CONSENT`	はい	`true` である必要があります。設定されていない場合は `consent_required` を返します。
`QA_API_SECURITY_AUTHORIZED_DOMAINS`	外部ホストでは必須	カンマ区切りの許可リストです。localhost / 127.0.0.1 は暗黙的に認可されます。

mass_assignment ルールはサーバーの状態を変更するため、デフォルトのカテゴリーから除外されています。呼び出し側が明示的に指定する必要があります。 categories=["headers", "broken_auth", "bola", "function_authz", "mass_assignment"]。

クイックスタート

"env": {
  "QA_RUNNER": "pytest",
  "QA_PROJECT_ROOT": "/path/to/project",
  "QA_API_SECURITY_CONSENT": "true",
  "QA_API_SECURITY_AUTHORIZED_DOMAINS": "api.staging.example.com"
}

次に、AI クライアントにスキャンを依頼します。

mk-qa-master.run_api_security_scan(
    spec_url="https://api.staging.example.com/openapi.yaml",
    auth={
        "token": "alice's bearer token",
        "alt_user_token": "bob's bearer token",
        "bola_test_ids": {"user_a": [101, 103], "user_b": [202]}
    },
    severity_threshold="medium"
)

v0.8 のセキュリティレポートブロックが返されます。

{
  "scan_id": "a3f8d1c9b7e2",
  "spec_url": "...",
  "base_url": "https://api.staging.example.com",
  "categories_run": ["headers", "broken_auth", "bola", "function_authz"],
  "rules_ran": ["OWASP-API8-Headers", "OWASP-API2-BrokenAuth", ...],
  "ops_scanned": 23,
  "severity_threshold": "medium",
  "findings": [
    {
      "rule_id": "OWASP-API1-BOLA-CrossUserDataExposure",
      "severity": "critical",
      "endpoint": "GET /orders/{id}",
      "title": "user_a can read user_b's object id=202 — missing object-level authorization check",
      "evidence": {"actor": "user_a", "target_owner": "user_b", "target_id": 202, "probed_path": "/orders/202", "status_code": 200, ...},
      "remediation_hint": "Compare the caller's identity to the object's owner before returning..."
    },
    ...
  ],
  "summary": {"total": 7, "by_severity": {"critical": 2, "high": 4, "medium": 1, "low": 0, "info": 0}}
}

Tier 1 の正解データ

examples/sample_vulnerable_api/ には、対象範囲内の OWASP カテゴリーすべてについて、脆弱なエンドポイントと安全なエンドポイントのペアを備えた、意図的に脆弱な Flask アプリが含まれています。ローカルで実行し、各ルールの動作を確認してください。

cd examples/sample_vulnerable_api
pip install -r requirements.txt
python app.py  # binds 127.0.0.1:5099
# Then from another shell, point run_api_security_scan at
# http://127.0.0.1:5099 + the bundled openapi.yaml

スキャナーは /vuln/* で 5 つのカテゴリーすべてを検出し、/safe/* では誤検知を 1 件も出しません。この特性は、すべての PR で実行される Tier 1 のドッグフードテストによって保証されています。

セキュリティに関する注意

スキャナーは敵対的なテストケースを実行します。所有していない本番システムや、使用許可を得ていないシステムに対して実行しないでください。上記の2つの環境変数が契約条件です。

PRD：docs/prd-v0.8-api-security.md。以前の v0.8 モバイル版の試みは保留になりました。そこから得た教訓と、API セキュリティ PRD のテストゲートにどのように反映されたかについては、docs/v0.8-mobile-postmortem.mdを参照してください。

Claude Code／Codex／Hermes／OpenClaw スキルとして使用する（v0.9.0）

agentskills.ioの規約により、同じスキルフォルダーを4種類のエージェントホストに読み込めます。

v0.9.0 では、MCP サーバー形式に加えて、mk-qa-master をクロスホスト対応のエージェントスキルとしてパッケージ化しています。skills/mk-qa-master/フォルダーが唯一の信頼できる情報源であり、同じSKILL.md、スラッシュコマンド、リファレンスドキュメントを次の環境に読み込めます。

Claude Code — .claude-plugin/plugin.json経由で使用します（このリポジトリはプラグインマーケットプレイスです）。
OpenAI Codex — .codex-plugin/plugin.json経由で使用します（Codex は Claude スタイルのマーケットプレイスを読み込みます）。
OpenClaw — ローカルのチェックアウトからインストールします：openclaw plugins install /path/to/mk-qa-master。
Hermes Agent — スキルフォルダーを~/.hermes/skills/にシンボリックリンクします。

クイックインストール（Claude Code）

# Inside Claude Code:
/plugin marketplace add kao273183/mk-qa-master
/plugin install mk-qa-master@mk-qa-master

スキルを登録するため、Claude Code を再起動してください。その後、QA テストに関するプロンプトでスキルが自動的に有効になります。スラッシュコマンドで明示的に呼び出すこともできます。

/mk-qa-master:run-tests login
/mk-qa-master:generate https://staging.example.com
/mk-qa-master:api-security https://api.staging.example.com/openapi.yaml

スキルの機能

このスキルは単一ファイルの運用契約であり、mk-qa-master の22個の MCP ツールを一貫性のある形で使う方法をホストに教えます。次の内容が記述されています。

自動的に有効化するタイミング — 「テストを実行して」「このテストが失敗した理由は？」「この API に OWASP の問題がないかスキャンして」などのフレーズで有効になります。
5つのフロー — テストの実行／テストの生成／失敗のデバッグ／CAPTCHA の解決／API のスキャン。
厳守事項 — 同意エラーをそのまま提示する、フィルターを緩和して黙って再実行しない、破壊的な実行の前に確認する。

詳細なリファレンスはskills/mk-qa-master/SKILL.mdを参照してください。

MCP サーバーに加えてスキルを使う理由

MCP サーバーにより、あらゆるクライアントから22個のツールを呼び出せるようになります。スキルにより、ツールを見つけやすくし、適切に使えるようになります。ホストのスキルルーターに、ツールをいつ使い、どのフローに従うかを判断するのに十分なコンテキストを与えます。同じパターンを使うmicrosoft/Webwrightに着想を得ています。

安定性の保証（v1.0.0）

22個のツール。スキーマを固定。変更はバージョンで管理。バージョンを固定して使えます。

mk-qa-master は2026-06-02に v1.0.0 をリリースしました。MCP ツールの仕様は固定されています。22個のツール、同意ゲートの環境変数、プラン／ブックエンドの形式、ハードストップのブラックリストは、非推奨化の期間を設けずに変更されることはありません。

呼び出し側にとっての意味

バージョンを固定する場合…	内容
`mk-qa-master==1.0.*`	パッチリリースのみ（バグ修正。仕様の変更なし）
`mk-qa-master==1.*`	マイナーリリース（追加のみ：新しいツール、新しい任意引数、新しいフィールド）
`mk-qa-master>=1,<2`	上記と同じ

破壊的変更には v2.0 へのバージョンアップが必要です。非推奨化の際は、少なくとも1回のマイナーリリース分、事前に警告します。実行時にDeprecationWarningを発生させ、MCP ツールの説明に「Deprecated:」を記載し、docs/MIGRATION-1.x-to-2.0.mdにエントリーを追加します（v2.0 の作業開始時に作成されます）。

保証の適用方法

CI のスナップショットテスト（tests/test_v1_schema_snapshot.py）では、tests/snapshots/v1/tool_surface.jsonを使用して22個のツールの仕様を固定します。PR でBREAKING_CHANGE_ACK=trueを設定し、かつdocs/MIGRATION-0.x-to-1.0.mdとdocs/DEPRECATION-POLICY.mdの両方が存在しない限り、仕様の変化があると CI は失敗します。承認だけで変更が許可されるわけではありません。ドキュメントも必要です。

2つ目のテスト（tests/test_v1_doc_sync.py）では、公開ドキュメントをすべてスキャンしてツール数の記載を確認し、実際のサーバーと一致しない場合は失敗します。

コントラクトを読む

docs/MIGRATION-0.x-to-1.0.md — v0.7 → v1.0 のすべての加算的な構造変更を列挙しています。要約：v0.10 → v1.0 では変更はありません。
docs/DEPRECATION-POLICY.md — 正式なサイクルです。パッチ＝バグ修正、マイナー＝機能追加、メジャー＝削除（非推奨化の後に限る）。
docs/prd-v1.0-stability-lock.md — 凍結された PRD です。

ライセンス変更計画（v1.2.1 の発表）

現在は MIT。v2.0 で Apache 2.0 に変更します。

mk-qa-master は、v2.0.0 で MIT から Apache 2.0 にライセンスを変更することを発表します。このパッチ（v1.2.1）は正式な発表であり、非推奨化の期間を開始します。

変更内容

固定するバージョン...	適用されるライセンス
`mk-qa-master==1.0.` / `==1.1.` / `==1.2.*` など	永久に MIT — すべての v1.x リリースは MIT ライセンスのままです
`mk-qa-master>=1,<2`	v1.x を使い続ける限り MIT
`mk-qa-master>=2,<3`（v2.0 のリリース後）	Apache 2.0

Apache 2.0 は、商用利用の許可はそのままに、MIT よりも明確に多くの権利を付与します（明示的な特許許諾と商標保護）。利用権が縮小する状況はありません。

スケジュール

v1.2.1（今回のリリース）：発表のみ。コードの変更はありません。
v1.3.x 以降：引き続き MIT です。v2.0 のリリースまで、少なくとも 1 回のマイナーリリース期間を設けます。
v2.0.0（未定）：実際にライセンスを変更します。Apache 2.0 の LICENSE ファイル、NOTICE ファイル、ソースヘッダーの一斉更新、マニフェストの同期を行います。

さらに、v2.0.0 のリリース後、少なくとも 6 か月間は v1.x のバグ修正リリースを維持することを約束します。すぐに Apache 2.0 に移行できない企業にも、移行までの猶予があります。

理由

長期的な持続可能性のためです。特許に関する安心、商標保護、コントリビューターの知的財産権の明確化、企業の調達要件との幅広い適合を実現します。詳しい理由と v2.0 の具体的なチェックリストについては、docs/RELICENSING.md を参照してください。

エッジ AI ランナー（v1.1.0 以降）

RTSP ストリーム、YOLO 推論、pytest アサーションを 1 つの QA_RUNNER=edge フラグで実行できます。

v1.1.0 では、エッジ AI 推論ランナーを追加しました。ウェブおよびモバイルのランナーと同じ「分析 → 生成 → 実行」のループに組み込めます。新しい analyze_stream MCP ツール（ツール #22）は、RTSP の映像サイズを調査し、検出されたラベルごとにテストケース候補を出力します。

クイックインストール

pip install "mk-qa-master[edge]"   # opencv-python + ultralytics + requests

# Plus the binary deps the runner shells out to:
brew install ffmpeg mediamtx       # macOS
# or: sudo apt install ffmpeg + download mediamtx from https://github.com/bluenviron/mediamtx

エンドツーエンドの手順

同梱のサンプルフィクスチャ examples/sample_edge_fixture/ で、全体の流れを確認できます。mk-qa-master==1.1.0（Edge AI）、mk-qa-master==1.1.1（ハウスキーピング）、および 1.1.2（このドキュメントの修正）でテスト済みです。

1. ランナーを設定します。 デスクトップで使用する場合、環境変数は3つで十分です。

export QA_RUNNER=edge
export QA_RTSP_SOURCE="$(pwd)/examples/sample_edge_fixture/factory.mp4"
export QA_MODEL_PATH=yolov8n.pt    # ultralytics auto-downloads on first use

任意の調整項目（括弧内はデフォルト値）：QA_MIN_FPS（25）、QA_LATENCY_SLA_MS（40）、QA_IOU_THRESHOLD（0.5）。

2. Claude / Cursor / 任意の MCP ホストに依頼します。 mk-qa-master を MCP サーバーとして接続した状態で（Claude Desktop への接続を参照）、次のプロンプトを入力します。

"examples/sample_edge_fixture/factory.mp4 のストリームを、同梱のアノテーションサイドカーとともに分析し、各ラベルの検出テストを生成してください。"

Claude は analyze_stream を呼び出して {width: 320, height: 240, fps: 5, labels: ["forklift", "person"], candidate_tcs: [...]} を取得し、各ラベルに対して generate_test を呼び出します。その後、PROJECT_ROOT/tests/ に test_edge_factory_person.py と test_edge_factory_forklift.py を書き込みます。

3. 実行します。 ランナーはローカルの mediamtx と ffmpeg を起動し（ファイルソースは RTSP をループ再生します）、設定した QA_* から EDGE_* 環境変数をエクスポートして、pytest を実行します。生成された各テストでは、次の処理を行います。

cv2.VideoCapture(EDGE_RTSP_URL) を使ってフレームを読み込みます
各フレームを YOLO バックエンドに渡します
LatencyTracker でフレームごとのレイテンシを記録します
正解データの時間枠内で、少なくとも1つのフレームにおいて、対象ラベルの検出が IoU 閾値以内に現れることをアサートします
p95 レイテンシが EDGE_LATENCY_SLA_MS 以下であることをアサートします
150フレームのウィンドウで、持続スループットが EDGE_MIN_FPS 以上であることをアサートします

レポートは PROJECT_ROOT/report.json と junit.xml に出力され、test-results/history/ にアーカイブされます。また、他のランナーと同様に get_optimization_plan が実行されます。

ベンダーホストに対する安全なデフォルト設定

analyze_stream は、既知の監視カメラ／IoT カメラベンダー（Dahua、Hikvision、Ezviz、Axis、Amcrest、Lorex、Swann、Reolink）のドメインを使った RTSP URL を、デフォルトで拒否します。これにより、公開カメラの映像を誤って調査することを、デフォルトの利用経路では防ぎます。自分のカメラでテストする場合は、QA_EDGE_ALLOW_VENDOR_HOSTS=true を設定して有効にしてください。

レジリエンス注入（v1.3.0）

v1.3.0 では、Edge の実行向けに、オプトイン方式のネットワーク劣化ハーネスが追加されました。generate_test に resilience_mode="netem" を渡すと、生成された pytest が Linux の tc qdisc（mk_qa_master.edge.resilience.apply_netem 経由）を使って、ループバックインターフェイスに 200 ms のレイテンシと 5 % のパケット損失を注入し、劣化状態でもランナーが SLA を満たすことをアサートした後、ティアダウン時に qdisc を解除します。

安全のため、二重のガードを設けています。

Linux 以外（macOS / Windows ホスト）では、apply_netem が RuntimeError を送出し、テストは自動的に pytest.skip されます。
Linux でも、QA_EDGE_NETEM_ENABLED=true が設定されるまでは実行を拒否します。ループバックへの影響に対する明示的な同意が必要です。

同じモジュールには、補助ヘルパーとして clear_netem（冪等なティアダウン）、kill_ffmpeg_subprocess（プロセス損失のシナリオ）、build_corrupted_gop_fixture（ffmpeg を使ったビットストリームのノイズ注入）も含まれています。詳細な項目については、src/mk_qa_master/edge/resilience.py と v1.3.0 PRD を参照してください。

レジリエンスモードでテストを実行すると、生成されるレポートに、テストごとの追加項目 edge_metrics ブロック（フレームドロップ、復旧時間など）が含まれます。get_optimization_plan はこの情報を読み取り、通常のシグナルに加えて、Edge 固有の4つのフレークシグナル（破損フレーム率、復旧時間の偏り、ドロップのバースト、継続的なレイテンシ違反）を提示します。

フェーズのステータス

フェーズ	内容	ステータス
1	デスクトップ YOLO ランナー + RTSP ソース管理 + メトリクス	✅ v1.1.0
2	`analyze_stream` MCP ツール + エッジ `generate_test` テンプレート	✅ v1.1.0
ハウスキーピング	サンプルフィクスチャ + `edge-sample` CI + EN/zh-TW エッジナレッジセクション	✅ v1.1.1
ドキュメント	README の手順説明 + トラブルシューティング（このセクション）	✅ v1.1.2
3	リモート推論（`RemoteHTTP.infer()` + `QA_JETSON_HOST` による実プローブ）	✅ v1.2.0
4	レジリエンス注入 + エッジのフレークシグナル + 劣化シナリオ	✅ v1.3.0

トラブルシューティング

症状	考えられる原因	対処方法
`Could not open RTSP stream: rtsp://localhost:8554/cam`	ffmpeg または mediamtx が PATH にない、または 10 秒後にレディネスプローブがタイムアウトした	`which ffmpeg mediamtx` で確認してください。mediamtx が別の場所にある場合は、`QA_MEDIAMTX_BIN=/full/path/to/mediamtx` を設定してください。Apple Silicon では初回起動が遅い場合があります。mediamtx の初回起動後に再実行してください
`[edge] setup failed: ConnectionError`	ポート 8554 が別の mediamtx / RTSP サーバーによってすでに使用されている	`QA_RTSP_PORT=8555`（または空いているポート）を設定してください。生成されるテストは `EDGE_RTSP_URL` を読み取るため、テストの編集は不要です
`analyze_stream` の返す `{ "error": "missing_extras", "hint": ... }`	`[edge]` エクストラを含まない基本インストール	`pip install "mk-qa-master[edge]"` を実行してください（または `mk-qa-master doctor` を実行してインストール全体を監査してください）
`{ "error": "forbidden_vendor_host", "blocked_host": "..." }`	デフォルトで有効になっているブラックリスト（Dahua / Hikvision など）	自分のカメラの場合は、`export QA_EDGE_ALLOW_VENDOR_HOSTS=true` を実行してください。そうでない場合は、ブロックをそのままにしてください
`NotImplementedError: RemoteHTTP backend lands in v1.2 (Phase 3 of theme G)`	v1.1.x で `QA_JETSON_HOST` または `QA_INFERENCE_ENDPOINT` を設定している	v1.1 で使えるのは LocalYolo のみです。リモート用の環境変数を解除して、デスクトップ YOLO にフォールバックしてください。フェーズ 3 は v1.2 で実施されます
`ultralytics` のインストールに時間がかかりすぎる	torch の初回ダウンロード（約 700 MB）	初回のみ発生するコストです。CI では `pip install` をキャッシュしてください。ローカルでは torch の配置後に一度 `pip install --no-deps` を使用してください
生成されたテストが `hit, "label X not detected"` をアサートする一方、サンプルフィクスチャが単なる `testsrc` である	合成テストパターンには実際の人物やフォークリフトが含まれていない	同梱フィクスチャでは想定どおりです（配線の検証のみを目的としています）。実際の検出をアサートするには、実際の映像とアノテーションに置き換えてください。詳細は `examples/sample_edge_fixture/README.md` を参照してください
CPU では p95 レイテンシのアサーションが失敗するが、GPU では成功する	デフォルトの `QA_LATENCY_SLA_MS=40` は GPU 推論を想定している	CPU 実行では `QA_LATENCY_SLA_MS` を引き上げてください（CPU での yolov8n は通常 60～120 ms です）。`get_qa_context(section="Edge Vision Inference")` の SLA デフォルト値の表を参照してください
ffmpeg が `Stream #0:0: Video: ... at 5/1 fps` について警告する	サンプルフィクスチャは、バイナリを 75KB に抑えるため、意図的に低フレームレート（5）になっている	想定どおりです。実際のテストでは、独自の高フレームレートのソースを指定してください

v1.0.0 から v1.1.x への移行

v1.0.0 → v1.1.0 は追加のみです。既存のツールの形式は変更されていません。v1.1.0 → v1.1.1 → v1.1.2 はパッチリリース（ハウスキーピング + ドキュメント）です。v1.2.0 ではフェーズ 3（リモート推論）が追加されました。v1.3.0 ではフェーズ 4（レジリエンス注入 + エッジのフレークシグナル）が追加されました。完全な変更履歴と新しい QA_* 環境変数の一覧（QA_EDGE_NETEM_ENABLED、…）は docs/MIGRATION-1.x.md を参照してください。

完全な PRD：docs/prd-v1.1-edge-ai-runner.md。

汎用の計画＋検証のブックエンド（v0.10.0）

最初に成功条件を宣言し、作業を実行して、チェックリストを受け取ります。対象は一部のツールだけではなく、意味のあるすべてのツールです。

v0.10.0 では、これまで run_api_security_scan のみに適用されていた v0.9.4 のブックエンドパターンを、5 つのコアツールに拡張しました。各ツールは、qa_plan が返す plan_id kwarg を任意で受け取ります。この plan_id を渡すと、ツールのレスポンスに plan_verification エンベロープが追加され、宣言した重要項目に照らして作業を自動検証します。別途 verify_plan を呼び出す必要はありません。

ツール	エビデンスの形式	代表的な CP
`run_tests`	pytest-json-report の `tests` 配列（テストごとの結果）	`"test_login passes"` / `"suite duration < 30s"`
`solve_visual_challenge`	単一レコード：`{kind, status, token_populated, rounds_used, fingerprint, challenge_id}` — エビデンスに生のトークンは絶対に含まれません	`"captcha solved AND token_populated"`
`analyze_url`	検出されたモジュールごとに 1 行（`kind`、`selectors`、ソース URL を含む）	`"form module discovered"` / `"≥1 cta found"`
`auto_generate_tests`	生成されたテストごとに 1 行（成功または失敗）	`"form module produced ≥1 test"` / `"no generation errors"`
`run_api_security_scan`（v0.9.4）	OWASP 検出項目ごとに 1 行	`"BOLA finding on /orders endpoint"`

plan = qa_plan(
    task="Smoke the signup flow",
    critical_points=[
        {"id": "CP1", "verification_hint": "test_happy_path passes"},
        {"id": "CP2", "verification_hint": "BOLA-on-orders"},
    ],
)

result = run_tests(plan_id=plan["plan_id"])

# result["plan_verification"]["status"] == "passed" | "incomplete" | "failed"
# result["plan_verification"]["checklist"] tells you per-CP outcomes

後方互換性：plan_id を省略すると、v0.9.x のレスポンス形式がそのまま維持されます。ツールごとのエビデンス契約と確定済みの決定事項については、docs/prd-v0.10-universal-bookend.md を参照してください。

Claude Desktop に接続する（従来の MCP のみの方法）

プラグイン／スキル層を使用せず、基本的な MCP サーバー接続を行う場合は、examples/configs/claude_desktop_config.example.json を次の場所にコピーします。

macOS：~/Library/Application Support/Claude/claude_desktop_config.json
Windows：%APPDATA%\Claude\claude_desktop_config.json

実行時には、次の 2 つの環境変数を使用します。

変数	例	用途
`QA_RUNNER`	`pytest` / `jest` / `cypress` / `go` / `maestro` / `schemathesis` / `newman`	使用するテストフレームワークを選択します
`QA_PROJECT_ROOT`	`/path/to/your/project`	テスト対象のプロジェクトを指定します
`QA_ANDROID_HOST` (任意)	`127.0.0.1:5555`	BlueStacks／Genymotion／Nox／クラウド Android 向けのリモート ADB エンドポイントです。設定すると、Maestro ランナーは各テスト／`analyze_screen` 呼び出しの前に `adb connect <host>` を自動実行します。PATH 上に `adb` が必要です。
`QA_TIMEOUT_SECONDS` (任意)	`600`（デフォルト）	1 回のサブプロセス呼び出し（pytest／jest／cypress／go test／maestro）に対するハード上限時間です。上限を超えると、stderr に `[TIMEOUT…]` タグを付けて `exit_code=124` を返します。これにより、MCP サーバーが停止したままになるのを防ぎ、AI クライアントが適切に対応できます。

ランナー別スニペット

pytest-playwright：

"env": { "QA_RUNNER": "pytest", "QA_PROJECT_ROOT": "/path/to/python-project" }

Jest：

"env": { "QA_RUNNER": "jest", "QA_PROJECT_ROOT": "/path/to/node-project" }

Cypress：

"env": { "QA_RUNNER": "cypress", "QA_PROJECT_ROOT": "/path/to/cypress-project" }

Go test：

"env": { "QA_RUNNER": "go", "QA_PROJECT_ROOT": "/path/to/go-project" }

Maestro（モバイル、v0.3.0 以降）：

"env": {
  "QA_RUNNER": "maestro",
  "QA_PROJECT_ROOT": "/path/to/maestro-flows",
  "QA_ANDROID_HOST": "127.0.0.1:5555"
}

QA_ANDROID_HOST は任意です。リモート ADB 経由で BlueStacks／Genymotion／クラウド Android ファームを対象とする場合にのみ設定してください。iOS Simulator／Android Emulator／ローカル USB デバイスは自動検出されます。

Schemathesis（API）：

"env": {
  "QA_RUNNER": "schemathesis",
  "QA_OPENAPI_URL": "https://api.example.com/openapi.json"
}

Newman（Postman）：

"env": {
  "QA_RUNNER": "newman",
  "QA_POSTMAN_COLLECTION": "/absolute/path/to/collection.json"
}

Edge AI（RTSP + YOLO、v1.1.0 以降）：

"env": {
  "QA_RUNNER": "edge",
  "QA_RTSP_SOURCE": "/absolute/path/to/factory.mp4",
  "QA_MODEL_PATH": "yolov8n.pt"
}

pip install "mk-qa-master[edge]" と ffmpeg、mediamtx が PATH 上に必要です。環境変数の一覧とトラブルシューティングについては、Edge AI ランナーの手順を参照してください。

その他の MCP クライアント

MCP はオープンなプロトコルであり、このサーバーは Claude 専用ではありません。同じ Python プロセスが JSON-RPC stdio を介して、あらゆる MCP クライアントと通信できます。クライアントによって異なるのは、（1）設定ファイルの形式と、（2）基盤となるモデルがツール呼び出しをどれだけ確実に連鎖させるかです。

クライアント	設定	形式	モデル	ツール連鎖の品質
Claude Desktop / Cursor	`~/Library/Application Support/Claude/...json` · `~/.cursor/mcp.json`	JSON	Claude Opus / Sonnet	最もよくテストされています
Codex CLI	`~/.codex/config.toml`	TOML	GPT-5 family	強力（ツール連鎖のトレーニングが十分に行われています）
Gemini CLI	`~/.gemini/settings.json`	JSON	Gemini 3.1 Pro / Flash	動作します。明示的なプロンプト（「最初に分析し、次に書く」など）を推奨します
Cline / Continue / Zed	それぞれ独自の MCP 設定スロットがあります	さまざま	さまざま	設定されたモデルによって異なります

リポジトリには設定例が含まれています： codex-config.example.toml · gemini-config.example.json · claude_desktop_config.example.json。

Codex（TOML）：

[mcp_servers.mk-qa-master]
command = "/path/to/.venv/bin/python"
args = ["-m", "mk_qa_master.server"]
cwd = "/path/to/mk-qa-master"
[mcp_servers.mk-qa-master.env]
QA_RUNNER = "pytest"
QA_PROJECT_ROOT = "/path/to/your-test-project"

Gemini（JSON、Claude Desktop と同じ構造）：

{
  "mcpServers": {
    "mk-qa-master": {
      "command": "/path/to/.venv/bin/python",
      "args": ["-m", "mk_qa_master.server"],
      "cwd": "/path/to/mk-qa-master",
      "env": {
        "QA_RUNNER": "pytest",
        "QA_PROJECT_ROOT": "/path/to/your-test-project"
      }
    }
  }
}

ツールの説明では、推奨される連鎖（analyze_url → generate_test、ドメインテストを生成する前の get_qa_context）をすでに促しています。ツール選択が得意でないクライアントほど、手順を明示したプロンプトの効果が大きくなります。

ツールの一覧

すべてのランナーで共通です（一部のツールは、pytest 以外のランナーでは適切に機能を縮退します）。

ツール	目的
`get_runner_info`	現在有効なランナーと、利用可能なすべてのランナーを確認します
`list_tests`	プロジェクト内のテストを列挙します
`run_tests`	テストを実行します（フィルター／ヘッドあり／ブラウザー。後ろの2つは pytest-playwright のみ）
`run_failed`	直近の失敗を再実行します（`pytest --lf`）
`get_test_report`	概要を表示します（成功／失敗／スキップ／所要時間／実行中の不安定なテスト）
`get_failure_details`	失敗ごとのメッセージと、スクリーンショット／トレース／動画のパスを表示します
`generate_test`	テストのひな形を生成します。`analyze_url`／`analyze_screen` の `module` を指定すると、実行可能なテスト（Playwright の `.py` または Maestro の `.yaml`）を生成します
`auto_generate_tests`	1回の操作で、URL を分析し、検出されたモジュールごとにテストを1つ生成します
`codegen`	Playwright codegen（Web）を起動します／`maestro studio`（モバイル）を案内します
`generate_html_report`	最新の実行結果を、自己完結型の HTML としてレンダリングします
`get_test_history`	アーカイブされた直近 N 件の実行概要を表示します（傾向分析／不安定なテストのデバッグ用）
`analyze_url`	Web：DOM を調査し、モジュール、セレクター、候補となる TC、API エンドポイント、レイアウトのはみ出しに関する警告を抽出します
`analyze_screen`	モバイル：`maestro hierarchy` を使って、フォーム／CTA／タブバーのモジュールと候補となる TC を抽出します（ノイズを除去）
`init_qa_knowledge` / `get_qa_context`	プロジェクトの QA ナレッジレイヤー（方法論＋ドメイン）を構成し、読み込みます。v0.6.2 からバイリンガル対応 — 方法論はデフォルトで英語（`QA_LANG=en`）、または繁体字中国語（`QA_LANG=zh-tw`）で提供されます。両言語で同じ13セクションがあり、追加された最新の4セクションでは、API テストの方法論、不安定さの根本原因の分類、テストダブル（モック／スタブ／フェイク／スパイ）、テストデータ管理を扱います。ドメインの例：`docs/qa-knowledge-en.example.md`（zh-TW： `docs/qa-knowledge.example.md`）。
`get_optimization_plan`	3層の自己改善コーチ（テストスイート／MCP／AI 戦略）
`inspect_visual_challenge` / `solve_visual_challenge`	v0.7.0 AI Visual Challenge Solver — reCAPTCHA v2 の画像グリッドチャレンジを検出してスクリーンショットを撮影し、AI クライアントによるタイルの選択を受け取り、クリック処理を実行します。`QA_VISUAL_CHALLENGE_CONSENT=true` と呼び出しごとの `confirm=true` が必要です。上記の専用セクションを参照してください。
`run_api_security_scan`	v0.8.0 OWASP API Security Top 10 (2023) のルールベーススキャナー — OpenAPI 3.x 仕様を読み込み、パス × メソッドを走査し、対象となる5つのルール（API1 BOLA、API2 Broken Auth、API3 Mass Assignment、API5 Function-Level Authz、API8 Misconfig）を適用します。`QA_API_SECURITY_CONSENT=true` と `QA_API_SECURITY_AUTHORIZED_DOMAINS` が必要です。上記の専用セクションを参照してください。

リソース

URI	内容
`report://html`	レンダリング済みの HTML レポート（ダークモード、自己完結型）
`report://json`	pytest-json-report の生の JSON
`report://optimization`	最新の `optimization-plan.md`

自己改善ループ

実行のたびに、_archive_report() が report.json のスナップショットを test-results/history/ に保存し、次の内容を含む最新の optimization-plan.md を書き込みます。

テストスイートの品質 — テストごとの結果文字列（PFPFP）。遷移から不安定度スコアを算出し、同一シグネチャの失敗が3回以上なら壊れていると判定し、再実行で成功した場合は実行中の不安定なテストとして記録します
MCP の使いやすさ — よく使われるツール、エラー率、引数の繰り返しパターン、よくある A→B の連鎖（テレメトリーの JSONL ログから取得）
AI 戦略 — generate_test の出力が採用された割合、対応するテストファイルがない analyze_url モジュールから特定したカバレッジの不足

計画では、優先度（high／medium／low）を付けたアクションが提示されます。各アクションには、対象、根拠、提案、および MCP クライアントが次のツール呼び出しに連鎖させられる任意の auto_action_hint が含まれます。

プロジェクト構成

mk-qa-master/
├── pyproject.toml
├── src/mk_qa_master/
│   ├── server.py            # MCP entry (tool routing + telemetry wrap)
│   ├── config.py            # Paths + env vars
│   ├── runners/             # Per-framework plugins
│   │   ├── base.py          # TestRunner abstract interface
│   │   ├── pytest_playwright.py
│   │   ├── jest.py
│   │   ├── cypress.py
│   │   └── go_test.py
│   ├── reporters/
│   │   └── html.py          # Self-contained HTML render
│   └── tools/               # Thin shims + analyzer + optimizer + telemetry
└── tests_project/           # Example project under test

ランナーの追加

src/mk_qa_master/runners/your_runner.py を作成し、TestRunner をサブクラス化して、抽象メソッドを実装します
runners/__init__.py の REGISTRY に名前を登録します
完了です

エンドツーエンドのワークフロー

URLから「次回は何を改善すべきか」までの想定パイプライン：

flowchart LR
    URL[URL] -->|analyze_url| MOD[modules<br/>+ candidate TCs<br/>+ API endpoints]
    MOD -->|generate_test<br/>module=...| TEST[tests/test_*.py<br/>runnable skeleton]
    TEST -->|run_tests| RES[report.json<br/>+ screenshots<br/>+ trace.zip<br/>+ junit.xml]
    RES -->|auto archive| HIST[history/ snapshot]
    RES -->|generate_html_report| HTML[HTML report<br/>self-contained]
    HIST -->|auto write| PLAN[optimization-plan.md]
    PLAN -.->|next session reads| URL

重要なのはこのループです。実行のたびにオプティマイザーに結果が送られ、オプティマイザーが最も弱い部分を特定し、次の実行ではまずそこをテストします。

ウォークスルー — ログインページのテスト

Claude / Cursor のセッションで：

あなた: https://shop.example/login を分析して、対応するテストを書いて

Claude: [analyze_url] フォーム（email_password_form_0）を1つ、APIエンドポイントを3つ検出しました。候補となるテストケースは5つです。 [フォームモジュールを使って generate_test] tests/test_login.py を作成しました。具体的なセレクターを使用してそのまま実行でき、# TODO の仮コードはありません。

あなた: 実行して

Claude: [run_tests] 23件成功、0件失敗、31秒で完了しました。すべてのテストでスクリーンショットとステップトレースを取得しました。

あなた: 次は何をすればいい？

Claude: [report://optimization を開く] 上位：tests/test_login.py::test_invalid_credentials が不安定です（flake_score=0.4、結果=PFPFP）。提案：エラーメッセージを検証する前に wait_for_response('/api/login') を追加してください。

3つのオプティマイザーの視点（テストスイートの品質／MCP の使いやすさ／AI 生成の効果）により、「次は何をすればいい？」への回答は勘ではなくデータに基づくものになります。

ウォークスルー — モバイルアプリのテスト（Maestro）

同じ流れで、実行ランナーが異なります。Maestro CLI のインストール、シミュレーター／エミュレーターの起動、およびアプリの起動が必要です（または app_id とともに launch_app=true を渡してください）。

あなた: モバイルアプリのホーム画面にあるバーコードボタンを分析して、対応するテストを書いて

Claude: [analyze_screen(app_id="com.example.app", launch_app=true)] 操作可能な要素を15個検出し、barcode_button（text="バーコード"、resource_id="barcodeButton"）と一致する要素、および候補となるテストケースを見つけました。 [cta モジュールを使って generate_test] maestro-flows/test_barcode.yaml を作成しました。tapOn: { id: barcodeButton } に waitForAnimationToEnd と takeScreenshot を組み合わせており、そのまま maestro test を実行できます。

あなた: 実行して

Claude: [run_tests] 5つのフローが成功し、再試行は発生しませんでした。スクリーンショットは HTML レポートに埋め込まれています。

あなた: 上のボタンが時々失敗するのはなぜ？

Claude: [get_optimization_plan] barcode_button::barcode_button は不安定としてフラグが付いています（flake_score=0.4、結果=PFPFP、rerun_count=1）。提案：タップする前にアニメーションが安定するまで、waitForAnimationToEnd または extendedWaitUntil を追加してください。

モバイル固有の注意事項：

同じ qa-knowledge.md（組み込みの方法論とドメイン情報）をウェブとモバイルの両方の実行で使用します。ビジネスルールは一度だけ記述すれば済みます。
analyze_screen は iOS のステータスバー（電波／Wi-Fi／バッテリー）とアセット名のラベル（bg_*、*_filled）を除外するため、関連性の高い結果が得られます。
Maestro の takeScreenshot: <name> ディレクティブによって、HTML レポートにインライン画像として表示する画面を指定できます。

プロンプト集

各行には、Claude / Cursor のセッションに貼り付けられるフレーズと、それによって実行される MCP ツール呼び出しを示しています。ツール名を自分で指定せずに AI に作業を依頼する方法を知るための参考にしてください。

初回のセットアップ

あなたが言うこと	Claude が呼び出すツール
"QA ナレッジファイルを初期化してください。"	`init_qa_knowledge` → プロジェクトのルートに `qa-knowledge.md` を作成
"現在の QA ナレッジを見せてください。"	`get_qa_context` → 方法論とドメイン情報のセクション
"ISTQB の原則のセクションを開いてください。"	`get_qa_context(section="ISTQB")`

日々のテスト

あなたが言うこと	Claude が呼び出すツール
"すべてのテストを実行してください。"	`run_tests`
"ログイン関連のテストだけを実行してください。"	`run_tests(filter="login")`
"失敗したテストだけを再実行してください。"	`run_failed`
"概要を見せてください。"	`get_test_report`
"どれが失敗しましたか？スクリーンショットとトレースもください。"	`get_failure_details`
"HTML レポートを生成してください。"	`generate_html_report`

URL からテストを作成する（Web）

ユーザーの指示	Claude の呼び出し
"`https://shop.example/` のテストを自動生成して。"	`auto_generate_tests(url=...)` — 一括処理
"まず `https://shop.example/coupon` を分析してから、モジュールごとにテストを1つ作成して。"	`analyze_url` → `generate_test` × N
"クーポンページを分析して、過去の冪等性バグの回帰テストを作成して。"	`get_qa_context(section="Bug")` → `analyze_url` → `generate_test(business_context=...)`
"チェックアウトのフローをベースラインとして記録するだけでいい。"	`codegen(url=...)`

モバイル画面からテストを作成する（Maestro）

QA_RUNNER=maestro、Maestro CLI、および起動済みのシミュレーター／エミュレーター／デバイスが必要です。

ユーザーの指示	Claude の呼び出し
"現在のモバイルアプリ画面を分析して、バーコードボタンのテストを作成して。"	`analyze_screen(app_id="com.example.app", launch_app=true)` → `generate_test(module=<cta>)`
"このアプリのログインフォームをテストして。"	`analyze_screen(launch_app=true)` → `form` モジュールを選択 → `generate_test`
"タブバーを網羅して。タブごとにフローを1つ作成して。"	`analyze_screen` → `tab_bar` モジュールを取得 → `generate_test`
"Maestro Studio を使ってフローを記録して。"	`codegen(url=...)` は `maestro studio` を示すヒントを返します（記録と保存は手動で行います）

BlueStacks／リモート Android インスタンス：QA_ANDROID_HOST=127.0.0.1:5555 を設定します（または BlueStacks が公開している host:port を指定します。Settings → Advanced → Android Debug Bridge を参照してください）。Maestro ランナーは各テストおよび analyze_screen の前に adb connect を実行し、遅い TCP-ADB 経路を考慮して hierarchy のタイムアウトを 60 秒に延長します。Genymotion／Nox／LDPlayer／WSA も同様に動作します。 adb connect に応答する host:port であれば使用できます。

継続的な改善

ユーザーの指示	Claude の呼び出し
"次は何を修正すればいい？"	`get_optimization_plan`
"`test_login_invalid` は最近不安定ですか？"	`get_test_history` + プランの検索
"なぜ失敗したの？トレースを見せて。"	`get_failure_details`（スクリーンショット／トレース／動画のパスを返します）

ヒント — Claude に適切なツールを選ばせる

QA ナレッジに明示的に言及する — 「クーポンのテストでは、QA ナレッジを参照して」と言うと、Claude は最初に get_qa_context を呼び出します。「クーポンをテストして」とだけ言うと、呼び出されないことがあります。
順序を指定する — 「まず分析してから作成して」と指定すると、generate_test の前に analyze_url が実行されます。「X のテストを作成して」だけでは、分析が省略されます。
一括処理か、個別指定か — 「ページ全体のテストを自動生成して」→ auto_generate_tests、「candidate_tc ごとにテストを1つ作成して」→ 手動で連続実行します。
失敗のデバッグ — 「なぜ失敗したの？／スクリーンショットを見せて」と尋ねると、確実に get_failure_details が呼び出されます（現在はスクリーンショット＋トレース＋動画のパスを返します）。

アンチパターン

❌ 「不安定かどうか確認するために5回実行して」— ランナーには自動再試行と履歴があります。「不安定ですか？」と尋ねて、get_optimization_plan に判断させてください。
❌ 「テストを100個生成して」— ノイズがシグナルを上回ります。まず get_optimization_plan を使って、不足しているものを確認してください。
❌ 「すべてのエッジケースをテストして」— 曖昧すぎます。「このフォームの candidate_tc をすべてテストして」と具体的かつ範囲を限定し、追跡できる形で指定してください。

出力例

`analyze_url`（抜粋）

{
  "url": "https://shop.example/login",
  "page_title": "Login",
  "module_count": 3,
  "modules": [
    {
      "kind": "form",
      "name": "email_password_form_0",
      "selectors": {
        "container": "#login",
        "fields": [
          {"label": "Email", "selector": "#email", "type": "email", "required": true},
          {"label": "Password", "selector": "#password", "type": "password", "required": true}
        ],
        "submit": "button[type='submit']"
      },
      "candidate_tcs": [
        "所有必填欄位為空時送出，應顯示必填錯誤",
        "Email 欄位填入格式錯誤的字串（無 @），應顯示格式錯誤",
        "Password 欄位輸入後應預設遮蔽（type=password）",
        "全部填入合法值後送出，應觸發成功流程"
      ]
    }
  ],
  "api_endpoints": [
    {
      "method": "POST",
      "path": "/api/login",
      "status": 401,
      "candidate_tcs": [
        "POST /api/login payload 缺必填欄位應回 400 + 欄位錯誤訊息",
        "POST /api/login 合法 payload 應回 2xx",
        "POST /api/login 缺少 auth header 應回 401/403"
      ]
    }
  ]
}

`generate_test` の出力（スマートモード、モジュール指定あり）

"""
Login happy path

Auto-generated from analyze_url module: email_password_form_0 (kind=form)
"""
from playwright.sync_api import Page, expect


def test_login(page: Page):
    page.goto('https://shop.example/login')
    page.locator('#email').fill('[email protected]')
    page.locator('#password').fill('TestPass123!')
    page.locator("button[type='submit']").click()
    # TC: Email 欄位填入格式錯誤的字串（無 @），應顯示格式錯誤
    # TC: Password 欄位輸入後應預設遮蔽
    # TC: 正確 Email + 正確密碼 → 導向 dashboard
    # TODO: 補上實際斷言，例如：
    # expect(page).to_have_url(...)
    # expect(page.get_by_text("成功")).to_be_visible()

`optimization-plan.md`（抜粋）

# Optimization Plan — 2026-05-12T14:03:40

_Based on 6 archived runs._

## Prioritized Actions

### 1. 🔴 HIGH — flaky
- **Target**: `tests/test_login.py::test_invalid_credentials`
- **Evidence**: flake_score=0.4, outcomes=PFPFP, rerun_count=1
- **Suggestion**: 加 explicit wait（wait_for_response / locator wait）

### 2. 🟡 MEDIUM — coverage_gap
- **Target**: `register_form`
- **Evidence**: 由 analyze_url 偵測但 repo 內找不到對應 test_*.py
- **Suggestion**: `call generate_test(description="...", filename="test_register_form.py")`

HTML レポート

ライブレンダリングデモを開く → （GitHub Pages 経由で配信 — GitHub の UI で sample_report.html へのリンクをクリックしても、ソースのみが表示されます）。

デモでは、統計グリッド、トレンドのスパークライン、スクリーンショットが埋め込まれた失敗カードとステップ一覧、折りたたまれた成功セクションを確認できます。

統合

mk-qa-master はサードパーティ製 SDK をバンドルせず、純粋なテスト実行・分析レイヤーに徹します。実際の QA ワークフローは、同じクライアント設定で複数の MCP サーバーを並行して実行し、 Claude がサーバー間の連携をオーケストレーションすることで構成されます。MCP サーバー間の RPC はなく、各サーバーは独立しており、AI クライアントが指揮役を担います。

特に多くの場合に一連の流れを完成させる組み合わせは次のとおりです。

組み合わせる相手	理由	連携の例
Atlassian MCP (JIRA + Confluence)	失敗時にバグチケットを自動作成し、`optimization-plan.md` をチームの Confluence ページと同期します	`run_tests` → `get_failure_details` → `atlassian.createJiraIssue` (スクリーンショット + トレースパスを添付)
Slack MCP	失敗時にチャンネルへ通知し、レンダリング済み HTML レポートを共有し、不安定なテストについてオンコール担当者にメンションします	`generate_html_report` → `slack.send_message(channel="#qa-bots", attachments=...)`
GitHub MCP	テストを生成する前に PR の説明や関連する issue を読み取り、ビジネス上の背景を把握します。結果は PR コメントとして投稿します	`github.get_pull_request` → `analyze_url` → `generate_test(business_context=PR body)` → `github.create_issue_comment`
Sentry MCP	本番環境のエラーを回帰テストの優先順位付けに活用します。頻度の高いクラッシュに対応する回帰テストを作成します	`sentry.list_issues(sort="frequency")` → `generate_test(business_context=stack trace)` → `run_tests`
Filesystem MCP	`QA_PROJECT_ROOT` の外部（モノレポやマルチプロジェクト構成など）にある共有の `qa-knowledge.md` や TC ソースファイルを読み取ります	`filesystem.read_file("~/shared/qa-knowledge.md")` → `init_qa_knowledge`

特別賞 — Google Drive MCP：Google スプレッドシートベースの TC 管理と組み合わせられます（シートから TC を読み取る → generate_test → ステータスを書き戻す）。

クライアント設定での構成

これら 5 つはすべて、mk-qa-master と並行して別々のプロセスとして実行します。

{
  "mcpServers": {
    "mk-qa-master": { "command": "python", "args": ["-m", "mk_qa_master.server"], "env": { "QA_RUNNER": "maestro" } },
    "atlassian":       { "command": "npx", "args": ["-y", "@atlassian/mcp"] },
    "slack":           { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-slack"] },
    "github":          { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"] }
  }
}

その後、1 つのプロンプトで一連の処理を実行できます。

「チェックアウトのテストスイートを実行してください。失敗ごとに、RIDER 形式でスクリーンショットを添付して、QA プロジェクトに JIRA を作成してください。完了したら、HTML レポートを #qa-bots に投稿してください。」

これが重要なのは、mk-qa-master がテストのサイクル（分析 → 生成 → 実行 → 改善提案）に集中できるためです。JIRA、Slack、Sentry はそれぞれ専用サーバーを持つ独立した領域です。これらを 1 つのサーバーに組み込むと、対象範囲がぼやけ、認証処理が重複し、必要としない依存関係までユーザー全員が引き継ぐことになります。

本リポジトリはサードパーティ製 SDK をバンドルせず、「テスト実行 + 分析」という単一の役割に徹します。実際の QA ワークフローは、複数の MCP サーバーを並行して実行し、Claude がサーバー間のツール連携をオーケストレーションすることで実現します。組み合わせの例として、JIRA、Slack、GitHub、Sentry、Filesystem の各 MCP サーバーをそれぞれ独立して動かし、mk-qa-master と連携させることで、テストパイプライン全体を構成できます。

公開（メンテナー専用）

リリースはTrusted Publishing経由で PyPI に公開されます。リポジトリに API トークンを保存する必要はありません。手順は以下のとおりです。

pyproject.toml の version = "x.y.z" を更新します（通常の PR で行います。main はブランチ保護されています）。

マージ後、main にタグを付けてプッシュします。

git tag -a vX.Y.Z -m "vX.Y.Z — short summary"
git push origin vX.Y.Z

そのタグの GitHub Release を作成します（gh release create vX.Y.Z ...）。
リリースイベントによって .github/workflows/publish.yml が実行され、sdist と wheel をビルドして PyPI にアップロードします。

PyPI の初回公開前に一度だけ行う設定：

https://pypi.org にサインインし、2FA を有効にします。
プロジェクトページ → Settings → Publishing → pending publisher を追加し、以下を設定します。
- Owner：kao273183
- Repository：mk-qa-master
- Workflow filename：publish.yml
- Environment name：pypi

初回の実行が成功すると、PyPI は pending publisher を信頼済みの publisher に自動昇格させます。以降のリリースでは OIDC 経由で認証されます。

リリースタグが pyproject.version と一致しない場合、ワークフローは公開を拒否します。これにより、「タグを付けたがバージョンを更新し忘れた」というミスを PyPI に公開する前に検出できます。

プロジェクトを支援する ☕

mk-qa-master は、夜間や週末に一人で開発・保守しています。時間の節約になった場合や、AI 主導の QA についてチームで考えるきっかけになった場合は、コーヒーの差し入れで深夜の Maestro デバッグを続ける力を貸してください。

ご支援は、リポジトリの無料提供と積極的な保守、Maestro テスト用のデバイスバリエーションの拡充（実機の iPhone／Android タブレット／BlueStacks）、QA コミュニティ向けの録画チュートリアル、そして次の午前2時のバグ探しに役立てられます。

広告も、スポンサーシップも、エンタープライズ向けのアップセルもありません。ただ、開発を続けるための支援です。

貢献

このリポジトリは一人で保守しています。アイデアやバグ報告を歓迎します。Issue を作成するか、Discussion を始めてください。すべて目を通し、プロジェクトの方向性に合うものを実装します。

外部からのプルリクエストは自動的にクローズされます。 貢献を歓迎していないからではありません。ここでは、複数のコントリビューターによる開発がもたらす作業量よりも、一貫した方針のもとでコードベースを保つことを重視しているためです。どうしても特定の変更を希望する場合は、問題を説明する Issue を作成してください。プルリクエストよりも、実現につながる可能性が高くなります。

このリポジトリは私一人で保守しています。アイデアや問題の報告は、Issue／Discussion で歓迎します。内容を確認し、実装します。外部からの PR は自動的にクローズされます——貢献を歓迎していないのではなく、コードのスタイルや方向性を一貫させるためです。

ライセンス

簡単に言うと、個人プロジェクト、商用利用、改変、再配布など、あらゆる用途に利用できます。配布するコピーには、著作権表示とライセンス表示を残してください。保証はありません。自己責任でご利用ください。

Markdown 対応

ログインしてコメント

MCP は初めてですか？

プロトコルの概要から最初のサーバーの導入まで、よくある疑問にまとめて答えます。

入門ガイドを読む

AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。

Ai 測試大師 / Mcp Test Runner

Ai 測試大師 / Mcp Test Runner について

主な機能

活用シーン

MCP 対応

設定

ツール

詳細

MK QA Master

同梱内容

インストール

A. uvx で実行（インストール不要。エンドユーザーに推奨）

B. プロジェクトの venv にインストール（コントリビューター／開発向け）

インストールを確認する（v1.4 以降）

ランナー固有の前提条件

API テスト（QA_RUNNER=schemathesis）

5 行の設定

環境変数

API テスト（QA_RUNNER=newman）

5 行の設定

環境変数

AI ビジュアルチャレンジソルバー（v0.7.0）

使うタイミング — Tier 1 と Tier 3

同意の確認

クイックスタート

ハードストップ対象のドメイン

プライバシー

成功率に関する注意

OWASP API Security のスキャン（v0.8.0）

同意と認可のゲート

クイックスタート

Tier 1 の正解データ

セキュリティに関する注意

Claude Code／Codex／Hermes／OpenClaw スキルとして使用する（v0.9.0）

クイックインストール（Claude Code）

スキルの機能

MCP サーバーに加えてスキルを使う理由

安定性の保証（v1.0.0）

呼び出し側にとっての意味

保証の適用方法

コントラクトを読む

ライセンス変更計画（v1.2.1 の発表）

変更内容

スケジュール

理由

エッジ AI ランナー（v1.1.0 以降）

クイックインストール

エンドツーエンドの手順

ベンダーホストに対する安全なデフォルト設定

レジリエンス注入（v1.3.0）

フェーズのステータス

トラブルシューティング

v1.0.0 から v1.1.x への移行

汎用の計画＋検証のブックエンド（v0.10.0）

Claude Desktop に接続する（従来の MCP のみの方法）

ランナー別スニペット

その他の MCP クライアント

ツールの一覧

リソース

自己改善ループ

プロジェクト構成

ランナーの追加

エンドツーエンドのワークフロー

ウォークスルー — ログインページのテスト

ウォークスルー — モバイルアプリのテスト（Maestro）

プロンプト集

初回のセットアップ

日々のテスト

URL からテストを作成する（Web）

モバイル画面からテストを作成する（Maestro）

継続的な改善

ヒント — Claude に適切なツールを選ばせる

アンチパターン

出力例

analyze_url（抜粋）

generate_test の出力（スマートモード、モジュール指定あり）

optimization-plan.md（抜粋）

HTML レポート

統合

クライアント設定での構成

A. `uvx` で実行（インストール不要。エンドユーザーに推奨）

API テスト（`QA_RUNNER=schemathesis`）

API テスト（`QA_RUNNER=newman`）

`analyze_url`（抜粋）

`generate_test` の出力（スマートモード、モジュール指定あり）

`optimization-plan.md`（抜粋）