Agent Teams：Mesh トポロジーと5つの死に方

知識マンガシリーズ — 最小の言葉で、最もハードな技術を。

誤解されたスター型

Claude Code Agent Teams の通信システムは完全にオープンなパイプだ。

SendMessage の recipient フィールドは任意の teammate name を受け付ける。ルーティングロジックがやることは一つだけ：

JSON を ~/.claude/teams/{team}/inboxes/{recipient}.json に追記する

ホワイトリストなし、ACL なし、「Lead としか話せない」ハードコーディングなし。

だが全員がスター型で運用している。なぜか？

Lead が teammate を spawn する時のプロンプト末尾のあの一文：

"When done, send a summary message to the team lead."

一文でトポロジーが固定される。

Mesh を開く

spawn プロンプトをこう変える：

"You can coordinate directly with 'backend-dev' via
SendMessage(recipient='backend-dev'). Agree on the API
contract before either of you starts coding. Send final
summary to team-lead when both sides are done."

システムは通常通りルーティングする。frontend-dev のメッセージは inboxes/backend-dev.json に書き込まれ、backend-dev は次のターンで自動的に受け取る。

設定変更不要。ツール変更不要。コード変更不要。

Mesh 通信図

frontend-dev ←──SendMessage──→ backend-dev
      │                              │
      └──────SendMessage─────→ team-lead
                                     │
                          (最終結果のみ受信、
                           中間の調整は見えない)

Lead の唯一の可視性は idle notification だが、含まれるのは4つのフィールドだけ：

{ "type": "idle", "from": "frontend-dev", "timestamp": "...", "idleReason": "..." }

Peer 同士が何を話し、何を決めたか — Lead は一切知らない — teammate が自発的に報告しない限り。

5つの死に方

スター型でも Mesh でも、teammate のプロセスには5つの終了方法がある。

死に方 1：正常シャットダウン ✅

Lead が shutdown_request を送信、teammate が approve: true で応答、システムが teammate_terminated を返す。

3行のログ。クリーンに完了。

完全なプロトコルを持つ唯一の死に方。

死に方 2：Rate Limit サイレントキル ☠️

API クォータ枯渇。最後のログ：

"You've hit your limit · resets 5am"

プロセスは即座に終了。Lead にも peer にも通知なし。

Inbox には未読メッセージが残っている可能性がある。

最も致命的な死に方。

Mesh ではさらに危険 — A が B の API コントラクト応答を待っている時、B が rate limit で殺された場合、A は永遠に待ち続ける。Lead は2つの idle notification を見て、正常に動作していると思い込む。

死に方 3：完了後の自然 Idle 😴

Teammate が作業完了。最後の assistant message はツールコールなしのプレーンテキスト要約。

Runtime が「次のステップなし」と判定し、idle notification を発行。プロセスは終了せず待機状態に入る：inbox に新しいメッセージが書き込まれれば起動、なければずっとハング。

Mesh では「peer の応答待ち」の正常な状態。

だが Lead は「peer 待ち」と「本当に完了」を区別できない。

死に方 4：Leader セッション終了 💀

Lead がターミナルを閉じるかセッションタイムアウト。

backendType: "in-process" の全 teammate が道連れに死ぬ — 同じプロセスツリーで実行されている。

シャットダウンプロトコルなし、通知なし、inbox の未読メッセージは孤児ファイルになる。

Mesh で A と B が会話中に Leader が退出すると、2人同時に消滅。

死に方 5：Max Turns タイムアウト ⏱️

Task(max_turns=N) またはテンプレートの30分上限。到達で強制停止。

Mesh で片方がタイムアウトし、もう片方が応答を待っている場合、効果は Rate Limit サイレントキルと同じ — 待機側は永遠にメッセージを受信できない。

Mesh の本当のリスク

5つの死に方のうち、最初の1つだけ（正常シャットダウン）が完全なライフサイクル管理を持つ。

残りの4つは「サイレント消滅」— 相手はあなたの死を知らず、あなたは相手が待っていることを知らない。

スター型では大問題ではない

全メッセージが Lead を経由する。Lead が応答を受け取れなければ問題発生を認識でき、shutdown して sub-agent に切り替えられる。

だが Mesh では…

2つの peer が直接やりとり、Lead はコンテンツを見れない。片方がサイレントに死亡：

A → SendMessage(to=B, "API スキーマは決まった？")
    ↓
    inboxes/B.json に書き込み ← 成功（システムは B の生死を確認しない）
    ↓
    A は応答を待つ... idle... idle... idle...
    ↓
    Lead は A がずっと idle なのを見て、A がフリーズしたと思う
    ↓
    Lead が A を shutdown
    ↓
    2人の作業が全て無駄に

結論

スター型は技術的制約ではない。リスク管理だ。

パイプは完全にオープン。だが Mesh を開けば「沈黙の死者」問題を自分で処理しなければならない。

現在のシステムにはハートビートなし、配達確認なし、「相手がオフライン」のコールバックなし。

SendMessage は常に success: true を返す
たとえ相手のプロセスがとっくに消滅していても

Multi-Agent アーキテクチャ：並列実行パターン — Sub-agent の基礎
Claude Opus 4.6：Agent Teams、100万 Token、Effort Tuning — Agent Teams 機能紹介