はじめに

GitHub の Pull Request（PR）で Copilot にコードレビューを頼んでいるリポジトリは、設定を何も触っていなくても、2026年9月28日からレビューの水準が切り替わっています。レビューの深さを決める effort（レビュー水準） の「Default」が、Balanced として動くようになったためです。さらに10月2日のチェンジログでは、REST と GraphQL の API から Copilot にレビューを依頼できるようになったことが発表されました。

ここで迷うのが、Default のまま放置してよいのか、Lite に切り替えるべきなのか、そして CI やスクリプトから依頼するときに水準をどう指定するのか、という点です。チェンジログは「リクエストごとに水準を指定できる」と書いていますが、肝心のパラメータ名は本文に出てきません。

対象読者は、GitHub Copilot のコードレビューをチームで使っている方と、CI やスクリプトからレビュー依頼を自動化したい方です。

この記事は GitHub の公式ドキュメントとチェンジログ（2026年10月9日時点）の記述に基づく解説で、実環境での挙動は検証していません。ドキュメントで確認できなかった点はその旨を明記し、読者が自分で確かめる手順を載せています。

TL;DR

Lite と Balanced の違いを押さえ、リポジトリの既定をどちらにするか決められます
PR 画面・gh CLI・REST API の3経路で Copilot にレビューを依頼できます
既定水準を変える場所（Enterprise / Organization / Repository / 個人）が分かります
API で水準を指定するパラメータ名は、執筆時点のドキュメントで確認できませんでした（確かめ方は後半に載せています）

9月28日と10月2日に何が変わったか

GitHub のチェンジログ「Copilot code review: API support and new default effort level」（2026年10月2日）は、2つの変更をまとめて伝えています。

日付	出来事
2026-08-28	既定のレビュー水準を Balanced に変えることを告知
2026-09-28	Default が Balanced として動作するように有効化
2026-10-02	REST / GraphQL API からのレビュー依頼に対応（チェンジログ公開）

1つ目は API 対応です。チェンジログには次の一文があります。

You can now request a review from Copilot using the supported REST and GraphQL APIs.

あわせて、リクエストごとに任意でレビュー水準を指定できるとも書かれています。ただし、どのエンドポイントのどのパラメータで指定するのかは、チェンジログ本文には書かれていません。

2つ目は既定水準の変更です。

Balanced is also now the default review effort level.

チェンジログによると、水準の設定が「Default」になっている場合は、新規・既存を問わず、リポジトリでも Organization でも Balanced で動きます。明示的に Lite を選んでいた設定はそのまま維持されます。つまり影響を受けるのは「何も選ばずに Default のまま使っていた」リポジトリです。

提供対象は Copilot Pro / Pro+ / Max / Business / Enterprise の5プランで、一般提供（GA）とされています。

Lite と Balanced の違い

公式ドキュメント「Using GitHub Copilot code review」は、2つの水準を次のように説明しています。

水準	公式ドキュメントの説明（要約）
Lite	バグ、セキュリティ脆弱性、スタイルの不統一といった明らかな問題に絞ってフィードバックする、コスト効率重視のレビュー
Balanced	複雑なロジック、セキュリティに敏感なコード、サービス横断の変更をより深く分析し、推論力の高いモデルを使う
Default	9月28日以降は Balanced として動作（明示的に Lite を選んだ設定は対象外）

Lite の原文は次のとおりです。

Cost-efficient review that provides targeted feedback on glaring issues such as bugs, security vulnerabilities, and style inconsistencies.

ざっくり言うと、Lite は「誰が見ても分かる問題を手早く拾う」レビューで、Balanced は「設計や影響範囲まで踏み込んで読む」レビューです。水準ごとのコスト（課金上の消費量）は、ドキュメント間で記述を突き合わせきれなかったため、この記事では扱いません。導入前に公式の課金関連ドキュメントで確認してください。

選び方の目安

以下は公式の説明から組み立てた目安で、GitHub が示した基準ではありません。分岐の軸は、ドキュメントが Balanced の得意分野として挙げている3点（セキュリティに敏感なコード、複雑なロジック、サービス横断の変更）です。

具体例に落とすと、次のような分け方になります。

Balanced に向く変更: 認証・認可、トークンや秘密情報の扱い、複数サービスの API 契約に触れる変更、状態遷移や並行処理を含むロジック
Lite で足りる変更: 文言やドキュメントの修正、フォーマットだけの差分、影響範囲の小さい設定変更

依存パッケージの更新のように、差分は小さくても中身次第でリスクが変わるものは、PR ごとに水準を選ぶのが無難です。

もう1つの判断材料は「Default を明示的な値として扱わない」ことです。9月28日の変更で分かるとおり、Default が何を指すかは GitHub 側の告知で変わります。チームとして Lite か Balanced かを決めたなら、Default のままにせず、その値を明示的に選んでおくと、将来の既定変更に左右されません。

