Claude Code Agent Teamで専門家チームを作る実践ガイド

Claude Codeで開発を進めていて、「1つのタスクを終わらせている間に別の作業も走らせたい」と思ったことはありませんか。

私は脱サラに向けて個人開発と副業ブログを同時に回しているのですが、ずっとこの非同期感に苦しんでいました。

エージェントが1人だと、結局は順番に作業させるしかなく、自分の時間を切り売りしている感覚から抜け出せなかったんです。

そんなときに出会ったのがClaude CodeのAgent Team機能でした。

複数のエージェントが独立したコンテキストを持ったまま、互いに通信して同時に動く。

最初に触った日、いつもなら長丁場になる検証作業があっという間に終わって、本気でゾッとしました。

Agent Teamは、環境変数を1つ設定するだけで有効化でき、複数のエージェントが独立したコンテキストを保ったまま直接会話し、並列で動きます。

この記事を読むと、次の4つが今日から使える形でわかります。

(1)サブエージェントとの違い、(2)3ステップの有効化手順、(3)個人開発で実際に効果が出た3つのユースケース、(4)チームが機能しなくなる典型的な失敗と回避策です。

Agent Teamとは？サブエージェントとの違い

Agent Teamとは、Claude Codeの中で複数のエージェントを「チーム」として並列稼働させる実験的機能です。

メンバー同士が直接やり取りしながら、共有タスクを進められます。

従来のサブエージェント（Agentツール）は「親から子に一方向で委譲する」モデルでした。

Agent Teamは、そこから「同僚同士で会話する」モデルに進化しています。

Agent Teamの独立コンテキストと直接通信

Agent Teamの最大の特徴は、各メンバーが独立したコンテキストウィンドウを持つことです。

サブエージェントも独立コンテキストではあるのですが、基本は親エージェント経由でしか結果が返ってきません。

例外として、Claudeが名前を付けて呼び出したサブエージェント同士は直接メッセージし合えます。

Agent Teamではメンバー間で直接メッセージを送れるため、伝言ゲームのオーバーヘッドが消えます。

私が実感したのは、レビュー役と実装役を分けたときの速さです。

実装役が書き終わるたびにレビュー役へ直接渡せるので、親エージェントが間に挟まる無駄な往復がありません。

これだけで1イテレーションごとの待ち時間が目に見えて減りました。

サブエージェント（Agentツール）との比較表

言葉だけだと違いが見えにくいので、実際に触って感じた差分を表にまとめます。

両者は対立する機能ではなく、向いている場面が違うだけなので、まずは性質を押さえておくと選択がブレません。

共有タスクリストとタスクのclaim・依存関係

Agent Teamにはメンバー全員が見える「共有タスクリスト」があります。

チームリードがタスクを作成すると、タスクはpending（未着手）→ in progress（作業中）→ completed（完了）の3状態で管理されます。

あるタスクが別タスクの完了を前提とする「依存関係」を持たせることもできます。

割り振り方は2通りあります。

リードが「このタスクはあなたに」と明示的に割り当てる方法と、メンバーが自分の作業を終えたタイミングで未着手のタスクを自分で拾いにいく「self-claim（自己申告）」です。

私のチームでは後者が主流で、リードが逐一指示を出さなくても手が空いたメンバーから勝手に次の仕事へ進んでくれるので、指揮官としての負担がかなり減りました。

なぜ今Agent Teamが必要なのか

個人開発でも仕事でも、タスクは複数ドメインにまたがるのが当たり前になりました。

フロント・バックエンド・インフラを1人で見るような状況で、シングルエージェントだと文脈の切り替えコストがバカになりません。

Agent Teamはこの切り替えコストをチーム側に押し付けてくれます。

要するに「人を増やす」のではなく「自分の認知を切り出す」ためのツールというのが私の理解です。

Agent Teamを有効化する3ステップ

Agent Teamは2026年9月時点でも実験的機能のため、デフォルトでは無効になっています。

