bug-analysis

Bug 分析（bug-analysis）

確認済みの Bug の根本原因を特定し、影響を分析して、回帰テストを提案します。

• 入力：Bug レポート（現象＋再現手順＋証拠）、コードリポジトリ、（任意）要件モデル／テストケース；一括実行の場合、A 類の項目は失敗振り分け表（../core/triage.md の成果物）から取得できます。項目に付随する G/S シグナルの概要と evidence フィールドが再現の出発点になります
• 出力（ファイルへの保存）：Bug 項目（以下の構造を参照）、テストレポートに追加（../core/report-template.md §3 の根本原因分析／影響範囲／Severity の根拠／修正提案／回帰テスト提案の 5 つの拡張フィールドが、この skill の記入範囲です）
• 範囲：入力は確認済みの Bug（ユーザーまたは実行結果によって「これは欠陥である」と確定済み）；レビューで見つかった疑わしい欠陥（未検証）は test-case-writing の Cx 記録に分類し、回帰の範囲選択は regression-testing に分類します

使用するタイミング

• Bug が確定しており、根本原因を特定する必要がある（ファイル:行 の分岐点まで読み解く）
• Bug の影響範囲（同じ根本原因による他の経路／不正データ／影響を受けるユーザー）を評価する必要がある
• 修正後に回帰テストの用例を提案する必要がある（修正の検証＋関連する回帰テスト）

使用しないタイミング

• まだ確定していない（「これは Bug ですか、それとも仕様ですか？」）→ 先にユーザーの判断を仰ぎます（Bug 判定チェックポイントは qa を参照）；証拠収集の段階 → automated-e2e-testing ワークフロー二／api-testing
• コードレビューで見つかった疑わしい欠陥（未再現、未確定）→ test-case-writing の Cx 欠陥記録（実測による確認待ち）
• 回帰テストの一覧（実行する用例）を作成する必要がある → regression-testing（この skill が出力するのは回帰テストの用例提案です）
• エンドツーエンドのパイプライン → qa がオーケストレーションします（この skill はその第 6 段階です）

Bug 項目の構造（テストレポートに追加）

項目のフィールドと記入テンプレートの唯一の参照元は ../core/report-template.md §3です（この段階で読み込みます）。この skill では記入の意味を補足するだけです。

• この skill の記入範囲：根本原因分析／影響範囲／Severity の根拠／修正提案／回帰テスト提案の 5 つの拡張フィールド（レポート §3 の「再検証ラウンド」以外の 8 つの基本フィールド——重大度／状態（初期値は「新規」。以降は回帰テストの結果に応じて更新します。../core/report-template.md の使用規約 6 を参照）／発見方法／再現手順／期待動作／実際の動作／証拠／環境——は発見者が記入済みのため、書き直しません）
• 根本原因分析には status を明記する必要があります：Inference（コードを読んだ推論で、実行による検証は未実施）または Verified（再現／最小実験で検証済み、E3）——推論を事実として偽ってはいけません（状態の意味は ../core/evidence.md 第 3 節を参照）
• 影響範囲／Severity の根拠には項目ごとに出典を記載し、証拠の連鎖には evidence レベル（E0–E4＋ファイル:行）を明記します

ワークフロー

1. 再現（まず安定した証拠を得る）

• Bug レポートの手順に従って再現します。再現できない場合は、無理に分析せず、「環境差異／データ依存／確率的な発生」を切り分け、ユーザーに環境やデータに関する手がかりを求めます
• 再現中に証拠を収集します：リクエスト／レスポンスの原文、ログ、スクリーンショット（E3 実行証拠）
• 確率的 Bug への戦術：再現頻度が低い場合、無理に待ち続けません——① ベースラインの定量化：まず十分なサンプル数を実行し、再現頻度のベースラインを作ります（N≥10 回の記録で発生回数を記録します。例：「N≥10 回中 2 回発生」）。修正後に同じ条件で再検証して比較し、単発の成功を修正済みと誤判定するのを防ぎます；② 狙いを定めた発生頻度の引き上げ：次の 3 種類を実施します。並行処理に関する問題は並行度を上げる／操作間隔を短くして再実行します。時間に関する問題は、タイムゾーン／日付変更／秒境界の時刻に集中して発生させます。環境に関する問題は、デバイス／データ／ネットワーク条件を変えて比較し、発生要因を切り分けます

2. コードを読んで根本原因を特定する

• 現象の発生箇所（画面／API）から下流を追跡します：入口 → 呼び出しチェーン → データの読み書き。具体的な動作と期待動作が分岐する箇所（ファイル:行）を特定します
• よくある根本原因の種類を確認します：境界チェックの不足／null のフォールバック不足／状態の競合／トランザクションの不備／キャッシュの不整合／権限判定の漏れ／並行処理による上書き／設定のずれ
• 根本原因の結論には status を明記します：Inference（コードからの推論で、実行による検証は未実施）または Verified（再現／最小実験で検証済み、E3）——推論を事実として偽ってはいけません