手順1: 既定のレビュー水準を設定する

チェンジログによると、既定水準は4つの階層で設定でき、各レベルは上位レベルの設定を上書きできます。

階層	設定画面の場所
Enterprise	AI controls → Agents → Copilot code review
Organization	Copilot → Code review
Repository	Copilot → Code review
個人	プロフィール画像 → Copilot settings → Copilot → Code review

たとえば Organization 全体は Balanced にしておき、文言修正が中心のドキュメント用リポジトリだけ Lite に下げる、といった分け方ができます。Default から Lite へ切り替えたい場合も、この4か所のいずれかで変更します。設定手順の詳細は、チェンジログからリンクされているコードレビューの設定ドキュメントにまとまっています。

階層の設定とは別に、PR 単位でも水準を選べます。公式ドキュメントによると、PR の Reviewers 欄でレビューを依頼する前に水準を選択でき、個人設定では自分が依頼するときの既定を持てます。自動レビューを使っている場合、その既定水準は Organization owner とリポジトリ管理者が設定できます。

手順2: レビューを依頼する

依頼の経路は3つあります。公式ドキュメントによると、依頼したレビューは既定では「Comment」として PR に付きます。

経路1: PR 画面の Reviewers 欄

最も手軽な経路です。Reviewers 欄で Copilot を選び、依頼する前に水準（Lite / Balanced）を選べます。PR ごとに水準を変えたい場合に、ドキュメントで操作を確認できるのはこの経路です。

経路2: gh CLI

公式ドキュメントには、gh CLI で Copilot をレビュアーに指定するコマンドが2つ載っています。

# PR の作成と同時に Copilot をレビュアーに指定する
gh pr create --reviewer @copilot

# 既存の PR に Copilot をレビュアーとして追加する（PR-NUMBER は PR 番号）
gh pr edit PR-NUMBER --add-reviewer @copilot

@copilot という指定で Copilot をレビュアーとして扱えるので、PR を作るスクリプトに1行足すだけで依頼まで自動化できます。なお、このドキュメントには gh から水準を指定するオプションの記載はありませんでした。gh 経由で依頼したときにどの水準が使われるかも、ドキュメント上では明記を確認できていません。

経路3: REST API

REST API では、Copilot のボットアカウント copilot-pull-request-reviewer[bot] をレビュアーとして依頼します。使うのは「Request reviewers for a pull request」のエンドポイントで、リクエストボディには reviewers（ユーザーログインの配列）と team_reviewers（チームスラッグの配列）を渡します。

ドキュメントの2つの記述（レビュアーとして copilot-pull-request-reviewer[bot] を依頼する／reviewers はログインの配列）を組み合わせると、リクエストボディは次の形になります。この形での送信結果は、この記事では検証していません。

{
  "reviewers": ["copilot-pull-request-reviewer[bot]"]
}

REST リファレンスに書かれている注意点は2つです。

細粒度トークン（fine-grained token）を使う場合、必要なリポジトリ権限（調査時点の資料では「Pull requests」の write とされていました）を、利用前に REST リファレンスで確認してください
短時間にコンテンツを大量に作成すると、セカンダリレート制限（GitHub が定める補助的な利用制限）の対象になる可能性があると、このエンドポイントのリファレンスに警告があります

CI から多数の PR へ一斉に依頼するような設計は、この制限に当たりやすくなります。依頼は PR の作成時に1回だけにするなど、回数を絞る設計が安全です。

REST リファレンスのパラメータ一覧には、執筆時点で水準を指定する項目がなく、Copilot 固有の注記もありません。GraphQL については、チェンジログが対応を明言している一方で、利用ガイドのページには記載がありません。

手順3: ドキュメントで確認できなかった点を確かめる

API 対応は発表されたばかりで、ドキュメントの記述がまだ揃っていません。執筆時点で確認できなかった点と、その確かめ方を整理します。

確認できなかったこと	現状	確かめ方
API で水準を指定するパラメータ名	チェンジログは「リクエストごとに指定できる」と書くが、REST リファレンスに該当項目がない	REST リファレンスの review-requests ページのパラメータ一覧が更新されていないかを確認する
GraphQL で使う入力フィールド名	利用ガイドに GraphQL の記載がない	GraphQL スキーマの入力型を調べ、レビュー依頼に使う入力に水準を表すフィールドがあるかを見る
Max プランの詳細	提供対象として名前が挙がっているのみ	GitHub の Copilot 料金ページでプランの内容を確認する

パラメータ名が分からない段階でも、依頼そのものと水準の違いは確かめられます。テスト用のリポジトリで、次の順に確認するのがおすすめです。

小さな変更で PR を作り、gh pr create --reviewer @copilot でレビューを依頼する
付いたレビューが「Comment」であり、Approve や Request changes ではないことを確認する
同じ差分の PR を2本用意し、Reviewers 欄で片方を Lite、もう片方を Balanced にして依頼し、指摘の数と踏み込み方を比べる
REST で依頼する予定なら、使うトークンに「Pull requests」の write 権限があるかを先に確認する

