GitHub Copilotのカスタムエージェントを活用し、Issue整理からPR作成までの開発フローを複数エージェントで連携（オーケストレーション）してみました。
本記事では、実際の構成例と設計上のポイントを紹介します。
AIオーケストレーションとは
AIオーケストレーションとは、1つのAIに全工程を任せるのではなく、工程ごとに担当のAIエージェントを分け、前工程の成果物を次工程へ渡しながら進める設計です。各エージェントは自分の担当範囲だけに集中し、進行役のオーケストレーターが工程間を橋渡しします。
今回、これをGitHub Copilotのカスタムエージェントで構築しました。
この記事では、実際に作成したオーケストレーターの定義を中心に、構成と設計上の考え方を紹介します。
開発フロー
今回のフローは次のようにしました。
実装計画を作った直後に、別のエージェントが計画をレビューする工程を置きました。
計画を作ったエージェント自身にそのまま見直しを任せると、最初の調査で生じた思い込みをそのまま引き継ぎやすいからです。
別のエージェントに、受け入れ条件、影響範囲、テスト観点を照合させると、実装前に抜けを見つけやすくなります。
ファイル構成
カスタムエージェントの定義は.github/agents/に置きます。
.github/
└── agents/
├── orchestrator.agent.md
├── issue.agent.md
├── plan.agent.md
├── plan-review.agent.md
├── impl.agent.md
├── review.agent.md
└── pr.agent.md
工程間の受け渡しは、チャットの文脈だけに頼らず、Issue番号ごとのファイルとして残します。
docs/development/issues/<issue番号>/
├── plan.md
└── pr-artifacts.md
Orchestratorの定義
以下が実際に使っているorchestrator.agent.mdを少し改変したものです。リポジトリ固有のコーディング規約やレビュー基準は、別途.github/copilot-instructions.mdに置いています。
---
name: Development Orchestrator
description: 'Issueの整理、実装計画の策定、TDDによる実装、コードレビュー、PR作成までを順番に進行するオーケストレーター。'
model: 'GPT-5.6-Sol'
tools: [agent, read, search, todo, web, github_MCPなど]
agents: [issue, plan, plan-review, impl, review, pr]
argument-hint: 'Issue URL、Issue番号、または実装したい内容'
user-invocable: true
---
あなたは開発ワークフロー全体を進行するオーケストレーターです。
自分ではコード・ドキュメント・Issueを直接変更せず、各工程の担当サブエージェントに作業を委譲してください。
成果物はすべて `docs/development/issues/<issue番号>/` 配下のファイルとして残し、
各サブエージェントに前工程の成果物のパスを明示して渡してください。
## 実行順序
1. `issue` に依頼し、対象Issueの内容確認、または新規Issue作成・要件整理を行う
2. `plan` に依頼し、`docs/development/issues/<issue番号>/plan.md` として実装計画を作成する
3. `plan-review` に、作成済みの `plan.md` とIssue内容を渡してレビューを依頼する
- Issueの受け入れ条件との不整合、変更対象ファイルの抜け漏れ、テスト観点の不足、
設計上の選択肢の洗い出し漏れがないかを確認させる
- 問題が見つかった場合は `plan.md` を修正させる（最大2回まで）
- 2回修正しても解消しない、またはIssue自体の解釈に関わる問題はユーザーに確認する
4. 実装計画の「選択の余地がある個所」に、ユーザー判断が必須な項目が残っていないか確認する
- 残っている場合はユーザーへ確認してから次へ進む
5. `impl` に依頼し、計画に基づきTDDで実装・検証する
6. `review` に依頼し、変更内容をレビューする
7. `[blocker]` または `[should]` の指摘があれば、指摘内容を添えて `impl` へ再度依頼する
8. 再修正後、`review` を再実行する（最大3回まで）
9. 指摘が解消したら `pr` に依頼し、ブランチ・コミット・PRの作成、または
`docs/development/issues/<issue番号>/pr-artifacts.md` としてPR成果物案を作成する
## 制約
- 各工程の完了を確認してから次の工程へ進む
- サブエージェントには、Issue番号・関連ドキュメントのパス・対象ブランチ名を必ず明示する
- 実装計画のレビュー・修正のやり取りは最大2回まで、コードレビューと修正のやり取りは最大3回までとし、
解消しない場合はユーザーに判断を仰ぐ
- テストが失敗している状態、または `[blocker]` 指摘が残っている状態でPRを作成しない
- 仕様や設計の判断が必要な場合のみユーザーに確認し、それ以外は自律的に進める
- `.github/copilot-instructions.md` のレビュー基準・コーディング規約を全工程で前提とする
## 進行報告
各工程の完了時に、以下を簡潔に報告してください。
- 完了した工程と成果物のパス
- 次に着手する工程
- ユーザー判断が必要な場合はその内容
agentsには呼び出せるサブエージェントだけを列挙しています。
また、オーケストレーター自身はコードを変更せずに、全体の進行、完了条件の確認、判断が必要な場面での停止に専念させています。
記事を書いていて、オーケストレータ役への指示文章をもっとシンプルにして、impl・reviewなどの実行Agent側にさらに情報を持たせた方がよさそうだなとも思いました。
また、テストの作成と実装を別のエージェントにすることも、考えられます。
サブエージェントの役割
各エージェントの主な責務と、ツールは次のように整理しました。
| エージェント | 主な責務 | 固有のツール・権限 |
|---|---|---|
issue |
Issueの確認、要件整理 | GitHubのIssue操作 |
plan |
既存コードの調査、実装計画の作成 | 読み取り・編集・検索 |
plan-review |
計画の抜け漏れとIssueとの整合確認 | 計画ファイルの編集 |
impl |
テスト追加、実装、検証 | 読み取り・編集・コマンド実行 |
review |
差分レビュー、リスクの指摘 | 読み取り・検索・コマンド実行 |
pr |
PR文面の作成、承認後のPR作成 | GitHubのPR操作 |
計画作成中にコードを変更する必要はないため、planに編集権限は与えていません。実装はimplだけが担当します。
（追記：実装計画を作成する必要があるため、編集権限をつけていました。表は修正済みです。）
一方で、plan-reviewは計画の不整合を見つけたときにはplan.mdを直す必要があるため、編集権限をつけています。ただ、本来はreviewの結果をimplにフィードバックし、直す方がベターではあると思います。
（reviewの結果が反映されすぎてしまうため）
それぞれのAgentについて、責務を分けることでそれぞれのリポジトリ固有のルールを反映でき、再利用性もあがります。また、コンテキストの汚染も防げます。
（内容をSkillsに書いて、Agents.mdから参照させることなども検討）
user-invocableの設定
VS CodeのCopilotでエージェントピッカーに出るのは、user-invocable: trueのエージェントです。今回は、入口をオーケストレーターに絞る目的で、orchestrator.agent.mdだけをtrueにしています。
これは、毎回必ずOrchestratorから始めなければならないということではなく、「計画だけ作成する」「既存の計画をレビューする」と依頼し、担当エージェントを使うこともできます。部分作業を頻繁に行うチームなら、planやreviewをuser-invocable: trueにして、ピッカーに出す運用もあり得ます。
自動化を止める条件を決めておく
オーケストレーションで効くのは、作業の順番だけではありません。どの状態なら先に進ませず、人の判断へ戻すかを先に決めておくことも重要です。
この構成では、未解消の[blocker]指摘がある、テストが失敗している、仕様や設計の判断が必要、といった状態ではPR作成へ進みません。PRの文面作成までは自動で進めても、git pushやPR作成のように共有リポジトリへ影響する操作は、ユーザーの明示的な承認を待つようにしています。
AIに任せる範囲を増やすほど、停止条件を決める価値が上がります。何を自動化するかよりも、どこで人が判断するかを明文化するほうが、実務では効くことが多いです。
このようなオーケストレーションを使うことで、ある程度一気通貫でPR作成までできてしまいますが、計画時点で人間がレビューして手直しすることで、より精度の高い出力が期待できます。