Copilot Coding AgentにIssueを任せる前に：instructions・AGENTS.md・PRレビューを整える

このテーマをもう少し広げて見るなら、AGENTS.md標準化の実務影響：AIコーディング指示ファイルをチーム運用に入れる判断基準 と チーム向けAGENTS.mdテンプレート：Codex・Claude Code・Cursorで権限とテスト手順をそろえる も合わせて確認してください。Copilotだけでなく複数agentに効く指示ファイルの扱いを整理できるため。

3行まとめ

Issue

目的、範囲、完了条件を書きます。

Instructions

repo規約とパス別ルールを整えます。

Review

PRは人間が確認してmergeします。

agentに任せる前に、入力と出口を整えます。

• GitHub Copilot coding agentにIssueを任せる前に、Issue本文を「目的、範囲、完了条件、禁止事項、確認コマンド」が入った作業依頼書へ整えます。
• .github/copilot-instructions.md、.github/instructions/*/.instructions.md、AGENTS.md、Issue本文は役割が違います。恒久ルールと今回だけの依頼を混ぜないほうが、agent PRをレビューしやすくなります。
• CopilotがPRを作ることと、そのPRをmergeしてよいことは別です。CODEOWNERS、テスト結果、未検証項目、secretや権限変更の有無を人間が確認します。

本文の事実確認には、GitHub Copilot coding agentの公式Docs、GitHub Copilot custom instructions関連Docs、GitHub ChangelogのAGENTS.md support情報、GitHubのresponsible use関連Docs、VS Codeのcustom instructions関連Docsを使っています。Xで伸びているCopilot agent、Issue assignment、AGENTS.mdまわりの投稿は需要シグナルとして扱い、本文の根拠にはしていません。

この記事でわかること

依頼文

Issueに書くべき情報を決めます。

指示ファイル

copilot-instructions、instructions、AGENTS.mdを分けます。

環境

セットアップと検証コマンドを固定します。

レビュー

PRの確認条件を決めます。

Issue assignmentを、運用できる作業単位に変えます。

• Copilot coding agentへ任せるIssueの書き方
• .github/copilot-instructions.md、.github/instructions/*/.instructions.md、AGENTS.mdの分担
• agentが再現しやすい開発環境と検証コマンドの整え方
• Copilotに任せやすいIssueと、最初は任せないほうがよいIssue
• agent PRのレビュー条件とCODEOWNERSの残し方
• secretや顧客ログをIssueへ混ぜない運用

Copilot coding agentは、Issueや複数の入口から作業を依頼し、変更をPull Requestとして出す流れを作れます。便利ですが、Issueが曖昧なままだと、agentは広い差分を作りやすくなります。

この記事では、Copilotそのものの機能紹介ではなく、チームがIssueを渡してもレビューできるPRとして戻ってくるように、入力、指示ファイル、環境、レビューを分けて整える手順を扱います。

前提知識

項目	内容	見方
Assign to Copilot		Issueや各入口からPR作成を依頼する流れを確認します。
Custom instructions		repo-wideとpath-specificの指示を確認します。
AGENTS.md support		coding agentでのAGENTS.md対応を確認します。
Responsible use		permissions、firewall、レビュー責任を確認します。

導入前に、利用中プランと組織設定も確認します。

