GitHub Copilot code review設定で何が変わる？2つの既定値チェックリスト【2026年9月版】
GitHubは2026年9月23日、Copilot code reviewに専用の個人設定ページとEnterprise全体の既定review effort設定を追加したと発表しました。今回のポイントは、レビュー品質そのものの新機能というより、誰が、どの粒度で、いつCopilotレビューを走らせるかを管理しやすくなったことです。Copilot BusinessやCopilot Enterpriseを使う組織では、開発者ごとの自動レビュー設定と、Enterprise管理者が決める既定値の衝突を整理しておく必要があります。
概要：今回増えた2つの設定
今回の変更は大きく2つです。1つ目は、プロフィール配下のCopilot settingsに専用の「code review」ページが用意され、Automatic reviewとdefault review effortを個人単位で扱えるようになったこと。2つ目は、Enterprise管理者がLite、Balanced、GitHub defaultのいずれかをEnterprise全体の既定review effortとして設定できるようになったことです。公式発表では、この改善は一般提供済みと説明されています。
対象は個人利用だけではありません。従来はPro、Pro+、Max中心だった個人レビュー設定が、BusinessとEnterpriseを含むすべてのCopilot planに広がりました。つまり、企業導入では「開発者が自由にON/OFFする設定」と「管理者が組織標準として揃える設定」を同時に設計する段階に入っています。
仕様表：個人設定とEnterprise既定値の違い
個人設定で扱うのは、Pull Request作成時、共同作成したPull Request、draft解除時、新しいpush、draft Pull Requestへの自動レビューです。default review effortは、本人が依頼するレビューや自動レビューに適用されます。一方、Enterprise既定値は組織所有リポジトリへ継承され、OrganizationやRepository側の上書き設定と組み合わせて使います。
実務では次のように整理すると迷いません。個人設定は「いつレビューを走らせるか」、Enterprise既定値は「どの強度を標準にするか」、Repository設定は「例外をどう扱うか」です。たとえば、基幹システムはBalancedを標準、検証用リポジトリはLite、セキュリティレビュー対象だけ手動でBalancedにする、といった切り分けがしやすくなります。
設定手順：管理者が先に確認する5項目
最初に確認したいのは5項目です。1つ目はCopilot code reviewを利用しているOrganizationとRepositoryの棚卸し。2つ目は現在のreview effortがLite寄りかBalanced寄りか。3つ目は自動レビューをdraft段階で走らせたいチームと、ready for review後に限定したいチームの分類。4つ目は高リスク領域の例外Repository。5つ目はAI creditsやレビュー待ち時間への影響です。
設定順序は、Enterprise既定値、Organization例外、Repository例外、個人設定の案内、運用レビューの順がおすすめです。いきなり個人設定だけを案内すると、チームごとに自動レビューのタイミングが分散し、Pull Request運用が読みにくくなります。先に管理側の標準値を決め、その後で開発者が自分の作業スタイルに合わせて自動レビューを有効化するほうが、運用ルールとして説明しやすくなります。
料金・工数への影響：100人組織の試算
100人の開発組織で、1人あたり週5本のPull Requestを作る場合、週500本のPRがレビュー対象になります。全員がdraft Pull Requestとnew pushの自動レビューをONにすると、レビュー実行回数は単純なPR本数より増えます。ここでBalancedを全体既定にすると、レビュー深度は上がりますが、待ち時間や利用量の増加も見込む必要があります。
おすすめは、最初の30日は2段階で測ることです。Week 1-2は主要10RepositoryだけBalanced、その他はLiteまたはGitHub defaultにします。Week 3-4でレビュー指摘の採用率、再レビュー回数、CI失敗率、レビュー待ち時間を比較します。数値が見えた後に、Enterprise既定値をBalancedに寄せるか、Repository単位の例外運用を残すかを判断します。
運用チェックリスト：導入前に決める8項目
導入前チェックリストは8項目です。1. Enterprise既定effortを決める。2. Organizationごとの例外可否を決める。3. Repository上書きの責任者を決める。4. draft PRへの自動レビュー可否を決める。5. new pushごとの再レビュー方針を決める。6. AI creditsまたは利用量の監視方法を決める。7. 指摘を採用しない場合の理由分類を決める。8. 30日後に見直すKPIを決める。
特に重要なのは、draft PRへの自動レビューです。早い段階でAIレビューを受けると手戻りを減らせる一方、試行錯誤中のpushに毎回レビューが走るとノイズが増えます。新入社員やジュニアが多いチームではdraftレビューをON、熟練チームや大量pushのリポジトリではready for review後に限定するなど、チームの成熟度で分けると現実的です。
FAQ：よくある質問
Q1. 個人のdefault review effortとEnterprise既定値はどちらが優先されますか。公式発表では、個人のdefault effortは本人が依頼するレビューや自動レビューに適用され、Enterprise既定値は組織所有Repositoryへ継承されると説明されています。OrganizationやRepository側の上書きもあり得るため、管理者は実際の設定画面で継承関係を確認してください。
Q2. LiteとBalancedはどちらを標準にすべきですか。速度と利用量を抑えたいならLite、重要なPull Requestで指摘の網羅性を優先するならBalancedです。全社一律ではなく、顧客影響の大きいRepository、セキュリティ関連、共通基盤だけBalancedから始める方法が現実的です。
Q3. 既存のCopilot code review運用と何が違いますか。9月1日のPR承認機能や9月18日の改善はレビュー体験そのものの更新でした。9月23日の変更は、個人設定ページとEnterprise既定値によって、レビューの依頼・自動化・強度を組織的に揃えやすくする管理面の更新です。
まとめ：2つの既定値を30日で検証する
今回の変更で、Copilot code reviewは「便利な補助レビュー」から「組織標準として設計するレビュー基盤」に近づきました。まずはEnterprise既定effortと個人の自動レビュー設定を分けて考え、対象Repository、draft PR、new push、AI credits、採用率の5つを30日だけ測るのがよい進め方です。
