はじめに
株式会社ネクストスケープ Chief Technology Office所属の小野塚です。
先月2月5日にClaude Code Agent Teamsという機能がAnthropicから発表されました。
Agent（エージェント）、そしてTeamsという言葉からなんとなくサブエージェントのようなものね、とスルーしていましたが、改めて見てみるととても興味深い内容でしたので試した内容を書いておきます。
Agent Teams、単純に言えば複数エージェントを管理してくれる機能なのですが、それだけ聞くとサブエージェントとの違いがわからないと思うので、まずはその違い・比較を以てAgent Teamsの概要を説明したいと思います。
（そもそもサブエージェントも取り上げようと思いつつ取り上げていないのでタイミングがあれば別途。。）
まずはサブエージェント型。
図に表すと以下のようになると思います。
サブエージェント型の特徴としては
・メインエージェントが 子エージェントを生成
・各エージェントが 独立して作業
・結果を メインエージェントに返す
といったものが挙げられます。１つのエージェントで処理することでコンテキストの肥大化が起き、推論の遅延が発生するのを抑えられるのがメリットです。
ではエージェントチームはどうなのか。
図にすると以下の通り。
エージェントチームの特徴としては
・エージェントが 「チームとして」動く
・タスクを 共有リストから取得
・エージェント同士で 情報共有
というものになります。
他の表現としてはサブエージェントが親子構造、エージェントチームがチーム構造、あるいはサブエージェントがタスク分割型、エージェントチームが協働型という表現ができるかなと思います。
では、上記の違いで何が良いのか、これは公式ドキュメントの以下の部分に集約されると思います。
"When the root cause is unclear, a single agent tends to find one plausible explanation and stop looking."
"Sequential investigation suffers from anchoring: once one theory is explored, subsequent investigation is biased toward it."
"With multiple independent investigators actively trying to disprove each other, the theory that survives is much more likely to be the actual root cause."
直訳は以下。
「根本原因が不明な場合、単独の調査担当者は一つの妥当な説明を見つけ出すと、それ以上探求を止めがちである。
順次的な調査はアンカリング効果に陥りやすい：一度ある仮説を検証すると、その後の調査はその仮説に偏る。
複数の独立した調査担当者が互いの仮説を積極的に反証しようとする状況では、生き残った仮説が実際の根本原因である可能性がはるかに高くなる。」
複数エージェントがチェックし合うことによる品質の向上、というところが今回のエージェントチームのメリットのようですね。
準備・設定
では、実際に試してみたいと思います。
オンラインドキュメントにも書かれているのですが、エージェントチームはまだ試験運用中のものでして、デフォルトでは無効になっています。
そこでsetting.json内に以下のように環境変数を設定することで有効にできます。
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
あとは表示モードとして２つのモードがあります。
・インプロセス：
すべてのチームメイトはメインターミナル内で実行されます。Shift+↓キーでチームメイトを切り替え、直接メッセージを送信できます。どのターミナルでも動作し、追加の設定は不要です。
・分割ペイン：
各チームメンバーに専用のペインが割り当てられます。全員の出力を一度に確認でき、ペインをクリックして直接操作できます。tmuxまたはiTerm2が必要です（つまりMac、Linux推奨）。
今回はWindowsでの動作になるのでインプロセスになります。自動検出でもいいのかもしれませんが、以下のように起動することで強制的にインプロセスモードで起動します。
claude --teammate-mode in-process
実行
では早速実行してみましょう。以下のプロンプトを投げてみます。
「ToDoアプリを作るエージェントチームを作ってください。
PMが要件定義、バックエンドがAPI実装、フロントエンドがUI実装、QAがテストを担当する構成で。」
まずは以下のようにチームを作成し、メンバーの招集が始まります。
指示した通り４つのエージェントが招集（作成）されます。
チームの立ち上げが完了し、実行フローと、
成果物が示されます。
そして作業に入ります。まずはPMが要件定義を作成します。
以下のように各メンバーの状況が表示されます。
以下の状況ではteam-lead、直訳ですがチームを導く担当が要件定義・設計を進めているのがわかります。
時々通常のやり取りのように質問・確認が出てきますが、「Bash commad」のあとに「@backend」と表示されているのがわかるかと思います。
これがどのメンバーからの質問・確認かを表しているものになります。
なので質問・確認するメンバーが変わるとその部分が変わります。以下は「@frontend」なのでフロンエンド担当ですね。
そして以下のように完了しまして、以降は割愛しますがToDoアプリの起動も確認できました。
ちょっとインプロセスでの動作だったので少々分かりづらかったかもですが、このように各エージェントが非同期で処理を進めてくれます。また、今回は行なえませんでしたが、各チームのメンバーに対して個別に指示を出すこともできます。
注意点
と、このように一歩進んだ動きをしてくれるこのエージェントチームですが、現時点ではトークンの消費が激しいので注意してください。
公式のオンラインマニュアルでこのトークンの消費を抑えるための対応方法として書かれている内容を幾つか抜粋します。
１．チームメイトにはモデルとしてSonnetをご利用ください。調整タスクの能力とコストのバランスが取れています。
２．チームの規模は小さく保ちましょう。各チームメンバーは独自のコンテキストウィンドウを実行するため、トークンの消費量はチームの規模にほぼ比例します。
まだまだ試用段階ですので正式リリース時には更に洗練され、トークン消費量が抑えられることを期待したいと思います。
最後に
エージェントチームの特徴の１つは最初に書いた通り各エージェントでやり取りを行う点なので、今回のような単純なコーディングは役割分担の例としては良かったのですが、実際には効果は得られなかったかもしれません。
例えば
「本番で時々タイムアウトが出る。
5人のエージェントに別々の仮説を検証させ、
互いの仮説を科学的な議論で否定し合ってください」
といったような指示、プロンプトでは更なる効果が期待できそうです。もしトークンの消費が気になる方は難しそうな不具合調査とか、そういった「いざという時」のために使うのが良さそうです。
当社では既に活用事例もありまして、スピード重視での設計書作成、あるいは複数メンバーによるレビューでこのエージェントチームを利用しているとのこと。
4人の性格を変えたエージェントにレビューさせ、そしてそれぞれのまとめ役を1人用意した5人のエージェントチームでの構成にしているそうで、「役割」ではなく「性格」別の各エージェントを用意した方が良いとのこと。
当然お願いするタスクやプロジェクトによって効果は異なるかもしれませんので、このあたりは皆さんの方でも試してみてもらえればと思いますが、エージェントチームは最初に書いた通り、まだ試験段階なので使用にあたっては色々と十分に注意の上、お願いします。
当社ネクストスケープはこのように生成AIを始めとした新しい技術・知識を日々取り入れており、Webサイト、スマホアプリ、Hololensアプリの開発をはじめ、CMSを利用したサイトの新規構築やリニューアルなど、お客様のニーズに幅広く対応いたします。お困りのことがございましたら、いつでもお気軽にお問い合わせください。
（以下当社お問合せフォーム）
当社では一緒に働いてくれる仲間を募集しています。是非以下のサイトよりお申込みください。
