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 は「議論しながら協調する独立したメンバー」です。

サブエージェントに感じていた限界

比較表だけでは伝わらない部分があります。私がサブエージェントを使う中で感じていた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 という面白いツールがあります。

https://zenn.dev/shio_shoppaize/articles/5fee11d03a11a1

侍をテーマにしたマルチエージェント管理ツールです。将軍（戦略調整）、家老（タスク分解）、足軽（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 のコストと性能に関する調査記事を書きました。

https://zenn.dev/storehero/articles/1ecfe362962766

参考資料

• Claude Code Agent Teams ドキュメント
• Claude Code CHANGELOG (v2.1.32)
• Anthropic Releases Opus 4.6 with Agent Teams - TechCrunch
• multi-agent-shogun 紹介記事