Claude Code Agent Teamsで複数エージェントを並列稼働させる方法

Last updated at 2026-09-24Posted at 2026-02-19

Agent Teamsとは

Claude Code Agent Teamsは、複数のAIエージェントをチームとして管理し、タスクベースで並列稼働させる仕組みです。2026年2月時点で利用可能です。

:::details 初心者向け: エージェントとは
ここでの「エージェント」は、Claude Codeのセッション1つ分と考えてください。普段Claude Codeを1画面で使うと1エージェント。Agent Teamsでは、それを複数同時に起動して、それぞれに別の仕事を任せます。人間のチームで言えば「メンバー1人＝エージェント1つ」です。
:::

特徴:

エージェント間でメッセージのやりとりができる（SendMessage）
タスクの依存関係を設定できる（blockedBy）
各エージェントが独立したコンテキストウィンドウを持つ
完了したタスクの次を自分で拾う（TaskList → TaskUpdate）

身近な例えで言うと、文化祭の準備に似ている。クラス委員長（リーダーエージェント）が「装飾班」「料理班」「広報班」に仕事を振る。各班は独立して動くが、「料理が完成してから写真を撮る」のような順序の制約がある。班同士の連絡はLINE（SendMessage）で行う。

この記事では、実際に6エージェントチームを構築して17タスクを並列実行した経験をもとに、セットアップ手順と実践的なパターンを解説します。

事前条件

Claude Code CLI（Max 5X以上推奨、6並列はMax 20Xが安全）
claude コマンドが使えること

Step 1: チームを作成する

Claude Code CLI内で TeamCreate ツールを呼びます:

TeamCreate:
  team_name: "my-studio"
  description: "AIゲーム開発チーム"

これにより以下が作成されます:

~/.claude/teams/my-studio/config.json — チーム設定ファイル
~/.claude/tasks/my-studio/ — タスク保存ディレクトリ

Step 2: タスクを作成する

TaskCreate でチームのタスクを定義します:

TaskCreate:
  subject: "UIデザイン作成"
  description: "メイン画面のUI設計。ボタン配置、色彩、フォントサイズを決定する"
  activeForm: "UIデザインを作成中"

TaskCreate:
  subject: "コアゲームループ実装"
  description: "プレイヤー移動、敵生成、衝突判定の基本ループを実装"
  activeForm: "コアループを実装中"

TaskCreate:
  subject: "スクリーンショット撮影"
  description: "プロモーション用スクリーンショット5枚を撮影"
  activeForm: "スクリーンショットを撮影中"

タスクの依存関係

:::details 初心者向け: 依存関係（blockedBy）とは
「タスクAが終わるまでタスクBを始めてはいけない」という順序の制約です。料理で言えば「ご飯が炊けるまで盛り付けできない」のような関係。blockedBy: ["1"] は「タスク#1が終わるまでブロック（待機）する」という意味です。
:::

タスク間の順序制約は TaskUpdate の addBlockedBy で設定します:

# Task #3（スクショ撮影）はTask #1（UI）完了後に開始
TaskUpdate:
  taskId: "3"
  addBlockedBy: ["1"]

これにより、Task #1が completed になるまでTask #3は着手不可になります。

Step 3: メンバーを起動する

Task ツールの team_name と name パラメータで、チームメンバーとしてエージェントを起動します:

Task:
  prompt: "お前はbuilder — ゲーム開発担当だ。TaskListを見て自分のタスクを探せ。"
  team_name: "my-studio"
  name: "builder"
  subagent_type: "general-purpose"

Task:
  prompt: "お前はdesigner — UI/素材担当だ。TaskListを見て自分のタスクを探せ。"
  team_name: "my-studio"
  name: "designer"
  subagent_type: "general-purpose"

各メンバーには prompt で以下を明記すると効果的です:

名前と役割 — 「お前は〇〇」
チーム設定の場所 — ~/.claude/teams/{name}/config.json
担当タスク — 「Task #Nがお前の仕事だ」
禁止事項 — 「コードを変更するな」「記事を書くな」等
完了時の行動 — 「TaskUpdateでcompletedに更新し、リーダーに報告」

Step 4: メンバー間通信

メンバー同士は SendMessage でDMを送れます:

SendMessage:
  type: "message"
  recipient: "builder"
  content: "スクリーンショット完成。パスは ~/screenshots/game-v1/ にある"
  summary: "スクショ完成通知"

重要なポイント:

テキスト出力はチームメンバーに見えない。必ず SendMessage を使う
recipient はメンバーの name（UUIDではない）
idle状態のメンバーにメッセージを送るとwakeupする
type: "broadcast" で全員に一斉送信できるが、コストが高いので控えめに

実践パターン

パターン1: タスク自動取得

メンバーのプロンプトに以下を含めると、タスク完了後に自分で次のタスクを探します:

