Agent Teams - Claude Code セッションのチームオーケストレーション

 (code.claude.com)
29 ポイント 投稿者 GN⁺ 2026-02-06 | 2件のコメント | WhatsAppで共有
  • 複数のClaude Code インスタンスを1つのチームとして構成し、並列で作業を分担・調整する実験的機能で、リードセッションがチームメンバーを作成し、作業を割り当て、結果を統合
  • 既存のサブエージェントと異なり、チームメンバー同士で直接メッセージをやり取りでき、ユーザーもリードを介さず個々のメンバーと直接やり取り可能
  • コードレビュー、デバッグ仮説の並列探索、フロントエンド・バックエンド・テストなどのクロスレイヤー作業に効果的で、逐次作業や同一ファイルの修正には単一セッションのほうが適している
  • 各メンバーが独立したコンテキストウィンドウを持つため、トークン使用量が大きく増加し、メンバー数に比例してコストが拡大する可能性がある
  • tmux または iTerm2 による分割画面モードをサポートし、並列探索と協業の自動化を通じて複雑な開発作業の生産性と品質向上を支援

Agent Teams の概要

  • 複数の Claude Code セッションを1つのチーム単位で調整し、並列で作業を実行
    • チームリードが作業を分配し、結果を統合
    • 各チームメンバーは独立したコンテキストウィンドウで個別に実行
  • Subagent と異なり、メンバー間で直接メッセージングが可能
  • 実験的機能のためデフォルトでは無効で、CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS 環境変数を設定して有効化

Agents Teams を使うのに適した場面

  • リサーチとレビュー: 複数のメンバーが問題の異なる側面を同時に調査し、その後に結果を共有して相互検証
  • 新しいモジュールや機能の開発: 各メンバーが別々のファイル/モジュールを担当し、競合なく並列作業
  • 競合仮説ベースのデバッグ: 異なる仮説を同時にテストして、原因をより迅速に特定
  • クロスレイヤー調整: フロントエンド、バックエンド、テストなどレイヤーごとにメンバーを配置して同時に変更
  • 逐次作業、同一ファイルの編集、依存関係の多い作業には、単一セッションまたはサブエージェントのほうが効率的

Subagent vs. Agent Team

  • サブエージェント: 独自のコンテキストウィンドウを持つが、結果は呼び出し元にのみ返される。メインエージェントがすべての作業を管理し、トークンコストは比較的低い
  • エージェントチーム: 完全に独立したコンテキストウィンドウを持ち、メンバー同士で直接メッセージを交換でき、共有タスクリストで自律的に調整。各メンバーが個別の Claude インスタンスであるため、トークンコストは高い
  • 結果だけが必要な集中作業にはサブエージェント、メンバー間の議論や協業が必要な複雑な作業にはエージェントチームが適している

最初のエージェントチームを始める

  • デフォルトでは無効で、CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS 環境変数を 1 に設定するか、settings.json に該当の環境変数を追加して有効化
  • 有効化後、自然言語でチーム構成と作業を説明すると、Claude がチームを作成してメンバーをスポーンし、作業を調整
    • > I'm designing a CLI tool that helps developers track TODO comments across their codebase. Create an agent team to explore this from different angles: one teammate on UX, one on technical architecture, one playing devil's advocate.
    • TODO 追跡用 CLI ツールを設計するにあたり、UX、技術アーキテクチャ、反対意見の役割を持つ3人のメンバーにそれぞれ独立して検討させ、その結果を統合する
    • こうすると Claude は共有タスクリストを用意し、各メンバーを作成してそれぞれの課題を検討させ、結果を統合し、作業完了後にチームをクリーンアップしようと試みる
  • リード端末にはチームメンバーの一覧と作業状況が表示され、Shift+Up/Down でメンバーを選択して直接メッセージを送信可能

