QA Radar

QA Radar

AI コーディングエージェントに、一から育てる必要のない品質判断力を与えます。

QA Radar はコードベースを分析し、構造化された品質ヘルスレポートを作成します。Git の変更頻度、テストカバレッジ、テストとソースのマッピングを組み合わせ、リスクスコア付きのモジュールを提示します。AI コーディングエージェント（Claude Code、Cursor、Windsurf）向けの MCP サーバー としても、人間や CI パイプライン向けの スタンドアロン CLI としても利用できます。

汎用的なテストではなく、的を絞ったテストを AI エージェントに書かせたい開発者のために作られています。

クイックスタート

Claude Code — 1 ステップ：

/plugin marketplace add Muratkus/qaradar
/plugin install qaradar@qaradar-marketplace

次に、エージェントに 「最初に何をテストすべきですか？」 と尋ねてください。

または、インストールせずに直接実行します：

uvx qaradar serve

インストール方法の全一覧 ↓

できること

QA Radar は、新しいチームメンバー（およびすべての AI エージェント）が必ず尋ねる質問、「最初に何をテストすべきですか？」 に答えます。

3 つのシグナルをスキャンして組み合わせ、ファイルごとのリスクスコアを算出します：

シグナル	測定内容	重要な理由
Git の変更頻度	コミット頻度、変更行数、変更時期	変更頻度の高いファイルはリグレッションの温床です
カバレッジの不足	既存レポートの行カバレッジとブランチカバレッジ	カバレッジが低いと、見落としが生じます
テストのマッピング	対応するテストがあるソースファイル	テストがなければ、安全網がまったくありません

出力は、リスクレベル（重大 → 低）でランク付けされたモジュールの一覧で、各評価の理由もわかりやすく示されます。

エージェントに任せるだけではだめですか？

bash にアクセスできる高性能なエージェントなら、git log --numstat を実行し、coverage.xml を解析して、テストファイルを検索できます。それなら、なぜ MCP サーバーを使うのでしょうか？

懸念事項	QA Radar の対応
トークンコスト	中規模リポジトリで 90 日分の git log を取得すると、数百 KB になります。QA Radar が返すのは約 5 KB の構造化 JSON です。
決定性	コンテキスト内で場当たり的に計算する加重リスクスコアは信頼できません。コードによる計算なら再現可能です。
速度	1 回のツール呼び出しで済むため、4～6 回の bash 呼び出しを順に実行し、その間に推論する必要がありません。
フォーマットの正規化	LCOV、Cobertura、coverage.py JSON、Go カバレッジプロファイルは、それぞれ解析方法が異なります。QA Radar は各フォーマットを正規化するため、エージェントが対応する必要はありません。
規約の組み込み	Python の test_x.py、JS/TS の x.test.ts、Go の x_test.go、Java の FooTest.java といった規約は、一度組み込めば、セッションごとに再導出する必要はありません。
移植性	同じ MCP ツールを、追加のプロンプトなしで Claude Code、Cursor、Windsurf 間で利用できます。

Claude Code プラグインとしてインストール（推奨）

最も手早い方法です。コマンド 1 つで MCP サーバーを設定し、4 つのスラッシュコマンドをインストールします。設定を手動で編集する必要はありません。

ステップ 0 — uv をインストールする（まだインストールしていない場合）：

curl -LsSf https://astral.sh/uv/install.sh | sh
# or: pip install uv

uv は必要に応じて PyPI から qaradar を起動するため、別途 pip install qaradar を実行する必要はありません。

ステップ 1 — マーケットプレイスを追加する：

/plugin marketplace add Muratkus/qaradar

ステップ 2 — インストールする：

/plugin install qaradar@qaradar-marketplace

インストールされるもの： 自動設定された 6 つの MCP ツールと 5 つのスラッシュコマンド：

コマンド	機能
/qaradar:qa-check	リスク、カバレッジ、未テストのファイルを網羅したヘルスレポート
/qaradar:qa-risky	リスクの高いファイルを理由付きでランク付けした一覧
/qaradar:qa-untested	テストが検出されていないソースファイルと、スキャフォールドの提案
/qaradar:qa-plan	優先順位付きのテスト計画（3 つのツールを連携）
/qaradar:qa-pr-risk	この PR で変更されたファイルのうち、最もリスクが高いもの

例： 大規模な機能ブランチをマージした後、/qaradar:qa-check を実行してリグレッションを確認します。PR を作成する前に、/qaradar:qa-pr-risk を実行して、最初に何をテストすべきか確認します。

MCP サーバー（AI コーディングエージェント向け）

