GitHub Copilot でプロダクト開発用のエージェントチームを作る

本記事では、VS Code の GitHub Copilot カスタマイズ機能を使って、プロダクト開発向けの「役割を持ったエージェントチーム」を作る考え方を整理します。

対象読者は、GitHub Copilot をすでに使っていて、次のような悩みを持っている方です。

企画、実装、テスト、レビューを毎回 1 つの会話でさばくのが重いです
要件整理とコード生成を同じエージェントに任せると出力がぶれやすいです
テスト観点やレビュー観点を毎回書き直すのが面倒です
実装後の動作確認まで含めた開発フローを Copilot 側に持たせたいです

2026年3月時点では、VS Code 側で GitHub Copilot のカスタマイズ機能の整理が進んでいます。対応バージョンやプレビュー機能の有無によって利用できる項目は多少変わりますが、.github 配下を中心に、常時ルール、役割別エージェント、再利用スキルを分離しやすくなっています。

先に結論を書くと、現時点で私が扱いやすいと考える最小構成の一例は次の通りです。

.github/
  copilot-instructions.md
  instructions/
    product.instructions.md
    review.instructions.md
  prompts/
    plan-feature.prompt.md
    run-review.prompt.md
  agents/
    planner.agent.md
    implementer.agent.md
    tester.agent.md
    reviewer.agent.md
    verifier.agent.md
  skills/
    feature-delivery/
      SKILL.md
README.md
AGENTS.md

ただし、最初から全部をそろえる必要はありません。小さく始めるなら .github/copilot-instructions.md と planner / implementer / reviewer の 3 役から始め、あとから tester と verifier を増やす構成でも十分です。

本記事の作成には生成AI（GitHub Copilot / ChatGPT）を使用しています。

1. はじめに
2. 内容
3. まとめ
A. 参考サイト
1. 公式ドキュメント
2. 補助的な外部資料
B. 関連書籍

1. はじめに

この記事で扱うのは、主に VS Code で利用する GitHub Copilot のカスタマイズ機能です。目的は、プロダクト開発の工程ごとに役割を分け、1 つの万能エージェントに全部を背負わせない構成を作ることです。

本記事は、VS Code で GitHub Copilot を利用しており、ワークスペース配下の .github ディレクトリを使って運用できる方向けです。利用できる機能は、VS Code のバージョン、GitHub Copilot の提供状況、Preview 機能の有無によって異なる場合があります。

まず、役割の整理です。

planner: 企画、要件整理、作業分解を担当します
implementer: 実装を担当します
tester: テスト設計とテストコード作成を担当します
reviewer: バグ、回帰、設計上の懸念を点検します
verifier: 実行、動作確認、確認結果の整理を担当します

この分け方にすると、各エージェントの責務がかなり明確になります。たとえば planner には編集をほとんどさせず、implementer には仕様追加ではなく実装に集中させ、reviewer にはコードを書かせずに指摘に専念させる、といった運用がしやすくなります。

なお、custom agents は、記事執筆時点の公式ドキュメントで案内されている機能です。機能名や設定名、Preview 表記の有無は更新されることがあるため、実運用では公式ドキュメントの最新記述を合わせて確認するのがおすすめです。

2. 内容

2-1. なぜ工程ごとにエージェントを分けるのか

プロダクト開発では、同じ「AI に頼む」という行為でも、工程によって期待する振る舞いが違います。

たとえば企画段階では、いきなりコードを書くよりも、目的、対象ユーザー、制約、非機能要件を整理した方が後戻りを減らせます。一方で実装段階では、設計を増やしすぎるより、既存コードの文脈を読んで最小差分で変更した方が価値が出ます。

さらに、テストやレビューは実装と視点が違います。実装担当が「動くコード」に寄りやすいのに対し、テスト担当は「壊れ方」を探し、レビュー担当は「将来の変更で崩れやすい点」を見る必要があります。

つまり、エージェントを分ける主な理由は、次の 3 点です。

出力の目的を工程ごとに固定しやすいです
使わせるツールや編集権限を役割ごとに絞れます
開発フローの handoff を明示しやすいです

Copilot をチームとして使うなら、「何ができるか」よりも先に「誰が何を担当するか」を決める方が運用しやすくなります。

2-2. 5 役に分けると何が整理しやすいか

プロダクト開発向けには、一例として次の 5 役が考えやすいです。

役割	主な責務	向いている出力
planner	目的整理、要件分解、タスク化、リスク洗い出し	仕様案、作業計画、論点整理
implementer	既存コード調査、実装、必要最小限のドキュメント更新	コード変更、設定変更
tester	テスト観点整理、単体テスト・結合テスト案、失敗ケース整理	テストコード、チェックリスト
reviewer	バグ、回帰、設計不整合、未テスト領域の指摘	レビューコメント、改善提案
verifier	実行手順、手動確認、ログ確認、結果の記録	動作確認手順、確認結果まとめ

