Copilot code reviewのAGENTS.md対応とは？使い方・設定場所・導入前の注意点

Copilot code reviewの「AGENTS.md support and UI improvements」は、プルリクエストレビューでCopilotにリポジトリのルールを伝えやすくする更新です。結論から言うと、まず確認すべきことは3つです。リポジトリのルートにAGENTS.mdを置くこと、レビュー対象のプルリクエストでCopilotにレビューを依頼すること、そしてCopilotの指摘を人間のレビューの代わりにしないことです。

今回の更新では、Copilot code reviewがリポジトリルートのAGENTS.mdを参照できるようになり、Draft pull requestでもCopilotへのレビュー依頼ボタンを見つけやすくなりました。さらに、プルリクエストのタイムライン上でCopilot関連イベントがまとまり、会話欄が見やすくなっています。GitHub Changelog上では2026年6月18日付のImprovementとして掲載されています。(The GitHub Blog)

Copilot code reviewで何が変わったのか

今回の変更は、Copilotが「コードの差分だけを見るレビュー」から一歩進み、リポジトリごとの前提やチームルールを踏まえたレビューをしやすくするための改善です。

主な変更点は次の3つです。

変更点	できるようになったこと	使う場面
`AGENTS.md`サポート	リポジトリルートの`AGENTS.md`に書いた指示をCopilot code reviewが参照できる	チームのレビュー観点、ビルド手順、禁止パターンを反映したい
Draft PRのUI改善	Draft pull requestでもCopilot横の`Request`ボタンからレビュー依頼しやすい	まだ正式レビュー前の段階で早めにAIレビューを受けたい
タイムライン整理	Copilot関連のレビューイベントがまとまって表示される	PRのConversationタブが通知で埋もれるのを避けたい

GitHubの公式説明では、Copilot code reviewはリポジトリルートのAGENTS.mdを読み、関連する指示をレビューコメント生成時に使うとされています。また、Draft PRではReviewer pickerでCopilotを探す手間が減り、Copilot横のRequestボタンから依頼しやすくなりました。(The GitHub Blog)

`AGENTS.md`は何のために使うのか

AGENTS.mdは、Copilotに「このリポジトリではどんな観点で作業・レビューしてほしいか」を伝えるためのMarkdownファイルです。今回のCopilot code reviewの更新では、特にリポジトリルートに置いたAGENTS.mdをレビューの文脈として使える点が重要です。(The GitHub Blog)

たとえば、次のような情報を書くと実務で役立ちます。

## Review priorities

- 変更内容が既存のAPI互換性を壊していないか確認してください。
- 例外処理がログ出力だけで終わっていないか確認してください。
- 認証・認可に関わる変更では、権限チェックの抜けを優先して指摘してください。

## Build and test

- Node.js 22を前提にしています。
- 変更後は `npm test` と `npm run lint` の実行を想定しています。
- UIコンポーネントを変更した場合は、アクセシビリティ属性も確認してください。

## Coding conventions

- 関数名は目的が分かる名前にしてください。
- ネストが深くなる場合は早期returnを優先してください。
- 既存のエラーハンドリング方針に合わせてください。

ポイントは、抽象的な「良いコードにしてください」ではなく、レビューで見てほしい観点を具体的に書くことです。GitHub Docsでも、Copilot code review向けのカスタム指示は短く、明確で、具体的な指示にすることが推奨されています。(GitHub Docs)

設定場所で迷ったときの考え方

Copilotの指示ファイルには複数の種類があり、ここで混乱しやすくなります。今回の更新で注目すべきはAGENTS.mdですが、すでに.github/copilot-instructions.mdや.github/instructions/*.instructions.mdを使っている場合は、役割を分けて考えると整理しやすくなります。

ファイル	設置場所	主な役割	向いているケース
`AGENTS.md`	リポジトリルート	Copilot code reviewなどのエージェント向けに、リポジトリの作業・レビュー方針を伝える	まず1つのファイルでチーム標準やレビュー観点を共有したい
`.github/copilot-instructions.md`	`.github`ディレクトリ配下	リポジトリ全体に適用するCopilot向けカスタム指示	Copilot Chatやレビューを含め、広く共通ルールを伝えたい
`.github/instructions/NAME.instructions.md`	`.github/instructions`配下	パスや言語ごとに適用するカスタム指示	Python、React、API、セキュリティなど領域別にルールを分けたい

GitHub Docsでは、リポジトリ全体のカスタム指示は.github/copilot-instructions.md、パス固有の指示は.github/instructions/**/*.instructions.mdに置くと説明されています。また、パス固有の指示ではapplyToを使って対象ファイルを指定できます。(GitHub Docs)

