AI

Claude Code エージェントチーム実践ガイド——複数エージェントを束ねるオーケストレーション

Claude Codeのエージェントチーム機能を使い、複数のAIエージェントに役割を分担させて並列開発を実現する方法を解説。20件超のチケットを抱える業務システム開発での実践的な活用法を紹介します。

2026年2月8日
Claude CodeAIエージェントオーケストレーション開発効率化
Claude Code エージェントチーム実践ガイド——複数エージェントを束ねるオーケストレーション

はじめに

業務システムの開発を進めていると、チケットがこんな風に溜まっていきます。

モジュールチケット例
営業管理FAX送信、地図マッピング、承認ワークフロー、電子契約連携...
経理インボイス対応、小口現金、支払一覧、会計ソフト連携、月締め設定...
帳票PDF出力(4種類)、売上計上ロジック、ステータス自動チェック...
在庫管理CTI連携、チャットツール連携...

全部で20件以上。1つずつClaude Codeに実装させると、膨大な時間がかかります。

「これ全部並列でやれないの?」——そう思った方のために、Claude Codeの**エージェントチーム(Agent Teams)**を使って、複数チケットを同時に実装する方法を解説します。

20件を全部同時に並列できる?

先に結論を言うと、20件を一度に全並列するのは現実的ではありません。理由は3つあります。

制約説明
コンテキストの限界各チームメイトが独立したコンテキストウィンドウを持つため、同時に多く起動するとリードの調整負荷が爆発する
チケット間の依存関係「会計ソフト連携」は「自動仕訳生成ロジック」の後でないと実装できない、といった順序がある
コストチームメイト1人あたり単独セッションと同程度のトークンを消費する。10人起動すれば10倍

では、どうするか。モジュール単位でグルーピングして、3〜4件ずつ並列にするのが最も効果的です。

本記事では、この「グルーピング → 並列実装」の流れを、架空の業務システム「KanriPro」のチケットを使ったハンズオンで体験します。

事前準備

エージェントチームを有効化する

~/.claude/settings.json に以下を追加します。

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

または一時的に試すだけなら環境変数でもOKです。

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

ハンズオン 1: 経理モジュールの4チケットを並列実装する

まずは、依存関係が少ない経理モジュールのチケットを4件同時に実装します。

チケットの選定

経理モジュールのチケットから、互いに依存関係がないものを選びます。

KP-101〜104は互いに独立しているので、同時に実装できます。

Claude Codeでの実行

プロジェクトのルートディレクトリでClaude Codeを起動します。

claude

次のプロンプトを入力します。

以下の4つのチケットを、それぞれ別のチームメイトに並列で実装して。

チームメイト1: KP-101 インボイス対応(仕入先マスタ拡張)
- src/app/accounting/suppliers/ にページを作成
- Firestoreの suppliers コレクションに以下のフィールドを追加:
  invoiceNumber(適格請求書発行事業者番号)、taxCategory(課税区分)
- 仕入先の新規登録・編集フォームにフィールドを追加
- 一覧画面にインボイス番号の列を追加

チームメイト2: KP-102 小口現金対応
- src/app/accounting/petty-cash/ にページを作成
- Firestoreに petty_cash コレクションを新規作成
- フィールド: date, description, amount, category, receiptUrl, createdBy
- 入出金の登録フォーム、一覧表示、残高計算を実装

チームメイト3: KP-103 支払一覧画面
- src/app/accounting/payments/ にページを作成
- Firestoreの payments コレクションを参照
- 支払先・金額・期日・ステータスの一覧表示
- ステータスでのフィルタリング(未払い/支払済み/期日超過)
- 日付範囲での絞り込み

チームメイト4: KP-104 月締め設定機能
- src/app/accounting/settings/closing/ にページを作成
- Firestoreに closing_settings コレクションを新規作成
- 締め日(毎月N日)、締め処理の自動実行フラグ
- 設定画面のUIと保存処理

全チームメイトの共通ルール:
- Next.js App Router + TypeScript + Tailwind CSS
- Firestoreは src/lib/firebase.ts の db を使用
- Server Actionで書き込み、Server Componentで読み取り
- 型定義は src/types/ に配置

最後にあなたが4人の成果を統合して、
型の整合性と画面遷移に問題がないか確認して。

何が起きるか

4人が同時に動くため、単純計算で4倍速で完成します。チームリードが最初に共通の型定義とディレクトリ構成を決めてから委譲するので、統合時の手戻りも最小限に抑えられます。

生成されるファイル