この構成の利点は、開発プロセスの抜け漏れを見つけやすくなることです。

たとえば implementer がコードを書いたあとに、そのまま完了扱いにすると、テストケース不足や起動確認漏れが起きやすいです。そこで tester と verifier を独立させると、「コードは入ったが品質確認はまだ」という状態を分離できます。

2-3. planner.agent.md は企画と分解に特化させます

planner は最初の入口です。ここでは、コード生成能力よりも、課題の切り分け能力を重視します。

planner に向いている仕事は次の通りです。

機能追加の背景と目的を整理する
対象ユーザーと利用シナリオを定義する
要件を機能要件と非機能要件に分ける
実装前に不明点、依存関係、リスクを洗い出す
実装単位にタスクを分解する

たとえば「通知機能を追加したい」という依頼に対して、planner はいきなりコードに入るのではなく、次のような観点を整えます。

どのイベントで通知するのか
即時通知か、日次集計か
通知失敗時の再送は必要か
管理画面で設定変更できる必要があるか
テストしやすい境界はどこか

この段階で論点を明文化しておくと、implementer と tester が迷いにくくなります。

2-4. implementer.agent.md は最小差分の実装役です

implementer は、既存コードを理解したうえで、必要な変更だけを入れる役です。ここで重要なのは、設計議論を広げすぎないことです。

implementer に持たせたい特徴は次の通りです。

まずコードベースを調べてから編集する
既存スタイルに合わせる
不要なリファクタリングを避ける
変更理由と影響範囲を明確にする
必要なら関連ドキュメントだけ更新する

実装役にありがちな失敗は、依頼範囲を超えて広く直してしまうことです。そこで agent 側の指示として、「根本原因は直すが、関係のない整理はしない」「既存の public API を勝手に変えない」といった制約を入れておくと扱いやすくなります。

2-5. tester.agent.md はテスト観点を増やす役です

tester は、単にテストコードを書く担当ではありません。品質リスクを見つけるために、正常系だけでなく異常系、境界値、依存先障害、入力ゆれを見る役です。

tester に向いている仕事は次の通りです。

追加機能のテスト観点を整理する
単体テストと結合テストの境界を決める
モック化すべき依存を洗い出す
既存テストへの追加箇所を見つける
再現性のある確認手順に落とし込む

たとえば API 追加なら、次のような観点が出せます。

必須パラメータ欠落時のレスポンス
権限不足時のふるまい
タイムアウトや外部 API 失敗時の扱い
同一リクエストの重複送信時の整合性
ログや監視に必要な情報が出るか

実装担当にこの観点まで兼任させると、どうしても抜けが出やすいです。だから tester を独立させる価値があります。

2-6. reviewer.agent.md はバグと回帰を優先します

reviewer は、好みの指摘よりも、動作不良、設計破綻、保守リスクを優先して見る役です。

reviewer に期待したい観点は次の通りです。

仕様と実装がずれていないか
既存利用者への回帰がないか
エラーハンドリングが十分か
テストが変更内容を本当にカバーしているか
命名や責務分離が将来の保守を阻害しないか

ここでは「きれいかどうか」よりも、「壊れるかどうか」を優先します。レビュー専用エージェントを作ると、実装時の前向きなバイアスを少し外しやすくなります。

2-7. verifier.agent.md は最後の動作確認を担当します

verifier は、実装後に実際の実行と確認をまとめる役です。ここがないと、テストは通ったが、起動手順が壊れていた、設定不足で画面が開かなかった、といった問題を見落としやすくなります。

verifier に向いている仕事は次の通りです。

実行コマンドや起動手順を整理する
手動確認項目を順序立てて並べる
ログ、画面、API 応答などの確認結果を記録する
再現できなかった場合は不足前提を明記する
リリース前チェックリストを作る

特に、ローカル起動、開発環境、ステージング環境で差が出るプロダクトでは、この役割があると助かります。自動テストだけで埋めきれない部分を補えるためです。

2-8. handoff を前提にフローを組みます

役割を分けるだけでは足りません。どの順序で流すかを決めておくと、チームとして機能しやすくなります。

基本の流れは次の通りです。

planner -> implementer -> tester -> reviewer -> verifier

この流れの意味は次の通りです。

planner が要件とタスクを固めます
implementer がコード変更を入れます
tester がテストコードや確認観点を追加します
reviewer がバグや回帰の観点で点検します
verifier が実際の動作確認と結果整理を行います

もちろん、案件によっては reviewer の指摘を受けて implementer に戻ることもあります。大事なのは、往復が発生しても「今どの工程にいるか」が明確なことです。

2-9. .github 配下の役割分担はこう考えます

