Agent Teamと「チームとして」会話する技術 — 7つの原則
Claude CodeのAgent Teamを本物のエンジニアチームとして扱い、最適なコミュニケーションで良い出力を得るための7つの原則と組織論の応用。
Agent Teamと「チームとして」会話する技術
概要
Claude CodeのAgent Teamをツールではなく、本物のエンジニア組織として扱う。リーダーには戦略的な目標を、個々のメンバーには具体的なタスクを渡す。この区別がうまくいくと、曖昧な委任なしに意思決定の裁量を持たせられる。
7つの原則
1. リーダーシップのコミュニケーション戦略
リーダーには戦略的目標を、ICには具体タスクを渡す。「競合5社を比較して」はオーケストレーションの裁量を持たせる指示で、「3ファイルをJSONに読み込んで」とは質が違う。
2. ファイルオーナーシップの分離
複数エージェントが同時に同じファイルを編集するのが最大の落とし穴。1エージェント1ファイルのクリーンな分離がソフトウェア設計の原則そのもの。マージコンフリクトを防ぎ、エージェント間通信のオーバーヘッドを減らせる。
3. 自己完結するコンテキスト設計
個々のエージェントはリーダーや他メンバーとの会話履歴を持たない。暗黙知を前提にせず、タスク仕様の中に必要な情報をすべて含める。
4. モデル選択 = 採用
適切なモデルの割り当ては組織のキャパシティ配分と同じ。ルーティンのリサーチにはHaiku、実装判断にはSonnet、アーキテクチャ決定にはOpus。
5. 明示的な依存関係宣言
addBlockedBy でタスクの関係を定義し、暗黙の逐次実行に頼らず自動並列化を可能にする。
6. フェーズごとのレビューチェックポイント
フェーズ間にバリデーションを挟むことで方向性のミスを早期にキャッチし、手戻りの連鎖を防ぐ。
7. 明示的なシャットダウン手順
shutdown_request と TeamDelete を省略すると、アイドル状態のエージェントがリソースを消費し続け、設定ディレクトリが散らかる。
組織論の応用
逆コンウェイ戦略
エージェント構成の後にアーキテクチャ境界を引くのではなく、望ましいアーキテクチャ境界に合わせてエージェントを構造化する。
Team Topologies
コラボレーションモード(X-as-a-Service、Facilitating、Collaboration)を曖昧なメッセージパッシングではなく、文書化された契約で形式化する。
RACIマトリクス
受信者の役割に応じてメッセージルーティングを自動化する。意思決定者にはフルレポート、コンサルタントには要約、周辺ステークホルダーには1行通知。
SECIモデル
チーム解散時にすべての学びを失うのではなく、自動レトロスペクティブを永続メモリに保存して組織知識を保持する。
アンドンコード
重大な問題を発見したエージェントが、ブロードキャストメッセージに期待するのではなく、ファイルシステムシグナルを通じて並列作業を停止できる品質ゲートを作る。
実践パターン
Swarm
均質なワーカーがタスクキューを自律的に処理する(10並列の企業リサーチャーなど)。
Pipeline
意図的な並列化機会を持つ逐次フェーズ(リサーチと設計を同時進行し、統合で合流)。
競合仮説
複数エージェントが独立して異なる根本原因を調査し、逐次調査のアンカリングバイアスを排除する。
Watchdog
主要な実行者と、異常を検知する並行モニター。
コスト最適化
HaikuチームのN並列はルーティンリサーチでSonnet1台とほぼ同等コスト。30分タスクではスタートアップオーバーヘッドが実行時間を超える場合がある。
実プロジェクトデータ
2026年2月のレトロスペクティブでは、実装(bg-audio-playback、コントロールセンター修正)、新機能(freee確定申告計算)、提案書生成(91スライド)、市場調査(21クリエイターカテゴリ)にわたる11チーム起動・150エージェント起動で、原則に従った場合のファイルコンフリクトはゼロだった。