qa-dashboard

データを表示するだけでなく、意思決定につながるダッシュボードを構築します。これにより、「5 件失敗」と表示されたパネルが並んでいるのに、失敗へのリンクも、目標値も、傾向もないという失敗パターンを防ぎます。これはツールを装った通知にすぎず、3 週目には誰も開かなくなります。このスキルでは、対象者に合わせた QA レポートを提供します。リッチな HTML レポート（Allure）、リグレッションアラート付きのリアルタイム傾向パネル（Grafana/InfluxDB）、セルフホスト型の AI 支援集約（ReportPortal）、関係者向けの自動サマリーを用意します。各パネルは実際に尋ねられる質問に対応し、赤い指標はすべて失敗したテストにドリルダウンできるようにします。

クイックルート

状況	移動先
インフラ指標に Grafana をすでに利用している	Grafana ダッシュボード — 本番環境の指標と並べてテスト指標を追加
テストランナーにホスト型ダッシュボードがある（Cypress/Playwright）	SaaS ネイティブダッシュボード — 準備作業が最小限
同梱の QA ランナーからローカルのエビデンスレポートが必要	ローカル QA レポート
既存の Allure アダプターからリッチな HTML を生成したい	Allure レポート
フレームワークをまたいだセルフホスト型の集約と AI トリアージが必要	ReportPortal
複数のランナーを横断する単一のビューが必要	Grafana または Allure（ランナー横断の集約）
関係者向けの週次サマリー／リリース判定が必要	関係者向けレポート

---

確認事項

最初に .agents/qa-project-context.md を確認してください。存在する場合はその内容を使用し、そこで回答済みの項目はスキップします。その後、次を確認します。

1. 現在、テストレポートにはどのツールを使っていますか？ コンソール出力、JUnit XML、HTML レポート、専用プラットフォームのどれですか？開始地点と、残っている準備作業を把握できます。
2. 誰がダッシュボードを見ますか？ 開発者には失敗の詳細とトレースが必要です。QA リードには傾向と不安定さが必要です。経営陣にはリリースの確実性と不具合率が必要です。対象者ごとに異なるビューが必要です。
3. ダッシュボードをどのような意思決定につなげますか？ 「このビルドは安全にリリースできるか？」「どのテストを修正する必要があるか？」「スプリントごとに品質は向上しているか？」意思決定の文脈がないダッシュボードは、使われないままになります。
4. テスト結果はどこに保存されていますか？ GitHub Actions のアーティファクト、S3、データベースなどですか？保存場所によって、実用的なダッシュボードツールが決まります。
5. 使用している CI プラットフォームは何ですか？ GitHub Actions、GitLab CI、Jenkins のどれですか？それぞれ、アーティファクトやレポートの連携方法が異なります。

---

基本原則

1. ダッシュボードは質問に答えるものであり、数値を表示するだけのものではありません。 各パネルは、実際に尋ねられる質問に対応している必要があります。「不安定さの発生率は？」は質問です。「テスト総数」は単なる豆知識です。

2. 対象者ごとに異なるビューが必要です。 CI の失敗をデバッグする開発者には、スタックトレース、スクリーンショット、トレースが必要です。VP に必要なのは、「リリースの準備はできているか？」という単一の指標です。両者に同じダッシュボードを使わせないでください。

3. CI にはリアルタイムの情報を、経営陣には傾向を提示します。 CI ダッシュボードはパイプラインの実行ごとに更新します。経営陣向けのダッシュボードは週次またはスプリント単位で集約します。更新頻度を混在させると、どちらの対象者も混乱します。

4. アクションにつながる詳細へドリルダウンできるようにします。 赤い指標はすべて、具体的に失敗したテスト、不安定なテスト、またはカバレッジの不足箇所にリンクしている必要があります。「5 件失敗」と表示するだけで失敗箇所へのリンクがないダッシュボードは、通知であってツールではありません。

5. レポート生成を自動化します。 手作業（スクリプトの実行、データのコピー、スライドの整形）が必要なレポートは、最初の多忙なスプリントで使われなくなります。CI パイプラインからレポートを自動生成してください。

---

ローカル QA レポート

QA Skills のチェックアウト全体を使用するプロジェクトでは、次を実行します。 node <qa-skills>/scripts/qa.mjs run --project <project> --goal "<current QA task>"。 生成された report.html を開き、機械可読な判定には result.json を使用します。 レポートには、スキルのルーティング、対象とソースのコンテキスト、各チェックの証拠、次のステップが含まれます。レポートを共有する際は、関連するログと証拠ディレクトリも保持してください。

