risk-based-testing

すべての機能を均等にカバーすると、リスクの低い領域に労力をかけすぎる一方で、重要な経路のテストが不足します。設定ページでカバレッジ90％を目指すのは、チェックアウトに使うべき労力を奪うことになります。このスキルではリスクを特定し、影響度 × 発生確率として数値化し、リスクゾーンに応じてテスト密度を割り当て、製品の進化に合わせて評価を最新の状態に保ちます。出力されるスコア付きリスクマトリクスは、`test-strategy` と `test-planning` に活用できます。

クイックルート

状況	開始地点
新しい製品で、リスクモデルがまだない	フェーズ1（特定）→ 6つのフェーズをすべて実施
インシデント後の再評価	フェーズ6（再評価のトリガー）を確認し、フェーズ2で該当項目を再スコアリング
評価対象がAI／LLM機能	フェーズ3（AI／LLMの障害クラス）を確認し、フェーズ2で各クラスをスコアリング
既存マトリクスのスプリントごとの更新	変更された機能について、フェーズ4～5（ヒートマップ＋カバレッジの整合）を実施
古いヒートマップが今も正しいか確認	フェーズ6のシグナルとアンチパターン「リスク・シアター」を確認

---

発見のための質問

まず .agents/qa-project-context.md を確認してください。存在する場合はその内容を基礎として使用し、そこですでに回答されている質問は省略します。エンジニアリング、プロダクト、運用の各関係者から、残りの情報を集めてください。

収益に直結するフロー

• どのユーザーフローが直接収益を生み出していますか？（チェックアウト、サブスクリプション、請求、アップグレード）
• 各フローが1時間停止した場合の収益への影響はどれくらいですか？
• 時間的制約のあるフローはありますか？（フラッシュセール、市場取引時間中の取引、給与支払いの期限）
• どのフローに、金銭的なペナルティを伴う契約上のSLAがありますか？

最近の障害

• 直近3回のリリースで何が壊れましたか？本番環境に流出した不具合はありますか？
• 根本原因は何でしたか？（コードの欠陥、設定エラー、サードパーティの障害、データ移行）
• 各インシデントの影響範囲はどれくらいでしたか？（影響を受けたユーザー数、失われた収益、評判への影響）
• テスト中に遅れて発見されたものの、流出する可能性があったニアミスはありましたか？

脆弱な領域

• コードベースのどの部分が最も頻繁に変更されていますか？（変更頻度が高いほどリスクも高くなります）
• 現在、テストカバレッジが最も低いモジュールはどれですか？
• ビジネスロジックが最も複雑な領域、または条件分岐が最も多い領域はどこですか？
• チームを離れたエンジニアが書いたコードはどれですか？

サードパーティ依存関係

• 製品はどの外部サービスに依存していますか？（決済プロセッサー、認証プロバイダー、CDN、API）
• 各依存関係の過去の信頼性はどうですか？
• 各依存関係が停止した場合、どうなりますか？（適切に縮退しますか、それとも完全に障害になりますか？）
• フォールバックのない単一障害点はありますか？

コンプライアンスとデータ

• どの規制要件が適用されますか？（GDPR、PCI-DSS、HIPAA、SOC2、SOX、EU AI Act）
• 最も機密性の高いデータは何ですか？（個人を特定できる情報、金融情報、健康情報、認証情報）
• データ侵害やコンプライアンス違反が発生した場合、法的にどのような結果が生じますか？
• 特定のテスト証跡を義務付ける監査要件はありますか？

---

中核となる原則