有効化は環境変数1つで済むのですが、再起動の順番を間違えるとチーム編成のコマンドが効かないので、手順どおりに進めるのが安全です。

環境変数CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1を設定する

シェルの設定ファイルに以下を追記します。zshなら~/.zshrc、bashなら~/.bashrcです。

一時的に試したいだけなら、ターミナルで直接exportしてもかまいません。

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

Claude Codeを再起動してチームを編成する

環境変数を反映させるため、Claude Codeを一度終了して立ち上げ直します。

起動後、自然言語で「フロント・バックエンド・QAの3人チームを作って」と頼むだけでメンバーが生成されます。

コマンドを覚える必要がないのは地味にうれしいポイントです。

上下矢印キーでメンバーを切り替えて指示を出す

チーム編成が終わったら、上下矢印キーでエージェントパネルのメンバーを選び、Enterキーでそのメンバーの画面を開いて直接メッセージを送れます。

メンバーの一覧はプロンプト入力欄の下のエージェントパネルに並ぶので、誰を選んでいるかを確かめながら操作できます。

私は最初これに気づかず、全員に同じ指示を出してしまい、3メンバー分のトークンを無駄にしました。

最初に切り替え操作を確認してから本番タスクに入るのをおすすめします。

表示モードを選ぶ｜in-processとtmux分割ペイン

ここまでの手順はデフォルトのin-processモード（1つのターミナルの中でエージェントパネルを切り替える方式）を前提にしています。

この方式はどんなターミナルでも追加設定なしに動くので、まずはこれで慣れるのがおすすめです。

もう1つ、tmuxまたはiTerm2（it2 CLIが必要）を使う「split panes」モードもあります。

メンバーごとに専用のペインが割り当たり、誰が何をしているか画面を分割したまま同時に眺められるのが利点です。

settings.jsonのteammateModeを"tmux"や"iterm2"に設定するか、起動時に--teammate-modeフラグを渡すと切り替わります。

私は複数メンバーの出力を目で追いたいときだけtmux版を使い、普段はin-processのままにしています。

Agent Teamの実践ユースケース3選

機能を入れただけでは生産性は上がりません。私が実際に効果を感じた3つのパターンを紹介します。

どれも「人間1人で順番にやると数時間かかる」けれど「並列なら数十分で終わる」タイプの作業です。

マイクロサービスを同時に実装して開発を速める

サービスAとサービスBが独立していて依存が薄いとき、メンバーをそれぞれに割り当てると本当に同時並行で進みます。

私はFastAPIの2サービスを並列で組ませて、シングルエージェントのときより明らかに早く終わる手応えがありました。

インターフェースだけ先に共有ドキュメントで固めておくのがコツです。

デバッグ仮説を並列検証して原因特定を高速化する

バグの原因候補が3つあるとき、シングルエージェントだと1つずつ潰すしかありません。

Agent Teamならメンバーごとに別仮説を割り振って同時検証できます。

「3人で勝負して一番先に原因を見つけた人が勝ち」というゲーム感覚で進められるので、自分の集中力も切れにくいです。

スプリントレビューを複数視点で同時分析する

私はブログ運営のレビューにも使っています。

SEO観点・収益化観点・読者体験観点の3メンバーに同じ記事を渡し、それぞれの視点で同時にフィードバックを出してもらう運用です。

1人のエージェントに全部頼むと観点が混ざるのですが、分けると各観点の解像度が一気に上がります。

シングルエージェントとの体感速度比較

ここまでの体感を一度まとめておきます。

いずれも私自身の個人開発での体感であり、正式なベンチマークを取ったものではありません。

Agent Team設計で押さえる4つの原則

Agent Teamは適当に作ると、すぐに「人数だけ多い、機能しないチーム」になります。私が失敗を重ねて辿り着いた4つの設計原則を共有します。

これを守るだけで、初期構築の事故が目に見えて減りました。

