アシスタントエージェントとエージェントチームの決定的な違い

プロンプトを入力します。「架空の AI スタートアップのランディングページを作成してください。」と。すると間もなく画面が分割され、青色で示されたフロントエンド開発者エージェント、緑色のバックエンド開発者エージェント、黄色の QA エージェントが同時に起動します。3 つのエージェントはそれぞれの領域で作業を開始します。しかし、アシスタントエージェントとは異なることが起こります。

フロントエンド開発者がバックエンド開発者にメッセージを送ります。QA エージェントが両開発者に修正を依頼します。エージェント同士が互いに会話しているのです。

これが「エージェントチーム」です。

アシスタントエージェントとエージェントチームの違いは、コミュニケーションの構造にあります。アシスタントエージェントは単方向（ワンウェイ）です。メインセッションがプロンプトを送ると、アシスタントエージェントは作業を実行し、その結果をメインセッションに返します。この過程で、アシスタントエージェント同士が相互に通信することはできません。並列で実行されても、各エージェントは孤立した状態で作業を続けます。

エージェントチームは双方向（Two-way）です。チームメンバーは互いにメッセージをやり取りでき、互いに作業を割り当て、共有されたタスクリストを共同で管理します。メインセッションを経由せず、メンバー間で直接コミュニケーションが可能です。

[図 26-1] 補助エージェントとエージェントチームの通信構造比較：補助エージェントはメインセッションとの単方向矢印のみが存在しますが、エージェントチームはメンバー間の双方向矢印と共有タスクリストが存在します。

この構造的差異が生み出す結果は劇的です。

補助エージェント構造において「コードをリファクタリングし、検証コードを作成してください」と依頼すると、メインセッションはリファクタリングエージェントと検証コード作成エージェントにそれぞれ作業を指示します。両エージェントは独立して作業を完了し、各自の結果をメインセッションに報告します。メインセッションが両結果を統合します。

問題は、リファクタリングエージェントが関数シグネチャを変更したにもかかわらず、検証コード作成エージェントが元のシグネチャを基準に検証コードを作成している可能性がある点です。互いに会話できないため、こうした不一致を検知する手段がありません。

エージェントチームの構造では状況は異なります。リファクタリングエージェントが関数のシグネチャを変更すると、検証作成エージェントにメッセージを送ることができます。「この関数のシグネチャが変更されましたので、ご参照ください」と。検証作成エージェントは変更されたシグネチャを反映して検証コードを作成します。QAエージェントが問題に気づいた場合は、該当のエージェントに直接修正を依頼します。中間にメインセッションを経由する必要はありません。

エージェントチームには、チームリード（Team Lead）の役割を果たすメインオーケストレーターがいます。プロジェクトマネージャーに似た役割です。エージェントの生成、タスクリストの初期化、全体の進捗状況のモニタリング、結果の品質確認を行います。ただし、すべての通信がこのオーケストレーターを経由するわけではありません。チームメンバーは必要に応じて直接通信します。

共有タスクリストと相互タスク割り当て

エージェントチームの協力を可能にする中核インフラは、共有タスクリスト（Shared Task List）です。

メインオーケストレーターがエージェントチームを生成すると、まず行うのはタスクリストの構築です。フロントエンド開発、バックエンドAPIの実装、検証コードの作成、QA検証などの項目が列挙され、各項目に担当者が割り当てられます。

このタスクリストが「共有」される点が重要です。チームの全メンバーは、すべてのタスクリストを確認できます。自分の作業が完了したら、そのステータスを更新します。他のメンバーの進捗状況も確認可能です。そして—これが補助エージェントとの決定的な違いですが—メンバーは他のメンバーに新しいタスクを割り当てることもできます。

あるデモで、このメカニズムが鮮明に示されました。フロントエンド開発者とバックエンド開発者がそれぞれの作業を完了し、成果物を QA エージェントに提出しました。QA エージェントがコードを検証した結果、3 つの致命的な問題が発見されました。QA エージェントはこれらの問題をフロントエンド開発者とバックエンド開発者に返送し、それぞれに修正作業を割り当てました。

2 人の開発者が修正を完了し、再度 QA エージェントに提出しました。2 回目の検証で、QA エージェントは合格判定を下しました。3 つの致命的な問題はすべて解決されました。

[図 26-2] 共有タスクリストに基づくコラボレーションフロー：フロントエンド・バックエンド作業完了 → QA エージェントによる検証 → 3 つの問題発見 → 各開発者への修正割り当て → 再検証 → 合格