エージェントチームの制御

  • 表示モードの選択

    • In-process モード: すべてのメンバーがメイン端末内で実行され、Shift+Up/Down でメンバーを選択してメッセージ送信可能。追加設定は不要
    • Split panes モード: 各メンバーが別々のペインに表示され、出力を同時に確認可能。tmux または iTerm2 が必要
    • 既定値 "auto" は、tmux セッション内で実行中であれば split pane、それ以外では in-process として動作
    • "tmux" 設定時は split-pane モードを有効にし、tmux と iTerm2 を自動検出
    • settings.json の teammateMode で上書きするか、claude --teammate-mode in-process フラグで単一セッション設定が可能

  • メンバー数とモデルの指定

    • Claude は作業に応じてメンバー数を自動決定するが、"Create a team with 4 teammates" のようなコマンドで正確な人数やモデル（例: Sonnet）を直接指定可能

  • プラン承認の要求

    • 複雑またはリスクの高い作業では、メンバーに読み取り専用のプランモードを適用し、リードが承認するまで実装をブロック
    • メンバーがプランを完成させるとリードに承認を要求し、リードが承認すれば実装を開始、却下された場合はフィードバックを反映して再提出
    • リードの判断基準はプロンプトで条件を示して影響を与えられる（例: "テストカバレッジを含むプランのみ承認"）

  • 委任（Delegate）モード

    • リードが自ら実装する代わりに、調整専用ツール（メンバーのスポーン、メッセージ送信、終了、タスク管理）のみを使うよう制限
    • チーム開始後に Shift+Tab を押して委任モードへ切り替え

  • メンバーとの直接対話

    • 各メンバーは完全に独立した Claude Code セッションなので、追加指示、追質問、方針変更などを直接伝えられる
    • In-process モードでは Shift+Up/Down で選択してメッセージ送信、Enter でセッション確認、Escape で現在のターンを中断、Ctrl+T でタスクリストを切り替え
    • Split-pane モードでは該当ペインをクリックして直接操作

  • タスクの割り当てとクレーム

    • 共有タスクリストを通じてチーム全体の作業を調整し、タスク状態は pending、in progress、completed の3段階
    • タスク間の依存関係を設定でき、未解決の依存関係があるタスクはクレーム不可
    • リードが明示的にタスクを割り当てることも、メンバーが完了後に次の未割り当て・未ブロックのタスクを自動クレームすることも可能
    • 複数のメンバーが同時に同じタスクをクレームするのを防ぐため、ファイルロックを使用

  • メンバーの終了とチームのクリーンアップ

    • リードが特定のメンバーの終了を要求すると、メンバーは承認または拒否（理由を説明）できる
    • チームのクリーンアップ時にはリードが共有チームリソースを削除し、アクティブなメンバーが残っているとクリーンアップに失敗するため、先にメンバーを終了させる必要がある

エージェントチームの内部動作

  • チーム開始の経路

    • ユーザーがチームを要求: 並列作業に適したタスクを説明し、明示的にエージェントチームの作成を要求
    • Claude がチームを提案: Claude が作業特性上、並列処理が有利だと判断した場合にチーム作成を提案し、ユーザー確認後に進行
    • いずれの場合も、ユーザー承認なしにチームは作成されない

  • アーキテクチャ構成要素

    • Team lead: メインの Claude Code セッション。チーム作成、メンバーのスポーン、作業調整を担当
    • Teammates: 個別の Claude Code インスタンスで、それぞれ割り当てられたタスクを実行
    • Task list: メンバーがクレームして完了する共有作業項目リスト
    • Mailbox: エージェント間通信用のメッセージングシステム
    • タスク依存関係は自動管理され、あるメンバーがタスクを完了すると、ブロックされていたタスクが手動介入なしでアンブロックされる
    • チーム設定は ~/.claude/teams/{team-name}/config.json、タスクリストは ~/.claude/tasks/{team-name}/ にローカル保存
    • config には members 配列が含まれ、各メンバーの名前、エージェント ID、エージェントタイプが記録される

  • 権限

    • メンバーはリードの権限設定を継承して開始し、リードが --dangerously-skip-permissions で実行された場合はすべてのメンバーにも同様に適用
    • スポーン後に個々のメンバーのモード変更は可能だが、スポーン時点でメンバーごとの権限設定はできない

  • コンテキストとコミュニケーション

    • 各メンバーは独立したコンテキストウィンドウを持ち、スポーン時に CLAUDE.md、MCP サーバー、スキルなど通常セッションと同じプロジェクトコンテキストを読み込む
    • リードの会話履歴はメンバーに渡されず、スポーンプロンプトのみが渡される
    • 自動メッセージ配信: メンバーが送ったメッセージは受信者に自動配信され、リードがポーリングする必要はない
    • アイドル通知: メンバーが作業を終えて停止すると、リードに自動通知
    • 共有タスクリスト: すべてのエージェントがタスク状態を確認し、利用可能な作業をクレームできる
    • メッセージング方式にはmessage（特定のメンバー1人宛て）と broadcast（チーム全体宛て。コストはチーム規模に比例するため節度が必要）がある

  • トークン使用量

    • エージェントチームでは単一セッションに比べてトークン使用量が大幅に増加し、アクティブなメンバー数に比例して増える
    • リサーチ、レビュー、新機能作業では追加のトークンコストは通常妥当だが、ルーチン作業には単一セッションのほうが費用対効果が高い

