PR レビューコメントへの効率的な対応

Pull Request のレビューコメントを効率的に対応し、エラー分析 3 段階アプローチで根本解決を図ります。

使い方

bash
# レビューコメントの取得と分析
gh pr view --comments
「レビューコメントを優先度別に分類して対応計画を作成してください」

# エラー関連コメントの詳細分析
gh pr checks
「CI エラーを 3 段階アプローチで分析して根本原因を特定してください」

# 修正完了後の品質確認
npm test && npm run lint
「修正が完了したので回帰テストとコード品質をチェックしてください」

基本例

bash
# コメント分類の実行
gh pr view 123 --comments | head -20
"レビューコメントを must/imo/nits/q に分類して対応順序を決めてください"

# エラー情報の収集
npm run build 2>&1 | tee error.log
"ビルドエラーの根本原因を特定し、適切な修正方法を提案してください"

# 修正実装の確認
git diff HEAD~1
"この修正がレビュー指摘事項を適切に解決しているか評価してください"

コメント分類体系

text
🔴 must: 修正必須
├─ セキュリティ問題
├─ 機能バグ
├─ 設計原則違反
└─ 規約違反

🟡 imo: 改善提案
├─ より良い実装方法
├─ パフォーマンス改善
├─ 可読性向上
└─ リファクタリング提案

🟢 nits: 軽微な指摘
├─ タイポ修正
├─ インデント調整
├─ コメント追加
└─ 命名の微調整

🔵 q: 質問・確認
├─ 実装意図の確認
├─ 仕様の明確化
├─ 設計判断の背景
└─ 代替案の検討

エラー分析 3 段階アプローチ

Stage 1: 情報収集

必須実行

• エラーメッセージの完全取得
• スタックトレースの確認
• 再現条件の特定

推奨実行

• 環境情報の収集
• 最近の変更履歴
• 関連ログの確認

Stage 2: 根本原因分析

• 5 Whys 分析の適用
• 依存関係の追跡
• 環境差異の確認
• 最小再現コードの作成

Stage 3: 解決策実装

• 即座の対処 (ホットフィックス)
• 根本的解決 (本質修正)
• 予防策 (再発防止)

対応フロー

1. コメント分析: 優先度別の分類
2. 修正計画: 対応順序の決定
3. 段階的修正: Critical → High → Medium → Low
4. 品質確認: テスト・リント・ビルド
5. 進捗報告: 具体的な修正内容の説明

修正後の確認

bash
# 基本チェック
npm test
npm run lint
npm run build

# 回帰テスト
npm run test:e2e

# コード品質
npm run test:coverage

返信テンプレート

修正完了報告

markdown
@reviewer ご指摘ありがとうございます。
修正完了いたしました：

- [具体的修正内容]
- [テスト結果]
- [確認方法]

技術判断説明

markdown
実装背景：[理由]
検討した代替案：[選択肢と判断根拠]
採用案の利点：[メリット]

注意事項

• 優先度遵守: Critical → High → Medium → Low の順で対応
• テストファースト: 修正前に回帰テスト確認
• 明確な報告: 修正内容と確認方法を具体的に記述
• 建設的対話: 技術的根拠に基づく丁寧なコミュニケーション