GitHubがCopilotコードレビューをRESTとGraphQLのAPIで管理可能にしレビュー概要を簡潔に：エンタープライズ・組織・リポジトリの設定を読み書きできるが、エンタープライズと組織のエンドポイントはGitHub Appsとfine-grainedトークンに非対応で、最大レビュー強度・課金・承認はAPI外のまま

2026年11月6日、GitHubは「Copilot code review: API management and review overview updates（Copilotコードレビュー：API管理とレビュー概要の更新）」というチェンジログを公開しました。Copilotコードレビューの設定を、エンタープライズのポリシーから個別のリポジトリまで、RESTとGraphQLのAPIで管理できるようになり、プルリクエストにCopilotが付ける概要コメントがより簡潔になったと述べています。更新はCopilot Pro、Pro+、Max、Business、Enterpriseの各プランで利用できるとされています。どの部分かがプレビューかどうかは書かれておらず、価格の変更も示されていません。これはベンダーのチェンジログで、私たちはエンドポイントを試していません。

この変更の前から、REST APIでは開発者がレビューを依頼し、レビューの強度を選び、情報を読み取ることができました。記事は三つを加えています。第一に、明示的な帰属フィールドがCopilotのレビューとコメントを識別します。第二に、レビューが使った強度が、そのメタデータがある場合に応答に示されます。第三に、あるコメントの情報源としてCopilotが報告したスキル、MCPサーバー、カスタム指示が一覧になります。「報告した」という言い方が重要です。これらのフィールドはCopilotが使ったと自分で述べた内容を表し、記事はそれを検証する方法があるとは述べていません。AIのレビューコメントを監査するチームにとって、これらのフィールドは、Copilotの出力と人間のコメントを区別し、指摘が何に基づくかを知る助けになります。

設定の部分は、GitHubの管理の三つの層に沿っています。エンタープライズ管理者は、すべての組織でコードレビューを有効または無効にでき、選択を組織管理者に任せることもできます。組織管理者は、有効化、既定のレビュー強度、ランナー構成を管理できますが、エンタープライズが管理する設定は上書きできません。リポジトリ管理者は、レビューの強度と、レビューでカスタム指示やMCPツールを使うかどうかを管理できます。REST APIはWebインターフェースと同じ強度の段階を受け付け、設定の応答には呼び出し側が使える段階が列挙されます。GitHubのドキュメントでは、段階はLite（標準のレビュー）、Balanced（複雑なロジック、セキュリティに敏感なコード、サービス間の変更をより深く調べる、組み込みの既定値）、Max（複数の高推論モデルで最も集中的にレビューする）です。

記事には見落としやすい認証の注意があります。エンタープライズと組織の設定エンドポイントは、組織のランナーのエンドポイントを含め、GitHub Appsやfine-grainedな個人アクセストークンに対応していません。リポジトリの設定エンドポイントは両方に対応し、設定の読み取りにはAdministrationの読み取り権限、更新には書き込み権限が必要です。クラシックな個人アクセストークンにはリポジトリ管理者のアクセスが必要です。つまり、GitHub Appとして作った自動化はリポジトリは管理できても、組織やエンタープライズのポリシーは管理できません。ドキュメントはまた、設定ページの最大レビュー強度、課金、承認などの他の設定はAPIでは使えないと述べています。

レビュー概要コメントも変わります。新しい概要は、指摘を上部にまとめます。使われたレビュー強度とアンケートはコンパクトなフッターに移ります。スキップされたファイルと内容を理由に除外されたファイルは、「Files not reviewed」という一つの区画にまとめられ、ファイル名とリンク付きの理由が示されます。空の区画は省かれ、長い一覧には超過分の数が表示されます。概要に低評価を付けると、同意できない承認の評価、冗長すぎるコメント、誤った指摘や細かすぎる指摘など、理由を追加できます。

その他の改善には、Copilotコードレビューのエージェントセッションに消費したAIクレジットを表示すること、「Automatically request Copilot code review」リポジトリルールがバイパスリストに対応し、リストにある対象者は自動レビューを受けないこと、同じプルリクエストの後のレビューで、最近の変更と関係のない指摘を折りたたんでから隠すこと、Balanced強度のレビューが三つのレビューモデルを使い、別のモデルがそれらの指摘を統合することがあります。不具合の修正としては、コードレビューをオフにしてオンに戻しても課金とプレビューの設定を保持すること、失敗またはタイムアウトしたレビューを一度自動で再試行し、優先モデルが使えないときは別の適格なモデルに切り替えること、外部のCopilotライセンスで依頼されたレビューをブロックする設定がオンで組織が支払う場合に、GitHub Actions、Dependabot、組織所有のアプリがボット作成のプルリクエストでレビューを依頼できるようにすること、レビュー開始直後の誤った失敗の報告をなくすことが挙げられます。

GitHubのドキュメントは自動レビューについての規則を補っています。プルリクエストは、ユーザー自身の設定、リポジトリのルールセット、組織のルールセットという複数の独立した出所から自動レビューの対象になりえます。これらは別々に評価され、Copilotが投稿するレビューは一つのままで、ルールセットが有効にしたプッシュ時やドラフトのレビューを、ユーザーの設定で無効にすることはできません。

私たちの見方です。管理者にとって有用なのは、ポリシーをコードにできる点です。チームは、ページをたどる代わりに、エンタープライズ、組織、リポジトリの設定をスクリプトで管理し、コメントの出所を示せます。限界も明確です。認証の規則により、上位二つの層ではGitHub Appによる自動化ができず、重要な制御はAPIの外にあり、情報源のフィールドはCopilotの自己申告で、記事にはレビュー品質の数字がありません。まず小さなリポジトリでエンドポイントを試すことをお勧めします。