利用例

  • 並列コードレビュー

    • 単一のレビュアーは一度に1種類の問題に集中しがちなため、レビュー基準をセキュリティ、性能、テストカバレッジなどの独立したドメインに分割
    • 各レビュアーが同じ PR に異なるフィルターを適用し、リードが完了後に全体結果を統合

  • 競合仮説ベースの調査

    • 単一エージェントは1つの説明を見つけると探索を打ち切りがちなため、メンバーを明示的に対立的な構成にする
    • 各メンバーが自説を調査しながら、同時に他のメンバーの理論を反証しようとする科学的討論方式
    • 逐次調査で生じるアンカリングバイアスを防ぎ、最後まで残った理論が実際の根本原因である可能性を高める

ベストプラクティス

  • メンバーに十分なコンテキストを提供する: プロジェクトコンテキストは自動読み込みされるが、リードの会話履歴は渡されないため、スポーンプロンプトに作業関連の詳細を含める必要がある
  • タスクサイズを適切に調整する: 小さすぎると調整オーバーヘッドが利点を上回り、大きすぎるとチェックインなしで長時間作業して無駄が増える。関数、テストファイル、レビューなど、明確な成果物を生む自己完結型の単位が適している
  • リードがメンバーの代わりに直接実装を始めた場合は、"Wait for your teammates to complete their tasks before proceeding" と指示
  • 初めて使う場合は、コード作成を伴わず境界が明確なリサーチとレビュー作業（PR レビュー、ライブラリ調査、バグ調査など）から始める
  • ファイル競合の防止: 2人のメンバーが同じファイルを編集すると上書きが発生するため、各メンバーが異なるファイル集合を担当するようにタスクを分割
  • メンバーの進捗を定期的に確認し、効果のないアプローチは方向転換させ、結果が出たら随時統合する

トラブルシューティング

  • メンバーが表示されない場合: in-process モードでは Shift+Down でアクティブメンバーを順に切り替え、作業がチーム編成に十分複雑かを確認し、split pane を要求している場合は tmux が PATH にインストールされているかを確認。iTerm2 の場合は it2 CLI のインストールと Python API の有効化を確認
  • 過剰な権限プロンプト: メンバーの権限要求はリードにエスカレーションされるため、メンバーをスポーンする前に権限設定で共通作業を事前承認しておく
  • メンバーがエラー後に停止する場合: 当該メンバーの出力を確認したうえで追加指示を直接出すか、代替メンバーをスポーンして作業を継続
  • リードが作業完了前に終了した場合: リードに継続するよう指示するか、委任前にメンバーの完了を待つよう設定
  • 孤立した tmux セッション: チーム終了後に tmux セッションが残っている場合は tmux ls で確認し、tmux kill-session -t <session-name> で削除