プロダクト開発用の .github 構成を考えると、各ファイルの役割は次のように整理できます。

置き場所	役割	何を書くか
.github/copilot-instructions.md	全体ルール	技術方針、禁止事項、変更方針
.github/instructions/*.instructions.md	条件付きルール	言語別、テスト別、レビュー別の追加条件
.github/prompts/*.prompt.md	定型タスク	機能計画、レビュー依頼、確認依頼
.github/agents/*.agent.md	役割定義	planner などの担当範囲とツール制限
.github/skills/*/SKILL.md	再利用手順	反復する開発ワークフローや参考資料
AGENTS.md	共通運用	複数エージェントに共通の always-on ルール
README.md	人向け説明	セットアップや開発手順

この整理は、tester と verifier の役割がかなり重要になります。コード生成だけでなく、確認工程まで分離した方が実務では扱いやすいケースが多いです。

2-10. まず追加したいファイル

最初に全部そろえなくても構いませんが、私なら次の順序で追加します。

.github/copilot-instructions.md
.github/agents/planner.agent.md
.github/agents/implementer.agent.md
.github/agents/reviewer.agent.md
.github/instructions/review.instructions.md
.github/agents/tester.agent.md
.github/agents/verifier.agent.md

この順序にする理由は、実装前後の意思決定と品質確認を先に固めたいからです。tester と verifier は重要ですが、最初の一歩では planner、implementer、reviewer の 3 役でも効果を出しやすいです。

定型作業が増えてきたら、次のような prompt を追加すると便利です。

/plan-feature: 機能追加の企画と作業分解を行う
/implement-task: 指定タスクの実装を進める
/design-tests: テスト観点とテストコード方針を出す
/review-change: 変更差分をレビューする
/verify-feature: 動作確認の手順と結果を整理する

最初のサンプルとしては、たとえば planner.agent.md に次のような最小方針を書くと始めやすいです。

# planner

- 目的、対象ユーザー、制約を先に整理する
- 実装に入る前に不明点と依存関係を列挙する
- 作業は実装可能な単位まで分解する
- 自分では大きなコード編集を行わず、実装は implementer に引き継ぐ

このように、各ファイルには長い説明を書くよりも、「担当範囲」「やること」「やらないこと」を短く固定する方が保守しやすいです。

2-11. 私ならこう構成します

ここまでは最小構成の話でした。次に、役割を増やした場合の拡張構成例を示します。

プロダクト開発向けに GitHub Copilot のエージェントチームを組むなら、私は次の構成から始めます。

.github/
  copilot-instructions.md
  instructions/
    review.instructions.md
    test.instructions.md
  prompts/
    plan-feature.prompt.md
    review-change.prompt.md
    verify-feature.prompt.md
  agents/
    planner.agent.md
    implementer.agent.md
    tester.agent.md
    reviewer.agent.md
    verifier.agent.md
  skills/
    feature-delivery/
      SKILL.md
README.md
AGENTS.md

feature-delivery のような skill には、次のような内容をまとめておくと再利用しやすいです。

要件整理の観点
実装前チェックリスト
テスト観点のひな形
レビュー時の確認項目
動作確認結果のテンプレート

これを 1 つの skill にまとめておくと、新機能追加のたびに同じ観点を流用しやすくなります。

2-12. 小さく始めて育てるのが現実的です

エージェントチームは、最初から完璧な形にしなくても構いません。むしろ、最初から細かく分けすぎると、どこに何を書くべきかが分かりにくくなります。

実務では、まず 3 役で始め、テスト漏れや動作確認漏れが見えてきた段階で tester と verifier を追加する流れが現実的です。

また、役割分担を作る目的は、AI を増やすこと自体ではありません。人間側が工程を整理し、Copilot に適切な責務だけを渡すことが本質です。ここを外さなければ、少人数の構成でも効果が見込めます。

3. まとめ

GitHub Copilot でプロダクト開発用のエージェントチームを作るときは、まず工程ごとに責務を分けると整理しやすいです。

planner: 企画、要件整理、作業分解
implementer: 実装
tester: テスト観点整理とテスト作成
reviewer: バグ、回帰、設計リスクの確認
verifier: 動作確認と結果整理

そして、.github 配下では、全体ルールを copilot-instructions.md、役割定義を agents、定型作業を prompts、再利用手順を skills に分けると保守しやすくなります。

最初から大きく作る必要はありません。まずは planner、implementer、reviewer の 3 役から始め、必要に応じて tester と verifier を追加する進め方が現実的です。プロダクト開発では、実装だけでなく品質確認と動作確認まで分けて考えることが、Copilot をチームとして使ううえで重要です。

人間が手を加えたのはここから下のみです。
もはや題材さえ渡してしまえば全部やってくれるところまで来てしまいました。