Claude Codeで"AIスクラムチーム"を構築し、実際にスプリントを実行してみた

Claude Code には「エージェント」「スキル」「Hook」という拡張機能があります。これらを組み合わせると、スクラム開発のチームを丸ごと AI で構成できます。

この記事では、8人のAIエージェントからなる開発チームのテンプレート 「AI Sprint Team」 を紹介します。実際にプロジェクト管理アプリを開発した過程を交えながら、導入から最初のスプリントを回すまでを解説します。

この記事で分かること

• Claude Code のエージェント・スキル・Hook の実践的な使い方
• GitHub Issues ベースのバックログ管理を AI に任せる仕組み
• /implement 42 と打つだけで設計→実装→レビュー→テスト→PR作成まで自動で回る体験
• 個人開発でも「チーム開発の品質」を維持する方法

AI Sprint Team とは

Claude Code のセッション内で /sprint-plan 1 "認証機能" のようにスラッシュコマンドを実行すると、AI エージェントたちがスクラムの各イベントを自動で回してくれる仕組みです。

やることは3つだけです。

1. GitHub Issues にバックログを書く
2. スラッシュコマンドを実行する
3. 出てきた PR を確認してマージする

あとは AI チームが計画・実装・レビュー・テストまでやってくれます。

チーム構成

エージェント	役割
product-owner	バックログの優先順位付け、受け入れ基準の定義
planner	要件分析、タスク分解、実装設計
backend-dev	DB スキーマ設計、API 実装
frontend-dev	UI コンポーネント実装
reviewer	コードレビュー、セキュリティ監査
tester	テスト設計・実装・実行
scrum-master	進行管理、障害検知、Slack 通知
reporter	レポート生成、ドキュメント作成

各エージェントは .claude/agents/ にマークダウンで定義されています。たとえば reviewer には「RLS ポリシーが全テーブルに設定されているか」「any 型が使われていないか」といったチェックリストが書かれており、レビューのたびにそれを機械的に確認します。

スプリントイベントの対応

スクラムイベント	コマンド	何が起きるか
スプリントプランニング	/sprint-plan 1 "ゴール"	ready な Issue を選定 → タスク分解 → マイルストーン作成
デイリースクラム	/standup	GitHub Issues から進捗取得 → Done/Today/Blockers を整理
（実装作業）	/implement 42	設計 → 実装 → レビュー → テスト → PR 作成
（PRレビュー）	/review-pr 15	diff 分析 → セキュリティ・品質チェック → GitHub にコメント
スプリントレビュー	/sprint-review	完了率集計 → レポート生成 → 未完了 Issue を次スプリントに移動
スプリントレトロスペクティブ	/retro	KPT 整理 → CLAUDE.md にルール追記 → git commit

セットアップ

この記事は 2026年3月時点の Claude Code で動作確認しています。エージェント・スキル・Hook の仕様は今後変更される可能性があります。

前提条件

• Claude Code がインストール済み
• GitHub CLI (gh) がインストール・認証済み
• Git リポジトリが初期化済み
• jq がインストール済み（Hook 内で JSON パースに使用）

# Claude Code のインストール（まだの場合）
npm install -g @anthropic-ai/claude-code

# GitHub CLI の認証確認
gh auth status

# jq の確認
jq --version

導入手順

# テンプレートをクローン
git clone https://github.com/nogataka/sprint-team.git
cd sprint-team

既存プロジェクトに導入する場合は、.claude/ ディレクトリと CLAUDE.md をコピーします。

cp -r sprint-team/.claude/ /path/to/your-project/.claude/
cp sprint-team/CLAUDE.md /path/to/your-project/CLAUDE.md

# Hook スクリプトに実行権限を付与
find /path/to/your-project/.claude/hooks -name "*.sh" -exec chmod +x {} \;

プロジェクトに合わせたカスタマイズ

コピー後、以下の2ファイルを自分のプロジェクトに合わせて編集してください。これをやらないとテンプレートのサンプル設定のまま動いてしまいます。

ドメイン知識（.claude/rules/domain/project.md）

プロジェクトの概要、DB スキーマ、ドメイン用語を記述します。エージェントはこのファイルを読んで実装内容を判断します。

CLAUDE.md のビルドコマンド

pnpm test や pnpm lint など、プロジェクトのコマンドに書き換えます。

実践: プロジェクト管理アプリを作る

ここからは、実際にシンプルなプロジェクト管理アプリを AI Sprint Team で開発した過程を紹介します。

まず、人間がやることと AI がやることの分担を整理します。