制約事項

  • In-process メンバーのセッション復元不可: /resume と /rewind では in-process メンバーを復元できず、復元後にリードが存在しないメンバーへメッセージを送れる場合があるため、新しいメンバーをスポーンする必要がある
  • タスク状態の遅延: メンバーがタスク完了をマークしないことで依存タスクがブロックされる場合があり、手動で状態を更新するか、リードにメンバーへの催促を依頼
  • 終了の遅延: メンバーは現在の要求またはツール呼び出しを終えてからでないと終了しない
  • セッションごとに1つのチームのみ可能: 新しいチームを開始するには、現在のチームを先にクリーンアップする必要がある
  • ネストしたチームは不可: メンバーは自分自身のチームやメンバーをスポーンできず、チーム管理はリードのみ可能
  • リード固定: チームを作成したセッションがそのチームの恒久的なリードであり、メンバーをリードに昇格したりリーダーシップを移譲したりはできない
  • スポーン時の権限一括設定: すべてのメンバーはリードの権限モードで開始し、スポーン時点でメンバーごとの権限設定はできない
  • Split pane には tmux または iTerm2 が必要: VS Code 統合ターミナル、Windows Terminal、Ghostty では split-pane モードは未対応

関連記事

2件のコメント

 
kuthia 2026-02-06

マルチエージェントのオーケストレーションでは、コンテキスト圧縮の過程で意味論的な結果をどう保存するかが重要になってきそうですね。認知科学みたいです。
 
