GitHub Code QualityでCopilot自動レビューが止まる原因と再有効化方法

GitHub Code Qualityを有効にしているのに、ある日からプルリクエストへGitHub Copilotのレビューが付かなくなった場合、障害ではなく2026年8月7日の仕様変更が原因かもしれません。

GitHubは、Code Qualityの有効化時に自動作成していたCode Quality Copilot review for default branchルールセットについて、Copilotの自動レビューに関する3つの設定を無効化しました。Code Qualityそのものが停止したわけではありません。Copilotの自動レビューが必要な場合は、リポジトリまたはOrganizationのルールセットで再有効化できます。(The GitHub Blog)

目次

GitHub Code QualityでCopilotレビューが来なくなった原因

GitHub Code Qualityは、コードの保守性や信頼性に関する問題を検出するサービスです。プルリクエストではCodeQLによるルールベースの解析を実行し、問題が見つかるとgithub-code-quality[bot]がコメントを投稿します。

一方、GitHub Copilot code reviewは、Copilotをレビュアーとして割り当て、AIによるコードレビューを実行する別の機能です。Code Qualityを有効にしていても、Copilot code reviewが自動実行されるとは限りません。(GitHub Docs)

2026年8月7日に自動レビューの扱いが変更された

GitHub Code Qualityが2026年7月20日に一般提供された当初、リポジトリでCode Qualityを有効にすると、次の名前のルールセットが自動作成されていました。

Code Quality Copilot review for default branch

このルールセットはデフォルトブランチを対象とし、プルリクエストへCopilotのレビューを自動的に要求する設定を含んでいました。(The GitHub Blog)

しかしGitHubは、「レビュアーを追加するかどうかは利用者が選択すべき」とのフィードバックを受け、2026年8月7日にこの動作を変更しました。

変更後は、次のようになります。

  • Code Qualityを新たに有効化しても、Copilotを自動レビュアーにするルールセットは作成されない
  • 既存の自動生成ルールセットでは、Copilot自動レビューに関する設定が無効化される場合がある
  • GitHub Copilot code review自体は廃止されていない
  • 必要な管理者は、ルールセットから自動レビューを再有効化できる

今回変更されたのは、Code Qualityの解析機能ではなく、Copilotを自動的にレビュアーとして追加する初期設定です。(The GitHub Blog)

無効化された3つの設定

GitHubが自動生成したルールセットでは、次の3設定が無効化されました。(The GitHub Blog)

設定有効な場合の動作無効化後の影響
Automatically request Copilot code review対象ブランチへのプルリクエストでCopilotレビューを自動要求する新しいプルリクエストにCopilotが自動追加されない
Review new pushesプルリクエストへ新しいコミットをプッシュするたびに再レビューする最初のレビュー後にコードを更新しても自動再レビューされない
Review draft pull requestsDraft状態のプルリクエストもレビューするReady for reviewになるまで自動レビューされない

3つのうち、最も重要なのがAutomatically request Copilot code reviewです。この設定が無効だと、残りの2設定を有効にしてもCopilotの自動レビューは開始されません。

Review new pushesReview draft pull requestsは、レビューを実行するタイミングを追加するためのオプションです。

影響を受けるリポジトリと受けないリポジトリ

すべてのルールセットがGitHubによって書き換えられたわけではありません。

GitHubは、自動生成時の状態から変更されていないルールセットだけを対象に、3設定を無効化しました。利用者が編集したルールセットや、自分で作成したルールセットは変更していません。(The GitHub Blog)

リポジトリの状態今回の変更による影響
自動生成されたルールセットを編集せず使っていた3つの自動レビュー設定が無効化される可能性が高い
自動生成ルールセットを独自に編集していたGitHubによる自動変更の対象外
独自のリポジトリルールセットを作成していたGitHubによる自動変更の対象外
Organizationルールセットで自動レビューを設定していた独自作成したルールセットは今回の自動変更対象外
2026年8月7日以降にCode Qualityを有効化したCopilot自動レビュー用ルールセットは自動作成されない
Code Qualityを利用していない今回の変更による直接的な影響はない