src/
├── types/
│   ├── supplier.ts         # インボイス関連の型
│   ├── petty-cash.ts       # 小口現金の型
│   ├── payment.ts          # 支払の型
│   └── closing-settings.ts # 月締め設定の型
└── app/accounting/
    ├── suppliers/
    │   └── page.tsx         # チームメイト1
    ├── petty-cash/
    │   ├── page.tsx         # チームメイト2
    │   └── actions.ts
    ├── payments/
    │   └── page.tsx         # チームメイト3
    └── settings/closing/
        ├── page.tsx         # チームメイト4
        └── actions.ts

ハンズオン 2: 依存関係のあるチケットを段階的に並列実装する

経理モジュールには、先ほどの4チケットに依存するチケットがあります。これらは「先に完了したチケットの成果」を使って実装する必要があるため、バッチを分けて段階的に進めます。

依存関係の整理

KP-105(自動仕訳)とKP-107(総合振込)は並列にできます。KP-106(会計ソフト連携)はKP-105の後に実装します。

Claude Codeでの実行

バッチ1(KP-101〜104)は実装済みです。
次のバッチとして、以下の2チケットを並列で実装して。

チームメイト1: KP-105 自動仕訳生成ロジック
- src/lib/accounting/journal.ts に仕訳生成ロジックを実装
- 小口現金(petty_cash)と仕入先データ(suppliers)を入力にして
  仕訳データ(journal_entries)を自動生成する
- 借方・貸方の勘定科目マッピング
- インボイス対応の税区分(10%/8%/非課税)に基づく消費税計算
- Firestoreの journal_entries コレクションに保存

チームメイト2: KP-107 総合振込データ作成
- src/lib/accounting/bank-transfer.ts に振込データ生成ロジックを実装
- 支払一覧(payments)から未払いデータを取得
- 月締め設定(closing_settings)の締め日に基づいて対象を絞り込み
- 全銀フォーマット(固定長テキスト)でファイル生成
- ダウンロード機能付きの画面を src/app/accounting/transfer/ に作成

この2つが完了したら、その結果を踏まえて
KP-106(会計ソフト連携)の実装方針を教えて。

ポイント: バッチ間のつなぎ方

バッチの切れ目でチームリードが成果物の整合性をチェックするのがコツです。前のバッチで作った型定義やコレクション構造が、次のバッチのチームメイトに正しく伝わっているか確認してから次に進みます。

ハンズオン 3: モジュール横断で並列実装する

慣れてきたら、異なるモジュールのチケットを同時に進めることもできます。モジュールが異なれば依存関係がないことが多いため、並列にしやすいです。

チケットの選定

Claude Codeでの実行

以下の3チケットを、それぞれ別のチームメイトに並列で実装して。
モジュールが異なるので互いに依存関係はありません。

チームメイト1: KP-201 インターネットFAX送信(営業管理モジュール)
- src/app/sales/fax/ にページを作成
- FAX送信先(顧客のFAX番号)の選択UI
- 送信内容のプレビュー画面
- FAX送信APIの呼び出し(外部サービス連携)
- 送信履歴のFirestore保存と一覧表示

チームメイト2: KP-301 CTI連携(在庫管理モジュール)
- src/app/inventory/cti/ にページを作成
- 着信番号から顧客情報をFirestoreで検索して表示
- 通話履歴のFirestore保存
- 着信ポップアップコンポーネント

チームメイト3: KP-401 帳票PDF出力(帳票モジュール)
- src/lib/reports/pdf-generator.ts にPDF生成ロジックを実装
- 4種類のテンプレート: 見積書、請求書、納品書、作業報告書
- Firestoreから対象データを取得してPDFに埋め込み
- ダウンロード機能付きの画面を src/app/reports/export/ に作成

各チームメイトに共通の指示:
- Next.js App Router + TypeScript + Tailwind CSS
- Firestoreは既存の src/lib/firebase.ts を使用

ここが効く: モジュール横断並列のメリット

手法所要時間(目安)トークンコスト
3チケットを順番に実装45〜60分1倍
3チケットをエージェントチームで並列15〜20分3倍

時間を3分の1にできる代わりに、トークンコストは3倍になります。締切が近い場面や、レビュー待ちの間に別チケットを進めたい場面で特に有効です。

20件超を効率的にさばくための全体戦略

ここまでのハンズオンを踏まえて、大量のチケットを実際にさばく全体戦略を整理します。

Step 1: 依存関係マップを作る

まずClaude Codeにチケットの依存関係を分析させます。

以下のチケット一覧を読んで、依存関係マップを作って。
並列実行できるグループ(バッチ)に分けてほしい。

営業管理:
- KP-201: インターネットFAX送信
- KP-202: 地図マッピング(巡回効率化)
- KP-203: 承認ワークフロー(金額/粗利基準のロック)
- KP-204: 有効期限のデフォルト値設定
- KP-205: 過去入力候補の表示
- KP-206: 電子契約サービス連携
- KP-207: 顧客の与信管理API連携

