エージェントチームアーキテクチャ
マルチエージェント協調を実現するための構造パターン。複数のAIエージェントインスタンスが、役割を分担しながら協調してタスクを達成する。
4つのコンポーネント
Team Lead(リーダー)
チームを作成・管理する最初のセッション。役割:
- チームメイトの生成(spawn)
- タスクの作成と割り当て
- 結果の統合と報告
- チームのクリーンアップ
設計上の注意: リーダーが実装作業に入らないよう、調整専用に制限する(Delegate Mode の概念)。リーダーが先走ると、チームメイトの作業との競合が起きる。
Teammates(チームメイト)
独立したエージェントインスタンス。それぞれが自分のコンテキストウィンドウを持つ。
重要な設計判断:リーダーの会話履歴は引き継がない。spawn 時のプロンプトが唯一の初期コンテキスト。必要な情報は明示的に渡す必要がある。
Task List(共有タスクリスト)
全エージェントが参照できる作業管理。状態:pending → in_progress → completed。
- タスク間の依存関係を設定できる
- チームメイトが自己判断でタスクを取得(claim)できる
- リーダーが逐一指示しなくても作業が進む
Mailbox(メッセージング)
エージェント間の直接通信。サブエージェントとの最大の違いがここにある。
- 特定のチームメイトへのメッセージ
- 全チームメイトへのブロードキャスト(コスト高)
有効な使い方
並列コードレビュー: 観点ごとにチームメイトを割り当て(セキュリティ・パフォーマンス・テスト等)、互いの発見を共有させて統合レポートを作る。
競合仮説テスト: 複数の仮説を並列で検証し、「互いの仮説を反証しようとする」という指示で生き残った仮説の信頼性を高める。
サブエージェントとの比較
| 観点 | サブエージェント | チームアーキテクチャ |
|---|---|---|
| 通信 | メインへの報告のみ | エージェント同士が直接通信 |
| 調整 | メインが全て管理 | 共有タスクリストで自己調整 |
| コスト | 低い | 高い(各自が独立インスタンス) |
| 向いている用途 | 結果だけ欲しいタスク | 議論・相互批判が必要なタスク |
落とし穴
- ファイル競合: 担当ファイルを明確に分けることで回避
- リーダーの先走り: Delegate Mode(調整専用ロール化)で制御
- コスト増大: チームサイズに比例してトークン使用量が増加
関連
- マルチエージェント協調 - チームアーキテクチャが実現するパターン
- サブエージェント - より軽量な委譲モデルとの対比
- 競合仮説テスト - チームアーキテクチャが有効な調査手法
- エージェントオーケストレーション - エージェント協調の全体パターン
- Claude Code Agent Teamsによるマルチエージェント協調 - 具体的な実装