失敗、ブロック、不完全、スキップされた作業も残してください。テストを実行したことが確認できない状態で終了コードがゼロでも、テストスイートが合格したことにはなりません。不足している証拠をエージェントの説明で置き換えないでください。失敗した実行も調査できるよう、if: always() を指定して実行ディレクトリを CI アーティファクトとして公開してください。設定と保持については、リポジトリの docs/QA-RUNNER.md を参照してください。

Allure レポート

Allure は、履歴、カテゴリ、リトライを組み込んだテスト結果から、詳細な HTML レポートを生成します。Playwright、Jest、Vitest、pytest など、ほとんどのフレームワークで動作します。

Allure 2 と Allure 3。 2 つの方法があり、フレームワークアダプター（allure-playwright、allure-vitest、allure-jest）が同じ Allure 2 の結果ファイルを出力するため、混同しやすくなっています。異なるのは読み取り側だけです。

• Allure 2 の方法 — allure-commandline（2.42.1、2026 年 6 月）。brew install allure でインストールされるのは v3 ではなく、こちらです。コマンド：allure generate / allure open / allure serve。カテゴリは allure-results/ に配置する categories.json で設定します。安定しており、機能は固定され、現在は依存関係の更新のみが行われています。
• Allure 3 の方法 — allure npm パッケージと allurerc.mjs（3.9.0、2026 年 5 月）。TypeScript で書き直されており、プラグイン、単一ファイルの設定、リアルタイムの allure watch、プロジェクト全体の品質ゲート、複数環境のレポート、サーバー側の履歴を管理する Allure Service を利用できます。コマンド：npx allure run / npx allure generate / npx allure watch。カテゴリは allurerc.mjs に移されており、配置する categories.json は v2 の仕組みです。

新規プロジェクトでは Allure 3 を選んでください。brew install allure / allure generate コマンドだけを使う場合は v2 の方法になります。これは問題なく、完全にサポートされていますが、どちらを実行しているか把握しておいてください。

Allure Playwright 3.x アダプターでは、レポーターのエントリ内に resultsDir と environmentInfo を登録し、各実行の生の結果が設定済みのディレクトリに書き込まれるようにしてください。 アダプターの設定を参照してください。

// playwright.config.ts
reporter: [
  ["list"],
  ["allure-playwright", {
    resultsDir: "allure-results",
    environmentInfo: {
      Environment: process.env.TEST_ENV ?? "local",
      BaseURL: process.env.BASE_URL ?? "http://localhost:3000",
    },
  }],
],

テストごとにメタデータ（allure.severity / feature / story / tag）を追加してグループ化を行い、失敗のcategoriesを定義して製品のバグとインフラの障害を分け、CI の実行間で history/ を保持して傾向を確認できるようにしてください。履歴がなければ、Allure レポートは単一のスナップショットにすぎず、傾向の把握も断続的な失敗の検出もできません。 Playwright/Vitest の完全な設定、v2 の categories.json、v3 の allurerc.mjs と実行可能な allure run の方法、GitHub Actions で履歴を保持する手順については、references/allure.md を参照してください。

---

Grafana ダッシュボード

Grafana では、アラート機能を備えたリアルタイムのダッシュボードを利用できます。チームがすでにインフラストラクチャ向けに Grafana を運用しており、テストのメトリクスを本番環境のメトリクスと並べて確認したい場合に最適です。

データパイプライン： テスト後の CI ステップで結果（JUnit XML、カバレッジ JSON、実行時間）を解析し、時系列データベース（InfluxDB または Prometheus pushgateway）にデータポイントを送信して、Grafana からクエリします。プッシュスクリプトは 2 つの測定値を書き込みます。test_execution（テストごとに 1 つのデータポイント。suite / test_name / status / branch / run_id でタグ付け）と test_run_summary（実行ごとに 1 つのデータポイント。pass_rate、total、failed、avg_duration_ms を含む）です。すべてのデータポイントに branch と run_id のタグを付けると、パネルで main に絞り込んだり、特定の実行にリンクしたりできます。

このスクリプトは if: always() のもとで実行されるため、書き込みループを try/flush/close で囲んでください。そうしないと、ループの途中で例外が発生した際に、バッファー内のすべてのデータポイントが失われます。flush のガードを含む完全な push-test-metrics.ts と GitHub Actions のステップについては、references/grafana.md を参照してください。

推奨パネル

