GitHub Copilot の Custom Agent で「AIスクラムチーム」を作って、5人のAIエージェントにスクラム開発させてみた
はじめに
この記事は、@shyamagu さんの「AIエージェントだけでスクラムを回してみた」に大きくインスパイアされて書いています。Shuji さんの記事では、5体の AI エージェントにスクラムチームを組ませ、2時間で1スプリントを駆け抜けるという衝撃的な実験が紹介されています。「AI にスクラムを回させる」というアイデア自体が非常に刺激的で、読んだ瞬間に「自分もやってみたい!」と思いました。本記事は Shuji さんのアプローチをリスペクトしつつ、自分なりのアレンジ(トイ・ストーリーのキャラクター、GitHub Issues 連携、テンプレートリポジトリ化など)を加えた実験記録です。先駆者の素晴らしい記事に感謝します!
GitHub Copilot の Custom Agent(.prompt.md)を使って、スクラムガイド 2020 に準拠した AI スクラムチームを構成し、実際にプロダクト開発を回してみました。
結論から言うと、要件定義からスプリントプランニング、実装、テスト、レビューまでを AI エージェント同士が会話しながら進めるという、かなり面白い体験ができました。
この記事では、仕組みの設計から実際にスプリントを2回回した結果までを紹介します。
リポジトリはテンプレートとして公開しているので、誰でもすぐに試せます。
やりたかったこと
- GitHub Copilot の Custom Agent を 複数のペルソナ(役割) に分割して、チーム開発をシミュレートしたい
- スクラムガイド 2020 に準拠したプロセスを AI に守らせたい
- 「人間は上司役で要件を伝えるだけ」で、あとは AI チームが回す世界観を試したい
チーム構成:トイ・ストーリーのキャラクターたち
AI エージェントにはトイ・ストーリーのキャラクター名を付けました。覚えやすさと、各キャラクターの性格が役割にフィットしたためです。
| 役割 | 名前 | モデル | 性格設定 |
|---|---|---|---|
| 🧑💼 顧客 (Customer) | Jessie | Claude Opus 4.6 | 情熱的でエネルギッシュ。ビジネス価値を最優先に考える |
| 🏃 スクラムマスター (SM) | Woody | Claude Opus 4.6 | 誠実でリーダーシップがある。質問で導くコーチングスタイル |
| 📋 プロダクトオーナー (PO) | Buzz | Claude Opus 4.6 | 戦略的思考。データに基づいた意思決定 |
| 💻 開発者 (Sr.) | Hamm | Claude Opus 4.6 | 堅実で分析的。アーキテクチャと品質にこだわる |
| 💻 開発者 | Rex | GPT-5.3 Codex | 好奇心旺盛。フロントエンドとUI/UX実装が得意 |
ユーザー(自分)の役割は「顧客の上司」 です。要件を Jessie に伝えるだけで、あとはチームが自律的に動きます。
仕組みの構成
ディレクトリ構成
.github/
prompts/ # Custom Agent のプロンプトファイル
customer-jessie.prompt.md
scrum-master-woody.prompt.md
product-owner-buzz.prompt.md
developer-hamm.prompt.md
developer-rex.prompt.md
sprint-planning.prompt.md # スクラムイベント用
daily-standup.prompt.md
sprint-review.prompt.md
sprint-retro.prompt.md
backlog-refinement.prompt.md
copilot-instructions.md # 全体ルール
backlog/
product-backlog.md # プロダクトバックログ(確約: Product Goal)
sprint-backlog.md # スプリントバックログ(確約: Sprint Goal)
docs/
definition-of-done.md # 完了の定義(Increment の確約)
scrum-guide.md
sprints/
sprint-1/
sprint-2/
src/ # 実際のソースコード
Custom Agent の設計ポイント
各エージェントの .prompt.md には以下を定義しています:
- ペルソナ設定(名前、性格、経験年数、得意分野)
- 役割と責任の明確化(スクラムガイドに基づく)
- 発言ルール(必ず名前と役割を名乗る)
- 制約(例: 顧客はコードを書かない、SM は優先順位を決めない)
-
GitHub CLI 連携(
ghコマンドで Issue を操作)
例えば、顧客 Jessie のプロンプトはこんな感じです:
---
description: "顧客 Jessie - ビジネス要件を持つ顧客代表"
mode: agent
tools: ["editFiles", "codebase", "terminal"]
---
# Jessie - 顧客 (Customer)
あなたは **Jessie**、このプロジェクトの **顧客(Customer)** です。
トイ・ストーリーのジェシーのように、情熱的でエネルギッシュな性格です。
## あなたの役割
1. ユーザー(上司)からの要件を受け取り、チームに伝達する
2. ビジネス要件を明確に言語化する
3. ユーザーストーリーの形式で要件を表現する
4. 受け入れ基準(Acceptance Criteria)を定義する
## 制約
- コードは書かない
- 技術的な実装方法には言及しない
- あくまでビジネスの視点で話す
スクラムイベント用のプロンプト
スプリントプランニングなどのスクラムイベントも Custom Agent として定義しています。#sprint-planning を呼ぶと、チーム全員の視点で発言を切り替えながらプランニングを進行してくれます。
#sprint-planning Sprint 1 のプランニングを実施してください
これだけで、Woody (SM) がファシリテートし、Buzz (PO) がゴールを提案し、Hamm と Rex が見積もりとタスク分解をやってくれます。
GitHub Issues との連携
Product Backlog は GitHub Issues で管理します。各エージェントが gh CLI を使って Issue の作成・ラベル付け・クローズを行います。
# Jessie が要件から Issue を作成
gh issue create --title "[Story] 日本全国の動物園を地図上で表示" \
--body "..." --label "scrum:pbi,type:user-story"
# Buzz がリファインメント後にラベル追加
gh issue edit 1 --add-label "scrum:ready,size:5"
ラベル体系もスクラムのワークフローに沿って設計しました:
| ラベル | 用途 |
|---|---|
scrum:pbi |
Product Backlog Item |
scrum:ready |
リファインメント済み |
scrum:in-sprint |
現スプリントで作業中 |
scrum:in-progress |
開発者が着手中 |
scrum:done |
完了の定義 (DoD) を満たした |
size:{1,2,3,5,8} |
ストーリーポイント |
実際に作ったプロダクト:「どうぶつマップ」
AI スクラムチームに作らせたのは、日本全国の動物園情報 Web アプリ「どうぶつマップ」 です。
技術スタック
| レイヤー | 技術 |
|---|---|
| フレームワーク | Next.js 15 (App Router) |
| 言語 | TypeScript |
| スタイリング | Tailwind CSS |
| 地図 | Leaflet (react-leaflet) |
| テスト | Vitest |
| データ | JSON シードデータ (63施設) |
プロダクトゴール
どうぶつマップ は動物好きなユーザーや子どもたちのために、日本全国の動物園情報・写真共有・マイ図鑑を提供する Web アプリである。動物園巡りをもっと楽しく、もっと便利にすることを目指す。
Sprint 1:地図と動物情報
Sprint Goal
ユーザーが日本全国の動物園を地図上で探索し、各動物園の動物情報を確認できるようにする。
選択した PBI
| PBI | タイトル | SP | 担当 |
|---|---|---|---|
| PBI-1 | 日本全国の動物園を地図上で表示・検索できる | 5 | Hamm |
| PBI-4 | 各動物園にいる動物の情報を確認できる | 5 | Rex |
Hamm (Sr. Developer) がやったこと
- Next.js 15 + TypeScript のプロジェクト初期セットアップ
- 全国63動物園のシードデータ作成(7地域に分割管理)
- Leaflet による地図コンポーネント実装
- 動物園検索・地域フィルター
- レスポンシブ対応
Rex (Developer) がやったこと
- 動物データモデル設計
- 動物園詳細ページ(飼育動物一覧)
- 動物名からの逆引き検索
- お気に入り動物登録機能(localStorage)
- 子ども向け表示モード切り替え
Sprint 1 結果
- 10/10 SP 完了 (100%)
- テスト全件パス
- ビルド成功
Sprint 2:マイ図鑑・コミュニティ・ニュース
Sprint Goal
ユーザーが動物園で撮った写真をマイ図鑑として記録し、コミュニティで共有でき、最新ニュースをチェックできるようにする。
選択した PBI
| PBI | タイトル | SP | 担当 |
|---|---|---|---|
| PBI-2 | マイ動物図鑑(写真アップロード・フィルター) | 8 | Hamm |
| PBI-3 | 写真共有・コミュニティ機能 | 8 | Rex |
| PBI-5 | ニュース・イベントカレンダー | 5 | Hamm & Rex |
合計 21 SP(キャパシティ 20 SP を少しストレッチ)
実装された機能
マイ図鑑 (Hamm)
- 写真アップロード(FileReader によるローカルプレビュー)
- localStorage による永続化
- 動物園別フィルタリング、日付順/名前順ソート
- エントリー削除、コンプリート率表示
コミュニティ (Rex)
- いいね機能(
useLikesフック + localStorage) - コメント機能(インカード UI)
- SNS シェア(Twitter/X, LINE, URLコピー)
- 通報機能
- 人気写真ランキング TOP 10(メダル付き)
ニュース (Hamm & Rex)
- お気に入り動物園のニュース優先表示
-
useFavoriteZoosフック - イベントカレンダー表示
Sprint 2 結果
- 21/21 SP 完了 (100%)
- テスト: 5ファイル、22テストケース全件パス
- ビルド成功
やってみてわかったこと
良かった点
1. プロンプト設計でエージェントの「役割分離」が効く
各エージェントに「これはやるな」という制約を入れることで、スクラムの役割分離がちゃんと機能しました。Jessie はコードの話をしないし、Woody は優先順位に口出ししない。
2. スクラムイベントのプロンプトが秀逸
#sprint-planning 一発で、全メンバーの視点を切り替えながらプランニングが進みます。Why → What → How の3トピックが自然に流れるように設計できました。
3. GitHub Issues 連携でトレーサビリティが担保される
PBI が GitHub Issue として管理されるので、コードの変更と要件の紐付けが自然にできます。ラベルでワークフローの状態も可視化できました。
4. テンプレートリポジトリとして再利用可能
Use this template ボタンで新しいプロジェクトを開始し、./scripts/setup.sh でラベルを自動作成。プロダクトを変えてもスクラムの仕組みはそのまま使えます。
課題・改善点
1. コンテキスト長の制約
スプリントが進むとコードベースが大きくなり、エージェントが全体を把握しきれない場面がありました。特にファイル間の依存関係で、既存コードと矛盾する実装をすることがたまにあります。
2. 「本当のスクラム」との違い
スクラムの本質は「経験主義」と「自己組織化」ですが、AI エージェントは与えられたプロンプトの範囲でしか動けません。予期せぬ問題に対する適応力は、まだ人間のチームには及びません。
3. コードレビューの質
Hamm と Rex の「相互レビュー」は DoD に含めていますが、実際には同じセッション内で実装とレビューが行われるため、客観的なレビューとしては限界があります。
4. テストカバレッジ
カスタムフック(useFavorites, useLikes など)のテストは書いてくれましたが、コンポーネントの統合テストや E2E テストまでは至りませんでした。
技術的な Tips
Custom Agent のプロンプト設計
---
description: "説明文"
mode: agent
tools: ["editFiles", "codebase", "terminal"]
---
フロントマター(YAML ヘッダー)で mode: agent を指定すると、ファイルの読み書き・ターミナル実行などのツールが使えるようになります。
複数エージェントを連携させるコツ
-
copilot-instructions.mdでグローバルルールを定義 — 全エージェント共通の情報(チーム構成、ファイル構成、コミュニケーション規約)をここに書く - 各エージェントに「制約」を明記 — 役割を超えた行動を防ぐ
-
共通アーティファクトを定義 —
backlog/product-backlog.mdなど、エージェント間でデータを受け渡すファイルを決めておく - スクラムイベント用のプロンプトで横断的にまとめる — 全員のロールを1つのプロンプトで演じさせる
セットアップの自動化
#!/bin/bash
# setup.sh — GitHub ラベルを自動作成
gh label create "scrum:pbi" --description "Product Backlog Item" --color "0E8A16"
gh label create "scrum:ready" --description "Refined and ready" --color "28A745"
gh label create "scrum:in-sprint" --description "In current Sprint" --color "1D76DB"
# ... 以下省略
まとめ
GitHub Copilot の Custom Agent を使えば、スクラムフレームワークに基づいた AI チーム開発が実現可能です。
2スプリントで以下の成果が出ました:
- 全国63動物園の地図表示・検索
- 動物情報ページ + お気に入り機能
- マイ図鑑(写真アップロード)
- コミュニティ機能(いいね・コメント・シェア・通報・ランキング)
- ニュースフィード + イベントカレンダー
- テスト: 22ケース全パス
- 合計 31 SP を消化
もちろん、本格的なプロダクション運用にはまだ課題がありますが、プロトタイプの高速開発や、スクラムの学習教材としての活用は十分に実用的だと感じました。
テンプレートリポジトリとして公開しているので、ぜひ試してみてください。