こんにちは、かつコーチです。
Pull Requestを提出できるようになったら、次に身につけたいのがコードレビューの進め方です。
レビューする側・される側、どちらの立場になっても困らないよう、GitHub上での基本の操作を整理しておきましょう。
この記事では、コメントの付け方から、Approve（承認）・Request changes（変更依頼）の使い分けまでを解説します。
読み終える頃には、チームのレビュー文化にスムーズに参加できるようになります。
コードレビューとは？
コードレビュー＝原稿に赤入れをしてもらう校閲
コードレビューとは、Pull Requestとして提出された変更を、他のメンバーが確認し、フィードバックを行う作業のことです。
たとえるなら、コードレビューは「書き上げた原稿に、編集者が赤入れをしてくれる校閲作業」のようなものだとイメージしてください。
執筆者は原稿（コード）を書き上げてPull Requestとして提出しますが、そのまま出版（マージ）してしまう前に、校閲者（レビュアー）が誤字脱字や表現のわかりにくさをチェックしてくれます。
赤入れされた箇所を修正し、校閲者が「これなら大丈夫」と判断して初めて、原稿は本として世に出ていきます。
GitHubのコードレビューも同じで、提出された変更に対してコメントを付け、必要な修正を経てからmainブランチへ合流させるという流れになっています。
なぜコードレビューが必要なのか
1人で書いたコードには、本人が気づきにくいミスや考慮漏れがどうしても生じます。
別の視点を持つメンバーが確認することで、バグの早期発見だけでなく、チーム内での知識共有やコーディング規約の統一にもつながります。
自分では読み返しても気づかなかった誤字が、他人の目にはすぐ見つかるのと同じ理屈です。
コードレビューの基本の進め方
手順1：Pull Requestの差分を確認する
GitHubのPull Request画面にある「Files changed」タブを開くと、変更前後の差分がハイライト表示されます。
赤入れをする箇所を探すように、追加された行（緑）・削除された行（赤）を1行ずつ確認していきます。
手順2：気になる箇所にコメントを付ける
修正してほしい行、あるいは質問したい行にカーソルを合わせると「+」マークが表示され、その行にコメントを残せます。
# レビュー対象のブランチをローカルで実際に動かして確認したい場合
git fetch origin pull/12/head:review-pr-12
git switch review-pr-12
このように、コメントだけでなく、実際に手元でブランチをチェックアウトして動作確認してからレビューすると、より精度の高いフィードバックができます。
手順3：Approve・Request changes・Commentを使い分ける
コメントを付け終えたら、「Review changes」ボタンから、以下の3種類のいずれかを選んで送信します。
- Comment：修正必須ではない感想や質問のみを伝える
- Approve：問題なしと判断し、マージを承認する
- Request changes：修正が必要と判断し、変更依頼を出す
これは、校閲者が原稿に対して「このままでOK」「ここは直してほしい」「参考までにコメントだけ」のいずれかを判断するのと同じです。
つまずきやすい設定・注意点
「Request changes」を選ぶと、多くのリポジトリ設定では、その変更依頼が解消されるまでマージがブロックされます。
軽微な提案であれば「Comment」、必須の修正であれば「Request changes」と、使い分けを意識しましょう。
よくあるつまずきポイント・エラー対処
コメントだけで済ませて修正漏れが起きた話
私が実際にチームでのレビューを経験して学んだのが、このケースです。
❌ Before
セキュリティ上、明らかに直してほしい箇所を見つけたのですが、強い言い方を避けたくて「Comment」として軽い提案のように書いてしまいました。
ここ、SQLインジェクションの対策入れたほうがいいかもです〜
提出者は「参考コメント」だと受け取り、そのまま修正されずにマージされてしまいました。
赤入れのつもりが、ただの感想として読み流されてしまったのです。
✅ After
以降は、修正が必須の指摘には必ず「Request changes」を選び、コメント本文にも理由を明記するようにしました。
[Request changes]
SQL文の組み立てにユーザー入力を直接連結している箇所があります。
プレースホルダを使ったクエリに変更してから、再度レビューをお願いします。
「これは必須修正である」ということが伝わる形で送るようにしたところ、修正漏れがなくなりました。
この経験から、レビューでは指摘の重要度に応じて機能（Comment / Request changes）を正しく使い分けることが大切だと学びました。
応用・一歩先の使い方
レビューコメントにコード提案（suggestion）を添える
GitHubのレビューコメントでは、suggestionというコードブロックを使うことで、修正案をそのままボタン1つで取り込んでもらえる機能があります。
```suggestion
const query = "SELECT * FROM users WHERE id = ?";
```
これは、校閲者が赤入れするだけでなく、「この表現に直すと良いですよ」と修正済みの文章そのものを渡してくれるようなものです。
提出者は「Commit suggestion」ボタンを押すだけで、提案内容をそのまま自分のブランチに反映できます。
まとめ
この記事のポイント
- コードレビューとは、提出された原稿（コード）に対する「校閲」のような作業
- Files changedタブで差分を確認し、気になる行にコメントを残す
- Comment・Approve・Request changesは、指摘の重要度に応じて使い分ける
suggestionブロックを使うと、修正案をワンクリックで反映してもらえる
次に読むべき記事
レビューの流れに慣れたら、次はチーム内だけでなく、社外のOSSプロジェクトへの貢献方法も見てみましょう。
「フォークとPull Requestで進めるOSS貢献の流れ」で、自分のリポジトリを持たないプロジェクトへの提案方法を解説しています。