AIの変更を承認なしで通さない：担当者を書いて終わりにしない4点
GitHub でコードの担当者を書いても届くのは確認の依頼だけで、AI の変更は承認必須と管理者への制限で止めます。
この記事の要点
- 担当者を書いても、届くのは確認の依頼だけ
- 承認を必須にする設定は、ブランチ保護で別に入れる
- AIは別アカウントで動かし、管理者にも制限をかける
- 効いているかは、取り込んだ提案の承認者で確かめる
目次
担当者を書いても、届くのは確認の依頼だけ
出典に基づく事実
CODEOWNERS は、どのファイルを誰が確認するかを書いておくファイルです。コードを置いて変更を受け付けるサービスの GitHub で、コードの置き場 (リポジトリ) ごとに置きます。
A&Aの考え方
GitHub では、コードを変える提案をプルリクエストと呼び、提案を本体のコードに入れることをマージと呼びます。以下では、プルリクエストを提案、マージを取り込みと書きます。
出典に基づく事実
担当者の承認がないと取り込めないようにするのは、別の設定です。公式文書によると、管理者が確認を必須にする設定を有効にしたうえで、担当者の承認も求めるかどうかを選べます。
仮想例
架空の例で考えます。社員 4 人の会社で、社長が Claude Code に修正を頼んで提案を出させ、外注の開発者も同じリポジトリに提案を出しているとします。決済まわりのフォルダには、外注のリーダーを担当者として書きました。
仮想例
この会社では、外注のリーダーに依頼は届きます。ただ、担当者を書いただけなので、リーダーが休んでいる間に出た提案も、承認を待たずに取り込めます。
出典に基づく事実
担当者の書き方によっても、依頼が思った人に届かないことがあります。公式文書によると、1 つのファイルが複数の行に当てはまると、最後に当てはまった行の担当者が選ばれます。リポジトリのコードを変えられる権限 (書き込みの権限) がない人やチームを書いても、担当者にはなりません。
A&Aの考え方
この記事を書いている Automate & Augment (A&A) は、担当者を書くことを「宛先を決めること」だと考えています。宛先を決めても、返事を待つ決まりは生まれません。しかも、外注のリーダーのアカウントに書き込みの権限がなければ、リーダーには依頼も届きません。
承認を必須にする設定は、ブランチ保護で別に入れる
出典に基づく事実
担当者の承認を必須にするのは、ブランチ保護という別の設定です。GitHub では、提案を取り込む先のコードの系統をブランチと呼び、ブランチ保護はブランチごとに決める保護の設定です。
出典に基づく事実
公式文書によると、ルールセットとブランチ保護はどちらもブランチを守れ、併用すると両方の規則が効きます。1 つのブランチに効くブランチ保護の規則は 1 つですが、ルールセットは複数を同時にかけられます。
A&Aの考え方
まず 1 つのリポジトリで試すなら、A&A はどちらか 1 つで組めば足りると考えます。どちらの形でも、1 つのファイルに担当者が複数いるときは、誰か 1 人の承認で足ります。
出典に基づく事実
使えるプランにも条件があります。公式文書によると、ブランチ保護と CODEOWNERS を非公開のリポジトリで使えるのは有料のプランです。無料のプランで使えるのは、公開しているリポジトリだけです。
出典に基づく事実
承認のあとに変更が足されたときの扱いも選べます。承認のあとに誰かが変更を足したら、足した本人とは別の人がもう一度承認するまで、取り込めないようにする設定があります。
A&Aの考え方
A&A は、担当者のファイルとブランチ保護の違いが、「書けば止まる」と思い込みやすい所だと考えます。担当者のファイルは置いたその日から依頼を届けるので、仕組みが動いているように見えます。止める設定が入っているかどうかは、設定画面を開かないと分かりません。
仮想例
先の架空の会社なら、取り込み先に担当者の承認必須を入れると、決済まわりに触れる提案だけが外注のリーダーの承認を待ちます。担当者を書いていない所の文言を直す提案は、リーダーの承認を待ちません。
A&Aの考え方
非公開のリポジトリを無料のプランで使っている場合、A&A は、設定より先にプランを確かめる所から始めると考えます。
| 設定 | 提案が出たとき | 承認なしで取り込めるか |
|---|---|---|
| 担当者を書いただけ | 担当者に確認の依頼が届く | 取り込める |
| 承認必須を入れた (社長のアカウントで AI) | 担当者の承認を待つ | 社長は管理者として取り込める |
| AI を別アカウントにし、管理者にも制限 | 担当者の承認を待つ | 取り込めない (管理者も同じ) |
AIは別アカウントで動かし、管理者にも制限をかける
A&Aの考え方
AI の提案は、社長とは別の、書き込みの権限だけを持つアカウントから出させ、管理者にも同じ制限をかけます。A&A が勧める理由は、管理者の扱いの既定と、社長のアカウントで AI を動かすと残る抜け道です。
出典に基づく事実
公式文書によると、ブランチ保護の制限は、既定ではリポジトリの管理者に当てはまりません。管理者にも同じ制限をかける項目は保護の設定にあり、画面には英語で Do not allow bypassing the above settings と出ます。
仮想例
社長が自分の GitHub アカウントのまま、Claude Code に提案を出させているとします。提案は社長の名前で出て、社長はリポジトリの管理者です。
A&Aの考え方
A&A は、この形では承認を必須にしても、承認なしで変更が入る道が残ると見ています。社長は自分の名前の提案を承認できませんが、管理者として承認なしで取り込めるので、Claude Code が社長の権限で取り込みまで進めても止まりません。
出典に基づく事実
公式文書によると、承認を 1 件必須にすると、ふつうは「書いた人と承認した人」の 2 人が関わります。GitHub は、自社の AI の Copilot が人の代わりでなく自分の名前で提案を出すと、この前提は成り立たないと書いています。そのためルールセットには、その提案にだけ承認を 1 件上乗せする項目があります。
A&Aの考え方
この項目は Claude Code の提案には効きません。それでも A&A は、AI の提案では承認 1 件が 2 人の確認にならない点は、Claude Code も同じだと考えます。
A&Aの考え方
そこで A&A は、AI 専用のアカウントを 1 つ用意し、Claude Code にはそこから提案を出させます。管理者にも制限をかける項目もオンにすれば、社長が管理者として承認なしに取り込む道も閉じます。
A&Aの考え方
ただし、この形でも、AI に頼んだ本人が承認すると、確かめたのは 1 人だけです。そこで A&A は、先の会社なら決済まわりの担当者に書いた外注のリーダーのように、頼んだ本人以外が承認することを勧めます。
A&Aの考え方
その代わり、社長が自分で出す変更も誰かの承認を待ちます。別アカウントで利用料が増えるかは、GitHub の料金の説明で、契約中のプランを確かめます。
効いているかは、取り込んだ提案の承認者で確かめる
A&Aの考え方
設定が効いているかは、設定画面と、直近に取り込まれた提案の承認者を並べて見ると分かります。設定画面だけでは、管理者が承認なしで取り込んだ変更に気付けないからです。確かめる所は次の 4 つです。
A&Aの考え方
担当者の指定: 担当者のファイルで、最後に当てはまる行を見ます。抜けていると、依頼が思った人に届きません。
A&Aの考え方
承認を必須にする設定: 取り込み先のブランチ保護か、ルールセットを見ます。抜けていると、担当者の承認なしで取り込めます。
A&Aの考え方
管理者への制限: Do not allow bypassing the above settings の項目と、AI が使うアカウントの権限を見ます。抜けていると、社長の権限で、承認なしに入ります。
A&Aの考え方
取り込んだ提案の承認者: 直近に取り込まれた提案の承認者を見ます。抜けていると、設定の抜けに気付きません。
A&Aの考え方
A&A が勧める確かめ方は、直近に取り込まれた提案を数件開き、誰が承認したか、承認なしで入ったものがないかを見ることです。設定を変えた後にも、同じ見方でもう一度見ます。
A&Aの考え方
AI や外注がこのファイルを書き換える提案を出せる以上、A&A は、このファイルも承認の対象に入れておくべきだと考えます。担当者の名前を書き換える提案が、承認なしで通らないようにするためです。
A&Aの考え方
リポジトリを全部一度に確かめる必要はありません。AI が提案を出す回数が一番多いリポジトリから、1 つずつ進めれば足ります。全部を一度にそろえるより、決済や顧客の情報に触れる所を先にそろえます。
A&Aの考え方
どの変更を誰の承認で止めるかは、AI に今どこまで任せられるかの見立てと一緒に決まります。A&A は、AI が今どこまでできるかを毎日の実運用で見ています。その立場から人と AI の線を引き、線を引いた人がそのまま設定まで受け持つ形で、この判断を手伝っています。
まとめ
A&Aの考え方
担当者のファイルは確認の依頼を届けるだけで、承認なしの取り込みは止めません。
A&Aの考え方
承認を必須にする設定は、ブランチ保護かルールセットで別に入れます。非公開のリポジトリでは有料のプランが前提です。
A&Aの考え方
AI を社長の管理者アカウントで動かすと、承認なしで取り込める道が残ります。AI を別アカウントで動かし、管理者にも制限をかけると、この道が閉じます。
A&Aの考え方
効いているかは、直近に取り込まれた提案の承認者で確かめます。
担当者のファイルは宛先を決めるだけで、承認なしの取り込みは止めません。AI の変更を承認なしで通さないには、承認を必須にする設定を入れ、AI を社長とは別のアカウントで動かして管理者にも制限をかけ、直近に取り込まれた提案の承認者で効いているかを確かめます。
よくある質問
一人で会社を回していて、承認する人がいないときはどうしますか。
承認を必須にする設定は合わないことがあります。AI を別アカウントにしても、AI の提案を承認できるのは作業を頼んだ本人だけなので、確かめるのは 1 人のままです。また、提案を出した本人は自分で承認できないので、管理者にも制限をかけると、自分の変更まで止まります。A&A は、その場合は取り込んだ後に見て、問題があれば戻せる運用を選ぶ方が合うと考えます。戻せるかどうかで任せる範囲を決める考え方は、関連記事「AIに実行まで任せる線引き：金額ではなく、取り消せるかで決める」で扱っています。
担当者を複数書けば、全員の承認が要りますか。
要りません。公式文書によると、担当者の承認を必須にしたとき、担当者が複数いれば誰か 1 人の承認で足ります。また、担当者を同じ行に並べずに別々の行へ書くと、担当者になるのは最後に当てはまった行の人だけです。
無料のプランでも、承認を必須にする設定は使えますか。
公開しているリポジトリなら使えます。公式文書によると、非公開のリポジトリでブランチ保護と CODEOWNERS を使えるのは有料のプランです。
出典・編集情報
記事の調査で確認した一次資料です。資料の公開・更新時期と、調査時の確認日を分けて記載しています。
- About code owners
GitHub Docs · Publication date not stated on page
確認日 2026-10-21 - About protected branches
GitHub Docs · Publication date not stated on page
確認日 2026-10-21 - Approving a pull request with required reviews
GitHub Docs · Publication date not stated on page
確認日 2026-10-21 - Available rules for rulesets
GitHub Docs · Publication date not stated on page
確認日 2026-10-21 - About rulesets
GitHub Docs · Publication date not stated on page
確認日 2026-10-21