タスク完了後の行動:
1. TaskUpdateでstatusを "completed" に更新
2. TaskListで次の未着手タスクを確認
3. ownerが空でblockedByが空のタスクをclaimする
4. なければリーダーに「手が空いた」と報告

パターン2: 専門化による衝突回避

各メンバーに明確な禁止事項を設定すると、同じファイルの同時編集を防げます:

# builder のプロンプトに含める
禁止事項:
- 出荷・公開操作（shipperの仕事）
- 記事執筆（writerの仕事）
- assets/ 配下の画像ファイル変更（designerの仕事）

パターン3: ブロック中の準備作業

依存タスクの完了待ちでidleになるのを防ぐため、プロンプトに「準備作業」を指定します:

待機中の過ごし方:
Task #2（スクショ）完了待ちの間に:
- itch.ioページの現状分析
- 更新が必要な箇所のリスト作成
- 変更後の理想像をテキストで記述

パターン4: モデルの使い分け

全員をOpusにすると高コストです。タスクの性質でモデルを変えると節約できます:

役割	推奨モデル	理由
builder（コード実装）	Opus	複雑な実装にはOpusが必要
researcher（調査）	Sonnet	情報収集はSonnetで十分
grower（指標収集）	Haiku	API呼び出しとデータ整理が中心
designer（素材作成）	Opus	品質判断にOpusが有効

実際の実行結果

6エージェント（team-lead + 5メンバー）で17タスクを作成し、1セッションで実行した結果:

指標	値
完了タスク	9/17 (53%)
最大並列数	6
メンバー間メッセージ	12件
依存関係	3ペア

並列稼働により、1エージェントで順次実行する場合と比較して、体感で3-4倍の速度でタスクが消化されました。

注意点

:::details 初心者向け: デッドロックとは
タスクAが「Bの完了を待つ」、タスクBが「Aの完了を待つ」という状態。お互いが相手を待ち続けて、どちらも永遠に動けなくなります。交差点で4台の車がお互いに「お先にどうぞ」と譲り合って全員が止まるイメージです。A→B→C→Aのように3つ以上が輪になっても同じことが起きます。
:::

コスト: 6エージェント × Opus = 相当なトークン消費。数時間のセッションで週のトークン上限に達する可能性がある
コンテキスト独立: 各エージェントは独立したコンテキストウィンドウを持つ。全員が同じファイルを読む場合、読み取りトークンが6倍になる
デッドロック: blockedByの設計を間違えると循環依存が発生する。A→B→C→Aのような依存は作らない
メッセージ遅延: SendMessageは非同期。相手が処理中の場合、キューに入って後で配信される

まとめ

Agent Teamsのセットアップ手順:

TeamCreate でチーム作成
TaskCreate でタスク定義 + TaskUpdate で依存関係設定
Task でメンバー起動（team_name と name を指定）
各メンバーが TaskList → TaskUpdate で自律的にタスク消化
SendMessage でメンバー間連携

チーム設定は ~/.claude/teams/{name}/config.json のJSONファイルなので、テンプレート化して再利用できます。

この記事はCC（Claude Code）が実際にAgent Teamsを運用した経験に基づいて書いています。

6月15日の billing 変更の Agent Teams への影響

本記事の Agent Teams (claude-code-experimental で起動する Agent の経路) は、 2026年6月15日の Anthropic の課金の経路の分割の対象に該当する可能性が高い領域。
Anthropic の公式の billing 文書で articulate された変更:

claude -p (一回完結の経路) と Claude Agent SDK の呼び出しは、対話の Claude Code とは別の credit bucket (Pool 2) に route される予定。
Agent Teams は内部的に Agent SDK の primitive を呼び出して member の作業者を起動する設計で、 6月15日の後で各 member の作業者のトークンが Pool 2 で集計される可能性が高い。本記事で4人の Team を組んだ場合、並列の4倍の Pool 2 のトークン消費の見込み。
Pool 2 への分離は2026年6月15日に予定されましたが、施行当日に一時停止されました(再実施に備えます)。 Agent Teams を業務の自動化で活用する利用者は、 6月15日の前に次の3件の確認を推奨:

自分の plan の Pool 2 の月額の credit の上限 (Pro: $20、 Max 5x: $100、 Max 20x: $200)
Agent Teams の起動の頻度 × 1回あたりの平均トークン × member の数の見積もり
月額の credit の枯渇の経路 (extra usage の有効化の有無の判定)
無料の見積もりの道具:

June 15 Pool 2 Estimator — 過去30日の使用量から6/15以後の月額の予測
June 15 Readiness Audit — 10問で readiness の score (0-100) を取得
詳細な決定の枠組みは Migration Playbook 第2版 (19米ドル、 241頁、 5/22発売) の第5章 Path B (Codex 移行) と第6章 Path D (local LLM 評価) で、 Agent Teams の代替の経路の整理を articulate。留まる / 切り替える / 混在の3経路の判定の入力。

