/bug-analysis

description: バグの原因を特定するための詳細分析を実施する
allowed-tools: Read, Glob, Grep, Task, Bash, AskUserQuestion
argument-hint: "[バグの概要（任意）]"

バグの発生経緯や症状から原因を特定し、修正方針を提示します。ソースコードを詳細に分析し、段階的に原因を絞り込みます。

context

出力ディレクトリ=".dcs" カレントディレクトリ={{プロジェクトルート}} 分析ファイルリスト=[] 調査段階=1

step

• $1 がある場合、その内容を簡潔に説明する
• step1 を実行する

step1: 初期情報収集

• AskUserQuestion ツールを使って以下の質問を順番に実施し、context を更新する：

1. バグの種類を確認 2. バグの発生状況を確認 3. エラー情報の有無を確認 4. 再現手順の有無を確認

• 収集した context の内容をまとめてユーザに宣言する
• step2 を実行する

step2: 初期調査の実行

• 既存の出力ファイルを確認して、重複しないナンバリングを決定する
• {{出力ディレクトリ}}/{{timestamp}}_*/ を検索
• バグの内容を簡単に英語化したもの（例: "order_total_bug", "cart_display_issue"）を作成
• 同じ timestamp と内容で既存ディレクトリがある場合、末尾の連番を +1 する
• ベースディレクトリを "{{出力ディレクトリ}}/{{timestamp}}_{{内容の英語化}}" とする
• 例: ".dcs/20251025_143022_order_total_bug"
• 分析結果ファイルのリストを準備する
• インデックスファイル: "{{ベースディレクトリ}}/index.md"
• 初期調査ファイル: "{{ベースディレクトリ}}/initial_investigation.md"
• 処理フロー分析ファイル: "{{ベースディレクトリ}}/flow_analysis.md"
• 詳細原因分析ファイル: "{{ベースディレクトリ}}/root_cause_analysis.md"
• 最終レポートファイル: "{{ベースディレクトリ}}/final_report.md"
• すべてのファイル名を 分析ファイルリスト に追加する
• <initial_investigation_template> の内容を context の情報で埋めて、Task ツールで直接実行する
• subagent_type: "general-purpose"
• description: "バグ初期調査の実行"
• prompt: テンプレートの内容を context で埋めた完全なプロンプト
• Task の実行結果を受け取る
• step3 を実行する

step3: 処理フロー分析の実行

• 初期調査結果を Read で確認する
• 追加で確認すべき情報があるかユーザに確認する
• ユーザの承認を得てから続行する
• <flow_analysis_template> の内容を context と初期調査結果で埋めて、Task ツールで実行する
• subagent_type: "general-purpose"
• description: "バグ処理フロー分析の実行"
• prompt: テンプレートの内容を埋めた完全なプロンプト
• Task の実行結果を受け取る
• step4 を実行する

step4: 詳細原因分析の実行

• 処理フロー分析結果を Read で確認する
• <root_cause_analysis_template> の内容を context とこれまでの分析結果で埋めて、Task ツールで実行する
• subagent_type: "general-purpose"
• description: "バグ詳細原因分析の実行"
• prompt: テンプレートの内容を埋めた完全なプロンプト
• Task の実行結果を受け取る
• step5 を実行する

step5: 最終レポートの作成

• <final_report_template> の内容を使って、Task ツールで最終レポートを作成する
• subagent_type: "general-purpose"
• description: "バグ分析 最終レポートの作成"
• prompt: テンプレートの内容を context で埋めた完全なプロンプト
• 最終レポートファイル名: "{{ベースディレクトリ}}/final_report.md"
• 全ての分析ファイルのパスを段階別に整理して表示する
• 初期調査ファイル
• 処理フロー分析ファイル
• 詳細原因分析ファイル
• 最終レポート
• 分析完了をユーザに報告する

rules

確認ポイント

AskUserQuestion ツールを使って、以下の質問を順番に実施する：

質問1: バグの種類

• **質問**: このバグはどのカテゴリに該当しますか？
• **header**: "バグ種類"
• **multiSelect**: true
• **options**:
• "UI/表示バグ" - 画面表示、レイアウト、スタイルの問題
• "ロジックバグ" - ビジネスロジック、計算処理、条件分岐の問題
• "データバグ" - データベース、API、状態管理の問題
• "統合バグ" - コンポーネント間連携、外部システム連携の問題
• "パフォーマンスバグ" - 処理速度、メモリ使用量の問題

質問2: バグの発生状況

• **質問**: バグはどのような状況で発生しますか？
• **header**: "発生状況"
• **options**:
• "常に発生" - 特定の操作で必ず発生する
• "特定条件で発生" - 特定のデータや状態でのみ発生する
• "間欠的に発生" - 再現性が低く、たまに発生する
• "環境依存" - 特定の環境でのみ発生する

質問3: エラー情報の有無

• **質問**: エラーログやエラーメッセージはありますか？
• **header**: "エラー情報"
• **options**:
• "あり（詳細）" - スタックトレースやエラーメッセージがある
• "あり（簡易）" - エラーメッセージのみある
• "なし" - エラー情報はないが動作がおかしい

質問4: 再現手順の有無

• **質問**: バグを再現する手順は明確ですか？
• **header**: "再現手順"
• **options**:
• "明確" - 確実に再現できる手順がある
• "おおよそ" - 大まかな手順はわかるが確実ではない
• "不明" - 再現手順がわからない

contextとして以下を保持する：

• バグの概要
• バグの種類
• 発生状況
• エラー情報の有無
• 再現手順の有無
• その他のバグ詳細情報

ファイル名のルール

