CopilotがApproveできる時代に、開発者の仕事はどう変わるのか
Copilotが「Approve」できるようになった、それが何を変えるのか
2026年9月1日、GitHubがひっそりとしかし重要なアップデートを発表した。Copilot code reviewが、Pull Requestを正式に「Approve」できるようになった。
地味に聞こえるかもしれないが、これは見た目より大きい変化だ。
これまでのCopilotによるレビューは「コメント」と「変更のリクエスト」の2択だった。つまり指摘はできるが、承認だけは人間がやらなければならなかった。GitHubのブランチ保護ルール（Branch protection / Rulesets）では多くのチームが「最低1件のApproveが必要」という条件をmainへのマージに課している。この「最後の1票」が、必ず人間の仕事として残っていた。
それが今回、AIが埋められるようになった。
自律開発ループとはどういう構成か
この変化を使うと、次のような開発の流れが組める。
Issue（やりたいこと）
↓
Copilotが実装してPRを作成
↓
Copilot code reviewが自動でレビュー
↓
問題なければCopilotがApprove
↓
Auto MergeがCI通過を待って自動マージ
↓
mainが進む → 次のIssueへ
人間の作業は「Issueを書くこと」と「たまに監督すること」に集約される。実装・レビュー・承認・マージという一連の手作業をパイプライン化するというのが基本的な発想だ。
具体的な設定は3ステップに分かれる。
1. ブランチ保護ルールで土台を作る
リポジトリのSettings → Rules → Rulesetsで、mainに対して「PRなしのdirect pushを禁止」「Approveを必須（最低1件）」「CIのステータスチェックを必須」「マージ前にブランチを最新に保つ」を設定する。
2. CopilotをPRに自動割り当てる
Settings → Code review → Copilotで、対象ブランチへのPRに自動でCopilotをレビュアーとして割り当てるルールを有効化する。PRが立てば人間が依頼しなくてもCopilotがレビューを始め、問題なければApproveを返す。
3. Auto MergeをGitHub Actionsで自動化する
Settings → General → Pull RequestsでAllow auto-mergeを有効にしたうえで、PR作成時にAuto Mergeを予約するワークフローを置く。
# .github/workflows/auto-merge.yml
name: Enable auto-merge
on:
pull_request:
types: [opened, reopened]
permissions:
contents: write
pull-requests: write
jobs:
enable:
runs-on: ubuntu-latest
steps:
- name: Enable auto-merge
run: gh pr merge "$PR_URL" --squash --auto
env:
PR_URL: ${{ github.event.pull_request.html_url }}
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
これでPRが立った瞬間にAuto Mergeが予約され、CopilotのApproveとCIの成功が揃った時点で自動的にマージされる。人間はマージボタンに触れない。
ここからは見方の話：これは「承認ボタン」の話ではない
今回の変化を「CopilotがApproveボタンを押せるようになった」と整理するのは正確だが、本質を捉えきれていない。
重要なのは、ブランチ保護の「最後の1票」という構造的な制約が崩れた点だ。これまで自動化の議論でよく出てくるのは「実装はAIに任せてもレビューは人間がやる」という話だった。その根拠のひとつが「Approveできるのは人間だけ」という制度的な事実にあった。今回の変化はその前提を変えている。
元記事にある比較表は端的だ。
| 工程 | 従来 | これから |
|---|---|---|
| 実装 | 人間 | Copilot |
| レビュー | 人間 | Copilot code review |
| 承認 | 人間 | Copilot（Approve可に） |
| マージ | 人間 | Auto Merge |
| 人間の役割 | 全部 | Issue設計と監督 |
この表が示すのは、開発のワークフローが構造ごと変わるという話だ。「ちょっと便利になった」ではなく、人間が果たしていた役割の分類が変わる。
ただし、ここで一つ留保が要る。
「制度的に可能になった」ことと「実務で使えるレベルになった」は、必ずしも一致しない。CopilotのApproveが、熟練したエンジニアのレビューと同水準の品質担保を提供できるかは、コードベースの複雑さや対象ドメインによって大きく変わる。今回の変化は「自律ループの構成が技術的に成立する」という段階に到達したことを意味するが、「全プロジェクトで安心して使える」という段階はまだ先にある。
実務に落とす：安全に回すための設計が本番
自律ループの設計で一番重要なのは、Approveを自動化することではなく、品質の担保をCIに移管する覚悟を持てるかどうかだ。
元記事はこの点を正直に書いている。「Approveが自動化される分、品質の担保はテストが背負います。ここが薄いと自律ループはただの事故製造機になります」。
これは過言ではない。これまでは「CIは通ったが、レビューで問題が発覚した」という最終防衛ラインが人間にあった。それをAIに任せる以上、CIが薄い状態でループを回すのは危険だ。RSpec・RuboCop・型チェックなど、品質の基準をコードとして明示し、それを必須ステータスチェックに指定する作業が前提になる。
もう一つ重要なのが、CODEOWNERSによる人間ゲートの設計だ。db/migrate/、インフラ設定、認証まわりなど「壊れたとき影響が大きい箇所」は、CODEOWNERSで人間のApproveを必須にすることで自律マージの対象外にできる。「全部AIに任せる」ではなく「どこに人間を残すか」を設計する作業が、むしろ自律化の中心的な仕事になる。
段階的な導入も重要だ。最初からフル機能のPRを自律ループに乗せるのではなく、READMEの更新・テストの追加・ドキュメントの整備といった「壊れても軽傷なPR」から始めて、ループの挙動を確かめる。そのうえで範囲を広げるほうが、障害のリスクを抑えられる。
誰（何）がApproveしたかはGitHubの履歴に残る。定期的にCopilotのApprove内容を振り返って、レビューの精度が実際の品質基準に合っているかを確認する監査の習慣も必要になる。
次の論点：自律ループが普及したとき、何が問われるか
この種の変化が広がっていくと、いくつかの問いが浮かび上がる。
レビューの責任はどこにあるのか。
PRをApproveした主体がCopilotである場合、そのコードに問題があったとき、誰が責任を持つのか。現状の答えは「設定した人間・チーム」になるが、この問いはガバナンスの設計として顕在化してくる。特にプロダクションの障害や、セキュリティインシデントが絡んだとき、「AIがApproveした」は言い訳にならない。自律ループを回す組織は、AIのApproveを自組織の承認行為として引き受ける覚悟が必要だ。
開発者の役割が分化する。
自律ループが当たり前になると、「実装を書く」という作業の比重が下がり、「Issueを適切に書く」「CIの品質基準を設計する」「CODEOWNERSで人間のゲートを配置する」という上流の仕事の比重が上がる。これは元記事の言葉を借りれば、人間が「実装者」から「Issue設計者兼監督者」へ移るということだ。スキルセットの要求が変わる。
次のニュースをどこで見るか。
今後、「AIがXできるようになった」という発表が続く。判断軸として持っておきたいのは、「それはブランチ保護などの制度的な制約と、どう絡み合うか」という視点だ。今回のCopilot Approveが重要だったのは、技術的な改善だけでなく、「ブランチ保護の必須条件をAIが満たせるようになった」という構造変化だったからだ。同種の発表を見るとき、「何の制度的制約が崩れたか、あるいは新しく生まれたか」を確認するのが一つの軸になる。
まとめ
Copilot code reviewがPRをApproveできるようになった。それ自体は1行の機能追加だが、意味は大きい。ブランチ保護の「最後の1票」をAIが埋められるようになったことで、Issue → 実装 → レビュー → 承認 → Auto Mergeという開発の一連の流れを、人間が張り付かなくても回せる構成が現実的になった。
ただし、この構成が機能するかどうかは、CIの品質と、CODEOWNERSによる人間ゲートの設計にかかっている。自律ループは「人間を開発から外す」ための仕組みではなく、退屈な定型作業から人間を解放して、設計と監督という高い価値の仕事に集中させるための仕組みだ。
まずは軽いPRから一度回してみる。「マージボタンを押さない開発」の手触りは、議論より先に試した人間が知っている。
