GitHub Copilotのコードレビュー｜使い方・自動レビュー設定・Max・日本語化と料金

GitHub Copilotのコードレビュー（Copilot code review）は、プルリクエストの差分をCopilotが読み、重要度付きの指摘と修正候補を返す機能です。2025年4月4日に一般提供（GA）となり、2026年9月から10月にかけて、既定のレビュー深度がBalancedに変わる、APIから深度を指定して依頼できるようになる、組織で課金先を選べるようになる、と仕様が続けて更新されました。10月28日には、最も深いレビュー深度「Max」がパブリックプレビューで選べるようになり、Copilotによる承認が一般提供に移っています。この記事では、2026年10月30日時点のGitHub公式ドキュメントとchangelogをもとに、依頼の方法、自動レビューの設定、Lite・Balanced・Maxの選び方、月のAI creditsで何回レビューできるか、日本語でレビューさせる指示、レビュー環境の準備、承認の設定までを順に説明します。

まとめ：GitHub Copilotコードレビューの要点（2026年10月時点）

• 使えるのはCopilot Student・Pro・Pro+・Max・Business・Enterprise。Copilot Freeで使えるのはVS Codeの「Review selection」（選択範囲のレビュー）だけで、プルリクエストのレビューは対象外です。
• 依頼はPR画面の「Reviewers」でCopilotの「Request」を押すか、gh pr edit PR番号 --add-reviewer "@copilot"、またはREST APIでcopilot-pull-request-reviewer[bot]をレビュアーに指定します。
• 自動レビューは個人のCopilot settings（2026年9月23日から全プラン）か、ブランチルールセットの「Automatically request Copilot code review」で有効にします。両方が有効でもレビューは1回です。
• 2026年9月28日から既定のレビュー深度はBalanced。1レビューの消費目安はLiteで0.05〜1米ドル（平均0.25米ドル）、Balancedで0.25〜5米ドル（平均1.50米ドル）相当のAI creditsです。Copilot Pro（月1,500クレジット）をレビューだけに使うと、Balancedでは月3〜60回、Liteでは15〜300回に相当します。
• 2026年10月28日から3段階目の「Max」がパブリックプレビューで選べます。異なるプロバイダーのモデルで複数のレビューを独立に走らせ、集約役のエージェントが1つにまとめる方式で、消費目安は1回1.5〜25米ドル（平均10米ドル）です。組織やリポジトリで「Maximum review effort」を設定すれば、Maxを選べないように制限できます。
• 日本語でレビューさせるには、.github/copilot-instructions.mdに「When performing a code review, respond in Japanese.」と書きます。指示はベースブランチではなく変更側のブランチから読まれます。
• Copilotはビルドやテストを実行して指摘を検証します。依存関係の準備は.github/workflows/copilot-code-review.ymlで行います。
• lockファイル・ログ・SVG・distやnode_modules配下はレビュー対象外です。指摘ゼロは「問題なし」を意味しません。
• Copilotによる承認は10月28日に一般提供となりました。ただし既定はオフで、有効にした場合だけCopilotの承認が必須承認の数に入ります。

GAから2026年10月までのコードレビューの仕様変更と運用への影響

提供開始の時期は記事によって書き方がばらつきます。GitHub.com上のCopilot code reviewは2024年10月29日に限定プレビュー（private preview）として発表され、当時は待機リストへの登録が必要でした。パブリックプレビューを経て、2025年4月4日に一般提供となっています。2024年に正式リリースされたという説明は、限定プレビューと一般提供を取り違えたものです。

GA後の変更のうち、使い方と費用に効くものを日付順に並べます。2026年9月以降はほぼ毎週更新されているため、古い解説記事の手順や料金は当てはまらないことがあります。

表を補足します。6月1日の移行で例外となったのは、年額契約のProとPro+で、こちらは引き続きpremium requestsで数えます。9月11日からはシェルツールでビルドやテストを実行して指摘を確かめるようになり、9月18日からは概要コメントが「Open」「Resolved since last review」「Previously missed」の3つに分かれました。9月23日に個人のcode review設定ページが全プランへ広がり、10月8日には課金先をメンバーと組織から選べるようになっています。同じ日に、組織外のライセンスによる依頼を止める設定も加わりました。

