Pull Request — 変更を他人にレビューしてもらう

学習目標

このレッスンを終えると、次のことができるようになります。

Pull Request (PR) の役割を 1 行で説明できる
良い PR のタイトル・説明文を書けるテンプレートを身につける
GitHub Web UI と gh コマンドの両方で PR を操作できる

Pull Request とは

Pull Request (PR、プルリク) = 「自分のブランチを main に取り込みたいです、レビューお願いします」という変更の依頼書。

flowchart LR P[git push feature/login] --> G[GitHub に ブランチが存在] G --> PR[PR を作る feature/login → main] PR --> R[レビュアーが diff を読む] R --> C{OK?} C -->|修正要| F[コメント → 修正 → push] F --> R C -->|承認| M[main に merge] M --> D[ブランチ削除]

PR は単なる merge 要求ではなく、チーム開発の中心となるコミュニケーション場。

PR を作るまでの流れ

1. ブランチを push してから PR を作る

git switch -c feature/login
# 作業 + commit
git push -u origin feature/login

# GitHub 上で PR を作る (3 通り)
gh pr create                       # CLI で対話的に
gh pr create --title "..." --body "..."   # CLI で直接
# または GitHub Web UI でボタンを押す

2. PR のタイトルと説明文を書く

悪い PR タイトル:

fix bug
WIP
update
修正

良い PR タイトル (動詞 + 対象 + 効果):

fix(login): ログイン後のリダイレクト先を /home に統一
feat(billing): Stripe Webhook 署名検証を追加 (#234)
chore(deps): Django を 5.1.2 → 5.1.5 に更新

ailms では Conventional Commits 風 (feat: / fix: / chore: / docs: / refactor: / test:) を慣習にしている。

説明文テンプレート:

## 概要
1-3 行で「何を変えたか」と「なぜ変えたか」

## 変更内容
- 箇条書きで具体的な変更点
- ファイル単位ではなく機能単位で

## テスト
- ユニットテスト追加・通過
- 手動テスト (シナリオを箇条書き)

## スクリーンショット (UI 変更がある場合)
変更前 → 変更後

## レビュアーへの依頼事項
特に見てほしい点・判断を仰ぎたい点

## 関連 Issue
Closes #123

3. レビューを受ける

GitHub の Files changed タブで:

行単位のコメント
まとめての「Approve / Request changes / Comment」

修正が必要なら同じブランチに追加 push すれば PR に自動反映される。

4. CI / テストの通過を待つ

ailms は GitHub Actions で自動テスト・lint・契約テストを実行する。全部緑になるまで merge できない。

5. main に merge する

flowchart LR A[Approve済] --> B{merge 方式} B -->|Squash and merge (ailms 推奨)| C[feature の commit を 1 つに圧縮して main へ] B -->|Merge commit| D[merge commit を作って 履歴を残す] B -->|Rebase and merge| E[履歴を一直線に] C --> F[ブランチ削除] D --> F E --> F

ailms は Squash and merge が標準。1 PR = 1 commit の綺麗な main 履歴を保つ。

`gh` コマンド — CLI で GitHub を扱う

GitHub 公式 CLI: https://cli.github.com/

gh pr create                       # 新規 PR 作成 (対話的)
gh pr list                         # PR 一覧
gh pr view 123                     # PR 詳細
gh pr checkout 123                 # 他人の PR をローカルで動かす
gh pr review 123 --approve         # 承認
gh pr merge 123 --squash           # squash merge
gh pr close 123                    # close (merge せず閉じる)

エディタから離れずに完結するので AI Agent と組み合わせやすい。

AI Agent に PR 作成を任せる時のコツ

flowchart LR H[人間「ログイン修正 を PR 化して」] --> AI[AI Agent] AI --> D[git diff main で 変更を読む] D --> S[要約 + テスト計画を 説明文に] S --> G[gh pr create で 下書き作成] G --> R[人間レビュー] R --> P[公開 / 修正指示]

良いプロンプト例:

このブランチの変更を gh pr create で PR 化してください。タイトルは fix(...) 形式。説明文には ① 変更内容 ② テスト計画 ③ スクリーンショット欄を含めてください。公開する前に下書きとして見せてください。

「下書きとして見せて」を忘れると AI が即公開して周りに通知が飛ぶ事故が起きる。

レビュー依頼のマナー

小さく出す: 500 行以下が読まれやすい目安
タイトルで主旨が分かる: 「修正」だけは NG
テスト計画を書く: 「動作確認しました」だけは不可
WIP は Draft PR: 完成してないなら「Draft」マークを付ける
レビューを待つ間に放置しない: 自分も他人の PR をレビューする

他の講座を見る次のプレビューレッスンへ →

全 14 レッスンを、登録なしで無料で読めます。