
Claude Code のエージェントチーム機能を試してみた
AI事業本部/西日本開発チームの片桐です。
これまで Claude Code のセットアップやサブエージェント機能についてご紹介してきました。
今回は、AI駆動開発をさらに効率化する エージェントチーム 機能についてご紹介します。
この記事について
[対象読者]
- Claude Code を使っている方
- AI駆動開発をさらに効率化したい方
🪧 セットアップ手順のみを確認したい方は 「ここから」 進んでください。
エージェントチームとは
エージェントチーム は、複数の独立した Claude Code エージェントが 同時に並列で動作 し、共有のタスクリストを通じて自律的に連携する機能です。
エージェントチームが必要な理由
単一エージェントとの根本的な違い
単一エージェント(サブエージェント機能など)でタスクを実行する方法と比較して、
「エージェントチーム」は異なるアプローチになります。
まずは、この2つの違いを解説します。
■ 単一エージェントの特徴
- 1つのセッション内で実行[1]
- メインエージェントにのみ結果を報告
- メインエージェントがすべての作業を管理・統制
■ エージェントチームの特徴
- メインセッション(リーダー)がチームを調整し、メンバーが自律的にタスクを実行
- 複数の独立したセッションとして動作
- チームメンバー同士が直接連携できる
- 共有タスクリストで自己調整
使い分けイメージ
【単一エージェントが向いている場面】
- 「Aの結果を踏まえてBを実行」のように順序が決まっている
- 結果をまとめるのはメインで、各タスクの独立度が低い
- コスト効率を最優先にしたい
【エージェントチームが向いている場面】
- 複数の調査や検証が並列で進められる
- メンバー同士の議論や検証が必要
- 作業の順序が柔軟で、メンバーを自律的に動かしたい
なぜ「チーム」が必要なのか
単一のAIエージェントで複雑なタスクに取り組む場合、最初の仮説に固執しやすいという課題があります。
「バグの原因を調査して」という指示を出した場合で比べてみます。
【単一エージェント】
最初の仮説「原因は 接続タイムアウト が原因では?」と判断
→ タイムアウト に関連する部分を中心に調査
→ タイムアウト と関連する証拠を重視しやすくなる
→ 本当の原因を見落とす可能性が高い
【エージェントチーム】
メンバーA「接続タイムアウトが原因では?」
メンバーB「でも、それなら別の症状も出るはず。メモリリークでは?」
メンバーC「待て。ファイルハンドルのリークの可能性も確認しよう」
→ 複数の仮説を同時に並列調査できる
→ より客観的に本当の原因に辿り着ける
これが複数のメンバーが異なる視点で検証できる エージェントチーム の力です。
1つの仮説に縛られず、より多角的で客観的な結論に辿り着けます。
実装選択のポイント
単一エージェント と エージェントチームを選ぶ際の主な違いは、以下の通りです。
| 観点 | 単一エージェント | エージェントチーム |
|---|---|---|
| コンテキストウィンドウ [2] | サブエージェントごとに独立(結果はメインへ返却) | リーダー + 複数メンバー(メンバーごとに独立したコンテキスト) |
| メンバー間通信 | ✖ できない | ⭕️ 直接通信可能 |
| 調整方式 | メインが統制 | 共有タスクで自己調整 |
| トークンコスト | 低い | 高い(各メンバーがそれぞれのコンテキストウィンドウを持つため) |
| 利用例 | 結果・目標が明らかな場面 | 議論・検証が必要な場面 |
エージェントチームの有効化
ステップ1:バージョン確認
まずは、Claude Code のバージョンが v2.1.32 以上 であることを確認します。
claude --version
実行結果:
Claude Code 2.1.84 (native)
ステップ2:settings.json で有効化
~/.claude/settings.json に以下を追加します。
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
既に settings.json がある場合
既存の設定を保持しながら、env ブロックに追加してください。
私の設定例
{
"cleanupPeriodDays": 14,
"model": "haiku",
"env": {
"DISABLE_NON_ESSENTIAL_MODEL_CALLS": "1",
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1",
"EDITOR": "nvim",
"VISUAL": "nvim"
},
"hooks": {
"Stop": [
{
"hooks": [
{
"type": "command",
"command": "osascript -e 'display notification \"作業が完了しました\" with title \"Claude Code\"'"
}
]
}
]
},
"statusLine": {
"type": "command",
"command": "bash ~/.claude/statusline-command.sh"
},
"language": "japanese",
"spinnerTipsEnabled": false,
"autoUpdatesChannel": "stable",
"showTurnDuration": true
}
ステップ3:設定の確認
設定が正しく反映されたことを確認するためには、 Claude Code を起動してエージェントチームの作成を指示してください。
正常に起動すれば有効化されています。
claude
テスト用のエージェントチームを作成してください。
1. エージェント1
2. エージェント2
正常にチームが作成されれば、設定は正しく反映されています。