3. 影響分析（5 つの観点）

• 機能面：同じ根本原因が影響する他の入口／経路（同じパターンがある他の呼び出し箇所を grep します）
• データ面：不正データがすでに発生しているか、既存データのうち影響を受ける範囲
• ユーザー面：影響を受けるロールと操作経路
• セキュリティ面：この欠陥が悪用可能な隙を生むかどうか（権限を超えたアクセスが可能／機密データの露出／インジェクションの攻撃面）——該当する場合、Severity を 1 段階引き上げます（S2→S1、S1→S0、S0 は上限）。第 4 ステップのレベル判定ルールとの役割分担に注意してください。セキュリティ面は潜在的な隙を引き上げる際に使います。すでに実際のセキュリティ上の被害（データ損失／資産の損害／実際に権限を超えた操作が行われた状態）が発生している場合は、直接 S0 とし、引き上げの基準は適用しません
• 修正による影響範囲：想定される修正で変更されるコード／設定／データ——修正自体によって変わる動作が、回帰テスト提案への直接の入力になります（第 5 ステップにつながります）

4. レベル判定と修正提案

• Severity は結果に基づいて分類します（S 系と用例優先度 P 系は別系統です）：データ損失／資産の損害／実際のセキュリティ上の被害（実際に権限を超えた操作によるデータ露出など）→ S0；コア機能の主経路が利用できない → S0、コア機能の迂回経路が利用できない → S1；一部の機能が低下 → S1；ユーザー体験の問題 → S2。悪用可能な潜在的な隙にとどまるセキュリティ問題は S0 まで引き上げず、第 3 ステップのセキュリティ面に従って 1 段階引き上げます（2 か所の基準を相互に照合し、同じ問題に二重のルールが適用されるのを防ぎます）
• 修正提案では方向性を示します（例：「インポート経路に、作成経路と同じ検証を追加する」）。範囲を越えて開発者の代わりにパッチを書いてはいけません

5. 回帰テストの提案（regression-testing につなぐ）

• 修正検証用例：この Bug を直接再現する用例（ない場合は追加を提案し、TC 番号の案を示します）。追加を提案する用例は、../core/case-format.md の形式と ../core/executability.md の実行可能性基準に従って記述し、用例ファイルに追加すれば実行できるようにします
• 関連する回帰テスト：同じ根本原因パターンを持つ他の経路＋その機能のアンカー用例
• 相互リンク：この項目の番号を、対応する回帰テスト一覧の「関連 Bug」行に記載し、一覧にある修正検証用例の TC 番号を、この項目の「回帰テスト提案」に記入します——Bug 一覧と回帰テスト一覧を相互に追跡できるようにします（一覧側のテンプレートは regression-testing を参照）
• 回帰テストの範囲選択（実行する既存用例とその分類）は regression-testing に引き継ぎます

6. ファイルへの保存

単独の段階として使用する場合：Bug 項目をテストレポートの該当項目に追加します（根本原因分析など 5 つの拡張フィールドを補います）。レポートがない場合は、../core/report-template.md に従ってレポートファイルを新規作成できます。パイプラインの Bug 分析段階として実行する場合：最終テストレポートを新規作成または書き換えません——項目はすべて {プロジェクト}/Bug条目_{日付}.md の中間ファイルに記載し、オーケストレーションの終了段階で組み立てます。終了レポートと同名のファイルに二重書きして、データソースが二重になるのを防ぎます。

• 知識の蓄積判定（終了時に必ず実施）：今回の根本原因と修正方法が qa-memory の書き込み基準（「3 か月後に新しいセッションで再テストしたとき、再発見の手間を 1 回分省ける」）を満たす場合、その手順に従ってプロジェクトの .qa/ ナレッジベースに defect 項目として蓄積します（evidence はこの Bug 項目を参照します）。後続のセッションで直接再利用できます

よくある間違い

間違い	結果	正しい方法
再現前に分析を始める	根本原因が想像に基づくものになる	まず再現して E3 証拠を取得します。再現できない場合は、まず手がかりを求めます
根本原因の推測を事実として確定する	誤った結論が広まる	status に Inference/Verified を明記します（../core/evidence.md）
現象を根本原因として扱う（「API がタイムアウトする。根本原因：API のタイムアウト」）	分析が空回りする	動作と期待動作が分岐する ファイル:行 まで追跡します
影響範囲を単一箇所だけで確認する	同じ根本原因による他の経路の修正・テスト漏れが生じる	同じパターンを grep し、機能／データ／ユーザー／セキュリティ／修正による影響の 5 つの観点から分析します
範囲を越えてパッチコードを書く	役割を越え、開発の妨げになる	修正の方向性と検証方法を提案します
回帰テストの範囲選択まで行う	regression-testing の役割と重複する	この skill では回帰テストの提案を行い、範囲選択は引き継ぎます
未確定の疑わしい欠陥をそのままこのフローに進める	Cx 記録の役割と混同する	入力は確認済みの Bug に限定します。未確定の場合は、先に判断を仰ぎます