2026年6月19日時点で確認できる公式情報では、Copilot code reviewに「リポジトリ直下の AGENTS.md をレビュー時の文脈として使う改善」と「ドラフトPull Requestでレビュー依頼しやすくするUI改善」が追加されています。結論から言うと、チームのコーディング規約やレビュー観点を AGENTS.md に整理しておくと、Copilotのレビューコメントをリポジトリの実情に近づけやすくなります。GitHub Changelog上では、これらの変更は一般提供済みの改善として案内されています。(The GitHub Blog)
ただし、AGENTS.md を置けば必ず人間のレビュアーと同じ判断ができるわけではありません。Copilot code reviewは、バグの見落としを減らしたり、レビュー前の一次チェックを効率化したりするための支援機能です。この記事では、「何が変わったのか」「誰が対象なのか」「見えない・使えない時はどこを確認すべきか」をQ&A形式で整理します。
Copilot code review: AGENTS.md support and UI improvements のよくある疑問を整理
今回の更新で特に重要なのは、Copilot code reviewがリポジトリルートの AGENTS.md を読み取り、関連する指示をレビューコメント生成時に利用できるようになった点です。既に AGENTS.md を置いているリポジトリでは、その内容が自動的に文脈として使われるため、レビューがチームの規約や期待値に沿いやすくなります。(The GitHub Blog)
あわせて、ドラフトPull RequestでもCopilotにレビューを依頼しやすいように、レビューピッカー上でCopilotの横にRequestボタンが表示されるようになりました。また、Pull RequestのConversationタブでCopilot code review関連イベントが増えて見づらくなる問題に対し、一部イベントを折りたたんで表示するUI改善も行われています。(The GitHub Blog)
| 変更点 | 何が便利になるか | 主に対象になる人 |
|---|---|---|
AGENTS.md サポート | コーディング規約、設計方針、レビュー観点をCopilot code reviewに伝えやすくなる | 開発チーム、リポジトリ管理者、テックリード |
| ドラフトPRのRequestボタン | 公開前のPull RequestでもCopilotレビューを依頼しやすくなる | PR作成者、レビュー前に自己チェックしたい開発者 |
| タイムラインイベントの折りたたみ | ConversationタブがCopilot関連イベントで埋まりにくくなる | レビュアー、メンテナー、複数人開発チーム |
なお、該当するGitHub Changelogページの分類表示は「Improvement」です。社内資料や記事タイトルで「Release」として扱う場合でも、本文では「一般提供された改善」「レビュー体験の改善」と説明した方が、機能の位置づけを誤解されにくくなります。(The GitHub Blog)
Copilot code reviewとは何ですか？
Copilot code reviewは、Pull RequestやIDE上の変更に対して、GitHub Copilotがレビューコメントや修正提案を出す機能です。GitHub公式ドキュメントでは、Copilot code reviewはコードを複数の観点から確認し、問題の指摘や修正候補の提示を行う機能として説明されています。(GitHub Docs)
人間のレビュアーを置き換えるというより、次のような場面で役立ちます。
- Pull Requestを出す前に、明らかなミスや規約違反を見つけたい
- レビュアーに依頼する前に、ドラフト段階で一度チェックしたい
- チーム共通の観点を毎回レビューに反映したい
- セキュリティ、可読性、テスト観点の抜け漏れを減らしたい
特に、レビュー待ち時間が長くなりやすいチームでは、Copilot code reviewを「人間レビュー前の一次チェック」として使うと効果が出やすくなります。人間のレビュアーは設計判断や仕様の妥当性に集中し、Copilotには単純な見落としや定型的な指摘を任せる、という分担が現実的です。
AGENTS.mdサポートとは何が変わったのですか？
今回のAGENTS.mdサポートでは、Copilot code reviewがリポジトリのルートにある AGENTS.md を読み取り、その内容のうち関連する指示をレビューコメント生成時に使えるようになりました。GitHub Changelogでは、リポジトリルートの AGENTS.md を読み、関連する指示をレビューのフィードバックに使うと説明されています。(The GitHub Blog)
これまでCopilotにリポジトリの事情を伝えるには、個別のプロンプトやカスタム指示を使う必要がありました。AGENTS.md を使うと、チームで共有したいレビュー観点をリポジトリ内に残せるため、レビューのばらつきを減らしやすくなります。
たとえば、次のような内容を AGENTS.md に書くと実務で使いやすくなります。
# Review guidance for this repository
- Public APIの変更がある場合は、互換性への影響を確認してください。
- データベースのクエリを変更する場合は、N+1問題とインデックスの必要性を確認してください。
- 認証・認可に関わる変更では、権限チェックの抜け漏れを優先して指摘してください。
- 新しいビジネスロジックを追加する場合は、正常系だけでなく異常系のテストも確認してください。
- ログには個人情報、アクセストークン、シークレットを出力しないでください。ポイントは、抽象的な理想論ではなく「何を見てほしいか」をレビュー観点として書くことです。「品質を高めてください」よりも、「認証・認可に関わる変更では権限チェックの抜け漏れを確認してください」の方が、Copilotにも人間にも伝わりやすくなります。
AGENTS.mdはどこに置けばよいですか？
今回のChangelogで明示されているのは、リポジトリのルートにある AGENTS.md です。つまり、README.md や package.json などがある最上位階層に AGENTS.md を置く形です。(The GitHub Blog)
間違えやすい配置は次のとおりです。
| 配置 | Copilot code reviewでの扱い |
|---|---|
/AGENTS.md | 今回の更新で説明されている配置 |
/docs/AGENTS.md | 公式Changelog上の説明対象ではないため、期待通り使われない可能性がある |
/.github/AGENTS.md | AGENTS.md サポートとして明示されている場所ではない |
/agent.md、/AGENT.md | ファイル名が異なるため対象外になる可能性が高い |
まずはリポジトリルートに短い AGENTS.md を置き、テスト用Pull Requestでレビューコメントの傾向が変わるか確認するのがおすすめです。
.github/copilot-instructions.mdとは何が違いますか？
GitHub Copilotには、従来からリポジトリ単位のカスタム指示として .github/copilot-instructions.md を使う方法があります。公式ドキュメントでは、リポジトリ全体のカスタム指示は .github/copilot-instructions.md に書き、パス固有の指示は .github/instructions/**/*.instructions.md に書けると説明されています。(GitHub Docs)
今回の更新は、それとは別にCopilot code reviewがリポジトリルートの AGENTS.md も使えるようになった点が特徴です。どちらか一方だけを使うべきというより、チームの運用に合わせて整理するとよいでしょう。
| ファイル | 向いている使い方 |
|---|---|
AGENTS.md | リポジトリ全体の開発方針、レビュー観点、ビルド・テスト方針を人間とAIの両方に共有したい場合 |
.github/copilot-instructions.md | Copilot向けのリポジトリ全体のカスタム指示を明確に管理したい場合 |
.github/instructions/**/*.instructions.md | フロントエンド、バックエンド、インフラなど、パスごとに異なるレビュー観点を持たせたい場合 |
注意したいのは、複数の指示ファイルに矛盾した内容を書かないことです。公式ドキュメントでも、複数種類のカスタム指示が適用される場合があり、競合する指示は避けることが推奨されています。(GitHub Docs)
AGENTS.mdには何を書くべきですか？
AGENTS.md には、Copilot code reviewに見てほしい観点を具体的に書くのが効果的です。長すぎる社内規約をそのまま貼るより、レビュー時に判断してほしい項目に絞りましょう。
書くと効果が出やすい内容
| 書く内容 | 具体例 |
|---|---|
| レビューで重視する観点 | セキュリティ、パフォーマンス、可読性、後方互換性、テスト不足 |
| プロジェクト固有の約束 | APIレスポンス形式、エラーハンドリング方針、命名規則 |
| テスト方針 | 新しいロジックにはユニットテストを追加する、DB変更時はマイグレーション確認を行う |
| 避けたい実装 | グローバル状態の追加、同期的な重い処理、直接SQLの乱用 |
| 重要な確認事項 | 個人情報をログ出力しない、認可チェックをスキップしない |
書いても効果が出にくい内容
| 避けたい書き方 | 理由 |
|---|---|
| 「良いコードにしてください」 | 判断基準が曖昧で、レビュー観点に落とし込みにくい |
| 社内規約を数万字貼る | 重要な指示が埋もれやすく、メンテナンスも難しい |
| 矛盾した指示を書く | 例外条件が不明確になり、レビューの一貫性が落ちる |
| 秘密情報を書く | リポジトリ内のファイルとして管理されるため、シークレットや認証情報は書くべきではない |
実務では、最初から完璧な AGENTS.md を作る必要はありません。まずは5〜10項目程度に絞り、Copilotのレビューコメントを見ながら改善していく方が運用に乗りやすくなります。
ドラフトPull RequestのUI改善では何が変わりましたか？
今回のUI改善では、ドラフトPull RequestでもCopilot code reviewを依頼しやすくなりました。GitHub Changelogによると、ドラフトPull RequestのレビューピッカーでCopilotの横にRequestボタンが表示され、Copilotを検索しなくても直接レビュー依頼できるようになっています。(The GitHub Blog)
これは、レビュー前の自己チェックに向いています。たとえば、次のような流れです。
| タイミング | Copilot code reviewの使い方 |
|---|---|
| 実装途中 | ドラフトPRを作り、早めにCopilotへレビュー依頼する |
| 人間レビュー前 | 指摘された軽微な問題を先に修正する |
| レビュー依頼時 | 人間レビュアーには設計・仕様・影響範囲を重点的に見てもらう |
| 追加修正後 | 必要に応じて再レビューを依頼し、修正漏れを確認する |
ドラフトPRでのレビューは、コードが完成してから初めて問題に気づくリスクを下げられます。特に大きな変更では、早い段階でセキュリティや設計の懸念を洗い出せるため、手戻りを減らしやすくなります。
Pull RequestのConversationタブはどう改善されましたか？
Copilot code reviewを使うと、Pull Requestのタイムラインにレビュー依頼やレビュー実行に関するイベントが増えます。今回の更新では、Conversationタブで一部のCopilot code reviewイベントがまとめて折りたたまれるようになり、重要なコメントや会話を見つけやすくなりました。(The GitHub Blog)
小さな改善に見えますが、チーム開発では意外に重要です。Pull RequestのConversationタブは、仕様の確認、レビューコメント、CI結果、マージ判断などが集まる場所です。ここがCopilot関連イベントで埋まると、人間の判断に必要な会話が追いにくくなります。
誰が今回の更新の対象になりますか？
Copilot code reviewは、GitHub.com、GitHub CLI、GitHub Mobile、VS Code、Visual Studio、Xcode、JetBrains IDE、Azure DevOpsのパブリックプレビューなどでサポートされています。GitHub公式ドキュメントでは、Copilot code reviewは有料のCopilotプランで利用可能とされています。また、組織からCopilotを提供されている場合は、組織側でCopilot code reviewのポリシーが有効になっている必要があります。(GitHub Docs)
特に今回の AGENTS.md サポートが効きやすいのは、次のようなリポジトリです。
| 対象 | 活用イメージ |
|---|---|
| 複数人で開発しているリポジトリ | レビュー観点を統一し、レビュアーごとの差を減らす |
| 新メンバーが多いチーム | 暗黙知になっている設計方針や禁止事項を明文化する |
| セキュリティや品質要件が高いプロジェクト | 認可、入力検証、ログ出力、依存関係の扱いを重点チェックする |
| 大規模なモノレポ | 共通ルールは AGENTS.md、領域別ルールはパス固有の指示で分ける |
| レビュー待ちがボトルネックになっているチーム | 人間レビュー前に機械的な指摘を先に処理する |
一方で、個人開発や小さな検証用リポジトリでは、最初から細かい AGENTS.md を作り込む必要はありません。READMEに書いている開発手順やテスト方法のうち、レビューに関係する部分だけを短く転記する程度でも十分です。
Copilot code reviewが見えない・使えない時の確認ポイント
Copilot code reviewや今回のUI改善が見えない場合は、機能そのものの不具合と決めつける前に、権限・プラン・リポジトリ設定・Pull Requestの状態を順番に確認しましょう。
| 確認項目 | 見る場所・判断基準 |
|---|---|
| Copilotの利用条件 | 有料Copilotプラン、または組織側で許可された利用条件を満たしているか |
| 組織ポリシー | OrganizationまたはEnterpriseでCopilot code reviewが有効になっているか |
| リポジトリ設定 | Copilot code reviewやカスタム指示の利用が無効化されていないか |
| Pull Requestの状態 | ドラフトPRか、通常のPRか、レビューピッカーが表示される権限があるか |
AGENTS.md の場所 | リポジトリルートに AGENTS.md があるか |
| ブランチ | レビュー対象PRのベースブランチ側に必要な指示が存在するか |
| ファイル種別 | Copilot code reviewの対象外ファイルだけを変更していないか |
| IDE利用時 | 対応IDEや拡張機能のバージョン要件を満たしているか |
GitHub Docsでは、組織からCopilotを提供されている場合、組織側でCopilot code reviewのオプションを有効にする必要があると説明されています。また、EnterpriseではCopilot code reviewのポリシーを通じて、ライセンスユーザーがレビュー依頼やPull Requestサマリー生成を利用できるように設定します。(GitHub Docs)
AGENTS.mdを置いたのに反映されない時は何を確認すべきですか？
AGENTS.md を置いたのにレビュー内容が変わらない場合は、まず「置き場所」「内容の具体性」「レビューの再実行」を確認します。
ルートに置いているか
今回のChangelogで説明されているのは、リポジトリルートの AGENTS.md です。サブディレクトリや .github 配下に置いている場合、今回のサポート対象として期待した動きにならない可能性があります。(The GitHub Blog)
指示が抽象的すぎないか
「品質を高める」「適切にレビューする」といった書き方では、レビューコメントに反映されにくくなります。以下のように、対象と観点を分けて書くと確認しやすくなります。
- APIレスポンスを変更する場合は、既存クライアントとの互換性を確認してください。
- 認可処理を変更する場合は、一般ユーザーが管理者向け操作を実行できないことを確認してください。
- DBアクセスを追加する場合は、ループ内クエリによるN+1問題がないか確認してください。PRを作り直す・レビューを依頼し直す
AGENTS.md を追加した後、既存のレビュー結果が自動的にすべて書き換わるとは限りません。確認用の小さなPull Requestを作り、Copilotにレビューを依頼し直して、指摘内容に変化があるかを見ます。
カスタム指示の設定が無効になっていないか
GitHub Docsでは、Copilot code reviewでカスタム指示を使う設定はデフォルトで有効ですが、リポジトリ設定から無効化・再有効化できると説明されています。設定画面では、RepositoryのSettingsからCopilot、Code reviewへ進み、「Use custom instructions when reviewing pull requests」を確認します。(GitHub Docs)
ドラフトPRでRequestボタンが出ない時は？
ドラフトPull RequestでCopilotのRequestボタンが見えない場合は、次の順番で確認すると原因を切り分けやすくなります。
| 症状 | 確認すること |
|---|---|
| Copilot自体がレビューピッカーに出ない | Copilot code reviewが利用可能なプラン・組織ポリシーか |
| Requestボタンが見えない | Pull Requestがドラフト状態か、レビューピッカーを開いているか |
| 検索するとCopilotは出る | UI更新の表示差やブラウザキャッシュの可能性があるため、再読み込みや別ブラウザで確認 |
| 自動レビューされない | ルールセットで自動レビューが設定されているか |
| ドラフトPRでは自動レビューされない | 自動レビュー設定で「Review draft pull requests」が有効か |
自動レビューを使う場合、GitHub Docsでは、Pull Requestへの新しいpushをレビューさせる「Review new pushes」や、ドラフト段階のPull Requestをレビューさせる「Review draft pull requests」をオプションとして設定できると説明されています。(GitHub Docs)
Copilot code reviewの対象外になりやすいケースはありますか？
あります。GitHub Docsでは、依存関係管理ファイル、ログファイル、SVGファイルなど、一部のファイル種別はCopilot code reviewの対象外になると説明されています。対象外ファイルだけを変更しているPull Requestでは、レビューコメントが出ないことがあります。(GitHub Docs)
また、Copilotがコメントしない場合でも、それは必ずしも「正しいコードである」という意味ではありません。公式ドキュメントの利用手順でも、問題が見つからない場合にCopilotがファイルにコメントしないケースがあることが示されています。(GitHub Docs)
実務では、次のように判断すると安全です。
| 状況 | 判断 |
|---|---|
| Copilotがコメントしない | 明確に指摘できる問題が見つからなかった可能性がある |
| レビュー対象外ファイルが多い | 人間の確認やCI、静的解析で補う |
| セキュリティ関連の変更 | Copilotの指摘だけで承認せず、専門観点で人間が確認する |
| 仕様変更を含むPR | Copilotではなく、プロダクトオーナーや設計者の判断が必要 |
AGENTS.mdを使う時の注意点
AGENTS.md は便利ですが、運用ルールを決めずに増やすと、かえってレビュー品質が不安定になります。特に注意したいのは、指示の重複、矛盾、古さです。
| 注意点 | 実務での対策 |
|---|---|
| 指示が長すぎる | 最初は重要なレビュー観点に絞る |
| 複数ファイルで矛盾する | AGENTS.md を全体方針、パス固有指示を例外として整理する |
| 古い設計方針が残る | 大きな設計変更時に AGENTS.md も更新する |
| セキュリティ情報を書いてしまう | シークレット、トークン、内部認証情報は絶対に書かない |
| Copilot任せになる | 最終判断は人間のレビュアーとCIで確認する |
Copilot向けの指示は、チームの開発ルールそのものです。書いたら終わりではなく、レビューで役に立った指摘、逆にノイズになった指摘を見ながら調整していくのが現実的です。
実務でのおすすめ導入手順
いきなり全リポジトリに展開するより、まずは変更頻度が高く、レビュー観点が明確なリポジトリで試すのがおすすめです。
| 手順 | 作業内容 |
|---|---|
| 1 | 既存のレビュー指摘を見返し、繰り返し出ている観点を洗い出す |
| 2 | リポジトリルートに短い AGENTS.md を作成する |
| 3 | ドラフトPRでCopilot code reviewを依頼する |
| 4 | 指摘が役に立つか、ノイズが増えていないか確認する |
| 5 | 必要に応じて .github/copilot-instructions.md やパス固有指示と整理する |
| 6 | チームのPull Requestテンプレートやレビュー手順に反映する |
導入時は、次のような短いテンプレートから始めると運用しやすくなります。
# AGENTS.md
## Code review priorities
- Security-sensitive changes must be reviewed for authorization checks, input validation, and secret leakage.
- Database changes must be reviewed for migration safety, indexes, and N+1 queries.
- Public API changes must be reviewed for backward compatibility.
- New business logic should include tests for normal and error cases.
- Avoid adding global state unless there is a clear reason.英語で書く必要があるわけではありませんが、チームで英語コメントを使っている場合は英語、国内チームで日本語レビューをしている場合は日本語で十分です。大切なのは、Copilotと人間の両方が同じ判断基準を参照できることです。
まとめ：AGENTS.mdはCopilot code reviewをチーム仕様に近づけるための入口
今回のCopilot code reviewの更新では、リポジトリルートの AGENTS.md を使ってレビューの文脈を補えるようになり、ドラフトPull Requestでのレビュー依頼やConversationタブの見やすさも改善されました。特に、チーム独自の設計方針やレビュー観点があるリポジトリでは、AGENTS.md を整備する価値があります。(The GitHub Blog)
まずやるべきことはシンプルです。既存のレビューで繰り返し指摘している内容を5〜10項目に絞り、リポジトリルートに AGENTS.md として追加します。そのうえで、ドラフトPRでCopilot code reviewを依頼し、指摘の質を確認します。効果が見えたら、パス固有の指示や自動レビュー設定と組み合わせ、チームのレビュー手順に組み込んでいきましょう。
コメント