リポジトリ内にCode Quality Copilot review for default branchというルールセットが残っていても、自動レビューが有効とは限りません。GitHubはルールセット自体を削除せず、該当する3設定をオフにした状態で残しています。

Code QualityとCopilot code reviewの違いを確認する

今回の変更で混乱しやすいのが、Code QualityのコメントとCopilotのレビューを同じ機能だと考えてしまうことです。

両者は次のように役割が異なります。

項目GitHub Code QualityGitHub Copilot code review
主な目的品質上の既知の問題やアンチパターンを検出するAIが変更内容を読み、コードレビューを行う
プルリクエスト上の主体github-code-quality[bot]GitHub Copilot
主な解析方法CodeQLによるルールベース解析AIによる文脈を考慮したレビュー
自動実行の設定Code Qualityの有効化設定Copilot設定またはルールセット
今回変更された機能変更なし自動レビュー要求の初期設定
手動でのレビュー要求対象外ReviewersからCopilotを指定可能

GitHubの公式ドキュメントでも、プルリクエスト上のCode QualityはルールベースのCodeQL検出を行い、AIによるプルリクエストレビューが必要な場合はCopilot code reviewを別途有効化するよう案内されています。(GitHub Docs)

したがって、github-code-quality[bot]のコメントが引き続き投稿されていても、Copilotレビューだけが来なくなることがあります。これはCode Qualityの故障ではありません。

自動レビューが無効になっているか確認する方法

まず、影響が疑われるリポジトリのルールセットを確認します。

リポジトリのルールセットを確認する

  1. 対象リポジトリを開きます。
  2. Settingsを開きます。
  3. 左側のメニューからRulesetsを開きます。
  4. ルールセット一覧でCode Quality Copilot review for default branchを探します。
  5. ルールセットを開き、Enforcement statusを確認します。
  6. Target branchesで対象ブランチを確認します。
  7. Branch rules内のAutomatically request Copilot code reviewを確認します。
  8. 必要に応じてReview new pushesReview draft pull requestsも確認します。

GitHubの現在の手順では、リポジトリのSettingsからルールセットを開き、ブランチルールとしてAutomatically request Copilot code reviewを設定します。(GitHub Docs)

プルリクエスト側でも確認する

対象のプルリクエストでは、次の点を確認してください。

  • Reviewers欄にCopilotが追加されているか
  • タイムラインにCopilotへのレビュー要求が記録されているか
  • github-code-quality[bot]のコメントだけが投稿されていないか
  • プルリクエストのベースブランチがルールセットの対象になっているか

Code Qualityのコメントだけがあり、Reviewers欄にCopilotがいない場合は、今回のルールセット変更によって自動レビューが止まっている可能性があります。

リポジトリ単位でCopilot自動レビューを再有効化する方法

特定のリポジトリだけで自動レビューを使いたい場合は、リポジトリレベルのルールセットを設定します。

既存のCode Quality Copilot review for default branchを再利用しても、新しいルールセットを作成しても構いません。

既存のルールセットを再利用する手順

  1. 対象リポジトリのSettingsを開きます。
  2. Rulesetsを開きます。
  3. Code Quality Copilot review for default branchを選択します。
  4. Enforcement statusActiveにします。
  5. Target branchesが適切か確認します。
  6. Automatically request Copilot code reviewを有効にします。
  7. 必要に応じてReview new pushesを有効にします。
  8. 必要に応じてReview draft pull requestsを有効にします。
  9. 変更を保存します。

既存ルールセットにCode Quality用の別ルールが含まれている場合は、削除して作り直すより、設定内容を確認して再利用した方が安全です。

新しいルールセットを作成する手順

既存ルールセットを残したくない場合や、対象ブランチを整理したい場合は、新しいブランチルールセットを作成します。

  1. リポジトリのSettingsを開きます。
  2. Rulesetsを開きます。
  3. New rulesetを選択します。
  4. New branch rulesetを選択します。
  5. ルールセット名を入力します。
  6. Enforcement statusActiveにします。
  7. Target branchesで対象ブランチを指定します。
  8. Automatically request Copilot code reviewを有効にします。
  9. 必要な追加オプションを選択します。
  10. ルールセットを作成します。

ルールセット名は、目的が分かる名前にしておくと管理しやすくなります。

