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

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チェック
• 型の整合性
• エラーハンドリングの網羅性

よくある原因パターン

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

info

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

バグの基本情報

バグの概要: {{バグの概要}} バグの種類: {{バグの種類}} 発生状況: {{発生状況}} エラー情報: {{エラー情報の有無と内容}} 再現手順: {{再現手順の有無と内容}} その他の情報: {{その他のバグ詳細情報}}

出力ファイル名: {{ベースディレクトリ}}/initial_investigation.md カレントディレクトリ: {{カレントディレクトリ}}

重要な注意事項

すべてのファイルパスは、カレントディレクトリを基準とした相対パスで記載してください。 絶対パス（/Users/... や C:\... など）は使用しないでください。 このファイルは500行以内を目標としてください。

初期調査の手順

1. バグの種類に応じた検索戦略の決定

バグの種類（{{バグの種類}}）に基づいて、適切な検索アプローチを決定する：

UI/表示バグの場合

• コンポーネントファイルの特定（.tsx, .jsx, .vue など）
• スタイル定義の確認（CSS, styled-components など）
• データバインディングの確認

ロジックバグの場合

• 関連する関数・メソッドの特定
• ビジネスロジックの所在確認
• 計算処理のコード検索

データバグの場合

• API定義の確認
• データモデルの特定
• 状態管理コードの確認

統合バグの場合

• コンポーネント間連携の確認
• API呼び出しのシーケンス
• イベントハンドラの追跡

パフォーマンスバグの場合

• 重複処理の検出
• N+1問題の確認
• 不要な再レンダリングの特定

2. エラー情報からの手がかり抽出

{{エラー情報の有無と内容}}がある場合：

• エラーメッセージから関連するコード箇所を特定
• スタックトレースから呼び出し経路を追跡
• エラーコードから該当処理を検索

3. 関連機能・コンポーネントの特定

使用するツール

• Grep: キーワード検索でコード箇所を特定
• Glob: ファイルパターンで関連ファイルを列挙
• Read: 特定ファイルの内容確認

検索キーワードの選定

• バグの概要から重要なキーワードを抽出
• 関連する関数名、クラス名、コンポーネント名
• エラーメッセージの一部

検索の実施

1. 最も可能性の高いキーワードで Grep 検索
2. 見つかったファイルを Read で確認
3. 必要に応じて追加のキーワードで検索
4. 関連ファイルを Glob で列挙

4. コードベースの構造理解

プロジェクト構造の確認

• frontend/ - フロントエンドアプリケーション
• admin/ - 管理画面
• backend/ - バックエンドAPI
• prismatix-factory/ - リソース定義

アーキテクチャパターンの理解

• BFF（Backend for Frontend）パターン
• Next.js API ルート経由のバックエンド呼び出し
• Prismatix Factory によるコード生成

5. 初期調査結果のまとめ

以下の形式で結果をファイルに出力してください。Write ツールを使用して保存してください。

# バグ初期調査結果

**実施日時**: {{実施日時}}
**分析者**: Claude Code

[← インデックスに戻る](./index.md)

---

## バグの基本情報

### 概要
{{バグの概要}}

### バグの種類
{{バグの種類}}

### 発生状況
{{発生状況}}

### エラー情報
{{エラー情報の詳細}}

### 再現手順
{{再現手順の詳細}}

---

## 関連コンポーネント・ファイル

### 主要な関連ファイル

#### [相対パス](相対パス)
- **役割**: {{このファイルの役割}}
- **関連度**: 高/中/低
- **理由**: {{なぜこのファイルが関連するのか}}
- **重要なコード箇所**:
  - 行番号: {{行番号}}
  - 内容: {{コードの概要}}

#### [相対パス](相対パス)
（同様の形式で複数記載）

### 補助的な関連ファイル

#### [相対パス](相対パス)
- **役割**: {{このファイルの役割}}
- **関連度**: 中/低
- **理由**: {{なぜこのファイルが関連するのか}}

---

## 検索キーワードと結果

### 使用したキーワード
1. `{{キーワード1}}` - XX件ヒット
2. `{{キーワード2}}` - XX件ヒット
3. `{{キーワード3}}` - XX件ヒット

### 検索結果のサマリー
{{検索結果の総括}}

---

## コードベース構造の理解

### アーキテクチャ上の位置づけ
{{このバグに関連するコンポーネントがアーキテクチャ上どこに位置するか}}

### データフローの概要
{{データがどのように流れるか}}