このプロセスにおいて、メインオーケストレータは全体のフローを監視しながらステータス更新を提供しましたが、QA エージェントが開発者エージェントに対して修正を依頼するコミュニケーションは、直接行われました。メインオーケストレータを介さない、メンバー間の直接コミュニケーションです。

チームメンバーは「メッセージ送信ツール」を使用して互いにメッセージを送ります。プロンプトで「作業が終わったらフロントエンド開発者にメッセージを送ってください」と指定すると、エージェントは該当するチームメンバーに直接メッセージを伝達します。

リファクタリングエージェントと検証作成エージェントの協働シナリオ

具体的なシナリオを通じて、エージェントチームの動作を追ってみましょう。

ユーザーがメインセッションに依頼します。「このモジュールをリファクタリングし、検証を追加してください。」

メインセッションは依頼を分析します。リファクタリングと検証作成という二つの専門領域が必要です。メインセッションは二つのエージェントを検索し、リファクタリングエージェントと検証作成エージェントを見つけ出します。

補助エージェント方式では、以下のように進行します。メインセッションがリファクタリングエージェントに「このモジュールをリファクタリングしてください」というプロンプトを送信します。同時に検証作成エージェントには「このモジュールに対する検証を作成してください」というプロンプトを送信します。両エージェントが並列で作業を行います。それぞれの結果がメインセッションに戻ってきます。メインセッションが両方の結果を統合します。

リファクタリングされたコードに合わせて検証を修正する必要があるかもしれません。この修正はメインセッションが直接行うか、検証作成エージェントを再度呼び出す必要があります。

エージェントチーム方式では流れが異なります。メインオーケストレーターが「リファクタ＋検証」チームを構成します。共有タスクリストが作成されます。

リファクタリングエージェントがまず作業を開始します。関数の抽出、変数名の変更、インターフェースの整理などを行います。作業が完了すると、検証作成エージェントにメッセージを送信します。「リファクタリングが完了しました。変更された関数のシグネチャは以下の通りです。」検証作成エージェントはこの情報に基づいて検証を作成します。変更されたインターフェースを正確に反映した検証が生成されます。

検証実行の結果、一部の検証が失敗した場合どうなるでしょうか？検証作成エージェントがリファクタリングエージェントにメッセージを送信できます。「この関数の戻り値の型がドキュメントと異なります。確認してください。」リファクタリングエージェントが確認して修正します。再度検証を実行します。この反復がチーム内で自律的に行われます。

[図 26-3] エージェントチームの協働シナリオ詳細フロー：リファクタリングエージェントの作業 → 検証エージェントへ変更点の伝達 → 検証文書の作成 → 失敗時のリファクタリングエージェントへの修正意見のフィードバック → 修正 → 再検証 → 通過 → メインオーケストレーターへの完了報告

T-Muxターミナルを使用すれば、このプロセスを視覚的に観察できます。画面が分割され、各エージェントの作業過程がリアルタイムで表示されます。青いエージェントがコードをリファクタリングしている間、緑色のエージェントが待機しており、メッセージを受信した瞬間に検証作業を開始する様子を直接見ることができます。必要に応じて、特定のエージェントに直接メッセージを送って追加の指示を出すことも可能です。

エージェントチーム構築時に考慮すべきアーキテクチャ原則

エージェントチームは強力ですが、誤って構成するとコストが高くなるだけで、結果として混乱した状況に陥る可能性があります。チームを構築する際に守るべき原則を整理します。

役割の明確化：各エージェントに固有の領域を付与する

チームの各エージェントは、独自のファイルと独自の成果物を持つべきです。複数のエージェントが同じファイルを修正すると、互いの作業を上書きしてしまう危険性があります。フロントエンド開発者はフロントエンドファイルのみ、バックエンド開発者はバックエンドファイルのみを修正するように、プロンプトで明確に指定してください。

成果物も具体的に定義する必要があります。「良いコードを書け」という指示は曖昧です。「REST API エンドポイントを実装し、各エンドポイントの検証ファイルを/tests/フォルダに作成せよ」という指示は明確です。エージェントに対して、何をどのように作成し、どこに保存すべきかを明確に指示してください。

コミュニケーションプロトコル：誰が誰に、いつ話すかを設計する

エージェントが自由に会話できるからといって、コミュニケーション構造を設計する必要がないという意味ではありません。プロンプトでコミュニケーションの流れを明示的に定義する方が、はるかに優れた結果をもたらします。