GN⁺ 2026-02-06
Hacker Newsの意見

  • この1年間のイノベーションが主に エンジニアリング中心 に進んできたのは興味深い
    MCP、agent、skill など新しい概念が次々に出てきたが、依然として 幻覚・不正確さ・文脈崩壊 といった根本的な問題は解決されていない
    こうした問題は単なるエンジニアリングではなく、基礎研究 でしか解けない気がする
    今の改善や発表は、投資家の期待を維持するための ハイプサイクル の一部のように感じる
    正直、AI というナラティブにはもう疲れていて、この技術が実際にどこで役立つのかが明確になる段階へ早く進んでほしい

  • こういう機能はかっこいいが、一日中 agent を回せる人がどれだけいるのかという疑問がある
    Cursor を使っていて トークン消費量 が大きすぎたので Ultra にアップグレードしたが、利用量が比例していない感じがする
    幸い、オープンソース LLM 陣営が急速に追いついてきているので希望はある

    • 自分は Claude Max の月 200 回の上限さえ使い切れない。毎日コーディングしてかなり重い作業をしていてもそうだ
    • こういうのは事実上 実験段階 なので、Gas Town のように失敗する可能性もある
    • 多くの会社は年収 15 万ドルのジュニアエンジニアを雇える。AI のサブスク料金がそれより高いなら問題だ
      しかも今話しているのは Cursor ではなく Claude Code だ。むしろ Claude Max を使ってみることを勧める
    • こういうものを一日中回せるのは VC 資金を受けた 2 人組スタートアップ くらいだと思う
    • Claude Code Max は トークン単価比で 30 倍の価値 があるので、使い切れないなら本人の責任だ。電気代より安いかもしれない

  • Steve Yegge は以前、Anthropic のような会社に agent orchestrator のアイデアを提案していた
    (Welcome to Gas Town)
    Anthropic が今 Agent Teams を出したのを見ると、当時から準備していたか、同じ結論にたどり着いたようだ
    いずれにせよ Steve のビジョンが 検証されたようなもの で興味深い。もうすぐ「polecat を飼いならす」シーズンが来るかもしれない

    • 自分も GasTown や Beeds は知らなかったが、似たものを作った。あまりにも 自然な次の段階 だった
      claude-code-orchestrator
    • 自分も GasTown ブームの前に簡単な agent チーム構造 を作ってみた。複数の Claude インスタンスを tmux セッションで動かし、.claude.lock で同期していた
      かなりうまく動いたが、まだ効率的ではない。仕様作成の速度と QA 品質がボトルネックだ
    • 実際のところ、こういう構造は actor フレームワーク では既に存在していた概念だ。Akka のようなシステムと比べれば新しいものではない
      LLM provider たちがようやくこういうことを学んでいるのを見ると、リアルタイムで成長中 なのだと感じる
      Kubernetes for agents という表現も大げさではない。自分もローカルでそういう形につないで使っている
    • Anthropic のエンジニアたちがこうしたアイデアを知らなかったはずがないと思う。ChatGPT 初期からこういう話は多かった
    • 実際、こうした multi-agent システム は 2023 年から arxiv や GitHub にたくさんあった
      当時はモデルがそこまで賢くなく、context window も小さかっただけで、今は十分可能になったというだけだ

  • 自分は複数の Claude Code インスタンスを tmux ベースの CLI agent として動かして協調させるワークフローを使ってきた
    今回の orchestration 機能 は共通の task list を共有し、メイン agent が調整してくれるので、ずっと実用的だ
    tmux-cli ツール で agent 間の協業を自動化できる

  • こういう機能はいずれ 標準で内蔵 されるのが明らかだったので今まで学ばなかったが、もう試すタイミングのようだ

  • 自分の月額 $20 のサブスクでは 10 分も持たないのではという不安がある

    • 個人で直接支払うなら Kimi や GLM を使うほうが合理的だ
    • 自分も同感だ。こういう構造が実際に 価値を生み出せるのか 疑問がある
    • 特定の作業では Haiku がかなり良い結果を出した

  • これは Gas Town に似て見える

    • プロジェクトがあまりに 奇妙だったり悪ふざけっぽく なったりすると、結局もっと幼稚でないクローンが出てきて勝つ可能性が高い
    • でも polecat はどこへ行ったのか、市場のユーモア感覚が気になる
    • Gas Town が何なのかは知らないが、自分はすでに Claude Code Agent Teams に近い構造を使ってきた
      メインの会話から 下位 agent を生成して作業を分割すれば、文脈を失わずに長時間働かせられる
    • デザインはもっとシンプルに見える。リーダー agent 1 つと複数 worker の構成で、Gas Town の複雑な役割体系よりすっきりしている
    • ただし polecat がいない点 は残念だ

  • 自分は Claude Code を 大きな作業に独立して任せることはできない
    コード品質を保つには設計プロセスに自分で直接介入しなければならない
    agent チームはむしろレビューとリファクタリングの負担を増やすだけに思える

    • コードベースの構造やパターン利用ルールを skill としてエンコード すれば、sub-agent にそれを監督させることができる
      こうして計画・設計・QA・レビュー agent を分けて協調させるのが、まさにこの機能の本質だ
    • Claude 内で 敵対的モデル を作って品質を上げる方法もある。1 つの agent が修正し、別の agent が検証する形だ
    • 人間も大きな仕事は分割して処理するように、Claude に 計画とテスト基準 を立てさせれば効率的だ
    • 実際には 3〜4 回に 1 回は チューニングや中断 が必要になる。熟練者だけがそれに気づく
    • LLM のタスク分割と結果統合に関する 研究 も進んでいる
      関連論文

  • 自分は Opus をメインに、下位 agent は Gemini や Codex で動かす マルチ LLM オーケストレーション を探している

    • こうした構造をサポートするツールとして Coder-Codex-Gemini、ccg-workflow、claude_code_bridge がある
      どれも 中国人開発者 が作ったプロジェクトだが、使ってみた結果かなり優秀だった
    • AgentWorkforce/relay を使えば、好きな LLM を リード/オーケストレーター に指定できる
      関連する体験を Twitter の投稿 にまとめた
    • 自分は Opus でコーディングし、Codex でレビューしている。各タスクごとに review skill を呼び出して Codex を実行する
      review skill コード、Greptile PR アナライザー も併用している
    • 今後 Cursor がこうした マルチモデル協調機能 をサポートすれば本当に便利だと思う
    • Pied-Piper の例のように、
      GPT-5.2 Codex Max で計画、Opus 4.5 で実装、Gemini でレビューを担当させる構成も可能だ

  • 自分は Beads の代替を自作しているうちに、最終的には似た構造の GitHub プロジェクトと同期される agent システム を完成させた
    近くオープンソースとして公開する予定で、長期的には チケットシステムと連携 するほうがより有用だと思う
    agent に依存しない agnostic な代替 が増えるのが望ましい