1. すべての機能が同じ重要度ではありません。 購入を妨げるチェックアウトのバグと、設定ページのアイコンの位置ずれは、根本的に異なります。すべてを同じようにテストすると、リソースを低リスク領域に浪費する一方で、重要な経路のテストが不十分なままになります。
2. リスク＝影響度 × 発生確率です。 リスクは直感で判断するものではありません。独立して評価する2つの要素、つまり失敗した場合の深刻さ（影響度）と、失敗の起こりやすさ（発生確率）から算出します。製品全体で両方を一貫して評価し、その値を掛け合わせます。
3. リスク評価は継続的に行います。 一度作成したリスクモデルを更新しないままにすると、誤った安心感を生みます。製品や依存関係、チームに変更があったとき、そして本番環境でインシデントが発生するたびに、リスクも変化します。定期的な見直しを日々の取り組みに組み込みます。
4. ニアミスはデータです。 ステージング環境で見つかった壊滅的なバグは、成功談ではありません。その領域のリスクをモデルが過小評価していたことを示すシグナルです。ニアミスも本番インシデントと同じ厳密さで記録します。
5. カバレッジはリスクに基づいて決め、逆にしてはいけません。 「どこもカバレッジ80％が必要だ」という考えから始めないでください。「障害が起きたとき、最も大きな影響が出るのはどこか？」から始め、モデルに基づいてモジュールごとのカバレッジ目標を定めます。

---

ワークフロー

1. Identify → 2. Classify → 3. Analyze → 4. Heatmap → 5. Coverage → 6. Reassess → (repeat)
                                 ↑
                       score ≥ 10 only; skip to 4 if no items reach threshold

フェーズ1：リスクの特定

起こりうる問題をすべて列挙します。幅広く洗い出してください。情報源には次のものがあります。

• ステークホルダーへのヒアリング： プロダクトマネージャーはビジネス上重要なフローを把握しています。エンジニアは脆弱なコードを知っています。サポート担当者は、ユーザーから繰り返し寄せられる苦情を把握しています。
• インシデント履歴： 過去の障害は、将来の障害を予測する手がかりになります。過去6〜12か月の事後検証を確認します。
• 依存関係のマッピング： 外部サービス、データベース、メッセージキュー、サードパーティ API をすべて洗い出します。それぞれがリスク要因になります。
• 変更の分析： コードの変更頻度が高い領域では、欠陥が発生する確率も高くなります。フェーズ6の変更頻度ランキングコマンドを使って特定してください。git log --stat <file> は特定の疑わしいファイルをコミットごとに調査するためのものであり、ランキングには使いません。
• アーキテクチャレビュー： 共有データベース、単一障害点、同期処理の連鎖、密結合したモジュールは、障害の影響範囲を拡大します。

フェーズ1での観点として HTSM v6.3（Heuristic Test Strategy Model、Bach）を活用します。状態ベースのヒューリスティックと境界のヒューリスティックにより、機能リストだけでは見落とされるリスクを洗い出せます。ダウンロード先：https://www.satisfice.com/download/heuristic-test-strategy-model

成果物：起こりうる障害と、その結果をそれぞれ記述したリスク項目の一覧。

フェーズ 2：リスク分類

各リスク項目を、2 つの軸に沿って分類します。

影響度のカテゴリ（どの程度深刻か）：

スコア	レベル	定義	例
5	壊滅的	収益損失、データ侵害、法的措置、ユーザーの安全	決済処理の失敗、PII の漏えい
4	重大	ユーザーへの大きな影響、SLA 違反、主要機能の破損	一部のユーザー層でログインできない、データ破損
3	中程度	ワークフローが妨げられるが、回避策がある	検索結果が誤っている、エクスポートに失敗する
2	軽微	見た目または軽微な UX の問題	配置の不具合、重要ではないページの表示が遅い
1	無視できる	ユーザーへの影響はなく、内部のみ	管理者向けツールチップの誤り、ログ形式の問題

発生確率のカテゴリ（どの程度起こりやすいか）：

スコア	レベル	定義	指標
5	頻繁	ほとんどのリリースで発生が予想される	コード変更が多い、テストがない、ロジックが複雑
4	可能性が高い	四半期以内に発生する可能性が高い	最近の変更、部分的なカバレッジ、既知の技術的負債
3	可能性がある	発生する可能性があり、過去にも発生している	中程度の複雑さ、ある程度のカバレッジ
2	可能性が低い	起こりそうにないが、不可能ではない	安定したコード、十分なカバレッジ、シンプルなロジック
1	まれ	例外的な状況が必要	十分にテスト済み、変更頻度が低い、シンプル