Step	人間がやること	AI がやること
1. 初期設定	ドメイン知識を書く（最初の1回だけ）	-
2. Issue 作成	やりたいことを1〜2行書く	product-owner が受け入れ基準を補完
3. スプリントプランニング	/sprint-plan を実行する	優先順位付け → タスク分解 → マイルストーン作成
4. 実装	/implement 1 を実行する	設計 → 実装 → レビュー → テスト → PR 作成
5. スプリントレトロスペクティブ	/retro を実行する	KPT 整理 → ルール追記 → git commit

人間が手を動かすのは Step 1 と、各 Step のコマンド入力だけです。

プロジェクト概要

• Next.js 15（App Router）+ TypeScript + Supabase
• 機能: プロジェクト作成、タスクの CRUD、ステータス管理（Todo/In Progress/Done）
• 認証: Supabase Auth

Step 1: ドメイン知識を書く（人間が1回だけやる作業）

唯一、人間がまとまった量を書く作業です。.claude/rules/domain/project.md に、プロジェクトの概要とドメイン用語を記述します。ここに書いた内容が全エージェントの判断基準になるため、最初にしっかり書いておくと後が楽です。

domain/project.md

# ドメイン知識

## ビジネスモデル
チーム向けのシンプルなプロジェクト管理ツール。
個人〜小規模チームが無料で使える。

## ドメイン用語
| 日本語 | コード内の用語 | 説明 |
|-------|--------------|------|
| プロジェクト | project | タスクをまとめる単位 |
| タスク | task | 作業の最小単位 |
| ステータス | status | todo / in_progress / done |

## DB スキーマ（主要テーブル）
```sql
projects (
  id UUID PRIMARY KEY,
  name TEXT NOT NULL,
  owner_id UUID REFERENCES auth.users,
  created_at TIMESTAMPTZ DEFAULT now()
)

tasks (
  id UUID PRIMARY KEY,
  project_id UUID REFERENCES projects,
  title TEXT NOT NULL,
  description TEXT,
  status TEXT CHECK (status IN ('todo', 'in_progress', 'done')),
  assignee_id UUID REFERENCES auth.users,
  created_at TIMESTAMPTZ DEFAULT now()
)
```

DB スキーマを書いておくと、backend-dev がそのままマイグレーションファイルを生成してくれます。逆に書かなければ、planner が Issue の内容からスキーマを設計します。

Step 2: Issue を作る（ざっくり書くだけ）

GitHub Issues にやりたいことを書きます。ポイントは、完璧に書く必要がないことです。タイトルと概要さえあれば、product-owner エージェントが受け入れ基準を補完し、planner がタスクに分解してくれます。

以下のように gh CLI で作ってもいいですし、GitHub の Web UI から作っても構いません。

gh issue create \
  --title "ログイン・サインアップ機能" \
  --body "メールアドレス+パスワードでの認証。未認証ユーザーはダッシュボードに入れないようにする。" \
  --label "ready,enhancement"

gh issue create \
  --title "プロジェクト CRUD" \
  --body "プロジェクトの作成・一覧・削除。自分のプロジェクトのみ表示。" \
  --label "ready,enhancement"

gh issue create \
  --title "タスク CRUD + ステータス変更" \
  --body "プロジェクト内でタスクを管理。Todo → In Progress → Done のステータス変更。" \
  --label "ready,enhancement"

ready ラベルを付けるのだけ忘れないでください。このラベルが「スプリントに投入可能」の目印になります。

Step 3: スプリントプランニング（コマンド1行、あとは AI）

Claude Code を起動して、以下を入力します。

claude
# セッション内で:
/sprint-plan 1 "認証機能とプロジェクトCRUD"

これだけで、以下が全自動で実行されます。

1. ready ラベルの Issue を GitHub から取得
2. product-owner が優先順位を判断（認証 → プロジェクト CRUD → タスク CRUD の順）
3. product-owner が各 Issue に受け入れ基準を追記（Step 2 で書いていなかった場合）
4. planner が各 Issue をタスクに分解
5. タスクリストを Issue の body に自動で追記する
6. マイルストーン Sprint 1 を作成し、Issue に設定する

たとえば、Step 2 で「ログイン・サインアップ機能」とだけ書いた Issue に対して、planner が以下のタスクリストを自動で書き込みます。

## タスク
- [ ] DB: profiles テーブル作成 + RLS ポリシー（backend-dev, 2pt）
- [ ] API: /api/auth/callback Route Handler 作成（backend-dev, 2pt）
- [ ] UI: LoginForm / SignupForm コンポーネント（frontend-dev, 3pt）
- [ ] UI: AuthGuard ミドルウェア実装（frontend-dev, 2pt）
- [ ] Test: 認証フローのユニットテスト（tester, 2pt）

GitHub Issues を開くと、このタスクリストがチェックボックスとして表示されます。実装が進むと自動でチェックが付くので、進捗が一目で分かります。

Step 4: 実装

ここが一番の見どころです。

/implement 1

