Claude CodeでPull Requestの質を10倍にする7つの実践テクニック

Pull Request はチーム開発の要です。しかし現実には「説明文が雑」「レビュー指摘が噛み合わない」「マージが遅い」といった摩擦が絶えません。Claude Code を PR フローに組み込むと、書く側・レビューする側の両方の負荷が激減します。

1. 差分から PR 説明文を自動生成

一番の時短ポイント。gh pr create の直前に Claude Code に説明文を書かせます。

git diff origin/main...HEAD | claude -p "
この diff から Pull Request 説明文を日本語で作成してください。

構造:
## 変更内容
## なぜこの変更が必要か
## レビュー時の注目ポイント
## テスト方法
## スクリーンショット（UI変更がある場合は「要添付」と記載）

トーンはチームレビュー向け。絵文字は使わない。
"

差分を読んで論点まで抽出してくれるので、書き手の思い込みが混入しません。

2. レビュー前のセルフチェック

PR を作る前に、自分でレビューしてもらう。

claude -p "
git diff origin/main...HEAD を確認し、以下の観点で指摘してください:

1. 命名が意図を表しているか
2. 関数が1つの責務に絞られているか
3. エラーハンドリングが適切か
4. テストが差分をカバーしているか
5. コメントが必要な箇所
6. CLAUDE.md の規約違反
7. セキュリティ上の懸念

重要度 高/中/低 を付けて、修正が必要なものだけ列挙してください。
"

レビュアーに指摘される前に直せるので、レビュー往復回数が半減 します。

3. レビューコメントへの返信案を生成

指摘への返答も機械的に速くなります。

gh pr view 123 --comments | claude -p "
以下のレビューコメントそれぞれに、
実装者として返信する文面を提案してください:

- 指摘を受け入れる場合: 修正方針を具体的に
- 反対する場合: 技術的根拠を添えて丁寧に
- 確認が必要な場合: 追加質問を整理

トーンは敬語、冗長にしない。
"

納得できる返信だけ採用すれば OK。

4. 巨大 PR を分割提案

大きすぎる PR はレビュー不能。Claude Code に分割を相談します。

claude -p "
現在のブランチ（feature/checkout-rewrite）には
800行の変更があります。

git diff --stat origin/main...HEAD を確認し、
論理的に分割できるなら分割案を提示:

- 依存関係がない範囲
- 独立してレビュー可能な粒度
- マージ順序
- 各 PR のタイトル案

分割できない理由があるならそれも説明してください。
"

5. レビュー視点でのコードリーディング

逆に、レビュアー側の負荷も減らせます。

gh pr checkout 456

claude -p "
このブランチの変更を以下の観点でレビューしてください:

- 変更の目的は PR 説明文と一致しているか
- 副作用のある変更を見落としていないか
- 命名やロジックの違和感
- 既存テストで十分か、追加テストが必要か
- 本番投入時の注意点

chunk 単位でコメントできる形式で出力してください。
"

GitHub の Files changed を開きながらペーストすれば、レビューコメントの下書きになります。

6. CHANGELOG と リリースノートを自動生成

マージされた PR をまとめる作業も Claude Code に。

gh pr list --state merged --base main --limit 20 --json number,title,body,mergedAt \
  | claude -p "
これら最近マージされた PR から、v1.8.0 のリリースノートを作成:

カテゴリ:
## 🎉 New Features
## 🐛 Bug Fixes
## ⚡ Performance
## 📝 Documentation
## 🔧 Internal

各項目には PR 番号 #xxx と1行説明を添えてください。
ユーザー向けなので技術用語は噛み砕いて。
"

7. PR テンプレートを Claude 親和で書く

.github/pull_request_template.md を Claude Code 連携前提で設計すると、1〜6 が回りやすくなります。

<!-- このテンプレは Claude Code で自動記入することを前提にしています -->

## 変更内容
<!-- claude -p "..." で生成 -->

## なぜこの変更が必要か
<!-- 背景とトリガー（Issue/障害/要望） -->

## レビュー時の注目ポイント
<!-- レビュアーが特に見るべき箇所 -->

## テスト方法
- [ ] 単体テスト追加
- [ ] 手動確認項目:
- [ ] スクリーンショット（UI変更時）

## セルフチェック
- [ ] CLAUDE.md の規約に従っている
- [ ] 既存テストが全て通る
- [ ] 不要なデバッグコード・コメントを削除
- [ ] シークレットを含まない

Hooks で PR フローを自動化

git push 後に自動で PR 説明文を生成する例。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Bash(git push*)",
        "hooks": [
          {
            "type": "command",
            "command": "if [ -z \"$(gh pr view 2>&1 | grep number)\" ]; then git diff origin/main...HEAD | claude -p 'PR説明文を書いて' > /tmp/pr-body.md && echo 'PR body draft saved to /tmp/pr-body.md'; fi"
          }
        ]
      }
    ]
  }
}

Hooks ガイド も参照。

やってはいけないこと

❌ AI 生成文をそのままコピペ

Claude Code の出力は叩き台。最低限、事実関係（数値・影響範囲）は自分で検証してから投稿する。

❌ レビュー返信を丸投げ

特に「反対する場合」は、技術判断の根拠を自分で理解していないと後で詰みます。

❌ 巨大 PR を押し通す

分割提案を Claude Code が出したら従うのが無難。レビュアーの認知負荷を甘く見てはいけません。

まとめ

• PR 説明文は差分から自動生成
• セルフレビューで指摘を先回り
• レビューコメント返信の下書きも AI で
• 巨大 PR は分割提案を相談
• レビュアー側もコードリーディングを加速
• CHANGELOG と リリースノートも自動化
• テンプレートを Claude 親和で設計

PR フローが速くなれば、チームの出荷頻度が上がります。

関連記事: コードレビュー / コードレビューチェックリスト / チーム開発ガイド

公式ドキュメント: Anthropic Claude Code