PR の承認の仕組みと、AI が作る PR

ブランチ保護（ルールセット）で main を守る では、PR の承認の必要人数を 0 人に設定しました。このページでは、その背景にある「承認」の仕組みを詳しく説明します。あわせて、AI が作る PR に対して GitHub が設けている仕組みと、AI と一緒に作業を進める中で起きたことをまとめます。

レビューの種類

GitHub の PR（プルリクエスト：変更の提案）には、内容を確認した人が付けられる「レビュー」という機能があります。レビューには 3 つの種類があります。

種類	意味
Comment（コメント）	意見や質問を書き込むだけ。賛成も反対もしない
Approve（承認）	「この変更をマージしてよい」と正式に賛成する
Request changes（修正依頼）	「直してからでないとマージしないでほしい」と求める

ブランチ保護の「承認の必要人数」は、マージする前に Approve が何人分必要かを決める設定です。

承認 0 人の意味

承認の必要人数を 0 人にすると、Approve がなくてもマージできます。ただし、ほかのルール（PR が必須、チェックの合格が必須）は引き続き守らせます。

0 人は「確認しなくてよい」という意味ではありません。正式な承認の記録を、マージの条件にしないという意味です。

自分の PR は承認できない

PR を作った本人も、変更内容を読んだり、コメントを書き込んだりはできます。しかし、自分の PR に Approve を付けることは、GitHub の仕組みとして禁止されています。

作った本人ができること	作った本人ができないこと
変更内容（Files changed タブ）を読んで確認する	自分の PR に Approve を付ける
気になる行にコメントを書き込む
Comment のレビューを付ける
確認が終わったら、自分でマージする

そのため、1 人で運用しているリポジトリで承認を 1 人以上にすると、誰もマージできなくなります。

AI があなたのアカウントで作る PR も同じ

Claude Code のような AI エージェントが、あなたの GitHub アカウントの権限で PR を作った場合、GitHub から見た PR の作者はあなたです。そのため、あなたはその PR にも Approve を付けられません。

このサイトでは、AI が変更内容と影響を説明し、人がそれを確認してからマージを指示する、という運用をしています。これは実質的に人によるレビューですが、GitHub 上に Approve の記録は残りません。確認した記録を残したい場合は、マージの前に「確認しました」とコメントを書く運用にもできます。

2 つ目のアカウントで承認するのは不可

自分で承認するために、2 つ目の GitHub アカウントを作る方法は使えません。GitHub の利用規約では、無料のアカウントは 1 人 1 つまでと定められています。

業務で承認者がいなくなった場合

業務で承認を 1 人にしていて、承認するメンバーが退職などでいなくなった場合を考えます。

必要人数は途中で変更できる

承認の必要人数は、リポジトリの管理者（admin 権限を持つ人）であれば、いつでも変更でき、すぐに反映されます。組織（Organization：会社やチームで GitHub を共有するための単位）でルールを設定している場合は、組織の管理者が変更します。

退職した人が唯一の管理者だった場合は、誰も変更できなくなります。管理者は複数人にしておくのが基本です。

退職者の承認は数に入らなくなる

マージの条件として数えられるのは、そのリポジトリへの書き込み権限を持つ人の承認だけです。退職して組織から外れると書き込み権限がなくなるので、その人が退職前に付けた承認は、数に入らなくなると考えておく必要があります。承認済みだと思っていた PR が、急にマージできなくなることがあります。

0 人に下げる前に検討すること

承認を 0 人に下げると、誰の確認もないまま本番に変更を入れられる状態になります。品質や不正防止のための仕組みを外すことになるので、次の順に検討します。

順番	対応	内容
1	別のメンバーをレビュアーにする	書き込み権限を持つほかのメンバーが承認できるようにする。本来はこれが対応の中心
2	CODEOWNERS を更新する	CODEOWNERS は「このファイルは、この人の承認が必要」と指定するファイル。退職者の名前が残っていると、その部分の PR がマージできなくなるので、後任に書き換える
3	期限を決めて、一時的に 0 人にする	後任が決まるまでの間だけ下げる。理由と、元に戻す予定日を記録しておく

会社によっては、「本番に入る変更には、必ずほかの人の承認が必要」と社内規程で定めていることがあります。その場合、0 人に下げること自体が規程違反になる可能性があるので、変更する前に責任者に確認します。

AI が作る PR と、追加の承認

ルールセットを適用したところ、こちらが書いていない次の設定を、GitHub が自動で追加していました。

"require_extra_approval_for_unattributed_changes": true

GitHub の公式ドキュメントでは、この設定は「Additional approval for unattributed Copilot pull requests」（人に結び付いていない Copilot の PR に、追加の承認を求める）として説明されています。2026 年に追加された機能で、まだ試験提供（public preview）の段階です。新しいルールセットにも既存のルールセットにも、最初から有効になっています。

なぜこの設定があるのか

「承認を 1 人必要にする」というルールは、本来「変更を書いた人」と「承認した人」の 2 人の人間が関わることを前提にしています。

ところが、GitHub の AI（Copilot）が、特定の人の依頼ではなく AI 自身の名義で PR を作ると、「変更を書いた人」にあたる人間がいなくなり、この前提が崩れます。そこで、そうした PR には、設定した人数より 1 人多い承認を求めます。

	人が PR を作った場合	AI が自分の名義で PR を作った場合
