複雑で複数領域にまたがるワークフローを単一の AI セッションに任せると、どうしても時間がかかります。Claude agent teams は、専門化された agents を並列実行することでこの問題を解決し、はるかに高速に、より深い成果を返します。このガイドでは、Claude Code agent teams の仕組み、設定方法、価値を最大化するためのベストプラクティスを解説します。
Claude agent teams とは
Claude Code agent teams は、複数の Claude セッションが同じコードベース上で並列に作業するマルチインスタンス協調システムです。1 つのセッションがリード agent として指定され、全体タスクを受け取り、それをサブタスクに分解し、最終成果を統合します。ほかの sub-agents は teammates であり、それぞれが独立したコンテキストウィンドウで動作し、個別の作業を担当し、他の teammates と直接通信します。
agent teams の利点
一般的な AI アシスタントはタスクを 1 つずつ順番に処理しますが、agent teams はそこが異なります。agent teams はその制約を取り払い、作業を本当に並列化できる場合には、その分だけ実時間を短縮します。
同時に、agent teams は単なる複数セッションではありません。協調レイヤーにより、手作業のマルチセッション運用にはない 3 つの機能が加わります。
ピアツーピアメッセージング： Teammates は、あなたやリードを経由せずに互いへ直接メッセージを送れます。たとえば、セキュリティレビュー担当を含む agent team では、実行中にチーム全体を止めることなく、セキュリティ担当 agent が発見事項をパフォーマンスレビュー担当に知らせることができます。
ファイルロック： teammate がファイルに書き込むとロックを取得し、他の agents による同時書き込みを防ぎます。これにより、マージコンフリクトのうち、気づかない上書きが起きるタイプを防げます。
依存関係の追跡： リードは分解時にタスク間の依存関係を記録します。協調レイヤーがそれを強制するため、前提条件が満たされるまで agent が開始されることはなく、手動で確認し続ける必要もありません。
agent teams は実際にどう動くのか
agent team は、特定の役割を持つ次のコンポーネントで構成されます。
チームリード はメインの Claude Code セッションです。チームを作成し、teammates を起動し、全員の作業を調整し、最終結果を統合します。あなたが直接やり取りするのはこのセッションです。
Teammates は個別の Claude Code インスタンスで、それぞれが自分のコンテキストウィンドウ内で割り当てられたタスクに独立して取り組みます。リードとも互いともコンテキストを共有せず、タスクリストとメールボックスを通じて明示的に通信します。
共有タスクリストとメールボックス が協調を可能にします**。** 共有タスクリストは、agent グループが読み書きするライブキューです。リードが分解時に項目を登録し、teammates がタスクを引き受け、処理し、完了としてマークします。依存関係は自動的に強制されます。teammate がタスクを完了すると、それにブロックされていたタスクは手動介入なしで解除されます。メールボックスは agent 間の直接通信のためのメッセージングシステムです。メッセージは teammates とリードの間を自動的に流れます。
チーム設定とタスクリストはいずれもローカル（~/.claude/teams/ と ~/.claude/tasks/）に保存されます。Claude Code はこれらのファイルを自動で生成・管理します。次回の状態更新時に変更が上書きされるため、手動で編集しないでください。
Claude Code agent teams の設定方法
Claude agent teams は、Claude Code ではデフォルトで無効になっています。experimental と位置づけられており、明示的なオプトインが必要です。設定手順は次のとおりです。agent teams を有効にする前に、Claude Code のバージョンが v2.1.32 以降であることを確認してください**。** ターミナルで claude --version を実行すれば確認できます。
ステップ 1：機能フラグを有効にする
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS 環境変数を 1 に設定します。方法は 3 つあります。
方法 A：~/.claude/settings.json（推奨）
方法 B：シェルプロファイル（~/.bashrc または ~/.zshrc）
方法 C：単一セッション用にインラインで指定
settings.json またはシェルプロファイルを編集した場合は、フラグを反映させるために Claude Code を再起動してください。
ステップ 2：tmux をインストールする（推奨、必須ではありません）
Agent teams の表示モードは 2 つあります。In-process（すべての teammates がメインターミナル内で実行）と分割ペイン（各 teammate が専用ペインを持つ。tmux または iTerm2 が必要）です。各 teammate を専用のターミナルペインで実行すると、チームの状況をリアルタイムでかなり監視しやすくなります。
分割ペインモードを維持するには、~/.claude/settings.json で teammateMode を設定します。
デフォルトの "auto" 設定を上書きするには、~/.claude/settings.json で teammateMode を in-process に設定します。単一セッションで in-process モードを強制するには、フラグとして claude --teammate-mode in-process を渡します。
ステップ 3：agent team を開始するプロンプトを書く
agent team を有効にしたら、agent team に実行してほしいタスク、成果物、チーム構成を自然言語で Claude に伝えるだけです。プロンプト内で各役割を指定でき、Claude はそれに応じてチームを作成し、teammates を起動し、タスクをスケジュールします。
プロンプト例：
"Use Sonnet for every teammate" のように、agent teams が使用するモデルを指定できます。Teammates はリード agent のモデルを継承しません。ユーザーは role file frontmatter でモデルを指定するか、/config でデフォルトの teammate モデルを設定する必要があります。
ステップ 4：複雑なタスクでは計画承認を求める（任意）
リスクや複雑性の高いタスクでは、実行前にチームへ計画を作成させることができます。agent グループ内の teammates は読み取り専用モードで作業し、リードが計画をレビュー、修正し、最終的に承認します。リードにより計画が承認されて初めて、teammates は実装に着手します。
意思決定はリード agent が行うため、判断基準をいくつか与えておくこともできます。
プロンプト例：
ステップ 5：ファイル分離のために git worktrees を設定する（任意、推奨）
teammate がファイルを書き込む場合、Claude Code worktrees を強く推奨します。git worktree は、メインのチェックアウトと同じ .git 履歴を共有しつつ、専用ブランチ上にある別の作業ディレクトリです。各 agent は分離されたファイルアクセスを持ち、ある worktree の編集が別の agent の作業途中の内容に触れることはありません。
agent ごとに有効にするには、agent の YAML frontmatter に isolation: worktree を追加するだけです。Claude Code は並列 agent 呼び出しごとに新しい worktree を用意し、agent の終了時に自動でクリーンアップします。
CLI で使う場合：claude --worktree または claude -w で、専用 worktree 内のセッションを開始します。デスクトップアプリはセッションごとに Claude Code worktree を自動作成します。
ステップ 6：定期的に監視する
Agent teams は放っておけばよいものではなく、長時間実行するチームは軌道から外れることがあります。Agents が権限プロンプトで止まったり、タスクを早まって完了扱いにしたり、スコープを見失ったりする可能性があります。10〜15 分ごとに状況を確認し、共有タスクリストで詰まっているタスクや未着手のタスクを確認してください。20〜30 分たっても進んでいないタスクがある場合、権限ブロックか、手動介入を要する不適切な役割指定が原因かもしれません。
横並び比較：subagents と agent teams
Subagents は委任のパターンです。Agent teams は協働のパターンです。この違いは、コンテキスト管理の方法から実行コストまで、あらゆる点に影響します。
| Subagents | Agent teams | |
|---|---|---|
| Communication | 一方向：リードが割り振り、subagents が報告する | ピアツーピア + リードによる調整 |
| 共有状態 | なし | 依存関係追跡付きの共有タスクリスト |
| コンテキストウィンドウ | 独自のコンテキストウィンドウ。結果はリードへ返る | 各 teammate が独自に持つ（最大 1M tokens） |
| ファイル競合の防止 | 組み込みなし | ファイルロックあり |
| Token コスト | 低い | 高い（各 teammate が 1 つの独立インスタンス） |
| セッション再開 | 対応 | /resume and /rewind don't restore in-process teammates |
| ネストされた agents | 対応 | 非対応。teammates を起動できるのはリードのみ |
| 適した用途 | 焦点を絞った委任、反復可能なワークフロー | 並列化可能で相互依存があり、複数領域にまたがる作業 |
Subagents は一方向の委任パターンです。リードがタスクを送り、subagent が自身のコンテキストウィンドウ内で実行し、結果を返します。共有状態も、兄弟 agents 間の直接通信も、調整レイヤーもありません。あるのは、割り振って返すだけの明快なループです。
Agent teams は、依存関係を自動的に適用する共有タスクリスト上で作業し、mailbox を介して teammates 同士がピアツーピアでメッセージをやり取りします。
要するに agent teams が効果を発揮するのは、作業を真に独立した並列トラックに分けられ、各トラックが知見を共有しながら互いに調整する必要がある場合です。素早い結果、順次タスク、単一ファイルの編集、あるいは速度よりコストの予測可能性が重要な場面では、subagents のほうが適しています。
Agent teams と subagents の使い分け
agent teams を使うべき場合：
Teammates 同士が直接やり取りする必要がある
並列ワークストリーム全体で依存関係を追跡する共有タスクリストが必要
タスクが単一セッションには大きすぎ、各作業者に完全に独立したコンテキストが必要
subagents を使うべき場合：
途中の出力全体ではなく、最終要約だけが必要
作業が自己完結しており、明確な結果を返せる
ツールを制限したい、またはより安価なモデルへルーティングしたい
互いに依存しない並列調査ルートが必要
真に独立した並列ワークストリームを少なくとも 3 つ特定できないなら、単一セッションまたは subagents のほうが低コストで agent team を上回る可能性が高いでしょう。
Agent teams の実践的ユースケース
作業が自然にスコープの明確な限定的ワークストリームへ分かれ、それぞれが互いを待たずに進められる（または依存関係を明示的に符号化できる）場合、並列実行で節約できる時間に比べて調整のオーバーヘッドは小さくなります。ここでは、agent teams が単一セッションを上回る 5 つのユースケースを紹介します。
並列コードレビュー
セキュリティ agent、パフォーマンス agent、テストカバレッジ agent を含む 3 人のレビュアーを、1 つのプルリクエストに同時に割り当てます。リードは 3 つの並列レポートを統合し、優先順位付きのアクションリストにまとめます。このパターンは、アーキテクチャレビュー（スケーラビリティ agent、セキュリティ agent、保守性 agent）や、異なる規制フレームワークにまたがるコンプライアンスチェックにも有効です。
競合仮説デバッグ
5 つの agents を起動し、それぞれに 1 つずつ仮説を持たせて、本番環境のバグ調査のために特定のファイルやログを検証させます。最初に仮説を確認した agent が修正案を提示し、他の agents は停止できます。各仮説を順番に調べ、1 つの道筋を何時間もデバッグし、引き返して次に進むより効率的です。
レイヤー横断リファクタリング
レイヤー横断のリファクタリングには、順次ステップと並列ステップの両方が含まれます。たとえば、破壊的な API 変更では、バックエンドのエンドポイント、それを利用するフロントエンドコンポーネント、そして両方をカバーするテストスイートの更新が必要です。フロントエンドに着手する前に、バックエンド作業を完了しておく必要があります。バックエンド作業が進み始めれば、テストスイート agent は新しいテスト構造の足場作りを並行して開始できます。agent team では、リードが共有タスクリストの依存関係追跡を使って、この順序を表現します。
コンテキスト汚染のない網羅的調査
技術的な意思決定では、データベースエンジンの選定、3 つのサードパーティ API の評価、ビルドツールの査定など、複数の独立した証拠群を調査する必要がある場合があります。各 agent に重複しない領域を割り当て、それぞれが構造化された要約を投稿します。リードはそれらを比較文書に集約します。分離により独立した視点が保たれ、結果の品質が向上します。
大規模コードベースの移行
大規模なコードベースで主要な依存関係をアップグレードする場合、通常は複数のモジュールに手を入れる必要があります。モジュール間の境界が明確で同時に移行できるなら、agent teams が役立ちます。独立したモジュールごとに 1 つの agent を割り当てます。各 agent は自分のモジュールを移行し、独自のテストスイートを実行し、変更されたインターフェースを含む移行サマリーを報告します。リードは移行完了を宣言する前にインターフェース変更をレビューし、マージ順序を調整します。
agent team 設計の Dos and don'ts
Claude Code で並列 agent システムを構築するのは、設定自体は簡単ですが、設計を誤るのも容易です。agent team が成果を出すか、時間を浪費するかを左右する設計原則は次のとおりです。
並列 agent システム構築のプロ向けヒント
権限を事前承認する： Teammates はリードの権限設定を引き継いで開始します。リードを --dangerously-skip-permissions で実行している場合、すべての teammates もそれを継承します。起動後に個々の teammate のモードを調整することはできますが、起動時点で teammate ごとのモードを設定することはできません。チームを立ち上げる前に、リード側で権限方針を決めておきましょう。
役割プロンプトを絞り込む： 各役割プロンプトでは、何をするのか、どのファイルや領域で作業するのか、何に注力し何を除外するのか、成果物はどのような形か、の 4 点を明確にします。Teammates を起動するときは、project、user、plugin、CLI 定義など、任意の subagent スコープにある subagent タイプを参照できます。これにより、セキュリティレビュアーやテストランナーのような役割を一度定義すれば、委任先の subagent と agent team の teammate の両方で再利用できます。
ファイル分離を徹底する： ディスクへ書き込む agent には、必ず分離を使ってください。2 つの agents が同じファイルを同時に変更することは、破損した出力を生む最も確実な方法の 1 つです。
定期的に確認する： 稼働中の agent teams では 10〜15 分ごとに確認します。共有タスクリストを見て、進んでいないタスクがないかを確認してください。20〜30 分以上止まっているタスクは、権限の問題、役割指定の誤り、循環依存が原因の可能性があり、手動での解決が必要になることがあります。
依存関係を明示的に記述する： Task B が論理的に Task A の後に来るなら、その依存関係は役割プロンプト内の指示ではなく、分解時にタスクリストへ書き込みます。調整レイヤーは依存関係を自動的に適用しますが、プロンプト内の指示は誤読されたり無視されたりすることがあります。
md ファイルで担当範囲を定義する： 複数セッションのプロジェクトでは、各モジュールまたはディレクトリに所有 agent が必ず 1 つだけ存在する、というルールを書いておきます。これにより、チームを起動する前から作業の重複を防げます。
クリーンアップは必ずリード経由で行い、teammate 経由では行わない： リードはリソースを解放する前に、アクティブな teammates が残っていないか確認します。Teammates には安全にクリーンアップするためのチーム全体のコンテキストがないため、teammate 側で行うとセッションが不整合な状態で残るおそれがあります。
agent team で避けられるよくある失敗
1 つのセッションできれいに処理できるタスクに team を起動しない： 役割ファイルを 1 つ書く前、あるいは swarm プロンプトを 1 つ送る前に、タスクグラフを描いてください。どのサブタスクが本当に独立しているのか。どれに依存関係があるのか。順次依存する作業ではないのか。境界の明確な並列トラックを 3 つ説明できないなら、単一セッションのほうが team より良い結果を出します。
同じファイルに 2 つの agents を割り当てない。 これはマージ競合とサイレント上書きの最も一般的な原因です。タスク分解の結果、同じコンポーネントに触る必要のある agents が 2 つ生まれるなら、そのコンポーネントの作業は順次実行にすべきです。片方が完了してから、もう片方の agent に割り当ててください。
Claude Code で権限の事前承認を省略しない。 実行途中で権限プロンプトが発生すると、並列実行が停止し、手動介入が必要になります。そのオーバーヘッドによって利点の多くが失われます。起動前に、作業ディレクトリに対するファイル書き込みとシェルコマンドを事前承認しておきましょう。
Claude Code team を復元できると期待しない。 セッションがクリーンアップされると、/resume や /rewind では in-process teammates は復元されません。長時間実行する前に、重要な途中成果を保存しておきましょう。
明確な理由なく 5 人を超える team を走らせない。 Token コストは線形に増えますが、調整のオーバーヘッドはそれ以上に大きくなります。役割が曖昧な 5 つの agents より、役割を絞った 3 つの agents のほうが一貫して高い成果を出します。Teammates を追加するのは、明示的に待機している並列ワークストリームがある場合だけです。「多いほどよい」気がするからではありません。
別のパラダイム：Kimi Agent Swarm でマルチ agent チームを構築する
Claude Code agent teams は、ターミナルワークフローや Git エコシステムと深く統合され、開発者向けのシナリオで力を発揮します。しかし、マルチ agent 協働というパラダイムは、コマンドラインの外にも大きく広がっています。Kimi Agent Swarm は、そのパラダイムを誰もが使える形にする場所です。
Kimi Agent Swarm は、複雑で大規模なタスクのために設計された Kimi のマルチ agent 協働システムです。広い目標を個別のサブタスクに分解し、検索、読解、分析、執筆、コーディング、スプレッドシート生成、スライド作成、Web ページ構築を、さまざまな agents とスキルに同時並行で処理させます。env フラグは不要。git 設定も不要です。
Kimi Agent Swarm の主な機能
最大 300 の sub-agents による並列協働： Kimi Agent Swarm は複雑なタスクを分解し、複数の sub-agents がサブタスクを同時に処理するようスケジューリングします。システムは最大 300 の sub-agents を調整し、1 回の実行で 4,000 回を超えるツール呼び出しを実行できます。
複数スキルの複合実行：Swarm は、徹底的な調査、pptx、レポート執筆、vibe-coding、Web サイト構築、論文執筆など、複数の専門スキルを 1 回の実行で組み合わせられ、出力の深さと形式の網羅性で単一 agent を上回ります。
大規模ドキュメント処理：Agent Swarm は 20 種類以上の形式（PDF、Word、Excel、PPT、画像など）のファイルをバッチ処理し、ドキュメントセット全体にわたって読み取り、情報抽出、要約を並列に行えます。ライブラリ、競合インテリジェンスファイル、複数ソースのデータ取り込みも参照可能です。
プロアクティブな広域調査： 広範囲の情報を必要とするタスクでは、Agent Swarm が sub-agents を派遣して Web 検索、情報源の特定、コンテンツのダウンロード、発見事項の分類、構造化要約の生成を並列に行います。
複数視点での推論： Agent Swarm は、同じ問題に対して複数の専門家視点を同時に実行できます。これにより、単一視点での検討より包括的な分析が得られ、順次レビューでは見落としがちな盲点が浮かび上がります。
深いコンテンツ提供： Agent Swarm の並列アーキテクチャは、数百ページ規模の調査レポート、長編の業界分析、学術文献レビュー、体系的な学習ガイド、長大な物語コンテンツなど、深さを持続する出力のために作られています。
1 回の実行で複数形式の出力： Agent Swarm は、同じタスクについて PDF レポート、PPT デッキ、Web ページ、Excel データセット、コードプロジェクトなど、複数種類の成果物を同時に生成できます。
Kimi Agent Swarm で agent team を実行する方法
ステップ 1：Kimi Agent Swarm を開き、プロンプトを入力する
Agent Swarm ページを開き、入力ボックスにタスクを記述します。最良の結果を得るには、スコープ、期待する成果物、期間・情報源・形式要件などの制約を具体的に指定してください。
プロンプト例：
ステップ 2：Kimi Agent Swarm に作業させる
プロンプトを送信すると、Agent Swarm はタスクをサブタスクに分解し、subagents を割り当てて並列に作業させます。タスク計画、sub-agent の起動、並列実行など、進捗をリアルタイムで確認できます。
ステップ 3：結果を受け取り、プレビューし、ダウンロードまたは共有する
実行が完了すると、成果物をインターフェース上で直接プレビューできます。タスクに応じて、出力には調査レポート、データ分析、PPT デッキ、Web ページ、コードプロジェクト、またはそれらの組み合わせが含まれます。ファイルをダウンロードし、そのまま共有できます。
Kimi Agent Swarm が力を発揮するユースケース
入札・提案書作成： 技術仕様、コンプライアンス要件、価格モデル、導入事例に対して並列 agents を同時に割り当て、orchestrator が一貫した提案書へ統合します。
財務分析： 市場データ、競合他社の開示資料、マクロ指標、社内モデルを扱う並列 agents を割り当て、orchestrator が統合された分析へまとめます。
ビジネス調査： 競争環境、顧客インタビュー、業界レポート、規制文脈について、異なる情報源から並列 agents に調査させ、orchestrator が構造化された出力を作成します。
セキュリティテスト： 偵察、脆弱性スキャン、依存関係監査、権限昇格チェックを並列 agents で実行し、orchestrator が発見事項を最終レポートに集約します。
フルスタック開発： フロントエンドコンポーネント、バックエンドエンドポイント、データベーススキーマ、テストスイートのために並列 agents を構築し、orchestrator がフルスタック全体の統合を調整します。
まとめ
Claude Code agent teams は、複雑なコードベースに対する並列実行をターミナルから直接扱えるようにする、エンジニアリングワークフロー向けの仕組みです。作業がコードの範囲を超えるなら、Kimi Agent Swarm が同じマルチ agent パラダイムを調査、分析、コンテンツ制作などへ広げます。タスクを説明するだけで、あとは swarm に任せられます。