{{データフロー図（テキスト形式）}} 例: Frontend Component ↓ (API呼び出し) Next.js API Route (BFF) ↓ (HTTP Request) Backend API ↓ (DLL呼び出し) Prismatix Factory ↓ (SQL) PostgreSQL

---

## 初期仮説

### 可能性の高い原因候補

#### 候補1: {{原因の概要}}
- **確度**: 高/中/低
- **理由**: {{なぜこの可能性が高いのか}}
- **該当箇所**: [相対パス:行番号](相対パス#L行番号)
- **検証方法**: {{どのように検証すべきか}}

#### 候補2: {{原因の概要}}
（同様の形式で複数記載）

### 可能性の低い候補
{{可能性は低いが念のため記載する候補}}

---

## 次段階の調査方針

### 処理フロー分析で確認すべき点
1. {{確認ポイント1}}
2. {{確認ポイント2}}
3. {{確認ポイント3}}

### 追加で確認すべき情報
{{ユーザに確認したい情報があれば記載}}

---

## 制限事項

### 検出できなかった可能性のある箇所
- {{制限事項1}}
- {{制限事項2}}

---

*この初期調査結果は自動生成されたものです。次段階の処理フロー分析でさらに詳細を確認します。*

調査の注意点

• 動的な呼び出し（リフレクション、eval など）は検出が困難
• 文字列による間接的な参照は検出が困難
• コメントアウトされたコードは除外する
• テストコードも関連性があれば含める
• すべてのファイルパスは相対パスで記載する（絶対パスは使用しない）
• ファイルは500行以内を目標とする

最後に、インデックスファイル（{{ベースディレクトリ}}/index.md）も作成してください。インデックスファイルには以下の内容を含めてください：

# バグ原因分析 - インデックス

**実施日時**: {{実施日時}}
**分析者**: Claude Code

---

## バグ情報

### 概要
{{バグの概要}}

### 種類
{{バグの種類}}

---

## 分析結果ファイル一覧

### 調査段階
- [初期調査](./initial_investigation.md) - 関連コンポーネントの特定
- [処理フロー分析](./flow_analysis.md) - ※まだ実行されていません
- [詳細原因分析](./root_cause_analysis.md) - ※まだ実行されていません
- [最終レポート](./final_report.md) - ※まだ実行されていません

---

## クイックサマリー

### 初期仮説
1. {{仮説1}}
2. {{仮説2}}
3. {{仮説3}}

### 次のアクション
{{次に実施すべきこと}}

---

*分析は段階的に実施されます。各段階の詳細は上記リンクから参照してください。*

</initial_investigation_template>

<flow_analysis_template> あなたはバグ原因特定のエキスパートです。初期調査結果に基づいて、バグが発生するまでの処理フローを詳細に分析してください。

分析対象の情報

バグの概要: {{バグの概要}} バグの種類: {{バグの種類}} 初期調査結果ファイル: {{ベースディレクトリ}}/initial_investigation.md 出力ファイル名: {{ベースディレクトリ}}/flow_analysis.md カレントディレクトリ: {{カレントディレクトリ}}

重要な注意事項

すべてのファイルパスは、カレントディレクトリを基準とした相対パスで記載してください。 絶対パス（/Users/... や C:\... など）は使用しないでください。 このファイルは500行以内を目標としてください。500行を超える場合は複数ファイルに分割してください。

処理フロー分析の手順

1. 初期調査結果の確認

• {{ベースディレクトリ}}/initial_investigation.md を Read で読み込む
• 特定された関連ファイルと初期仮説を把握する
• 分析の焦点を明確にする

2. エントリーポイントの特定

UI/表示バグの場合

• ユーザーが操作する画面コンポーネント
• イベントハンドラ
• useEffect などのライフサイクルフック

ロジックバグの場合

• APIエンドポイント
• サービス層の関数
• ビジネスロジックの開始点

データバグの場合

• データ取得のAPI呼び出し
• 状態管理の初期化
• データベースクエリの発行箇所

統合バグの場合

• コンポーネント間のインターフェース
• API呼び出しの開始点
• イベント発火の起点

パフォーマンスバグの場合

• パフォーマンスボトルネックが発生する処理
• ループ処理
• 繰り返し呼ばれる関数

3. 処理フローの追跡

ステップバイステップ分析

各処理ステップについて以下を記録する：

1. ステップ番号: 処理の順序
2. ファイルと行番号: 相対パス:行番号
3. 処理内容: 何をしているか
4. 入力: どのようなデータを受け取るか
5. 出力: どのようなデータを返すか
6. 副作用: 状態変更、API呼び出しなど
7. 注目点: バグに関連する可能性のあるポイント

データの変換追跡

• データがどのように変換されるか
• 型の変更
• 値の計算
• フィルタリング、マッピングなどの操作

状態の変化追跡

• どの時点でどの状態が変わるか
• 状態変更のトリガー
• 状態の依存関係

条件分岐の分析

• 条件式の評価
• 各分岐での処理内容
• バグが発生する条件での分岐

4. 異常系の処理確認

エラーハンドリング

• try-catch ブロックの配置
• エラーの伝播経路
• エラーメッセージの生成

バリデーション

• 入力値の検証
• 境界値のチェック
• null/undefined チェック

ガード条件

• early return
• デフォルト値の設定
• フォールバック処理

5. 非同期処理の分析

Promise/async-await

• 非同期処理の順序
• awaitの有無
• Promise.allなどの並行処理

タイミングの問題

• レースコンディション
• 状態の更新タイミング
• イベントの発火順序

6. 処理フロー分析結果のまとめ

以下の形式で結果をファイルに出力してください。Write ツールを使用して保存してください。

# バグ処理フロー分析

**実施日時**: {{実施日時}}
**分析者**: Claude Code

[← インデックスに戻る](./index.md) | [初期調査](./initial_investigation.md)

---

## 分析対象

### バグの概要
{{バグの概要}}

### 分析の焦点
{{初期調査で特定された主要な関連箇所}}

---

## エントリーポイント

### [相対パス:行番号](相対パス#L行番号)

**役割**: {{エントリーポイントの役割}}

**コードスニペット**:
```{{language}}
{{関連するコードの抜粋（10行程度）}}

トリガー: {{このエントリーポイントが呼ばれる条件}}

---

処理フローの詳細

ステップ1: {{ステップの名前}}

ファイル: 相対パス:行番号

処理内容: {{この処理で何が行われるか}}

入力:

• {{変数名}}: {{型}} - {{説明}}
• {{変数名}}: {{型}} - {{説明}}

出力:

• {{変数名}}: {{型}} - {{説明}}

副作用:

• {{状態変更、API呼び出しなど}}

コードスニペット:

{{関連するコードの抜粋}}

注目点: {{バグに関連する可能性のあるポイント}}

---

ステップ2: {{ステップの名前}}

（同様の形式で各ステップを記載）

---

ステップN: {{ステップの名前}}

（処理フローの最終ステップ）

---

データフローの詳細

データ変換の追跡

{{データの変換フロー（テキスト形式）}}
例:
初期データ: { orderId: "123", items: [...] }
  ↓ (ステップ1: データ取得)
APIレスポンス: { order: {...}, total: 1000 }
  ↓ (ステップ2: データ整形)
整形済みデータ: { id: "123", amount: 1000, ... }
  ↓ (ステップ3: 状態更新)
最終状態: OrderState = { ... }

重要なデータ変換ポイント

変換1: {{変換の名前}}

• 位置: 相対パス:行番号
• 変換前: {{変換前のデータ構造}}
• 変換後: {{変換後のデータ構造}}
• 変換ロジック: {{どのように変換されるか}}
• 注目点: {{バグに関連する可能性}}

---

状態変化の追跡

状態の変更履歴

ステップ	状態変数	変更前の値	変更後の値	変更箇所
ステップ1	{{変数名}}	{{値}}	{{値}}	相対パス:行番号
ステップ2	{{変数名}}	{{値}}	{{値}}	相対パス:行番号

重要な状態変更

状態変更1: {{変更の概要}}

• タイミング: {{いつ変更されるか}}
• トリガー: {{何が変更を引き起こすか}}
• 影響範囲: {{どのコンポーネントに影響するか}}
• 注目点: {{バグに関連する可能性}}

---

条件分岐の分析

重要な条件分岐

分岐1: {{分岐の概要}}

位置: 相対パス:行番号

条件式:

{{条件式のコード}}

分岐パターン:

• 条件A（真の場合）: {{処理内容}} → ステップ{{N}}へ
• 条件B（偽の場合）: {{処理内容}} → ステップ{{M}}へ

バグ発生時の条件: {{バグが発生する場合の条件式の評価結果}}

注目点: {{バグに関連する可能性}}

---

異常系の処理

エラーハンドリングの実装状況

エラーハンドリング1: {{エラーの種類}}

位置: 相対パス:行番号

対象エラー: {{どのようなエラーを捕捉するか}}

処理内容:

{{エラーハンドリングのコード}}

問題点: {{不十分な点、改善すべき点}}

バリデーションの実装状況

バリデーション1: {{検証内容}}

位置: 相対パス:行番号

検証項目: {{何を検証しているか}}

実装の有無: ✅ 実装済み / ❌ 未実装

問題点: {{不十分な点、改善すべき点}}

---

非同期処理の分析

非同期処理の順序

{{非同期処理のシーケンス（テキスト形式）}}
例:
1. ユーザー操作
   ↓
2. API呼び出し開始（非同期）
   ↓ (await)
3. APIレスポンス受信
   ↓
4. 状態更新（同期）
   ↓
5. 再レンダリング

タイミング問題の可能性

タイミング問題1: {{問題の概要}}

位置: 相対パス:行番号

問題の詳細: {{レースコンディション、順序の問題など}}

発生条件: {{どのような条件で問題が発生するか}}

影響: {{バグへの影響}}

---

フロー分析からの所見

発見された問題点

問題点1: {{問題の概要}}

• 深刻度: 高/中/低
• 位置: 相対パス:行番号
• 詳細: {{問題の詳細説明}}
• バグとの関連: {{このバグにどう関連するか}}

問題点2: {{問題の概要}}

（同様の形式で複数記載）

次段階で詳しく調べるべき箇所

1. {{調査ポイント1}}

   • 理由: {{なぜ詳しく調べる必要があるか}}
   • 着目点: {{何に着目すべきか}}

2. {{調査ポイント2}} （同様の形式で記載）

---

この処理フロー分析結果に基づいて、次段階で詳細な原因分析を実施します。

# 分析の注意点

- 処理フローは時系列順に記載する
- 各ステップのコードスニペットは簡潔に（10行程度）
- データと状態の変化を明確に追跡する
- バグに関連する可能性のあるポイントを強調する
- **すべてのファイルパスは相対パスで記載する（絶対パスは使用しない）**
- **ファイルは500行以内を目標とする。超える場合は分割する**

分析が完了したら、インデックスファイル（{{ベースディレクトリ}}/index.md）を更新して、処理フロー分析へのリンクを有効化してください。
</flow_analysis_template>

<root_cause_analysis_template>
あなたはバグ原因特定のエキスパートです。これまでの分析結果に基づいて、バグの根本原因を特定し、詳細な検証を実施してください。

# 分析対象の情報

バグの概要: {{バグの概要}}
バグの種類: {{バグの種類}}
初期調査結果ファイル: {{ベースディレクトリ}}/initial_investigation.md
処理フロー分析ファイル: {{ベースディレクトリ}}/flow_analysis.md
出力ファイル名: {{ベースディレクトリ}}/root_cause_analysis.md
カレントディレクトリ: {{カレントディレクトリ}}

# 重要な注意事項

**すべてのファイルパスは、カレントディレクトリを基準とした相対パスで記載してください。**
**絶対パス（/Users/... や C:\\... など）は使用しないでください。**
**このファイルは500行以内を目標としてください。500行を超える場合は複数ファイルに分割してください。**

# 詳細原因分析の手順

## 1. これまでの分析結果の統合

- {{ベースディレクトリ}}/initial_investigation.md を Read で読み込む
- {{ベースディレクトリ}}/flow_analysis.md を Read で読み込む
- 初期仮説と処理フロー分析から得られた所見を統合する
- 最も可能性の高い原因候補を特定する

## 2. 原因候補の絞り込み

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

#### 未初期化変数
- 変数が使用される前に初期化されているか
- デフォルト値が適切か
- 条件付き初期化の漏れはないか

#### nullポインタ/undefined参照
- null/undefinedチェックが適切か
- オプショナルチェイニングの使用
- デフォルト値の設定

#### 配列の範囲外アクセス
- インデックスの範囲チェック
- 空配列の処理
- 境界値での動作

#### 型の不一致
- 型変換の適切性
- TypeScript/型定義の整合性
- 暗黙の型変換による問題

#### 非同期処理の問題
- awaitの漏れ
- Promise.allの適切な使用
- レースコンディション
- 状態更新のタイミング

#### ロジックの誤り
- 条件式の誤り
- 計算式の誤り
- ループの終了条件
- エッジケースの処理漏れ

#### メモリ関連
- メモリリークの可能性
- 循環参照
- イベントリスナーの解除漏れ

#### エラーハンドリングの不備
- try-catchの範囲
- エラーの伝播
- エラーメッセージの不適切さ

### バグの種類別のチェックポイント

#### UI/表示バグ
- データバインディングの誤り
- 条件付きレンダリングのロジック
- スタイルの優先順位
- useEffectの依存配列
- 再レンダリングのタイミング

#### ロジックバグ
- ビジネスルールの実装誤り
- 計算ロジックの誤り
- 条件分岐の不備
- エッジケースの考慮漏れ

#### データバグ
- データ変換の誤り
- API契約の不一致
- 状態の整合性
- キャッシュの問題

#### 統合バグ
- インターフェースの不一致
- データの受け渡しミス
- イベントの伝播問題
- トランザクション境界

#### パフォーマンスバグ
- N+1問題
- 不要な再計算
- 大量データの非効率な処理
- メモ化の不足

## 3. 詳細コード検証

### 該当箇所の徹底調査
- コードの詳細な読解
- 変数のスコープ確認
- 関数の入出力検証
- 副作用の特定

### 境界値での動作確認
- 最小値での動作
- 最大値での動作
- 空データでの動作
- null/undefinedでの動作

### エッジケースの検証
- 想定外の入力
- 極端なデータサイズ
- 並行実行
- エラー発生時の動作

## 4. 関連コードの確認

### 呼び出し元の確認
- どのような引数で呼ばれるか
- 呼び出しタイミング
- 複数回呼び出される可能性

### 呼び出し先の確認
- 依存する関数の動作
- 外部APIの仕様
- ライブラリの使用方法

### テストコードの確認
- 既存のテストケース
- テストでカバーされていない範囲
- テストが失敗していないか

## 5. 根本原因の特定

### 根本原因の定義
- 技術的な原因
- ビジネスロジックの問題
- 設計上の問題
- 実装の誤り

### 原因の検証
- コードから明らかな問題
- ドキュメントとの照合
- 仕様との整合性

## 6. 詳細原因分析結果のまとめ

以下の形式で結果をファイルに出力してください。Write ツールを使用して保存してください。

```markdown
# バグ詳細原因分析

**実施日時**: {{実施日時}}
**分析者**: Claude Code

[← インデックスに戻る](./index.md) | [初期調査](./initial_investigation.md) | [処理フロー](./flow_analysis.md)

---

## 分析サマリー

### バグの概要
{{バグの概要}}

### これまでの分析経緯
{{初期調査と処理フロー分析で判明したこと}}

---

## 原因候補の評価

### 候補1: {{原因の概要}}

**確度**: ⭐⭐⭐⭐⭐ (5段階評価)

**位置**: [相対パス:行番号](相対パス#L行番号)

**問題の詳細**:
{{技術的な問題の詳細説明}}

**該当コード**:
```{{language}}
{{問題のあるコードスニペット（20行程度）}}

問題点の指摘:

// ❌ 問題のあるコード
{{問題のある部分を抽出}}

// ✅ 期待される動作
{{本来どうあるべきか}}

なぜこれが問題か: {{この問題がバグを引き起こす理由を詳しく説明}}

バグとの関連性: {{報告されているバグ症状とどう結びつくか}}

検証内容:

1. {{検証した内容1}}
2. {{検証した内容2}}
3. {{検証した内容3}}

検証結果: {{検証から得られた確証}}

---

候補2: {{原因の概要}}

（候補1と同様の形式で記載）

---

候補3: {{原因の概要}}

（確度が低い場合も含めて記載）

---

根本原因の特定

最も可能性の高い根本原因

結論: {{根本原因の結論}}

原因の分類:

• 未初期化変数
• null/undefined参照
• 配列の範囲外アクセス
• 型の不一致
• 非同期処理の問題
• ロジックの誤り
• メモリ関連
• エラーハンドリングの不備
• {{該当する分類}}

技術的な説明: {{技術的な観点からの原因説明}}

発生メカニズム:

{{バグが発生するまでのステップバイステップの説明}}
例:
1. ユーザーが特定の操作を実行
   ↓
2. {{ファイル名}}の{{関数名}}が呼ばれる
   ↓
3. 変数{{変数名}}が未初期化のまま参照される
   ↓
4. undefinedに対して{{操作}}を実行
   ↓
5. エラーが発生またはバグが顕在化

なぜ今まで発見されなかったか: {{このバグが今まで見逃されていた理由}}

---

詳細コード検証

問題箇所の詳細分析

相対パス:行番号

コード全体:

{{問題のある関数・メソッド全体（必要に応じて40行程度）}}

問題のある部分:

{{特に問題のある5-10行を抽出}}

詳細な説明: {{行ごとの詳細な分析}}

変数の状態:

変数名	この時点での値	期待される値	問題
{{変数名}}	{{実際の値}}	{{期待値}}	{{問題点}}

実行フロー:

{{この箇所での実行フローの詳細}}

エッジケースでの動作:

• 正常系: {{正常時の動作}}
• 異常系: {{異常時の動作}} ← バグ発生
• 境界値: {{境界値での動作}}

---

影響範囲の確認

このバグが影響する範囲

直接的な影響

1. {{影響1}}

   • 影響箇所: 相対パス:行番号
   • 影響内容: {{どのような影響があるか}}

2. {{影響2}} （同様の形式で記載）

間接的な影響

1. {{影響1}}
   • 影響経路: {{どのような経路で影響するか}}
   • 影響内容: {{どのような影響があるか}}

---

関連する問題点

類似のバグの可能性

類似箇所1: 相対パス:行番号

• 類似度: 高/中/低
• 問題の内容: {{同じパターンの問題がある可能性}}
• 確認の必要性: {{確認すべきかどうか}}

設計上の問題

{{根本原因が設計に起因する場合}}

• 問題点: {{設計上の問題}}
• 影響範囲: {{どの程度広範囲に影響するか}}
• 抜本的な対策: {{どのような対策が必要か}}

---

テストケースの検証

既存テストの確認

テストファイル: 相対パス

カバレッジ状況:

• ✅ カバーされている: {{カバーされている内容}}
• ❌ カバーされていない: {{カバーされていない内容}}

このバグを検出できなかった理由: {{なぜ既存テストで検出できなかったか}}

必要なテストケース

テストケース1: {{テスト名}}

// テストの疑似コード
test('{{テスト名}}', () => {
  // Given: {{前提条件}}
  // When: {{実行内容}}
  // Then: {{期待結果}}
})

目的: {{このテストで何を検証するか}}

---

修正の方向性

推奨される修正方法

修正案1: {{修正方法の概要}}（推奨）

変更箇所: 相対パス:行番号

修正前:

{{現在のコード}}

修正後:

{{修正後のコード案}}

修正の説明: {{なぜこの修正が適切か}}

メリット:

• {{メリット1}}
• {{メリット2}}

デメリット:

• {{デメリット1}}（あれば）

影響範囲: {{この修正による影響}}

テスト方針: {{どのようにテストすべきか}}

---

修正案2: {{修正方法の概要}}（代替案）

（修正案1と同様の形式で記載）

---

応急処置と恒久対策

応急処置（短期）

{{すぐに実施できる対策}}

恒久対策（長期）

{{根本的な解決策}}

---

再発防止策

コードレベルの対策

1. {{対策1}}
2. {{対策2}}
3. {{対策3}}

プロセスレベルの対策

1. {{対策1}}（例: レビュープロセスの改善）
2. {{対策2}}（例: テストカバレッジの向上）
3. {{対策3}}（例: リント設定の追加）

設計レベルの対策

{{設計の見直しが必要な場合}}

---

参考情報

関連ドキュメント

• {{関連するドキュメントや仕様}}

外部参考資料

• {{参考になる記事やドキュメントのURL}}

---

この詳細原因分析の結果は、最終レポートで総括されます。

# 分析の注意点

- 根本原因の特定には確実な根拠が必要
- 推測と確実な事実を明確に区別する
- 複数の原因候補がある場合は確度を評価する
- 修正案は具体的なコード例を示す
- **すべてのファイルパスは相対パスで記載する（絶対パスは使用しない）**
- **ファイルは500行以内を目標とする。超える場合は分割する**

分析が完了したら、インデックスファイル（{{ベースディレクトリ}}/index.md）を更新して、詳細原因分析へのリンクを有効化してください。
</root_cause_analysis_template>

<final_report_template>
あなたはバグ原因特定のエキスパートです。これまでのすべての分析結果を統合し、包括的な最終レポートを作成してください。

# レポート作成対象の情報

バグの概要: {{バグの概要}}
分析ファイルリスト: {{分析ファイルリスト}}
最終レポートファイル名: {{ベースディレクトリ}}/final_report.md
カレントディレクトリ: {{カレントディレクトリ}}

# 重要な注意事項

**すべてのファイルパスは、カレントディレクトリを基準とした相対パスで記載してください。**
**絶対パス（/Users/... や C:\\... など）は使用しないでください。**
**このファイルは500行以内を目標としてください。**

# 最終レポート作成手順

## 1. 全分析結果の読み込み

- {{ベースディレクトリ}}/initial_investigation.md を Read で読み込む
- {{ベースディレクトリ}}/flow_analysis.md を Read で読み込む
- {{ベースディレクトリ}}/root_cause_analysis.md を Read で読み込む
- 各ファイルの内容を把握し、重要なポイントを抽出する

## 2. 情報の統合とサマリー作成

- バグの根本原因を明確にする
- 分析プロセスで得られた重要な発見をまとめる
- 修正方針と優先順位を決定する
- テスト戦略を策定する

## 3. エグゼクティブサマリーの作成

- 非技術者にも理解できる概要
- 技術的な詳細は別セクションで説明
- 結論を先に、詳細は後で

## 4. 最終レポートの出力

以下の形式で結果をファイルに出力してください。Write ツールを使用して保存してください。

```markdown
# バグ原因分析 - 最終レポート

**実施日時**: {{実施日時}}
**分析者**: Claude Code

---

## ナビゲーション

- [インデックス](./{filename}_index.md)
- [初期調査](./initial_investigation.md)
- [処理フロー分析](./flow_analysis.md)
- [詳細原因分析](./root_cause_analysis.md)

---

## エグゼクティブサマリー

### バグの概要
{{バグの簡潔な説明}}

### 根本原因
{{根本原因を1-2文で簡潔に}}

### 影響度
**深刻度**: 🔴 高 / 🟡 中 / 🟢 低

**影響範囲**: {{どの機能に影響するか}}

### 推奨される対応
**優先度**: 🔴 即座に対応 / 🟡 早急に対応 / 🟢 計画的に対応

**修正工数**: {{概算時間}}

**リリースへの影響**: {{リリースを遅らせるべきか}}

---

## バグの詳細情報

### 発生条件
{{どのような条件でバグが発生するか}}

### 症状
{{ユーザーから見えるバグの症状}}

### エラー情報
{{エラーメッセージやスタックトレース（ある場合）}}

### 再現手順
1. {{ステップ1}}
2. {{ステップ2}}
3. {{ステップ3}}
4. {{バグが発生}}

---

## 分析結果のサマリー

### 分析プロセス
1. **初期調査**: {{何を調査したか}}
2. **処理フロー分析**: {{何を分析したか}}
3. **詳細原因分析**: {{何を特定したか}}

### 主要な発見事項

#### 発見1: {{発見内容}}
- **重要度**: 高/中/低
- **詳細**: {{詳しい説明}}
- **参照**: [詳細](./{filename}_{{section}}.md)

#### 発見2: {{発見内容}}
（同様の形式で記載）

---

## 根本原因の詳細

### 技術的な原因

**分類**: {{原因のカテゴリ}}（例: null/undefined参照、ロジックの誤り、非同期処理の問題など）

**問題箇所**: [相対パス:行番号](相対パス#L行番号)

**問題のコード**:
```{{language}}
{{問題のあるコードスニペット（10-20行）}}

何が問題か: {{技術的な観点からの詳細な説明}}

なぜバグが発生するか:

{{バグ発生のメカニズムをステップバイステップで説明}}
1. {{ステップ1}}
   ↓
2. {{ステップ2}}
   ↓
3. {{バグ発生}}

ビジネスロジック上の問題

{{ビジネスロジックに関連する問題がある場合}}

設計上の問題

{{設計レベルの問題がある場合}}

---

修正方針

推奨される修正方法

概要: {{修正の概要を1-2文で}}

変更箇所: 相対パス:行番号

修正前:

{{現在のコード}}

修正後:

{{修正後のコード}}

修正の説明: {{なぜこの修正が適切か}}

変更の影響範囲:

• {{影響1}}
• {{影響2}}
• {{影響3}}

破壊的変更: ✅ あり / ❌ なし

---

代替案

{{他の修正方法がある場合}}

---

修正作業の詳細

実装ステップ

1. {{ステップ1}}

   • ファイル: 相対パス
   • 作業内容: {{具体的な作業}}
   • 所要時間: {{概算}}

2. {{ステップ2}} （同様の形式で記載）

注意点

• {{注意点1}}
• {{注意点2}}
• {{注意点3}}

---

テスト戦略

修正の検証方法

手動テスト

1. {{テストケース1}}

   • 手順: {{テスト手順}}
   • 期待結果: {{期待される結果}}

2. {{テストケース2}} （同様の形式で記載）

自動テスト

追加すべきユニットテスト:

// テストの疑似コード
test('{{テスト名}}', () => {
  // Given: {{前提条件}}
  // When: {{実行内容}}
  // Then: {{期待結果}}
})

追加すべき統合テスト: {{統合テストの内容}}

E2Eテスト: {{E2Eテストの内容}}

回帰テスト

{{既存機能への影響を確認するテスト}}

テストカバレッジ目標

• 変更箇所のカバレッジ: {{目標値}}%
• 関連箇所のカバレッジ: {{目標値}}%

---

影響範囲と関連修正

直接的な影響

相対パス:行番号

• 影響内容: {{どのような影響があるか}}
• 必要な修正: {{修正が必要か}}

間接的な影響

相対パス:行番号

• 影響内容: {{どのような影響があるか}}
• 確認事項: {{確認すべきこと}}

類似のバグの可能性

相対パス:行番号

• 類似度: 高/中/低
• 確認の必要性: {{確認すべきか}}
• 対応方針: {{どう対応するか}}

---

再発防止策

即座に実施すべき対策

1. {{対策1}}

   • 内容: {{具体的な対策内容}}
   • 実施者: {{担当者}}
   • 期限: {{期限}}

2. {{対策2}} （同様の形式で記載）

コードレベルの改善

リント設定の追加

// ESLint/TSConfig などの設定例
{{設定の追加内容}}

型定義の強化

{{TypeScriptの型定義を厳格にするなど}}

テストカバレッジの向上

{{カバレッジ目標と計画}}

プロセスの改善

コードレビュー

• {{改善ポイント1}}
• {{改善ポイント2}}

テストプロセス

• {{改善ポイント1}}
• {{改善ポイント2}}

ドキュメント

• {{改善ポイント1}}
• {{改善ポイント2}}

設計の見直し

{{設計レベルの改善が必要な場合}}

---

タイムライン

修正作業のスケジュール

フェーズ	作業内容	担当	期間	状態
1	{{作業1}}	{{担当者}}	{{期間}}	⏳ 未着手
2	{{作業2}}	{{担当者}}	{{期間}}	⏳ 未着手
3	{{作業3}}	{{担当者}}	{{期間}}	⏳ 未着手
4	{{作業4}}	{{担当者}}	{{期間}}	⏳ 未着手

総所要時間: {{合計時間}}

---

リスクと課題

既知のリスク

リスク1: {{リスクの内容}}

• 発生確率: 高/中/低
• 影響度: 高/中/低
• 対策: {{リスク軽減策}}

リスク2: {{リスクの内容}}

（同様の形式で記載）

未解決の課題

1. {{課題1}}

   • 詳細: {{課題の詳細}}
   • 対応方針: {{どう対応するか}}

2. {{課題2}} （同様の形式で記載）

---

関係者への推奨事項

開発チームへ

• {{推奨事項1}}
• {{推奨事項2}}
• {{推奨事項3}}

QAチームへ

• {{推奨事項1}}
• {{推奨事項2}}

プロダクトオーナーへ

• {{推奨事項1}}
• {{推奨事項2}}

---

付録

用語集

• {{用語1}}: {{説明}}
• {{用語2}}: {{説明}}

参考資料

• {{資料1}}
• {{資料2}}

分析ファイル一覧

1. 初期調査
2. 処理フロー分析
3. 詳細原因分析

---

結論

{{分析全体の結論を2-3段落でまとめる}}

---

分析完了日: {{日付}} 分析者: Claude Code レビュー状況: ⏳ レビュー待ち

---

このレポートは自動生成されたものです。内容についてはチームでレビューしてください。

# レポート作成の注意点

- エグゼクティブサマリーは簡潔に（1ページ以内）
- 技術的な詳細は適切なセクションに配置
- 具体的で実行可能な推奨事項を提示
- タイムラインは現実的な見積もりを
- **すべてのファイルパスは相対パスで記載する（絶対パスは使用しない）**
- **ファイルは500行以内を目標とする**

レポート作成が完了したら、インデックスファイル（{{ベースディレクトリ}}/index.md）を最終更新して、すべての分析へのリンクを有効化し、クイックサマリーを更新してください。
</final_report_template>