※お役に立てたらストック、いいねをよろしくお願いします！！
＜📝本記事のターゲット層＞
- GitHub Copilot AgentやAI Agentに開発タスクを任せ始めている開発者
- Copilot Agentの成果物が「惜しい」「意図と違う」と感じている人
- Issueやタスクの書き方を改善したいテックリード・開発リーダー
- AI Agentに任せる作業範囲、完了条件、検証方法を整理したい人
- Custom Agentやinstructionsをチーム運用に取り入れたい人
🔷はじめに：“いい感じにやって”は人間にもAIにも難しい
GitHub Copilot AgentのようなAI Agentに作業を任せるとき、つい次のような依頼をしたくなります。
注文一覧画面をいい感じに修正して
気持ちはとても分かります。
自分の頭の中では「こういう方向で直してほしい」が何となく見えているので、短い言葉で伝えたくなります。
ただ、この依頼は新人エンジニアに曖昧なチケットを渡すのとかなり近いです。
- 何を修正するのか
- どこまで触ってよいのか
- 既存仕様を変えてよいのか
- 何をもって完了なのか
- どのテストで確認すればよいのか
- レビューで何を重点的に見てほしいのか
これらが曖昧なままだと、成果物も曖昧になりやすいです。
この記事では、GitHub Copilot Agentにタスクを渡すときの考え方を、Agent向けタスク設計として整理します。
ポイントは、AIに「いい感じにお願いする」のではなく、迷わず作業できる作業ルール・完了条件・検証方法を渡すことです。
🔷GitHub Copilot Agentに任せられる範囲が広がっている
GitHub Docsでは、Copilot cloud agentについて、リポジトリ調査、実装計画の作成、バグ修正、機能追加、テストカバレッジ改善、ドキュメント更新などを行えるものとして説明されています。
さらに、GitHub.com上のagents panelなどから、Copilotにリポジトリ調査、計画作成、ブランチ上でのコード変更を任せ、Pull Request作成前に反復できることも説明されています。
また、GitHub IssuesやVisual Studio Codeなどの入口からPull Request作成を依頼することもできます。
つまり、Agentは単なるコード補完ではありません。
人間が渡したタスクをもとに、リポジトリを読み、計画し、変更し、テストやリンター実行まで行う可能性があります。
だからこそ、タスクの渡し方がとても重要になります。
🔹Agentは「渡されたタスク」をもとに動く
GitHub Docsでは、Copilot cloud agentは与えられたプロンプトに基づいて割り当てられたタスクを評価すると説明されています。
また、GitHub Actionsで動く一時的な開発環境の中で、コード探索、変更、テスト、リンター実行などを行えるとも説明されています。
ここで大事なのは、Agentが高機能になった分だけ、人間側の曖昧な指示もそのまま影響するということです。
人間が「何を守るべきか」「何を変更してはいけないか」「どう確認すべきか」を書かないまま任せると、Agentはリポジトリを読みながら推測します。
推測に頼る部分が増えるほど、「そこは変えてほしくなかった」「そのテストも見てほしかった」というズレが起きやすくなります。
🔷“いい感じにやって”が失敗する理由
「いい感じにやって」が失敗しやすい理由は、Agentの能力不足だけではありません。
多くの場合、タスク設計が足りていません。
曖昧な依頼では、次のような情報が抜けがちです。
🔹1. 目的が曖昧
何のための変更なのかが分からないと、Agentは優先順位を決めにくくなります。
たとえば「注文一覧画面を改善して」だけでは、検索性を上げたいのか、表示速度を改善したいのか、見た目を整えたいのかが分かりません。
🔹2. 対象範囲が曖昧
どの画面、API、ファイル、テストを触ってよいのかが不明だと、変更範囲が広がりすぎることがあります。
Agentに任せるときほど、「ここは対象」「ここは対象外」を書く価値があります。
🔹3. 変更してはいけないことが曖昧
既存仕様を守る必要がある場合は、明示しておくべきです。
- 既存の検索条件は変えない
- ページング仕様は変えない
- CSV出力仕様は変えない
- 注文詳細画面は触らない
このような制約がないと、Agentは「よかれと思って」周辺仕様まで変える可能性があります。
🔹4. 完了条件と検証方法が曖昧
「完了」の定義がないタスクは、人間でも判断が難しいです。
Agentに渡すなら、最低限以下を明確にしましょう。
- 何ができれば完了か
- どの既存挙動が維持されていればよいか
- どのテストを実行すべきか
- 追加すべきテストは何か
- 手動確認が必要なら何を見るか
🔷Agentに渡すタスクはIssueではなく“作業指示書”
Agentに渡すIssueは、単なるお願い文ではなく、作業指示書として書くのがおすすめです。
まずは、以下のテンプレートを使うと整理しやすいです。
## 背景
## やりたいこと
## 対象範囲
## 変更してはいけないこと
## 実装方針
## 受け入れ条件
## 検証方法
## レビューしてほしい観点
それぞれの役割を見ていきます。
🔹背景
なぜこの作業が必要なのかを書きます。
背景があると、Agentが実装上の判断をするときに「何を優先すべきか」を推測しやすくなります。
## 背景
注文一覧画面で、配送状況ごとに注文を確認したいという運用要望がある。
🔹やりたいこと
今回達成したい目的を書きます。
ここは短く、具体的に書きましょう。
## やりたいこと
注文一覧画面の検索条件に「配送ステータス」を追加する。
🔹対象範囲
変更してよい範囲を書きます。
画面、API、型定義、テストなど、Agentが調査・変更してよい領域を明確にします。
## 対象範囲
- 注文一覧画面の検索フォーム
- 注文検索API
- 検索条件の型定義
- 関連するテスト
🔹変更してはいけないこと
対象外や守るべき既存仕様を書きます。
ここはAgent向けタスク設計でかなり重要です。
## 変更してはいけないこと
- 既存の検索条件の挙動
- ページング仕様
- CSV出力仕様
- 注文詳細画面
🔹実装方針
実装の方向性や避けたい実装を書きます。
チームの既存パターンに合わせてほしい場合は、ここで明示します。
## 実装方針
- 既存の検索条件追加パターンに合わせる
- 配送ステータスの選択肢は既存の定義を再利用する
- 新しい独自定数を重複定義しない
🔹受け入れ条件
どの状態になれば完了とみなすかを書きます。
レビューするときの判断基準にもなります。
## 受け入れ条件
- 配送ステータス単体で検索できる
- 既存の検索条件と組み合わせて検索できる
- 未指定の場合は既存と同じ検索結果になる
🔹検証方法
実行すべきテストや確認コマンドを書きます。
コマンドが決まっている場合は、具体的に書くのが一番です。
## 検証方法
- 既存テストを実行する
- 配送ステータス検索のユニットテストを追加する
- 画面から検索条件を指定して結果が絞り込まれることを確認する
プロジェクトでコマンドが決まっているなら、たとえば以下のように書けます。
npm test
npm run lint
※実際のコマンドはリポジトリに合わせてください。
🔹レビューしてほしい観点
人間が特に見たいポイントを書きます。
Agentの成果物をレビューするときにも、そのままチェックリストになります。
## レビューしてほしい観点
- 既存の検索仕様を壊していないか
- 型定義が既存パターンに沿っているか
- テストケースに未指定・単体指定・複合指定が含まれているか
🔷悪い例・良い例で見るタスク設計の差
ここで、曖昧な依頼をAgent向け作業指示書へ変換する流れを図で整理します。
図1: Agentに渡すタスクは「お願い文」ではなく、目的・範囲・完了条件・検証方法まで含む作業指示書として設計する。
重要なのは、図の右側にある項目を全部きれいに埋めることではありません。
Agentが迷いそうな部分を先回りして書くことです。
🔹悪い例
注文一覧画面をいい感じに修正して
この依頼では、次のことが分かりません。
- 何を修正するのか
- どのファイルが対象なのか
- 既存仕様を変えてよいのか
- 何をもって完了なのか
- どのテストを実行すべきなのか
Agentは何とか読み取ろうとしますが、推測が多くなります。
🔹良い例
## 背景
注文一覧画面で、配送状況ごとに注文を確認したいという運用要望がある。
## やりたいこと
注文一覧画面の検索条件に「配送ステータス」を追加する。
## 対象範囲
- 注文一覧画面の検索フォーム
- 注文検索API
- 検索条件の型定義
- 関連するテスト
## 変更してはいけないこと
- 既存の検索条件の挙動
- ページング仕様
- CSV出力仕様
- 注文詳細画面
## 実装方針
- 既存の検索条件追加パターンに合わせる
- 配送ステータスの選択肢は既存の定義を再利用する
- 新しい独自定数を重複定義しない
## 受け入れ条件
- 配送ステータス単体で検索できる
- 既存の検索条件と組み合わせて検索できる
- 未指定の場合は既存と同じ検索結果になる
## 検証方法
- 既存テストを実行する
- 配送ステータス検索のユニットテストを追加する
- 画面から検索条件を指定して結果が絞り込まれることを確認する
## レビューしてほしい観点
- 既存の検索仕様を壊していないか
- 型定義が既存パターンに沿っているか
- テストケースに未指定・単体指定・複合指定が含まれているか
このように書くと、Agentは「何を変えるべきか」と同時に「何を変えてはいけないか」も理解しやすくなります。
レビューする人間にとっても、差分を見る基準が明確になります。
💡Tips：Issue作成支援も“最後は人間がレビューする”
GitHub Docsでは、Copilotが自然言語のプロンプトやスクリーンショットからIssueを作成・更新できる機能も説明されています。
ただし、この機能はpublic previewで変更される可能性があるとされています。
また、CopilotがIssueのタイトル、本文、ラベル、担当者などのドラフトを作れる場合でも、最後は人間が確認・編集してから作成する流れです。
つまり、Issue作成をAIに手伝わせる場合でも、最終的には次の観点で見直すのがおすすめです。
- 目的は明確か
- 対象範囲は十分か
- 変更してはいけないことが書かれているか
- 受け入れ条件はレビュー可能か
- 検証方法は実行可能か
- Agentに任せる範囲が広すぎないか
🔷Custom Agentには“役割ごとの作業ルール”を持たせる
ここまでは、単発のIssueやタスクに何を書くかを見てきました。
次は、繰り返し使うルールをCustom Agent側に持たせる考え方です。
GitHub Docsでは、custom agentsはMarkdownファイルのagent profileで定義できると説明されています。
agent profileでは、prompt、tools、MCP serversなどを指定できます。これにより、チームの規約、利用するフレームワーク、期待する成果物をCopilotに直接持たせられます。
たとえば、次のような役割分担が考えられます。
| Custom Agent | 持たせるルールの例 |
|---|---|
backend-agent |
API、DB、ドメインロジック、既存アーキテクチャの規約 |
frontend-agent |
UI、状態管理、アクセシビリティ、デザインシステム |
review-agent |
差分レビュー、テスト観点、リスク洗い出し |
docs-agent |
README、運用手順、リリースノート、表記ルール |
今回だけの条件はIssueに書き、繰り返し使う役割ルールはCustom Agentに持たせる。
この分担にすると、タスク設計が整理しやすくなります。
図2: 今回だけの条件はIssueへ、繰り返し使う役割ルールはCustom Agentへ分けると、Agent向けタスク設計が整理しやすくなる。
図のように、Issue側には「今回の目的」「対象範囲」「受け入れ条件」を書きます。
一方で、Custom Agent側には「この役割なら常に守ってほしいルール」を持たせます。
🔹毎回書くものと、Agent側に持たせるものを分ける
毎回Issueに書くべきものは、今回だけの条件です。
- 今回の目的
- 対象範囲
- 変更してはいけないこと
- 受け入れ条件
- 検証方法
Custom Agent側に持たせるとよいものは、繰り返し使う役割の前提です。
- 使用するフレームワークの規約
- レイヤーごとの責務
- テスト方針
- レビュー観点
- ドキュメント作成ルール
この分担にすると、Issueが長くなりすぎるのを防ぎながら、Agentに必要な前提を渡しやすくなります。
💡Tips：instructionsは短く、具体的に、例を入れる
GitHub Blogの記事では、Copilot code review向けのinstructions filesについて、短く焦点を絞ること、見出しや箇条書きで構造化すること、直接的なルールにすること、例を示すことが推奨されています。
これはcode review向けの記事なので、cloud agentのタスク設計にそのまま当てはめるものではありません。
ただし、Agentにルールを渡すときの考え方としては参考になります。
特に避けたいのは、次のような指示です。
常に最高品質で実装してください。
いい感じに安全で読みやすくしてください。
プロジェクトに合うようにしてください。
こうした指示は気持ちは分かりますが、具体的な判断基準になりにくいです。
代わりに、次のように書くほうが実用的です。
- 既存の検索条件追加パターンに合わせる
- 新しい独自定数を重複定義しない
- 既存のページング仕様を変更しない
- テストには未指定・単体指定・複合指定のケースを含める
❓困ったときは：Agent向けタスク設計の見直しポイント
▸Agentの成果物が意図とズレる
まず、Issueに「変更してはいけないこと」が書かれているか確認しましょう。
ズレが出るときは、対象範囲よりも非対象が不足していることがあります。
▸変更範囲が広がりすぎる
対象ファイル、対象画面、対象APIを具体的に書きます。
「必要に応じて周辺も修正」だけだと、Agentの判断範囲が広くなります。
▸レビューで何を見ればよいか分からない
Issueに「レビューしてほしい観点」を入れておきましょう。
レビュー観点は、Agentだけでなく人間のレビュー効率にも効きます。
▸テストが足りない
検証方法に「既存テストを実行する」だけでなく、追加してほしいテスト観点を書きます。
たとえば検索条件の追加なら、以下のように書けます。
- 未指定の場合は既存と同じ検索結果になる
- 配送ステータス単体で検索できる
- 既存条件と配送ステータスを組み合わせて検索できる
✅まとめ：Agentに任せるほど“迷わせない力”が重要になる
この記事では、GitHub Copilot Agentに渡すべき作業ルールの作り方を、Agent向けタスク設計として整理しました。
要点を振り返ります。
- 「いい感じにやって」は、人間にもAI Agentにも通じにくい依頼
- Agentに渡すIssueは、お願い文ではなく作業指示書として書く
- 背景、目的、対象範囲、非対象、実装方針、受け入れ条件、検証方法、レビュー観点を整理する
- 今回だけの条件はIssueへ、繰り返し使う役割ルールはCustom Agentへ分ける
- Agentに任せる範囲が広がるほど、人間側のタスク設計力が成果物の品質を左右する
AI Agentの活用で大事なのは、「雑に投げる力」ではありません。
大事なのは、Agentが迷わず動けるようにする迷わせない力です。
次にCopilot Agentへタスクを渡すときは、まずIssueに以下の見出しを入れるところから始めてみてください。
## 背景
## やりたいこと
## 対象範囲
## 変更してはいけないこと
## 実装方針
## 受け入れ条件
## 検証方法
## レビューしてほしい観点
これだけでも、「いい感じにやって」から一歩卒業できます。
🔷参考資料
- About GitHub Copilot cloud agent
- Using GitHub Copilot to create or update issues
- About custom agents - GitHub Docs
- Creating custom agents for Copilot cloud agent
- Unlocking the full power of Copilot code review
※お役に立てたらストック、いいねをよろしくお願いします！！