Test Risk Analyzer

短時間でリスク洗い出しと追加テスト案を出すための手順。全言語/フレームワーク共通で使える。

使い方（アウトプットフォーマット）

• リスク一覧: - [重大度 🔴/🟡/🟢] 領域 (file:line 任意) — リスク内容 / 重要な理由
• 追加テスト: - 種類 (unit/integration/e2e/property) — シナリオ — 期待される検証・アサーション
• 短く、重要度順に並べる。推測が含まれる場合は「assume: ...」と明記。

ワークフロー

1. 入力を確認: 目的・対象コード/差分/期待挙動を把握し、不足情報があれば短く質問。
2. 壊し方を3–5個作り、"What could go wrong?" を問う: 極端入力（例: 2万文字フォーム）、部分失敗、並行実行、通信断/遅延、スキーマずれ、LLMログのサニタイズ/監査JSON逸脱など「異常だが現実的な」壊し方を先に列挙し、正常系を前提にしない。
3. リスクを洗い出す（AIで拡張＋軽レビュー）: 壊し方ごとにAIに「何が壊れ得るか」を語らせて候補を増やし、重大度順に列挙（根拠・トリガー・file:line など簡潔に）。修正や加筆のたびに軽いレビューを挟み、リトライ/並行時の状態持ち越しや重複書き込みを重点チェック。
4. テスト追加案を提示: 各リスクに対し、対応を確認できる最小テストを書く（unit/integration/e2e/property など適切な種類）。入力例と期待結果/不変条件を明示。すぐ書けない場合は前提や依存をメモして後続タスクに残す。

メモ

• コード位置がわかる場合は file:line を添えると参照しやすい。
• テスト実装を求められたら対象言語の一般的なテストフレームワーク（pytest/Jest/RTL/JUnit等）で書く。
• 新規テストが既存挙動を固定化しすぎる場合はそのリスクを明記。

バグ発見のコツ（1行メモ）

• 壊し方を先に作る → AIで「何が壊れ得るか」を増やす → 軽レビューで状態持ち越し/並行を確認 → 壊し方を変えつつ最小テストに落とす。