実務では、最初から細かく分けすぎないほうが失敗しにくいです。小規模なリポジトリなら、まずルートのAGENTS.mdにレビュー観点をまとめます。モノレポや複数言語のリポジトリでは、共通方針をAGENTS.mdに置き、言語別・領域別のルールを.github/instructions/*.instructions.mdに分けると管理しやすくなります。

Copilot code reviewの基本的な使い方

Copilot code reviewは、プルリクエストにCopilotをReviewerとして追加して使います。GitHub.comでは、プルリクエストを作成または開き、右側のReviewers欄でCopilotの横にあるRequestをクリックします。レビュー後はCopilotのコメントを確認し、必要に応じて修正します。(GitHub Docs)

手動でレビュー依頼する流れ

手順	操作	確認ポイント
1	`AGENTS.md`をリポジトリルートに追加する	レビュー観点、ビルド手順、禁止パターンを短く具体的に書く
2	`AGENTS.md`をベースブランチに反映する	PRの差分ブランチだけに置いても、期待通り参照されない場合がある
3	プルリクエストを作成する	Draft PRでも早めに確認できる
4	`Reviewers`欄でCopilotの`Request`を押す	Draft PRでもボタンが見つけやすくなった
5	Copilotのコメントを確認する	人間のレビューと同じように返信、解決、非表示ができる
6	修正後に必要なら再レビューを依頼する	自動設定をしていない場合、push後に自動で再レビューされるとは限らない

Copilotがレビュー済みのPRに追加コミットをpushしても、設定によっては自動で再レビューされません。再レビューが必要な場合は、Reviewersメニューから手動で再依頼するか、リポジトリ側で新しいpushもレビューする設定にします。(GitHub Docs)

Draft pull requestでの使い方

今回のUI改善で、Draft pull requestでもCopilotにレビューを依頼しやすくなりました。これにより、人間のレビューを依頼する前に、明らかなミスや規約違反をCopilotで先に洗い出す使い方がしやすくなります。(The GitHub Blog)

Draft PRで特に効果が出やすいのは、次のような場面です。

実装途中で、設計の方向性が大きく外れていないか確認したい
大きなPRを出す前に、分割できる箇所やリスクの高い箇所を見つけたい
新人や外部メンバーのPRで、基本的なコーディング規約違反を先に減らしたい
セキュリティ、例外処理、テスト不足などの観点を早めに洗い出したい

ただし、Draft PRでのレビューは「完成判定」ではありません。まだ設計や実装が変わる段階なので、Copilotの指摘をすべて直すより、重要度の高いものだけを先に処理する運用が向いています。

自動レビューを使うべきか

Copilot code reviewは手動依頼だけでなく、自動レビューとして設定することもできます。GitHub Docsでは、個人設定、リポジトリ単位、組織単位で自動レビューを構成する方法が説明されています。リポジトリ単位では、SettingsからRulesetsを開き、branch rulesでAutomatically request Copilot code reviewを有効にします。(GitHub Docs)

運用	向いているケース	注意点
手動レビュー依頼	まず試したい、重要PRだけレビューしたい	依頼忘れが起きやすい
Draft PRも自動レビュー	早い段階でミスを減らしたい	未完成コードへの指摘が増える
新しいpushもレビュー	修正後の再確認を自動化したい	コメント量が増えやすい
組織単位で自動レビュー	複数リポジトリに標準導入したい	リポジトリごとのルール差を整理してから導入する必要がある

最初は手動レビューから始めるのがおすすめです。コメントの質、ノイズの量、チームの受け入れ方を確認してから、自動レビューやDraft PRレビューを有効にすると失敗しにくくなります。

導入前に確認したい前提条件

Copilot code reviewを導入する前に、機能そのものよりも運用条件を確認しておくことが重要です。

確認項目	見るポイント	理由
Copilot code reviewを使える状態か	個人、組織、Enterpriseの設定や権限	UIにCopilotが表示されない原因になりやすい
リポジトリにファイルを追加できるか	`AGENTS.md`をルートに追加できる権限	指示ファイルを管理できないと運用が定着しない
ベースブランチに指示が入っているか	`main`などPRのマージ先ブランチ	CopilotはPRのベースブランチ側のカスタム指示を使うため
レビューの責任範囲を決めているか	Copilotの指摘を必須扱いにするか、参考扱いにするか	チーム内で判断がぶれやすい
人間のレビュー体制があるか	Approve権限を持つレビュアーの確認	Copilotのレビューは承認の代わりにならない

GitHub Docsでは、Copilot code reviewのレビューはCommentであり、ApproveやRequest changesではないため、必須承認にはカウントされず、マージをブロックするものでもないと説明されています。(GitHub Docs)

`AGENTS.md`に書くと効果が出やすい内容

AGENTS.mdは、長く書けば良いわけではありません。Copilotがレビュー時に使いやすいのは、短く、見出しがあり、判断基準が明確な指示です。GitHub Docsでも、短く焦点を絞った指示、見出しと箇条書きによる整理、具体例の追加が推奨されています。(GitHub Docs)

書くべき内容

内容	例
レビューで優先してほしい観点	認可チェック、例外処理、入力検証、破壊的変更
ビルド・テスト手順	`npm test`、`pytest`、`dotnet test`など
コーディング規約	命名規則、関数の分割方針、禁止構文
セキュリティ観点	秘密情報のハードコード禁止、SQLインジェクション対策
ドキュメント方針	公開API変更時はREADMEや型定義も更新する
既存設計の前提	この層ではDBへ直接アクセスしない、など

書かないほうがよい内容

避けたい内容	理由
「完璧にレビューして」	抽象的でレビュー品質が安定しにくい
外部URLだけを参照させる指示	Copilot code reviewが期待通り外部リンクを参照するとは限らない
秘密情報や内部トークン	リポジトリに残すべきではない
コメント形式を細かく強制する指示	レビュー内容より表示形式に意識が寄りやすい
互いに矛盾する指示	Copilotがどちらを優先すべきか判断しにくい

GitHub Docsでは、Copilot code reviewのカスタム指示では、外部リンクに従わせる指示や、Copilotの中核的な動作を変えるような指示はサポート対象として期待しないほうがよいと説明されています。必要な基準はリンクだけで済ませず、指示ファイル内に要点を書きます。(GitHub Docs)

そのまま使える`AGENTS.md`のひな形

最初は次のような短い構成から始めると運用しやすくなります。

# Repository review guidelines

## Review priorities

- Focus on correctness, security, maintainability, and consistency with existing code.
- Point out changes that may break existing API behavior.
- Flag missing tests when the change affects business logic.

## Build and test

- Use the package manager already used in this repository.
- Run the relevant unit tests before suggesting that the change is complete.
- If a change affects UI behavior, check accessibility and error states.

## Security

- Do not allow hardcoded secrets, API keys, or credentials.
- Check authentication and authorization logic carefully.
- Validate external input before it reaches database queries or command execution.

## Code style

- Prefer simple, readable code over clever implementations.
- Keep functions focused on one responsibility.
- Follow naming and formatting patterns already used in nearby files.

## Documentation

- Update README, API docs, or examples when public behavior changes.

このひな形を入れたら、すぐに全社展開するのではなく、まず1つのDraft PRで試します。Copilotのコメントが多すぎる場合は指示を減らし、逆に観点が不足する場合は具体例を追加します。

迷いやすいポイントと解決策

`AGENTS.md`を置けば自動でレビューされるのか

AGENTS.mdはレビュー時の文脈を与えるファイルであり、それだけでPRレビューが自動実行されるわけではありません。手動でCopilotにレビューを依頼するか、自動レビューのRulesetを設定する必要があります。GitHub Docsでは、初期状態では人間のレビュアーと同じようにCopilotをPRに割り当ててレビューを依頼すると説明されています。(GitHub Docs)

`AGENTS.md`をfeatureブランチに追加したのに反映されない

レビューで参照される指示は、PRのベースブランチ側にあるものが使われます。たとえばfeatureからmainへマージするPRでは、main側の指示が使われます。新しいAGENTS.mdを本格運用したい場合は、先にmainなどのベースブランチへ反映してからレビューを試すのが安全です。(GitHub Docs)

Copilotのコメントは必ず直すべきか

必ずしもすべて直す必要はありません。Copilotはレビュー支援ツールであり、指摘が常に正しいとは限りません。GitHub Docsでも、Copilot code reviewはすべての問題を見つける保証はなく、フィードバックを慎重に検証し、人間のレビューで補う必要があると説明されています。(GitHub Docs)

実務では、Copilotの指摘を次の3段階で扱うと判断しやすくなります。

扱い	対応
セキュリティ、データ破損、互換性破壊	原則として修正または人間が明示的に判断
可読性、命名、軽微な設計改善	チーム方針に合うものだけ採用
誤検知、文脈不足の指摘	コメントで理由を残して解決

Draft PRでコメントが多すぎる

Draft PRは未完成のため、Copilotが当然の未実装箇所にも反応することがあります。コメントが多すぎる場合は、AGENTS.mdに「Draft PRでは重大な欠陥、セキュリティ、テスト不足を優先する」など、レビュー対象を絞る指示を入れると改善しやすくなります。

## Draft PR review policy

- For draft pull requests, prioritize security risks, broken tests, and design issues.
- Avoid commenting on minor formatting issues unless they indicate a broader problem.

PRのConversationタブでCopilotイベントが見つけにくい

今回のUI改善では、Copilot code reviewの一部タイムラインイベントが折りたたまれ、Conversationタブのノイズを減らす方向に変更されています。これはレビューコメントが消えるという意味ではなく、イベント表示がまとまって見やすくなる改善です。(The GitHub Blog)

チーム導入で失敗しやすいパターン

Copilot code reviewの導入でよくある失敗は、機能をオンにすること自体を目的にしてしまうことです。レビュー品質を上げるには、チームの判断基準を先にそろえる必要があります。

失敗パターン	起きる問題	対策
`AGENTS.md`が長すぎる	重要な指示が埋もれる	まず20〜40行程度から始める
抽象的な指示が多い	一般論のコメントが増える	禁止パターンや確認コマンドを書く
自動レビューをいきなり全リポジトリに適用	コメント量が増え、開発者が無視し始める	1〜2リポジトリで検証してから広げる
人間のレビューを省略する	誤検知や見落としに気づけない	Copilotは一次チェックとして扱う
ベースブランチに指示がない	期待したルールが反映されない	先に`main`へ指示ファイルを入れる

特に重要なのは、Copilotのコメントを「守るべきルール」と「参考意見」に分けておくことです。たとえば、セキュリティ、認可、データ整合性に関する指摘は必ず確認し、命名や細かなリファクタリング提案はレビュアー判断にする、といった運用が現実的です。

導入時のおすすめ手順

最初から完璧なAGENTS.mdを作ろうとすると、チーム内の合意に時間がかかります。まずは小さく始め、Copilotのレビュー結果を見ながら調整する進め方が向いています。

最初の1週間でやること

タイミング	やること
初日	既存のレビュー観点を5〜10個に絞って`AGENTS.md`へ書く
2〜3日目	Draft PRまたは小さなPRでCopilot reviewを試す
4〜5日目	コメントが多い項目、少ない項目、誤検知を整理する
週末	`AGENTS.md`を短く修正し、チームのPRテンプレートにも反映する

慣れてきたら追加すること

言語別の指示を.github/instructions/*.instructions.mdに分ける
自動レビューを一部ブランチや一部リポジトリで試す
Draft PRレビューを有効にするか判断する
Copilotの指摘をレビューガイドラインに組み込む
月1回程度、AGENTS.mdの内容を見直す

GitHub Docsでは、リポジトリ単位の自動レビュー設定で、新しいpushをレビューするオプションやDraft PRをレビューするオプションも選べると説明されています。導入初期は、これらをすべて有効にするのではなく、コメント量と開発フローへの影響を見て段階的に広げるのが安全です。(GitHub Docs)

まず何から始めるべきか

Copilot code reviewのAGENTS.md対応は、レビューを完全自動化する機能ではなく、Copilotにチームの前提を伝え、レビューの質を上げるための改善です。最初にやるべきことは、リポジトリルートに短いAGENTS.mdを置き、Draft PRまたは小さなPRでCopilotにレビューを依頼することです。

そのうえで、コメントの質を見ながら指示を調整します。レビュー観点が足りなければ具体例を追加し、コメントが多すぎれば対象を絞ります。自動レビューは便利ですが、最初から全PRに適用するより、チームのレビュー運用に合うことを確認してから広げるほうが定着しやすくなります。

Copilotの指摘は、あくまで人間のレビューを助ける材料です。AGENTS.mdでチームの基準を明文化し、Copilotには一次チェックを任せ、人間は設計判断や仕様の妥当性に集中する。この分担ができると、Copilot code reviewの効果を実務で感じやすくなります。

この記事を書いた人

佐藤健司

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