エージェントチーム

エージェントチームは、個別のコンテキストを持つ複数のメンバーで一つの目標に取り組みます。共有タスクリストが担当と進捗を記録し、メッセージが必要な情報を運びます。タスクを完了しても、他のメンバーの理解は自動更新されません。インターフェースの変更は、利用するメンバーへ伝える必要があります。

三人の技術者が、それぞれノートを持ち、一つのタスクボードを共有する場面を考えます。「API の構築」を完了にしても、応答フィールドが name から display_name に変わったことは伝わりません。ページを接続する前に、フロントエンドはその情報を必要とします。

独立して進められる仕事を分担し、結果を交換する場合にチームが役立ちます。本例では API とレイアウトを並行して作れますが、データの接続は両方の完了を待ちます。メンバーを増やしても、この依存関係は消えません。

エージェントチームの仕組み

Lead が目標を調整し、Backend が API、Frontend がページを担当します。各メンバーの個別のコンテキストには、自分の割り当てと受け取った証拠があります。別のオブジェクトであるタスクボードは、タスク、担当者、前提条件、状態を記録します。担当の取得によって、二人が同じタスクを引き受けることを防ぎます。

メールボックスも情報の保存先です。バックエンドは API の契約変更をフロントエンドへ直接送れます。メッセージはまずメールボックスに入り、コンテキストへ届くと次の判断に使えます。送信者は、受信者が情報を使い終えるまで待つ必要はありません。

Claude Code の文書は、メンバーの個別のコンテキスト、共有タスク、受信者のメールボックス、自動配信を説明しています。本レッスンは事前に組んだ実行順でこれらを示します。Claude によるタスク選択やコード生成の記録ではありません。Agent Teams の公式文書

タスクは三つです。

最初の二つは並行して進み、三つ目は両方を待ちます。依存関係が定めるのは開始できる条件です。API の契約をフロントエンドのコンテキストへ書き込むわけではありません。

ステップごとの解説

既定では更新を送信（Send update）を選び、API フィールドは display_name です。フロントエンドの既存の契約は name を使います。目標のページには Ada を表示する必要があります。

仕事を割り当てる

Lead はプロフィールページの目標を受け取ります。Backend は display_name を使う API の構築、Frontend はレイアウトとバインディングを担当し、既存の name という契約を持ちます。コンテキストは別々なので、Backend に新しいフィールドを伝えても Frontend の記録は変わりません。

Lead が三つのタスクを作ります。Backend が t1、Frontend が t2 の担当を取得し、両方が進行中になります。担当取得は作業開始前に一人の所有者を定めます。

API を完成させ、契約を送る

Backend は {"display_name":"Ada"} を作り、t1 を完了にします。Frontend はまだレイアウトを作っています。この時点では、ボードの t1 は完了、Frontend のメールボックスは空で、コンテキストのフィールドは name のままです。

Backend は API フィールドが display_name であると伝えるメッセージを送ります。Frontend 宛てなので、Lead のコンテキストを通りません。メールボックスで待っている間、Frontend のコンテキストには古いフィールドが残ります。

Frontend がレイアウトを完成させ、t2 を完了にします。前提となる二つが完了したため、t3 を開始できます。次の模擬ターン境界でメッセージがコンテキストへ自動配信され、既知のフィールドが name から display_name に変わり、メールボックスは空になります。配信の時点は模式的なもので、モデルの遅延を測定していません。

バインディングを作り、結果を確認する

Frontend は t3 の担当を取得し、自分のコンテキストのフィールドを使って response.display_name を読むバインディングを作ります。t3 を完了にすると、ボードには三つの完了が並びます。ただし、統合結果はまだ未確認です。

Frontend は実際のキーを Lead に報告します。報告はメールボックスを経由して Lead のコンテキストへ入ります。Lead は API の成果物と報告を組み合わせ、{"display_name":"Ada"} を display_name で読み、Ada を得ます。ここでプロフィールのプレビューに値が表示されます。検証前の名前欄は空です。バインディングの作成と結果の検証は別の段階です。

最後のメンバーはアイドル状態で、コンテキストを保ったまま次の仕事を受けられます。一つのタスクの完了は、セッションの終了とは異なります。

全タスクが完了しても統合が失敗する理由