3番目の比較を自分のコードベースで1回やっておくと、Lite で足りるか Balanced が要るかを、ドキュメントの説明ではなく自分のリポジトリの差分で判断できます。

運用で押さえておく3つの特性

公式ドキュメントには、運用設計に直結する仕様が3つ書かれています。

1つ目は、Copilot のレビューは既定では「Comment」のみ で、Approve や Request changes にはならないことです。そのため、ブランチ保護の「必須承認」にはカウントされません。Copilot のレビューだけでマージ条件を満たす設計はできません。

2つ目は、承認機能（public preview）を有効にすると Copilot が Approve を出せる ことです。ただし、新しいコミットを push すると、その承認は取り消されます。レビュー後に修正コミットを積む運用では、push のたびに承認が外れる前提で考える必要があります。

3つ目は、Copilot はレビューコメントへの返信には応答しない ことです。指摘に反論や質問を返しても、Copilot との対話にはなりません。指摘への対応方針（直した、直さない理由）は、人間のレビュアーやあとから読む人に向けた記録として残す位置づけになります。

自前のセルフレビューと併用するときの設計判断

ここからは事実と考察を分けて書きます。

事実（このブログの運用）: このブログは Claude Code のスケジュール実行で記事の執筆から公開までを回しており、運用基盤そのものを改修する PR では、PR を作ったセッション自身が観点別のセルフレビューを実行し、機械チェックとセルフレビューを通過したら自動でマージしています。Copilot へのレビュー依頼は、運用ルールとして廃止しています。理由は、外部レビュアーの応答を約25分待つ待機をなくすことと、外部の従量課金に依存せずコストを定額の枠内に収めることでした。現時点の運用ルールは「依頼しない」のままです。

考察（再導入を考える場合の設計）: 今回の API 対応で、無人のパイプラインからも Copilot にレビューを依頼しやすくなりました。仮に再導入するなら、上の3つの特性から次のように設計します。

マージ条件にしない: Comment のみで必須承認に数えられない仕様は、裏を返せば「待たずに並走させる」使い方と噛み合います。PR 作成時に依頼だけ出し、自前のセルフレビューの通過でマージを進め、Copilot の指摘はあとから拾って別の改善タスクにする形なら、応答待ちは再発しません
承認機能はゲートに使わない: セルフレビューの指摘を修正コミットで直す流れでは、push のたびに Copilot の承認が取り消されます。承認をゲートにすると、修正のたびに再承認を待つことになり、廃止した待機が別の形で戻ってきます
水準の出し分けは、パラメータ名が確認できるまでコードに書かない: 理想は、Markdown だけの記事 PR は依頼対象から外し、フックや権限設定に触れる改修 PR にだけ Balanced で依頼する出し分けです。ただし API で水準を指定する方法がドキュメントで確認できない以上、推測のパラメータをスクリプトに埋め込むのは避け、当面はリポジトリの既定水準を明示的に固定する形にとどめます
依頼は PR ごとに1回: セカンダリレート制限の注記があるため、レビューのやり直しを自動で何度も依頼するループは組みません

Copilot がレビューコメントへの返信に応答しない点は、このブログのように「指摘への対応結果をスレッドに書いて閉じる」運用とはむしろ相性がよいと考えています。対話を前提にしない分、記録の置き場所を人間側で決めておけば足りるからです。

まとめ

2026年9月28日から、水準が Default のリポジトリでは Copilot のコードレビューが Balanced で動きます。明示的に Lite を選んだ設定は維持されます
Lite は明らかな問題に絞ったコスト効率重視のレビュー、Balanced は複雑なロジック・セキュリティ・サービス横断の変更まで踏み込むレビューです
依頼は PR 画面、gh pr create --reviewer @copilot / gh pr edit PR-NUMBER --add-reviewer @copilot、REST API（copilot-pull-request-reviewer[bot] を reviewers に指定）の3経路です
API で水準を指定するパラメータ名と GraphQL の入力フィールド名は、執筆時点のドキュメントで確認できませんでした
レビューは Comment のみでマージ条件にならず、返信にも応答しないため、既存のレビュー体制を置き換えるより、並走させる追加の観点として設計するのが扱いやすい形です

まずはテスト用リポジトリで Lite と Balanced を同じ差分に当て、自分のコードベースでどれだけ差が出るかを確かめるところから始めてください。

関連記事

参考リンク

Copilot code review: API support and new default effort level（GitHub Changelog・2026-10-02。API 対応と既定水準の変更）
Using GitHub Copilot code review（GitHub Docs。水準の説明・依頼方法・Comment のみの仕様）
Copilot code review の設定ドキュメント（GitHub Docs。既定水準の設定）
Request reviewers for a pull request（GitHub REST API Docs。レビュー依頼のパラメータ・権限・レート制限）