9月11日の変更は、指摘の質に直接関わります。changelogによれば、Copilotはファイルを読むだけでなく、ビルドコマンドやテストを実行して指摘を確かめるようになりました。同じ告知では、GitHubの実験において、Liteを複数エージェント構成にしたところレビュー費用が約8%下がったと報告されています。

10月28日の変更は、深度と承認の2つにまたがります。10月28日のchangelogは、Maxを認証ロジックや複数サービスで共有するライブラリのような、見落としの代償が大きい変更向けと位置づけ、承認と組み合わせて使う運用を勧めています。9月1日にプレビューで始まった承認は、この告知で一般提供になりました。9月時点の解説で「Maxは近日提供」「承認はプレビュー」と書かれていれば、どちらも現在の状態とは異なります。

使えるプランと、月のAI creditsで回せるレビュー回数

2026年10月時点のプラン比較表では、Copilot code reviewの行がCopilot Freeだけ「Only “Review selection” in VS Code」となっており、Student・Pro・Pro+・Maxは含まれています。BusinessとEnterpriseも対象です。組織に属するメンバーの場合は、組織のCopilotポリシーで「Copilot code review」が有効になっている必要があります。このポリシーを未設定のまま残していた組織では、2026年10月22日から26日にかけて段階適用された「Default policy for new features」により、エンタープライズが選んだ全体の既定方針（有効・無効・組織に任せる）で一度だけ設定されます。使えるはずなのにReviewersにCopilotが出ないときは、まずここを確認してください。

Copilotのライセンスを持たない組織メンバーにも使わせることができます。対象はBusinessとEnterpriseの組織で、「AI credits paid usage」と「Allow members without a Copilot license to use Copilot code review in GitHub.com」の2つのポリシーを有効にします。後者は既定で無効です。この場合の消費は組織やエンタープライズへの追加請求になり、IDE内のレビューは使えません。

費用はAI creditsで数えます。個人プランの説明では1 AI credit＝0.01米ドルで、月に使える量はPro 1,500、Pro+ 7,000、Max 20,000クレジットです。これを公式の消費目安で割ると、レビューだけに枠を使った場合の回数の幅が出ます。

この回数は、月の枠をレビューだけに使う場合に、公式の通常の消費目安から計算した参考値です。保証された上限・下限ではなく、チャットやエージェントにも枠を使えば、レビューに充てられる回数は減ります。注意したいのは下限側です。大きな差分をBalancedでレビューすると、Proの枠は3回で尽きる計算です。個人でProを使っていて、Copilotのエージェントも併用しているなら、日常の小さな変更はLiteに固定し、Balancedは依頼時に個別に選ぶ方が枠を守れます。BusinessとEnterpriseでは、席ごとのクレジットが組織の共有プールに入り、超過分の課金額は1クレジット0.01米ドルです。プラン全体の料金と使用量の集計方法はGitHub Copilotの料金（pricing）｜AI Credits後のプラン比較とEnterprise同梱・Billing APIでの集計【2026年10月】で扱っています。

Maxを表に入れていないのは、1回の幅が150〜2,500クレジットと広く、月の回数に直すと実態から離れるためです。公式の平均値どおり1回1,000クレジット（10米ドル）で計算すると、Proの枠では月に1回半、Pro+で7回、Maxプランで20回にとどまります。Maxを使えるのはPro・Pro+・Max・Business・Enterpriseで、changelogの対象プランにStudentは含まれていません。

コードレビューを依頼する4つの経路と画面・CLI・APIの操作方法

依頼はGitHub.com・GitHub CLI・API・GitHub Mobileのいずれからでも出せます。どれを使っても同じCopilotがレビュアーとして登録されます。

プルリクエスト画面でのレビュー依頼と深度の選択・修正候補の取り込み

プルリクエストを開き、右サイドバーの「Reviewers」でCopilotの横にある「Request」を押します。公式手順ではレビューは通常30秒以内に返り、各コメントに「High」「Medium」「Low」の重要度が付きます。依頼前に同じ欄で選択できる深度はLite・Balanced・Maxです。Maxは複数のレビューを集約するため、LiteやBalancedより返ってくるまで時間がかかります。Copilotが残すのは既定で「Comment」レビューで、承認の設定を有効にしない限り、必須承認の数には入りません。

