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

- 媒体: 知能圏（CHINOUKEN）
- 公開日: 2026-09-04
- カテゴリー: エージェント・ソフトウェア
- タグ: GitHub Copilot、コードレビュー、Pull Request、開発チーム
- 想定読了時間: 約9分
- 調査基準日: 2026年9月4日
- 出典: 8件（末尾の「参照リンク」に番号順で記載）
- ページ: https://www.chinouken.com/articles/copilot-approval-paths
- このMarkdown: https://www.chinouken.com/articles/copilot-approval-paths.md
- 利用条件: 引用する場合は出典として「知能圏（chinouken.com）」と該当ページのURLを明記してください。本文の再配布は行わず、要約や引用の範囲で使ってください。

この記事は、GitHubでチームのソフトウェアを管理し、コードの確認にAIを使いたい人へ向けています。開発者が変更案を送り、別の人が内容を確認して「取り込んでよい」と承認してからチームの正式なコードへ加える流れが前提です。GitHub Copilotはこの確認をAIで行い、設定によっては人と同じ一件の承認として数えられます。しかし、AIが見落とした変更まで人の確認なしで取り込める状態になりかねないため、指定した場所の変更だけにAI承認を効かせ、テストと人の承認を残す始め方を説明します。

![開発者の変更提案をCopilotと担当者がそれぞれ確認してから正式なコードへ進める図](https://www.chinouken.com/images/articles/copilot-approval-paths/hero.png)

*Copilotの承認を人の確認と組み合わせ、AIだけでコード変更を通さない形から始めます。*

## コード変更を取り込む前にAIが確認する

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の確認、自動テスト、担当者の確認をそれぞれ通り、正式なコードへ進む図](https://www.chinouken.com/images/articles/copilot-approval-paths/figure-review-gates.png)

*コード変更はCopilotの確認だけで進めず、自動テストと担当者の承認を別の条件として通します。*

## Copilotのコメントと承認は効力が違う

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

| Copilotが返すもの | 画面で分かること | マージ条件への影響 |
| --- | --- | --- |
| レビューコメント | 問題の候補や直し方 | コメントだけでは承認にならない |
| 承認評価 | Copilotが承認できる状態と考えたか | 表示だけでは承認数に入らない |
| 正式な承認 | CopilotがPull Requestを承認したこと | 管理者が許可すると必要な承認の一件に数えられる |

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

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

## AI承認の効く場所は変更ファイルで絞れる

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

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

| Pull Requestの変更 | Copilotの承認を数えるか | 理由 |
| --- | --- | --- |
| `docs/guide.md`だけ | 数える | すべての変更が指定場所にある |
| `docs/guide.md`と`src/login.py` | 数えない | ログイン処理のファイルが指定場所の外にある |

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

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

## 実在30件では文書だけの変更は1件だった

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

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

| AI承認を数える候補範囲 | 全ファイルが範囲内だった件数 | 30件に占める割合 |
| --- | ---: | ---: |
| Markdownなどの文書形式だけ | 1件 | 3.3% |
| 文書形式と`docs`、`examples` | 1件 | 3.3% |
| 上記に`tests`を追加 | 2件 | 6.7% |


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

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

![文書形式だけ、説明書とサンプルコード、テスト追加の三候補へ実在するコード変更30件を通し、残った1件、1件、2件を示す比較図](https://www.chinouken.com/images/articles/copilot-approval-paths/figure-policy-results.png)

*一つでも候補外ファイルがあればPR全体を対象外にした結果です。*

## 文書やテストだけでも安全とは限らない

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

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

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

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

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

## AIだけで通さない四つの条件

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

| 確認すること | GitHubで使う仕組み | 止められること |
| --- | --- | --- |
| 変更場所 | Copilot承認を数えるファイルパス | 指定外の実装ファイルが混ざった変更 |
| 動作確認 | 自動テストやビルドなどの状態検査 | 動かないコードや検査に落ちた変更 |
| 担当者 | 変更場所ごとの責任者を指定する`CODEOWNERS`と人の承認 | 認証、決済、契約文書などを担当外の判断だけで通すこと |
| 最新の変更 | 新しい変更後に古い承認を外し、再確認を求める設定 | 確認後に追加されたコードを未確認のまま通すこと |

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

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

## 自分のチームでは直近30件から始める

最初の対象範囲は、想像で決めず、自分のリポジトリで最近マージした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`に整理しています。

## 参照リンク

1. [GitHub Changelog: Copilot code review can now approve pull requests](https://github.blog/changelog/2026-09-01-copilot-code-review-can-now-approve-pull-requests/)
2. [GitHub Docs: Configuring code review by GitHub Copilot](https://docs.github.com/en/copilot/how-tos/copilot-on-github/set-up-copilot/configure-code-review)
3. [GitHub Docs: REST API endpoints for pull requests](https://docs.github.com/en/rest/pulls/pulls)
4. [GitHub Docs: Managing a branch protection rule](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule)
5. [GitHub: openai/openai-python Pull Requests](https://github.com/openai/openai-python/pulls)
6. [GitHub Docs: Pull Request](https://docs.github.com/ja/pull-requests/reference/pull-requests)
7. [GitHub Docs: プルリクエストで提案された変更をレビューする](https://docs.github.com/ja/pull-requests/how-tos/review-pull-requests/reviewing-proposed-changes-in-a-pull-request)
8. [GitHub Docs: ブランチ保護ルールを管理する](https://docs.github.com/ja/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule)

2026年9月4日時点の公式資料を確認しています。仕様は更新される可能性があります。

---

© 知能圏 https://www.chinouken.com/articles/copilot-approval-paths