チームで GitHub Copilot code review を全PRに自動で入れるようにし、去年12月ごろから数か月運用してきました。
狙いはシンプルで、レビュアーが見る前にPRの質を上げて、人によるレビューの時間を減らすことです。
実際にやったこと自体は、全PRで自動レビューを入れる設定と、copilot-instructions の整備が中心です。この記事では、その設定そのものよりも、今どんな流れで運用しているのかと、実際にどうよかったのかを書きます。
チームとしての課題
自分たちのチームで大きな課題だと感じていたのは、レビュー負荷の高さでした。
AI を使って PR を作ることが増え、以前よりもレビュー対象となる PR の数や変更量が増えていました。加えて、バックエンドとフロントエンドを兼務しているメンバーや新しく入ったメンバーもいて、レビューの前提知識や得意領域にも差がありました。
そのため、変更内容によっては既存仕様や周辺実装を理解したうえでレビューする必要があり、レビューに時間がかかりやすい状況でした。さらに、チームとして扱う PR の量やコンテキストもさまざまで、レビュー開始からアプルーブまでの時間も長くなりやすい、という課題がありました。
そのため、人によるレビューに入る前に、ある程度 PR の質を上げておき、レビュー負荷を下げたいと考えました。
最初にやったこと
最初にやったことは、主に2つです。
1つ目は、GitHub Copilot code review を全PRで自動実行するようにしたことです。
GitHub の Rulesets で自動レビューを設定し、PR を open したタイミングで Copilot のレビューが入るようにしました。
2つ目は、copilot-instructions を最初に整備したことです。
自動レビューを入れるだけでも効果はありますが、そのままだとコメントはやや汎用的になりがちです。そこで、自分たちのリポジトリでは、レビューで見てほしい観点を copilot-instructions に書いています。
たとえば、次のような内容です。
- 日本語でコメントする
- プロジェクトの概要
- レビューで見てほしい観点
- バックエンド / フロントエンドそれぞれで気をつけたいこと
これを入れる前よりも、入れた後のほうが「その観点を見てほしかった」と思う指摘が増えました。
なお、運用を始める前に、PR 作成者側でも Copilot を使える状態にしておきました。
下記の制限もあるため、確認しておく必要があります。
- copilot-instructions に関する制限事項（2026年3月時点）
Copilot code review では最初の4000文字だけ読み込まれるとのことです。
Copilot code review only reads the first 4,000 characters of any custom instruction file. Any instructions beyond this limit will not affect the reviews generated by Copilot code review. This limit does not apply to Copilot Chat or Copilot coding agent
Copilot code review では CLAUDE.md を読み込んでくれないみたいです。
今のレビュー運用
今の運用は、だいたい次の流れです。
- PR を open すると Copilot code review が自動で入る
- PR 作成者が Copilot の指摘を先に確認する
- 直せるものは先に修正する
- 対応済みのものは resolve し、残すものは理由を書く
- そのあとで人によるレビューに進む
- 振り返りで出た観点を
copilot-instructionsに反映する
1. PR を open すると Copilot code review が自動で入る
PR を open すると、Copilot code review が自動で入るようにしています。
手動で必要なときだけ呼ぶ運用もできますが、自分たちのチームでは人によって使ったり使わなかったりして、効果にばらつきが出やすいと感じました。そのため、全PRで自動レビューを入れる方針にしました。
最初は push のたびにレビューさせることも試しましたが、コメントが増えすぎて読むコストが上がりやすかったため、今は PR を open したタイミングでまずレビューし、その後は必要なときだけ再レビューする形にしています。
2. PR 作成者が Copilot の指摘を先に確認する
Copilot のレビューが入ったら、まず PR 作成者が指摘を確認します。
作成者が先に指摘を確認できるようにしておくと、このあとの対応を進めやすくなります。
3. 直せるものは先に修正する
Copilot の指摘のうち、すぐ直せるものは人によるレビューに入る前に先に修正します。
作成者側で先に直せるものを減らしておくことで、そのあとのレビューを進めやすくしています。
4. 対応済みのものは resolve し、残すものは理由を書く
対応済みのものは resolve し、すぐ閉じないものは対応中か、今回は対応しない理由をコメントで残すようにしています。
これをしないと、レビュアーから見てその指摘が放置なのか判断しづらく、レビューのノイズになりやすいためです。
5. そのあとで人によるレビューに進む
Copilot の指摘をある程度捌いたあとで、人によるレビューに進みます。
Copilot の指摘を先に確認してから渡すことで、人によるレビューではより重要な論点を見やすくなります。
6. 振り返りで出た観点を copilot-instructions に反映する
スプリントの振り返りや障害の振り返りで「今後はこの観点もレビューで見たい」となった内容は、必要に応じて copilot-instructions に反映しています。
そうすることで、次のレビューで同じような見落としを未然に防ぎやすくしています。
運用でよかったこと
フロントエンドでは、細かい指摘を前段で減らせた
フロントエンドで特によかったのは、細かい指摘を人によるレビューの前に減らしやすくなったことです。
たとえば、
- 翻訳漏れ
- 文言の不整合
- UI ライブラリ移行時のスタイルミス
のようなものです。
どれも致命的ではないですが、人が毎回見ると地味に時間を使います。こうした指摘を Copilot が先に拾ってくれるようになってから、人によるレビューではより重要な確認に入りやすくなりました。
バックエンドでは、見落としやすい観点を指摘してくれた
バックエンドでよかったのは、知らないと抜けやすい観点を先に出しやすくなったことです。
たとえば自分たちの環境では、 ECS をデプロイ後に新旧バージョンが並行稼働する前提があります。
そのため、コードとしては正しく見えても、並行稼働時に問題が起きないかは別で見ないといけません。
そのため、次のような観点も見ていたりします。
- 並行稼働時の安全性
- レースコンディション
- マイグレーション時の注意点
このあたりは、バックエンドに慣れている人なら自然に見ますが、フロントエンド出身の自分含め兼務メンバーや経験が浅い人だと抜けることがあります。Copilot が先にそこをコメントしてくれるだけでも、論点が最初からレビューに出てくるので助かっています。
レビューからアプルーブまでの時間も改善した
Copilot の指摘を PR 作成者が先に確認し、直せるものを人によるレビューの前に修正する運用にしたことで、自分たちのチームではレビューからアプルーブまでの時間も改善していました。
もちろん、時期による開発状況や他の改善の影響やメンバーの努力も大いにあるとは思いますが、少なくとも PR 作成者が先に Copilot の指摘を捌く運用は、レビューを進めやすくするうえで効果があったと感じています。
その結果、人によるレビューが重要な論点に集中しやすくなった
フロントエンドでは細かい指摘を前段で減らしやすくなり、バックエンドでは見落としやすい観点を先に出しやすくなりました。
その結果として、人によるレビューでは、仕様や UX、設計の意図のような、より重要な論点に集中しやすくなったと感じています。
もちろん、最終的に判断するのは人です。
ただ、最初から論点がある程度整理された状態になっているだけでも、レビュー全体はかなり進めやすくなります。
まとめ
GitHub Copilot code review を全PRに自動で入れてよかったのは、レビュアーが見る前に PR の質を上げやすくなったことでした。
自分たちのチームでやったこと自体はかなりシンプルで、
- 全PRで Copilot code review を自動実行する
copilot-instructionsを最初に整備する
の2つが中心です。
そのうえで、
- PR を open すると Copilot のレビューが入る
- PR 作成者が先に指摘を確認して、直せるものは直す
- resolve やコメントで状態を残してから人によるレビューに進む
- 振り返りで出た観点は
copilot-instructionsに戻す
という流れにすることで、レビュー全体がかなり回しやすくなりました。
GitHub Copilot code review を使うなら、手動でたまに呼ぶより、まずは全PRに自動で入れてみるのがおすすめです。そのうえで、copilot-instructions や運用を少しずつ育てていくのが、自分たちのチームではうまく回っています。