変更に関わる人	作成者 ＋ 承認者 1 人	AI ＋ 承認者 2 人
承認 1 人のルールで必要な承認の数	1 人	2 人
結果として関わる人間	2 人	2 人

AI が作った PR でも、関わる人間を 2 人にそろえるための、理にかなった仕様といえます。

GitHub が数えるのは、書き込み権限を持つ人の承認が何人分あるかだけです。「AI に依頼した人」と「もう 1 人のレビュアー」という役割までは区別しません。誰と誰が承認するかは、チームの運用ルールとして決めておく必要があります。

なお、AI が「特定の人の依頼で作った」と記録されている PR は、その人が作成者として扱われるので、追加の承認は求められません。

承認 0 人なら効果はない

公式ドキュメントには、承認の必要人数が 0 人の場合、この設定は何の効果も持たないと明記されています。このサイトは 0 人なので、影響はありません。実際に、この設定が有効なままでも、チェックに合格した PR はマージできる状態になりました。

GitHub は AI の PR をどう見分けているか

GitHub は、PR の中身を読んで「AI が書いたかどうか」を判断しているわけではありません。判断の材料は、誰の名義で PR やコミットが作られたかです。

PR を作ったアカウントの種類

種類	意味	このサイトでの例
User	人間のアカウント	作業用ブランチから作った PR の作者
Bot	アプリが動かすアカウント	Dependabot が作った PR の作者 dependabot[bot]

Copilot が自分の名義で PR を作ると、作者は Copilot のアプリのアカウントになります。そのうえで、その PR が特定の人の依頼として記録されているかどうかで、「人に結び付いているか」が決まります。

コミットの作者が GitHub アカウントに結び付いているか

コミット（変更の記録）には、作者の名前とメールアドレスが書かれています。GitHub は、そのメールアドレスが登録済みの GitHub アカウントのものかどうかを照合します。

このサイトで Claude Code が作ったコミットを確認すると、次のようになっていました。

項目	内容	GitHub アカウントとの紐付け
コミットの作者	リポジトリの持ち主（GitHub 用のメールアドレス）	紐付いている
コミットメッセージ末尾の共同作者の記載	Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	このメールアドレスの GitHub アカウントは存在しない

Claude Code は、リポジトリの持ち主の GitHub アカウントの権限で動いています。そのため、GitHub から見ると PR の作者もコミットの作者も持ち主本人です。AI が関わったことを示すのは、AI が自分で書き加えている Co-Authored-By の 1 行だけです。

確かめられていないこと

ほかのリポジトリからは、「GitHub アカウントに紐付かない共同作者の記載があると、人に結び付いていない変更として扱われ、追加の承認を求められた」という報告があります。しかし、公式ドキュメントが説明しているのは Copilot の PR についてだけで、共同作者の記載がどう扱われるかは書かれていません。

このサイトは承認 0 人なので、この設定は効果を持たず、実際にどちらの扱いになるのかを確かめる手段がありません。業務で承認を 1 人以上にしていて、AI エージェントに PR を作らせる場合は、試験用のリポジトリで「共同作者の記載がある PR に、追加の承認が求められるか」を確かめてから導入するのが確実です。

AI と進める中で起きたことと、その対処

この設定作業は Claude Code と一緒に進めました。その中で起きたことと、その対処をまとめます。

起きたこと	対処
ルールセットを適用したとき、AI は「説明のない設定項目がある。意味は分からない」と伝え、判断の材料を出さずに止まった。調べる範囲を広げさせたところ、公式ドキュメントに説明が見つかった	「分からない」と言われたら、どこまで調べたのかを確認する。公式ドキュメントや変更履歴など、調べる範囲を広げさせる
AI は「GitHub が自動で付けた設定は 2 つ」と説明したが、プログラムで比較すると 4 つだった	設定や数値の比較は、目で見て数えさせずに、プログラムで比較させる

どちらも、AI の説明をそのまま判断の根拠にせず、「どう調べたのか」「どう確かめたのか」を確認することで防げるものです。

まとめ

• PR のレビューには Comment、Approve、Request changes の 3 種類がある。ブランチ保護の「承認の必要人数」は Approve の数。
• 自分の PR には Approve を付けられない。AI があなたのアカウントで作った PR も、あなたの PR として扱われる。
• 承認 0 人は「確認しなくてよい」ではなく、「正式な承認の記録をマージの条件にしない」という意味。
• 業務で承認者がいなくなったときは、0 人に下げる前に、別のレビュアーの指定や CODEOWNERS の更新を検討する。
• 人に結び付いていない Copilot の PR には、GitHub が承認を 1 人追加する。承認 1 人なら、人間 2 人がそろうように設計されている。承認 0 人なら効果はない。
• GitHub は、アカウントの種類と、コミットのメールアドレスとアカウントの紐付けで、PR が誰のものかを判断している。AI エージェントを業務で使う前に、追加の承認が求められるかを試しておく。
• AI の説明は、「どう調べたのか」「どう確かめたのか」を確認してから判断に使う。

参考

• Available rules for rulesets - GitHub Docs
• Approving a pull request with required reviews - GitHub Docs