「Claude Code」
今回の連載では、何がそんなに衝撃だったのか、結局Agent Teamsは何ができて何が欠点なのか、その現在地に触れながら、今後の可能性を探求していきたいと思います。
Agent Teamsとは
Agent Teams
これまでもメインエージェントとコンテキストの切り離された領域で活躍するエージェントの両方を立ち上げることで、課題解決に対しての精度や効率をあげるSub Agent
それに対してAgent Teamsは
これまでもターミナルでも動作するClaude Codeの平行処理性を利用して、複数のエージェントを立ち上げて連携させて似たような仕組みを実現するライブラリはありましたが、プレビュー機能としてではありますが公式にビルトイン機能として追加され、その動作概念と仕組みをもたらしたのは大きな出来事でした。
何故ならば、マルチエージェントによるワークフローがサービスとして常識化し広がっていく流れを伺わせる事例であり、簡単に言えばLLMが標準で解決できる課題の拡大を感じさせられたためです。それこそがAgent Teamsが衝撃をもって迎えられた一因だと筆者は考えています。
Agent Teamsの導入と使い方
Agent Teamsの機能は2026年2月現在ではまだプレビューフィーチャーであり、デフォルトで無効化されています。
使用するには、環境変数としてCLAUDE_を設定するか、~/.claude/に以下を追加して有効化してください。
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
すぐに試してみたい方は下記のようにターミナルで環境変数と共にClaude Codeを起動することですぐに試すことができます。
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 claude
発動方法は、Claude Codeへのプロンプトの指示の中にチームで行ってくださいやAgent Teamsを使ってくださいなどと指示を入れるだけです。
たとえば以下のようなプロンプトです。
> フロントエンドとバックエンドの繋ぎこみをAPI仕様書に従って、チームで実装を行ってください。
これにより、一例としてフロントエンドとバックエンドのチームが立ち上がり、それぞれが仕様書に基づいて協業を始めます。
Agent Teamsに出てくる概念と仕組み
Agent Teamsが発動すると、メインエージェントはまずチームリーダー(Team lead)となり、その課題をこなすためのエージェント達を生み出します
その後リーダーは彼らがこなすべき共有タスクリスト(Task list)を作ります。
そしてそれらを~/.claude/というディレクトリにJSONファイルとして保存します。
記載されたタスクはそれぞれのチームメイト(Teammate)と呼ばれるエージェントが、タスクをリーダーから割り当てられるか、興味深いことに自発的にタスクファイルをエージェントが排他制御することで担当します。
タスクは保留・
そして、ここがポイントですが、実装が始まると、ほかのチームメイトとも適宜必要な情報をお互いに交換を行います。
Agent Teamsの発動
エージェントの内容や人数もプロンプトで指定することもできます。ざっくりとした指示だけでチームリーダーが判断してチームを準備してくれます。
明示したい場合、たとえば下記のように指定すると、3人のエージェントが誕生します。
> チームで相談し、このディレクトリに歯科医院のランディングページを作ってください。Astro.jsを希望します。ディレクター、デザイナー、コーダー、で実装して下さい。
次のように指示してもAgent Teamsで動いてくれます。
> チームで相談し、このディレクトリに歯科医院のランディングページを作ってください。
Agent Teamsを正しく終了する
実装が完了したら、チームリーダーにシャットダウンをリクエストしてください。
> チームをシャットダウンして下さい。
これにより
次にチームリーダーにチームをクリーンアップすることを指示してください。
> チームをクリーンアップしてください。
これにより共有チームリソースが解放されます。
クリーンアップ前にチームリーダーはアクティブなチームメイトがいないか確認を行うため、必ず事前にシャットダウン指示をする必要があります。
誤って中断した場合
誤って途中でターミナルを切るなどして、チーム全体の作業を中断させてしまった場合、ファイルロックなどで不整合が起きている可能性があります。claude -cなどでセッションを再開して、誤ってシャットダウンしてしまった旨をメインエージェントに伝えた方が良いでしょう。
もし、誤って中断した場合、まだチームメイトが適切なアウトプットできていなかった時や完了ステータスにできていない時は、各タスクリストとそのステータス、会話履歴は残ります。
ですので、セッションを再開した時は、チームリーダーが進捗を確認したのち、そこからの作業再開になります。
実際に筆者も、大規模なマルチレポジトリなコードベースに対する調査と各ディレクトリに対してCLAUDE.
しかし、すでに調査が完了し、会話履歴が残っていたため、そこからAgent Teamの発動を行わずとも、その履歴とチームメイトの調査結果から、チームリーダーが各CLAUDE.
Agent Teamsの特徴
公式ドキュメントを元にこれまでのSub AgentとAgent Teamsの特徴を比較し、まとめてみました。
| サブエージェント | エージェントチーム | |
|---|---|---|
| コンテキスト | 独自のコンテキストウィンドウを持ち、結果は呼び出し元に返される | 独自のコンテキストウィンドウを持ち、完全に独立 |
| コミュニケーション | メインエージェントにのみ結果を報告 | チームメイト同士が直接メッセージをやり取り |
| 調整方法 | メインエージェントがすべての作業を管理 | 共有タスクリストによる自己調整 |
| 適したケース | 結果のみが重要な集中的なタスク | 議論やコラボレーションが必要な複雑な作業 |
| トークンコスト | 低い：結果がメインコンテキストに要約されて返される | 高い：各チームメイトが個別のClaudeインスタンスである |
注目すべきなのはそれぞれが完全に独立しており、共通のタスクリストを持ちながら自己調整を行っていく事です。
この点がこれまでになかったポイントで、Sub Agentは用意されたエージェントにタスクを任せたら
これは原始的なメールのような仕組みを使っていて、Agent Teamsが動いたあとの~/.claude/を見ると面白いのですが、お互いが通信した履歴を見ることができます。
たとえば以下は上述の歯科医のランディングページをAgent Teamsで作ってもらった際のチームリーダーの受信箱
コーダーが最初のタスクを終わって、ディレクターやデザイナーの作成待ちになっていることがわかります。
[
{
"from": "coder",
"text": "コーダーです。Task #3 を担当設定しました。現在 Task #1（ディレクター）がまだ in_progress、Task #2（デザイナー）が pending の状態です。Task #2 が完了次第、実装を開始します。待機中です。",
"summary": "Task #3担当設定、Task #2完了待ち",
"timestamp": "2026-02-08T06:06:07.535Z",
"color": "yellow",
"read": true
}
]
Agent Teamsの欠点
しかし、Agent Teamsはなんでも課題を解決できる魔法の道具ではありません。
特徴や難しさ、欠点を知りうまく使いこなす必要があるのはあらゆるツールと変わりません。
欠点1.管理が難しい
Agent Teamsは各エージェントが協業して動く前提で、タスクの分割はリーダーに、そしてどのように動くかはそれぞれのエージェントの自発性にゆだねられます。
そのため、人は大きな枠組みでの指示管理は行えますが、個別具体な管理までは難しくなります。
これはエージェント全般に言えることではありますが、たとえばいくつかのエージェントが間違った方向に突っ走っていったとしても、作業が完了して
もしエージェントが方向性を間違えたとしたら、LLMの限界ももちろんありますが、それは指示が曖昧であったためであり、個別に修正指示を行っていく必要があります。
パワフルであるからこそ、方向性を誤った時の修正も大変なので、なるべくしっかりと方向性を示せる指示を与えた方がよい、ということになります。
対策1. フィードバックループを生かす
その時に必要になってくるのが
たとえばコーディングさせるなら、静的解析やLintによるフォーマット、テスト、レビューフィードバック、エラーフィードバックの仕組みなどは必須です。
いくら指摘してもへこたれない、というAIの特性を活かして、コードの実装、設計、セキュリティなどあらゆる面で、徹底的にレビューを複数のエージェントに行わせている方もいますが、正しい使い方だと筆者は考えています[1]。
また海外のエンジニアのコミュニティなどをみても、実際に敵対的レビューがコーディング性能を上げる、という事例は多数報告されているようです。
このようにさまざまなエージェントを組織的に動かす以上、
- しっかりと規律で縛る
- 答えを明確にする
- 正しい方向性になるようなフィードバックが効く仕組みにする
といったことが大変重要になります。
最近も
これに関しても、
欠点2.トークンコストが掛かる
通常のエージェントを動かすよりもはるかにトークンコストがかかるので注意が必要です。
公式ドキュメントにもAgent Teamsはチームメイトがplan modeで動いている時、通常と比べて約7倍のトークンが消費される、と言及されています[3]。
それらの対策として、
- Sonnetで動かすこと
- チーム規模を小さく保つこと
- 不要なMCPサーバーを使わないこと
が推奨されています。
対策2. SonnetやHaikuで動かす
SonnetやHaikuで動かす為には、単にプロンプトで下記のようにモデルを指名して指示するのが最も効率が良いです。
> リファクタリングの課題をチームで解決して下さい。チームメイトのモデルにはSonnetを使ってください。
> チームで美容皮膚科のランディングページを作ってください。チームメイトにはHaikuのモデルを使ってください。
メインのモデルをOpusにしておけば、Opusがプランニングや指示、Sonnet
対策3. MCPサーバーをなるべく使わない
またMCPサーバーは注意です。
Agent Teamsでは、チームメイトと言われるエージェントそれぞれが、独立したコンテキストウィンドウをもって動作することになりますが、この際は、CLAUDE.
つまり全くTeamの動作に関係ない機能であっても全員が読み込んでしまい、何倍も無駄にトークンを消費する事になります。ただし、v2.
しかし、コマンドで代替できるようなものはコマンドで、またスキルで代替できるものはスキルで代替しましょう。
たとえばGitHubを操作するのに、GitHubのMCPサーバーではなくghコマンドを使うように指示したり、Google Driveなどを操作するにしても必要な操作だけを行うSkillなどをマーケットプレイスなどからダウンロードするのが望ましいです。
どうしてもチーム全員がそのMCPサーバーを使う必要があるのは稀かと思いますので、Agent Teamsを使う際は無駄なMCPサーバーを外したほうが無難です。
現在立ち上がってるMCPサーバーは/mcpコマンドで、またコンテキストを占有しているMCPサーバーがないかは/contextコマンドで確認することができます。
欠点3. /rewind、/resumeできない
2026年2月現在、Agent Teamsはまだプレビュー機能であり、チームメイトの処理や会話内容は/rewind、/resumeでの巻き戻しや、再開することはできません。
rewindはエージェントが実装したコード内容を、任意のタイミングに戻せる機能ですが、特に一つの指示でパワフルにコードに手を入れる可能性があるAgent Teamsにrewindがないのは注意です。
またresumeによるセッションの再開もないため、Agent Teamsを使うと、タスクや会話履歴以外では、これまでのエージェント操作と比べて埋没やすい、という特性を持っています。
対策3. リーダーはDelegate Modeで権限を委譲する
通常Shift+Tabキーを押すことで、Planモードや、Accept Editsモードを切り替えることができますが、Agent Teamsが発動した時だけDelegateがモードの中に追加されます。
これは基本的にメインエージェントが、実装権限をチームメイトに委譲しプランニングやマネジメントに徹するためのモードです。タスクに対してリーダーであるメインエージェントが下手に実装に走ってしまうことがあるようで、それだとチームを管理できなくなってしまうことがあるため、このモードがあります。
このDelegate Modeは、チームメイトも切り替えることができますので、うっかり実装者なのにDelegate Modeにしてしまわないようにして下さい。
余談ですが、本記事の冒頭の例で示した歯科医院のランディングページを、テストでAgent Teamsで実装してもらった際に、うっかり実装タスクの始まったコーダーにDelegate Modeを適用してしまったことがあり、コーダーがタスクを受け持ったにも関わらず、実装を途中で止めてしまいました。そうすると、コーダーが動かず実装が仕上がらない事に業を煮やしたディレクターが、自分でコーディングを始めて完成させる、という現実のようなでき事が起きました。
このようにDelegate Modeは本来リーダーであるメインエージェントのために用意されたモードですので注意してください。
基本的にはエージェントチームが動き始めたら、チームリーダーであるメインエージェントはDelegate Modeにして仕上がりを待つ事になります。
Agent Teamsの使いどころ
Agent Teamsは大量のコンテキストを消費する代わりに、大規模な課題解決や様々な角度から複数のメンバーが必要な作業に有効です。
Agent Teamsの活用例1. 大規模リファクタリング
まず強みを活かせる道として考えられるのが、大規模なリファクタリングです。たとえばバックエンドフロントエンド両方絡むようなリファクタリングなどが該当します。
筆者の経験でいえば、TypeScriptの在庫管理アプリケーションがあり、開発の止まってしまったAPIスキーマライブラリを使ってバックエンドを構築していました。またフロントエンドはそのライブラリが用意したReactのHooksで型安全に呼べる、というものでした。
このライブラリ自体は素晴らしかったのですが、開発が止まったため他のライブラリのバージョンアップグレードと競合するようになってしまい、アプリケーション自体がこれ以上最新化できない状況となってしまいました。そのため、計画としてなるべく独自実装に依存しないような、Fastifyのネイティブ機能とOpenAPIスキーマに置き換えなければならない、という事例が直近でありました。
これまでであれば、APIスキーマのライブラリの取り外しには大変な痛みを伴ったものでした。
しかし、Agent Teamsを使い
Agent Teamsの活用例2. 新規実装
同様に、新規実装での開発も向いています。
たとえば拙著で書かせていただいた営業日報のアプリケーション開発を新規で行う例などでは、こSub Agentを動かすことも多かったです。ただし、Sub Agentは競合がないように作業領域やタイミングを明確に分けたりする必要がありました。
しかし、Agent Teamsの利点を生かせば、まだタスクの連携においてはバグもあるようではありますが、DBスキーマ設計からマイグレーションをあるエージェントが、API実装を別のエージェントが、バックエンドの実装をもう一つのエージェント、などと、お互いで連絡し合いながら実装をさせることができます。
Agent Teamsの活用例3.コードレビューやバグ調査
そして前述の通りコードレビューにも生かせますし、他にもバグ調査などにも期待できます。大規模なコードベースにおいても、設計視点や規約、セキュリティやパフォーマンスなど異なる視点から複数のメンバーが同時にチェックすることもできます。またバグ調査においても、たとえば本番での表示バグが、DBクエリで起きてるのか、外部のAPI要因で起きてるのか、フロントのミスなのか、などそれぞれのメンバーが同時に調査をしながら、
このように同時並行で多角的かつ網羅的な課題解決が可能になることがAgent Teamsの利点です。
Agent Teamsの表示モード（Teammate Mode）
チームの表示モード
デフォルトでは"auto"となっており、ターミナル環境を自動検知して1画面表示か分割画面表示かを自動で判別します。
"in-process"モードは通常の1画面で動作を行うものです。
Xや記事などで見かける画面分割した状態でTeamの状態を表示させているのが"tmux"モード
1画面での操作方法
Tmuxではない通常のターミナル操作であればin-processモードという、チームメイトの表示の切り替えを一つの画面で行うモードが採用されます。
Agent Teamsが動作している時にShift + ↑を押すことで、チームメイトの一覧が開きます。
そのままShift + ↑もしくはShift + ↓でチームメイトを選択し、Enterで詳細を見たり、追加プロンプトをチームメイトに入れたりすることができます。
分割ペインで動かす
分割ペインで動かす方がチームの働きや通信のやり取りがわかりやすくなります。
たとえば筆者の経験では、チームメイトとチームリーダーとの通信がうまくいかず、チームメイトはタスクを終えたのに、リーダーがタスク完了を受信できず、完了待ちのまま止まってしまうことなどがありました。
このような場合、分割表示で全体を見た状態で、個別に確認・
特にAgent Teamsの作業はブラックボックス化しやすいため、分割表示で見た方が管理効率が高いです。
Tmuxの準備
Tmuxは拙著でも書きましたが、ターミナルマルチプレクサと言われるターミナルの分割やマルチペイン操作を行うライブラリです。
Tmuxは歴史も古くエンジニアの間でスタンダードな存在であるため、Claude Codeの並行処理において、Tmuxで動かす前提で考えられている部分があります。
sudo apt install tmux
brew install tmux
上記でインストールできない方やgitからバージョン指定してインストールしたい方は以下を実行してください。
git clone https://github.com/tmux/tmux.git cd tmux sh autogen.sh ./configure make && sudo make install
これによりAgent Teamsで画面分割が使える準備が整います。
Agent Teamsを分割ペインで動かす
基本的にはTmuxセッション内では"tmux"モードとなり、分割ペインで複数画面を使って動くようになります。
tmux
これでターミナル下部に緑の帯が出てたらTmuxの起動成功です。
ここからclaudeコマンドでClaude Codeを立ち上げましょう。
この状態でチームでなどのプロンプトを加えると、リーダーがチームメイトをスポーンし、タスクを作り始めます。
あとは何もしなくてもチームメイトが無事動き始めれば分割モードで表示され始めます。
Tmuxのペインの移動はマウスではなく、基本的にキーボードでの操作が必要です。
デフォルトではCtrl + bを押した後にoや矢印キーを押すことで、ペインを移動することができます。
Teammate Modeの設定を固定する
例えばTmuxで動かしていて、1画面で動かしたいときはTeammate Modeを固定することができます。
例えばsettings.
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
},
"teammateMode": "in-process"
}
と記述するか、
claude --teammate-mode in-process
のコマンドライン引数で固定できます。
iTerm2で画面分割を行う
なお、Mac専用のターミナルソフトであるiTerm2でも、特定の操作をすれば、分割画面が可能です。Macを持っていて、キーボード操作がメインのTmuxが苦手な方はこちらの方が操作はしやすいかもしれません。
iTerm2を持っていない方はソフトウェアをダウンロードしてMacにインストールしてください。
通常のMacのターミナルよりも便利な機能がある他、日本語表示にも対応しています。
次にiTerm2のCLIをインストールします。
以下はPCへグローバルインストールしています。
uv tool install it2
その上でiTerm2を開いて設定を有効にします。
iTerm2 → Settings → General → Magic → Enable Python API で Python API を有効
注意点としては、iTerm2で画面分割を行う時はTeammate Modeを明示的に"tmux"にする必要があります。
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
},
"teammateMode": "tmux"
}
もしくはこれまでと同じように下記のように指定できます。
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 claude --teammate-mode tmux
この状態で下記のように指示してみます。
> チームで小児科のランディングページを作ってください。モデルはHaikuでお願いします。
無事デザイナーとコンテンツライターのチームができ上がり、分割画面で協働を始めました。
その後フロントエンド開発者も加わってランディングページを作成してくれました。
iTerm2の場合画面をクリックするだけでペインを移動できるので、直感的に操作しやすいかと思います。
最終的に下記のように、フロントエンド開発者がタスクを完了したにも関わらず、チームリーダーがそれを受信できずに、しばらく待ちの状態になってしまいました。
個別にプロンプトを入れることができるため、フロントエンド開発者には
Agent Teamsの今後
LLMの課題解決においてはエージェンティックワークフローなど複数のエージェントが連携する事で課題を解決することがサービスレベルでは当たり前になりつつあります。
しかしそれらはどちらかというと課題に対してエージェントAが担当したものをエージェントBが、次にエージェントCが作業する、という一方向の線形の解決フローでした。
Agent Teamsがもたらすマルチエージェントは相互通信を使った、まさにコラボレーションというべき共同作業です。
それぞれがタスクを受け持ち、理解した内容を通信し、必要な情報を連携し、課題に取り組む社会性というべき姿を持っています。
Agent Teamsは現時点ではまだ原始的なP2P通信であり、連携に問題が見られることもあります。しかし、これらがよりシームレスに、かつ精緻に連携しながら自律的にタスクを作り、分担しこなしていていく時、LLMのさらなる実力が爆発的に発揮されていくように思います。
その未来の潮流に立ち会うことが筆者は楽しみでなりません。
イベント：Claude Code Meetup Japan #3
著者の平川さんが登壇する対面・
AI駆動開発の最先端を走る開発者の皆様が、AI技術を使った開発に興味を持つ方々向けに、GitHub CopilotやCursor, Claude Code, WindsurfなどのAIツールを使った開発のノウハウや、AIによる開発プロセスの最適化、生成AI・
なお、参加には事前にconnpassでの登録が必要です。皆様、ぜひご参加ください。