こんにちは。AIあれこれ散歩道、運営者のもっちゃんです。
GitHub Copilotのコードレビューに、対応済みコメントを自動で解決する更新が入りました。「修正後のコメント確認が少し楽になりそう」と感じる一方で、自動解決されたらそのままマージしてよいのか、料金はどこで増えるのか、気になりますよね。
先に結論を言うと、今回の更新は対応が残るコメントへ目を向けやすくする改善です。ただし、コメントの自動解決はプルリクエストの自動承認でも、安全性の保証でもありません。差分、テスト、未解決コメント、人の承認を残して使うのが大切です。
- コメントが自動解決される条件
- 手動レビューと自動レビューの使い方
- AI CreditsとActions分の考え方
- マージ前に人が確認するポイント
この記事の要点
2026年9月11日の更新で、再レビュー時のコメント自動解決、提案適用時のコミット文生成、シェルツールを使った分析、Liteでの複数エージェント確認が加わりました。便利さは増えましたが、最終判断を人から外す更新ではありません。
GitHub Copilotコードレビューの新機能
まず、2026年9月11日に発表された四つの変化を見ていきます。画面上で分かりやすいのはコメント自動解決とコミット文ですが、レビューの裏側でも検証方法とLiteの動きが変わりました。
なお、ここで扱う内容はGitHub Changelogの2026年9月11日更新と現行のGitHub Docsを基にしています。私は今回の機能を実際のリポジトリでは試していないため、体感速度や検出結果を実体験のようには書きません。
更新された四つのポイント
変更点は、レビューを受けた後の扱いやすさを変える二つと、Copilotがコードを調べる過程を変える二つに分けると理解しやすいです。前者は対応済みコメントの自動解決と変更内容に沿ったコミットメッセージ案。後者はシェルツールによる検証とLiteでの複数エージェント利用です。
| 更新 | 変わる場面 | 人が見る点 |
|---|---|---|
| コメント自動解決 | 修正後の再レビュー | 本当に指摘が解消したか |
| コミット文生成 | Copilotの提案適用 | 変更内容と文面が一致するか |
| シェルツール | レビュー中の検証 | テスト結果と対象範囲 |
| 複数エージェント | Liteの分析 | 重複や誤検知がないか |
四つは別々の機能ですが、流れとしてはつながっています。Copilotが変更を調べてコメントし、開発者が修正を反映し、再レビューで対応済みかを判断する。その往復を短くしつつ、開いたままの指摘を目立たせる更新だと捉えるとよいでしょう。
コメントが自動解決される条件
自動解決が行われるのは、Copilotが残したコードレビューコメントに対して、後からプッシュしたコミットが指摘の根本に対応したと再レビューで判断されたときです。コメントが付いた瞬間に閉じるわけでも、修正ファイルを保存しただけで閉じるわけでもありません。
ポイントは「再レビュー時」という部分です。リポジトリの自動レビュー設定で新しいプッシュも確認するようにしていれば、コミットを追加するたびに再レビューへ進めます。一方、その設定を使っていなければ、修正後にCopilotへもう一度レビューを依頼する必要があります。
たとえば、入力値の検証不足を指摘された後に、検証処理とテストを追加してプッシュしたとします。再レビューでその変更が元の指摘に対応すると判断されれば、Copilot自身のコメントが解決済みになります。ここで得られるのは「コメント一覧を片付ける手間の軽減」であって、変更全体の合格通知ではありません。
自動解決までの流れ
レビュー依頼 → Copilotがコメント → 修正コミットをプッシュ → 再レビュー → 対応済みコメントを自動解決、という順番です。新しいプッシュを自動で見るかどうかは設定に左右されます。
未対応コメントは残る
GitHubは、対応がまだ残るフィードバックは開いたままになると説明しています。つまり、すべてのスレッドを一律で閉じる機能ではありません。修正できた指摘と、引き続き注意が必要な指摘を画面上で分け、開いているコメントへ集中しやすくします。
ただし、開いているコメントだけを見て終わりにするのは早計です。AIには見落としや誤検知があり、解決済みの判断も人間の意図とずれる可能性があります。特に認証、権限、決済、個人情報、データ削除のような影響の大きい変更では、解決済みスレッドも含めて差分をたどるほうが安心です。
レビューの役割を、信号機よりも「確認箇所を示す付箋」と考えると分かりやすいかもしれません。付箋が外れたからコード全体が安全になったのではなく、その指摘に関する確認が一段進んだという意味です。自動解決されたコメントほど、対応コミットとテスト結果を対で見るようにしましょう。
提案適用でコミット文を生成
Copilotのレビューコメントに含まれるコード提案を適用すると、以前の定型的なコミットメッセージではなく、変更内容に沿った案が生成されるようになりました。あとから履歴を読んだ人が、何を直したコミットなのか把握しやすくなる方向の改善です。
とはいえ、コミット文は変更そのものではありません。生成された文面が、実際の差分、変更理由、影響範囲と合っているかは確認が必要です。複数の提案をまとめて適用した場合や、提案の前後に手作業の変更を加えた場合は、文面が一部だけを表していないかも見ます。
チームにコミット規約があるなら、接頭辞、課題番号、破壊的変更の表記なども合わせましょう。便利なのは「ゼロから文面を考える負担が減る」点です。生成案を確定文として受け取らず、履歴を読む人への説明文として仕上げる。この一手間で、後日の調査や差し戻しがしやすくなります。
シェルツールで検証が広がる
レビューの裏側では、Copilot SDKのシェルツール群を使えるようになりました。GitHubの説明では、ビルドコマンドの実行、テスト、対象を絞ったスクリプト、利用可能なツールやAPIからの情報取得などを、Copilot agent firewallの内側で行います。
ファイルを読むだけでは分かりにくい不具合も、実際にテストやビルドを走らせることで見つけられる可能性があります。ただし、テストを実行できることと、必要なテストがすべて揃っていることは別です。テストの対象外にある挙動、外部サービスとの組み合わせ、本番固有の権限やデータまでは、自動で保証されません。
また、エージェント機能にはGitHub Actionsランナーが関わります。Actionsが利用できない、または関連ワークフローが失敗した場合でもレビューは生成されますが、完全なプロジェクト文脈の収集など、エージェント機能による追加の確認は含まれないと案内されています。レビューが届いたかだけでなく、関連ワークフローの結果も見る必要があります。
レビューが出たことと、十分に検証できたことは同じではありません
Actionsの状態、テスト対象、失敗やスキップ、外部依存を確認してください。レビューコメントだけを見て、実行環境の問題を見落とさないようにします。
Liteは複数エージェントで確認
既定のLiteでは、一つのエージェントだけで調べるのではなく、複数エージェントがそれぞれの観点を出し、Copilotが一つのレビューへまとめる方式になりました。日常的な変更向けの軽い設定を保ちつつ、見る角度を増やす狙いです。
GitHubの実験では、レビューあたりの対応済みコメント平均が重大度Highで47％、Mediumで31％、Lowで11％増え、費用は約8％減ったとされています。ここは魅力的な数字ですが、GitHubの実験結果であり、あなたのリポジトリでも同じ比率になるという約束ではありません。言語、変更規模、テスト、カスタム指示によって結果は変わります。
複数の観点が入ると、同じ問題に近いコメントが出たり、重要度の感じ方が人とずれたりすることも考えられます。導入初期は「指摘数が増えたか」だけで評価せず、役に立った指摘、誤検知、対応時間、見落としを小さく記録すると、チームに合う使い方が見えてきます。
GitHub Copilotコードレビューの使い方
ここからは、利用できるプランと環境、手動依頼、自動設定、料金、安全確認を順番に見ていきます。最初からすべてのプルリクエストへ自動適用せず、影響の小さいリポジトリで手動レビューから始めると、結果と費用を確かめやすいですよ。
利用できるプランと環境
GitHub Docsのコードレビュー概要では、Copilot code reviewはすべての有料Copilotプランで利用できると案内されています。個人向けのCopilot Freeには含まれません。個人の自動レビュー設定はCopilot Pro、Pro+、Maxが対象です。
対応先はGitHub.com、GitHub CLI、GitHub Mobile、VS Code、Visual Studio、Xcode、JetBrains IDE、Azure DevOpsです。ただし、Azure DevOpsはパブリックプレビューなので、一般提供済みの機能と同じ安定性や固定仕様を前提にしないほうがよいでしょう。
| 確認項目 | 内容 |
|---|---|
| 個人利用 | 有料プランで手動レビュー、Pro・Pro+・Maxで個人の自動レビュー設定 |
| 組織利用 | 管理者のCopilot code reviewポリシーを確認 |
| ライセンスなし | Business・Enterprise組織が許可すればGitHub.comで利用できる場合がある |
| 対応環境 | GitHub.com、CLI、Mobile、各IDE、Azure DevOpsプレビュー |
組織からCopilotを付与されている場合、GitHub.comやGitHub Mobileでのレビューには組織側のポリシー許可が必要です。また、ライセンスのない組織メンバー向けに有効化する仕組みもありますが、その場合のAI Creditsは組織へ追加利用として計上され、IDEでは使えません。利用ボタンが見えないときは、プランだけでなく管理ポリシーも確かめます。
手動レビューを依頼する手順
GitHub.comでの基本手順はシンプルです。対象のプルリクエストを開き、右側のReviewers欄でCopilotの横にあるRequestを選びます。レビューが終わったら、概要とファイルごとのコメントを読み、提案をそのまま適用するか、自分で修正するか、対応しない理由を残すかを判断します。
既定では、CopilotはApproveやRequest changesではなく、コメントとしてレビューを返します。つまり、Copilotのコメントがなくなっても、通常は必須承認数を満たしたことにはなりません。Copilotによる承認を使える設定もありますが、これはパブリックプレビューで、管理側の明示的な設定が関係します。
修正をプッシュしたら、再レビューへ進みます。新しいプッシュの自動レビューが有効なら次のレビューが動き、無効ならReviewers欄から再度依頼します。今回の自動解決が働くのはこの再レビュー時です。手順の現行表示はGitHub Copilotを使ったコードレビューで確認できます。
◆もっちゃんのワンポイントアドバイス
最初の数回は、Copilotのコメント、対応したコミット、再レビュー後の表示を一組で見てください。自動解決だけを目的にせず、どの変更を理由に閉じたのか追える状態を保つと、判断しやすくなります。
自動レビューを設定する方法
自動レビューは、個人設定とリポジトリ・組織のルール設定で入口が異なります。個人利用ではプロフィール画像からCopilot settingsを開き、Automatic Copilot code reviewを有効にします。リポジトリや組織では、対象ブランチやリポジトリを定めるルールセットから、自動でCopilotレビューを要求する項目を設定します。
リポジトリのルールでは、Openのプルリクエスト作成時だけでなく、新しいプッシュをレビューするか、Draftの段階でも見るかを選べます。新しいプッシュを確認しない設定では、自動レビューは原則1回です。修正後のコメント自動解決まで継続して使いたいなら、再レビューを自動にするか、手動で必ず依頼する運用を決めます。
すべてへ一気に有効化すると、利用量と通知が想定より増えるかもしれません。まず対象リポジトリとブランチを絞り、Liteで始め、週に一度だけ利用量と役立った指摘を確認するやり方が現実的です。設定場所と現在の選択肢はCopilotコードレビューの構成手順で追えます。
レビュー方針を伝えるときは、リポジトリ全体なら.github/copilot-instructions.md、追加の文脈ならルートのAGENTS.md、パス別なら.github/instructions/**/*.instructions.mdなどが使われます。ルールは長くするより、守るべきテスト、禁止する変更、優先する観点を具体的に書くほうが判断材料になります。
料金は二つの利用量で考える
Copilot code reviewの費用は、レビューそのものに使うAI Creditsと、完全なプロジェクト文脈の収集やツール利用などに関わるGitHub Actions分の二つに分かれます。AI Creditsだけを見ていると、Actionsランナーの利用を見落とすので注意が必要です。
公式の目安では、1レビューあたりLiteは約0.05〜1米ドル相当、Balancedは約0.25〜5米ドル相当のAI Creditsを使います。これは一般的な見込みで、プルリクエストの大きさやカスタム指示によって増減し、GitHub Actions分は含みません。より大きなGitHubホストランナーは、分単位で高い割合の課金になります。
また、プランに含まれる許容量を超えた追加利用は、GitHubのモデルと価格設定で1 AI Creditあたり0.01米ドルと案内されています。レビューごとの金額を固定費のように断定せず、実際の利用レポートと予算設定を見ながら調整してください。
自動レビューを有効にすると、プルリクエストの数だけ利用機会も増えます。誰の利用量として計上されるかは依頼方法や作成者によって変わり、ボットが作成・依頼した場合は組織へ直接計上されることがあります。AI Creditsの共通ルールと予算の見方は、サイト内のCopilot AI Credits料金と上限の解説も合わせてどうぞ。
予算確認の順番
対象PR数 → LiteとBalancedの使い分け → AI Creditsの利用レポート → Actionsランナーと分数、の順で見ると、どこで利用量が増えたか追いやすくなります。
安全に使うための確認項目
GitHubは責任ある利用の説明で、コードレビューには見落とし、誤検知、不正確または安全でないコード提案があり得ると明記しています。生成されたコードは、意味や構文が正しく見えても、指摘を本当に直せていなかったり、別の不具合や脆弱性を加えたりする可能性があります。
そのため、Copilotのレビューは人間のレビューを置き換えるものではなく、確認箇所を増やす補助役として使います。詳しい制限はGitHub Copilotエージェントの責任ある利用にまとめられています。
- 元の要件とプルリクエストの差分が一致しているか
- 未解決だけでなく自動解決済みコメントも妥当か
- 必要なテストが実行され、失敗やスキップがないか
- 権限、シークレット、個人情報、外部通信への影響がないか
- 人間のレビュアーと必要な承認を残しているか
AIが使えるツールや権限を広げるほど、できる確認は増えますが、影響範囲も広がります。リポジトリの権限設計や承認の考え方はAIエージェントの権限管理で詳しく説明しています。
モデル名を自分で選べると思う人もいるかもしれませんが、Copilot code reviewは調整済みのモデル、プロンプト、システム動作を組み合わせた専用機能で、モデル切り替えはサポートされていません。Copilot Chatで使うモデルの話とは分けて考えましょう。Copilotの新モデルを知りたい場合はGitHub Copilot GPT-6 Astraの使い方が別の検索意図に対応します。
コードレビューのよくある質問
Q1. 無料プランでもCopilot code reviewを使えますか？
A. 個人のCopilot Freeにはコードレビューが含まれません。すべての有料Copilotプランで利用できます。組織では管理者がポリシーを有効にすると、CopilotライセンスのないメンバーがGitHub.com上で利用できる場合がありますが、利用分は組織に課金されます。
Q2. コメント自動解決とPR承認は同じですか？
A. 同じではありません。自動解決は、後続コミットが指摘内容に対応したとCopilotが再レビュー時に判断したコメント表示です。既定のCopilotレビューは必須承認に数えられず、プルリクエスト全体の安全性やマージ可否を保証しません。
Q3. 修正後は自動で再レビューされますか？
A. 設定によります。自動レビューのルールで新しいプッシュのレビューを有効にしていれば、コミットをプッシュするたびにレビューされます。無効なら自動レビューは原則1回なので、修正後に手動で再レビューを依頼します。
Q4. LiteとBalancedはどう選びますか？
A. 日常的な変更は既定のLite、複雑なロジック、安全性に関係するコード、サービスをまたぐ変更はBalancedが目安です。BalancedはAI CreditsとGitHub Actions分をより多く使う可能性があるため、変更の重要度と予算を合わせて選びます。
Q5. Copilotの指摘だけでマージしてよいですか？
A. Copilotの指摘だけで判断するのは避けます。見落とし、誤検知、不正確または安全でない提案があり得るため、差分、未解決コメント、テスト結果、権限やシークレットへの影響を確認し、人間のレビューと承認を残します。
GitHub Copilotコードレビューまとめ
GitHub Copilotコードレビューは、2026年9月11日の更新で、対応済みコメントを再レビュー時に自動解決できるようになりました。提案適用時のコミットメッセージ案、シェルツールによる検証、Liteでの複数エージェント確認も加わり、修正と確認の往復を進めやすくなっています。
一方で、自動解決は自動承認ではありません。対応が残るコメントは開いたままになりますが、AIの見落としや誤検知、提案コードの問題はあり得ます。解決済みコメントの対応コミット、差分、テスト、Actionsの状態、権限への影響、人間の承認を確認してからマージしましょう。
- 小さなプルリクエストで手動レビューから試す
- 修正後の再レビュー方法を決める
- AI CreditsとActions分を別々に見る
- 自動解決済みも人が確認して承認する
まずは影響の小さいリポジトリでLiteを使い、役に立った指摘と誤検知、利用量を数回分だけ確認するのがおすすめです。そこでチームの基準と合うと分かってから、自動レビューの対象を少しずつ広げると、便利さと安全性の両方を保ちやすいですよ。