修正候補は1件ずつ、または複数件をまとめて1コミットとして取り込めます。コメントの「Fix with Copilot」を押すと、Copilotのクラウドエージェントに修正を任せ、同じプルリクエストへのコミットか、ブランチに対する新しいプルリクエストとして受け取れます。再レビューの依頼先は、ReviewersメニューのCopilotの横にある再依頼ボタンです。クラウドエージェントやIDEのエージェントモードとの使い分けはGitHub Copilotエージェントモードの使い方｜Ask・Plan・Agentの違いと承認設定・料金で扱っています。

GitHub CLIでのレビュー依頼とターミナルからの再依頼の操作

GitHub CLI 2.96.0のヘルプには、Copilot専用の指定方法が明記されています。--add-reviewerは再依頼にも使えるため、pushした後の再レビューもCLIで出せます。

# 以下のヘルプ出力は関連部分のみ抜粋
$ gh pr edit --help | grep -E "add-reviewer|copilot"
- `@copilot`: request or remove review from Copilot (not supported on GitHub Enterprise Server)
      --add-reviewer login      Add or re-request reviewers by their login. Use "@copilot" to request review from Copilot.

# 新規PRを作るときに依頼する
$ gh pr create --reviewer @copilot

# 既存PRに依頼する（再依頼も同じコマンド）
$ gh pr edit 23 --add-reviewer "@copilot"

ヘルプのとおり、@copilotの指定はGitHub Enterprise Serverでは使えません。GHESとCopilotの関係はGitHub Copilotはオンプレミスで使える？GHES非対応の代替構成とデータの扱い・料金【2026年版】で整理しています。

REST・GraphQL APIでのレビュー依頼と深度指定パラメータの現状

自動化に組み込む場合は、通常のレビュアー指定と同じエンドポイントでcopilot-pull-request-reviewer[bot]を指定します。トークンには「Pull requests」のwrite権限が必要です。

$ curl -L -X POST \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  https://api.github.com/repos/OWNER/REPO/pulls/23/requested_reviewers \
  -d '{"reviewers":["copilot-pull-request-reviewer[bot]"]}'

2026年10月2日のchangelogは、REST APIとGraphQL APIからの依頼で深度を指定できるようになったと告知しています。ただし10月26日時点で、GitHubが公開しているREST APIのOpenAPI定義（github/rest-api-description）では、このエンドポイントの本文にreviewersとteam_reviewersしか載っておらず、深度を渡すパラメータ名は確認できません。パラメータを推測して組み込むより、リポジトリや個人の既定値で深度を決めておく方が確実です。

GitHub Actionsから別のAIにレビューさせる構成と比べる場合は、anthropics/claude-code-action@v1の設定リファレンス｜入力一覧・claude_args・betaからの移行が参考になります。Copilot code reviewはレビュアー指定だけで動き、ワークフローを自分で書く必要がない点が違います。

GitHub Mobileでのレビュー依頼とモバイル画面での操作手順

GitHub Mobileでは、プルリクエストの「Reviews」を開いて「Request Reviews」を押し、Copilotを追加して「Done」を押します。

IDEでのpush前レビューの使い方と対応環境・消費クレジットの確認

プルリクエストを作る前に、手元の変更をレビューさせることもできます。対応環境はVS Code・Visual Studio・Xcode・JetBrains系IDEで、Azure DevOpsもパブリックプレビューで対応しています。IDE内のレビューもAI creditsの消費対象です。公式の機能対応表では、EclipseとNeoVimはCopilot code reviewに非対応です。

• VS Code：コードを選択して右クリックし「Generate Code」→「Review」で選択範囲をレビューします（Copilot Freeで使えるのはこの操作だけです）。未コミットの変更全体は、Source Controlビューの「CHANGES」にカーソルを合わせて「Copilot Code Review – Uncommitted Changes」を押します。
• Visual Studio：17.14以降で、Git Changesウィンドウの「Review changes with Copilot」から実行します。
• JetBrains系IDE：Commitツールウィンドウの「Copilot: Review Code Changes」を押します。
• Xcode：GitHub Copilot Chat拡張0.41.0以降で、チャット画面のCode Reviewボタンから「Review Staged Changes」か「Review Unstaged Changes」を選びます。

