はじめに
いえらぶＧＲＯＵＰの開発部で執行役員を務めています、和田です。わだけんです。
みなさん、Claude CodeのAgent Teams つかってます？
複数のClaude Codeインスタンスを「チーム」として協調動作させるという、なかなか攻めた実験的機能（Research Preview）。
なんか名前からしてワクワクするじゃないですか。「エージェントチーム」って。
ということで、社内で使っているChrome拡張機能の新規開発を、5エージェント体制でやらせてみました。
結論から言うと、人間のチーム開発で起きるのと似たような問題起きて、なんというか、笑ったというか、感心したというか。その過程で考えたことをまとめておきます。
誰かのトライのきっかけになればいいなと思いつつ。
そもそもAgent Teamsって何が違うの
Claude Codeには以前から「Subagent」という仕組みがあって、メインのセッションから子タスクを投げることはできました。ただ、Subagentはあくまで「親に報告する下請け」なんですよね。親のコンテキスト内で動くし、通信も一方通行。
Agent Teamsは根本的に違っていて、チームメイト同士が直接コミュニケーションを取れる。各エージェントが独立したコンテキストウィンドウを持っていて、共有タスクリストで依存関係を管理して、自律的に次のタスクを取りに行く。
| Subagent | Agent Teams | |
|---|---|---|
| 通信 | 親への報告のみ | チームメイト間で直接やり取り可能 |
| コンテキスト | 親のコンテキスト内 | 各自が独立 |
| 並列性 | 限定的 | 完全な並列実行＋自律取得 |
| コスト | 低 | 高（各インスタンス独立なので約5倍） |
LLMって、コンテキストが広がるほど性能が落ちる傾向があるんですが、Agent Teamsは各エージェントに狭いスコープとクリーンなコンテキストを与えることで、ドメインごとの推論品質を高めるというアプローチを取っています。
まあ、人間のチームでも「あれもこれも」って兼務してる人より、自分の担当に集中してる人のほうがアウトプットの精度は高いですよね。それと同じ構造なのかなと。
セットアップ
環境変数を1つ設定するだけです。
export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
もしくは settings.json に追加。
{ "env": { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1" } }
有効にすると、Team Lead（メインセッション）がチームメイトをスポーンできるようになります。
表示モードは「In-process（デフォルト）」と「Split panes（tmux/iTerm2で各エージェントが独自ペイン）」の2種類。自分はWSL上で動かしたのでIn-processでやりました。
やったこと：5エージェント体制でChrome拡張を作る
指示プロンプト
Team Leadに対して、こんな感じで指示を出しました。
新規ディレクトリを作成して、Chrome拡張機能の開発をお願いします。
agent-teamsを使って以下のエージェントに役割分担をして実装してください。
・プロジェクトマネージャー → 進行管理
・プロダクトマネージャー → 要件整合性チェック
・実装者（フロントエンドエンジニア） → 実装担当
・コードレビューベテランエンジニア → コードレビュー担当
・テスト実行者
普段、自分がチームに指示出すのとほぼ同じ感覚で書いてます（笑）。
チーム構成
| エージェント | 役割 |
|---|---|
| PjM（Team Lead） | タスク分解、依存関係定義、統合修正 |
| PdM | 設計書 vs 実装コードの全件照合 |
| フロントエンドエンジニア ×3 | コアライブラリ / UI層 / Service Worker |
| ベテランエンジニア | セキュリティ・品質・Manifest V3準拠 |
| テスト実行者 | ユニットテスト作成・実行 |
エンジニアが3人いるのは、担当領域を分けて並列実装させるためです。
実際の作業フロー
Phase 1: PjMがタスクを分解する
PjMとして動いたTeam Leadが、まず7つのタスクに分解して依存関係を定義しました。
「Phase 2/3/4（並列実装） → Phase 5（要件チェック） → Phase 6（コードレビュー） → Phase 7（テスト）」という流れ。
ディレクトリ構造やmanifest.json、アイコンといった基盤を作った上で、各エージェントへのプロンプト（指示書）を設計しています。
ここ、地味に大事なポイントで。各チームメイトはリーダーの会話履歴を引き継がないんですよね。だからスポーン時のプロンプトで「何を」「どこに」「どういう制約で」作るかを全部伝えないといけない。
人間のチームでも、プロジェクトの途中から入ったメンバーに背景説明するのって大変じゃないですか。あれと同じ感覚です。
Phase 2/3/4: 3エージェントが並列で実装
ここが一番面白かったところ。3つの実装エージェントが同時に起動して、それぞれの担当を独立して実装していきました。
| Agent | 担当 | ファイル数 | 所要時間 |
|---|---|---|---|
| Agent 1 | コアライブラリ | 4ファイル | 約4.8分 |
| Agent 2 | UI層 | 7ファイル | 約5.6分 |
| Agent 3 | Service Worker | 2ファイル | 約2.4分 |
各エージェントは詳細設計書を「共通の仕様書」として受け取って、独立に実装を進めます。
案の定ですが、インターフェースの不整合が6件発生しました。
Agent 1: checkAll() と命名
Agent 2: check() で呼び出し ← 合わない
Agent 1: buildL2Prompt() と命名
Agent 2: buildLayer2Prompt() で呼び出し ← 合わない
Agent 2: 設定をトップレベルキーで保存
Agent 3: { settings: {...} } でネスト保存 ← スキーマが違う
笑うしかなかったんですよね。
だって、自分のチームでも全く同じことが起きるから。設計書を共有していても、メソッド名の命名規則がずれたり、データ構造の解釈が人によって違ったり。並列開発の宿命みたいなもので。
Agent Teamsがこの問題を再現したこと自体が、ある意味すごいなと思いました。
Phase 5 & 6: PdMとレビュアーが並列でチェック
実装が終わると、PdMエージェントとベテランエンジニアエージェントが並列で起動して、それぞれの視点でコードをチェックしました。
PdM → 設計書の各セクションと実装を1対1で突合。合格19項目、要修正12項目。
レビュアー → セキュリティ・パフォーマンス・Manifest V3準拠の観点でレビュー。Critical 7件検出。
面白かったのが、両者の指摘が重なったところと、片方しか見つけられなかったところがあったこと。
| 問題 | PdM | レビュアー |
|---|---|---|
| メソッド名不一致 | ✅ Critical | ✅ Critical |
| ストレージスキーマ不統一 | — | ✅ Critical |
| CSSセレクタインジェクション | — | ✅ Critical |
| チェック機能未実装 | ✅ High | — |
| カスタムルールの動作ロジック未実装 | ✅ Medium | — |
PdMは「設計書に書いてあるのに実装されてない」を見つけるのが得意で、レビュアーは「設計書に書いてなくてもセキュリティ的にマズい」を見つけるのが得意。
異なる角度からの並列レビューが品質を担保する仕組みとして機能していて、これは人間のチームでもそのまま使える考え方だなと。ダブルチェックをアーキテクチャレベルで実現している、というか。
PjMが統合修正
PdMとレビュアーの指摘を受けて、PjMが11件の統合修正を実施しました。
check() → checkAll() に統一、ストレージスキーマの統一、チェック機能の追加実装、CSSセレクタインジェクション対策、etc.
Phase 7: テスト実行
修正後のコードに対してユニットテストを作成・実行。
全体のフローを図にするとこう
┌──────────────────────────────────┐
│ 詳細設計書（共通の仕様書） │
└───────────┬──────────────────────┘
│
┌───────────┼──────────────┐
▼ ▼ ▼
[Engineer A] [Engineer B] [Engineer C]
コアライブラリ UI・Content Service Worker
約4.8分 約5.6分 約2.4分
│ │ │
└───────────┼──────────────┘
│
┌───────────┼──────────────┐
▼ │ ▼
[PdM Agent] │ [Reviewer Agent]
設計書突合 │ コード品質レビュー
│ │ │
└───────────┼──────────────┘
▼
[PjM（Team Lead）]
統合修正 11件実施
│
▼
[Test Runner]
テスト実行・検証
各エージェント間の対話は、リアルタイムの会話というよりも、「成果物（コード）」と「レビュー結果」を通じた非同期的なフィードバックループでした。
Pull Requestベースの開発ワークフローに近い、と言えば伝わりますかね。
やってみて思ったこと
「チーム開発シミュレーター」としての可能性
たぶんちょっと別軸の話なのかもしれないんですが、
実際に動かしてみると、人間のチームで起きるのと似たような問題が再現されたっていうのは純粋に驚きですね。インターフェースの不整合、設計書の解釈のズレ、レビュー観点の違い。
なんというか、もともと想定してなかったんですが、新人研修や組織設計のシミュレーションに使えるんじゃないかなと思いました。「チーム開発ではこういう問題が起きますよ」を、実際に体験させられる。
おもしろいなー。
役割分離の効果はやっぱりある
各エージェントが自分の専門領域だけに集中できるので、単一セッションで全部やるより精度が高いアウトプットが出ました。PdMは要件突合に100%のコンテキストを割けるし、レビュアーはセキュリティに100%集中できる。
人間のチームでも「兼務が多すぎて何も進まない」はあるあるなので、役割を絞ることの効果を改めて感じます。
Contract-Firstでインターフェース不整合は減らせそう
今回6件のインターフェース不整合が出ましたが、事前にインターフェース定義書（型定義やAPIスキーマ）を共有しておけば、もう少し防げたと思います。
Contract-First（契約ベース）の開発手法をAgent Teamsに適用するのは、次に試してみたいところです。人間のチームでも同じ話ですが。
こっから手探りしたい内容。
- Read-onlyタスクから始める — PRレビューやコード調査で協調パターンを掴んでからのほうがいい
- ファイル所有権を明確にする — 同一ファイルの並列編集は上書きが起きるので、担当ファイルは事前に分ける
- リーダーはオーケストレーションに専念 — Shift+Tabでdelegateモード固定
- スポーンプロンプトに十分なコンテキストを含める — チームメイトはリーダーの会話履歴を引き継がないので、ファイルパス・制約条件・完了条件を全部書く
- 適度にチェックインする — 放置するとトークンが無駄に消費されることがある
まあこれも、人間のチームマネジメントと同じ、、、ですよね。。。「役割を明確にする」「背景を共有する」「適度に進捗確認する」。
まとめにならないまとめ
Agent Teamsを使ってみて一番印象に残ったのは、技術的な新しさよりも「チーム開発の問題がそのまま再現された」という事実でした。
3つの実装エージェントが並列で独立開発して、インターフェース不整合が6件発生して、PdMとレビュアーが異なる角度から検出して、PjMが統合修正する。この一連の流れが、普段自分のチームで見ている光景そのもので。
Agent Teamsは「並列処理ツール」として見ると「まあそうだよね」で終わるんですが、「チーム開発のシミュレーター」として見ると、組織設計や新人教育への応用可能性が見えてきます。
まだResearch Previewなので制約も多いですが（セッション再開不可、ネストされたチーム非対応、シャットダウンの不安定さ等）、今後のアップデートが楽しみな機能ではあります。
引き続きジタバタしていきます。
おわり。
CM
こんな感じで新しい技術をガシガシ試しながら不動産テックを作っている組織です。
一緒にいじり倒してくれる方、常に募集してます。
新卒採用サイト：