AIが​書いた​コードを、​AIが​レビューする​ ──GitHubが​レビューの​上限を​外した​日と、​誰の​権限とお金で​回るのか

2026年8月27日、GitHubがコードレビューを担うAIの制限を3つ外した^[1]。①ボットが作った変更もレビュー対象に ②300ファイル・2万行という上限を撤廃 ③AIの指摘を閉じるときに理由を選んで残せる。細かい改善に見えるが、並べると背景が透けて見える。

人が読み切れない大きさの変更が、日常的に出てくるようになったということだ。上限を外すのは、そこに収まらない変更が現実に増えたからで、ボットのPRをレビュー対象にするのは、変更を書く側がすでに人ではなくなっているからだ。

この記事で扱うのは4つ。①何が外れたのか ②誰の権限とお金で動くのか ③「間違っている」と記録できることの意味 ④導入前に決めること。②には見落としやすい前提がある。この機能はGitHub Actionsの上で動き、既定では閉じている。

01 外れた​3つの​制限──上限の​撤廃が​示すもの

変わったこと	これまで	これから
ボットが作った プルリクエスト	自動レビューの対象外（レビューを紐づける有償アカウントがないため）	レビューできる。利用分は組織に直接課金される
AIエージェントが 作ったもの	限定的なレビューに落ちていた	通常どおりのレビューが当たる
変更の大きさ	300ファイル／2万行を超えるとレビューできない	上限そのものが撤廃
指摘を閉じるとき	ただ閉じるだけ	理由を3つから選べる（後述）

読み筋は3行目にある。300ファイル・2万行は、人間のレビューではまず現実的でない規模だ。その上限を外したということは、「そこに収まらない変更が実際に来ている」という認識が前提にある。エージェントに実装を任せれば、変更は一度に大きくなる。人の手が追いつかない場所から順に、AIが入っていく。

02 誰の​権限と、​誰の​お金で​動くのか──既定では​閉じている

ボットが作ったプルリクエストには、レビューを紐づける有償アカウントがない。ではどう回すのか。GitHubの答えは組織に直接請求するだった^[1]。

そのためには、管理者が2つのポリシーを順番に有効にする必要がある^[2]。

順番	設定	意味
1	AIクレジットの 従量課金を許可	組織や企業が、コードレビューのAIクレジット利用分の費用を負うことを認める
2	ライセンスのない メンバーの利用を許可	Copilotのライセンスを持たない組織メンバーでも、GitHub.com上でコードレビューを使えるようにする

この2つ目は既定で無効だ^[2]。さらに、企業レベルで設定すると組織側からは見えるが編集できなくなる。設定は「最も制限の強いものが勝つ」形で効く。放っておいて勝手に始まる機能ではない——ここは昨日扱ったモデルポリシーとは逆の向きになる。

関連記事 ｜ 既定がどちらに倒れるか社員のAI利用を、会社はどこまで見られるか ──8月26日に重なった3つの統制機能と、放置したときに倒れる向き →

もうひとつ、動く場所の話がある。このレビューの高度な部分（リポジトリ全体を読んで文脈を集める、指摘をエージェントに渡して修正版のプルリクエストを作らせる）は、GitHub Actionsのランナーを使って動く^[2]。公式ドキュメントには、Actionsが使えない場合やワークフローが失敗した場合でもレビュー自体は生成されるが、エージェント機能による追加分は付かないと書かれている。

つまり、同じ「Copilotのレビュー」でも、環境によって中身が変わる。レビューが薄いと感じたときに疑う先が、モデルの調子ではなくActionsの状態である場合がある、ということだ。

03 ​「間違っている」と​記録できる​──却下が​データに​なる

3つ目の変更は地味だが、運用としては重い。Copilotの指摘を閉じるとき、「対応した（Addressed）」「対応しない（Won't fix）」「間違っている（Incorrect）」の3つから理由を選べるようになった^[1]。「会話を解決」ボタンの隣に付いたドロップダウンから選ぶ形だ。

効くのは3つ目だ。これまで、AIの指摘に納得できないときの選択肢は「黙って閉じる」しかなかった。閉じた理由が残らないので、「指摘が的外れだった」のか「面倒で放置した」のかを後から区別できない。理由が付けば、そこが分かれる。

GitHubはこれを製品改善のフィードバックとして使うと書いている^[1]。ただ現場にとっての意味はもう少し手前にある。AIのレビューを導入するとき、いちばん怖いのは「まちがった指摘に振り回されること」だ。却下の理由が形として残るなら、どのくらい外していたのかを、印象ではなく件数で振り返れるようになる。

04 導入するなら​決めて​おく​こと​──4項目

• 費用の出どころ。 ライセンスのないメンバーやボットのぶんは組織に請求される。まず「AIクレジットの従量課金を許可」を有効にする必要があるので、誰がその判断をするかを先に決める^[2]。
• どのプルリクエストを自動レビューに載せるか。 エージェントが作るものまで対象にすると件数が増える。全部に自動で当てるのか、人が指定したときだけかを決める。
• Actionsの状態を監視するか。 Actionsが落ちてもレビューは出るが、文脈収集や修正版の作成は付かない^[2]。「出ているのに薄い」状態を見分ける手立てを用意しておく。
• 却下の理由を書く運用にするか。 3つの理由を選ぶ運用にすれば、AIの指摘の当たり外れが記録として溜まる。3か月後に見直すつもりなら、最初から付ける。

05 人は、​どこを​見る​側に​回るのか──役割が​上に​動く

ここまでの変更を並べると、レビューの構図が変わってきているのが分かる。書くのがエージェント、一次のレビューもエージェントという組み合わせが、例外ではなく既定の経路として整備された。

では人は何をするのか。個々の行を読む役から、AIの指摘を採否する役へ動く。今回「Incorrect」を選べるようになったのは、その役割変更を製品が認めた形でもある。人がやるのは「この指摘は当たっているか」と「この変更を入れてよいか」の2つの判断で、行を1本ずつ追うことではなくなっていく。

もっとも、これは人の判断が減るという話ではない。読む対象が「コード」から「AIの指摘」に変わっただけで、間違った指摘を通せば、間違いはそのまま本番に入る。むしろ判断の1回あたりの重みは増している。

06 まとめ──上限が​外れたのは、​AIの​ためではない

問い	今回の答え
なぜ上限を外したのか	300ファイル・2万行に収まらない変更が現実に来ているから
誰が費用を払うのか	ライセンスのない利用は組織に直接請求。管理者が2つのポリシーを有効にして初めて動く
放置すると始まるのか	始まらない（既定で無効）。昨日扱ったモデルポリシーとは逆向き
レビューが薄いときの疑い先	モデルではなくGitHub Actionsの状態のことがある
人の役割はどうなるか	行を読む側から、指摘を採否する側へ

AIのレビューを入れる判断は、「精度が十分か」だけでは決まらない。費用の出どころ、動く場所、そして外れた指摘をどう記録するか——この3つを決めてから配ると、後から効いてくる。