Claude Code Agent Teamsは、単一スレッドのClaude Code体験を、独立したClaudeインスタンスが通信し、タスクを共有し、コードベース上で並列に作業する協調型マルチエージェントシステムへと変革します。2026年2月に実験的機能としてリリースされたAgent Teamsは、開発者がAIコーディングアシスタントとやり取りする方法の根本的な転換を意味します。一度に1つの会話から、開発チーム全体のオーケストレーションへ。本ガイドでは、初期セットアップから本番対応のパターンまで、効果的なエージェントチームを構築するために必要なすべてを解説します。
要点まとめ
Agent Teamsを使うと、共有プロジェクトで連携する複数のClaude Codeセッションを起動できます。1つのセッションが作業を調整するチームリーダーとして機能し、チームメイトは独自のコンテキストウィンドウで独立してタスクを実行します。サブエージェント（単一セッション内で動作し、親にのみ報告可能）とは異なり、チームメイトは互いに直接メッセージを送り、タスク中に発見を共有し、リーダーを介さずに連携できます。環境変数またはsettings.jsonでCLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=trueを設定することで有効化でき、Claude Code v2.1.32以降が必要です。Anthropicは、16の並列エージェントを使用してLinuxカーネルをコンパイル可能な10万行のCコンパイラを構築することで、このアプローチの威力を実証しました。約2,000セッションで約20,000ドルのコストがかかりました（Anthropicエンジニアリングブログ、2026年2月）。
Claude Code Agent Teamsとは？（サブエージェントとの違い）
Agent Teamsが登場する前、Claude Codeでは作業を並列化する主な手段としてサブエージェントが提供されていました。サブエージェントは単一セッションのコンテキスト内で動作し、限定されたタスクを実行して結果を親エージェントに返します。メインの会話でアーキテクチャについて思考を続けながら、コードベースのパターン検索を別途行うなど、探索を分離するのに便利です。しかし、サブエージェントには根本的な制限があります。互いに通信できないのです。エージェントAがエージェントBの作業に関連する発見をした場合、その情報は親エージェントを経由する必要があり、ボトルネックが発生して可能な連携の種類が制限されます。
Agent Teamsは、各チームメイトに独立したコンテキスト、ツールアクセス、そしてリーダーや他のチームメイトにメッセージを送信する機能を持つ完全なClaude Codeセッションを与えることで、この問題を解決します。このアーキテクチャの違いにより、サブエージェントでは不可能なパターンが実現します。フロントエンドエージェントがバックエンドエージェントにAPIコントラクトの変更を直接伝えたり、テストエージェントがリーダーのリレーを待たずにコード作成者にテスト失敗を通知したり、複数のエージェントが直接議論を通じて問題の共有理解に収束したりできます。
以下の表は、各アプローチをいつ使うべきかを明確にします。間違った選択は、不必要な複雑さ（単純な検索にAgent Teams）や連携のボトルネック（横断的な変更にサブエージェント）につながります。
| 項目 | サブエージェント | Agent Teams |
|---|---|---|
| セッション | 親のセッション内で動作 | 各自が完全なセッションを取得 |
| 通信 | 一方向：子 → 親のみ | 双方向：任意 → 任意 |
| コンテキスト | 親のコンテキストウィンドウを共有 | 独立したコンテキストウィンドウ |
| 連携方式 | 親が仲介者として機能 | 直接ピアツーピアメッセージング |
| 最適な用途 | 集中的で独立したタスク | 複雑なマルチパートプロジェクト |
| セットアップ | 組み込み、設定不要 | 実験的フラグが必要 |
| コスト | 低い（単一セッションのオーバーヘッド） | 高い（複数セッションのオーバーヘッド） |
サブエージェントは、あなたに報告するスペシャリストコンサルタントを雇うようなものと考えてください。一方、Agent Teamsは全員が互いに会話できるプロジェクトチームを編成するようなものです。Claude Codeの機能に既に精通していて、エージェントチームがより広いツールセットの中でどこに位置するかを理解したい場合は、Claude Codeインストールガイドで基本的なセットアップを解説しています。
Agent Teamsの内部動作の仕組み
Agent Teamsのアーキテクチャは3つの中核コンポーネントで構成されます。チームリーダーセッション、1つ以上のチームメイトセッション、そしてタスクファイルとエージェント間メッセージングに基づく共有コーディネーションレイヤーです。
チームリーダーは、あなたのプライマリClaude Codeセッションです。チームに何を達成してほしいかを記述する最初のプロンプトを入力するセッションです。Claudeがタスクが並列作業に適していると判断すると、Teammateツールを使用して追加のClaude Codeプロセスを起動します。起動された各プロセスは、独自のコンテキストウィンドウ、ツール権限、会話履歴を持つ独立したClaude Codeセッションとして実行されます。リーダーは各チームメイトに初期タスクを割り当て、共有タスクシステムを通じて進捗を監視します。
チームメイトは、リーダーから初期プロンプトを受け取り、独立して作業する完全自律型のClaude Codeインスタンスです。ファイルの読み書き、コマンドの実行、コードベースの検索、そしてすべての標準Claude Codeツールを使用できます。重要なのは、SendMessageツールを使ってリーダーや他のチームメイトにメッセージを送信できることです。これにより、Agent Teamsを単純な並列実行と区別するリアルタイムの連携が可能になります。
コーディネーションレイヤーは、2つのメカニズムが連携して機能します。第一に、すべてのチームメンバーが読み書きできるディスク上の共有タスクリストです。タスクにはステータス（pending、in_progress、completed）があり、他のタスクをブロックでき、誰が何に取り組んでいるかのメタデータを含みます。チームメイトがタスクを完了すると、ブロックされていた下流のタスクが自動的に利用可能になり、他のチームメイトがクレームできます。第二に、SendMessage APIは、タスクステータスの変更よりもニュアンスが必要な状況、つまり発見の共有、明確化の要求、アプローチの変更提案のための直接的なエージェント間通信を提供します。
このアーキテクチャにより、Agent Teamsは起動時に並列活動のバーストを生成し、タスクの完了とチームメイトの発見の共有に伴って徐々に収束し、最終的にリーダーセッションに集約されて結果が統合され、あなたに提示されます。プロセス全体はターミナルで確認できます。エージェント間のメッセージの流れを監視し、タスクステータスの更新を確認し、チームが軌道を外れた場合に介入することができます。
エージェントチームセッションのライフサイクルを理解することで、コストとタイミングを予測できます。起動フェーズ(通常10～30秒)では、リーダーがチームメイトセッションを作成し初期タスクを割り当てます。並列実行フェーズ(セッションの大部分、数分から数時間)では、チームメイトがエージェント間メッセージをときどき交換しながら独立して作業します。収束フェーズは、最初のチームメイトがタスクを完了し、残りの作業の支援や他者の出力のレビューを開始すると始まります。最後に、統合フェーズではリーダーがすべての結果を収集し、コンフリクトを解決し、統一されたレスポンスを提示します。各フェーズには異なるトークン消費特性があります。起動は安価で、並列実行が最もコストが高く、統合はリーダーが行う必要がある調整の量に依存します。
各チームメイトセッションは、リーダーセッションの権限とツールアクセスを継承しますが、会話履歴は継承しないことに注意してください。チームメイトは、割り当てられたタスクの説明とリーダーが提供する初期コンテキストのみを含むクリーンなコンテキストで開始します。つまり、チームメイトはチーム作成前にリーダーと何を議論したかを知りません。これは実際には利点です。リーダーが以前の会話からの暗黙的なコンテキストに頼るのではなく、明示的で自己完結した指示を提供することを強制するからです。チームメイトが会話履歴の情報を必要とする場合、リーダーはタスクの説明にそれを含めるか、メッセージで送信する必要があります。
最初のAgent Teamのセットアップ（ステップバイステップ）
Agent Teamsを動かすには、実験的機能フラグの有効化と、チームの動作に影響するいくつかの設定オプションの理解が必要です。セットアッププロセスは5分もかかりませんが、ここで行う設定の選択がチームの効率に影響します。
ステップ1：Claude Codeのバージョンを確認する。 Agent Teamsにはv2.1.32以降が必要です。ターミナルでclaude --versionを実行してバージョンを確認してください。アップデートが必要な場合は、npm install -g @anthropic-ai/claude-code@latestを実行するか、インストール方法に適したパッケージマネージャーを使用してください。
ステップ2：実験的フラグを有効にする。 Agent Teamsを有効にするには3つのオプションがあり、機能をグローバルに利用可能にするかプロジェクトごとにするかによって選択が異なります。
json// オプションA：プロジェクトレベルの設定（.claude/settings.json） { "env": { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "true" } } // オプションB：ユーザーレベルの設定（~/.claude/settings.json） { "env": { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "true" } } // オプションC：環境変数（セッションレベル） // export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=true
プロジェクトレベルの設定がチームにはおすすめです。同じリポジトリで作業するすべての人が、個人設定を変更することなくAgent Teamsを有効にできるためです。この設定はセッション間で永続化され、プロジェクトとともにバージョン管理にチェックインされます。
ステップ3：Claude Codeを起動してチームタスクを記述する。 プロジェクトディレクトリでClaude Codeを起動し、並列作業を自然に示唆するプロンプトを与えます。重要なのは、Claudeにチームの構成方法を細かく指示するのではなく、望む成果と関連する異なるワークストリームを記述することです。例えば、「3つのエージェントを作成して」と言う代わりに、次のように言いましょう。「このプルリクエストをセキュリティの問題、パフォーマンスの問題、テストカバレッジの欠落について確認してください。各分野は独立して検討し、結果を1つのレポートにまとめてください。」
Claudeはプロンプトを分析し、何人のチームメイトが効果的かを判断し、焦点を絞った指示とともに起動し、タスクコーディネーション構造をセットアップします。チームメイトが作成され作業を開始するとターミナルにメッセージが表示されます。
ステップ4：進捗を監視する。 チームが作業している間、ターミナル出力で共有タスクリストとエージェント間メッセージを確認できます。リーダーエージェントは定期的にチームメイトの状況を確認し、チームメイトが早く終了したりブロッカーに遭遇した場合はタスクを再割り当てすることがあります。チームを誘導する必要がある場合は、リーダーエージェントにメッセージを送信でき、リーダーが関連する指示を影響を受けるチームメイトにリレーします。
ステップ5：結果を収集してレビューする。 すべてのタスクが完了すると、リーダーエージェントがすべてのチームメイトの発見を統合し、統一されたレスポンスを提示します。チームメイトはSendMessageシャットダウンプロトコルを通じて自動的にシャットダウンされます。リーダーがshutdown_requestを送信し、各チームメイトがshutdown_responseで確認し、セッションがクリーンに終了します。
セットアップ中に問題が発生した場合、最も一般的な問題はバージョン非互換（Claude Codeをアップデート）、機能フラグの欠落（3つの設定場所すべてを確認）、権限エラー（APIキーまたはサブスクリプションに複数の同時セッションに十分なクォータがあることを確認）です。APIユーザーの場合、各チームメイトが独自のトークン割り当てを消費するため、レート制限の消費が大幅に加速する可能性があることに注意してください。
もう1つの実用的な考慮事項はシステムリソースです。各チームメイトは別のNode.jsプロセスとして実行されるため、RAMが限られたマシンで大規模なチームを起動するとパフォーマンスの問題が発生する可能性があります。ほとんどの開発マシンでは、3～5人の同時チームメイトが快適に動作します。より大規模なチーム（10人以上）が必要な場合は、少なくとも16GBのRAMを搭載したマシンで実行し、プロセスメモリの使用量を監視することを検討してください。チームメイト間の通信はローカルファイルシステム操作とAPI呼び出しを通じて行われるため、ネットワーク帯域幅がボトルネックになることはめったにありませんが、Anthropic APIへのレイテンシはチームメイトのメッセージへの応答速度に影響する可能性があります。
無料ティアでClaude Codeを使用しているチームの場合、Agent Teamsにアクセスできますが、複数の同時セッションにより限られた使用クォータがはるかに速く消費されます。Agent Teamsで本格的な作業を行う前に、ProまたはMaxへのアップグレードを検討するか、中断を避けるために十分なティア割り当てを持つAPIアクセスを使用してください。
実際のプロジェクトに使えるチームアーキテクチャパターン
生産的なエージェントチームと、並列Claudeセッションの混沌とした状態の違いは、チームの責任範囲と通信パターンをどのように構造化するかにあります。コミュニティの経験とAnthropicのテストから、異なる種類の作業に一貫して効果的な4つのアーキテクチャパターンが浮かび上がっています。
パターン1：レビュースクワッド。 このパターンは、同じ成果物を複数のレビュアーに割り当て、それぞれが異なるレンズで検査します。典型的な構成では、3人のチームメイトを起動します。1人はセキュリティの脆弱性に焦点を当て、1人はパフォーマンスのボトルネック、もう1人はコードスタイルと保守性に集中します。リーダーがすべてのレビューを収集し、深刻度順に優先順位付けされた統一レポートを作成します。このパターンは、レビュアー間の連携が不要なため、プルリクエストのレビュー、アーキテクチャ評価、ドキュメント監査に特に効果的です。各レビュアーは同じコンテンツを独立して検査し、リーダーが統合を担当します。各レビュアーは大きなコード変更を生成せずに同じファイルを読むため、トークンコストは比較的低くなります。
パターン2：フィーチャービルダー。 スタックの複数レイヤーにまたがる新機能を構築する場合、フィーチャービルダーパターンは各レイヤーに1人のチームメイトを割り当てます。フロントエンド、バックエンド、データベース、テストです。リーダーがレイヤー間のインターフェース（APIコントラクト、データスキーマ）を事前に定義し、各チームメイトが独立して担当部分を実装します。ここでエージェント間メッセージングが重要になります。バックエンドのチームメイトがAPIコントラクトの調整が必要であることを発見した場合、リーダーを経由するのではなく、フロントエンドのチームメイトに直接メッセージを送信します。フィーチャービルダーパターンは、機能の境界が明確で、コンポーネント間のインターフェースが作業開始前に定義できる場合に最も効果的です。
パターン3：デバッグスワーム。 複雑な問題のデバッグは、複数の仮説を同時に探索することで恩恵を受けることがよくあります。デバッグスワームは複数のチームメイトを起動し、それぞれが根本原因について異なる仮説を追求します。1人は最近のコード変更を調査し、もう1人はログパターンを検査し、3人目は環境間の設定の違いをレビューします。チームメイトが仮説を否定したり裏付けとなる証拠を発見したりすると、発見を互いに共有します。証拠が蓄積されるにつれてスワームは自然に収束し、明確な全体像が浮かび上がるとリーダーが診断を統合します。このパターンは、断続的な障害、レースコンディション、または複数のサービスにまたがる問題を扱う場合に特に価値があります。
パターン4：クロスレイヤーコーディネーション。 最も高度なパターンは、1つの領域での変更が他の複数の領域に波及するタスクを処理します。例えば、APIレイヤー、データベースマイグレーション、フロントエンドコンポーネント、テストフィクスチャに影響するコアデータモデルの名前変更などです。リーダーが変更シーケンスを計画し、各レイヤーをチームメイトに割り当て、チームメイトが直接メッセージングを通じて具体的な変更を連携します。このパターンは最もエージェント間通信を必要とし、明確なタスク依存関係の恩恵を受けます。データベースマイグレーションはAPI変更の前に完了する必要があり、API変更はフロントエンド更新の前に完了する必要があります。
実際の事例がこれらのパターンの動作を示しています。文書化された1つのケースでは、開発者がClaudeに「エージェントチームを使って、localhost:4321の自分のブログに対してQAを行って」とプロンプトを出しました。リーダーは5人のSonnetベースのチームメイトを起動し、それぞれに異なるQAの観点を割り当てました。コアページレスポンス、ブログ投稿のレンダリング、ナビゲーションとリンク、RSS/サイトマップ/SEO、そしてアクセシビリティです。チームメイトは独立して作業しました。ページレスポンスエージェントは16ページのHTTP 200ステータスコードを確認し、リンクチェッカーは146の内部URLを検証し、アクセシビリティエージェントはHTMLクラス属性内の文字列化されたブーリアンやテーマトグルのARIAラベル欠落などの問題を発見しました。リーダーはすべての発見を10件の問題（重大4件、中程度2件、軽微4件）に統合した優先順位付きレポートにまとめました。単一のエージェントが順次実行した場合、かなり長い時間がかかったであろう作業です。
見落とされがちですが強力な機能がプラン承認ゲートです。チームメイトを起動する際、変更を行う前に実装プランの承認を求めることを要求できます。チームメイトは読み取り専用のプランモードで作業します。ファイルの読み取りやコードベースの分析はできますが、リーダー（またはあなた）がプランを承認するまで何も変更できません。プランが却下された場合、チームメイトはフィードバックを受けてアプローチを修正します。これは、コードが変更される前に人間のチェックポイントが必要な高リスクの変更に非常に有用であり、同時にAgent Teamsが提供する並列分析の恩恵を受けられます。
これらのパターンの選択は2つの要因に依存します。ワークストリームがどの程度相互に影響するか（低い相互作用はレビュースクワッド、高い相互作用はクロスレイヤーに適している）と、新しいコードを作成しているか既存のコードを修正しているか（新しいコードはフィーチャービルダー、既存のコードはデバッグスワームまたはクロスレイヤーに適している）です。ほとんどのプロジェクトでは、より連携の多いパターンを試す前に、まずレビュースクワッドパターンでAgent Teamsに慣れることをおすすめします。
通信とタスク管理の詳細
Agent Teamsの効果は、チームメイトがどれだけうまく通信するか、そしてタスクがどのように構造化されているかに大きく依存します。チームメイトが利用できる通信プリミティブを理解することで、より良い連携パターンにつながるプロンプトを設計できます。
SendMessageはプライマリの通信ツールです。異なる連携目的を果たす複数のメッセージタイプをサポートしています。標準メッセージは、あるエージェントから別のエージェントにテキストを配信します。送信者は受信者（名前またはチームの役割で指定）とメッセージ内容を指定します。ブロードキャストメッセージは全チームメイトに同時に送信され、リーダーが方向転換を発表したり、全員に関連する発見を共有する必要がある場合に便利です。シャットダウンリクエストとレスポンスは、チームメイトがタスクの途中で中断されないようにする優雅な終了プロトコルを形成します。
Anthropicが行った重要な設計上の選択は、SendMessageが唯一の直接通信チャネルであることです。共有メモリ、共有クリップボード、あるチームメイトが別のチームメイトの会話履歴を読む機能はありません。この制約は意図的なものです。通信を明示的かつ構造化されたものに強制し、チームの動作を予測不可能にするような暗黙的な結合を防ぎます。チームメイトAがチームメイトBからの情報を必要とする場合、メッセージを通じてそれを要求する必要があり、チームメイトBは関連するコンテキストで応答する必要があります。これにより、情報の流れが監査可能でデバッグ可能になります。
タスク管理は連携の構造的なバックボーンを提供します。タスクはTaskCreateで作成され、TaskUpdateで更新され、TaskListとTaskGetで照会されます。各タスクには、件名、説明、ステータス、所有者、およびオプションの依存関係リンクがあります。依存関係システムは特に強力です。タスクBがタスクAにブロックされることを指定でき、タスクAが完了するとタスクBが自動的にチームメイトがクレームできるようになります。
フィーチャービルダーチームのためにリーダーがタスクを構造化する方法の例を示します。
pythonTaskCreate(subject="ユーザープロフィールのAPIコントラクトを定義", description="...") TaskCreate(subject="バックエンドAPIエンドポイントを実装", description="...", addBlockedBy=["task-1"]) # APIコントラクトが定義されるまでブロック TaskCreate(subject="フロントエンドプロフィールコンポーネントを構築", description="...", addBlockedBy=["task-1"]) # 同様にAPIコントラクトまでブロック TaskCreate(subject="統合テストを作成", description="...", addBlockedBy=["task-2", "task-3"]) # 両方の実装完了までブロック
この依存関係構造により、コントラクトが定義される前にチームメイトが実装を開始することがなく、テストはフロントエンドとバックエンドの両方が完了した後にのみ開始されます。チームメイトは現在のタスクを完了すると、次に利用可能なブロックされていないタスクを自己クレームするため、リーダーが介入する必要なくチームが自動的にロードバランシングされます。
よくある間違いは、タスクの依存関係グラフを過度に複雑にすることです。依存関係は、タスクBがタスクAの完了まで本当に開始できないという真の順序要件を反映すべきであり、実行順序の好みを表現するものであってはなりません。依存関係を過剰に指定すると、チームメイトがブロックされたタスクのアンブロックを待つ時間が増えるため、並列性が低下します。逆に、依存関係の指定不足は、2人のチームメイトが重複するコードを同時に変更する際にコンフリクトを引き起こします。最適なバランスは、データまたはファイルレベルの依存関係がある場合にのみ依存関係を作成し、チームメイトに明確なファイル所有権を与える広いタスクスコープの定義を使用することです。
大規模なコードベースを処理するチームでは、エージェント間の通信量を監視することが有用な健全性シグナルとなります。エージェントがタスクごとに数回以上のメッセージを送信している場合、通常はタスクの分解が細かすぎて、エージェントが成果物の生成ではなく連携に過剰なトークンを消費していることを示しています。理想的なパターンは、起動後に短いメッセージのバースト（エージェントがタスクの理解を確認）、実行中のときどきのメッセージ（発見の共有や明確化の要求）、そして統合中の最終ラウンドのメッセージを示します。Claude CodeのAPI機能を使用してアプリケーションを構築する開発者のために、MCP統合ガイドでは、Model Context Protocolを通じてカスタムツールでAgent Teamsを拡張する方法を説明しています。
コスト分析：Agent Teamsの実際のコストはいくらか？
Agent Teamsのコストを理解することは、並列実行への投資が価値があるケースと、単一のClaude Codeセッションで十分なケースについて情報に基づいた判断を行うために不可欠です。Agent Teamsのコストモデルは理論的にはシンプルですが、実際の支出に大きく影響するニュアンスがあります。
基本的な計算式は次の通りです。総コスト = チームメイト数 x チームメイトあたりの平均トークン数 x トークンあたりの価格。各チームメイトは、ファイルの読み取り、思考、出力の生成、他のチームメイトとの通信のためにトークンを消費する独立したセッションです。リーダーセッションも連携のオーバーヘッドでトークンを消費します。月額固定予算のサブスクリプションベースの使用とは異なり、APIベースのAgent Teamsはトークンあたりで厳密に課金されるため、コストは実行された作業量に直接比例します。
AnthropicのCコンパイラ実験は、利用可能な最も具体的なコストベンチマークを提供しています。16の並列Opus 4.6エージェントを使用し、約2,000のClaude Codeセッションで、チームはx86、ARM、RISC-Vアーキテクチャ上でLinuxカーネルをコンパイル可能な10万行のRustベースCコンパイラを生産しました。総コストはAPI使用料で約20,000ドルでした（Anthropicエンジニアリングブログ、2026年2月より確認）。これは生成されたコード1行あたり約0.20ドル、またはセッションあたり平均10ドルに相当します。これは最も高価なモデル（Opus）を極めて複雑なタスクに使用したハイエンドシナリオです。ほとんどの開発者のワークフローでは、コストは大幅に低くなります。
モデルの選択はコストに大きく影響します。 Opus 4.6の代わりにSonnet 4.6を使用すると、トークンあたりのコストが40%削減されます（Sonnetが$3/$15/MTok vs Opusが$5/$25、claude.com/pricing、2026年3月確認）。コードレビュー、ドキュメント生成、テスト作成など、多くのAgent Teamsタスクでは、Sonnetはコストを大幅に削減しながらOpusに匹敵する品質を提供します。実用的な戦略は、リーダーエージェントにOpus（連携に最も強い推論が必要）、チームメイトにSonnet（より集中的で明確に定義されたタスクを実行）を使用することです。
コスト最適化戦略として、品質を犠牲にせずにAgent Teamsの支出を削減する方法には、作業を有意義に並列化できる最小限のチームメイト数に制限する（3～5人が通常最適）、各チームメイトに明確なスコープ境界を設定して冗長な探索を防ぐ、タスク依存関係を使用してブロックされた作業での不必要なトークン消費を避ける、Claude Consoleのリアルタイムダッシュボードでトークン使用量を監視するなどがあります。
Agent Teamsを頻繁に実行し、コストをさらに削減したい開発者のために、laozhang.aiのようなサードパーティAPIルーティングサービスは、Anthropicとの直接的なAPIティア管理よりも潜在的に低いオーバーヘッドでClaudeモデルへのトークン単位のアクセスを提供しています。このアプローチは、使用パターンが変動するチーム（ある週はAgent Teamsを多用し、別の週は最小限の活動）にとって特にコスト効果が高くなります。未使用のサブスクリプション容量に対する支払いを避けられるためです。
もう1つのよく見落とされるコスト要因はプロンプトキャッシングです。複数のチームメイトが同じ大きなファイルを読む場合（レビュースクワッドパターンでよくあること）、プロンプトキャッシングは実効トークンコストを大幅に削減します。Anthropicのキャッシュ対応ITPMシステムは、キャッシュされた入力トークンがレート制限にカウントされず、基本入力価格の10%で課金されることを意味します。共通のコードベースコンテキストを共有するAgent Teamsでは、効果的なキャッシングにより、ナイーブな実装と比較して入力トークンコストを50～80%削減できます。最適化の鍵は、共有コンテキスト（システム指示や共通の参照ファイルなど）が各リクエストの先頭に来るようにチームメイトのプロンプトを構造化し、チームメイト間のキャッシュヒット率を最大化することです。キャッシングとレート制限の相互作用の詳細については、Claude Codeレート制限ガイドをご覧ください。
| シナリオ | エージェント数 | モデル | 推定トークン | 推定コスト |
|---|---|---|---|---|
| PRレビュー（3つの視点） | 3 | Sonnet 4.6 | 約50万合計 | 約$2-5 |
| 新機能（3レイヤー） | 4 | Opus+Sonnet混合 | 約200万合計 | 約$15-30 |
| デバッグスワーム（4つの仮説） | 4 | Sonnet 4.6 | 約100万合計 | 約$5-12 |
| 大規模リファクタリング（クロスレイヤー） | 5 | 混合 | 約300万合計 | 約$25-50 |
| Cコンパイラ（Anthropicの事例） | 16 | Opus 4.6 | 数十億 | 約$20,000 |
AnthropicのCコンパイラ実験からの教訓
大規模なAgent Teamsの最も示唆に富む事例は、Anthropicのエンジニアリングチーム自身によるもので、16のOpus 4.6エージェントを使用してRustでCコンパイラをゼロから構築しました。2026年2月にAnthropicのエンジニアリングブログで文書化されたこの実験は、マルチエージェント開発の驚異的な可能性と実用的な制限の両方を明らかにしました。重要な教訓は、開発者が自身のAgent Teamsをどのように構造化すべきかに直接適用されます。
教訓1：並列化は自然に分解可能な問題で最も効果的。 Cコンパイラプロジェクトが成功したのは、コンパイルが本質的にモジュール型であるためです。パース、型チェック、コード生成、最適化は、ある程度独立して開発しテストできます。チームは、多数の異なる失敗テストがある場合に最も高い並列性が達成可能であることを発見しました。各エージェントが連携なしに異なる失敗テストに取り組めるためです。テストスイートが99%のパス率に達し、残りの失敗が相互に関連するようになると、エージェントがより慎重に連携する必要があるため、並列性は自然に低下しました。開発者への教訓は、Claudeが分解を自力で見つけることを期待するのではなく、チームを起動する前にプロジェクト内の自然な並列境界を特定することです。
教訓2：オラクルがあればすべてが容易になる。 Linuxカーネルコンパイルの課題では、チームは既知の正しいコンパイラオラクルとしてGCCを使用しました。ほとんどのカーネルファイルをGCCでランダムにコンパイルし、少数のファイルのみを新しいコンパイラでコンパイルするテストハーネスを構築し、各エージェントが異なるファイルの異なるバグを同時に修正できるようにしました。このパターン（出力を信頼できるリファレンスと比較する）は、コンパイラ以外にも一般化できます。APIをリファクタリングしている場合、古い実装を新しい実装と並行して稼働させ、エージェントに動作の同等性を検証させましょう。データベースを移行している場合、古いスキーマと新しいスキーマの間でクエリ結果を比較しましょう。オラクルパターンは、オープンエンドな品質問題を、エージェントが独立して実行できるクローズドループの検証サイクルに変換します。
教訓3：通信オーバーヘッドは現実的だが管理可能。 16のエージェントでは、通信の混沌が生じる可能性は大きいです。Anthropicチームは、構造化されたタスク依存関係が不要なエージェント間のチャットを削減することを発見しました。エージェントが何に取り組んでいるかを常にメッセージし合う代わりに、タスクシステムが誰が何をしているかの可視性を提供しました。直接メッセージングは、2人のエージェントが同じファイルを変更しようとした場合など、本物の発見やコンフリクトのために予約されました。自身のチームでは、過度なコミュニケーションを奨励する誘惑に抗してください。ほとんどのAgent Teamsタスクは、継続的な議論よりも「チェックポイント付きの分割統治」アプローチから恩恵を受けます。
教訓4：トークンコストは出力ではなく探索に比例する。 10万行のコードに対する20,000ドルのコストは高く見えるかもしれませんが、実世界のCコードの完全な複雑さを処理するコンパイラを構築するために必要な広範な探索とデバッグを反映しています。各エージェントは単にコードを書いたのではなく、既存のコードを読み、バグに関する仮説を立て、修正をテストし、失敗した試みを元に戻し、反復しました。この探索作業のトークンコストは、最終出力のコストを遥かに上回ります。より直接的なタスク（明確な仕様を持つ機能実装など）に取り組むチームは、はるかに低いコスト対出力比を見ることになります。
教訓5：重要な決定ポイントでの人間の介入がチームの効果を倍増させる。 Cコンパイラは大部分が自律的に構築されましたが、Anthropicチームは、アーキテクチャ上の決定ポイント（例えば、コード生成の競合するアプローチの選択）でのときどきの人間のガイダンスが、エージェントが最適でないパスの探索に数千トークンを費やすことを防ぐことを発見しました。最も効果的なワークフローは、完全自律型ではなく半自律型でした。エージェントは明確に定義されたサブタスクに独立して取り組み、人間がそれらのサブタスクをフレームする高レベルの戦略的決定を行います。このハイブリッドアプローチは、両者の強みを尊重しています。エージェントは明確に定義されたタスクの並列実行に優れ、人間は戦略的判断と長期的な計画に優れています。
教訓6：Agent Teamsの価値はプロジェクトの複雑さに応じて増大する。 シンプルな機能追加の場合、単一のClaude Codeセッションは通常、チームを起動するよりも速くて安価です。損益分岐点（Agent Teamsが順次作業よりもドルあたりより良い結果を提供するポイント）は、タスクが真に並列なワークストリーム（異なるファイル、異なる関心事）を含む場合、またはタスクが複数の視点からの恩恵を受ける場合（コードレビュー、アーキテクチャ評価）に発生します。Cコンパイラプロジェクトは、並列にデバッグ可能な数千の独立したテストケースを含んでいたため、損益分岐点をはるかに超えていました。ほとんどの開発者のワークフローでは、損益分岐点は3～5の真に独立したサブタスク前後です。それ以下では、チーム連携のオーバーヘッドが並列性の利点を上回ります。
よくある質問
一般的なプロジェクトでは何人のチームメイトを使うべきですか？
ほとんどのタスクでは3～5人のチームメイトから始めてください。レビュースクワッドパターンは3人の専門レビュアーでうまく機能し、フィーチャービルダーパターンは通常4人（レイヤーごとに1人とテスト）が必要です。5人以上にしても、連携のオーバーヘッドが並列性の利点を上回り始めるため、スループットが向上することはめったにありません。例外は、Anthropicのコンパイラ実験のように高度に分解可能なタスクで、16のエージェントがそれぞれ最小限の連携で真に独立したテストケースに取り組んだため効果的でした。
Agent TeamsはProまたはMaxサブスクリプションで動作しますか？APIアクセスが必要ですか？
Agent Teamsはサブスクリプションプランと直接APIアクセスの両方で動作します。サブスクリプション（Proが月額$20またはMaxが月額$100-200）を使用する場合、各チームメイトが共有サブスクリプションクォータからトークンを消費するため、単一セッションよりも速く使用制限に達します。APIアクセスは、チームメイトごとのトークン予算をより細かく制御でき、サブスクリプションクォータの上限を回避できるため、Agent Teamsの多用に適しています。アクセス方法に関係なく、実行する予定の並列セッション数に十分なクォータがあることを確認してください。
2人のチームメイトが同時に同じファイルを編集しようとした場合どうなりますか？
Claude Codeは、標準的なファイルロックとコンフリクト解決メカニズムを通じて並行ファイルアクセスを処理します。実際には、適切に構造化されたタスク依存関係が、特定の時点で1人のチームメイトだけが特定のファイルに取り組むようにすることで、ほとんどのコンフリクトを防ぎます。コンフリクトが発生した場合、リーダーエージェントが通常、統合中にそれを検出し、一方のチームメイトの変更を優先することで解決します。重複する領域ではなく、個別のファイルやディレクトリの責任を各チームメイトに割り当てるようにタスクを構造化することで、コンフリクトを最小限に抑えることができます。
チーム設定を保存して再利用する方法はありますか？
現在、Agent Teamsには事前定義されたチーム構造のための組み込みテンプレートや設定ファイルはありません。しかし、好みのチームパターンを記述するCLAUDE.mdの指示を作成するか、特定のチームアーキテクチャをエンコードするカスタムスキルを作成することで、再利用可能な設定を実現できます。コミュニティもGitHub gistやリポジトリを通じて設定パターンを共有しています。この機能が実験的ステータスを超えて成熟するにつれ、より構造化された設定オプションが期待されます。
Agent TeamsはGitブランチやバージョン管理とどのように連携しますか？
各チームメイトはリーダーと同じ作業ディレクトリおよびGit状態で動作します。つまり、すべてのチームメイトが同じブランチ、コミットされていない変更、ファイル状態を見ます。複雑なタスクでは、リーダーがgit worktreeを使用した分離モードで作業するようチームメイトに指示できます。これにより、各チームメイトにリポジトリの個別のコピーが与えられます。並列作業中のマージコンフリクトを防ぎますが、最後に調整ステップが必要です。チームメイトが異なるファイルを変更するよりシンプルなタスクでは、メインの作業ディレクトリへの直接的な並行アクセスがうまく機能します。
Agent Teamsは本番ワークフローに十分安定していますか？
Agent Teamsは現在実験的とラベル付けされており、AnthropicがAPIの動作や可用性を予告なく変更する可能性があることを意味します。本番ワークフローでは、この実験的ステータスにはリスクが伴います。Claude Codeのアップデートがチームの連携方法を変更したり、SendMessageプロトコルに破壊的な変更を導入する可能性があります。とはいえ、多くの開発者がコードレビュー、機能開発、デバッグの日常的なワークフローでAgent Teamsを使用しています。推奨されるのは、部分的な失敗が許容でき手動介入が可能なタスクに使用することであり、信頼性が重要な完全自動化されたCI/CDパイプラインには使用しないことです。現在の主な制限として、セッション再開なし（/resumeコマンドはチームメイトを復元しない）、セッションあたり1チームのみ、ネストされたチームなし（チームメイトは自身のチームを起動できない）、チームメイトがタスク完了をマークし忘れることがあり依存タスクがブロックされることがあります。これらの制限は、機能が実験的ステータスを超えて進化するにつれて改善されることが期待されます。