経理:
- KP-101: インボイス対応(仕入先マスタ拡張)
- KP-102: 小口現金対応
- KP-103: 支払一覧画面
- KP-104: 月締め設定機能
- KP-105: 自動仕訳生成ロジック
- KP-106: 会計ソフト連携(API連携全般)
- KP-107: 総合振込データ作成

(以下、帳票・在庫管理モジュールが続く...)

各バッチは3〜4チケットで構成して。

Step 2: バッチ単位で並列実装する

依存関係マップができたら、バッチ単位でエージェントチームに投げます。

Step 3: バッチ間でチームリードにレビューさせる

各バッチの完了後、チームリードに以下を確認させます。

バッチ1の実装が完了しました。
次のバッチに進む前に、以下を確認して。

1. 型定義の整合性: src/types/ 内の型に矛盾がないか
2. Firestoreコレクション設計: 重複や命名の不一致がないか
3. コンポーネント設計: 共通パーツの抽出漏れがないか
4. ビルドエラー: yarn build が通るか

問題があれば修正してから、バッチ2の実行計画を立てて。

カスタムエージェントで品質を担保する

20件以上のチケットを並列で進めると、品質のばらつきが心配になります。そこで、プロジェクト専用のレビューエージェントを作っておくと安心です。

Firestoreレビューエージェント

.claude/agents/firestore-reviewer.md を作成します。

---
name: firestore-reviewer
description: Firestoreのデータ設計・クエリ・セキュリティをレビューする。Firestore関連の実装後に使用する。
tools: Read, Grep, Glob, Bash
model: sonnet
---

あなたはFirestoreの設計に精通した専門レビュアーです。

## チェック項目

### データ設計
- コレクション・ドキュメント構造は適切か
- ドキュメントサイズが1MB制限を超えないか
- 非正規化が適切に行われているか

### クエリ効率
- 不要な全件取得をしていないか
- 複合インデックスが必要なクエリがないか
- ページネーション(limit + startAfter)を使っているか

### セキュリティ
- セキュリティルールが設定されているか
- Admin SDKとClient SDKを混同していないか
- 機密データをクライアントに露出していないか

## 報告フォーマット

**[重大度] 問題名**
- ファイル: パス:行番号
- 問題: 何が問題か
- 修正案: 具体的なコード例

各バッチ完了後のレビュー実行

firestore-reviewer を使って、
バッチ1で作成された以下のファイルをレビューして。

- src/app/accounting/suppliers/
- src/app/accounting/petty-cash/
- src/app/accounting/payments/
- src/app/accounting/settings/closing/
- src/types/ 内の新規型定義

知っておくと便利なTips

キーボードショートカット

ショートカット動作
Shift + ↑/↓チームメイトの選択を切り替え
Ctrl + Tタスクリストを表示
Ctrl + B現在のタスクをバックグラウンドに移動
Escape現在の操作を中断

tmuxモードで見やすくする

チームメイトが4人いると出力が混在します。tmuxモードで各チームメイトを別ペインに表示しましょう。

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1",
    "CLAUDE_CODE_AGENT_TEAMS_DISPLAY": "tmux"
  }
}

コストの目安

バッチ構成チームメイト数トークンコスト所要時間(目安)
1チケットずつ順番01倍15分 × 20件 = 約5時間
3〜4件ずつ並列3〜43〜4倍/バッチ15分 × 6バッチ = 約1.5時間

トークンコストは増えますが、開発時間を約3分の1に短縮できます。

サブエージェントとの使い分け

比較項目サブエージェントエージェントチーム
コンテキストメインセッション内で動作各エージェントが独立
通信メインに結果を返すのみエージェント間で直接通信可能
適した場面1チケットの調査・レビュー複数チケットの並列実装

迷ったら「実装はエージェントチーム、レビューはサブエージェント」と覚えておくとシンプルです。

まとめ

大量のチケットを効率的にさばくための戦略を整理します。

ステップやること
1. 依存関係の分析チケット間の依存を洗い出し、バッチに分ける
2. バッチ単位で並列実装3〜4チケットをエージェントチームで同時実装
3. バッチ間レビュー型の整合性・コレクション設計・ビルド確認
4. カスタムエージェントで品質担保Firestore/Next.js専門レビュアーで自動チェック

エージェントチームは「全部を一度に並列」ではなく、**「依存関係を見極めて、適切な粒度で並列」**にするのがコツです。20件超のチケットも、6〜7バッチに分ければ約1.5時間で完了します。

まずは自分のプロジェクトのチケット一覧を見て、「依存関係がなくて同時にやれるのはどれだろう?」と考えるところから始めてみてください。


参考リンク: