この記事で得られること
- Claude Code Agent Teamの仕組みと使いどころ
- ソロ開発者がAgent Teamを使う具体的なユースケース
- 実際のタスクリスト・チーム構成の実例
- 通常のサブエージェントとの違いと使い分け
前提：1人開発の「壁」
第6回で、Claude Codeを使って22万行のSaaSを1人で開発している話を書いた。AIが「10人分の手」として機能し、仕様策定から実装、テストまでを高速にこなしてくれる。
しかし、Claude Codeを使い込むほど、1つの限界が見えてきた。
Claude Codeは1つのセッションで1つのことしかできない。
人間のチーム開発なら、AさんがAPIを実装している間にBさんがテストを書き、Cさんがコードレビューをする。しかしClaude Codeは1つのセッションで逐次的にしか動かない。PRを5件マージする作業も、1件ずつ順番に処理するしかなかった。
Agent Teamは、この制約を壊す機能だ。
Agent Teamとは何か
Agent Teamは、複数のClaude Codeインスタンスを1つのチームとして協調動作させる機能だ。2026年2月にResearch Previewとしてリリースされた。
通常のClaude Code:
1セッション ──→ 逐次処理
Agent Team:
Team Lead ──→ Teammate A ──→ 並列処理
├→ Teammate B ──→ 並列処理
└→ Teammate C ──→ 並列処理
通常のサブエージェント（Taskツール）との違いは明確だ：
| 特徴 | サブエージェント（Task） | Agent Team |
|---|---|---|
| コミュニケーション | 親に報告するだけ | メンバー間で直接会話できる |
| コンテキスト | 親のコンテキストを共有 | 各自が独立したコンテキストを持つ |
| タスク管理 | なし | 共有タスクリスト（依存関係付き） |
| 人間の介入 | 親経由のみ | 各メンバーに直接指示可能 |
| 用途 | 調査、単発の作業委任 | 複数トラックの並行作業 |
サブエージェントが「部下に仕事を投げて結果を受け取る」なら、Agent Teamは「チームを編成してプロジェクトを回す」感覚に近い。
実例1：PR棚卸しチーム
背景
Saruの開発では、機能実装とCI修正が並行して進むため、PRが溜まりやすい。ある日、以下の状態になっていた：
- マージ待ちPR：5件（リベース必要）
- 古いworktree：12個以上（マージ済みPRのゴミ）
- CI失敗中のPR：2件（原因調査必要）
これを1件ずつ手動で処理すると、丸1日かかる。Agent Teamで一気に片付けた。
タスクリスト
Agent Teamの核は共有タスクリストだ。各タスクには依存関係（blocks/blockedBy）を設定でき、チームメンバーが自律的に次のタスクを拾える。
実際に使ったタスクリストの構造：
| |
ポイントは、各タスクのdescriptionに完了条件を明確に書くこと。「リベースする」ではなく「mainにリベース、CI失敗を調査・修正、プッシュ、レビュー依頼」まで書く。曖昧な指示ではAIは中途半端な仕事をする。
結果
5件のPR処理 + 12個のworktreeクリーンアップが、人間の介入なしで完了した。私がやったのは最初の指示と、最終的なマージボタンを押すことだけ。
実例2：CI安定化マージチーム
背景
第7回で書いたCI安定化の最終段階で、より複雑な依存関係を持つ作業が発生した：
- PR #550（E2E安定化修正）をマージ
- PR #547（サインアップ修正）をマージ（#550のマージ後でないとコンフリクト）
- 7個のPRブランチをmainにリベース（#550と#547のマージ後）
- リベースしたブランチをforce push（リベース完了後）
- 全PRのCI実行を確認（push後）
- worktreeの後片付け（push後）
順序が重要で、しかも1つのミスが連鎖的な問題を起こす。人間がやると「あれ、#547はもうマージしたっけ？」となりがちな作業だ。
チーム構成
| |
依存関係付きタスクリスト
Task 1: Merge PR #550 ── blocks → [2, 3]
Task 2: Merge PR #547 ── blocks → [3], blockedBy → [1]
Task 3: Rebase 7 PR branches ── blocks → [4], blockedBy → [1, 2]
Task 4: Force push all ── blocks → [5, 6], blockedBy → [3]
Task 5: Verify CI triggers ── blockedBy → [4]
Task 6: Clean up worktrees ── blockedBy → [4]
タスク5と6は独立しているため並列実行できる。Agent Teamは依存関係を見て、ブロックが解除されたタスクを自動的に拾う。
このDAG（有向非巡回グラフ）構造が、Agent Teamの最大の武器だ。人間が「次は何をすべきか」を考える必要がない。
実例3：品質検証の多重チェック
Agent Teamとは別に、専門家エージェントをワークフローの各段階で起動するパターンも日常的に使っている。
CLAUDE.mdによるオーケストレーション
Saruでは、CLAUDE.md（Claude Codeへの指示書）に品質検証のワークフローを定義している：
仕様作成 → /qa.verify-spec → 仕様検証
設計計画 → /qa.verify-design → 設計検証
実装完了 → /qa.verify-impl → 実装検証
テスト → /qa.verify-test → テスト検証
各検証ステップで、専門エージェントが自動的に起動する：
| エージェント | 役割 | 起動タイミング |
|---|---|---|
| security-engineer | RLSポリシー、認証・認可のレビュー | 仕様確認、実装検証 |
| backend-architect | API設計、データモデルのレビュー | 設計検証 |
| quality-engineer | テスト網羅性、カバレッジの確認 | テスト検証 |
ソロ開発者にとっての価値
チーム開発なら、コードレビューは同僚がやってくれる。ソロ開発ではそれがない。
「自分で書いて自分でレビュー」は、人間には困難だ。書いた直後のコードは、自分にとって正しく見える。バイアスがかかっている。
専門エージェントは、別の視点を持ち込んでくれる。security-engineerは「この入力は検証されていない」と指摘し、backend-architectは「このAPI設計はRESTの原則に反する」と指摘する。
これはAgent Teamの並列実行とは別の価値だが、「1人なのにチーム」という体験の重要な構成要素だ。
実例4：ブログ記事の公開前チェック
このブログ記事を含め、公開前に複数の検証を並列で実行している：
記事執筆完了
├→ security-engineer: 情報漏洩・セキュリティリスクチェック
├→ Tavily検索: 類似記事の検索（盗作チェック）
└→ Codex: 技術的正確性の確認
これらは互いに依存しないため、サブエージェントとして並列に実行できる。Agent Teamを使うまでもなく、Taskツール（サブエージェント）の並列呼び出しで十分なケースだ。
使い分けの判断基準
実際に使ってみて、以下の判断基準に落ち着いた：
| 条件 | 選択 |
|---|---|
| 独立した調査・分析タスク | サブエージェント（Task） |
| 互いに連携が必要な並行作業 | Agent Team |
| 依存関係のある順序付きタスク群 | Agent Team（タスクリスト活用） |
| 単発の専門レビュー | サブエージェント |
| 大規模なリファクタリング | Agent Team（frontend/backend/test分離） |
迷ったらサブエージェントから始めるのが正解だ。Agent Teamはオーバーヘッドがある（チーム作成、タスクリスト管理、メンバー間のメッセージング）。単純なタスクにAgent Teamを使うと、セットアップの時間がかえって無駄になる。
注意点と限界
1. トークン消費が大きい
Agent Teamは各メンバーが独立したコンテキストを持つため、トークン消費量が通常の数倍になる。3人チームなら概算で3倍。コスト意識は必要だ。
2. コンテキストの分断
Team Leadの会話履歴はメンバーに引き継がれない。メンバーへの初期指示に必要なコンテキストをすべて含める必要がある。「さっきの話の続きで」は通じない。
3. ファイル競合のリスク
複数のメンバーが同じファイルを同時に編集すると競合する。git worktreeで作業ディレクトリを分離するか、担当ファイルを明確に分けるかの対策が必要。Saruではworktreeを必須にしているため、この問題は自然に回避できている。
4. Experimental機能
Agent Teamは2026年2月時点でResearch Previewだ。セッション復元がサポートされていない、タスクのステータス更新を忘れることがある、など粗い部分はある。本番のデプロイパイプラインに組み込むのは時期尚早。
ソロ開発 × Agent Team = ?
第6回で「AIは10人分の手であって、10人分の頭ではない」と書いた。Agent Teamによって、その「手」が並列に動くようになった。
ソロ開発の世界では、Agent Teamはチームメンバーの代替ではなく、作業の並列化ツールとして機能する。
- PRの棚卸しを依存関係付きで自動処理
- 品質検証を複数の視点から同時実行
- CI安定化のような複雑なオペレーションを順序通り実行
「1人チーム」は矛盾した表現に聞こえるかもしれない。しかし実際にやってみると、チーム開発で最も面倒な部分（コミュニケーション、認識合わせ、スケジュール調整）がなく、最も価値のある部分（並列処理、専門レビュー、依存関係管理）だけが残る。
これは、ソロ開発者にとっての理想形かもしれない。
まとめ
| ポイント | 内容 |
|---|---|
| Agent Teamとは | 複数のClaude Codeインスタンスが協調動作する仕組み |
| サブエージェントとの違い | メンバー間の直接通信、共有タスクリスト、独立コンテキスト |
| ソロ開発での活用 | PR棚卸し、CI安定化、品質検証の並列実行 |
| 判断基準 | 連携不要ならTask、依存関係ありならAgent Team |
| 注意点 | トークンコスト増、コンテキスト分断、Experimental |
シリーズ記事
- 第1回: 保守不可能な複雑さに自動化で立ち向かう
- 第2回: CI環境でのWebAuthnテスト自動化
- 第3回: Next.js × Go モノレポアーキテクチャ
- 第4回: PostgreSQL RLSによるマルチテナント分離
- 第5回: マルチポータル認証の落とし穴
- 第6回: Claude Codeで20万行のSaaSを1人で開発している話
- 第7回: セルフホストCI/CDで踏んだ地雷と解決策
- 第8回: Claude Code Agent Teamで「1人チーム開発」を実現する（この記事）