この1行で、以下が順番に実行されます。

planner が設計する

Issue #1 を読み、影響ファイルと実装順序を決定します。既存のコードベースも確認した上で、どこに何を追加するか具体的に計画します。

backend-dev が実装する

planner の計画に従って、Supabase のマイグレーションファイル、API Route、サーバーサイドのクライアント設定などを実装します。

supabase/migrations/20250401_create_profiles.sql

-- RLS ポリシー付きの profiles テーブル
CREATE TABLE profiles (
  id UUID PRIMARY KEY REFERENCES auth.users,
  display_name TEXT,
  created_at TIMESTAMPTZ DEFAULT now()
);

ALTER TABLE profiles ENABLE ROW LEVEL SECURITY;

CREATE POLICY "profiles_select_own"
  ON profiles FOR SELECT
  USING (auth.uid() = id);

frontend-dev が UI を作る

ログインフォーム、サインアップフォーム、認証ガードを実装します。backend-dev が作った API に合わせて、型安全にフェッチします。

reviewer がレビューする

ここで面白いことが起きました。reviewer が以下の Critical 指摘を出しました。

🔴 Critical: app/api/auth/callback/route.ts:15
  Supabase の createClient() がサーバーサイドで
  anon key を直接使用しています。
  createServerClient() を使用してください。

Critical 指摘があると、自動で実装エージェントに差し戻されます。backend-dev が修正し、再度 reviewer が確認して今度は LGTM が出ました。

人間がレビューする前に、ありがちなミスが自動で拾われます。

tester がテストを書く

tests/unit/lib/auth.test.ts

describe('認証フロー', () => {
  it('未認証ユーザーは /dashboard にアクセスできない', async () => {
    const response = await GET(
      new Request('http://localhost:3000/dashboard')
    )
    expect(response.status).toBe(307) // リダイレクト
  })
})

テストが全て通ったら、Draft PR が自動作成されます。PR の本文には Closes #1 が含まれているため、マージすると Issue が自動クローズされます。

Step 5: 残りの Issue も同様に

/implement 2   # プロジェクト CRUD
/implement 3   # タスク CRUD

同じ流れで2つ目、3つ目の Issue も実装されます。2つ目以降は既存コードの文脈を読んだ上で実装するため、コードの一貫性が保たれます。

Step 6: スプリントレビューとスプリントレトロスペクティブ

/sprint-review

マイルストーン Sprint 1 の完了率が集計され、レポートが docs/sprint-reviews/sprint-1.md に保存されます。未完了の Issue があれば次のスプリントに自動移動されます。

/retro

スプリントレトロスペクティブでは、スプリント中の学びが CLAUDE.md に自動追記されます。たとえば以下のようなルールが追加されました。

### スプリントで学んだルール

- [Sprint 1 - 2025-04-14] Supabase のサーバーサイドクライアントは
  必ず createServerClient() を使う。createClient() はブラウザ専用

次のスプリントからは、全エージェントがこのルールを参照するため、同じミスを最初から避けるようになります。

バックログ管理の仕組み

AI Sprint Team では、GitHub Issues を唯一の正（Source of Truth）として3層でバックログを管理します。

プロダクトバックログ（GitHub Issues, ラベル: backlog → ready）
  └─ スプリントバックログ（マイルストーン: Sprint N）
       └─ タスク（Issue body 内の - [ ] チェックリスト）

なぜ GitHub Issues なのか

独自のファイルやデータベースで管理すると、Claude Code のセッションが終わったときに状態が消えるリスクがあります。GitHub Issues なら外部に永続化されていて、gh CLI で簡単に読み書きできます。

planner がタスク分解した結果は Issue の body にチェックリストとして書き込まれます。

# planner の分解結果を Issue に追記
gh issue edit 1 --body "$(gh issue view 1 --json body -q .body)

## タスク
- [ ] DB: profiles テーブル作成（backend-dev, 2pt）
- [ ] API: 認証コールバック Route（backend-dev, 2pt）
..."

実装が進むと、/implement スキルがチェックボックスを更新します。Issue を開けば、どのタスクが完了しているか一目で分かります。

Hook による安全ガード

AI に実装を任せるとなると、安全性が気になります。AI Sprint Team には6つの Hook が組み込まれており、危険な操作を自動でブロックします。

block-dangerous.sh

以下のコマンドが実行されそうになると、Hook が介入して止めます。

ブロック対象	理由
rm -rf	再帰削除を防止
git push --force	リモート履歴の破壊を防止
git push origin main	main への直接プッシュを防止（PR 経由を強制）
.env の読み書き	シークレット漏洩を防止
sudo	権限昇格を防止

