AIの確認だけでコード変更を通さないCopilot承認を狭く使う方法

GitHubは、チームでソフトウェアのコードと変更履歴を管理するサービスです。たとえば開発者がログイン画面の不具合を直したとき、変更したコードをすぐチームの正式版へ混ぜるのではなく、変えたファイルと理由をGitHub上でひとまとめにして確認を頼みます。この「コード変更を取り込んでほしい」という提案をPull Requestと呼びます。6

依頼を受けた担当者の作業は、変更されたファイルを開き、不具合の直し方に問題がないか、別の機能を壊さないか、自動テストに合格したかの確認です。問題がなければ「承認」を送り、その変更を正式なコードへ取り込みます。この取り込み操作がGitHubでいうマージです。チームによっては、少なくとも一人の承認がなければマージできないルールを設定しています。7

GitHub Copilot code reviewは、この確認作業へ加わるAIです。開発者がPull Requestを作った後にCopilotへレビューを頼むと、AIが変更ファイルを読み、気になる箇所へコメントします。2026年9月1日からは、管理者が許可したリポジトリで、Copilot自身が「取り込んでよい」という正式な承認も送れるようになりました。1

ここで変わるのは、AIの指摘を参考にできることだけではありません。必要な承認が一件のリポジトリでCopilotの承認を一件として数えると、人が内容を読んでいなくてもマージ条件を満たす場合があります。Copilotが自動でマージする機能ではありませんが、人がマージボタンを押せる状態にはなり得ます。

AIレビューを使うかどうかより先に、AIの承認をどの変更まで有効にするかを決める必要があります。答えは、リポジトリ全体で有効か無効かの二択ではありません。対象の変更ファイルを狭く指定し、自動テストと担当者の承認を別の条件として残せます。

Copilotのレビュー画面には、助言、承認評価、正式な承認という効力の異なる結果が並びます。2026年9月4日時点の違いは次のとおりです。12

正式な承認は既定で無効です。企業全体、GitHub上の組織、個別のリポジトリという三段階で、どこまで許可するかを管理できます。2026年9月4日時点では公開プレビューなので、導入時には設定画面と最新資料をもう一度確認する必要があります。12

Copilotが承認した後にコードが追加または変更されると、その承認は解除されます。最初に見た内容への承認が、後から加わった変更へそのまま残るわけではありません。必要ならCopilotへ再レビューを頼みます。1

リポジトリ管理者は、Copilotの承認をマージ条件へ数えるPull Requestを、変更されたファイルの場所で限定できます。設定欄では、説明書を置くdocsフォルダのように、対象のフォルダやファイル名を表すパターンを一行ずつ指定します。こうした場所の指定がファイルパスで、複数の名前へ一致させる書き方がglobです。2

たとえば、説明書を置くdocsフォルダだけを対象にした場合、結果は次のように分かれます。

判定はPull Requestに含まれる全ファイルが対象です。一つでも指定外のファイルが混ざれば、Copilotの承認はマージ条件へ数えられません。パターンは最大15個まで設定でき、何も書かなければすべてのファイルが対象になります。2

この設定は、AI承認の効力が予定外の場所へ広がるのを止めます。一方で、docsにある変更なら安全だと判断する機能ではありません。どの場所から始めるかは、過去のPull Requestを使って確かめる必要があります。

知能圏では、OpenAIが公開しているPython向けソフトウェア部品のリポジトリopenai/openai-pythonを例に、マージ済みPull Request 30件の全変更ファイルを調べました。取得にはGitHub公式のデータ取得窓口を使い、2026年9月4日07:13 JST時点の結果を保存しています。35

AI承認を数える候補範囲を、文書形式だけ、説明書とサンプルコードまで、テストまでの三段階に広げました。一つでも候補外のファイルが入るPull Requestは対象外です。

変更ファイルが100件に達したPull Request #3791は標本から外しました。データ取得の一ページ目だけでは、すべてのファイルを確認できたと保証できないためです。その結果、大規模な変更を含まない30件になった点は、この観測の限界です。

最も広い候補でも残ったのは2件だけでした。この数字は、どのリポジトリでも6.7%になるという意味ではありません。今回の30件は、説明書、テスト、実装コードなどを一つのPull Requestで一緒に変えることが多く、ファイルの場所だけで明確に分けにくかったと分かります。

候補に残った2件を読むと、ファイルの場所だけでは変更の重要度を判断できないことが分かりました。

文書だけで残ったPull Request #3778は、SECURITY.mdと安全設計の説明書を変更しています。プログラムの動作を直接変えなくても、利用者が安全な使い方を判断する文書なら、人の確認を外してよいとは限りません。

テストまで広げて追加で残ったPull Request #3721は、AIへの作業指示を置くAGENTS.mdと、大きな通信データを扱う際の互換性を確かめるテストを変更していました。テストは製品が何を正しい動作とみなすかを固定するため、置き場所だけで影響が小さいとは言えません。

反対に、定型作業に見えるタイトルでも実装へ触れる例があります。依存ソフトウェアの更新を示すPull Request #3744は、設定ファイルだけでなく、実際に動くプログラムと複数のテストを変更していました。リリース作業のPull Request #3785も、変更履歴だけでなく、版番号やソフトウェア構成を変えています。

対象ファイルの設定が答えるのは「AIの承認をどこまで効かせるか」です。「この変更を受け入れて安全か」は、自動テストと変更内容を知る人が別に判断します。

Copilotの承認を使うなら、変更場所、動作確認、担当者、最新の変更という四つを別々の条件にします。48

ファイルパスの条件と自動テストは、確認する対象が別です。自動テストが成功しても、価格、権限、公開する仕様を変えてよいかまでは決められません。影響の大きい場所では、その担当者の承認も必須条件です。

導入時の出発点は、Copilotの承認を唯一の必須承認にしない設定です。AIが一件を担っても、担当者の承認と状態検査を満たさなければマージできない形なら、レビュー待ちを減らしながら判断と責任を人に残せます。

最初の対象範囲は、想像で決めず、自分のリポジトリで最近マージしたPull Request 30件から選びます。30という数は安全性を証明する基準ではなく、日常の変更を手作業でも読み返せる出発点です。

1. 各Pull Requestで追加、変更、削除したファイルをすべて一覧にします。
2. 説明書、サンプル、生成物、独立したテストなど、チームが影響を説明できる候補場所を一つ選びます。
3. 候補のファイルパスを30件へ当て、全ファイルが収まるPull Requestだけを残します。
4. 残った内容を人が読み、文書なのに契約や安全方針を変える例、テストなのに製品仕様を変える例を探します。
5. 反対例を人の承認で止められることを確認してから、Copilotの承認を数える設定を有効にします。

対象外になった件数は失敗ではありません。たとえば説明書と実装コードがいつも同じPull Requestに入るなら、AI承認の範囲を広げる前に、変更を分けた方が確認しやすくなります。

最初は一つの場所だけを対象にし、2〜4週間は人の承認を残したまま観測するのが知能圏の提案です。差し戻し、新しい変更後の再レビュー、自動テストの見逃し、担当者へ戻した件数を記録し、問題がなければ次の場所を一つ足します。件数を増やすために対象を広げたくなったときが停止線です。

Copilotは、人がコードを読む前の確認役として使えます。その承認を人と同じ効力にする範囲は、AIの便利さではなく、間違えたときの影響を説明できるかで決めるものです。指定した場所、自動テスト、担当者の承認、最新変更の再確認を別々に残すことで、AIだけでコード変更を通さずに利用を始められます。

参照番号

出典のURL、確認日、各資料から採用した論点は同ディレクトリのsources.mdに整理しています。