Copilot のレビュー結果を、承認として扱えるようになった
GitHub は 2026 年 9 月 1 日、Copilot code review がプルリクエスト (PR) を承認できる機能を公開プレビューで発表しました。対象は Copilot Pro、Pro+、Max、Business、Enterprise です。
今回の変更で先に押さえたいのは、「承認してよいと Copilot が評価した」と「GitHub 上で正式に承認した」の違いです。前者は概要コメントに表示される判断で、それだけでは必要承認数に数えられません。後者は管理者が許可した場合に送信される承認です。承認機能は既定で無効になっています。詳しくは GitHub の発表 を参照してください。
たとえば「承認が 1 件必要」というリポジトリで正式な承認を有効にすると、その 1 件を Copilot が担えるようになります。これまで人のレビューを待っていた変更について、承認者の条件が変わり得る更新です。
この記事では公式仕様を確認したうえで、試験導入の進め方を提案します。以下の試験例は、FIXIT が実機で検証した結果ではありません。自社の設定で期待する挙動を確かめるための例です。
FIXITCopilot に「承認してよさそう」と言われたら、もう承認済みなの？
Dodaiそこは別だ。評価コメントと正式な承認を分けて確認しよう。
評価、承認、マージを分けて確認する
PR の画面を読むときは、次の 3 つを順に見ます。
| 確認するもの | 意味 | チームが確認すること |
|---|---|---|
| レビューの評価コメント | Copilot が承認可能と判断したか | 判断の理由と個別の指摘 |
| 正式な承認 | 必要承認数へ数えられるレビュー | 誰が、どの変更に対して承認したか |
| マージ条件の充足 | 設定された各条件を満たした状態 | 必要なレビューと CI などの結果 |
GitHub の rulesets の説明 では、必要なレビューと、マージ前に成功を求めるステータスチェックを個別に設定できます。Copilot の承認を有効にする作業と、これらの条件を変更する作業は切り分けてください。
「Copilot が承認したからテストは省略する」という運用にすると、レビューとテストの両方を変えた結果になってしまいます。試験導入では CI の条件を保ち、承認者の変更による差を観察するほうが判断しやすくなります。
同様に、必要承認数を満たすことと「必ず人が 1 人は確認する」ことも同じではありません。後者を運用方針にするなら、人の確認が済むまでマージできないことを、実際の保護ルールとテスト用 PR で確かめます。CODEOWNERS の指定、必要承認数、バイパス権限も確認対象です。
AI と人のレビューで何を見るかは、AI コードレビューの設計 で詳しく扱っています。今回の機能を導入するときも、レビュー担当者の役割を先に決めると設定を選びやすくなります。
管理者が決められる範囲
GitHub の発表では、管理者の制御を 3 階層に分けています。
| 管理レベル | 選べる方針 |
|---|---|
| Enterprise | 企業全体で無効にする、または組織に判断を委ねる |
| Organization | 組織全体で有効または無効にする、特定リポジトリへ適用する、リポジトリ管理者に委ねる |
| Repository | 有効または無効を選ぶ、承認可能なファイルパスを選ぶ |
最初は対象リポジトリを 1 つ選ぶ方法を勧めます。利用中の設定を記録し、チームの管理者と「どの変更なら Copilot の承認を数えてよいか」を決めてから、有効化を試します。
候補として考えやすいのは、影響を確かめやすく、元に戻す手順が明確な変更です。ただし、拡張子やディレクトリ名だけで安全性は決まりません。Markdown に書かれた運用手順が、本番データの削除方法を含む場合もあります。チームが承認を委ねたい変更の種類を具体例で揃えてください。
ファイルパスの許可範囲を決める場合は、対象ファイルと対象外ファイルが同じ PR に入ったときも試します。許可パターンの解釈や、複数パスが混ざる PR の結果を、名前から推測して運用ルールに書かないためです。
試験用 PR を 4 種類用意する
次の表は、導入前に確かめるための試験案です。いずれも本番への影響がない検証用リポジトリ、またはマージしないテスト用 PR で実施します。
| 試験 | 用意する変更 | 記録する結果 |
|---|---|---|
| 許可した範囲の変更 | 承認対象にしたファイルだけの小さな差分 | 評価内容、正式承認の有無、必要承認数の状態 |
| 許可範囲外を含む変更 | 対象ファイルと対象外ファイルの両方を含む差分 | 想定外の範囲まで承認されていないか |
| 承認後の変更 | 正式承認を得た PR への追加コミット | 以前の承認が取り消され、新しいレビューが必要になるか |
| CI が失敗する変更 | 必須チェックが失敗する検証用の差分 | 承認の有無にかかわらず、マージを阻止できるか |
GitHub の発表と Copilot code review の公式説明 では、承認後に新しいコミットを追加すると Copilot の承認が取り消され、新たなレビューを依頼できるとされています。試験では、最初の承認だけでなく、その後の修正まで一連の操作として確認します。
記録にはコミット ID を添えてください。「承認が付いた」というスクリーンショットだけでは、修正前と修正後のどちらを確認したのか分からなくなります。確認した差分、Copilot の評価、人が指摘した点を 1 つの PR に残すと、あとで適用範囲を見直す材料になります。
FIXIT最初の PR がうまく承認されたら、試験は終わりでいい？
Dodai追加コミットと CI の失敗も試そう。承認できない場面の確認も必要だ。
レビューの再実行も運用に含める
レビュー後に修正したとき、誰が再レビューを依頼するかを決めておきます。公式説明では、新しい push ごとのレビューを設定していない場合、自動レビューは原則として PR ごとに 1 回です。必要な再レビューは手動で依頼できます。
また、同じ公式説明ではコードレビューが AI クレジットを消費し、エージェント機能には GitHub Actions の利用も関わるとされています。試験中はレビュー回数と利用量を記録し、自動再レビューの頻度を決める材料にしてください。本記事では、個別契約の料金や月額削減額は見積もりません。
近い時期の課金やレビュー設定の変更は、GitHub Copilot の課金・ポリシー変更 に整理しています。承認を有効にする前に、管理者が確認する作業をまとめておくと重複を減らせます。
承認を任せる範囲は、試験結果から広げる
Copilot の正式な承認は、レビュー待ちの運用を見直す選択肢になります。導入の判断に使いたいのは、単に承認が何件付いたかではありません。人が修正を求めた差分を Copilot がどう評価したか、追加コミット後に確認がやり直されたか、必須チェックが機能したかを見ます。
まず対象を絞って試し、差分の種類ごとに結果を残すことを勧めます。判断が揃わない変更は人のレビューを続け、どこまで任せられるかを見直してください。
チームの開発フローに合わせたレビュー設計は、AI 開発ツール定着支援 でご相談いただけます。