timestamp の形式

• yyyyMMddHHmmss 形式（例: 20251025143022）

内容の英語化のルール

• バグの内容を簡潔な英語に変換する
• スネークケース（snake_case）を使用
• 最大30文字程度に収める
• 例:
• "注文合計の計算バグ" → "order_total_bug"
• "カート表示の問題" → "cart_display_issue"
• "決済エラー" → "payment_error"
• "パフォーマンス問題" → "performance_issue"

セクション別ファイル名のルール

• 分析結果は段階ごとに分割し、各ファイル500行以内を目標とする
• ファイル一覧:
• `_index.md` - インデックス（全体概要とファイル一覧）
• `_initial_investigation.md` - 初期調査結果
• `_flow_analysis.md` - 処理フロー分析
• `_root_cause_analysis.md` - 詳細原因分析
• `_final_report.md` - 最終レポート

完全なファイル名の例

• `.dcs/20251025143022_order_total_bug/index.md`
• `.dcs/20251025143022_order_total_bug/initial_investigation.md`
• `.dcs/20251025143022_order_total_bug/flow_analysis.md`
• `.dcs/20251025143022_order_total_bug/root_cause_analysis.md`
• `.dcs/20251025143022_order_total_bug/final_report.md`

ファイルパスの記載ルール

• **カレントディレクトリを基準とした相対パスを使用する**
• フルパス（絶対パス）は記載しない
• 例:
• ❌ `/Users/makotan/projects/ensemble-si/src/utils/helper.ts`
• ✅ `src/utils/helper.ts`
• カレントディレクトリは分析開始時の作業ディレクトリ
• すべてのファイルパスは相対パスで統一する

バグの種類別分析アプローチ

UI/表示バグ

• コンポーネントの構造とプロパティ
• スタイル定義とCSS適用状況
• データバインディングの確認
• 条件付きレンダリングの検証
• ブラウザ互換性の確認

ロジックバグ

• 関数・メソッドの入出力
• 条件分岐のロジック
• 計算処理の精度
• エッジケースの処理
• エラーハンドリング

データバグ

• データフローの追跡
• API呼び出しとレスポンス
• 状態管理の整合性
• データベースクエリ
• データ変換処理

###統合バグ

• コンポーネント間のデータ受け渡し
• イベント伝播
• API連携のシーケンス
• 非同期処理のタイミング
• トランザクション境界

パフォーマンスバグ

• N+1問題の検出
• 重複処理の特定
• 不要な再レンダリング
• メモリリークの可能性
• 非効率なアルゴリズム

原因特定のための観点

コード解析の観点

1. **制御フロー**: 条件分岐、ループ、例外処理 2. **データフロー**: 変数の生成、変換、利用 3. **依存関係**: モジュール間、関数間の依存 4. **副作用**: 状態変更、外部システムへの影響 5. **タイミング**: 非同期処理、イベント順序

検証すべきポイント

• 入力値の検証
• 境界値の処理
• nullチェック
• 型の整合性
• エラーハンドリングの網羅性

よくある原因パターンとの照合方法

**重要**: 以下は参考リスト。すべてを機械的にチェックするのではなく、バグ症状・エラー情報から関連性の高いパターンを2-3個選択し、実際のコードで該当箇所を探す。該当箇所が見つかった場合のみ候補として記載し、見つからない場合は除外する。

よくある原因パターン（参考）

• 未初期化変数の使用
• nullポインタ参照
• 配列の範囲外アクセス
• 型の不一致
• 非同期処理の競合
• メモリリーク
• 無限ループ
• 不適切なエラーハンドリング

候補記載の品質基準

確度評価の基準（⭐ 1-5段階）

• ⭐⭐⭐⭐⭐: コードで問題を確認済み、バグ症状と完全に一致、再現性の説明が可能
• ⭐⭐⭐⭐: コードで問題を確認済み、バグ症状とほぼ一致
• ⭐⭐⭐: コードで問題を確認済み、バグ症状と部分的に一致
• ⭐⭐: コード上の問題を確認したが、バグとの関連は推測の域
• ⭐: 一般的なパターンに該当するが、コード上の明確な証拠なし

**重要**: ⭐⭐未満の候補は記載しない。コード上の証拠がない候補は推測と見なし除外する。

候補記載の絶対条件

候補を記載するには、以下すべてを満たす必要がある： 1. コードベースで具体的な該当箇所を特定できた（ファイル:行番号） 2. バグ症状との関連性を論理的に説明できる 3. 実際のコードで問題の存在を確認した 4. 確度が⭐⭐以上

上記条件を満たさない候補は記載しない。推測のみの候補、一般論、ベストプラクティスの列挙は不要。

info

<initial_investigation_template> あなたはバグ原因特定のエキスパートです。以下の情報に基づいて、バグの初期調査を実施し、関連するコード箇所を特定してください。

重要な分析方針

**網羅性と品質のバランス**:

• ✅ 可能性のある原因を幅広く調査する（網羅性）
• ✅ ただし、コード上の証拠がない推測は記載しない（品質）
• ❌ 一般論やベストプラクティスの列挙は不要
• ❌ 「このような問題が起こりうる」という可能性の羅列は不要

**候補記載の絶対条件**: 1. コードベースで具体的な箇所を特定できた 2. バグ症状との関連を論理的に説明できる 3. 確度が⭐⭐以上（コード上の証拠がある）

上記を満たさない候補は、たとえ一般的なパターンでも記載しない。

バグの基本情報

バグの概要: {{バグの概要}} バグの種類: {{バグの種類}} 発生状況: {{発生状況}} エラー情報: {{エラー情報の有無と内