GitHub公式Docsでは、Copilot coding agentにIssueなどから作業を依頼し、Pull Requestを作らせる流れが案内されています。利用には対象プランや組織設定が関係します。さらに、GitHub DocsやChangelogでは、Copilot coding agentがAGENTS.md custom instructionsをサポートすること、従来の.github/copilot-instructions.mdや.github/instructions/*/.instructions.mdなども扱うことが説明されています。

GitHub Copilotのcustom instructionsには、repository-wideの指示と、path-specificな指示があります。VS Code側のDocsでも、プロジェクト固有のコーディング標準や作業方針をinstruction fileで渡す考え方が説明されています。

ただし、指示ファイルは万能の安全装置ではありません。GitHubのresponsible use関連Docsでは、permissions、firewall、レビュー責任、生成コードの確認といった運用上の注意も扱われています。Copilot coding agentを使うときは、指示ファイル、GitHub設定、PRレビューをセットで見ます。

agentに任せる前に人間の仕事を減らさない

CopilotにIssueをassignできるようになると、「Issueを渡せば終わる」と考えたくなります。実際には、Issueを作る、作業範囲を決める、完了条件を書く、PRをレビューする、mergeする、という人間側の仕事は残ります。

条件

最初は、docs修正、小さなtest追加、小さいbugfixのように、差分が読みやすく、完了条件を書きやすいIssueから始めます。

注意点

CopilotがPRを作っても、branch protection、required checks、CODEOWNERS、人間reviewerの確認は残します。agent PRを特別扱いせず、むしろ未検証項目を丁寧に見ます。

Issueは作業依頼書として書く

1. 1目的

   何を変えるIssueかを1文で書きます。

2. 2範囲

   触ってよいpathと対象外を分けます。

3. 3完了条件

   テスト、UI確認、受け入れ条件を書きます。

4. 4制約

   禁止操作や人間確認が必要な点を書きます。

曖昧なIssueほど、大きいPRや手戻りにつながります。

Copilot coding agentに任せるIssueは、ただのメモではなく、作業依頼書として書きます。人間なら文脈で補える情報も、agentには明示したほうが安定します。

Issueに最低限入れたいのは、目的、対象範囲、対象外、完了条件、検証コマンド、禁止事項です。

項目	書く内容
目的	何を直す/作るIssueか
対象範囲	触ってよいpath、module、画面
対象外	今回触らない機能、別Issueにする範囲
完了条件	テスト、表示、API応答、受け入れ条件
検証	実行してほしいlint、typecheck、unit test
禁止事項	secret表示、本番変更、不要な依存追加、広いrefactor

Issue本文に背景を書きすぎない

背景は必要ですが、長すぎる背景は作業範囲をぼかします。Copilotに渡すIssueでは、背景、依頼、完了条件を分けます。特に、古い議論、未決定の案、別チームの要望を混ぜすぎないようにします。

完了条件をテストへ落とす

「いい感じに直す」ではなく、「このコマンドが通る」「この画面でこの表示になる」「このAPIでこのstatusを返す」のように、確認できる形にします。

Goal:
ログイン失敗時のエラーメッセージを、フォーム下部に表示する。

Scope:
- frontend/auth/LoginForm.tsx
- frontend/auth/LoginForm.test.tsx

Out of scope:
- APIのエラー仕様変更
- 認証フロー全体のrefactor

Done when:
- npm run test -- LoginForm が通る
- npm run typecheck が通る
- 既存の成功ログイン動作を変えない

今回だけの制約はIssueへ書く

恒久的な規約は指示ファイルへ書きます。今回だけの対象path、今回だけ触らない範囲、今回だけの受け入れ条件はIssueへ書きます。ここを混ぜると、あとで指示ファイルが肥大化します。

instructionsとAGENTS.mdの役割を分ける

項目	内容	見方
repo指示		repo全体のCopilot向け基本方針を書きます。
path別指示		pathや作業種別ごとのルールを書きます。
AGENTS		複数agentに伝える作業契約を書きます。
Issue		今回だけの目的、範囲、完了条件を書きます。

恒久ルールと今回だけの依頼を分けます。

Copilot coding agentを使うチームでは、指示ファイルが増えがちです。.github/copilot-instructions.md、.github/instructions/*/.instructions.md、AGENTS.md、場合によってはCLAUDE.mdやGEMINI.mdもあります。

全部に同じことを書くと、古いルールが残りやすくなります。役割を分けます。

