デバッグ支援スキル

概要

バグの原因特定から最小限の修正提案、副作用リスク評価、再発防止策までを支援するスキル。

エラーメッセージやスタックトレースから根本原因を素早く突き止める。

発動条件

「バグ」「エラー」「動かない」「おかしい」「落ちる」「クラッシュ」「TypeError」等の

不具合に関する相談を受けたとき。

デバッグ手順

Step 1: 情報収集

質問せずにまず以下を確認する:

エラーメッセージ / スタックトレースの全文

再現手順（ユーザーが提示していれば）

Step 2: エラー分類

エラーを以下のカテゴリに分類する:

| カテゴリ | 典型例 | 調査方針 |

|---------|--------|---------|

| 構文エラー | SyntaxError, Parse error | コードの該当行を確認 |

| 型エラー | TypeError, undefined is not a function | 変数の型とスコープを追跡 |

| 参照エラー | ReferenceError, NameError | import / 変数宣言の確認 |

| ランタイムエラー | 例外、クラッシュ | 実行パスの追跡 |

| 論理エラー | 期待と異なる結果 | 条件分岐とデータフローの検証 |

| 環境エラー | ENOENT, MODULE_NOT_FOUND | パス、依存、環境変数の確認 |

| 非同期エラー | Unhandled Promise, Race condition | 実行順序とエラーハンドリングの確認 |

Step 3: 根本原因の特定

スタックトレースの**最も深いフレーム**（自分のコード内）から読む

変数の値を追跡する（入力 → 変換 → 出力の各段階）

最近の変更（`git diff`）と発生タイミングを照合

「なぜこの値がここに来るのか」を逆方向に追跡する

Step 4: 修正提案

#### 修正の原則

**最小限の変更**: バグ修正に必要な箇所だけを変更する

**リファクタリングと混ぜない**: バグ修正とコード改善は別コミットにする

**元のコードの意図を尊重**: スタイルや設計方針を変えない

#### 副作用リスク評価

修正に対して以下を評価する:

この修正が他の機能に影響する可能性は？

同じパターンが他の箇所にもあるか？

修正によって新たなエッジケースが生まれないか？

Step 5: 再発防止

#### テスト提案

バグを再現するテストケースを提案

修正後にテストが通ることを確認

関連するエッジケースのテストも追加

#### 防止策

型の厳格化（TypeScript の `strict` モード等）

バリデーションの追加

エラーハンドリングの強化

コードレビューでのチェック項目追加

よくあるバグパターンと対処法

JavaScript / TypeScript

**`Cannot read properties of undefined`**: Optional chaining `?.` + nullチェック

**`Maximum call stack size exceeded`**: 再帰の終了条件を確認

**`Module not found`**: パスの大文字小文字、拡張子、exports フィールド

**React の無限ループ**: `useEffect` の依存配列に関数/オブジェクトが直接入っていないか

**Hydration mismatch**: サーバーとクライアントで異なる出力（Date, Math.random 等）

Python

**`IndentationError`**: タブとスペースの混在

**`KeyError`**: `dict.get(key, default)` を使う

**`AttributeError: 'NoneType'`**: 関数の戻り値が None のケース

**循環 import**: 遅延 import またはモジュール構成の見直し

環境系

**`ENOENT`**: ファイルパスの存在確認、相対パスの基準ディレクトリ

**`EACCES`**: ファイル権限、ポート使用状況

**`CORS`**: サーバー側のヘッダー設定

出力フォーマット

1. **原因** — 根本原因を1〜2文で（推測の場合は明記）

2. **修正コード** — diff 形式で最小限の変更

3. **副作用リスク** — 影響範囲の評価（低/中/高）

4. **確認方法** — 修正が正しいことの確認手順

5. **再発防止** — テストケース or 防止策の提案