表示モード:チームの進捗確認方法
エージェントチームには、2つの表示モードがあります。
1. In-process モード(デフォルト)
すべてのチームメンバーがメインターミナル内で実行されます。
使うタイミング:
- すぐにエージェントチームを使用したい
- VS Code などの統合ターミナルで動かしたい
操作方法:
Shift+Down:チームメンバーの切替Enter:現在のメンバーのセッションを表示Escape:ターンを中断Ctrl+T:タスクリストの表示を切替
2. 分割ペインモード
複数のウィンドウに各チームメンバーを表示し、すべてのメンバーの進捗が同時に見えるモードです。

使うタイミング:
- 複数メンバーの進捗を同時監視したい
- チームメンバーの議論をリアルタイムで見たい
必要な環境:
- tmux または iTerm2(
it2CLI導入済み) がインストールされている - tmux の場合は tmux セッション内で Claude Code を実行している
チームメンバーとのやり取り
エージェントチームでは、私たちがリーダーに指示を出すことで、リーダーがチームメンバーを調整・管理する仕組みになっています。
リーダーの役割
私たちからの指示に応じて、リーダー(Claude Code メインセッション)が以下を行います:
- タスク割り当て:チームメンバーに何をするかを指示
- 進捗監視:各メンバーが正しく動いているか確認
- 調整・ナッジ:立ち往生したメンバーを指示しなおす
- 結果統合:各メンバーの成果をまとめる
チームメンバーへの直接指示
チームメンバーが正常に動作していない場合、以下のように直接指示を活用して制御します。
@security-reviewer: セッションタイムアウトの脆弱性についても確認してください。
チームメンバーをシャットダウンする
チームが不必要になったら、リーダーへクリーンアップするように指示を出します。
チームを削除してください。