ファイル	向いている内容
.github/copilot-instructions.md	repo全体のCopilot向け基本方針
.github/instructions/*/.instructions.md	path別、言語別、作業種別のルール
AGENTS.md	複数agentに共通で伝えたい作業契約
Issue本文	今回だけの目的、範囲、完了条件
PR template	変更内容、テスト、未検証項目の報告形式

copilot-instructionsには共通方針を書く

repository-wide instructionには、プロジェクトの構成、使うpackage manager、テスト方針、禁止する大きな変更、PR説明の期待値を書きます。毎回変わるIssue固有の内容は書きません。

path-specific instructionsは狭く効かせる

.github/instructions/*/.instructions.mdのようなpath-specific instructionは、frontend、backend、infra、docsなどの領域別ルールに向いています。たとえばfrontendではアクセシビリティとコンポーネント規約、backendではmigrationとAPI互換性のように分けます。

AGENTS.mdは複数agent向けの作業契約にする

GitHub Changelogでは、Copilot coding agentのAGENTS.md custom instructions対応が案内されています。すでにCodexやClaude Codeなど複数agentを使うチームでは、AGENTS.mdを共通の作業契約として置き、Copilot固有の詳細は.github/copilot-instructions.md側へ寄せると管理しやすくなります。

この分担は、チーム向けAGENTS.mdテンプレートで扱った考え方と同じです。AGENTS.mdは期待する動きの共有であり、権限そのものではありません。

開発環境と実行コマンドを先に固定する

Setup

依存関係、package manager、lockfileを明記します。

Test

lint、typecheck、unit、E2Eを分けます。

Env

secretなしで動くfixtureを用意します。

Artifacts

スクショやログの保存先を決めます。

環境が曖昧だと、agentの差分もレビューしにくくなります。

Copilot coding agentにIssueを任せるなら、環境を先に固定します。セットアップが曖昧だと、agentが依存関係やテスト実行で迷い、差分が広がります。

書いておく項目

項目	例
package manager	npm、pnpm、yarn、bunのどれか
install	npm ci、pnpm install --frozen-lockfile
lint	npm run lint
typecheck	npm run typecheck
unit test	npm test -- <対象>
E2E	必要なときだけ、実行条件も明記
fixture	secretなしで動くサンプルデータ
forbidden	本番API、DB migration、deploy、外部POST

secretなしで再現できるようにする

Issueに本番tokenや顧客ログが必要な作業は、最初の対象から外します。必要ならfixture、mock、redacted logを用意します。

失敗したコマンドを報告させる

CopilotがPRを出したとき、実行したコマンド、通ったコマンド、失敗したコマンド、未実行の理由をPR本文に残す運用にします。差分だけでは、レビューしにくいからです。

Copilotに任せるIssueと任せないIssue

項目	内容	見方
任せる		小さなbugfix、テスト追加、docs修正、型修正。
慎重		UI変更、依存更新、複数package横断。
任せない		secret、認証、課金、DB migration、本番運用変更。
分割		大きいIssueは調査、実装、テストに分けます。

最初は成功しやすいIssueではなく、レビューしやすいIssueを選びます。

最初に任せるIssueは、成功しやすいIssueではなく、レビューしやすいIssueを選びます。レビューできないPRが増えると、チームはすぐ使わなくなります。

分類	例	初期方針
任せやすい	docs修正、小さなtest追加、型修正、小さいbugfix	最初の対象
慎重に任せる	UI変更、依存更新、複数package横断	小さく分割して試す
任せない	secret、認証、課金、DB migration、本番運用変更	人間主導
分割する	大きな機能、広いrefactor、設計変更	調査、実装、テストに分ける

Issueを小さく切る

Copilot coding agentに並行で複数Issueを任せるなら、触るpathが重ならないようにします。同じmoduleを複数PRで変更すると、コンフリクトやレビューの順序問題が出ます。

調査Issueと実装Issueを分ける

未知の領域では、いきなり実装させるより、まず調査Issueを作ります。原因候補、影響範囲、修正案、必要なテストを出させ、その後に実装Issueへ進めます。

agentが作ったPRのレビュー条件

差分

Issue範囲外の変更がないか見ます。

テスト

指定コマンドが通ったか確認します。

説明

変更理由と未検証項目があるか見ます。

Owner

CODEOWNERSや担当者承認を残します。

PRが作られたことと、mergeしてよいことは別です。

CopilotがPRを作ったら、通常のPRと同じようにレビューします。むしろ、agent PRでは次の点を明示的に見ます。

確認項目	見ること
Issue範囲	対象外の変更がないか
差分サイズ	不要なrefactorや整形が混ざっていないか
テスト	指定したコマンドが通ったか
未検証	何を実行していないか書かれているか
secret	ログや差分に秘密情報がないか
owner	CODEOWNERSや担当者reviewが残っているか

PR本文を固定する

agent PRの本文には、次の項目を求めます。

• Summary
• Issue scope
• Files changed
• Commands run
• Commands not run
• Risks
• Follow-up needed

これはAIコードレビューをPRに入れる前にで扱った、AIコメントの扱いともつながります。agentが作ったPRでも、最終判断は人間が行います。

mergeは人間が行う

CopilotがPRを作ることと、mergeすることは別です。branch protection、required checks、CODEOWNERS、human approvalは残します。

並行依頼とコンフリクトを避ける

1. 1path

   触る領域が重ならないIssueを選びます。

2. 2branch

   agent PR同士の依存を避けます。

3. 3order

   基盤変更は先に人間が決めます。

4. 4merge

   小さい順に確認して取り込みます。

複数agentより、重ならない作業単位の設計が大事です。

Copilot coding agentの価値は、複数のIssueを並行で進めやすいところにもあります。ただし、並行にすればするほど、作業範囲の設計が重要になります。

pathで分ける

同じファイルや同じmoduleを複数Issueで触らせないようにします。たとえば、frontendの表示修正、backendの型修正、docs更新のように領域を分けます。

基盤変更を先に決める

依存関係更新、formatter変更、ディレクトリ再編、共通component改修のような基盤変更は、他のagent PRより先に人間が方針を決めます。

merge順を決める

小さいPRから確認し、取り込んだ後に次のPRをrebaseまたは再作成します。agent PR同士を放置すると、後で人間がコンフリクト解消を抱えることになります。

セキュリティとsecretをIssueへ書かない

項目	内容	見方
secret		API key、token、cookie、private keyは書きません。
顧客ログ		個人情報や本番データはredactionします。
内部URL		必要最小限にし、公開repoでは避けます。
権限変更		admin設定やdeploy token変更は人間確認にします。

Issueは作業依頼であり、秘密情報の置き場ではありません。

Issueは作業依頼の場所であり、secretの置き場ではありません。Copilot coding agentへ渡る可能性がある情報には、最初からsecretや顧客情報を入れないようにします。

Issueへ入れない情報

• API key、token、cookie、private key
• .envの実値
• 本番DBのdumpや顧客ログ
• 社内VPNや内部管理画面の詳細URL
• deploy tokenやcloud credential
• 認証、課金、顧客データの未加工ログ

redactionした材料を渡す

再現にログが必要なら、値をredactionし、fixture化します。必要な情報は、型、status code、エラー種別、再現手順に絞ります。

権限変更は人間確認にする

GitHub Apps、Actions permissions、branch protection、secret、deploy key、MCP接続の変更は、Copilotに自動で任せる初期対象から外します。提案まではよくても、適用は人間が確認します。

導入初週の進め方

1. 1日目

   指示ファイルとIssueテンプレートを整えます。

2. 2日目

   docs修正や小さなtest追加を任せます。

3. 3日目

   小さなbugfixでPRレビューします。

4. 5日目

   失敗した依頼文を直します。

5. 7日目

   対象Issueと除外Issueを決めます。

最初の目的は、自動化ではなく依頼とレビューの型作りです。

Copilot coding agentをチームに入れるなら、最初の1週間は「何を任せられるか」より「どんなIssueならレビューできるPRになるか」を見ます。

1日目: 指示ファイルとIssueテンプレートを整える

.github/copilot-instructions.mdにrepo共通方針を書き、Issue templateに目的、範囲、完了条件、検証コマンド、対象外を入れます。

2日目: docs修正か小さなtest追加を任せる

最初はコード本体より、docs修正やテスト追加が向いています。差分が読みやすく、完了条件も確認しやすいからです。

3日目: 小さなbugfixを任せる