セットアップ

別の方法：MCP 設定を手動で行う（プラグインを使わない場合）：

Claude Code の MCP 設定に追加します（ユーザーレベルは ~/.claude/mcp.json、プロジェクトレベルはプロジェクトルートの .mcp.json）：

{
  "mcpServers": {
    "qaradar": {
      "command": "uvx",
      "args": ["qaradar", "serve"]
    }
  }
}

または、手動で起動します：

uvx qaradar serve

プロンプトの例

接続したら、エージェントに次のように尋ねてください。

"このリポジトリで最初にテストすべきことは何ですか？" "現在、最もリスクが高いファイルはどれですか？" "過去1か月で変更頻度が最も高いファイルを表示してください。" "テストがまったくないソースファイルはどれですか？" "変更したファイルのうち、リスクが高いものはどれですか？" ← diff を考慮

利用可能な MCP ツール

ツール	エージェントが使用するタイミング
qaradar_healthcheck	リポジトリの品質を包括的に把握するとき
qaradar_risky_modules	最初にテストすべき対象や、最もリスクが高いファイルを確認するとき
qaradar_churn	ホットスポットを検出し、リグレッションが発生しやすい場所を確認するとき
qaradar_coverage_gaps	カバレッジが低いファイルや、テストの盲点を確認するとき
qaradar_untested_files	対応するテストファイルがないソースファイルを確認するとき
qaradar_pr_risk	この PR で変更したファイルのうち、注意が必要なものを確認するとき
qaradar_should_run	作業完了後、QA Radar で再分析すべきか、差分またはリポジトリ全体を分析すべきかを確認するとき

差分を考慮：この PR でリスクが高いものは？

qaradar_pr_risk は、リポジトリ全体ではなく、ベースの ref と HEAD の間で変更されたファイルのみをスコアリングします。リポジトリ全体で正規化することでリスクスコアの一貫性を保つため、エージェントが把握している変更ファイルが1つだけの場合でも、PR 内のコミットが2件あるファイルが誤って CRITICAL と判定されることはありません。

エージェントに次のように尋ねてください。

"変更したファイルのうち、リスクが高いものはどれですか？" "変更したファイルの中に、テストがないものはありますか？" "この PR を出す前に、何をレビューすべきですか？"

または CLI から：

# Diff against main — shows only changed files
qaradar analyze . --base main

# Diff against a specific ref
qaradar analyze . --base origin/main --days 60

qaradar_pr_risk は GITHUB_BASE_REF（GitHub Actions で自動設定）からベースブランチを自動検出し、検出できない場合は main／master を使用します。上書きするには base_ref を明示的に指定してください。

CLI

# Full health check on current directory
qaradar analyze

# Analyze a specific repo with 180 days of history
qaradar analyze /path/to/repo --days 180

# Output as JSON (for piping to other tools)
qaradar analyze --json-output

# Show top 10 risky modules only
qaradar analyze --top 10

# Diff-aware: score only files changed since main
qaradar analyze . --base main

インストール

pip install qaradar

または、インストールせずに実行します。

uvx qaradar serve

ソースから（開発用）：

git clone https://github.com/Muratkus/qaradar.git
cd qaradar
pip install -e .

言語サポート

すべての言語サポートは、単一のレジストリ qaradar/analyzers/languages.py に集約されています。そのため、言語の追加は1つのエントリ（拡張子、テスト名の規則、テスト関数カウンター）を追加するだけで済み、churn と test-mapping の両方で利用されます。

Tier 1 — 標準サポート、テスト済み