「バックエンド開発が完了したら、フロントエンド開発者に API スペックを渡してください」「すべての開発が完了したら、結果物を QA エージェントに送ってください」「QA で問題が発見されたら、該当ファイルの担当エージェントに修正を依頼してください」といったように明示的に指定することで、エージェントは依存関係を理解し、正しい順序で作業を進めることができます。

受信者を名前で指定することも重要です。「他のエージェントに送る」は曖昧ですが、「フロントエンド開発者エージェントに送る」は正確です。

衝突防止：エージェント同士が互いに邪魔しないようにする

ファイルの所有権については既に触れました。その他にも、いくつかの衝突防止戦略があります。

権限の事前承認：エージェントが毎回権限確認のために作業を中断すると、全体のワークフローが遅くなります。プロジェクト設定やローカル設定で特定の命令を事前に承認しておけば、中断なく作業がスムーズに進みます。チームメンバーはメインセッションの権限を継承するため、メインセッションでバイパスモードを設定すれば、すべてのチームメンバーが同じ権限を持つことになります。

計画承認モード：チームメンバーが作業を開始する前に計画を策定し、その計画をメインのオーケストレーターが承認した後にのみ実行するように設定できます。初期段階ではユーザーが各計画を直接承認する方式で始め、チームの運用に慣れれば、メインセッションに承認を委譲するのが実用的です。チームメンバーの一人を計画のレビューと承認専任に割り当てる構成も可能です。

正常終了 (Graceful Shutdown): 作業が完了すると、メインのオーケストレータが各チームメンバーに終了リクエストを送信します。「作業を保存して終了してください」という指示です。チームメンバーは、まだ進行中の作業がある場合、「まだ完了していません」と応答することができます。すべてのチームメンバーが完了を確認した後に、チームは解散します。強制終了すると作業が整理されずに残る可能性があるため、正常終了の手順を踏むことが安全です。

チーム規模とコスト

エージェントチームの各メンバーは独立したセッションを運営します。3人のエージェントがいればコストは約3倍になります。5人であれば5倍です。

推奨されるチーム規模は3名から5名です。10名以上の大規模なエージェントスウォームではコストが急激に増加し、調整の複雑さも比例して高まります。

[表 25-1] エージェントチームの適否を判断する基準

順次処理可能なタスクであれば、サブエージェントで十分です。エージェント間の通信が必要ない場合は、サブエージェントの方が優れています。同じファイルを複数のエージェントが修正する必要がある場合は、エージェントチームであってもサブエージェントであっても、構造を再設計する必要があります。

エージェントチームの設定方法

エージェントチームは実験的機能であり、デフォルトでは無効化されています。有効化するには、プロジェクトの .claude/settings.local.json に環境変数を追加する必要があります。Claude Code 公式ドキュメントのエージェントチームページから該当する JSON をコピーし、設定ファイルに貼り付けるだけです。

エージェントチームを呼び出すプロンプトの構造は、以下のパターンに従います。

1. 目標の設定: チーム全体が達成すべき目標を明示します。チームメンバーは起動時に何のコンテキストも持たないため、メインセッションが目標を明確に伝える必要があります。2. チームの構成: 「3 人のメンバーで構成されるチームをソネットモデルで作成してください」のように、チーム規模とモデルを指定します。3. 役割の定義: 各メンバーの役割、担当領域、コミュニケーション対象を具体的に記述します。4.

最終成果物の定義：メインセッションがチーム作業の結果として受け取る最終成果物を明示します。

[図 26-4] エージェントチームのプロンプト構造：目標→チーム構成→役割ごとの指示（コミュニケーション対象を含む）→最終成果物の定義

T-Muxターミナルでエージェントチームを実行すると、分割画面で各エージェントの作業をリアルタイムで観察できます。誤った方向に進んでいるエージェントを早期に発見して終了できるため、不要なコストの浪費を防げます。IDE拡張プログラムではエージェントの内部思考プロセスを詳細に確認できないため、複雑なエージェントチームの作業にはT-Mux環境がより適しています。

補助エージェントは、メインセッションの指示のもとで独立して作業する専門家です。エージェントチームは、共有された目標に向かって対話し協力するチームです。どちらも強力なツールですが、適用される文脈は異なります。迅速かつ効率的な委任が必要な場合は補助エージェントを、複雑な相互依存性と高い品質が求められる場合はエージェントチームを選択します。

この2つの構造を状況に応じて組み合わせることが、Claude Codeの運用者の力量であり、スキルとエージェントを織り交ぜてワークフローを設計する次の段階へと進む基盤となります。