なぜAI Agent Teamにしたほうが、一人の優秀なAIがいるよりいいのか #学ぶ

 Claudeの回答


とても本質的な質問です。簡単に言うと**「コンテキストウィンドウの限界」と「並列処理」**が核心です。

一人の優秀なエージェントの限界

コンテキスト劣化問題

会話が長くなるほど、モデルの「集中力」が落ちます。ステップ2の詳細がステップ5では曖昧になる、という現象が起きます。

LLMはコンテキストが膨らむほどパフォーマンスが落ちます。これはトークン上限の話だけではなく、コンテキストウィンドウに情報が多いほど、今重要なことに集中しにくくなります。プロジェクトマネージャーの戦略メモが、CSSのバグを直そうとしているコンテキストに混在すると、パフォーマンスが実際に落ちます。

順番待ち問題

1人のエージェントはすべてを直列でこなします。バックエンド→フロントエンド→テストと順番に。

Teamにすると何が変わるか

並列処理

1人のAIエージェントがタスク全体を順番に処理するのではなく、専門的な役割を持つ複数のエージェントが同時に問題の異なる部分を担当します。バックエンドAPI、フロントエンドUI、テストスイート、コードレビューをそれぞれ別のエージェントが並行して進めます。

エージェント同士の直接対話

チームメイトAがAPIエンドポイントを変更し、チームメイトBがそれを使うフロントエンドを作っているとき、両方が完成してから矛盾を発見するのではなく、リアルタイムで調整できます。

「科学的討論」による精度向上

複数の独立した調査者が互いの理論を積極的に反証しようとすることで、生き残った理論が実際の根本原因である可能性がずっと高くなります。順番に調査すると「アンカリング」が起きます（最初に探った仮説に引きずられる）。

わかりやすいアナロジー

一人の天才エンジニア エンジニアチーム
得意 シンプルなタスク、一貫性 複雑・大規模・並列処理
苦手 大規模で長期間の作業 依存関係が多い細かい作業
コスト 安い 高い（人数分のトークン）

結論：どちらを選ぶか

Agent Teamは並列探索に本当の価値がある場合に最も効果的です。順番に行うタスク、同じファイルへの編集、依存関係が多い作業には、単一セッションやサブエージェントのほうが効果的です。

つまり「タスクを分割して同時進行できるか？」がTeamを使うかどうかの判断基準です。


とても実践的な質問です。公式ドキュメントと実際の事例を調べてみます。良い情報が集まりました。具体的にまとめます。

チーム構成の基本的な考え方

エージェントの構成を自分で指定すると、何が動いているかとコストが把握でき、Claude が勝手に8人スポーンするのを防げます。ファイルの所有権も管理でき、協調・対立・独立などチームのダイナミクスを設計できます。

典型的なチーム構成パターン

フルスタック開発チーム

以下のような役割定義が実践的です：

  • Backend Agent：/src/server/ 担当。Expressのミドルウェアパターンに従い、TypeORMでDB操作
  • Frontend Agent：/src/client/ 担当。共有コンポーネントライブラリとTailwindの規約に従う
  • Test Agent：/tests/ 担当。Jestとカスタムテストユーティリティを使用
  • Review Agent：全出力をセキュリティ・型安全性・ESLint設定への準拠で検査

コードレビューチーム

3人のレビュアーが異なる視点で見ることで、1人では見逃すものを見つけられます：

  • セキュリティの観点に特化したレビュアー
  • パフォーマンスへの影響をチェックするレビュアー
  • テストカバレッジを検証するレビュアー

デバッグチーム（競合仮説型）

本番APIが断続的に500エラーを返している場合：

  • 仮説1：DBコネクションプールの枯渇
  • 仮説2：キャッシュレイヤーのレースコンディション
  • 仮説3：リクエストハンドラのメモリリーク

それぞれが証拠を共有しながら議論し、どの仮説がログに合致するか絞り込む

CLAUDE.md の書き方

CLAUDE.mdに明確なルールがあれば、チームメイトはリード介入なしに「27個のconsole.logを3ファイルから削除。12個のconsole.errorと2個のconsole.warnは保持。担当ファイルに残存ゼロを確認」のような正確な報告を自律的に出せます。

具体的にはこのように書きます：

## Agent Team Configuration

### チーム構成
マルチエージェントで作業する場合、以下の役割定義を使うこと：

- **Backend Agent**: /src/server/ 担当
  - Expressのミドルウェアパターンに従う
  - TypeORMでDB操作
  - 他のエージェントが変更したAPIは必ずメッセージで通知する

- **Frontend Agent**: /src/client/ 担当
  - /src/client/components/shared/ の共有コンポーネントを使う
  - Tailwindの既存規約に従う

- **Test Agent**: /tests/ 担当
  - JestとカスタムユーティリティをJests/helpers/で使用

- **Review Agent**: 全出力をチェック
  - セキュリティ・型安全性・ESLint設定への準拠を検査

### ファイル所有ルール
- 同じファイルを複数エージェントが編集しない
- 共有ファイルを触る前に必ずメッセージで調整する
  → 「coordinate before editing」ファイル: src/types/api.ts

### 完了報告の書き方
「何を・どこで・検証コマンドは何か」を必ず含めること

スポーンプロンプトの書き方

「認証モジュールをレビューして」という曖昧な指示ではなく、以下のように具体的に書くことがポイントです：「src/auth/ の認証モジュールをセキュリティ脆弱性の観点でレビュー。トークン処理・セッション管理・入力検証に注目。アプリはhttpOnlyクッキーに保存されたJWTトークンを使用。問題があれば深刻度評価とともに報告」という形式です。何をする・どこで・何に注目・成果物は何か というパターンが基本です。

タスクサイズの目安

タスクが小さすぎると調整のオーバーヘッドが利益を上回り、大きすぎるとチェックインなく長時間作業して無駄が増えます。チームメイト1人あたり5〜6タスクを目安にすると、全員が生産的に動き、詰まったときに再割り当てもできます。

一言まとめ

CLAUDE.mdには「誰が・どこを・どんなルールで・どう報告するか」を書く。これが明確なほど、チームが自律的に動きます。