6. Agent Team — 役割分担されたAI開発チーム
なぜAIを1人に任せないのか
1つのAIに、設計・実装・テスト・検査・リリースを全部やらせると、自己チェックになります。
自己チェックは弱いです。
人間の開発組織でも、実装者・レビュワー・QA・リリース担当を分けます。
AIでも同じです。
基本構成
指揮役の役割
指揮役は司令塔です。
重要なのは、自分で実装しないことです。
指揮役がやること:
- 仕様と影響範囲を読む
- 調査すべき依存関係（Required Investigation Set）を出す
- 適切な担当者へ委任する
- 返ってきた証拠を確認する
- 未解決リスクがあれば止める
- 検査を走らせる
- 人間に上げるべき問題を判断する
実装系エージェント
| エージェント | 役割 |
|---|---|
| 実装役 | バックエンド、仕様、計画、実装 |
| フロントエンド担当 | UI、画面実装、デザイン忠実性 |
| テスト作成役 | 単体・統合・契約テスト |
| E2E検証役 | エンドツーエンドテストの検証 |
| バグ修正役 | テスト失敗や検査違反の最小修正 |
| リリース担当 | PR、CI待機、マージ、デプロイ監視 |
検査系エージェント
検査系は原則として読み取り専用です。
実装に介入させないことで、検査の独立性を保ちます。
| エージェント | 見るもの |
|---|---|
| 原則検査役 | 開発方針に反していないか |
| コード検査役 | 重複、型安全、生成コード迂回、DBアクセス階層など |
| テスト検査役 | テストが仕様を本当に検証しているか |
| 要件レビュワー | 仕様の曖昧さ、矛盾、漏れ |
| 設計レビュワー | 設計、データモデル、API境界 |
| 実装レビュワー | 仕様忠実性、変更最小性、回帰リスク |
| 整合性検査役 | Artifact間の意味的矛盾 |
テスト検査の3層チェック
| レベル | 内容 | 例 |
|---|---|---|
| Level 1 | 仕様IDとの紐づきがあるか | テスト名だけに仕様IDがある |
| Level 2 | IDが実在するか | 存在しない仕様を参照 |
| Level 3 | テスト内容が仕様の意味に合うか | 仕様はバリデーション要求なのに存在確認しかしていない |
DSLで定義する意味
各エージェントについて、次をYAMLで定義します。
director:
role_name: 指揮役
dispatch_only: true
can_read_artifacts: [spec, design, plan]
can_write_artifacts: [spec, design]
can_execute_tools: [lint, check, impact-analysis]
can_invoke_agents: [implementer, test-writer, code-auditor]
escalation_criteria:
- condition: same task fails twice
action: stop_and_report
これにより、「誰が何をしてよいか」が明文化されます。
結論
AIエージェントをチームとして設計することで、次が実現できます。