リスクベース優先度づけ

概要

限られた工数で「どこを優先的にテストするか」はQAの核心判断ですが、勘や声の大きさで決まりがちで、根拠が残りません。本ツールは各対象のリスクを根拠つき・再現可能に算出し、優先順位を説明できる形にします。判断材料が足りない場合も黙ってゼロ評価せず、何を補えばよいかを明示します。

効果

• 限られた工数を、リスクの高い対象から根拠つきで割り当てられる。
• 影響度・発生可能性のどちらの手がかりで上がったかが出るため、優先順位を説明・合意できる。
• 不足している判断材料を明示するので、評価の穴が分かる。
• 決定的スコアは同入力同出力＝同じ対象には同じ優先度を返し、判断のブレを抑える。

インプット

• テスト対象一覧
• 共通コンテキスト要因
• 構造化信号（任意）

汎用LLMとの違い

リスク要因モデル（影響度・発生可能性の手がかりカタログ）・重み・しきい値・帯が bubo 独自の中核です。汎用LLMに「どれを優先する？」と聞くより、決定的に再現可能なスコアを土台にし、その上でLLMが暗黙リスクと不足材料を上乗せするため、優先順位の根拠が追えて説明できます。

優先順位づけ結果の比較

同じテスト対象一覧・コンテキスト・シグナルを、汎用AIと risk-based-test-prioritizer にそのまま渡した実際のやりとりです（要約ではありません）。

【テスト対象一覧】
- 決済確定処理
- 注文履歴画面の表示
- ヘルプページの文言更新

【コンテキスト（担当者が口頭で足す前提知識）】
決済は基幹・過去不具合多発。ヘルプページの文言更新は表示のみで影響小。

【シグナル（リポジトリから機械的に集めた実測値）】
{"決済確定処理": {"churn": 35, "bugfix_count": 6}}

優先順位づけ結果の比較

本ツールだけが返した情報 — 何が足りなくて判定が粗いのか（集計: 最優先1件・優先0件・標準0件・低2件）

## リスク優先順位

**1位: 決済確定処理**
- 基幹機能であり、失敗時の影響がユーザー・事業双方に直結(誤課金・二重決済・注文不整合など)
- signalsでchurn=35、bugfix_count=6と、変更頻度・過去不具合数ともに突出して高い → コードが
  不安定で退行しやすい箇所
- 影響度・発生確率ともに最大で、優先度は明確に最上位

**2位: 注文履歴画面の表示**
- 表示系だが決済結果を反映する画面であり、決済処理の不具合の影響を可視化する経路にもなる
  (誤表示は問い合わせ・信頼低下に直結)
- signalsデータなし・context記載なしのため不確実性はあるが、決済と隣接する機能である以上、
  ヘルプページより明確にリスクが高い

**3位: ヘルプページの文言更新**
- contextで「表示のみで影響小」と明記されており、機能的な副作用がほぼない
- 最悪でも文言の誤りに留まり、業務影響・データ整合性への影響はない

## 判断根拠
- 決済確定処理: 影響度(大)×発生確率(高、signals裏付けあり)
- 注文履歴画面: 影響度(中)×発生確率(不明だが決済に隣接するため中程度と推定)
- ヘルプページ: 影響度(小)×発生確率(低、contextで明言)

# テスト優先度ランキング

> 3件のテスト対象を評価。最優先1件・優先0件・標準0件・低2件。

## 優先順位（3件）

1. **決済確定処理** — 最優先（score=25）
   - 根拠: 影響度↑: 基幹・中核機能・課金・決済に関与 / 発生可能性↑: 過去不具合の多発 / 変更頻度が高い（実測35回） / 過去不具合が多い（実測6件）
2. **注文履歴画面の表示** — 低（score=3）
   - 根拠: 影響度↑: 画面・表示の品質 / 影響小の指定を反映し影響度を低評価
3. **ヘルプページの文言更新** — 低（score=3）
   - 根拠: 影響度↑: 画面・表示の品質 / 影響小の指定を反映し影響度を低評価

機械可読な出力（抜粋）:
{
  "rankings": [
    {"item": "決済確定処理",       "risk_score": 25, "tier": "最優先", "likelihood": 5, "impact": 5},
    {"item": "注文履歴画面の表示", "risk_score": 3,  "tier": "低",     "likelihood": 3, "impact": 1},
    {"item": "ヘルプページの文言更新", "risk_score": 3, "tier": "低", "likelihood": 3, "impact": 1}
  ],
  "tier_distribution": {"最優先": 1, "優先": 0, "標準": 0, "低": 2},
  "top_focus": ["決済確定処理"],
  "collection_plan": {
    "missing": {
      "注文履歴画面の表示":   ["churn", "bugfix_count"],
      "ヘルプページの文言更新": ["churn", "bugfix_count"]
    }
  },
  "notes": "決定的スコアのみで算出しました（BYOK鍵を接続するとLLM層が暗黙リスク・根拠補完・不足コンテキストを上乗せします）。"
}

どちらのやり方でも最優先は決済確定処理になります。分かれるのは、実測シグナルが無い対象の扱いです。汎用AIは「隣接するからリスクが高い」という推定で2位・3位に序列を付け、その旨を〈不明だが…と推定〉と本文中に添えます。本ツールは実測シグナルが無い2件を同点（score=3・tier=低）のまま置き、代わりに collection_plan.missing として、どの対象にどのシグナル（churn・bugfix_count）が欠けているかを機械可読で返します。順位の根拠が「35回・6件」という実測値なのか、埋め合わせの推定なのかが、出力の上で分離されたまま残ります。

社外秘のコードを、どう守るか

ワンタイムコードは単回使用・有効期限7日・サーバーに平文保存はしません。発行したトークンは設定ファイルに直書きせず環境変数で参照します。既存のMCP設定がある場合も、壊さず冪等にマージします。

どう申し込み、どうつなぐのか

← QA向けMCPツール一覧へ戻る