Appearance
8. CI とレビューを確認する
概要
前の記事で作成した Pull Request に対して、CI の結果、コードの差分、レビュー結果を確認します。すべての確認を終えたら、feature ブランチの変更を develop ブランチへマージします。
CI はテストやビルドを毎回同じ手順で自動確認し、レビューでは変更の意図、読みやすさ、業務上の妥当性などを確認します。どちらか一方だけで安全になるわけではありません。自動確認とレビューを組み合わせ、問題がある変更を共有ブランチへ取り込まないことがこの章の目的です。
手順
1. CI と差分を確認する
test-and-build は、.github/workflows/ci.yml に定義されている CI の job 名です。GitHub が用意する Ubuntu 環境で、依存関係のインストール（npm ci）、テスト（npm test）、ビルド（npm run build）を順に実行します。Pull Request の Checks には、この名前で実行結果が表示されます。
Agent モードで以下の指示を与えます。
2 は、前の記事で作成した実際の Pull Request 番号へ置き換えます。
text
/review-pr 2
Pull Request の CI、差分、コミット、関連 Issue を読み取り専用で確認し、test-and-build の状態、変更が意図した2ファイルだけか、Issue の完了条件を満たすかを要約してください。
CI が未完了なら待機中と報告し、マージ、レビュー送信、ファイル変更は行わないでください。次を確認します。
test-and-buildの状態と、CI が完了しているかが報告されている- 変更が意図した2ファイルだけで、Issue の完了条件を満たしている
- CI が未完了の場合は待機中と報告されている
- マージ、レビュー送信、ファイル変更が行われていない
powershell
# 現在の GitHub リポジトリの完全な名前を取得します
$repo = (gh repo view --json nameWithOwner | ConvertFrom-Json).nameWithOwner
# develop 向けに開いている Pull Request の URL を取得します
$featurePrUrl = (gh pr list --repo $repo --base develop --state open --json url |
ConvertFrom-Json |
Select-Object -First 1).url
# Pull Request のチェックが完了するまで監視します
gh pr checks $featurePrUrl --watch
# Pull Request の変更差分を表示します
gh pr diff $featurePrUrl --repo $repobash
# 現在の GitHub リポジトリの完全な名前を取得します
repo=$(gh repo view --json nameWithOwner --jq .nameWithOwner)
# develop 向けに開いている Pull Request の URL を取得します
feature_pr_url=$(gh pr list --repo "$repo" --base develop --state open --json url \
--jq '.[0].url')
# Pull Request のチェックが完了するまで監視します
gh pr checks "$feature_pr_url" --watch
# Pull Request の変更差分を表示します
gh pr diff "$feature_pr_url" --repo "$repo"- GitHub で feature Pull Request を開きます。
- Checks を選択します。
test-and-buildの完了を待ちます。
test-and-build が成功し、Pull Request に意図した2ファイルの変更だけが含まれることを確認します。CI が成功していても、要件や変更内容が正しいとは限らないため、続けてレビューを行います。
CI が失敗している場合
CI が失敗している場合は、マージを行わず、原因を特定して修正する必要があります。GitHub Copilot と共にトラブルシューティングする場合は、以下のように指示ができます。2 は、CI が失敗した実際の Pull Request 番号へ置き換えます。
text
/review-pr 2 CIが失敗しているため原因を特定して修正してください2. レビューを依頼する
- Pull Request の Reviewers からレビュー担当者を指定します。
- Pull Request の URL と、特に確認してほしい点があればレビュー担当者へ伝えます。
GitHub Copilot code review へ依頼する場合
利用できる環境では、レビュー担当者へ依頼する前に GitHub Copilot code review で事前確認できます。
- Pull Request の右側にある Reviewers で、Copilot の横にある Request を選択します。
- レビューが完了したら、Copilot が追加した行単位のコメントと重要度を確認します。
- 指摘が妥当かを差分と Issue に照らして判断し、必要な修正を feature ブランチへ追加します。
- 修正を push した場合は、必要に応じて Reviewers から Copilot の再レビューを依頼します。
GitHub Copilot code review は、既定では Comment として送信され、通常は必須の承認数に含まれません。提案をそのまま適用せず、Issue の完了条件や既存動作と一致することを確認してください。利用条件や設定については、GitHub Docs の GitHub Copilot code review を使用するを参照してください。
3. レビューを行う
レビュー担当者の責務
この作業はレビュー担当者として行います。実装担当者とは別の視点で、Issue、CI、差分を確認し、マージしてよいかを判断します。
レビューは GitHub Web UI で行います。Web UI では変更された行を選び、その行に対して質問、問題点、修正案をコメントできます。
- 共有された Pull Request を開きます。
- Checks を開き、CI が成功していることを確認します。
- Files changed を開き、Issue の完了条件と差分を照合します。
- コメントする行の左側に表示される + を選択し、その行に対するコメントを入力します。複数のコメントをまとめて送信する場合は Start a review を選択します。
- すべてのファイルを確認したら Review changes を選択し、次のいずれかを選びます。
- Comment: 承認または修正要求をせず、フィードバックだけを送信します。
- Approve: 変更を承認します。
- Request changes: マージ前に対応が必要な修正を依頼します。
4. レビューの指摘へ対応する
作業者の責務
ここからは再び作業者が操作します。指摘の意図を確認し、必要な修正と再検証を行います。
- 行単位のコメントへ返信し、必要な修正を feature ブランチへ追加します。
- 修正後にテストとビルドを実行し、変更をコミット、push します。
- CI が再実行されたことを確認し、レビュー担当者へ再レビューを依頼します。
- レビュー担当者の承認と CI の成功がそろうまで、マージへ進みません。
個人で実施する場合は、Issue の完了条件、変更ファイル、テスト結果を自分で確認し、レビュー担当者によるレビューを省略したことを記録します。
補足: CI とレビューで確認できること
CI は、定義されたテストとビルドを同じ環境・同じ手順で繰り返し実行できます。一方で、「要件の理解が正しいか」「変更が保守しやすいか」「利用者にとって適切か」といった判断は、テストだけでは十分に確認できません。
レビュー担当者は、Issue と差分の対応、命名、読みやすさ、影響範囲、運用上のリスクなどを確認します。review-pr Skill や GitHub Copilot code review はレビュー観点をそろえるための事前確認に使えますが、担当者の承認やチームでの合意を代替するものではありません。
5. develop へマージする
必要なレビューを完了してから実行します。
マージ担当者の責務
この作業は、リポジトリでマージ権限を持つ担当者が行います。チームによって、レビュー担当者、メンテナー、実装担当者のいずれがマージするかは異なります。対象 Pull Request、CI、レビュー、ベース、ヘッドを再確認し、承認された変更だけを develop へ統合します。本ハンズオンでは、演習用リポジトリの Owner がマージ担当者を兼ねます。
- GitHub で feature Pull Request を開きます。
- Checks が成功し、必要なレビューが完了していることを確認します。
- ベースが
develop、ヘッドが feature ブランチであることを確認します。 - Pull Request の末尾でマージ方法に Create a merge commit を選択します。
- Merge pull request、Confirm merge の順に選択します。
- Delete branch が表示された場合は選択します。
6. ローカルにマージを反映
ローカルの develop ブランチを、マージ後の状態へ更新します。
Agent モードで以下の指示を与えます。
text
既存の AGENTS.md と git-workflow Skill のガードレールに従ってください。
feature Pull Request が develop へマージ済みであること、作業ツリーが clean であること、現在のブランチと origin/develop の状態を確認してください。
問題がなければローカルを develop へ切り替え、fast-forward のみで origin/develop を取り込んでください。未コミット変更、競合、履歴不整合があれば変更せず質問してください。
実行後に現在のブランチと最新コミットを報告し、push やブランチ削除は行わないでください。次を確認します。
- feature Pull Request が
developへマージ済みである - 作業ツリーが clean であり、ローカルの
developが fast-forward で更新されている - 現在のブランチと最新コミットが報告されている
- push やブランチ削除が行われていない
powershell
# ローカルの develop ブランチへ切り替えます
git switch develop
# リモートの develop ブランチを fast-forward で取り込みます
git pull --ff-onlybash
# ローカルの develop ブランチへ切り替えます
git switch develop
# リモートの develop ブランチを fast-forward で取り込みます
git pull --ff-only確認事項
- feature Pull Request の
test-and-buildが成功している - 必要なレビューが完了している
- feature Pull Request がベース
develop、ヘッドが feature ブランチの状態で Merge commit によりマージされている - ローカルの
developがorigin/developのマージ結果と同期している - 作業ツリーが clean である
まとめ
この章では、作成した Pull Request に対して「CI による自動テスト」と「レビュー」の確認を行い、feature ブランチを無事に develop へマージしました。
CI（自動テスト・ビルド）と人の目によるレビューには、それぞれ異なる役割があります。
- CI: テストやビルドが壊れていないかを、いつでも同じ基準で自動チェックします。
- レビュー: 変更の意図が明確か、読みやすく保守しやすいコードか、予期せぬ影響がないかなどを人間が判断します。
この2重のチェックを通過させることで、不具合のあるコードがチームの共有ブランチへ混入するリスクを減らせます。マージの直前には、GitHub の画面上で CI の成否やレビュー状況、マージ先（ベース）とマージ元（ヘッド）が正しいかを忘れずに確認しましょう。
補足: 実務で役立つ CI とレビューの運用
- ルールの強制（ブランチ保護ルール / Ruleset）: 「CI が成功していること」「1名以上の承認があること」をリポジトリのルールとして設定しておくと、うっかりミスによるマージを防げます。
- CI 失敗時はログを確認する: CI が落ちたときは、すぐに再実行ボタンを押すのではなく、エラーログを見て原因を特定しましょう。
- 相手に伝わりやすいレビューコメント: 単に「修正してください」と書くのではなく、「なぜ問題なのか」「どう直すと良くなるか」の理由や提案を添えると、スムーズに修正が進みます。
- 修正後の再確認: レビュー指摘に対応した後は、差分と CI の結果を自分でもう一度確認してから、レビュー担当者へ再確認を依頼します。
- マージ方針の統一: チーム内でマージ方法（マージコミット、Squash、Rebase）をあらかじめ決めておきます。本ハンズオンでは、履歴の流れがわかりやすいマージコミットを採用しています。
- マージ済みブランチの削除: 作業が終わった feature ブランチはこまめに削除し、リポジトリを整理された状態に保ちます。
参考資料:
補足: AI 駆動開発時代の CI の重要性
生成 AI が作成したコードも、人が書いたコードと同じ品質基準で確認する必要があります。テストに加えて、Linter、型チェック、静的解析、依存関係の監査などを CI で自動実行すると、書き方のばらつきや不具合、セキュリティ上の問題を早い段階で検出できます。
これらの検査はローカルでも実行し、push 前に問題を素早く見つけます。同じコマンドを CI でも実行すると、実行忘れや開発環境の違いに左右されず、チーム全体へ同じ品質基準を適用できます。ローカルは素早いフィードバック、CI は共通基準の強制という役割です。
CI の検査をマージ前の必須チェックにすると、誰がコードを作成したかに関係なく、基準を満たした変更だけを統合できます。設計や業務上の判断はレビュー担当者が確認し、機械的に確認できる項目はローカルと CI に任せることが重要です。
次は、develop に統合された変更をリリース単位で確認し、いよいよ本番公開用の main ブランチへ取り込むための Pull Request を作成します。