display_name を選んだまま状態のみ更新（Status only）へ切り替えます。古い契約（Stale contract）のシナリオから検証へ進むこともできます。この比較では Backend から Frontend への契約メッセージだけを取り除き、タスク、担当、前提条件、API 応答は変えません。Frontend の最終報告は残り、キーはその時点のコンテキストから選びます。

Frontend が受信境界へ来ても、メールボックスは空です。この方針では API の成果物も読まないため、既知のフィールドは name のままです。response.name を使ってタスクを完了しますが、Lead がそのキーで {"display_name":"Ada"} を読むと、プロパティが見つかりません。

三つのタスクは完了しているのに、プレビューは名前を取得できません（Name unavailable）と表示します。完了状態が示すのは、その作業単位が終わったことです。独立した成果物同士が整合する証拠にはなりません。

状態のみ更新のまま API フィールドを name にすると、統合は通ります。応答が既存の契約に合うためです。契約が変わらない場合の成功だけでは、変更にも対応できる方針だとは判断できません。

設計では、タスクの境界を越えて何を伝えるかを決めます。メッセージ、共有成果物の読み取り、タスク説明への契約の記載、Lead による伝達が使えます。失敗例はこれらをすべて省いています。示しているのは情報の欠落であり、エージェントに共有ファイルを調べる能力がないということではありません。

チームが適する仕事

各メンバーが別の部分を担当し、発見を交換する仕事に向きます。API とページを同時に変更する場合や、設計の異なる部分を分担してレビューする場合などです。一つの結果を返せば済む仕事には、サブエージェントが合うこともあります。全タスクが直前のタスクを待つ場合や、全員が同じファイルを編集する場合は、一つのセッションの方が調整を減らせることが多いです。個別のコンテキストにはトークン費用もかかります。本アニメーションは費用も速度向上も測っていません。利用場面とトレードオフ

分担前に、各利用側に必要な情報を洗い出します。本例では読むフィールド、応答例、変更が必要な利用側を伝えます。統合の検証にも担当者を置きます。Frontend がまだ name を想定していれば、「API は完了した」というメッセージにも完了マークと同じ情報の不足が残ります。

境界ケース

• メールボックスが空。 更新がなければ既知のフィールドは変わりません。シミュレーターは完了状態から display_name を推測しません。
• 前提の一つだけが完了。 t1 が完了しても、t2 が未完了なら t3 は開始できません。
• 担当を二重に取得。 既に担当者がいれば二回目の取得を拒否します。ただし実際のプロジェクトでは、別のタスクが同じファイルを書くことは防げません。ファイルの担当も調整が必要です。
• 別の宛先へのメッセージ。 Frontend 宛ては Lead のコンテキストを更新せず、Lead 宛ての報告は Backend のコンテキストを更新しません。
• 重複配信。 このモデルでは、処理済みのメッセージ ID を受信者のコンテキストに再追加しません。
• 契約が変わらない。 name が正しければ状態のみ更新でも通ります。この場合、更新メッセージは出力値を変えません。

よくある間違い

• タスクボードを完全な共有メモリと考える。 状態は終了した仕事を示しますが、他のメンバーの作業内容をすべて含むわけではありません。
• 送信を理解の証拠にする。 待機中のメッセージとコンテキスト内の情報は別の状態です。受信だけで、実際のエージェントによる正しい利用まで保証できません。
• すべて Lead を経由させる。 メンバーは直接契約を交換でき、双方の会話全体を調整役へコピーする必要はありません。
• 情報不足を人数で解決する。 新しいメンバーにも前提情報が必要です。独立した仕事を分け、情報交換を明確にします。
• 統合検証を省く。 個別に完了したタスクの成果物が食い違うことがあります。目標の達成を判断する前に、一緒に検証します。

このレッスンでの簡略化

本レッスンは決定論的な説明で、正式な研修や使用するエージェントランタイムの文書を代替しません。タスク、割り当て、順序は事前に作成しています。ブラウザーは担当取得、依存関係の確認、メールボックスの配信、コンテキスト更新、応答オブジェクト、バインディング、統合時の読み取りを計算し、LLM は実行しません。実際のエージェントは、この順序に従わず成果物を読んだり質問したりできます。配信失敗、再試行、権限確認、ファイル競合、終了処理は省略しています。再生時間はモデルの実行時間や速度向上を表しません。