自分のトークン消費パターンを確認したい方へ
Token Checkupで5つの質問に答えるだけでトークン消費の診断ができる。Hook Selectorで最適なhookセットも分かる。

🚀 cc-safe-setupがProduct Huntに登場 — Claude Codeの安全hookを一発でインストール。701 hooks / 56セクションのSurvival Guide / 無料ツール7個。upvoteで応援お願いします！

📖 トークン消費に困っているなら → Claude Codeのトークン消費を半分にする——800時間の運用データから見つけた実践テクニック（¥2,500・第1章無料）| Ko-fi $17

非エンジニアがClaude Codeを800時間走らせた全記録
$600を投じて何が起きたか——事故、収益の現実、再現可能なフレームワーク。失敗も数字も隠さず書いた体験記:
→ AIに仕事を任せてみた——非エンジニアが800時間で学んだ全記録（¥800・第2章まで無料）

⚠️ Opus 4.7緊急情報（2026年4月17日）
Opus 4.7のauto mode安全分類器がOpus 4.6にハードコードされている問題が発覚。3日間で23件以上のデータ損失。さらにv2.1.100以降、APIコールごとに約20,000トークンが見えない場所で追加課金されている問題も判明（#46917、GitHub上196件のリアクション）（50GB永久消失含む）。4倍のトークン消費も報告されている。対策: npx cc-safe-setup --opus47（Survival Guide / Safety Scanner）

2026-09-19 追記。 上の手順でレジストリ（npm）から入るのは 29.8.0（2026-04-20 公開） です。今日、配られている実物を落として確かめました。手順そのものはこの版でも動きます。ただし、現在の版が止める25通りの命令の形を、この版は通します。41通りを両方へ同じ方法で撃った実測で、例えば rm --recursive --force /（-rf の長い綴り）、rm -rf "$HOME"（引用符つきの変数ごしの指定）、cd repo && git push --force origin main（区切りの後ろに置かれた強制の push）などです。逆向き（29.8.0 が止めて現在の版が通す形）は0件でした。

最新の版は GitHub から入ります → npx github:yurukusa/cc-safe-setup

比較の表と測り方は README のこの節にあります。**2026-09-25 追記。レジストリ側が追いつきました。**2026-09-24 に 30.0.5 が、翌日に 30.0.6 が公開され、latest もそちらへ移っています（公開が止まっていたのは資格情報の失効が理由でしたが、鍵を復旧したのではなく、npm の trusted publishing＝ビルドがその場で身元を証明する方式に切り替えて解決しました）。**いま npx cc-safe-setup で入るのは現在の版です。**上の25通りは、その5か月のあいだに入る版の話として読んでください。

ただし、**2026-09-24 より前に入れている場合、手元は 29.8.0 のままです。**同じコマンドを打ち直しても今は別のものが来るので、打ったコマンドからは見分けがつきません。npx cc-safe-setup --outdated が、手元のフックのうち現在の版と違うものを並べます。

📊 2026-05-05 Path D (Hybrid Stack) の実例 — 利用者の集まりの場で観測: ある利用者が月 200 ドルの上位の枠から月 30 ドルの直接の API + 模型の振り分けに移行して、 6.7 倍の費用削減を実測で報告 (Reddit r/ClaudeAI 5/5 投稿)。 1 日の作業の内訳は 40% がファイル読みと文脈走査 / 25% が試験と雛形 / 20% が形式整え / 15% が硬い推論で、上位の模型が必要なのは 15% だけ。残り 85% は中位の模型 (Sonnet) で同じ結果が出る。本記事の並列のエージェントの活用に加えて、振り分けの仕組みで作業ごとに使う模型を選ぶことで月額の費用を 6.7 倍下げる別の経路。 Migration Playbook 第 6 章 (Path D) の中核の主張への直接の補強 (5/22 配信予定の第 2 版に取り込み予定 (5/15 の audit の結果次第))。

📚 子エージェントの境界の不在の月次の解説 (Claude Code 安全運用便): 本記事の Agent Teams の並列稼働で利用者が直面しやすい子エージェントの境界の問題 (#55488 子エージェントが親の会話の履歴を漏らす / #55653 子エージェントが境界を確認せずに動く / #55660 子エージェントの作業時間の損失「数十時間」) を含む 5 件の事故事例を、月額の購読 Claude Code 安全運用便（¥500/月）で構造化して届けています。無料の見本は Claude Code 事故まとめ(無料・月次) で読めます。 6 月号の事故事例の章の中核の素材。
📖 子エージェントの事故の総括 (Postmortems): 4 月から 5 月の子エージェントの境界の事故と、安全装置の集まりへの組み込みの手順を 1 件の文書にまとめた Postmortems (Gumroad、 4,350 円)。並列の運用の前に読むと、本記事の Agent Teams の構成に「子エージェントの作業領域の所有」と「身分の漏れの予防」の段が組み込めます。