VS CodeでのCopilotの導入手順はVS CodeでGitHub Copilotを使うには？導入手順・使い方・料金を解説【2026年10月版】で扱っています。

PRの自動レビューを有効にする個人設定とルールセットの適用範囲

自動レビューの設定元は、個人の設定とルールセットの2系統です。公式の設定手順によれば、両者は上下関係を持たず別々に評価され、どちらか一方でも有効ならレビューが走ります。両方が有効でもレビューは1回です。

個人設定による自分のPRの自動レビューと新しいpush時の再実行条件

プロフィール画像から「Copilot settings」を開き、サイドバーの「Code review」で「Automatic Copilot code review」を有効にします。このページは2026年9月23日からBusinessとEnterpriseのライセンスでも使えるようになり、同じ画面で「Review new pushes」「Review draft pull requests」と既定の深度も選べます。自分が作成したPRに加えて、共同作成者になったPRやDraftから外したPRも対象です。マネージドユーザーアカウントでは使えません。

ルールセットによる対象ブランチのPR自動レビューと適用範囲の設定

リポジトリの「Settings」→「Rulesets」→「New ruleset」→「New branch ruleset」を開き、「Enforcement Status」をActive、「Target branches」で対象ブランチを指定して、「Branch rules」の「Automatically request Copilot code review」を選びます。追加の2項目で、レビューが走るタイミングが変わります。

基本設定だけのときは、PRをOpenの状態で作成した時点と、DraftからOpenへ初めて切り替えた時点の2回が契機です。表の「Draftのレビュー」は、画面上では「Review draft pull requests」という名前で表示されます。

ルールセットがpushごとのレビューを有効にしている場合、個人の設定でそれを止めることはできません。APIでルールセットを管理する場合、ルール種別はcopilot_code_reviewで、上の2項目はreview_on_pushとreview_draft_pull_requestsに対応します。次はREST APIでブランチルールセットを作るときの本文の例です。

{
  "name": "copilot-review",
  "target": "branch",
  "enforcement": "active",
  "conditions": {
    "ref_name": { "include": ["~DEFAULT_BRANCH"], "exclude": [] }
  },
  "rules": [
    {
      "type": "copilot_code_review",
      "parameters": {
        "review_on_push": true,
        "review_draft_pull_requests": false
      }
    }
  ]
}

組織では組織の「Settings」→「Repository」→「Rulesets」で、対象リポジトリをfnmatch形式のパターン（例：*feature）で指定します。エンタープライズではエンタープライズ単位のブランチルールセットで同じルールを有効にします。「Review new pushes」は費用への影響が最も大きい設定です。pushのたびに1レビュー分のAI creditsを使うため、コミットを細かく積む運用では、まず基本設定だけで始めてください。自動レビューの既定深度をMaxにしたままpushごとのレビューを有効にすると、平均10米ドル相当がpushのたびに積み上がります。

Lite・Balanced・Maxの選び方と、深度が決まる順番

深度は3段階です。公式ドキュメントの説明と消費目安は次のとおりです。Maxは2026年10月28日からパブリックプレビューで選べるようになり、ドキュメントにも「currently in public preview and subject to change」と明記されています。

消費量について、ドキュメントは「Consumption generally increases with pull request size and repository custom instructions」と書いています。差分が大きいほど、カスタム指示を厚く書くほど高くなります。この目安にGitHub Actionsの実行時間は含まれません。BalancedはLiteより、Actionsの分数もわずかに多く使うと説明されています。

Maxによる複数モデルのレビュー集約と費用に応じた対象変更の絞り方

10月28日のchangelogによれば、Maxは複数のレビューエージェントを独立に走らせ、それぞれに異なるプロバイダーのモデルを使います。そのうえで集約役のエージェントが結果を突き合わせ、食い違いを解消し、指摘の正確さを確かめてから1つのレビューにまとめます。1つのモデルの癖で見落とす箇所を、別系統のモデルで拾う設計です。そのぶん処理が多く、返ってくるまでの時間も消費するAI creditsも、LiteやBalancedより大きくなります。