パネル	質問	クエリの形式
合格率の推移（時系列）	品質は向上していますか？	SELECT mean("pass_rate") FROM "test_run_summary" WHERE "branch"='main' GROUP BY time(1d)、しきい値は95％（黄色）／99％（緑色）
リリース準備状況（統計）	main はリリース可能な状態ですか？	SELECT last("pass_rate") FROM "test_run_summary" WHERE "branch"='main'、95未満は赤、95～99は黄色、99以上は緑 — カバレッジ80以上の統計パネルと組み合わせます
不安定なテストの上位10件（テーブル）	最も時間を浪費しているテストはどれですか？	SELECT "test_name", count("retries") AS retry_count FROM "test_execution" WHERE "retries">0 AND time>now()-14d GROUP BY "test_name" ORDER BY retry_count DESC LIMIT 10
CI 実行時間の推移	パイプラインの実行時間は長くなっていますか？	時間の経過に伴う avg_duration_ms を、600秒の目標線とともに表示します

クエリ全文に加え、「カバレッジの推移」と「実行時間の分布」パネルについては、references/grafana.md を参照してください。

アラート

アラートルールは provisioning/alerting/ の下に YAML 形式でプロビジョニングします（Grafana 11+）。Done When で必須となるのは、main の合格率が1日で2パーセントポイントを超えて低下することです。2つのクエリ（直近 1d の pass_rate の平均と、その前日の平均）から数式 $yesterday - $today > 2 を作成し、Slack のコンタクトポイント（incoming-webhook URL）経由でルーティングします。プロビジョニング済みのルールとコンタクトポイントの全容は、references/grafana.md にあります。次の項目についてもアラートを設定してください。合格率が95％を下回る（10m の時間枠）、CI の実行時間が15分を超える、1週間でカバレッジが2％を超えて低下する。ダッシュボードは調査用、アラートは検知用です。誰も開かないダッシュボードでは何も検知できません。

---

ReportPortal

ML を活用した失敗分析、フレームワーク横断の集計、リアルタイムダッシュボードを備えた、セルフホスト可能なテストレポートプラットフォームです。

# Pin to a tagged release (current 26.0.x line: 26.0.3). The `master` branch may not
# match the supported 26.x line.
curl -LO https://raw.githubusercontent.com/reportportal/reportportal/26.0.3/docker-compose.yml
docker compose up -d
# Access at http://localhost:8080 (default: superadmin/erebus)
# ML auto-analysis lives in the `service-auto-analyzer` container — confirm it is running.

26.0.3 以降、ReportPortal は エージェント型テスト結果も取り込めます（launch には AGENTIC と AUTOMATION の実行タイプを示すバッジが付きます）。テストスイートの一部が Claude Code や別のエージェントを介して実行される場合に関係します。

Playwright との連携

// playwright.config.ts
reporter: [
  ["list"],
  ["@reportportal/agent-js-playwright", {
    apiKey: process.env.RP_API_KEY,
    endpoint: process.env.RP_ENDPOINT ?? "http://localhost:8080/api/v1",
    project: "my-project",
    launch: `E2E Tests - ${process.env.CI ? "CI" : "local"}`,
    attributes: [
      { key: "branch", value: process.env.GITHUB_HEAD_REF ?? "local" },
      { key: "build", value: process.env.GITHUB_RUN_ID ?? "dev" },
    ],
  }],
],

npm i -D @reportportal/agent-js-playwright でインストールします。

機能	内容
自動分析	ML による失敗分類：製品のバグ、テストのバグ、システムの問題、または調査対象
不具合タイプのマッピング	プロジェクト向けのサブタイプを含む、カスタムの不具合カテゴリ
不安定なテストの検出	launch 間で合格／不合格が入れ替わるテスト
launch の統合	シャーディングされた CI 実行を1つの統合ビューにまとめます
品質ゲート	launch ごとの合格／不合格基準（最大失敗数、最小合格率）
比較	2つの launch を並べて、リグレッションを特定します

品質ゲートは実行後に照会できます（GET /api/v1/$PROJECT/launch/$LAUNCH_ID/quality-gate）。ステータスを CI ゲートとして使い、PASSED でない場合はパイプラインを失敗させてください。

Allure TestOps（マネージド型の代替）

セルフホストの負担が大きい場合、Allure TestOps（2026年の26.2.x 系列）は SaaS の選択肢です。Allure 3 の品質ゲート、名前付き環境、グローバル添付ファイル、そして Allure 3 形式の不安定なテスト検出（直近10回の実行でステータス遷移が3回以上発生したテストにフラグを付けます）を備えています。同製品の **MCP サーバーはパブリックベータ版（26.1.1）**で、AI エージェントが launch と品質ゲートを直接照会できます。QA ワークフローが Claude Code や Cursor を介して実行される場合に関係します。

SaaS ネイティブのテストダッシュボード

テストランナーに専用のホスト型ダッシュボードがある場合は、そのランナー固有のデータには Allure/Grafana よりもそちらを優先してください。配線の手間が減り、データの保持期間が長く、PR コメント機能も組み込まれています。複数のランナーを横断して集計する場合にのみ、Allure/Grafana と組み合わせてください。

プラットフォーム	テストランナー	ネイティブデータと PR コメント
Cypress Cloud	Cypress	テストリプレイ、並列化、フレーク検出、AI アドオン（Auto Heal、Bug Triage）
Currents.dev	Cypress、Playwright	OSS に適した Cypress Cloud の代替サービス。価格も低め
Playwright HTML + --reporter=blob	Playwright	無料、セルフホスト可能。merge-reports でシャードを結合
Datadog Test Optimization	任意（CI 側）	Flaky Test Management（Bits AI による自動修正に対応）、TIA、ネイティブ APM
Allure TestOps	任意	Allure 3 の品質ゲート、名前付き環境、MCP サーバーのベータ版

シャード化された Playwright の実行を結合する（無料、ネイティブ）。 各シャードで blob レポートを出力してから、1 つの HTML レポートに結合します。これは「シャード化された CI の実行を結合する」ための無料の方法です。

# each shard: npx playwright test --reporter=blob   (uploads blob-report/ as an artifact)
npx playwright merge-reports --reporter html ./blob-reports

複数のランナーをまたぐ 1 つのダッシュボードが必要な場合や、SaaS オプションの料金やデータレジデンシーが要件に合わない場合は、Allure または Grafana を使用してください。それ以外の場合、SaaS ネイティブのダッシュボードが PR レベルのシグナルを得る最も安価な方法であることがほとんどです。

---

ステークホルダー向けレポート

週次 QA サマリー — スケジュールされた CI ジョブで自動化します。合格率と推移、新規失敗と修正済み失敗、フレークの多いテスト上位 5 件、カバレッジの差分、平均 CI 実行時間を含めます。状態を分類します：STABLE（>= 98%）、NEEDS ATTENTION（>= 95%）、CRITICAL（< 95%）。Slack に自動投稿します。

リリース品質レポート — 各リリース前に生成します。E2E 合格率 >= 99%、ユニットテスト合格率 100%、ブランチカバレッジ >= 80%、重大なバグがゼロ、重大度の高いバグが 2 件以下、Core Web Vitals の予算をゲート条件とします。ゲートごとの合否内訳を添えて、READY / NOT READY の判定を出力します。

パフォーマンスゲートにおける Core Web Vitals の「良好」なしきい値（2026 年現在）：LCP < 2500ms、INP < 200ms、CLS < 0.1。 FID ではなく INP をゲート条件にしてください。INP は 2024-03-12 に Core Web Vital として FID に取って代わり、FID は 2024-09-09 に完全に廃止されました。

---

推奨ダッシュボードパネル

チームからよく寄せられる質問のほとんどをカバーする、実用的な構成です。

パネル	答える質問	データソース	対象者
合格／失敗の推移	品質は向上していますか、それとも低下していますか？	時系列の CI テスト結果	全員
フレークの多いテスト上位 10 件	最も時間を浪費しているテストはどれですか？	過去 14 日間に再試行されたテスト	開発者、QA
カバレッジヒートマップ	どこを把握できていませんか？	モジュール／ディレクトリ別カバレッジ	開発者
不具合流出の推移	バグが本番環境に到達していますか？	テストで検出できなかった不具合としてタグ付けされたインシデント	QA リード、経営陣
CI 実行時間	パイプラインの実行は遅くなっていますか？	時系列のパイプライン実行時間	DevOps、開発者
テスト追加速度	機能の追加に比例してテストも増えていますか？	スプリントごとに追加された新しいテスト	QA リード
失敗カテゴリ	製品のバグですか、それともテスト基盤の問題ですか？	分類済みの失敗理由	QA リード
リリース準備状況	リリースできますか？	すべてのゲートから算出した総合スコア	経営陣

---

アンチパターン

30個のパネルがあるダッシュボード。 誰も読みません。最も緊急性の高い質問に答える5～6個のパネルから始め、ダッシュボードで答えられない質問が出てからパネルを追加します。

背景情報のないメトリクス。 「合格率：97％」だけでは、「目標：99％」「先週：98.5％」がなければ意味がありません。メトリクスをアクションにつなげるには、すべてに目標値と傾向を示す必要があります。

レポートの手動生成。 週次サマリーの作成に、誰かが SSH で接続してクエリを実行し、結果をスライドに貼り付ける必要があるなら、3週目までには作成されなくなります。CI に組み込んで自動化しましょう。

開発者と経営層で同じダッシュボードを使う。 開発者には失敗の詳細、スタックトレース、再現手順が必要ですが、経営層に必要なのは信号機のような表示ひとつです。別々のビューを作成しましょう。

テスト数を進捗として報告する。 「テストを200件追加しました」だけでは、品質は分かりません。代わりに、クリティカルパスのカバレッジ、欠陥流出率、リグレッション検出までの平均時間を報告しましょう。

リグレッションのアラートがない。 誰も確認しないダッシュボードは役に立ちません。合格率の低下、カバレッジの減少、CI 実行時間の増加をアラートで通知しましょう。ダッシュボードは調査に、アラートは検知に使います。

履歴のない Allure。 Allure レポートが1つだけではスナップショットにすぎません。傾向も、断続的な失敗の検出も、改善の測定もできません。CI の実行をまたいで history/ を必ず保持するか、サーバー側で履歴を管理する Allure 3 または Allure Service を使用してください。

Allure 2 と 3 のコードパスを混在させる。 説明文では v3 の案内に従っているのに、brew install allure ＋ allure generate ＋配置しただけの categories.json をコピーすると、v2 と v2 用のカテゴリーを使うことになります。どちらか一方を選び、最後までそのコマンドを使用してください。

---

検証

完了とする前に、レポート／ダッシュボードが実際に表示されることを確認してください。まずは最小限のチェックから行います。

# Allure: a report builds and the trend widget shows >1 run (history preserved)
npx allure generate allure-results --clean -o allure-report && npx allure open allure-report
#   -> Overview page loads; the "Trend" widget shows more than one run.

# Grafana push: the summary point landed in InfluxDB
influx query 'from(bucket:"test-results") |> range(start:-1d) |> filter(fn:(r)=> r._measurement=="test_run_summary")'
#   -> returns at least one row with a pass_rate field for branch=main.

# Grafana alert: the provisioned rule loaded
curl -s http://localhost:3000/api/v1/provisioning/alert-rules -u admin:admin | jq '.[].title'
#   -> includes "Main pass rate dropped >2pp in a day".

---

完了条件

• ダッシュボードが既知の場所に公開され、チームが HTTP 200 を受け取れること（CI アーティファクトの URL、Grafana の URL、またはホスト型 SaaS のリンク）。ローカル環境のセットアップやレポートの手動実行は不要です。
• テスト実行の傾向（合格率、失敗数、実行時間）が、少なくとも2週間分の履歴データにわたって確認できること。
• ローリング14日間の再試行回数とともに、フレーキーテストの上位テストを表示するフレーキーネスパネルが設定されていること。
• ステークホルダーレポートのテンプレートが自動生成されること。次のいずれかを満たすこと：STABLE／NEEDS ATTENTION／CRITICAL のヘルスラベル付き週次サマリー、または READY／NOT READY の判定とゲートごとの内訳を含むリリース単位の品質レポート（どちらか一方、または両方で可）。
• メインブランチの合格率が1日で2パーセントポイントを超えて低下した場合に通知されるアラートが設定され、Slack または同等のサービスにルーティングされていること。

関連スキル

• qa-metrics — 品質 KPI、測定フレームワーク、メトリクスの解釈を定義します。何を測定するかを決めるにはこちらを、測定結果を可視化するにはこのスキルを使用してください。
• ci-cd-integration — レポート生成とアーティファクト管理を自動化するためのパイプライン設定です。
• ai-bug-triage — ダッシュボードの失敗カテゴリーに反映する、AI を活用した失敗の分類です。

参考ファイル（references/ 内）

• allure.md — Playwright／Vitest アダプターの完全な設定、テストごとのメタデータ、v2 の categories.json、v3 の allurerc.mjs ＋ allure run による実行可能な手順、CI で履歴を保持するワークフロー。
• grafana.md — push-test-metrics.ts スクリプト（フラッシュガード付き）、すべてのパネルクエリ、プロビジョニング済みの「>2pp pass-rate drop」アラートルールと Slack の連絡先。