この記事は、Claude Code の Agent Teams を発表し解説するものである。執筆時点ではリサーチプレビュー段階にあったこの機能では、リードエージェントが複数のチームメイトに作業を委任し、チームメイトは並列に作業しながら互いに調整する。記事は、コミュニティがこうしたパターンを「スウォーム」と呼んでいたこと、そして開発者が Claude Code のバイナリ内でフィーチャーフラグ付きの機能を見つけ出し、サブエージェントや bash スクリプトで回避策を組み立てていたものが、正式な機能になったことを指摘している。
記事は Agent Teams を、単一エージェントのモデルとは根本的に異なるアーキテクチャとして位置づけている。その動機となっているのは、コンテキストが大きくなるほど LLM の性能が落ちるという観察である。記事はセットアップ、操作方法、タスク管理を順に説明し、このパターンがうまく機能する場面と注意すべき点を挙げ、活動量が必ずしも価値に結びつくわけではないという注意で締めくくっている。
要点
- 動機となる失敗パターンは、複雑なタスクにおける単一エージェントのコンテキスト劣化である。記事の中心的な主張は、コンテキストウィンドウ内の情報が多いほど、モデルは今重要なことに集中しにくくなるので、各エージェントに狭い範囲とクリーンなコンテキストを与えれば、それぞれの領域内でより良い推論が得られる、というものである。
- このアプローチはタスクが適切に切り分けられている場合にしか機能しない。記事は、トークンを浪費するだけの「アプリを作って」と、仕様に基づいて明確に定義された API エンドポイントを実装することとを対比している。
- Agent Teams はサブエージェントと区別される。サブエージェントは単一の親に結果を報告し、互いに会話することはできないが、チームメイトは互いに直接メッセージを送り、共有タスクリストを通じて調整する。その代わり、各チームメイトが別々の Claude インスタンスであるため、トークンコストは高くなる。
- 記事は、手早く焦点を絞った作業者にはサブエージェントを、チームメイトが発見を共有し、互いに異議を唱え、自ら調整する必要がある場合には Agent Teams を推奨している。
- 向いている状況として挙げられているのは、デバッグにおける競合する仮説（アンカリングを避けるために、チームメイトが互いの説を反証しようとする）、異なる観点からの並列コードレビュー、レイヤーをまたぐ機能開発、そして調査と探索である。
- 著者は、優れたエンジニアリングマネージャーのスキルがエージェントのオーケストレーションにそのまま通用すると論じている。すなわち、タスクのサイズ決め（記事はチームメイト 1 人あたり 5〜6 個のタスクを提案している）、上書きを避けるためのファイルの担当分け、そしてチームメイトはリードの会話履歴を引き継がないため、タスク固有のコンテキストを起動時のプロンプトに読み込ませることである。
- 挙げられている粗削りな点には、リードが委任せずに自分で実装してしまうこと、インプロセスのチームメイトではセッションを再開できないこと、タスクのステータス更新の遅れ、1 セッションにつき 1 チームで入れ子のチームは作れないこと、チームメイトの数に比例して増えるトークンコスト、分割ペインに tmux か iTerm2 が必要なこと、パーミッションがリードから伝播すること、そしてシャットダウンの遅さがある。
- 記事は、マルチエージェントシステムでは大量のコードを素早く生み出すのが簡単になってしまうと警告し、問題に応じてツールを選ぶよう助言している。逐次的なタスク、同じファイルへの編集、依存関係の多い作業では、単一のセッションかサブエージェントのほうが効果的である。
- Agent Teams を中心としたより構造化されたワークフローとして、Compound Engineering Plugin を勧めている。
- 著者の締めくくりの主張は、中核となるスキルは問題を Agent Teams が実行できる構造へと分解することであり、実装はますます十分に精密な仕様の問題になりつつある、というものである。
背景
この記事は著者による実践的なガイドであり意見であると自らを位置づけており、完全なセットアップと使用方法のガイドについては Claude Code 自身のドキュメントを参照するよう示している。記事は Agent Teams を、指揮者からオーケストレーターへの移行に関する著者の以前の文章（エージェント型コーディングの未来：指揮者からオーケストレーターへ を参照）や、並列エージェントのワークフローに関する文章（AI コーディングエージェントにはマネージャーが必要だ を参照）、そして彼によるエージェント型エンジニアリングの捉え方と結びつけている。