平均値で比べると、Max 1回はBalancedの約7回分、Liteの40回分に当たります。すべてのプルリクエストをMaxにするのではなく、次のように変更の種類で分けると費用の見通しが立ちます。

• Maxを選ぶ：認証・認可、決済や課金の計算、個人情報を扱う処理、複数サービスから呼ばれる共有ライブラリ、データベースのマイグレーション。見落としがそのまま事故になる変更です。
• Balancedのまま：通常の機能追加や、複数ファイルにまたがるリファクタリング。
• Liteに下げる：文言修正、設定値の変更、テストの追加だけの変更、依存更新。

運用では、既定はBalancedかLiteに置き、Maxは依頼時にReviewers欄で個別に選ぶ形が扱いやすいでしょう。changelogは、見落としの代償が大きいリポジトリではMaxと承認を組み合わせる使い方を挙げています。ただしプレビュー期間中は仕様と消費量が変わりうるため、本番の必須レビューをMaxに依存させるのは一般提供を待ってからにしてください。

Maximum review effortによる深度の上限設定と適用範囲

メンバーが個別にMaxを選べると、組織の枠が想定外の速さで減ります。これを防ぐため、設定手順のページには、リポジトリ・組織・エンタープライズの各設定に「Maximum review effort」が用意されています。選択肢は「No limit」「Lite」「Balanced」「Max」の4つです。

エンタープライズと組織の設定画面では、既定の深度は「Default review effort level」という項目名で表示されます。上限の「Maximum review effort」は、どの単位でもその隣に並んでいます。

下位の単位は、上限と同じかそれより低い深度だけを選べます。たとえば組織の上限をBalancedにすれば、どのリポジトリでもMaxは選べません。既定値は下位の単位で上書きできますが、上限は上書きできない、という関係です。Maxをまず一部のリポジトリで試すなら、組織の上限はBalancedに置き、試すリポジトリだけを別の組織に分けるか、組織の上限をNo limitにしたうえで他のリポジトリ側の上限をBalancedにします。

レビュー深度が決まる設定の優先順位と個人設定・リポジトリ既定の関係

自動レビューで「いつの間にかBalancedで回っていた」という事態を避けるには、深度がどの設定から決まるかを知っておく必要があります。Copilotは次の順に見て、最初に当てはまったものを使います。いずれの段でも、上で説明した上限を超える深度は選ばれません。

1. 依頼時にReviewers欄で選んだ深度
2. そのプルリクエストで前回使った深度
3. 依頼者の個人設定の深度（新規PRでは作成者、Draftを外したときは外した人）
4. リポジトリに設定した深度
5. 組織に設定した深度（個人所有のリポジトリではその所有者の設定）
6. GitHubの既定値であるBalanced

3番目が4番目より先に適用されるため、個人設定がリポジトリの既定より優先される順序です。リポジトリの既定をLiteにしても、作成者が個人設定でBalancedやMaxを選んでいれば、その人のPRはその深度でレビューされます。費用を抑えたいチームは、既定値を揃えるだけでなく、上限の設定で個人の選択に枠をはめてください。どの深度が使われたかは、プルリクエストの概要コメントにレビューごとに表示されます。

コードレビューの課金先の選択とActions分数・消費クレジットの管理

費用はAI credits（レビュー本体）とGitHub Actionsの分数（文脈収集やツール実行）の2本立てです。AI creditsが誰に付くかは、依頼の経路で決まります。

• 自動レビュー：プルリクエストの作成者に付きます。他の人が手動で依頼した場合は依頼した人です。
• Copilotのクラウドエージェントが作ったPR：まず人間の共同作成者に付き、その人に請求できなければ組織に直接請求されます。
• その他のbotが作ったPR、またはbotの依頼：組織に直接請求されます。

2026年10月8日から、組織オーナーは「Choose how members with a Copilot license are billed」で課金先を選べます。既定の「Member」はメンバー自身の枠を使い、枠が尽きるとレビューは失敗します。「Organization」を選ぶと組織に請求され、メンバーの枠を減らしません。後者にはAI credits paid usageの有効化が必要です。同時に「Only allow Copilot code review to be triggered by authorized users」も追加され、有効にすると、個人契約など組織外のCopilotライセンスではレビューを依頼できなくなります。ルールセットによる自動レビューはこの設定の影響を受けません。課金先を「Organization」にしてMaxを開放すると、メンバーの枠では止まらず組織の請求が増えるため、上限設定とセットで決めてください。

Actionsの分数はリポジトリに付きます。使用量は、Actionsのメトリクスでcopilot-pull-request-reviewerワークフローに絞るか、請求レポートでworkflow_pathがdynamic/agents/copilot-pull-request-reviewerの行を見ると確認できます。セルフホストランナーならActionsの分数は消費しません。

課金方式には例外が1つあります。2026年6月1日以降も年額のリクエスト課金に残っているCopilot Pro・Pro+では、消費を数える単位はAI creditsではなくpremium requestsです。レガシー課金のページには「Starting June 1, 2026, Copilot code review will have a model multiplier of 13.」とあり、PR上でもIDE内でも1レビューで13リクエストを消費します。

カスタム指示によるレビュー観点と言語の指定方法・指示ファイルの適用範囲

Copilotのレビューは、リポジトリに置いたMarkdownファイルで制御できます。置き場所は目的によって分かれます。

• .github/copilot-instructions.md：リポジトリ全体に常に適用するCopilot向けの規約。
• .github/instructions/**/*.instructions.md：パス単位の指示。フロントマターのapplyToにグロブを書き、変更ファイルが一致したときだけ適用されます。
• リポジトリ直下のAGENTS.md：Copilot以外のAIエージェントとも共有したい前提。
• CLAUDE.md・GEMINI.md・REVIEW.md：存在すれば、Copilot code reviewはこれらもカスタム指示として読みます。

日本語化もこの仕組みで行います。公式ドキュメントの例は「When performing a code review, respond in Spanish.」という1行で、言語名を差し替えれば日本語になります。次の例のチェックリストのパスは、リポジトリに実在するファイルに書き換えてください。

# .github/copilot-instructions.md

When performing a code review, respond in Japanese.
When performing a code review, focus on readability and avoid nested ternary operators.
When performing a code review, apply the checks in the `/docs/review-checklist.md` file.

パス単位で観点を変える場合は、次の内容を.github/instructions/typescript.instructions.mdとして保存します。グロブはカンマ区切りでの複数指定が可能です。逆に、クラウドエージェント向けに書いた指示をレビューには使わせたくない場合は、フロントマターにexcludeAgent: "code-review"を加えます。

---
applyTo: "**/*.ts,**/*.tsx"
---

TypeScriptの変更では、any型の追加と、Promiseのawait漏れを重点的に指摘してください。

指示はベースブランチではなく変更側（head）のブランチから読まれます。指示ファイルを書き換えるプルリクエストで、そのままマージ前に効果を試すことが可能です。書き方の詳細はcopilot-instructions.mdとは？書き方とサンプル・配置場所、AGENTS.mdとの違い【2026年10月】で扱っています。指示が長くなるほど1回の消費も増えるため、Maxで使うリポジトリでは、観点を絞った短い指示にしておくと費用を抑えられます。

レビュー専用の手順を持たせたい場合は、.github/skills配下にエージェントスキルを置きます。公式ドキュメントは、ディレクトリ名をcode-reviewのようにレビュー向けにすると使われやすいと説明しています。MCPサーバーもレビューに使われ、GitHub MCPサーバーとPlaywright MCPサーバーは既定で有効です。2026年7月29日付の一般提供の告知によれば、レビュー中のMCPツール呼び出しは読み取り専用に制限されます。MCPをクラウドエージェント専用にしたい場合は、リポジトリ設定の「Allow Copilot to use MCP tools when reviewing pull requests」を無効にします。スキルの書き方はAgent Skillsとは？SKILL.md仕様とAAIF寄贈後も移植性を保つ実装手順を参照してください。

レビュー環境の準備とcopilot-code-review.ymlの設定

Copilot code reviewはGitHub Actions上の一時的な開発環境で動き、9月11日以降はそこでビルドやテストを実行して指摘を確かめます。依存パッケージが入っていなければ、この検証は空振りするか、試行錯誤に時間がかかる状態です。非公開パッケージに依存するリポジトリでは、Copilotが自力で取得できない場合もあります。

環境は2つのファイルのどちらかで用意します。クラウドエージェント用に.github/workflows/copilot-setup-steps.ymlがあれば、レビューでもそのファイルが環境設定の参照先です。レビュー専用に分けたいときは.github/workflows/copilot-code-review.ymlを作り、こちらがあれば優先されます。注意点は、ランナー設定の公式例で、copilot-code-review.ymlの中でもジョブ名がcopilot-setup-stepsのままになっていることです。クラウドエージェントの説明では、このジョブ名でないとCopilotに読み込まれないとされています。

# .github/workflows/copilot-code-review.yml
# Node.js 24・npmを使用するプロジェクトの例
# リポジトリ直下にpackage.jsonと、それに整合するpackage-lock.jsonが必要
name: "Copilot code review setup"

on:
  workflow_dispatch:

jobs:
  copilot-setup-steps:
    runs-on: ubuntu-latest
    timeout-minutes: 30
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: "24"
          cache: "npm"
      - run: npm ci

ジョブで変更が反映されるのはsteps・permissions・runs-on・services・snapshot・timeout-minutes（最大59）だけで、それ以外は無視されます。セルフホストで動かす場合、レビューに公式対応しているのはActions Runner Controller（ARC）で管理するUbuntu x64のランナーだけです。組織でGitHubホステッドランナーを無効にしていると、文脈収集やツール実行が使えない限定的なレビューに縮退します。レビューの通信先は「Internet access」タブのファイアウォール設定で、クラウドエージェントとは別に絞れます。

レビュー対象から外れるファイルの指定パターンと依存更新PRでの注意点

「依頼したのに指摘が何も付かない」原因の一部は、ファイルが除外対象だったことです。公式の一覧には、ファイル名指定としてpackage-lock.json・Gemfile.lock・go.sum・requirements.txt・tsconfig.json・build.gradleなど、パターン指定として**/*.lock・**/*.svg・**/*.log・**/*.min.js・**/*.d.ts・**/*.map・**/dist/**/*・**/node_modules/**/*・**/coverage/**/*・**/vendor/**/*・**/generated/**/*・**/bin/**/*が並びます。

