GitHub CopilotにPull Requestを自動レビューしてもらう

2026年9月17日

GitHubでは、Pull Requestを作成したときに、GitHub Copilotにコードを自動レビューしてもらうことができます。

チーム開発では、コードを書いたらすぐにmainへ入れるのではなく、

作業ブランチで修正
↓
Commit
↓
Push
↓
Pull Request
↓
レビュー
↓
Merge

という流れで進めます。Copilotの自動レビューを使うと、この「レビュー」の段階でAIにもコードを確認してもらえます。mainブランチを直接更新してしまう事故については、「新人がmainを直接更新してしまった！」なぜブランチ保護が必要なのかでも解説しているので、あわせて参考にしてください。

Copilotコードレビューとは？

Copilotは、コードを書くためだけの機能ではありません。Pull Requestに含まれている変更を確認して、

• バグになりそうな部分
• 分かりにくいコード
• セキュリティ上気になる部分
• 書き方の不整合
• 改善できそうな部分

などをコメントしてくれます。

例えば、自分では問題ないと思って書いたコードでも、Copilotから、

この条件では一部のデータを処理できない可能性があります

のような指摘を受けることがあります。

大切なのは、指摘されたコードをそのまま直すことではありません。「なぜこの指摘を受けたのか」を考えることが重要です。

自動レビューを設定するとどうなる？

通常はPull Requestを作成したあと、自分でCopilotをレビュアーとして指定する必要があります。しかし、リポジトリにルールを設定しておくと、

Pull Requestを作成
↓
Copilotが自動でレビュー

という動きにできます。毎回レビューを依頼する操作をしなくても、自動的にCopilotが確認してくれるようになります。GitHubではRulesetという仕組みを利用して設定できます。

設定の考え方

設定する場所は、リポジトリのSettingsです。そこからブランチ用のRulesetを作成し、mainなどの対象ブランチに対して、

Automatically request Copilot code review

を有効にします。すると、そのルールに該当するPull RequestでCopilotレビューが自動的に実行されます。

授業では、設定そのものを暗記する必要はありません。まずは、「Pull Requestを作成すると、自動的にCopilotが確認してくれる仕組みを作れる」ということを理解しておきましょう。

修正後のコードもレビューできる

Pull Requestを作ったあとで、Copilotから指摘を受けたとします。そのコードを修正し、もう一度Pushすることがあります。

Pull Request
↓
Copilotレビュー
↓
修正
↓
Commit
↓
Push

設定によっては、この新しいPushについてもCopilotに再レビューしてもらうことができます。つまり、

レビュー
↓
修正
↓
再レビュー

という流れを繰り返すことができます。

Copilotがいれば人間のレビューはいらない？

いいえ。授業では、Copilotレビューと人間のレビューの両方を行います。イメージは次のようになります。

Pull Request
↓
Copilotレビュー
↓
コードを修正
↓
チームメンバーがレビュー
↓
Approve
↓
Merge

Copilotは便利ですが、コードを書いた本人が何を考えて実装したのかまでは完全には分かりません。また、Copilotの指摘が必ず正しいとも限りません。そのため、

CopilotがOKと言った
↓
だからそのままMerge

とはしません。人間もコードを確認します。実際にチームでPR・レビューを回す様子は4人で作るPR・レビュー付きチーム開発で紹介しています。

Copilotの役割

授業では、Copilotを次のように考えてください。

Copilot
＝
コードを一緒に確認してくれる補助役

Copilotに全部任せるのではなく、

自分でコードを書く
↓
自分で確認する
↓
Copilotにも確認してもらう
↓
指摘内容を考える
↓
チームメンバーにも確認してもらう

という使い方をします。

なぜ自動レビューを使うの？

理由の一つは、レビューを忘れにくくするためです。人間だけで運用すると、

レビューをお願いするのを忘れた

ということが起こります。自動レビューを設定しておけば、

Pull Requestを作る
↓
自動でCopilotレビュー

となるため、確認する仕組みを作ることができます。チーム開発では、「気を付ける」だけではなく、「仕組みでミスを減らす」という考え方が重要です。

mainを守る仕組みと組み合わせる

これまで学習してきたように、mainブランチへ直接変更を入れないためには、Branch rulesやRulesetを利用できます。設定の詳しい手順はGitHub Rulesetsでmainブランチを保護するやGitHubでmainブランチを守ろうで紹介しています。例えば、

mainへ直接Pushしない
↓
Pull Requestを作る
↓
Copilotがレビュー
↓
人間がレビュー
↓
Merge

という仕組みにできます。これなら、「mainを直接変更しないように気を付けてください」と注意するだけではありません。GitHub側の仕組みを使って、チームのルールを守りやすくできます。

授業で大切なこと

Copilotのレビューで最も大切なのは、指摘された内容を理解することです。例えばCopilotから修正案が出たときに、

よく分からないけど、そのまま修正する

では学習になりません。次のように考えてください。

なぜ指摘された？
↓
今のコードの何が問題？
↓
修正すると何が変わる？
↓
自分で説明できる？

自分で説明できるところまで確認することが大切です。Copilot以外のAIコーディングツールとの違いが気になる人は、結局どれを使えばいい？AIコーディングツール選び方ガイドも参考にしてください。

まとめ

GitHub Copilotには、Pull Requestのコードをレビューする機能があります。さらに設定を行うことで、Pull Requestを作成したときに自動的にCopilotレビューを実行できます。

授業では、

作業ブランチで開発
↓
Commit
↓
Push
↓
Pull Request
↓
Copilotレビュー
↓
人間のレビュー
↓
Merge

という流れを経験します。

Copilotを使う目的は、「自分でコードを読まなくてよくすること」ではありません。むしろ、「自分のコードをもう一度見直すきっかけを増やすこと」です。

チーム開発では、人が気を付けるだけでなく、仕組みを使ってミスを減らすという考え方も重要です。Copilotの自動レビューも、そのための仕組みの一つです。mainブランチを守る仕組み全体については、「新人がmainを直接更新してしまった！」なぜブランチ保護が必要なのかもあわせてご覧ください。