受入テストが終盤に差し掛かると、BTS（Bug Tracking System）に欠陥チケットが山積みになる。「どれから潰すか」を毎日判断するPMが、いつのまにか「声の大きい人の指摘」を優先してしまう——多くのチームが通る景色です。
「AIで欠陥分析を自動化」と聞きますが、汎用要約だけでは判断材料になりません。求められるのは、重大度×再現性×顧客影響の3軸で自動スコアリングし、PMが議論すべき上位欠陥に集中できる運用です。
この記事では、Claude CodeのSkillでBTSチケットを3軸スコアリングし、品質判断を構造化する実装を、現場で動かせる粒度で解説します。
なぜ欠陥の優先順位はぶれるのか
欠陥対応の優先順位がぶれるのは、判断軸が混ざるためです。
- 重大度（Severity）：システム的な深刻度（クラッシュ／機能不全／表示崩れ など）
- 再現性（Reproducibility）：常時／条件下／稀／不明
- 顧客影響（Customer Impact）：全顧客／一部顧客／社内のみ
この3つを混ぜて議論すると、「再現性は低いけど見た目が派手」な欠陥が優先されたり、「全顧客に出るが軽微な表示崩れ」が後回しにされたりします。Claude Codeは、Skillで3軸を分離してスコア化し、根拠付きで上位欠陥を提示する運用を素直に組めます。
Claude Codeを「欠陥3軸分析器」にする全体像
必要な要素は次の3つです。
- BTS取得MCP：JIRA・Redmine・Backlog などの欠陥チケットを読み取り専用接続
- 欠陥スコアリングSkill：3軸を分離してスコア算出、根拠付きでランキング出力
- CLAUDE.md品質運用ルール：3軸の判定基準、ステアリング報告基準、close基準を明記
これが揃えば、毎朝Skillを叩くだけで「今日議論すべきトップ10」が手元に届きます。
ステップ1：3軸スコアリング基準を決める
BTSのチケットに3軸ラベルを付ける運用を整えます。CLAUDE.mdに基準を書く前に、運用上の定義を一本化します。
# docs/quality/scoring-rubric.yaml
severity:
S1: { label: "クラッシュ・データ破壊", score: 5 }
S2: { label: "主要機能不全・代替不可", score: 4 }
S3: { label: "副次機能不全・代替あり", score: 3 }
S4: { label: "表示崩れ・軽微なUX問題", score: 2 }
S5: { label: "コスメ・タイポ", score: 1 }
reproducibility:
R1: { label: "常時再現", score: 5 }
R2: { label: "条件下で再現", score: 3 }
R3: { label: "稀に再現", score: 1 }
R4: { label: "再現未確認", score: 0 }
customer_impact:
C1: { label: "全顧客に発生", score: 5 }
C2: { label: "主要顧客セグメントに発生", score: 4 }
C3: { label: "一部顧客に発生", score: 2 }
C4: { label: "社内のみ", score: 1 }総合スコアは「severity × 0.5 + reproducibility × 0.25 + customer_impact × 0.25」で計算。重大度を重く配分するのは、再現性が低くても重大なクラッシュは優先すべきという業界的な常識を反映するためです（重みは組織ごとに調整可能）。
ステップ2：欠陥スコアリングSkillを定義する
.claude/skills/defect-rank/SKILL.md を作成します。
---
name: defect-rank
description: BTSの欠陥チケットを取得し、docs/quality/scoring-rubric.yamlの3軸基準でスコア化、tmp/quality/{YYYY-MM-DD}-rank.md にランキング付き欠陥分析を出力する
disable-model-invocation: true
allowed-tools: Read, Write, mcp__jira__*
---
# 欠陥3軸分析Skill
## 入力
- なし（オープン状態のチケットを全件対象）
## 処理
1. BTSから「open」「in-progress」状態のチケット全件を取得
2. 各チケットに付与されたsevereity / reproducibility / customer_impactラベルを読む
3. ラベル未付与のチケットはチケット本文から推定し、low_confidenceフラグを付ける
4. 総合スコアを算出し降順ソート
5. トップ10を「議論候補」、close候補（スコア5以下）を別章で表示
## 出力フォーマット
- ファイル名：`tmp/quality/{YYYY-MM-DD}-rank.md`
- 章立て：①サマリー（オープン件数・スコア分布） ②議論候補トップ10 ③ラベル未付与・要再分類 ④close候補 ⑤PM判断欄（**空欄**）
## 厳守
- ラベル未付与チケットの推定は必ずlow_confidenceフラグ付き
- スコア計算ロジックの根拠を必ず併記
- ⑤PM判断欄をAIが埋めない「ラベル未付与の推定は low_confidence」が安全装置です。AIによる推定をそのまま採用せず、PMが必ず確認する設計にしておきます。
ステップ3：CLAUDE.mdに品質運用ルールを書く
## 欠陥管理運用ルール
### 3軸ラベル付与の責務
- severity：開発リーダー
- reproducibility：QA担当
- customer_impact：PM／プロダクトオーナー
- 3軸が揃うまで「triage待ち」ステータスに留める
### スコア閾値とアクション
- スコア17以上：当日中にステアリングへ報告
- スコア13〜16：今週中に対応方針決定
- スコア5以下：原則close候補（理由付きで判断）
### ステアリング報告基準
- スコア17以上の件数推移を週次で報告
- close候補の件数も合わせて報告（消化スピードの指標）
### AIで判定しないこと
- 顧客影響（customer_impact）は事業文脈が必要なため、PMが必ず最終判定
- close判断は人間（QAリーダーまたはPM）が行う「AIで判定しないこと」を明示するのが運用の鍵です。3軸のうちcustomer_impactは事業判断が必要で、AIには根拠ある判定ができません。
ステップ4：実際の運用フロー
毎朝の運用は次の通りです。
- PMが
claudeを起動し/defect-rankを実行（朝の5分） - 「議論候補トップ10」を朝会で議論、対応担当を即決
- 「ラベル未付与・要再分類」を該当ロールにエスカレーション
- close候補は週末にまとめて棚卸し
慣れれば朝会の準備が5分で済み、「今日どこに体力を使うか」が即決します。
期待効果と運用上の注意点
導入チームから報告される効果は3点です。
- 欠陥対応の優先順位がぶれにくい：3軸スコアが客観的根拠になり、感覚論を排除できる
- 声の大きい指摘に流されない：全件スコア化されるため、隠れた高スコア欠陥が見える
- ステアリング報告に説得力が出る：「スコア17以上が先週から3件減少」と数値で語れる
落とし穴は3つ。
- ラベル付与運用が崩れるとSkillが機能しない：3軸ラベル必須をBTSのワークフローで強制する
- 重みを頻繁に変えない：scoring-rubric.yamlの重みは四半期ごとの見直しに留める
- AIに最終決定をさせない：あくまで議論の叩き台。close判断は人間が責任を持つ
まとめ
- 欠陥対応の優先順位ぶれは判断軸の混在が原因
- 3軸（重大度×再現性×顧客影響）を分離してスコア化することで、客観的な議論材料が手に入る
- AIにはスコア計算とランキング作成を任せ、最終判断はPM／QAが担う
- CLAUDE.mdに「AIで判定しないこと」を明記することで、自動化と責任の境界がはっきりする
ここまでで「動く欠陥3軸分析器」は手に入ります。実務でこれを“品質保証の運用”に育てるには、テスト戦略との接続、リリース判定基準の設計、炎上案件の優先順位設計といった上位設計が必要です。
IPJ-105『要件・仕様統制』 と FEX-101『炎上対応の優先順位設計』 を組み合わせると、本記事のSkillをベースに、品質の構造化判断と炎上時の意思決定を体系で学べます。「欠陥が積み上がって優先順位がブレる」PMが、最短で“仕組みで判断する運用”に到達するための導線です。