例外もあります。**/bin/**/*に当たるファイルのうち、Rustのソース（**/bin/**/*.rs）と、SAP Commerce Cloud（Hybris）の**/hybris/bin/custom/**配下はレビューされます。依存更新のプルリクエストで、変更ファイルがすべて公式の除外対象に当たる場合は、レビューコメントが生成されません。指摘ゼロを「レビュー済みで問題なし」と読まず、依存関係の脆弱性検査やテストで確認してください。

Copilotの承認をマージ要件に数える設定と人のレビューの役割分担

GitHub自身が検出の網羅性を保証していません。ドキュメントは「Copilot is not guaranteed to spot all problems or issues in a pull request. Sometimes it will make mistakes.」と書き、人のレビューで補うよう求めています。

承認まで任せる設定は、2026年9月1日にパブリックプレビューで始まり、10月28日に一般提供となりました。既定はオフです。各レビューの概要コメントには、マージしてよいかの判定（approval assessment）が毎回載りますが、それだけではマージ要件に数えられません。リポジトリ設定の「Auto-approval」にある「Allow Copilot to approve pull requests」（承認の投稿）と「Allow Copilot approvals to count toward merge requirements」（必須承認への算入）は別のトグルで、後者を入れなければマージ要件は変わりません。算入対象はファイルパスのグロブで最大15個まで絞れ、変更ファイルがすべていずれかのグロブに一致するプルリクエストだけが対象になります。承認後に新しいコミットがpushされると承認は取り消され、もう一度レビューを依頼すれば新しい判定が出ます。

上位の設定は次のとおりで、リポジトリで有効にするには上位がそれを許している必要があります。

画面上の項目名は、エンタープライズが「Allow Copilot to approve pull requests」、組織が「Count Copilot approvals toward merge requirements」です。組織の選択肢は英語表記で「Enabled everywhere」「Let repositories decide」「Enable for selected repositories」「Disabled everywhere」の4つが並びます。

エンタープライズの既定は「Disabled everywhere」です。始めるときは、docs/**や*.mdのように影響範囲の小さいパスにグロブを絞り、コードの変更には人の承認を残してください。認証や決済のように見落としの代償が大きいリポジトリでCopilotの承認を数えるなら、深度もMaxにしたうえで、人の承認も必須に残す二重の構成にするのが安全です。GAになったとはいえ、承認を数えるかどうかの判断はGitHubではなく各組織の責任です。

Copilotの指摘への返信の扱いは、資料によって書き方が違います。使い方のドキュメントは、返信はCopilotには見えず、Copilotは返事をしないという説明です。一方で9月18日のchangelogは、「未解決のまま残して」という返信を自動解決の判断で尊重すると告知しています。会話の相手にはならないが、解決扱いにするかどうかには返信が効く、と読むのが実態に近いでしょう。

導入効果を測るときは、9月25日に使用状況メトリクスAPIへ追加されたpull_request_review_timesが、人のレビューだけを計時し、Copilot code reviewのレビューは数えない点に注意してください。人のレビュー待ちが縮んだかを見るには使えますが、Copilotのレビュー件数はこの指標に入りません。レビューの観点や進め方全般はコードレビューとは？目的・観点・進め方と実装現場の運用設計を解説で扱っています。社内でAIによる開発支援の導入範囲や運用ルールを決める段階であれば、生成AI導入支援もご相談いただけます。

よくある質問

GitHub Copilotのコードレビューは無料で使えますか？

Copilot Freeでは、プルリクエストのレビューは使えません。Copilot Freeで使えるのは、VS Codeで選択範囲をレビューする「Review selection」だけです。一方、無料で提供されるCopilot Studentにはコードレビューが含まれています。組織ではBusinessかEnterpriseであれば、ライセンスを持たないメンバーにもGitHub.com上でのレビューを開放できますが、消費分は組織への追加請求になります。

GitHub Copilotのコードレビューの料金はいくらですか？

専用の料金はなく、プランのAI creditsから引かれます。1レビューの目安はLiteで0.05〜1米ドル（平均0.25米ドル）、Balancedで0.25〜5米ドル（平均1.50米ドル）、プレビュー中のMaxで1.5〜25米ドル（平均10米ドル）相当で、これとは別にGitHub Actionsの分数も消費対象です。Copilot Pro（月10米ドル・1,500クレジット）をレビューだけに使うと、Balancedで月3〜60回、Liteで15〜300回に相当します。

レビューコメントを日本語にできますか？

日本語への変更は可能です。.github/copilot-instructions.mdに「When performing a code review, respond in Japanese.」と1行書けば、そのリポジトリのレビューに適用されます。組織オーナーであれば、組織のカスタム指示として指定することもできます。

コミットをpushするたびに自動でレビューしてもらえますか？

既定では再レビューされません。個人の設定かルールセットで「Review new pushes」を有効にした場合だけ、pushごとに走ります。未設定ならCopilotは1つのプルリクエストを1回しかレビューしないため、Reviewersメニューかgh pr edit 番号 --add-reviewer "@copilot"で再依頼してください。

Copilotの承認だけでマージできますか？

既定ではできません。承認は2026年10月28日に一般提供となりましたが、既定はオフです。上位のポリシーで許可されたうえで、リポジトリの「承認の投稿」と「必須承認への算入」を両方有効にし、パス条件があれば全変更ファイルがそれを満たすときに限り、Copilotの承認が必須承認として数えられます。必須承認を1人に設定しているリポジトリでこれを有効にすると、条件に合うプルリクエストはCopilotの承認だけでマージできる状態になるため、対象パスは慎重に選んでください。

関連記事

• GitHub Copilotの料金（pricing）｜AI Credits後のプラン比較とEnterprise同梱・Billing APIでの集計【2026年10月】
• copilot-instructions.mdとは？書き方とサンプル・配置場所、AGENTS.mdとの違い【2026年10月】
• コードレビューとは？目的・観点・進め方と実装現場の運用設計を解説
• GitHub Copilotエージェントモードの使い方｜Ask・Plan・Agentの違いと承認設定・料金
• anthropics/claude-code-action@v1の設定リファレンス｜入力一覧・claude_args・betaからの移行