バグ報告から修正・PRまでの全手順
このワークフローが有効な場面
Section titled “このワークフローが有効な場面”- ユーザーからバグが報告されたとき
- 本番でエラーが発生していて原因を急いで特定したいとき
- 自分では原因がわからないバグを調査したいとき
- 修正したつもりが再発するバグを根絶したいとき
ステップバイステップの手順
Section titled “ステップバイステップの手順”ステップ1: バグ情報を整理してClaudeに渡す
Section titled “ステップ1: バグ情報を整理してClaudeに渡す”バグを報告するとき、情報が整理されているほど早く解決できます。
プロンプト例:
「本番環境でバグが発生しています。情報を整理したので調査してください。
【症状】ユーザーが注文完了後にサンクスページに遷移するはずが、カートページにリダイレクトされる。
【エラーログ】[2026-05-20 14:32:11] ERROR: Redirect failed at OrderService.completeOrder (src/services/order.ts:87) TypeError: Cannot read properties of undefined (reading ‘id’)
【再現手順】1. カートに商品を追加2. チェックアウトページで支払い情報を入力3. 「注文確定」ボタンをクリック4. → カートページにリダイレクトされる（本来はサンクスページ /orders/[id]/complete に遷移するはず）
【発生頻度】報告: 3件 / 発生期間: 昨日から
【最近のデプロイ】昨日17時にデプロイあり（PR #234: チェックアウトフローのリファクタリング）」ステップ2: 原因の仮説を立てさせる
Section titled “ステップ2: 原因の仮説を立てさせる”プロンプト例:
「この情報をもとに、考えられる原因の仮説を3〜5つ挙げてください。可能性が高い順に並べて、それぞれ調査方法も教えてください。」ステップ3: 仮説を検証する
Section titled “ステップ3: 仮説を検証する”Claudeが提示した仮説を一つずつ確認します。
「仮説1の検証から始めましょう。src/services/order.ts の completeOrder 関数を確認してください。エラーログの87行目周辺を中心に見てください。」会話例:
Claude: `src/services/order.ts の 87行目を確認しました。
問題を発見しました：
```typescript // 修正前（バグあり） async completeOrder(cartId: string, paymentResult: PaymentResult) { const order = await this.createOrder(cartId);
// paymentResult.transactionId が undefined の場合にクラッシュ await this.recordPayment(order.id, paymentResult.transactionId);
return order; } ```
PR #234 で PaymentResult の型が変更されており、`transactionId` が `transaction_id` にリネームされましたが、ここの参照が更新されていませんでした。`
ステップ4: 修正を実施する
Section titled “ステップ4: 修正を実施する”原因が特定できたら修正します。
「原因が特定できました。修正してください。
修正方針:- paymentResult.transaction_id を使うように変更- 同様の問題が他の箇所にもないか確認- 型定義も合わせて確認」ステップ5: テストを書く（再発防止）
Section titled “ステップ5: テストを書く（再発防止）”「修正が完了しました。同じバグが再発しないよう、テストを追加してください。
テストケース:1. 正常系: 注文完了後に order.id が返る2. 異常系: paymentResult が不正な場合のエラーハンドリング3. リグレッションテスト: PR #234 で変更された型との互換性」ステップ6: 変更内容を確認してコミット
Section titled “ステップ6: 変更内容を確認してコミット”「修正とテストが完了しました。以下を確認してからコミットしてください:1. 変更内容のサマリー2. 影響範囲（他に同様の変更が必要な箇所はないか）3. コミットメッセージの案
問題なければコミットして、PRの説明文も作成してください。」エラーログを最大限活用する
Section titled “エラーログを最大限活用する”スタックトレースをそのままClaudeに渡す
Section titled “スタックトレースをそのままClaudeに渡す”「以下のエラーログを見てください。原因と修正方法を教えてください。
[ここにスタックトレースをそのままペースト]」Claudeはスタックトレースから問題のある行を特定し、コードを調べます。
ログが不十分なとき
Section titled “ログが不十分なとき”「エラーが再現しましたが、ログが不十分です。より詳細なログを出力するように、一時的なデバッグコードを追加してください。本番には入れず、ローカルで調査用として使います。」注意点・よくある失敗
Section titled “注意点・よくある失敗”失敗1: 症状を伝えずに「直して」と言う
Section titled “失敗1: 症状を伝えずに「直して」と言う”「注文がバグってる、直して」は情報が少なすぎます。再現手順・エラーログ・発生状況を必ず伝えましょう。
失敗2: 修正だけしてテストを書かない
Section titled “失敗2: 修正だけしてテストを書かない”「直った！コミット！」ではなく、必ずリグレッションテストを追加します。「同じバグが3ヶ月後に再発した」は最もつらいパターンです。
失敗3: 原因の仮説を確認せずに最初の提案を実装する
Section titled “失敗3: 原因の仮説を確認せずに最初の提案を実装する”Claudeの最初の仮説が正しいとは限りません。複数の仮説を出させて、可能性を絞り込んでから修正に入りましょう。
緊急バグ対応のショートカット
Section titled “緊急バグ対応のショートカット”本番で緊急対応が必要な場合は、フローを短縮します。
「緊急です。本番で決済エラーが出続けています。
エラー: [エラーメッセージ]直近デプロイ: [PR番号またはコミット]
まず: このエラーの原因として最も可能性が高い箇所を1つ特定してください。急いでいるので、仮説の列挙より最有力候補への集中を優先します。」