Copilot code reviewの今回の変更でまず確認すべきなのは、リポジトリ直下のAGENTS.mdがレビューコメントに影響する可能性があるという点です。これまで開発エージェント向けにAGENTS.mdを書いていたチームでは、その内容がCopilot code reviewの指摘方針にも使われるため、ルールの書き方を見直す価値があります。
あわせて、ドラフトプルリクエストからCopilotへレビュー依頼しやすくなるUI改善と、プルリクエストのタイムライン表示を整理する改善も入っています。大きな移行作業が必要な変更ではありませんが、既存のAGENTS.mdやカスタム指示を放置すると、レビューが細かすぎる、意図しない観点で指摘される、チーム標準とずれるといった運用上のズレが起きる可能性があります。
変更の要点
GitHub Changelogでは、Copilot code reviewがリポジトリレベルのAGENTS.mdに対応し、ドラフトプルリクエストでCopilotへレビューを依頼しやすくなったことが案内されています。対象の変更は一般提供済みとして説明されています。なお、確認できるGitHub Changelog上の当該ページは2026年6月18日付の「Improvement」表示です。日本時間や社内取り込み日では2026年6月19日更新として扱われる場合があります。(The GitHub Blog)
| 変更点 | 何が変わったか | 利用者への影響 |
|---|---|---|
AGENTS.md対応 | リポジトリ直下のAGENTS.mdをCopilot code reviewが読み取り、関連する指示をレビューコメント生成に利用 | 既存のAGENTS.mdがレビュー品質や指摘内容に影響する |
| ドラフトPRのレビュー依頼UI改善 | ドラフトプルリクエストでも、レビュー担当者選択の流れでCopilot横にRequestボタンが表示される | 下書き段階でCopilotレビューを依頼しやすくなる |
| PRタイムラインの整理 | Conversationタブ上の一部Copilot code reviewイベントが折りたたまれて表示される | タイムラインのノイズが減り、重要なコメントを追いやすくなる |
今回の中心は、単なる画面変更ではなく「Copilotにどのルールを読ませてレビューさせるか」がより重要になった点です。特に、複数人で開発するリポジトリではAGENTS.mdをチームのレビュー基準として整えることで、レビューコメントのばらつきを減らしやすくなります。
Copilot code reviewのAGENTS.md対応で何が変わるのか
今回の更新により、Copilot code reviewはリポジトリのルートにあるAGENTS.mdを読み取り、その中の関連する指示をレビューコメントに反映できるようになりました。GitHub Changelogでは、すでにAGENTS.mdが存在するリポジトリでは、その内容がCopilot code reviewのワークフロー内で自動的に活用されると説明されています。(The GitHub Blog)
たとえば、AGENTS.mdに次のようなルールを書いている場合、Copilotのレビュー観点に影響する可能性があります。
# Code review guidelines
- レビューコメントは日本語で書く。
- 認証・認可処理の変更では、権限チェック漏れを重点的に確認する。
- APIレスポンスの互換性を壊す変更があれば指摘する。
- テストが追加されていない仕様変更にはコメントする。
- 命名規則は既存コードのスタイルに合わせる。これにより、Copilot code reviewを「一般的なAIレビュー」ではなく、プロジェクト固有のレビュー担当者に近づけやすくなります。特に、セキュリティ観点、テスト観点、API互換性、命名規則、例外処理、ログ出力ルールなど、チーム内で毎回確認している項目を明文化しておくと効果的です。
一方で、AGENTS.mdが実装エージェント向けに書かれている場合は注意が必要です。「必ずリファクタリングする」「可能な限りコードを短くする」「全ファイルを最新設計に寄せる」といった曖昧または強すぎる指示は、レビューコメントのノイズを増やす原因になります。
対象になる利用者
今回の影響を受けやすいのは、GitHub上でCopilot code reviewを使ってプルリクエストレビューを行っているチームです。特に、すでにAGENTS.mdを運用しているリポジトリ、または今後Copilotによるレビュー品質を標準化したいリポジトリでは確認が必要です。
| 対象者 | 確認すべきこと |
|---|---|
| 開発者 | CopilotのレビューコメントがAGENTS.mdのルールと合っているか |
| リポジトリ管理者 | AGENTS.mdやカスタム指示がチーム標準として適切か |
| テックリード | レビュー観点が過不足なく書かれているか |
| セキュリティ担当 | セキュリティレビューで必ず見てほしい観点が明文化されているか |
| GitHub管理者 | Copilot code reviewやカスタム指示の設定が意図通りか |
反対に、Copilotのコード補完だけを使っていて、GitHub上のCopilot code reviewを使っていない場合、今回の影響は限定的です。また、AGENTS.mdが存在しないリポジトリでは、すぐにレビュー内容が変わるとは限りません。
すぐ確認したいポイント
リポジトリ直下にAGENTS.mdがあるか確認する
まずは対象リポジトリのルートにAGENTS.mdがあるか確認します。
your-repository/
├─ AGENTS.md
├─ README.md
├─ package.json
└─ src/AGENTS.mdがある場合は、内容がCopilot code reviewに読まれても問題ないかを確認してください。特に次のような内容が含まれている場合は見直し候補です。
| 見直したい記述 | なぜ注意が必要か | 修正例 |
|---|---|---|
| 「常に最適化する」 | 何をもって最適化するか曖昧 | 「パフォーマンスに影響するループやN+1クエリを指摘する」 |
| 「できるだけ短く書く」 | 可読性より短さを優先する指摘が出る可能性 | 「短さより可読性と保守性を優先する」 |
| 「全体をリファクタリングする」 | PRの目的外の指摘が増えやすい | 「変更箇所に直接関係する設計上の問題のみ指摘する」 |
| 外部ドキュメントのURLだけを書く | Copilotがリンク先を必ず参照するとは限らない | 重要なルールはAGENTS.md内に要約して書く |
| 秘密情報や内部資格情報 | リポジトリに保存すべきでない | 機密情報は書かず、公開可能なルールだけを書く |
AGENTS.mdはリポジトリにコミットされるファイルです。パスワード、APIキー、社内限定の認証情報、顧客情報などは絶対に含めないでください。
Copilot向けの既存カスタム指示と矛盾していないか確認する
GitHub Copilotには、AGENTS.md以外にもリポジトリ単位やパス単位のカスタム指示があります。GitHub Docsでは、リポジトリ全体のカスタム指示は.github/copilot-instructions.md、パス別の指示は.github/instructions/**/*.instructions.mdに書けると説明されています。(GitHub Docs)
たとえば、次のように複数の指示ファイルが併存しているリポジトリでは、内容の重複や矛盾を確認してください。
your-repository/
├─ AGENTS.md
└─ .github/
├─ copilot-instructions.md
└─ instructions/
├─ frontend.instructions.md
└─ security.instructions.mdよくある失敗は、AGENTS.mdでは「レビューコメントは日本語」と書いているのに、.github/copilot-instructions.mdでは「Respond in English」と書いているようなケースです。GitHub Docsでも、複数種類のカスタム指示が適用される可能性があり、品質に不安がある場合は矛盾を避けるべきだと説明されています。(GitHub Docs)
役割分担としては、次のように整理すると運用しやすくなります。
| ファイル | 向いている内容 |
|---|---|
AGENTS.md | エージェントやレビューに共通して伝えたいプロジェクトの基本方針 |
.github/copilot-instructions.md | Copilot全体に適用したいリポジトリ標準 |
.github/instructions/*.instructions.md | 言語別、ディレクトリ別、セキュリティ別など対象を絞った指示 |
既存ファイルをすべて増やす必要はありません。小規模なリポジトリなら、まずAGENTS.mdにレビュー方針を短くまとめるだけでも十分です。
Copilot code reviewのカスタム指示設定を確認する
GitHub Docsでは、Copilot code reviewのカスタム指示はデフォルトで有効ですが、リポジトリ設定から無効化または再有効化できるとされています。設定場所は、対象リポジトリのSettingsからCopilot、Code reviewへ進み、「Use custom instructions when reviewing pull requests」を切り替える流れです。(GitHub Docs)
確認する流れは次のとおりです。
| 手順 | 確認内容 |
|---|---|
| 1 | GitHubで対象リポジトリを開く |
| 2 | Settingsを開く |
| 3 | Code & automation配下のCopilotを開く |
| 4 | Code reviewの設定を確認する |
| 5 | カスタム指示をレビューに使うかをチーム方針に合わせる |
チームでAGENTS.mdや.github/copilot-instructions.mdを整備しているのに、設定が無効になっていると期待したレビューになりません。反対に、まだ指示ファイルが整理できていないリポジトリでは、一時的に無効化してから段階的に整える判断もあります。
ベースブランチ側の指示を確認する
GitHub Docsでは、プルリクエストをレビューする際、Copilotはプルリクエストのベースブランチにあるカスタム指示を使うと説明されています。たとえばmy-feature-branchからmainへマージするPRでは、main側の指示が使われます。(GitHub Docs)
そのため、指示ファイルを追加したブランチでPRを作っただけでは、すぐ期待どおりに反映されない場合があります。まずmainなどのベースブランチにチーム標準の指示を入れてから、通常の機能開発PRでレビュー結果を確認するのが安全です。
AGENTS.mdに書くべき内容
AGENTS.mdは長ければよいわけではありません。GitHub Blogでは、Copilot code review向けの指示は短く、構造化され、直接的なルールとして書くことが推奨されています。また、長すぎる指示ファイルは一貫性のない動作につながる可能性があるとも説明されています。(The GitHub Blog)
実務では、次の5項目を優先して書くと効果が出やすくなります。
| 書く内容 | 具体例 |
|---|---|
| レビュー言語 | 「レビューコメントは日本語で書く」 |
| 優先して見る観点 | 「認証、認可、入力検証、例外処理を重点的に確認する」 |
| チームの設計方針 | 「Controllerにビジネスロジックを書かず、Service層に分離する」 |
| テスト方針 | 「仕様変更には単体テストまたは統合テストの追加を確認する」 |
| 指摘しないこと | 「単なる好みの命名変更やフォーマットだけの指摘は避ける」 |
すぐ使えるサンプルは次のとおりです。
# Copilot code review guidelines
## Review language
- レビューコメントは日本語で書く。
- 指摘は簡潔にし、必要に応じて修正例を示す。
## Security
- 認証、認可、入力検証、ログ出力の変更を重点的に確認する。
- 個人情報やトークンがログに出力される可能性がある場合は指摘する。
## Maintainability
- 既存の命名規則、ディレクトリ構成、責務分離に反する変更を指摘する。
- 変更範囲と関係が薄いリファクタリング提案は避ける。
## Tests
- 仕様変更、バグ修正、条件分岐の追加にはテストの有無を確認する。
- テストがない場合は、どの観点のテストが必要かを具体的に提案する。ポイントは「Copilotに何をしてほしいか」だけでなく、「何をしなくてよいか」も書くことです。これにより、レビューコメントが実務で使いやすい粒度に近づきます。
書かないほうがよい内容
Copilot code reviewへの指示として不向きな内容もあります。GitHub Blogでは、CopilotコメントのUXや表示形式を変えようとする指示、Pull Request Overviewコメントの目的を変えようとする指示、レビュー以外のタスクを実行させようとする指示、外部リンクだけを含める指示などは避けるべき例として説明されています。(The GitHub Blog)
たとえば、次のような指示は避けたほうが安全です。
- このPRをマージできないようにブロックする。
- CopilotのコメントUIを赤色にする。
- 必ずすべての設計を最新アーキテクチャに変更する。
- 詳細は社内WikiのURLを参照する。
- とにかくすべての問題を見つける。これらは実現できない、曖昧すぎる、レビュー範囲を超えている、またはノイズになりやすい指示です。Copilot code reviewには、レビュー担当者に渡すチェックリストのように、具体的で検証しやすい観点を書きましょう。
ドラフトプルリクエストでの使い方
今回のUI改善により、ドラフトプルリクエストでもCopilotへのレビュー依頼がしやすくなりました。GitHub Changelogでは、ドラフトPRのレビュー担当者選択でCopilotの横にRequestボタンが表示され、Copilotを検索しなくても直接依頼できるようになったと説明されています。(The GitHub Blog)
実務では、次のような使い方が向いています。
| タイミング | Copilot code reviewの使い方 |
|---|---|
| 実装途中のドラフトPR | 大きな設計ミスやテスト不足を早めに検出する |
| 人間レビュー前 | 明らかなミスや機械的な指摘を先に潰す |
| セキュリティ関連の変更 | 認可漏れ、入力検証漏れ、ログ出力の問題を補助的に確認する |
| リファクタリングPR | 既存仕様の破壊やテスト不足を確認する |
おすすめは、ドラフトPRの段階で一度Copilotレビューを依頼し、指摘を整理してから人間のレビュアーに回す流れです。人間のレビュアーは、仕様判断、設計判断、業務知識が必要な部分に集中しやすくなります。
ただし、Copilotのレビューを通したからといって、人間レビューを省略できるわけではありません。特に本番影響の大きい変更、権限管理、課金処理、個人情報処理、データ移行などは、必ず担当者が確認する運用にしてください。
PRタイムラインの表示改善で変わること
もう一つのUI改善は、プルリクエストのConversationタブに表示されるCopilot code review関連イベントの整理です。GitHub Changelogでは、一部のCopilot code reviewタイムラインイベントをまとめて折りたたむことで、Conversationタブのノイズを減らすと説明されています。(The GitHub Blog)
この変更は、レビューコメントそのものを削除するものではありません。Copilotがレビューした、再レビューした、イベントが記録されたといった情報が見やすく整理される改善です。
運用上は、次の点だけチーム内で共有しておくと混乱を防げます。
| 確認ポイント | 説明 |
|---|---|
| コメントが消えたわけではない | 一部イベント表示がまとまるだけで、レビュー内容は確認できる |
| タイムラインが短く見える | Copilot関連イベントの表示が整理されるため |
| 監査目的では詳細確認が必要 | 必要に応じてレビューイベントやセッション情報を個別に確認する |
これまでCopilotレビューを頻繁に使っていて、PRのConversationタブがCopilotイベントで埋まりがちだったチームには、地味ながら使いやすい改善です。
既存リポジトリでの確認手順
既存リポジトリでは、次の順番で確認すると無駄がありません。
| 順番 | 作業 | 判断基準 |
|---|---|---|
| 1 | AGENTS.mdの有無を確認 | ルートに存在するか |
| 2 | 内容をレビュー向けに確認 | 曖昧、過剰、矛盾する指示がないか |
| 3 | .github/copilot-instructions.mdなども確認 | 同じ内容や反対の指示がないか |
| 4 | Copilot code review設定を確認 | カスタム指示を使う方針と合っているか |
| 5 | ドラフトPRで試す | コメントの粒度、言語、観点が期待通りか |
| 6 | 必要に応じて指示を短く修正 | ノイズが多い場合はルールを減らす |
最初から完璧なAGENTS.mdを作る必要はありません。まずは「レビューコメントは日本語」「セキュリティとテストを重点確認」「好みだけの指摘は避ける」程度の短いルールから始め、実際のレビュー結果を見ながら調整するほうが失敗しにくいです。
運用で失敗しやすいポイント
指示を増やしすぎる
レビュー品質を上げようとして、AGENTS.mdに大量のルールを書き込むと逆効果になることがあります。長すぎる指示は、重要なルールが埋もれたり、Copilotのコメントが安定しにくくなったりする原因になります。
最初は10〜20行程度に絞り、実際に不足した観点だけを追加してください。
実装エージェント向けの指示をそのまま使う
AGENTS.mdは、Copilot code reviewだけでなく、エージェント型の開発支援でも使われる可能性があります。そのため「実装時の作業手順」と「レビュー時の確認観点」が混在していると、レビューコメントが期待とずれる場合があります。
おすすめは、見出しで用途を分けることです。
## General project rules
- 既存の設計方針を優先する。
## Code review rules
- レビューでは、変更箇所に直接関係する問題を優先して指摘する。
- 仕様判断が必要な点は、断定せず確認コメントとして書く。人間レビューの代替として扱う
Copilot code reviewは、見落としを減らす補助としては有効ですが、仕様の妥当性、事業上の判断、ユーザー影響、リリース判断まで自動で保証するものではありません。
特に次の変更では、人間の確認を必須にしてください。
| 変更内容 | 人間レビューが必要な理由 |
|---|---|
| 認証・認可 | 権限設計や業務要件の理解が必要 |
| 決済・課金 | 金銭的影響が大きい |
| 個人情報処理 | 法務・セキュリティ観点が必要 |
| データ移行 | 失敗時の復旧計画が必要 |
| 公開API変更 | 既存利用者への影響確認が必要 |
Copilotには「機械的に拾いやすい問題」を先に見てもらい、人間は「判断が必要な問題」に集中するのが現実的です。
今回の変更でチームが取るべき対応
今回のCopilot code reviewの変更は、すぐに大規模な移行が必要なものではありません。ただし、AGENTS.mdをすでに置いているリポジトリでは、レビュー結果に影響する可能性があるため、早めに内容を点検したほうが安全です。
まずは次の3つを実施してください。
1つ目は、リポジトリ直下のAGENTS.mdを確認し、レビューに使われても問題ない内容にすることです。2つ目は、.github/copilot-instructions.mdなど既存のカスタム指示と矛盾していないかを見ることです。3つ目は、ドラフトプルリクエストでCopilot code reviewを試し、コメントの粒度や言語、指摘観点がチームの期待と合っているか確認することです。
AGENTS.mdをうまく整備すれば、Copilot code reviewは単なる自動レビューではなく、チームのレビュー文化を反映した補助役になります。今回のUI改善もあわせて、ドラフト段階で早めにAIレビューをかけ、人間レビューの前に明らかな問題を減らす運用へ見直すのがよいでしょう。
コメント