Skills: デバッグスキル
最終更新:2026-08-31
デバッグは開発で最も時間を消費する作業——Skills がデバッグ経験を固定化し、すべてのトラブルシューティングを方法論に沿って行います。
1. デバッグ Skill のタイプ
(1) エラー診断
エラーメッセージから根本原因を特定:
YAML
---
name: error-diagnoser
description: "エラーメッセージから根本原因を診断"
triggers:
- keyword: "error|bug|crash|exception|エラー|バグ"
tools:
- Read
- Grep
- Glob
- Bash
---
(2) パフォーマンス分析
パフォーマンスのボトルネックを特定:
| 分析観点 | ツール/手法 | 出力 |
|---|---|---|
| CPU ホットスポット | プロファイラー出力 | 関数実行時間ランキング |
| メモリリーク | メモリスナップショット比較 | リークしたオブジェクトの位置 |
| スロークエリ | SQL ログ分析 | スロークエリリスト |
| 起動時間 | タイムスタンプマーカー | フェーズ別の所要時間分布 |
(3) ログ分析
ログから重要な手がかりを抽出:
MARKDOWN
## ログ分析フロー
1. ログファイルを読み込む
2. Grep で ERROR/WARN キーワードを検索
3. 例外スタックとタイムラインを抽出
4. 同一リクエストのログエントリを関連付け
5. 分析レポートを出力
2. 体系的なデバッグフロー
(1) 4段階デバッグ法
TEXT
📖 参照専用
デバッグ4段階
├── 1. 再現
│ ├── エラーが再現可能か確認
│ ├── 再現手順を記録
│ └── 再現条件を絞り込む
├── 2. 特定
│ ├── エラースタックトレースを読み込む
│ ├── 関連コードを検索
│ └── 問題の場所を確認
├── 3. 修正
│ ├── 根本原因を分析
│ ├── 修正コードを書く
│ └── 防御的チェックを追加
└── 4. 検証
├── 再現シナリオが通過
├── フルテストスイートを実行
└── リグレッションがないことを確認
(2) 二分探索による特定
MARKDOWN
## 二分探索デバッグ
1. 問題が存在するバージョン範囲を確認
2. Bash:git bisect start
3. 特定のコミットまで段階的に絞り込む
4. そのコミットの diff を Read
5. 問題を引き起こした具体的なコード行を特定
(3) 仮説駆動デバッグ
MARKDOWN
## 仮説検証法
1. 考えられる原因の仮説をリストアップ(最大3つ)
2. 各仮説の検証方法を設計
3. 最も可能性の高いものから検証
4. 検証通過 → 根本原因を確認
5. 検証失敗 → 仮説を排除し、再分析
3. 一般的なエラーパターン
(1) エラーパターン早見表
| エラータイプ | 典型的なシグネチャ | 調査方向 |
|---|---|---|
| ヌルポインタ | NoneType/null/undefined |
変数の代入チェーンを確認 |
| 型エラー | TypeError/ClassCastException |
型変換とアサーションを確認 |
| 並行性の問題 | 間欠的な失敗 | 共有状態とロックを確認 |
| 境界条件 | 特定の入力でのみ失敗 | null、ゼロ、極値を確認 |
| 環境差異 | ローカルでは動くが本番で失敗 | 設定、依存バージョンを確認 |
| タイミング問題 | 順序依存 | 非同期操作とイベント順序を確認 |
(2) エラーメッセージの読み方
TEXT
📖 参照専用
エラースタックトレースの読む順序:
1. 最下行:エラータイプとメッセージ(最も重要)
2. 下から2〜3行目:あなたのコード内の呼び出し箇所
3. 上位のスタックフレーム:フレームワーク/ライブラリの呼び出しチェーン
4. 最初の非フレームワーク行:実際のトリガーポイント
4. デバッグ Skill の実践
▶ 例:スマート診断 Skill
Alice は自動診断エラー Skill を作成しました:
YAML
---
name: smart-debug
description: "体系的デバッグ:再現→特定→修正→検証"
tools:
- Read
- Grep
- Glob
- Bash
- Edit
---
MARKDOWN
## デバッグフロー
1. エラーメッセージとスタックトレースを読み込む
2. Grep でエラーメッセージのコード内の位置を見つける
3. 関連コードを読み込み、考えられる原因を分析
4. 3つの仮説をリストアップし、1つずつ検証
5. 根本原因を確認した後、Edit で修正
6. Bash でテストを実行して検証
Bob は言います:「デバッグで最も怖いのは『とりあえず試す』こと——なぜ直ったか分からないまま修正すると、同じバグが再発する。Skills は仮説→検証のプロセスを強制し、すべてのステップを証拠に基づかせる。」
❓ よくある質問
Q AI デバッグは手動より速いですか?
A パターン化されたエラー(ヌルポインタ、型エラー、一般的な例外)では大幅に速いです。複雑なビジネスロジックの問題では、AI は範囲を絞り込めますが、最終的な特定には人間の判断が必要です。
Q AI が間違ったデバッグ方向を示すのを防ぐには?
A AI に仮説をリストアップし1つずつ検証させるよう要求し、結論に飛び越えないようにしてください。推論チェーンの各ステップを検証します。
Q デバッグ Skill には編集権限が必要ですか?
A 診断段階は読み取り専用権限のみで十分です。修正段階では Edit が必要です。2つの Skill に分割することをお勧めします:診断(読み取り専用)+修正(読み書き)。
📖 まとめ
- 3つのデバッグ Skill タイプ:エラー診断、パフォーマンス分析、ログ分析
- 4段階フロー:再現→特定→修正→検証
- 特定手法:スタックトレース分析、二分探索、仮説検証
- コア原則:行動の前に理解する、盲目的な試行ではなく仮説駆動
📝 練習問題
- 基礎問題(難易度⭐):エラースタックトレースからコード位置を自動特定するエラー診断 Skill を作成してください。
- 応用問題(難易度⭐⭐):仮説検証を組み込んだ4段階法を実装する体系的デバッグ Skill を作成してください。
- チャレンジ問題(難易度⭐⭐⭐):プロファイラー出力からボトルネックを特定し、推定影響度付きの最適化提案を示すパフォーマンス分析 Skill を作成してください。