Claude Code Agent Teams をどう使うか? サブエージェントの課題から考える
こんにちは、StoreHero で CPO をしている永田です。
2026年2月5日、Claude Code v2.1.32 がリリースされました。目玉機能は Agent Teams です。複数の Claude Code インスタンスがチームとして協調動作する仕組みで、従来のサブエージェントとは設計思想が異なります。
まだ Research Preview なので実戦投入はしていませんが、普段サブエージェントを使う中で感じていた課題と照らし合わせながら、使い道を考えてみました。
Agent Teams の概要
機能の簡潔な説明
Agent Teams は、複数の Claude Code インスタンスをチームとして動かす機能です。1つのセッションが「チームリード」となり、他のインスタンスが「チームメイト」として参加します。
従来のサブエージェントとの大きな違いは2つあります。チームメイト同士がリードを経由せず直接メッセージをやり取りできること。そして、ユーザー自身がチームメイトに直接指示を出せることです。調整には共有タスクリストが使われ、タスクの依存関係や状態管理も組み込まれています。
利用条件
Agent Teams は Research Preview として提供されています。実験的機能であり、今後破壊的な変更が入る可能性があります。利用には Claude Code v2.1.32 以上と、環境変数による有効化が必要です。
settings.json に以下を追加します。
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
なお、各チームメイトが独立した Claude インスタンスとして動くため、トークン消費量はチームメイトの数に比例して増えます。単一セッションやサブエージェントと比べて大幅にコストが上がるので、利用時は注意してください。
サブエージェントとの違い
比較表
公式ドキュメントに基づく比較です。
| サブエージェント | Agent Teams | |
|---|---|---|
| コンテキスト | 独自のコンテキストウィンドウ。結果はメインに返る | 独自のコンテキストウィンドウ。完全に独立 |
| コミュニケーション | メインエージェントにのみ結果を返す | チームメイト同士で直接メッセージング |
| 調整方式 | メインエージェントが全作業を管理 | 共有タスクリストで自律的に調整 |
| 向いている場面 | 結果だけが重要な集中タスク | 議論・協調が必要な複雑な作業 |
| トークンコスト | 低め(結果がメインに要約される) | 高め(各チームメイトが独立したインスタンス) |
端的に言えば、サブエージェントは「結果だけ返す作業者」で、Agent Teams は「議論しながら協調する独立したメンバー」です。
サブエージェントに感じていた限界
比較表だけでは伝わらない部分があります。私がサブエージェントを使う中で感じていた3つの課題を書いておきます。
1つ目は、サブエージェントの不透明さです。サブエージェントは結果を返してくれますが、途中でどんな手順を踏んでいるのか、細かく追うことができません。うまく進んでいるのか、変な方向に逸れていないか。その不安を抱えたまま完了を待つしかありませんでした。Agent Teams では Shift+Up/Down でチームメイトの作業を直接確認できます。
2つ目は、割り込みができないことです。サブエージェントの作業中に「やっぱりこの方針で」と伝えたくても、介入する手段がありません。Agent Teams ならチームメイトに直接メッセージを送れるので、方針転換にも柔軟に対応できると期待しています。
3つ目は、用途の限界です。サブエージェントはコンテキストの重い処理をオフロードするのに向いています。しかし、複数の役割が連携するオーケストレーションには不向きでした。「PM 視点の検討」と「エンジニア視点の検討」を並行して走らせ、突き合わせるような使い方は設計に合いません。Agent Teams はまさにそのオーケストレーションのための仕組みです。
Agent Teams の使い道を考える
上流工程でのブレインストーミング
設計フェーズで、PM・アーキテクト・Devil's Advocate・ユーザー代弁者・セキュリティレビュワーといった複数の役割を持たせたチームメイトに議論させるのは相性がよさそうです。議論の結果を Design Doc や技術仕様書としてまとめる流れも自然です。
上流工程のアウトプットはテキストが中心なので、ファイル競合のリスクが低い点も利点です。「独立並行で議論し、リードが統合する」という Agent Teams の構造がそのまま活きます。
API 設計のフロント/バック協調
バックエンドとフロントエンドの2つの視点から Swagger/OpenAPI の設計を進めるケースです。チームメイト同士のメッセージングで設計の齟齬を解消し、合意後にそのまま並行実装に移れます。
従来のサブエージェント構成だと、フロントとバックの間にメインエージェントが挟まり、やり取りが迂遠でした。Agent Teams で直接対話できる点に価値があります。
記事執筆ワークフローの改善
私は Claude Code で記事を書くとき、リサーチ、構成、執筆、ファクトチェックといった工程をサブエージェントに分担させることがあります。ただ、この方式だと著者(私)がサブエージェントに直接指示を出せません。「私 → メイン → サブエージェント」という経路を往復する必要がありました。
Agent Teams なら、私がリードとなり、リサーチャー・ライター・ファクトチェッカーに直接指示を出せます。「ここのトーンを変えて」「この情報を追加調査して」といったフィードバックが即座に届きます。
ナレッジベースの並行整備
私の会社では、マーケティング施策や運用オペレーションなど、領域ごとのナレッジベースを Claude Code で整備しています。現状はドメインごとに1セッションずつ進めています。Agent Teams を使えば、1つのセッションの中で複数ドメインを並行して整備しつつ、リードが全社共通のトーンやルールの統一を保つ構成が取れます。品質基準をリードが握り、各チームメイトが担当領域を進める形です。
おわりに: Claude Code の進化と OSS エコシステム
Claude Code の進化速度は異常です。この速さが、便利な OSS ツールの採用をためらわせる要因にもなっています。
たとえば、multi-agent-shogun という面白いツールがあります。
侍をテーマにしたマルチエージェント管理ツールです。将軍(戦略調整)、家老(タスク分解)、足軽(8並列ワーカー)の三層構造で、tmux とファイルベース通信により複数の Claude Code を制御します。エージェント同士が武家言葉で会話するエンタメ性も魅力です。私はこのツールを応援していますし、作者の発想力に敬意を持っています。
しかし、Agent Teams が公式にリリースされた今、そのコア機能はカバーされつつあります。公式機能の高速な進化が OSS の陳腐化を早めるというジレンマは、Claude Code エコシステム全体に共通する課題です。
Agent Teams はまだ Research Preview の段階です。実際に使い込んでみて、次回はレビュー記事を書きたいと考えています。
まとめ
- Agent Teams は複数の Claude Code インスタンスが独立して協調動作する仕組みです。v2.1.32 から Research Preview として利用できます
- サブエージェントとの最大の違いは、チームメイト同士の直接メッセージングと共有タスクリストによる自律的な調整にあります
- 上流工程のブレインストーミングや API 設計の協調など、テキストベースの議論が必要な場面に向いています
- トークン消費量の増加やセッション再開不可など、制約も把握した上で使う必要があります
- Claude Code の進化速度は OSS エコシステムにも影響を与えており、Agent Teams はその一例です
追記
Agent teams のコストと性能に関する調査記事を書きました。
Discussion