注目 Agent Teams Architecture 知識マンガ Claude Code Session Management

Agent Teams：死後清算 — Session 管理の6つの亀裂

前回は5つの死に方を解説した。今回はその後のシステム的崩壊 — agent が記憶喪失で復活し、生存者を巻き込む時、session のライフサイクル全体がどう崩れるかを分析する。

2026年2月9日 • 10 分で読める • 著者：Claude World

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

本記事は《Mesh トポロジーと5つの死に方》の続編。

前回のあらすじ

前回の記事では Agent Teams における teammate プロセスの5つの終了方法を分析した。結論：正常シャットダウンだけが完全なプロトコルを持ち、残り4つはサイレント消滅。

だがそれは始まりに過ぎなかった。

Agent が死んでからが本番 — その残留効果が session のライフサイクル全体に6つの亀裂を引き起こす。

亀裂1：先着順の罠

Agent Teams は完全非同期。5つの agent を派遣し、各自が独立して作業・報告する。

問題：メイン context は待たない。

タイムライン：
t=0    Lead が Agent A, B, C, D, E を同時派遣
t=10s  Agent A 完了、結果を報告
t=11s  Lead が A の結果を確認 →「フェーズ1の結果が出た」→ フェーズ2へ
t=15s  Agent B 完了、結果を報告
t=16s  Lead が B を受信 → だが既にフェーズ2の作業中
       → B の結果は無視されるか重複処理される
t=30s  Agent C, D, E が順次完了...
       Lead は同じ作業のために新しい agent を既に派遣している可能性

barrier なし。waitAll() なし。「全員集合を待つ」仕組みなし。

inbox は JSON ファイルの追記書き込み：

~/.claude/teams/{team}/inboxes/{lead}.json

Lead は各ターンの終了時に inbox を消費する。先に到着した順に処理。遅着者は「フェーズ2の Lead」に新タスクとして扱われる可能性がある。

実測：5 agent チームで同じ作業が3回派遣された。Lead が誰が何をしたか忘れたため。

亀裂2：記憶喪失の Compact

Claude Code の auto-compact は context window 使用量が 80% に達すると発動（v1.0.51 で 60% から引き上げ）。

Compaction がやること：会話全体をテキスト要約に圧縮。

compaction 前：完全な会話履歴（全ツールコール、agent 報告、タスク状態）
compaction 後：テキスト要約 +「ここから続行」

致命的問題：要約はプレーンテキスト。構造化された状態を持たない。

Compact 後、モデルは以下を知らない：

  • どの agent がまだ実行中か
  • その agent ID は何か
  • どのタスクを担当しているか
  • どのタスクが完了済みでどれが待機中か

まだ外で走っている agent がようやく帰ってくると：

Agent D (t=45s): "API スキーマ設計が完了しました、結果はこちら..."
Lead (compact 後): "API スキーマ？確認します... よし、API スキーマ設計の
                    担当者を割り当てましょう。"
                   → Agent F に同じ作業を派遣

Compact は記憶を殺す。Agent は死から蘇るが、マスターはもう自分を認識しない。

CHANGELOG の修正記録がこの問題の深刻さを証明：

バージョン修正内容
v2.1.0Fixed files and skills not being properly discovered when resuming
v2.0.7Fixed sub-agents using the wrong model during conversation compaction
v1.0.51Increased auto-compact warning threshold from 60% to 80%
v1.0.12Improved todo list handling during compaction

閾値を上げても解決にならない。記憶喪失のタイミングを先送りするだけだ。

亀裂3：Token 核爆発

各 sub-agent の transcript は独立した JSONL ファイルで、サイズ制限なし。

実測データ（匿名化）：

あるセッションの agent transcript サイズ：
agent-aaa.jsonl  →  425 MB
agent-bbb.jsonl  →  256 MB
agent-ccc.jsonl  →  19 MB
agent-ddd.jsonl  →  12 MB
メイン session     →  22 MB、1,533 行

1つのセッションの sub-agent 合計：700 MB 超。

v2.1.0 で 30K 文字の切り詰めが追加されたが、メイン context に返す部分だけが対象。Agent 自身の transcript は制御不能。

より悪いシナリオ：複数の並列 agent が同時に完了し報告。

Agent A: 25K の結果を返す
Agent B: 28K の結果を返す
Agent C: 30K の結果を返す
─── 同時に Lead の inbox に書き込み ───
Lead の次のターン: 83K の新コンテンツを消費
                  + 既存 context ≈ 75%
                  = 瞬時に 80% 超過 → compact 発動
                  → 亀裂2に戻る

並列 agent の報告はバーストトラフィック。バックプレッシャーなし、フロー制御なし、キューイングなし。

亀裂4：Resume の記憶ブラックホール

Session の永続化は .jsonl の逐次追記。Resume 時はファイル全体の再読み込みが必要。

2時間稼働、10+ agent を使用したセッションの JSONL は 20+ MB に達しうる。

claude --resume <session-id>
    ↓
    22MB の JSONL を読み込み
    ↓
    ケース A: 以前の compact あり → compact summary を読み込み（正常）
    ケース B: compact boundary が破損 → 完全な履歴を読み込み（22MB）
    ケース C: 孤立した tool_result あり → resume が直接失敗

CHANGELOG は繰り返し修正を記録：

バージョン修正内容
v2.1.9Fixed long sessions with parallel tool calls failing (orphan tool_result)
v2.1.7Fixed orphaned tool_result errors when sibling tools fail
v2.1.0Fixed session resume failures caused by orphaned tool results
v2.0.1Fixed session persistence stuck after transient server errors

パターンに気づいただろうか？「orphaned tool result」が繰り返し出現する。