例として、次のような名前が使えます。

  • Copilot automatic review for main
  • Copilot review for protected branches
  • Copilot review for pull requests

GitHub公式ドキュメントでも、ルールセットをActiveにし、対象ブランチを指定してからAutomatically request Copilot code reviewを選択する手順が案内されています。(GitHub Docs)

対象ブランチの指定に注意する

ルールセットは、プルリクエストの変更元ブランチではなく、マージ先となるベースブランチに対して適用されます。

たとえば、次のプルリクエストを考えます。

feature/login
    ↓
develop

ルールセットがデフォルトブランチのmainだけを対象にしている場合、このプルリクエストには適用されません。

Git Flowに近い運用をしている場合は、次のようなブランチも対象にする必要があります。

main
develop
release/*

「ルールは有効なのにレビューされない」という場合は、最初にプルリクエストのベースブランチとTarget branchesを照合してください。

Organization単位で自動レビューを再有効化する方法

複数のリポジトリで同じルールを適用したい場合は、Organizationレベルのルールセットが適しています。

リポジトリごとに設定すると、設定漏れやオプションのばらつきが発生しやすくなります。チーム共通のレビュー方針として運用するなら、Organizationルールセットで一元管理した方が確実です。

Organizationルールセットの設定手順

  1. GitHub右上のプロフィール画像からOrganizationsを開きます。
  2. 対象Organizationを選択します。
  3. OrganizationのSettingsを開きます。
  4. RepositoryからRulesetsを開きます。
  5. New rulesetを選択します。
  6. New branch rulesetを選択します。
  7. ルールセット名を入力します。
  8. Enforcement statusActiveにします。
  9. Target repositoriesで対象リポジトリを指定します。
  10. Target branchesで対象ブランチを指定します。
  11. Automatically request Copilot code reviewを有効にします。
  12. 必要に応じて追加オプションを有効にします。
  13. ルールセットを作成します。

Organizationルールセットでは、リポジトリ名のパターンによる対象指定と除外指定を組み合わせられます。除外条件は包含条件より後に適用されます。(GitHub Docs)

たとえば、すべてのリポジトリを対象にしつつ、検証用リポジトリを除外する構成が考えられます。

包含:*
除外:sandbox-*
除外:archive-*

最初から全リポジトリへ適用するのではなく、数個のリポジトリで動作と利用量を確認してから対象を広げる方法が安全です。

リポジトリ設定とOrganization設定の選び方

判断基準リポジトリルールセットOrganizationルールセット
対象1つのリポジトリ複数のリポジトリ
向いている用途試験導入、例外設定全社・全チームの標準化
設定変更リポジトリ管理者が行いやすいOrganization側で一元管理
設定漏れ発生しやすい抑えやすい
例外対応個別に柔軟に設定できる除外パターンなどの設計が必要

Organizationレベルのルールセットを管理できるのは、Organization ownerまたはルールセット管理権限を持つユーザーです。リポジトリレベルでは、管理者権限またはedit repository rules権限を含むカスタムロールが必要です。(GitHub Docs)

3つの設定はどこまで有効にすべきか

すべての設定を有効にすればよいとは限りません。レビュー頻度が増えるほど、AIクレジットの消費やレビュー通知も増えます。

GitHub Copilot code reviewは、レビューの実行ごとにAIクレジットを消費します。特にReview new pushesを有効にすると、コミットを追加するたびに再レビューが要求されます。(GitHub Docs)

新規プルリクエストを1回だけレビューする

次の設定にします。

Automatically request Copilot code review:オン
Review new pushes:オフ
Review draft pull requests:オフ

通常の開発チームでは、まずこの構成から始めるのが現実的です。

Open状態で作成されたプルリクエスト、またはDraftから初めてReady for reviewに変更されたプルリクエストがレビュー対象になります。追加コミットをプッシュしても自動再レビューは行われません。(GitHub Docs)

コード更新のたびに再レビューする

次の設定にします。

Automatically request Copilot code review:オン
Review new pushes:オン
Review draft pull requests:オフ

次のようなリポジトリに向いています。

  • セキュリティ上重要なコードを扱う
  • レビュー指摘後の修正内容も自動確認したい
  • 1つのプルリクエストに追加コミットが多い
  • 人による再レビューの補助として利用したい

ただし、細かなコミットを頻繁にプッシュする開発スタイルでは、レビュー回数と通知が増えやすくなります。

Draft段階からレビューする

次の設定にします。

Automatically request Copilot code review:オン
Review new pushes:必要に応じてオン
Review draft pull requests:オン

Draft段階からレビューすると、人にレビューを依頼する前に基本的な問題を修正できます。

一方、未完成のコードや一時的な実装にも指摘が付くため、試行錯誤の多い開発ではノイズが増えることがあります。Draftプルリクエストを「早期レビュー用」として運用しているチームに適しています。

自動レビューを再有効化してもレビューされない場合

ルールセットを設定した後もCopilotレビューが来ない場合は、次の項目を順番に確認してください。

ルールセットがActiveになっていない

GitHubの設定手順では、Copilotの自動レビュー用ルールセットをActiveにします。Disabledのままではルールが適用されません。(GitHub Docs)

確認箇所は次のとおりです。

Settings
→ Rulesets
→ 対象ルールセット
→ Enforcement status

対象ブランチが一致していない

Target branchesInclude default branchだけを設定している場合、デフォルトブランチ以外をベースとするプルリクエストには適用されません。

次の3点を照合してください。

  • プルリクエストのベースブランチ
  • リポジトリの現在のデフォルトブランチ
  • ルールセットのTarget branches

デフォルトブランチを変更したことがあるリポジトリでは、古いブランチ名を直接指定したルールが残っていないかも確認します。

最初のレビューだけ実行されている

Review new pushesが無効な場合、Copilotは原則としてプルリクエストを1回だけレビューします。

最初のレビュー後にコードを修正しても、自動的には再レビューされません。再レビューが必要な場合は、次のいずれかを行います。

  • Review new pushesを有効にする
  • プルリクエストのReviewers欄からCopilotへ手動で再レビューを依頼する

GitHubの公式ドキュメントでも、新しいプッシュごとのレビューを設定していない場合は、Reviewers欄から手動で再レビューを要求するよう案内されています。(GitHub Docs)

既存のプルリクエストで確認している

自動レビューの基本的なトリガーは、新しいOpen状態のプルリクエストを作成したとき、またはDraftを初めてReady for reviewに変更したときです。(GitHub Docs)

すでにOpen状態になっているプルリクエストへルールセットを後から適用しても、直ちにレビューが始まるとは限りません。

既存プルリクエストでは、Reviewers欄からCopilotを手動指定してください。Review new pushesを有効にした場合は、その後の新しいプッシュが再レビューのトリガーになります。

Organizationポリシーで利用が制限されている

ルールセットだけでなく、OrganizationやEnterprise側のCopilotポリシーも確認します。

特に管理環境では、次のような理由でレビューが実行されないことがあります。

  • Copilot code reviewがOrganizationで許可されていない
  • Enterpriseポリシーで利用対象が限定されている
  • 対象ユーザーや対象リポジトリがポリシーの範囲外
  • 利用予算やAIクレジットの上限に達している

Copilot BusinessまたはCopilot Enterpriseでは、ユーザーレベルやEnterprise、コストセンターの予算上限に達すると、AIクレジットを使用するコードレビューがブロックされることがあります。(GitHub Docs)

設定を編集する権限がない

ルールセットは、読み取り権限があれば内容を確認できます。しかし、作成、編集、削除には管理権限が必要です。

リポジトリレベルでは、次のいずれかが必要です。

  • リポジトリのAdmin権限
  • edit repository rules権限を含むカスタムロール

Organizationレベルでは、Organization ownerまたはOrganizationルールセットを管理できる権限が必要です。(GitHub Docs)

レビュー対象外のファイルだけを変更している

Copilot code reviewでは、一部のファイルがレビュー対象外です。公式ドキュメントでは、依存関係管理ファイル、ログファイル、SVGファイルなどが対象外として挙げられています。(GitHub Docs)

たとえば、ロックファイルやログファイルだけを変更したプルリクエストでは、期待するレビューコメントが付かない可能性があります。

コメントの有無だけで判断せず、Reviewers欄やプルリクエストのタイムラインで、Copilotへのレビュー要求そのものが行われたか確認してください。

Review effort levelを変更しても自動レビューは復旧しない

リポジトリの次の画面には、Copilotレビューの詳しさを設定する項目があります。

Settings
→ Copilot
→ Code review
→ Review effort level

LiteBalancedは、レビューの深さを選ぶ設定です。自動レビューを開始する設定ではありません。

  • Liteは、通常の変更を速くレビューする用途
  • Balancedは、複雑なロジックやセキュリティ上重要な変更を詳しく確認する用途

自動レビューが来ない問題を解決するには、Review effort levelではなく、ルールセットのAutomatically request Copilot code reviewを確認する必要があります。(GitHub Docs)

再有効化後の動作確認方法

設定を保存したら、既存のプルリクエストだけで判断せず、新しいテスト用プルリクエストを作成して確認します。

基本設定のテスト

  1. テスト用ブランチを作成します。
  2. 小さなコード変更をコミットします。
  3. ルールセットの対象ブランチへOpen状態でプルリクエストを作成します。
  4. Reviewers欄にCopilotが追加されたか確認します。
  5. タイムラインにレビュー要求が記録されたか確認します。

Review new pushesのテスト

  1. 最初のCopilotレビューを確認します。
  2. 同じプルリクエストへ新しいコミットをプッシュします。
  3. Copilotへの再レビュー要求が行われたか確認します。

再レビューされない場合は、Review new pushes、対象ブランチ、ルールセットの状態を再確認します。

Draftレビューのテスト

  1. Draft状態でプルリクエストを作成します。
  2. Ready for reviewへ変更する前に、Copilotレビューが要求されるか確認します。

Draft状態でレビューされず、Ready for reviewへの変更時にレビューされる場合は、基本設定は有効ですが、Review draft pull requestsが無効になっています。

運用ではCode QualityとCopilotレビューを別々に管理する

今回の変更を機に、Code QualityとCopilotレビューを同じ設定として扱わない運用へ切り替えることが重要です。

Code Qualityは、既知のアンチパターンや品質上の問題を一定のルールで検出する仕組みです。必要に応じてルールセットへ品質基準を設定し、基準を満たさないプルリクエストをブロックできます。(GitHub Docs)

Copilot code reviewは、AIを利用して変更内容をレビューする補助機能です。レビュー回数や対象タイミングは、チームの開発スタイルと利用量を考慮して決める必要があります。

実務上は、次のように分けて管理すると分かりやすくなります。

管理項目推奨する考え方
Code Quality原則として継続実行し、客観的な品質検査に使用する
Copilot自動レビューチーム方針に基づいて明示的に有効化する
新しいプッシュの再レビュー重要リポジトリまたは必要なチームだけ有効化する
Draftレビュー早期レビューを重視するチームで有効化する
Organizationルールセット共通基準を適用するリポジトリに使用する
リポジトリルールセット試験導入や例外的な設定に使用する

Code Qualityを無効化してから再度有効化しても、Copilot自動レビューは復元されません。2026年8月7日以降、Code Qualityの有効化とCopilot自動レビューの有効化は明確に分離されています。(The GitHub Blog)

Copilotレビューが止まったときに行うこと

GitHub Code Qualityの導入後にCopilotレビューが来なくなった場合は、次の順番で確認します。

  1. Code Quality Copilot review for default branchルールセットを開く
  2. Automatically request Copilot code reviewが無効になっていないか確認する
  3. Enforcement statusActiveか確認する
  4. プルリクエストのベースブランチが対象に含まれているか確認する
  5. 必要に応じてReview new pushesReview draft pull requestsを有効にする
  6. 新しいテスト用プルリクエストで動作を確認する
  7. 既存プルリクエストにはReviewers欄からCopilotを手動指定する
  8. 複数リポジトリで必要ならOrganizationルールセットへ移行する

今回の変更はCopilot code reviewの終了ではなく、自動的にレビュアーを追加する初期設定の撤回です。Copilotレビューをチームの標準プロセスとして利用する場合は、Code Quality任せにせず、適用対象とレビュータイミングを決めたうえでルールセットへ明示的に設定してください。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次