エージェントチームを使ってみる
Claude Code セッション内で、以下の例を参考に
プロンプトを作成して実行するとエージェントチームが起動します。
新しい機能を実装するチームを作成してください。
以下の3人で構成してください:
1. フロントエンド実装担当
2. バックエンド実装担当
3. テスト実装担当
各メンバーが並列に作業を進めながら、必要に応じて相互に確認してください。
各チームメンバーが並列に実行され、リーダーがタスク調整を行います。
実際にエージェントチームを試した結果
以下は、実際に users.py をレビューするチームを作成したときの実行例です。
3つのタスクが自動的に生成され、各専門家メンバーに割り当てられているのが分かります。
エージェントチーム実行時の出力
出力結果が長いため、一部省略しています。
❯ @tmp/users.py をレビューするチームを作成してください。セキュリティ、パフォーマンス、テストカバレッジの専門家を用意して。
⎿ Read tmp/users.py (41 lines)
⏺ tmp/users.pyをセキュリティ、パフォーマンス、テストカバレッジの観点からレビューするチームを作成します。
**計画**
3人の専門家エージェントを持つチームを作成し、以下を実施します:
1. セキュリティレビュー担当: パスワード管理、入力検証、ファイル操作の脆弱性をチェック
2. パフォーマンスレビュー担当: 検索ロジック、リソース管理、効率性を分析
3. テストカバレッジ担当: テストの必要性と品質基準を評価
各エージェントがusers.pyを分析し、レポートを作成します。
⏺ 次に、3人の専門家エージェントをチームに招待します。
⏺ 3 background agents launched (↓ to manage)
├─ @security-expert (code-reviewer)
├─ @performance-expert (code-reviewer)
└─ @test-expert (code-reviewer)
⏺ チーム構成完了です!✓
users-py-reviewチーム が立ち上がりました:
| 専門家 | 担当タスク |
|---|---|
| 🔒 security-expert | セキュリティ脆弱性をレビュー (Task #1) |
| ⚡ performance-expert | パフォーマンスを分析 (Task #2) |
| 🧪 test-expert | テストカバレッジを評価 (Task #3) |
3人の専門家が並列でusers.pyを分析しています。
...[各メンバーが並列で分析を進める]...
これで3人の専門家の分析が全て揃いました。統合レビューレポートを作成します。
---
**users.py 総合レビューレポート**
📋 **Executive Summary**
users.pyは複数の重大な脆弱性を抱えており、即座の改善が必須です。セキュリティ、パフォーマンス、テストカバレッジの3観点から、段階的な改善ロードマップを提案します。
---
🔒 **セキュリティ評価:CRITICAL(5つの脆弱性)**
P0 - 緊急対応必須
| # | 脆弱性 | 現状 | リスク | 改善案 |
|---|---|---|---|---|
| 1 | ハードコードされたパスワード | "admin1234"がコードに露出 | 認証情報漏洩 | 環境変数で管理 |
| 2 | 入力値バリデーション完全欠落 | ID・年齢・名前チェックなし | データ破損、インジェクション | 型検査と範囲検証実装 |
| 3 | KeyErrorハンドリング欠落 | 存在しないID呼び出しでクラッシュ | DoS攻撃 | try-except実装 |
| 4 | ファイルリソースリーク | close()なし、ディレクトリトラバーサル対策なし | ファイルディスクリプタ枯渇 | with文導入 |
| 5 | データ改変可能性 | get_all_users()が内部状態を直接参照 | 意図しないデータ変更 | コピー返却 |
---
⚡ **パフォーマンス評価:要改善(3.3倍高速化可能)**
**計算量分析**
search_users()の現状: O(n × m)
- n = ユーザー数
- m = ユーザー名平均長
**ベンチマーク結果:**
| ユーザー数 | 現状 | 改善後 | 倍率 |
|---|---|---|---|
| 1,000 | 100μs | 50μs | 2倍 |
| 10,000 | 1ms | 300μs | 3.3倍 |
| 100,000 | 10ms | 3ms | 3.3倍 |
| 1,000,000 | 1秒 | 300ms | 3.3倍 |
**改善案(優先度順)**
| Phase | 内容 | 実装時間 | 効果 |
|---|---|---|---|
| P0 | with文によるファイルI/O修正 | 5分 | リソースリーク排除 |
| P1 | search()のキャッシング実装 | 1時間 | 3.3倍高速化 |
| P2 | インデックス化(本格実装) | 4時間 | メモリ最適化 |
---
🧪 **テスト評価:ZERO COVERAGE → 70%を目標**
**現状**
- テストファイル:存在しない
- カバレッジ:0%
- 必須実装:Phase 1で5個テスト
**Phase 1(即座 - 70%目標)**
最優先の5つのテストケース:
```python
import pytest
from users import UserManager
def test_add_user_valid():
"""ユーザー追加の正常動作"""
...[テスト値が記載]...
def test_get_user_not_found():
"""存在しないユーザー取得時のエラーハンドリング"""
...[テスト値が記載]...
def test_delete_user():
"""ユーザー削除機能"""
...[テスト値が記載]...
def test_save_and_load_users():
"""ファイル保存・読み込みの統合テスト"""
...[テスト値が記載]...
def test_search_users_partial_match():
"""検索機能の正常動作"""
...[テスト値が記載]...
テスト実装ロードマップ
┌─────┬──────┬────────┬─────────┬─────────────────┐
│ Pha │ 期限 │ テスト │ カバレ │ タスク │
│ se │ │ 数 │ ッジ │ │
├─────┼──────┼────────┼─────────┼─────────────────┤
│ Pha │ 本日 │ │ │ │
│ se │ 中 │ 5個 │ 70% │ 基本機能テスト │
│ 1 │ │ │ │ │
├─────┼──────┼────────┼─────────┼─────────────────┤
│ Pha │ 1週 │ │ │ エッジケース追 │
│ se │ 間 │ 8個 │ 80% │ 加 │
│ 2 │ │ │ │ │
├─────┼──────┼────────┼─────────┼─────────────────┤
│ Pha │ 2週 │ │ │ 全機能カバレッ │
│ se │ 間 │ 12個 │ 90%+ │ ジ完成 │
│ 3 │ │ │ │ │
└─────┴──────┴────────┴─────────┴─────────────────┘
---
📊 改善優先度マトリクス
| 実装時間 | 影響度 |
---------|----------|--------|
P0: セキュリティ修正 | 5分 | CRITICAL
P1: テスト Phase 1 | 2時間 | CRITICAL
P2: パフォーマンス改善 | 1時間 | HIGH
P3: テスト Phase 2-3 | 4時間 | MEDIUM
---
✅ 実行アクションプラン
今すぐ(今日中)
- save_to_file() / load_from_file()にwith文導入
- テストファイル作成 + Phase 1テスト5個実装
- ハードコードされたパスワードを環境変数化
1週間以内
- KeyError/FileNotFoundError ハンドリング追加
- search_users() キャッシング実装
- Phase 2テスト3個追加(カバレッジ80%達成)
1ヶ月以内
- インデックス化による本格的な検索最適化
- 入力値バリデーション完全実装
- Phase 3テスト完成(カバレッジ90%+)
---
📈 期待される改善効果
┌────────────────────────┬─────┬───────┬───────────┐
│ メトリクス │ 現 │ 改善 │ 向上度 │
│ │ 状 │ 後 │ │
├────────────────────────┼─────┼───────┼───────────┤
│ 検索パフォーマンス(10 │ 1ms │ 300μs │ 3.3倍 │
│ k users) │ │ │ │
├────────────────────────┼─────┼───────┼───────────┤
│ テストカバレッジ │ 0% │ 90%+ │ 完全網羅 │
├────────────────────────┼─────┼───────┼───────────┤
│ リソースリーク │ あ │ なし │ リスク排 │
│ │ り │ │ 除 │
├────────────────────────┼─────┼───────┼───────────┤
│ セキュリティ脆弱性 │ 5個 │ 0個 │ 全解決 │
└────────────────────────┴─────┴───────┴───────────┘
---
チーム分析完了! 3名の専門家による詳細な改善提案をお渡ししました。ご質問や追加の調査があればお知らせください。
実行例から見るエージェントチームの価値
実行時の出力から分かるように、エージェントチームの利用には、下記のメリットがあります。
- 複数メンバーが同時に並列実行
各専門家が同じコードを異なる視点で分析 - 自律的にタスク実行
セキュリティレビュー完了、パフォーマンス分析提出と、それぞれが独立して進捗 - 詳細な分析結果
単なる「問題あり」ではなく、「O(n × m)」「1,000,000ユーザーで1秒の遅延」など、具体的で実装可能な情報が得られる - 統合レビュー計画
各分析を合算して、総合的な改善アクションプランの作成
今回はシンプルなプロンプトでの検証でしたが、プロジェクト情報(スケール、セキュリティ要件、アーキテクチャなど)を事前に指示することで、エージェントチームはそれらを踏まえた、より実践的なレビューをしてくれます。
エージェントチームが活躍する場面
これまでのコードレビュー例以外にも、エージェントチームが力を発揮する場面があります。
複数領域の並列開発
新機能実装をフロントエンド、バックエンド、データベース設計の3チームで同時進行する場合:
【エージェントチームなし】
1. バックエンドのAPI設計
2. フロントエンドの開発(API完成待ち)
3. DB設計の調整
→ 依存関係で時間がかかる
【エージェントチームで並列化】
フロントチーム → UI実装・モック API の作成
バックチーム → API仕様設計・実装を同時進行
DBチーム → スキーマ設計・最適化を並列実施
→ 各チームが自律的に進め、定期的に同期
技術選定の多角的検討
新しいフレームワーク導入時に、複数視点での評価が必要な場合:
【エージェントチームなし】
1. パフォーマンス調査(ベンチマーク実施)
2. 運用性の検討(デプロイ・監視の確認)
3. コスト分析(インフラ・ライセンス・学習コスト)
→ 順番に調査するため時間がかかる
【エージェントチームで並列化】
パフォーマンスチーム → ベンチマーク・スケーラビリティ検証を実施
運用チーム → デプロイ・監視・ログ機能を並列評価
コストチーム → インフラコスト・ライセンス・学習曲線を分析
→ バランスの取れた判断材料が同時に揃う
このように、複数の視点や領域が絡むプロジェクトほど、エージェントチームの並列化の価値が高まります。
注意点と対策
1. トークンコストが思った以上に高い
エージェントチームは、各メンバーが独立した Claude インスタンスとして動作するため、トークン消費が単一エージェントより大幅に増加します。
対策:
- 本当に並列実行が必要な場面のみ使う
- サブエージェントで十分な場合はそちらを使う
2. チームメンバーが同じファイルを編集してしまう
複数のチームメンバーが同じファイルを編集すると、上書きが発生します。
- メンバーA が users.py を編集中
- メンバーB も users.py を編集
→ メンバーA の変更が失われる
対策:
作業を分割する時点で、ファイルの所有権を明確にする:
+ メンバーA「users.py を編集」
+ メンバーB「test_users.py を編集」
→ 異なるファイルなので競合しない
3. チームを放置すると無駄な作業が増える
複数メンバーが独立して動いているため、進捗を見守らないと不要な検証に時間を使ってしまう可能性があります。
対策:
- 定期的に進捗をチェック
- 方針がズレていたら修正指示
- 立ち往生したメンバーには直接指示を活用
4. 実験的機能ゆえの制限
エージェントチームは実験的機能のため、以下の制限があります:
- セッション再開時(
/resume)には、in-process チームメンバーが復元されません - 1セッション = 1チームのみ(複数チーム並行は未対応)
- チームメンバー自身が新しいチームを生成できない(リーダーのみ可能)
5. タスクサイズの目安
公式ドキュメントのベストプラクティスでは、チームメンバーあたり 5~6個 のタスクが、生産的に動く目安とのことです。
おわりに
エージェントチームは、AI駆動開発をさらに進化させるための強力な武器です。
ただし、使い分けが大事になります:
【エージェントチームを使うべき】:
- 複数の仮説を並列検証したい
- 異なる視点からのレビューが必要
- 複数領域の並列開発がしたい
【サブエージェントで十分】:
- 「調査してまとめて」のような一方向タスク
- コスト効率を最優先にしたい
私自身も使い込んでいる途中ですが、複数視点でのレビューや並列開発で特に価値を実感しています。
皆さんのプロジェクトでも、並列化から恩恵を受ける場面がないか、ぜひ検討してみてください。