複合スコア ＝ 影響度 × 発生確率。頻繁な変更は不具合の発生確率を高めます。そのため、中程度の影響度（3）の機能でも、変更が頻繁であれば発生確率は 5 となり、「中程度」の影響度にすぎなくても、リスクスコア：15 → 重大ゾーンに分類されます。優先度を決めるのは複合スコアであり、影響度だけではありません。

フェーズ 3：故障モード分析

高リスク項目（スコア ≥ 10）ごとに、詳細な故障モード分析を実施します。

Feature/Component: [name]
Risk Score: [impact × probability]

Failure Mode 1: [what specifically can fail]
  Trigger:            [what causes this failure]
  Blast Radius:       [users affected, systems affected, data affected]
  Detection Method:   [how would we know -- monitoring, user report, test]
  Current Mitigation: [existing tests, monitoring, feature flags, fallbacks]
  Gap:                [what is missing from current mitigation]

Failure Mode 2: ...

例 — E コマースのチェックアウト（リスクスコア 20、影響度 5 × 発生確率 4）：

Failure Mode 1: Payment charge succeeds but order not recorded
  Trigger:            Race condition between payment API callback and order write
  Blast Radius:       Individual users; money charged but no order confirmation
  Detection Method:   Payment reconciliation job (runs hourly), user complaint
  Current Mitigation: Idempotency key on payment, retry on order write
  Gap:                No automated test for the race condition; reconciliation delay is 1 hour

Failure Mode 2: Discount code applies incorrect amount
  Trigger:            Percentage discount on already-discounted item
  Blast Radius:       All users with stacked discounts; revenue leakage
  Detection Method:   Margin monitoring alert (>5% deviation)
  Current Mitigation: Unit tests for single discounts
  Gap:                No tests for discount stacking; no tests for rounding edge cases

Failure Mode 3: Inventory not reserved during checkout
  Trigger:            Concurrent purchases of last-stock item
  Blast Radius:       Oversold items, fulfillment failure, customer trust
  Detection Method:   Fulfillment team discovers during packing
  Current Mitigation: Database-level stock check on order creation
  Gap:                No load test simulating concurrent last-item purchases

AI/LLM の故障クラス

AI/LLM 機能については、これらの CT-GenAI クラスに照らして分類し、他のリスクと同様に影響度と発生確率を個別にスコア付けします。リスク軽減策となるのは、自動化された評価スイートの存在であり、単一の手動テストではありません。

AI/LLM 固有の故障クラス（ISTQB CT-GenAI v1.1 に基づく。2026 年 4 月 27 日発効）：

• 幻覚／推論エラー — 影響度：中程度から重大。明示的なプロンプト評価のカバレッジがない場合、発生確率は高くなります。検出方法：ゴールデンデータセットによる評価、ファクトチェックのアサーション（ai-system-testing を参照）。
• バイアス — 規制対象業界（金融、ヘルスケア、採用）では影響度は壊滅的です。発生確率はデータセットに依存します。検出方法：反実仮想評価、人口統計的パリティチェック。
• プロンプトインジェクション／ジェイルブレイク — 影響度：重大（データ流出、プロンプト抽出）。外部公開されるあらゆる LLM 機能で、発生確率は高くなります。検出方法：Garak、PyRIT、Promptfoo redteam。
• プライバシー漏えい — GDPR/CCPA/EU AI Act の下では影響度は壊滅的です。発生確率はデータセットに依存します。検出方法：トレーニングデータとプロンプトの PII スキャン。
• AI Act／規制への不適合 — 影響度：壊滅的（罰金、禁止）。EU 向けの AI 機能では発生確率が高くなります。検出方法：compliance-testing を参照。

ツールの最新状況（2026 年半ば）：PyRIT の現在のリポジトリは microsoft/PyRIT です。以前の Azure ホストのリポジトリは 2026 年 3 月にアーカイブされたため、新しい redteam 作業で従来の Azure のパスを参照しないでください。Promptfoo は OpenAI に買収されました（2026 年 3 月）が、MIT ライセンスのままです。Garak は最新の状態で、変更はありません。

参照フレームワーク： CT-GenAI v1.1（ISTQB、2026 年 4 月 27 日発効）では、上記の AI/LLM クラスが体系化されています。WQR 2025-26（Capgemini、第 17 版、2025 年 11 月）は、AI リスク計画における導入段階の枠組みを示しています。

フェーズ 4：リスクヒートマップ

すべてのリスク項目を 5×5 のマトリックスにプロットし、優先順位を共有してカバレッジの判断を促します。

                    PROBABILITY
                    Rare(1)   Unlikely(2)  Possible(3)  Likely(4)   Frequent(5)
                   +----------+-----------+-----------+----------+-----------+
  Catastrophic(5)  |  5  MED  | 10  HIGH  | 15  CRIT  | 20 CRIT  | 25  CRIT  |
                   +----------+-----------+-----------+----------+-----------+
  Major(4)         |  4  LOW  |  8  MED   | 12  HIGH  | 16 CRIT  | 20  CRIT  |
I                  +----------+-----------+-----------+----------+-----------+
M  Moderate(3)     |  3  LOW  |  6  MED   |  9  MED   | 12 HIGH  | 15  CRIT  |
P                  +----------+-----------+-----------+----------+-----------+
A  Minor(2)        |  2  LOW  |  4  LOW   |  6  MED   |  8 MED   | 10  HIGH  |
C                  +----------+-----------+-----------+----------+-----------+
T  Negligible(1)   |  1  LOW  |  2  LOW   |  3  LOW   |  4 LOW   |  5  MED   |
                   +----------+-----------+-----------+----------+-----------+

ゾーンの境界と対応の対応付け：

ゾーン	スコア範囲	色	テスト対応
CRITICAL	15-25	赤	完全に自動化 ＋ 本番環境で監視 ＋ 負荷テスト ＋ 手動の探索的テスト
HIGH	10-14	オレンジ	完全に自動化 ＋ 定期的な手動レビュー
MEDIUM	5-9	黄色	ハッピーパス ＋ 主要なエラーケースを自動化
LOW	1-4	緑	リリース時に手動テスト、または完全に省略

入力例（各リスク項目の該当ゾーン）：

                    Rare(1)   Unlikely(2)  Possible(3)  Likely(4)   Frequent(5)
  Catastrophic(5)             Auth bypass   Payments fail  Checkout crash
  Major(4)                                  Data export    Search broken  User upload
  Moderate(3)                  Report fmt    Email deliver  Profile edit
  Minor(2)         Footer link Tooltip text  Theme switch
  Negligible(1)    Admin label

フェーズ 5：テストカバレッジの整合

テスト密度をリスクレベルに対応させます。各ゾーンには、定められたアプローチがあります。

リスクゾーン	単体テスト	統合テスト	E2E テスト	手動テスト	モニタリング
CRITICAL (15-25)	90% 以上の分岐カバレッジ	すべてのサービス境界	ユーザージャーニー全体 ＋ エラーパス	リリースごとに探索的テスト	リアルタイムアラート、合成チェック
HIGH (10-14)	80% 以上の分岐カバレッジ	主要なインタラクション	ハッピーパス ＋ 上位 3 つのエラーパス	抜き取りチェック	ダッシュボード ＋ 毎日のレビュー
MEDIUM (5-9)	70% 以上の分岐カバレッジ	ハッピーパスのみ	ハッピーパスのみ	大きな変更時	週次レビュー
LOW (1-4)	基本的なハッピーパス	不要	不要	初回ビルド時	不要

ギャップ分析ワークシート

リスクゾーンごとに、現在のカバレッジを必要なカバレッジと比較します。

Feature: [name]
Risk Zone: [CRITICAL / HIGH / MEDIUM / LOW]      Risk Score: [number]

Required Coverage:
  Unit:        [target %]     Current: [actual %]     Gap: [delta]
  Integration: [required?]    Current: [exists? y/n]  Gap: [missing scenarios]
  E2E:         [required?]    Current: [exists? y/n]  Gap: [missing flows]
  Monitoring:  [required?]    Current: [exists? y/n]  Gap: [missing alerts]

Priority: [P0 / P1 / P2 / P3]
Estimated Effort: [hours / story points]
Owner: [name]                Target Sprint: [sprint number]

コード変更の多さを示すシグナルがあれば、このワークシートを開いて確認します。3 か月で 47 回変更されたモジュール（発生確率 → 5）が、分岐カバレッジ 40% で統合テストもない場合、ゾーンが上がります（例：MEDIUM → HIGH）。新しいカバレッジ目標は恣意的に選ぶのではなく、コード変更の多さを根拠に設定します。

リスクスコアから所定のカバレッジに至るまでを示す、スコアをすべて付与した 4 つの例（チェックアウト、メディアプラットフォーム、サードパーティ API、認証）については、references/examples.md を参照してください。

フェーズ 6：モニタリングと再評価

リスク評価は一度限りの作業ではありません。チームの日常的な活動に再評価を組み込みましょう。

再評価のトリガー：

• 本番環境でインシデントが発生するたび（48 時間以内）：影響を受けた項目を再スコアリングし、依存関係の健全性を確認して、フェーズ 5 のギャップ分析を再実施し、インシデントで明らかになったカバレッジの不足を把握します
• 新しい機能領域が導入されたとき
• 重要な依存関係が変更されたとき（API バージョン、プロバイダーの切り替え）
• チーム構成が大きく変わったとき
• トリガーがなくても、最低限、四半期ごと

継続的に監視するリスクシグナル：

• モジュールごとのコード変更頻度（頻度順の表）：

  git log --since="3 months ago" --name-only --format= | grep -v '^$' | sort | uniq -c | sort -rn | head -20
  

• 不具合の集中状況： どのモジュールで最も多くのバグが発生しているかを確認します。イシューレーベルで追跡します。
• ニアミスの頻度： ステージングや QA での検出によって、本番環境でのインシデントをどの程度防げているかを確認します。
• 依存関係の健全性： 重要なサードパーティサービスのステータスページと稼働時間を監視します。
• カバレッジの傾向： 高リスク領域のカバレッジは増加していますか、それとも減少していますか？

---

アンチパターン

すべてを同じようにテストする

リスクに関係なく、すべての機能に同じカバレッジ目標を適用することです。設定ページに 90% の目標を設けるのは、決済や認証に割くべき労力を無駄にします。リスクモデルに基づいて割り当てましょう。

一度きりのリスク評価

計画時にマトリックスを作成し、その後更新しないことです。プロダクト、チーム、依存関係はすべて変化します。6 か月前のモデルは古く、依存関係、機能、インシデントによって状況が変わった瞬間に現状を反映しなくなります。再評価を予定に組み込み、確実に実施しましょう。

ニアミスを無視する

ステージングで検出されたバグを、単なる成功として扱うことです。重大なバグが手動テストでしか検出されなかった場合、自動化された安全網には抜けがあります。ニアミスを記録し、モデルを調整しましょう。

リスク演習の形骸化

マトリクスを埋めたり、ヒートマップを作成したりするだけで、テストの割り当てを変更しないことです。ヒートマップがあっても、テストカバレッジがそれに沿っていなければ、この作業は無駄です。整合性を四半期ごとに確認してください。Bolton の「Quality Engineering Is Not Testing」（2026-04-20）は、まさにこの問題、つまりヒートマップを作成して「QE 完了」とすることを警告しています。参考：https://developsense.com/blog/2026/04/quality-engineering-is-not-testing

過去のリスクに固執する

過去のインシデントを重視しすぎ、新しいリスク要因を軽視することです。2 年前に障害を起こしたモジュールがその後書き直されていれば、もはや高リスクではないかもしれません。一方、新たに導入したサードパーティ連携には未知のリスクがあり、注意を払う必要があります。

重大度と優先度の混同

重大度は障害がどれほど深刻かを示し、優先度はどれほど急いでテストすべきかを示します。壊滅的でもまれな障害（地震でデータセンターが破壊される）は、中程度でも頻繁に起きる障害（検索結果が時折誤る）より優先度が低い場合があります。影響度だけでなく、複合スコアを使用してください。

---

検証

完了とする前に、マトリクスが実在し、整合していることを証明してください。まずは最小限の確認から行います。

• 成果物が存在し、追跡対象になっていること： git ls-files | grep -E 'risk-matrix|qa-project-context' でファイルが返されることを確認します。誰かのノートパソコンにある未追跡のドラフトは、リスクモデルではありません。
• 対象範囲内のすべての機能がスコア付けされていること： 成果物を grep し、影響度または発生確率の数値がない行を探します。名前はあるのにスコアがない機能は、低リスクではなく漏れです。
• 上位項目に故障モード分析があること： スコアが 10 以上のすべての項目に、5 つのフィールド（Trigger、Blast Radius、Detection Method、Current Mitigation、Gap）がすべて記載されたブロックがあることを確認します。Gap 行が空の故障モードは、実際には分析されていません。
• カバレッジがヒートマップと整合していること： CRITICAL/HIGH の各機能について、Phase-5 の表で指定されたカバレッジが実際に存在することを確認します（スイートを実行し、カバレッジレポートのモジュール別数値を目標と照合します）。ヒートマップで CRITICAL とされているのに、そのモジュールのブランチカバレッジが 40% で E2E もなければ、この作業はリスク演習の形骸化です。
• 変更頻度のシグナルが最新であること： Phase-6 の変更頻度コマンドを再実行します。上位 10 位以内のモジュールで発生確率スコアが 4 未満のものがあれば、モデルが現実から乖離しています。

完了条件

• スコア付きリスクマトリクスが追跡対象の成果物として存在している（.agents/qa-project-context.md のリスクセクション、またはコミット済みの risk-matrix.md）。対象範囲内のすべての機能が、影響度（1～5）と発生確率（1～5）でスコア付けされている
• 各機能の複合スコアによって、対応するテストアクションが割り当てられた名前付きゾーン（CRITICAL、HIGH、MEDIUM、LOW）のいずれかに分類されている
• スコアが 10 以上のすべての機能について、トリガー、影響範囲、検出方法、現在の緩和策、ギャップが記録された故障モード分析が完了している
• ゾーンごとのカバレッジ要件が現在のカバレッジと照合され、各ギャップに優先度（P0～P3）、担当者、対象スプリントが割り当てられている
• 再評価のトリガーと頻度が同じ成果物に記録されている（最低でも四半期ごとに加え、本番インシデント発生後 48 時間以内）

参照ファイル（references/ 内）

• examples.md — 4 つの完全な採点済み事例（チェックアウト、メディアプラットフォーム、サードパーティ API、認証）：リスクプロファイル → 故障モード → 指定カバレッジ。

関連スキル

• test-strategy — このリスクマトリクスが反映される、複数四半期にわたる QA 戦略です。リスク評価は、より広範な戦略における 1 つの入力です。
• test-planning — 単一スプリント／リリースの計画では、今回のイテレーションで何をテストするかを決める際に、リスクの優先度を使用します。
• release-readiness — Go/No-Go の判断では、ヒートマップを参照して重要領域がカバーされていることを確認します。
• qa-metrics — 欠陥流出率と欠陥の集中状況を、リスク再評価にフィードバックします。
• ai-system-testing — Phase-3 の AI/LLM 故障クラスを緩和する評価スイートを構築します。
• qa-project-context — このスキルが利用する重要なフロー、脆弱な領域、依存関係を記録し、リスクマトリクスをここに書き戻します。