開発中、backend-dev が rm -rf node_modules && pnpm install を実行しようとして Hook にブロックされる場面がありました。rm node_modules に書き換えることで解決しましたが、こうした「うっかり」を仕組みで防げるのは安心感があります。

auto-quality.sh

TypeScript ファイルが編集されるたびに ESLint と Prettier が自動実行されます。node_modules がなければスキップされるので、テンプレートを配置しただけの段階でエラーにはなりません。

カスタマイズのポイント

エージェントの振る舞いを変える

reviewer/AGENT.md のチェックリストに項目を追加すれば、レビュー観点を増やせます。

reviewer/AGENT.md

### 追加チェック項目
- [ ] アクセシビリティ: aria-label が適切に設定されているか
- [ ] パフォーマンス: 画像は next/image を使っているか

ルールを追加する

.claude/rules/ にマークダウンファイルを追加すると、全エージェントがそのルールに従います。コーディング規約、テスト戦略、セキュリティルールなどを自由に定義できます。

Slack 通知

環境変数を1つ設定するだけで、デイリースクラムやスプリント完了の通知が Slack に届くようになります。

export SLACK_WEBHOOK_URL=https://hooks.slack.com/services/T.../B.../xxx

ファイル構成

your-project/
├── CLAUDE.md                         # 組織憲法（ルール・起動順序）
└── .claude/
    ├── sprint-state.md               # スプリント状態のスナップショット
    ├── sprint-log.md                 # エージェント活動ログ
    ├── settings.json                 # 権限設定・Hook 定義
    ├── agents/                       # 8エージェント定義
    │   ├── planner/AGENT.md
    │   ├── product-owner/AGENT.md
    │   ├── backend-dev/AGENT.md
    │   ├── frontend-dev/AGENT.md
    │   ├── reviewer/AGENT.md
    │   ├── tester/AGENT.md
    │   ├── scrum-master/AGENT.md
    │   └── reporter/AGENT.md
    ├── skills/                       # 7つのスラッシュコマンド
    │   ├── sprint-plan/SKILL.md
    │   ├── implement/SKILL.md
    │   ├── standup/SKILL.md
    │   ├── review-pr/SKILL.md
    │   ├── sprint-review/SKILL.md
    │   ├── retro/SKILL.md
    │   └── daily-report/SKILL.md
    ├── hooks/                        # 自動実行スクリプト
    │   ├── pre-tool/block-dangerous.sh
    │   ├── post-tool/auto-quality.sh
    │   ├── post-tool/update-progress.sh
    │   ├── session/on-start.sh
    │   ├── session/on-stop.sh
    │   └── subagent/on-stop.sh
    └── rules/                        # プロジェクトルール
        ├── architecture.md
        ├── code-style.md
        ├── testing.md
        ├── security.md
        └── domain/project.md         # ドメイン知識（要カスタマイズ）

よくある疑問

スプリントの途中で Issue を追加したい

ready ラベルを付けた Issue を作成し、マイルストーンを設定するだけです。

gh issue create --title "緊急バグ修正" \
  --label "bug,ready" \
  --milestone "Sprint 1"

Hook を無効にしたい

.claude/settings.json の hooks セクションから該当エントリを削除してください。

pnpm 以外を使いたい

CLAUDE.md のビルドコマンドと、auto-quality.sh 内の npx コマンドを変更してください。

1人で使う意味はあるか

あります。個人開発でも「reviewer が自動でセキュリティチェックをしてくれる」「tester がテストを書いてくれる」という恩恵は大きいです。実装に集中しながら、品質は AI チームが担保してくれます。

トラブルシューティング

gh auth status でエラーが出る

GitHub CLI が未認証です。gh auth login を実行してブラウザから認証してください。

Hook が動かない

実行権限が付いていない可能性があります。

find .claude/hooks -name "*.sh" -exec chmod +x {} \;

エージェントが期待通りに動かない

.claude/sprint-log.md にエージェントの活動ログが記録されています。どのエージェントがいつ起動・終了したかを確認できます。

cat .claude/sprint-log.md

Issue が大きすぎてコンテキストが足りなくなる

1つの Issue に機能を詰め込みすぎると、Claude Code のコンテキストウィンドウを圧迫します。「1つの Issue = 1つの機能」を目安に、Issue を分割してください。

まとめ

AI Sprint Team は、Claude Code の拡張機能を組み合わせて「AI だけのスクラムチーム」を構成するテンプレートです。

• GitHub Issues に書く → /sprint-plan で計画 → /implement で実装 → PR が出てくる
• reviewer と tester が品質を担保する
• /retro のスプリントレトロスペクティブでチームが学習・進化する
• Hook で危険な操作を自動ブロック

テンプレートはパブリックリポジトリで公開しています。clone して .claude/rules/domain/project.md を自分のプロジェクトに合わせて書き換えれば、すぐに使い始められます。