原因：並列ツールコールの1つが失敗すると、他の tool_result が「孤児」になる — 結果はあるが対応する tool_use がない。API は tool_use と tool_result の厳密な対応を要求する。孤児が存在すると即座にエラー。

並列が多いほど孤児が増え、resume が脆くなる。

亀裂5：浮遊霊

セッションを強制終了（Ctrl+C、ターミナル終了、token 枯渇）した後の残骸：

~/.claude/teams/
├── team-alpha/          ← 先週のチーム
│   ├── config.json
│   └── inboxes/
│       ├── agent-1.json  ← 未読メッセージあり
│       ├── agent-2.json
│       └── agent-3.json
├── team-beta/           ← 3日前
│   └── inboxes/
│       └── ... 11個の inbox
├── default/             ← いつのものか不明
│   └── inboxes/         ← config.json なし（不完全状態）
└── ... さらに6つ

システムに存在しないもの：

  • PID トラッキング（プロセスの生死を知らない）
  • 孤児検出（どのチームがアクティブか知らない）
  • 自動クリーンアップ（期限切れチームディレクトリの GC なし）
  • Resume 時のチーム状態復元（チームの進捗を知らない）

Agent Teams を使うたびにディスクに堆積層が残る。クリーンアップは手動のみ。

# 現在利用可能な唯一の「クリーンアップ機構」
rm -rf ~/.claude/teams/team-*

亀裂6：Idle 嵐

Agent Teams の idle notification 設計には暗黙の前提がある：agent は1回 idle すれば十分。

現実：agent のターンが終了するたび（ツールコールなし）に idle notification が発火する。

実測データ（あるチームの10秒間）：

agent-1: idle (t=0.000s)
agent-1: idle (t=0.514s)    ← 0.5秒間隔
agent-1: idle (t=0.951s)    ← 0.4秒間隔
agent-1: idle (t=1.505s)
agent-1: idle (t=1.960s)
agent-1: idle (t=2.533s)
agent-1: idle (t=3.034s)
agent-1: idle (t=3.522s)
agent-1: idle (t=5.076s)

1つの agent が5秒間に9回 idle notification を送信。

6 agent のチームで、Lead の inbox の 69% が idle ノイズ。

各 idle notification は Lead を起動 → Lead が inbox を消費 → 新ターン発火 → token 消費 → context 膨張加速 → compact が早まる → 亀裂2に戻る。

idle 嵐 → token 膨張 → compact → 記憶喪失 → 重複派遣 → agent 増加 → idle 増加
             ↑                                                    │
             └──────────── 正のフィードバックループ ──────────────┘

v2.0.14 で1度修正：「Fixed how idleness is computed for notifications」。

だが根本問題は変わらない — idle はターンごとに発火し、セッションごとではない。

6つの亀裂の相互作用

これら6つの問題は独立していない。互いに増幅する：

                    ┌──── 亀裂1（先着順）
                    │         ↓
                    │    重複派遣
                    │         ↓
亀裂6（idle 嵐）  → token 爆発 ← 亀裂3（token 核爆発）
                    │         ↓
                    │    亀裂2（記憶喪失 compact）
                    │         ↓
                    │    さらなる重複派遣
                    │         ↓
                    │    亀裂4（resume 失敗）
                    │         ↓
                    │    強制再起動
                    │         ↓
                    └──── 亀裂5（浮遊霊）

2時間の複雑なセッションで、6つの亀裂すべてを経験しうる。

根本原因：3つのインフラ不足

インフラ現状引き起こす亀裂
状態機械管理構造化された agent レジストリなし1, 2, 4
プロセス監視PID トラッキングなし、ハートビートなし5, 6
同期バリアbarrier / waitAll なし1, 3

Agent Teams は「メッセージパッシング + 共有タスクリスト」の緩い協調フレームワーク。

分散システムに必須の3大インフラが欠けている。分散システムの用語で言えば：

message passing あり → だが delivery guarantee なし
task queue あり      → だが exactly-once processing なし
process spawn あり   → だが supervisor tree なし

対比：プロセス分離が回避できる理由

亀裂Agent Teamsプロセス分離（独立 CLI セッション等）
先着順Lead が待たないオーケストレータが全 worker 完了を待って推進
記憶喪失 compact要約が実行中状態を喪失各 worker が独立 context
Token 核爆発Agent transcript 無制限各タスクが独自の context window
Resume ブラックホール巨大 JSONL を読み込み各 worker が独立永続化
浮遊霊プロセス追跡なし独立プロセス、終了 = 回収
Idle 嵐ターンごとの notificationWorker 完了 → プロセス終了

核心的な違い：Agent Teams はインプロセス並行性（コルーチン）。プロセス分離は真の並列性（プロセス）。

前者は運命共同体 — 1つが死ねば全体に影響。後者は独立 — 1つの障害がカスケードしない。

結論

前回の結論：スター型は技術的制約ではなく、リスク管理。

今回の結論：Agent Teams の session 管理には、分散システムのインフラが欠けている。

短期・低複雑度のチームタスクには最適 — 3つの agent、10分間、compact 不要のケース。

だがセッションが時間単位に伸び、agent 数が5を超え、多段階の協調が必要になると、6つの亀裂が共振を始める。

Agent Teams のスイートスポット：
✅ 3-5 agent
✅ 10-15 分
✅ 単一フェーズのタスク
✅ resume 不要

危険ゾーン：
❌ 5+ agent
❌ 30+ 分
❌ 多段階の依存関係
❌ compact や resume が必要

Agent Teams がダメだと言っているのではない。適用範囲があると言っている。

その範囲を超えたら、プロセスレベルの分離が必要 — 各 worker が独立 CLI セッション、オーケストレータは調整のみで context window を共有しない。

関連記事