責務分離｜1メンバー1ロールで認知負荷を下げる

1人に「実装もレビューもデプロイも」と詰め込むと、結局シングルエージェントと同じになります。

1メンバー1ロールを守ると、メンバーに渡す指示（スポーン時のプロンプト）も短くでき、トークン効率が大きく改善します。

成果物インターフェース｜ファイルベースで受け渡す

メンバー間の口頭引き継ぎは記憶のように揮発します。

設計書・APIスペック・テスト結果はすべてファイルに落とし、ファイルパスを介して引き渡すのが安定運用のコツです。

私はリポジトリ直下に/handoff/ディレクトリを用意して、ここを共有ホワイトボード代わりに使っています。

委譲範囲の明示｜指示テンプレートを揃える

「いい感じに頼む」はAgent Teamでは禁物です。「入力・出力・完了条件・禁止事項」の4点を毎回テンプレで埋めると、再作業が激減します。

私はSnippetツールで以下のテンプレを呼び出して使っています。

【入力】参照すべきファイル: 〇〇.md
【出力】生成物の保存先: handoff/result.md
【完了条件】テスト通過 + レビュー1名承認
【禁止事項】既存APIの破壊的変更

コンテキスト遮断｜トークンバジェットを配分する

全メンバーに全ファイルを読ませると、トークン消費が一瞬で跳ね上がります。役割に応じて読ませる範囲を絞り、コンテキストを意図的に遮断するのが鉄則です。

フロント担当にbackend/配下を読ませないなど、シンプルな線引きで十分です。この線引きは口頭指示だけに頼らないほうが安全です。

メンバーに使わせるツールは、サブエージェント定義（.claude/agents/）のtoolsで絞っておくと、指示を出し忘れても事故りにくくなります。なお、.claude/settings.local.jsonなどの権限設定はチーム全員に共通で、メンバーごとには分けられません。

Agent Teamでよくある失敗と回避策

ここからは私が実際にやらかした失敗パターンと、その後の回避策をセットで紹介します。先に知っておくだけで、月数千円規模のトークン浪費は防げるはずです。

メンバーを増やしすぎてコストが爆発する

最初の頃、私は「とりあえず6人チーム」を組んで1日でAPIクレジットを使い切りました。並列度はメンバー数に比例しますが、コストもほぼ比例します。

経験則ですが、序盤は3人までに抑え、ボトルネックを特定してから増員するのが安全です。

タスク分割の粒度がバラバラで再作業が増える

メンバーAに「ログイン機能を作って」、メンバーBに「ボタンのデザインを整えて」と頼むと、粒度が違いすぎてBの作業がすぐ終わり、手持ち無沙汰になります。

同じ時間軸で終わる粒度に揃えるのが鉄則です。私は1タスク=30〜60分で終わるサイズを目安にしています。

役割定義が曖昧で同じ作業を重複してしまう

「実装担当」と「修正担当」のように似た役割を作ると、2人が同じファイルを編集してコンフリクトが頻発します。

役割名は機能ではなく領域で切るのがおすすめです。

「frontend担当」「backend担当」のようにファイルレベルで境界が引ける名前にすると衝突が消えます。

Agent Teamとサブエージェントはどう使い分ける？

結論から言うと、単発の調査・実装はサブエージェント、役割を持った長期協働はAgent Teamが正解です。両方を併用するのが理想なので、どちらかを捨てる必要はありません。

単発ならサブエージェント、長期はAgent Team

「このディレクトリを調べて」「このコードをリファクタして」のような単発タスクはサブエージェント1択です。立ち上げコストが低く、後始末も不要だからです。

一方、複数イテレーションをまたぐ開発はAgent Teamが圧勝します。状態が維持されるため、毎回コンテキストを再構築する必要がありません。

タスク数・期間・コストで選ぶ判断フロー

3つの軸で機械的に判断すると迷いません。タスク数が3未満ならサブエージェント、5以上ならAgent Team。