言語	テストの検出	カバレッジ
Python	test_x.py、x_test.py	coverage.py JSON + XML
JavaScript / TypeScript	x.test.*、x.spec.*、x-test.*（React Native）	LCOV、Jest/Istanbul JSON
Go	x_test.go	Go カバレッジプロファイル（cover.out）
Swift	XTests.swift（XCTest func test…）	Cobertura / LCOV
Kotlin	XTest.kt（@Test）	Cobertura / LCOV
Dart / Flutter	x_test.dart（test(、testWidgets(）	LCOV（coverage/lcov.info）
Objective-C	XTests.m / .mm（XCTest - (void)test…）	Cobertura / LCOV

Tier 2 — ベストエフォート、命名規則ベース

Java、Ruby、Rust — 命名規則によってテストを検出します。カバレッジは、出力されている場合に Cobertura XML または LCOV を使用します。

カバレッジの解析はフォーマットに基づくため、言語固有の test-mapping 検出よりも多くのエコシステムに対応しています。

モノレポ： Istanbul/Jest のレポートは packages/*/coverage および apps/*/coverage から自動検出されます。また、絶対パスおよびパッケージ相対のカバレッジパスはリポジトリ相対パスに正規化されるため、churn と test-mapping のシグナルと正しく照合されます。

対応するカバレッジ形式

形式	ツール
coverage.py JSON	Python coverage run + coverage json
Istanbul / Jest JSON	coverage-final.json、coverage-summary.json（Jest/Vitest/nyc）
Cobertura XML	Python、Java/Gradle、.NET（Coverlet）
LCOV	JS/TS、Flutter/Dart、C/C++、Rust（grcov）
Go カバレッジプロファイル	go test -coverprofile=cover.out

出力例

╭──────────────── QA Radar Health Report ─────────────────╮
│ Repository: /home/user/my-service                       │
│ Source files: 47  Test files: 23  Ratio: 0.49           │
│ Avg coverage: 62.3%  Tested: 31  Untested: 16          │
╰─────────────────────────────────────────────────────────╯

  CRITICAL risk modules: 3
  HIGH risk modules: 7

┌─────────────────────────────────────────────────────────┐
│ Risky Modules                                           │
├──────────────────────┬──────────┬───────┬───────────────┤
│ File                 │ Risk     │ Score │ Reasons       │
├──────────────────────┼──────────┼───────┼───────────────┤
│ src/payments/core.py │ CRITICAL │  0.87 │ High churn:   │
│                      │          │       │ 34 commits;   │
│                      │          │       │ No tests      │
│ src/auth/tokens.py   │ CRITICAL │  0.82 │ Low coverage: │
│                      │          │       │ 12.3%; Active │
│                      │          │       │ recently      │
└──────────────────────┴──────────┴───────┴───────────────┘

時間の経過に伴う実行の追跡

デフォルトでは、QA Radar はステートレスです。永続化を有効にすると、実行をまたいでリポジトリを追跡し、差分分析を段階的に行えます（毎日／毎週、N 回の差分後、またはエージェントの作業完了後など）。

qaradar analyze . --save      # record a snapshot to .qaradar/state.json (gitignore it)
qaradar should-run .          # exit 0 if a re-run is warranted, 1 if not — prints JSON
qaradar status .              # last run, commits/days since, current decision + risk delta

should-run はスケジューラーではなくゲートです。すでに使用しているものに組み込んでください。

# cron / CI / git hook: only do expensive work when criteria are met
qaradar should-run . && qaradar analyze . --save

scope: "full"（間隔が経過）または scope: "diff"（変更されたファイルが十分にある）を報告するため、qaradar_should_run MCP ツールを呼び出すエージェントは、qaradar_healthcheck と qaradar_pr_risk のどちらを続けて実行するべきか判断できます。状態はリポジトリごとに .qaradar/state.json というファイルに保存されるため、「複数のリポジトリの集まり」は、独自のインフラでリポジトリをループ処理するだけです。

条件は qaradar.toml で調整できます。

[schedule]
interval_days = 7        # re-run the full healthcheck at least weekly
min_changed_files = 25   # ...or sooner, once this many files have changed

--save は、前回の実行との差分も報告します。新たにリスクが高まったファイル、悪化したファイル、改善または解決したファイルを確認できます。

ロードマップ

• v0.1.2 — Claude Code プラグインとスラッシュコマンド
• v0.2.0 — 設定ファイル（qaradar.toml）、Tier 2 言語検証、堅牢性の強化
• v0.3.0 — 差分認識モード：qaradar_pr_risk と --base CLI フラグ
• v0.4.0 — モバイル／モノレポの言語カバレッジ（Swift、Kotlin、Obj-C、Dart、React Native、Jest）、実行の永続化と再実行条件（should-run、--save、qaradar_should_run）
• v0.5.0 — CI 履歴からの不安定なテストの検出（JUnit XML の解析）

基本理念

QA Radar は、次の 3 つの考え方に基づいています。

1. ボトルネックは移りました。 AI により、テストを書くことは簡単になりました。どのテストが重要なのかを知ることが難しいのです。
2. 品質は数値ではなく、全体像です。 カバレッジの割合が 1 つあるだけでは、すべてが見えなくなります。リスクはモジュールごと、シグナルごと、期間ごとに異なります。
3. エージェントにはコンテキストが必要です。 リポジトリの脆弱な領域を知らない AI コーディングアシスタントは、一般的なテストを書いてしまいます。品質の全体像を与えれば、的を絞ったテストを書けます。

ライセンス

MIT