対象pathを絞った小さなbugfixを任せます。PR本文、差分、実行コマンド、未検証項目が期待通りか見ます。

5日目: 失敗した依頼文を直す

大差分になった、対象外を触った、テストが未実行だった、説明が薄かった、という失敗をIssue templateやinstructionsへ反映します。

7日目: 対象Issueと除外Issueを決める

任せるIssue、慎重に任せるIssue、任せないIssueをチームで決めます。対象範囲を決めてから、並行数を増やします。

失敗時に見直す条件

大差分

Issue範囲が広すぎます。

未検証

テスト指示が曖昧です。

規約違反

instructionsが足りません。

責任不明

reviewerやownerが曖昧です。

失敗はagent性能だけでなく、依頼と環境の問題として見ます。

Copilot coding agentのPRで次の状態が出たら、agent性能だけでなく、Issue、instructions、環境、レビュー条件を見直します。

サイン	よくある原因	見直す場所
大差分になる	Issueの範囲が広い	Issue template
対象外を触る	禁止範囲が曖昧	Issue本文、instructions
テスト未実行	コマンドが不明確	copilot-instructions
規約違反	path別ルール不足	.github/instructions
secret疑い	入力ログが危ない	Issue運用、redaction
レビュー不能	PR本文が薄い	PR template

失敗をテンプレートへ戻す

1回の失敗で終わらせず、Issue template、copilot-instructions、AGENTS.md、PR templateのどこへ反映するか決めます。

指示を増やしすぎない

失敗のたびに長いルールを足すと、指示ファイルが読みにくくなります。まずは、対象範囲、検証コマンド、禁止事項、報告形式の4つに戻して整理します。

FAQ

全Issue

最初から任せません。

AGENTS.md

対応範囲を公式Docsで確認します。

instructions

恒久ルールだけを書きます。

merge

人間reviewを残します。

迷ったら、Issue、指示、環境、レビューへ分けて戻ります。

Copilot coding agentに全Issueを任せてよいですか

最初から全Issueは避けます。docs修正、小さなtest追加、小さいbugfixから始め、差分とレビュー負荷を見て対象を広げます。

AGENTS.mdだけ置けば十分ですか

十分とは言い切れません。Copilotの機能ごとに対応するinstruction形式が変わる場合があります。GitHub公式DocsとChangelogで、利用中のCopilot機能がどの指示ファイルを読むか確認します。

copilot-instructionsには何を書けばよいですか

repo全体に効く方針を書きます。package manager、テストコマンド、PR本文の期待値、禁止する大きな変更、設計上の注意などです。Issue固有の要件はIssue本文へ書きます。

Copilotが作ったPRは自動mergeしてよいですか

自動mergeの前に、人間review、required checks、CODEOWNERSを残します。agentがPRを作ったことと、mergeしてよいことは別です。

secretが必要なIssueはどうしますか

最初の対象から外します。必要ならfixtureやredacted logで再現できる形へ変え、人間が権限やsecretを管理します。

---

次に読むなら

参照した主な情報源

• https://docs.github.com/en/copilot/how-tos/use-copilot-agents/coding-agent/assign-copilot-to-an-issue
• https://docs.github.com/en/enterprise-cloud@latest/copilot/responsible-use-of-github-copilot-features/responsible-use-of-copilot-coding-agent-on-githubcom
• https://docs.github.com/en/copilot/concepts/prompting/response-customization
• https://docs.github.com/en/copilot/how-tos/configure-custom-instructions/add-repository-instructions
• https://github.blog/changelog/2025-08-28-copilot-coding-agent-now-supports-agents-md-custom-instructions/
• https://code.visualstudio.com/docs/copilot/customization/custom-instructions

次に読むなら

更新履歴

1. 2026年5月31日

   GitHub Copilot coding agent、custom instructions、AGENTS.md support、responsible use関連Docsを確認して初版を作成しました。

導入時には最新Docsと組織設定を再確認してください。

• 2026年5月31日: GitHub Copilot coding agent、custom instructions、AGENTS.md support、responsible use関連Docsを確認し、初版を作成しました。