ClaudeとQaseを連携する方法 — テストケース登録と実行結果の集計
Qase Test Managementは、テストケース・ラン・結果・不具合をClaudeから読み書きできるコネクタです。接続方法の選び方、仕様書からのケース登録、実行結果の集計、つまずきやすい点をまとめます。
Claude Qase連携でできること
Qase Test Managementは、テスト管理サービスQaseが提供するコネクタです。Claudeのコネクタ一覧には2026年8月に追加され、「Anthropic verified」の表示が付いています。テストケース、ラン(実行単位)、プラン、スイート、環境、マイルストーンを会話から扱えます。
中身はQase MCP Serverです。自然言語の指示でテストケース・ラン・結果・不具合・スイート・マイルストーン・環境を読み書きでき、独自のクエリ言語QQL(Qase Query Language)で横断検索もできます。
コネクタ一覧に載っているツールは次の13個です。
| ツール | 役割 |
|---|---|
qase_project_context | 役割プロジェクトの構造(スイート・マイルストーン・環境・カスタムフィールド・ユーザー)を1回で取得 |
qase_get | 役割種類とIDを指定して1件取得 |
qql_search / qql_help | 役割QQLで検索 / QQLの文法を引く |
qase_case_upsert | 役割テストケースの作成・更新 |
qase_run_upsert | 役割ランの作成・更新 |
qase_result_record | 役割ランに結果を記録 |
qase_defect_upsert | 役割不具合の作成・更新 |
qase_ci_report | 役割ランの作成から結果記録、完了までを1回で実行 |
qase_regression_run | 役割回帰テスト用のランを1回で組む |
qase_triage_defect | 役割失敗した結果から不具合を起票 |
qase_api | 役割専用ツールの無いエンドポイントを直接呼ぶ |
qase_discover_tools | 役割隠れているツールを探して有効化 |
Qaseの開発者向け資料では、v2のツール総数は41個で、接続時に一覧へ出るのはそのうち17個です。残り24個は削除系やレビュー系などで、qase_discover_toolsで有効化するまで隠れています。
接続方法は契約プランで分かれる
Qaseの資料は接続方法を2つに分けています。ここを先に決めないと、接続できたのに全部の呼び出しが断られる状況になります。
Qase MCPの2つの接続方法
ホスト型(Qaseが運用)
URLはhttps://mcp.qase.io/mcp。Qaseのログイン(OAuth)だけで使え、インストールもAPIトークンも要りません。専用クラウド環境のEnterpriseは対象外で、自己運用側を使います。
自己運用(手元で起動)
Node.jsと自分のAPIトークンで@qase/mcp-serverを動かします。Enterpriseの専用クラウド環境でもこちらです。トークンは、作成した本人と同じ権限を持ちます。
Enterprise以外でホスト型に接続すると、サインインは通り、ツール一覧も表示されます。それでも呼び出しはすべて拒否されます。エラーには契約プランが示されますが、クライアントによっては権限不足とも表示され、この部分は不正確とQaseの資料にあります。
Claudeのコネクタ一覧に載る「Qase Test Management」がどちらの接続先を使うかは、コネクタのページにもQase側の資料にも書かれていません。Qaseの資料は、公式コネクタを更新中として、当面はカスタムコネクタの作成手順を案内しています。Enterprise以外の契約なら、次の自己運用が確実です。
Claude Codeに自己運用のMCPを追加する
手元のClaude Codeに足す場合は、claude mcp addで登録します。APIトークンはQaseの画面で、Settings → API tokensから発行します。
export QASE_API_TOKEN=your_api_token_here
claude mcp add qase -- npx -y @qase/mcp-server
# プロジェクトで共有するなら --scope project、
# 自分の全プロジェクトで使うなら --scope user
claude mcp add --scope project qase -- npx -y @qase/mcp-server登録後は「List all my Qase projects」のように聞けば、接続の疎通を確かめられます。追加が管理設定で止まる場合は、claude mcp addが失敗する原因を参照してください。
手元のサーバーはトークンを環境変数で受け取るため、設定ファイルをリポジトリに置く運用ではトークンの値を書かない形にしてください。
仕様書からテストケースを登録する
ケース登録の流れは、構造を読む、案を作る、登録する、の3段です。最初にqase_project_contextを呼ぶと、スイート階層・マイルストーン・環境・カスタムフィールドが一度に返ります。この結果は5分間キャッシュされ、各コレクションは既定で先頭100件までです。Qaseの資料も、プロジェクトに着手するときの最初の呼び出しとして勧めています。
プロンプトの例です(Qase側の例文に沿った形で、プロジェクトコードDEMOは仮の値です)。
プロジェクトDEMOのスイート構成を確認して。
そのうえで、貼り付けたログイン仕様書から、
スイート「認証」に入れるテストケース案を表で出して。
私が承認した行だけ、優先度つきで登録して。承認を挟むのが要点です。Claudeが起こした案をそのまま書き込むと、重複や的外れなケースがプロジェクトに残ります。表で出させて、登録は人が通した行だけに絞る運用なら、後から消す手間が減ります。
登録に使うツールは次のとおりです。
- 1件ずつ:
qase_case_upsert。idを渡すと更新、省くと新規作成になります。優先度や重要度は"high"・"blocker"のようなラベルでも数値IDでも渡せます。 - まとめて:
qase_case_bulk_create。一度に最大100件で、作成専用です。更新はqase_case_upsertにidを渡します。 - 共通手順:共有ステップのハッシュを
sharedに渡すと、ケースのステップに差し込めます。
仕様書の改訂で既存ケースを直すときは、まずQQLかIDで対象を特定し、idつきで更新します。新規作成を繰り返すと、同じケースが増えます。
実行結果を記録して集計する
回帰テストの準備はqase_regression_runが1回で済ませます。スイートID、ケースID、プランIDのいずれかで対象を選び、ランを作って該当ケースを入れます。結果の記録はqase_result_recordで、ステータスはpassed・failed・blocked・skipped・invalidの5種です。
件数の上限に差があります。
結果を送るときの上限
qase_result_record
200件
1回の呼び出し。超えると書き込み前に拒否
qase_ci_report
2,000件
自動で分割して送る
qase_case_bulk_create
100件
1回のケース作成
qase_result_recordが200件超を自動分割しない理由は、結果が追記専用だからです。途中で失敗した束を巻き戻せず、再試行で先頭200件が二重に入ると、合格率が狂います。完了済みの実行結果をまとめて入れるなら、分割まで面倒を見るqase_ci_reportのほうが安全です。途中で失敗した場合、エラーに作成済みのランと届いた件数が出ます。残りはqase_result_recordで足し、同じ呼び出しを繰り返さないようにします。ランが2つできてしまうためです。
集計は、ランを開く代わりにQQLで聞けます。件数を数えるときは行を取らず、SELECT (COUNT(id))で集計する形が推奨されています。SELECTは条件より前に書きます。フィールド名はエンティティごとに違うため、未知のエンティティは先にqql_helpのentitiesを引きます。たとえば「直近7日の失敗結果を探して」といった頼み方がQaseの例文にあります。
失敗した結果を不具合にする
失敗の起票にはqase_triage_defectを使います。必須はtitle・actual_result・severityの3つで、重要度はblocker・critical・major・normal・minor・trivial・undefinedから選びます。
注意点が1つあります。APIには、不具合へランや結果を紐づける手段がありません。ランや結果の配列は、テストランナーが結果を不具合つきで報告したときに埋まる仕組みです。そのため、どの失敗が原因かはactual_resultに書いて参照させます。「ラン42の結果をもとに」と書き込ませる指示にしておくと、後から辿れます。
不具合の状態変更はqase_defect_upsertで、statusをresolvedにすると解決済みになります。取りうる状態はopen・in_progress・resolved・invalidです。
Qaseは、失敗の仕分けと不具合の起票までを進めるQuality Supervisorというプラグインも用意しています。Claude CodeやClaude Desktop、Coworkなどで動き、MITライセンスで無料です。削除操作を持たず、書き込みは確認を待つ作りです。MCPサーバーだけでも読み書きはできるので、必要になってから足せば足ります。
つまずきやすい点
落とし穴
削除が確認なしに拒否される
Qase MCPの削除はすべて、MCPのelicitation機能で利用者に確認を取ってから実行されます。クライアントがこの機能に対応していないと、削除はQaseに届く前に拒否されます。Claude CodeのVS Code拡張でのelicitationの扱いは、自動辞退される不具合の記事にあります。qase_api経由でも同じです。その場合はQaseのWeb画面で削除します。
- 期待したツールが無い:削除、テストプラン、マイルストーン、環境、共有ステップ、カスタムフィールド、レビュー系は最初は隠れています。「milestone」「delete」などの語で
qase_discover_toolsを呼ぶと有効化されます。それでも呼べないときは、クライアントがツール一覧を作り直していません。自己運用ならnpm update -g @qase/mcp-serverで2.6.0以降にし、新しいセッションを始めます。 - レビューの承認はできない:テストケースのレビュー機能では、提案の作成と更新まではツールで行えます。承認、変更依頼、マージ、却下にはAPIがなく、Qaseの画面だけの操作です。また、プロジェクト設定で「Test case review」を有効にしておく必要があります。
- ファイルは添付できない:
qase_apiはJSONしか送れず、ファイルのアップロードに必要なmultipart/form-dataは扱えません。 - APIでできることとMCPでできることが食い違う:Qaseの資料は、原因を「ホスト型がEnterprise限定」「削除に確認が要る」「ツールが隠れている」のどれかとしています。ロールやライセンス種別は原因になりません。
データの流れと権限
MCP経由の変更は、画面から手で変えたのと同じ権限で動き、Qaseの画面に表れます。Enterpriseでは監査ログにも残ります。テストデータの正本はQaseに残りますが、質問のために取得した結果は、クライアントが使うAIモデルに、そのモデル提供元の規約のもとで送られます。
Claudeのコネクタ全般の権限や管理の考え方は、Connectorsの総合ガイドにあります。契約書やコンプライアンスなど、別の業務システムを同じ作法で繋ぐ例には、Ironcladの契約管理やDrataのコンプライアンス管理があります。Hooksと組み合わせてテストの差分を見張る例は、ChromaticのPR差分検知が近い構成です。
まとめ
接続の選択肢は、契約プランで先に決まります。Enterpriseならホスト型、それ以外は@qase/mcp-serverを手元で動かす形です。運用の型は、構造を読み、ケース案を表で出させ、承認した行だけ登録し、結果はqase_ci_reportで一括記録し、集計はQQLで聞く流れです。
削除の確認、隠れたツール、レビューの承認不可の3点を知っていれば、初回の接続でつまずく場所はほぼ見当がつきます。