期間が短く単発で終わるならサブエージェント、1セッションの中で長く協働が続くならAgent Team（チームはセッションをまたいで引き継げません）。

コスト上限が厳しいならサブエージェント、品質優先ならAgent Teamです。私は「タスク数」を最優先軸にしています。

私が個人開発で実際に使い分けている例

ブログ運営ではAgent Team、自動化スクリプトの修正ではサブエージェントを使っています。

ブログは「SEO・収益化・読者体験」の3観点が常に必要で、状態を維持するメリットが大きいからです。

一方、Pythonスクリプトのバグ修正は単発で完結することが多く、サブエージェントの軽さが効きます。

要は「協働が必要か、委譲で済むか」で切り替えています。

よくある質問（FAQ）

最後に、私がX（旧Twitter）や勉強会でよく聞かれる質問をまとめておきます。

実験的機能ゆえに情報が散っているので、ここで一気に確認しておくと安心です。

Agent Teamは有料プランでないと使えない？

Claude Code自体が利用できる契約であれば、Agent Teamの有効化に追加課金は不要です。ただしメンバー数に比例してトークン消費が増えるため、Pro以上のプランで使うのが現実的です。なお、Freeプランでは Claude Code 自体が利用できません。

メンバーは最大何人まで作れる？

公式に明示された上限は2026年9月時点でもありません。Anthropicの実証事例では16エージェントでCコンパイラを構築した報告がありますが（Agent Team機能ではなく、研究者が自作した仕組みによるものです）、個人利用では3〜5人が現実的なラインです。多すぎるとオーケストレーションのほうに頭を取られて本末転倒になります。

通常のサブエージェントは廃止される？

廃止予定のアナウンスはありません。むしろ役割が違うので併存が続くと見ています。サブエージェントは「軽量な手」、Agent Teamは「組織」と捉えると整理しやすいです。両方を場面で切り替えるのが、現時点でのベストプラクティスです。

Windows・VS CodeでもAgent Teamを使えますか？

使えますが、一部の表示モードに制限があります。デフォルトのin-processモード（1つのターミナル内でエージェントパネルを切り替える方式）はどの環境でも動きます。一方、tmuxやiTerm2を使うsplit panesモードは、VS Codeの統合ターミナル・Windows Terminal・Ghosttyでは非対応です。これらの環境ではin-processモードのまま使うのが確実です。

共有タスクリストはサブエージェントのタスク管理と何が違いますか？

サブエージェントのタスクは親エージェントが個別に発行して結果を待つ一方向の依頼ですが、Agent Teamの共有タスクリストはメンバー全員が見える1つのリストです。pending・in progress・completedの3状態で管理され、メンバーは手が空いたタイミングで未着手のタスクを自分でclaim（自己申告）できます。

まとめ｜Agent Teamは「指揮官になる」訓練の場

Agent Teamを触ってみて一番変わったのは、自分の役割が「実装者」から「指揮官」にシフトしたことです。

コードを書く時間より、誰に何を任せるかを設計する時間が増えました。

これは脱サラを目指す個人にとって、組織を持たずにスケールするための重要な訓練になります。

• Agent Teamは独立コンテキスト×直接通信が強み
• 有効化は環境変数1つ＋再起動の3ステップで完了
• 初期は3人チーム＋責務分離＋ファイル受け渡しが鉄板
• 単発はサブエージェント、長期協働はAgent Teamで併用する

「個人開発者にAgent Teamはまだ早い」という声もよく聞きます。トークンコストへの懸念自体はもっともです。

ただその多くは「とりあえず6人チーム」のような過剰な編成が原因で、3人以下の小規模運用に絞れば個人開発でも十分実用的というのが私の結論です。

まずは3人チームで小さく始めて、ボトルネックが見えてから増員する。これが私が現時点でたどり着いている最適解です。

ぜひ今日中に環境変数を1行足して、自分専用の専門家チームを作ってみてください。