GitHubは日本時間2026年11月7日9時27分、Copilotコードレビューの設定をREST・GraphQL APIで管理する機能などを発表しました。複数リポジトリの設定をそろえる担当者には便利ですが、先に確認すべきなのは管理する階層、認証方式、継承された実効値です。公式発表ではPro、Pro+、Max、Business、Enterpriseが対象とされています。
APIで扱う設定と、画面で扱う設定
| 管理階層 | 今回のAPI管理の主な範囲 |
|---|---|
| Enterprise | コードレビューの有効・無効、組織管理者への判断の委任 |
| Organization | 委任されている場合の有効・無効、既定のreview effort、ランナー構成 |
| Repository | review effort、カスタム指示とMCPツールの使用設定 |
一方、最大review effort、課金、承認に関する設定は、このAPI管理の対象外です。必要ならGitHubの設定画面を使います。また、リポジトリのレビュー設定を変更しても、自動レビュー自体が有効になるわけではありません。自動実行は個人設定やルールセットを別途確認します。設定範囲の公式説明を基準に、変更項目を一つに絞りましょう。
認証方式は階層ごとに確認する
公式発表によると、EnterpriseとOrganizationの設定エンドポイントは、組織のランナー設定も含めてGitHub Appsとfine-grained personal access tokensに対応していません。Repositoryの設定エンドポイントは両者に対応し、読み取りにはAdministration: read、変更にはAdministration: writeが必要です。classic PATを使う場合もリポジトリ管理者としてのアクセスが必要です。
「同じトークンで別APIは呼べた」だけでは、今回の操作権限が足りる証拠になりません。組織で認められた認証方式を使い、トークン文字列を原稿・共有ログ・チケットへ貼り付けない運用にしてください。
1リポジトリで継承へ戻すGraphQL例
- 現行のCopilot GraphQLスキーマで、mutationの入力項目と戻り値を確認します。
- 対象リポジトリのSettings → Copilot → Code reviewを開き、現在のreview effort、カスタム指示、MCP設定を記録します。組織・企業の既定値も確認します。
- 対象のGraphQLノードIDを取得し、変数repositoryIdへ設定します。リポジトリ名やURLをそのままIDとして渡さないでください。
- 次のmutationを、その1リポジトリだけに適用します。これは設定変更の例であり、読み取り専用の操作ではありません。
mutation ConfigureReview($repositoryId: ID!) {
updateRepositoryCopilotCodeReviewSettings(
input: {
repositoryId: $repositoryId
reviewEffort: INHERIT
}
) {
settings {
availableReviewEfforts
reviewEffort { configured effective }
customInstructionsEnabled
mcpEnabled
}
}
}INHERITはリポジトリ独自のeffort指定を解除し、上位設定などから引き継ぐための値です。例ではカスタム指示とMCPの入力を省略しているため、それらの設定は変更しません。戻り値として読むことと、入力して変更することは別です。
例えば、社内ツールの試験リポジトリだけ独自のeffortを設定していた場合、現在値を記録してから継承へ戻し、組織の既定運用に合うか確認できます。意図どおりでなければ記録した値と利用可能なeffortを照合して戻し、一括展開は確認後に判断します。
configuredとeffectiveを読み分ける
configuredは保存されている指定、effectiveはリクエストした人や対象PRがeffortを指定しない場合に使う既定値です。個別のリクエストやPRで別途指定されたeffortまで、この値で決まるわけではありません。configuredがnullでも、継承中や指定値が現在利用できない場合があり、それだけで失敗とは判断できません。effectiveとavailableReviewEfforts、設定画面を照合してください。変更後はカスタム指示・MCPの状態も記録した値と比較します。
Organizationのポリシー変更でPOLICY_MANAGED_BY_ENTERPRISEが返る場合は企業側が管理しています。Organizationの設定変更に対するSETTING_NOT_EDITABLEも、組織側で変更できない状態を示します。これらは組織レベルの操作のconflict値です。上に掲載したリポジトリ用mutationではsettingsの戻り値を確認します。認証・管理権限・上位ポリシー・利用可能なeffortの順に確認し、権限を広げる前に原因を切り分けましょう。
レビュー結果でも確認する
今回の更新では、Copilotが投稿するレビュー概要も整理され、対象外のファイルをFiles not reviewedで確認しやすくなりました。設定が成功しても、すべてのファイルをレビューしたとは限りません。レビューの利用ガイドに沿って結果と参照情報を読み、人の確認につなげてください。
調査対象期間：日本時間2026年11月7日8時00分〜11月8日7時57分。公式発表・公開スキーマに基づく解説です。記載のmutationは実際の組織・リポジトリに対して実行しておらず、実環境での動作確認は行っていません。
コメント