Agent Teamsが存在する前に、私たちはそれを作っていた

Knowledge Comicシリーズ — 最大の技術的深度、最小の言葉。

誰も語らない問題

すべてのClaude Codeヘビーユーザーは同じ壁にぶつかる：

Turn 1-20:   Claudeは鋭く、集中し、すべてを覚えている
Turn 30-50:  以前の決定を忘れ始める
Turn 80+:    「どのファイルを作業していたっけ？」

これがcontext腐敗。単一のcontext windowには限界がある。やればやるほど、忘れる。

Sub-agents（Task tool）は役立つが、メインcontextを共有する。結果が戻ってきて、ウィンドウがさらに早く埋まる。

本当の問題：50回以上の開発イテレーションを記憶喪失なしで実行するには？

CMSの回答（2026年1月）

私たちは**CMS（Claude Multi-Session）**を構築した — 各開発イテレーションを独自のプロセスに分離するマルチセッションオーケストレーター。

┌─────────────────────────────────────────────┐
│              CMS Orchestrator                │
│                                              │
│   Iteration 1    Iteration 2    Iteration 3  │
│   ┌─────────┐   ┌─────────┐   ┌─────────┐  │
│   │ 新しい   │   │ 新しい   │   │ 新しい   │  │
│   │ Context  │   │ Context  │   │ Context  │  │
│   │ Window   │   │ Window   │   │ Window   │  │
│   └────┬─────┘   └────┬────┘   └────┬─────┘  │
│        │              │              │         │
│        └──────┬───────┴──────┬───────┘         │
│               ▼              ▼                  │
│         checkpoint.json（共有状態）              │
└─────────────────────────────────────────────────┘

各イテレーション：

新しいClaude Codeプロセスを起動 — フルcontext window、ゼロ荷物
checkpoint.jsonを読み取る — 前回の続きから
タスクを実行 — 実装、テスト、修正
checkpoint.jsonに書き込む — 次のイテレーションのために進捗を保存
終了 — プロセス終了、context解放

オーケストレーターがループする。50回？100回？context腐敗は永遠にない。

そしてAgent Teamsが来た（2026年2月）

Opus 4.6はAgent Teamsをもたらした — Claude Code公式のマルチエージェント協調システム。

機能リストを見て、奇妙なデジャヴを感じた：

共有Task List → 私たちには checkpoint.json があった
エージェント間メッセージング → 私たちにはcheckpoint状態伝達があった
独立context window → 私たちにはCMS各イテレーション独立プロセスがあった
Team Lead協調 → 私たちには6フェーズオーケストレーションループがあった

コンセプトマッピング

┌─────────────────────┬──────────────────────────────────┐
│ Agent Teams (v2.1)   │        CMS（2026年1月）           │
├─────────────────────┼──────────────────────────────────┤
│ TeamCreate           │ cms-iterate spawn                │
├─────────────────────┼──────────────────────────────────┤
│ TaskList / TaskGet   │ checkpoint.json                  │
├─────────────────────┼──────────────────────────────────┤
│ SendMessage          │ checkpoint状態伝達                │
├─────────────────────┼──────────────────────────────────┤
│ Teammate（process）  │ CMS iteration（process）          │
├─────────────────────┼──────────────────────────────────┤
│ Team Lead            │ self-upgrade 6フェーズループ       │
├─────────────────────┼──────────────────────────────────┤
│ Shutdown protocol    │ iteration exit + checkpoint      │
├─────────────────────┼──────────────────────────────────┤
│ Idle notification    │ iteration完了シグナル              │
└─────────────────────┴──────────────────────────────────┘

同じ問題。同じ解決策。違う名前。

CMSがまだリードしている点

Agent Teamsはエレガント。しかしCMSには、公式システムがまだ追いついていない実戦で鍛えられた利点がある。

0. 根本的な違い：誰がイテレーションループを所有するか？

最も重要なアーキテクチャの違い：

Agent Teams:
  ┌──────────────────────────────┐
  │     Lead（メインcontext）     │  ← Leadはターミナルセッション内に存在
  │                              │
  │  spawn teammate A ──→ [A]    │  ← Teammateは新しいcontextを取得
  │  spawn teammate B ──→ [B]    │
  │  結果を待つ                   │  ← Leadのcontextが埋まっていく
  │  結果を統合                   │
  │  spawn teammate C ──→ [C]    │
  │  ...                         │  ← 50回後、Leadは肥大化
  └──────────────────────────────┘

CMS:
  ┌──────────────────────────────┐
  │     CMS Orchestrator         │  ← 薄いシェルスクリプト、LLMではない
  │                              │
  │  spawn iteration 1 ──→ [I1]  │  ← 新しいcontext、すべてを実行
  │  checkpoint.json ←── [I1]    │  ← 状態外部化、I1死亡
  │  spawn iteration 2 ──→ [I2]  │  ← 新しいcontext、checkpointを読む
  │  checkpoint.json ←── [I2]    │  ← I2死亡
  │  ...                         │  ← 50回後もまだフレッシュ
  └──────────────────────────────┘

Agent TeamsはTeammateを分離したが、Leadは分離していない。

Leadはすべてのspawn結果、すべてのメッセージ、すべてのtask更新を蓄積する。50回のイテレーション後、Leadのcontextはシングルセッションワークフローと同じぐらい肥大化する。

CMSはすべてを分離する — イテレーションループ自体を含めて。

OrchestratorはシェルスクリプトでLLMではない。トークンを消費しない。忘れない。腐敗しない。各イテレーションは完全に独立したClaude Codeプロセスで、JSONファイルを読み、仕事をし、死ぬ。

これは「共有ボスを持つ並列エージェント」と「共有ディスクを持つ直列プロセス」の違い。

1. 並列だが脳を共有しない

タスクに依存関係がない場合、CMSは待たない：

CMS（並列モード）:
  ┌──────────────────────────────────┐
  │       CMS Orchestrator           │
  │                                  │
  │  Task A（依存なし）──→ [Process 1] │  ← 独立プロセス
  │  Task B（依存なし）──→ [Process 2] │  ← 独立プロセス
  │  Task C（依存なし）──→ [Process 3] │  ← 独立プロセス
  │                                  │
  │  全完了を待つ ←─── checkpoint      │
  │                                  │
  │  Task D（依存: A,B）──→ [Proc 4]   │  ← A & B完了後に実行
  └──────────────────────────────────┘

Agent Teams（並列）:
  ┌──────────────────────────────────┐
  │       Lead（メインcontext）       │
  │                                  │
  │  spawn A ──→ [Teammate A]        │
  │  spawn B ──→ [Teammate B]        │  ← 全並列、良い
  │  spawn C ──→ [Teammate C]        │
  │                                  │
  │  結果A受信 ← Leadを埋める         │
  │  結果B受信 ← Leadを埋める         │  ← Leadがすべてを蓄積
  │  結果C受信 ← Leadを埋める         │
  └──────────────────────────────────┘

両方ともタスクを並列実行する。しかしCMSのオーケストレーターはcontextを消費しない。Agent TeamsのLeadは消費する。

CMSは並列性とcontext分離の両方を得る。Agent Teamsはどちらかを選ばせる。

2. 再起動後の復旧

CMS:
  プロセスがクラッシュ → checkpoint.jsonはディスクに残る
  --resume を実行 → 前回の正確な地点から再開

Agent Teams:
  Leaderがターミナルを閉じる → 全teammateが死亡（Death #4）
  Mailboxメッセージ → 孤児ファイルに
  復旧 → 最初からやり直し

CMSのcheckpointは設計上永続的。Agent Teamsのインメモリ状態はデフォルトで一時的。

3. 無制限イテレーション

CMS:
  各イテレーション = 新プロセス = 新しい200k context
  50回？200k × 50 = 10Mトークンの累積容量
  50回目でもゼロ劣化

Agent Teams:
  各teammate = 1プロセス = 1 context window
  長時間実行のteammate = 同じcontext腐敗問題
  Max turnsリミット = 強制停止

CMSはcontextの制限と戦わない。完全に迂回する。

4. 自己進化ループ

CMS + Self-Evolving:
  イテレーション失敗 → 学習を抽出 → skillsを進化 → より良いツールでリトライ
  各失敗が次のイテレーションをよりスマートにする

Agent Teams:
  Teammate失敗 → Leadがリトライまたは再spawn
  失敗間の組み込み学習メカニズムなし

CMSは学習ループを統合。Agent Teamsは協調を提供するが、進化は提供しない。

Agent Teamsがリードしている点

1. リアルタイムピア通信

Agent Teams:
  frontend-dev → SendMessage → backend-dev
  「APIスキーマの準備はできた？」
  リアルタイム、任意対任意、両方が同時に実行中

CMS:
  Iteration 5がcheckpointを書き込む
  Iteration 6がcheckpointを読み取る
  直列のみ。並行対話なし。

Agent Teamsは並列対話をサポート。CMSは本質的に直列。

2. ネイティブ統合

Agent Teams:
  Claude Codeランタイムに組み込み
  Shift+Up/Downでteammateを選択
  Ctrl+Tでtask listを表示
  設定不要

CMS:
  カスタムskill + checkpointフォーマット + オーケストレーションロジック
  セットアップと理解が必要
  Claude Code内部変更時に壊れる可能性

Agent Teamsはファーストクラス。CMSはユーザーランドのハック（見事なハックだが、それでもハック）。

3. トポロジーの柔軟性

Agent Teams:
  Star、Mesh、またはハイブリッドトポロジー
  任意のteammateが他の任意のteammateにメッセージ可能
  Leadは委任して手を放せる

CMS:
  厳格な直列パイプライン
  イテレーション間の横方向通信なし
  Orchestratorが常にコントロール

マイグレーションパス

Agent Teamsが安定したら、CMSのコンセプトは直接マッピングできる：

# CMS checkpoint.json → Agent Teams TaskList
checkpoint = read_checkpoint()
for task in checkpoint["remaining_tasks"]:
    TaskCreate(subject=task["name"], description=task["spec"])

# CMS iteration spawn → Agent Teams teammate
# Before:
spawn_cms_iteration(task, checkpoint)
# After:
Task(subagent_type="general-purpose", team_name="dev-team", prompt=task)

# CMS状態伝達 → Agent Teamsメッセージング
# Before:
write_checkpoint({"api_schema": schema, "status": "ready"})
# After:
SendMessage(recipient="frontend-dev", content=f"API schema ready: {schema}")

# CMS resume → Agent Teams task list復旧
# Before:
cms_iterate --resume
# After:
TaskList()  # pendingタスクを見つけて再割り当て

ビジネスロジックは変わらない。トランスポート層が変わる。

より深い教訓

これは「私たちが先だった」という話だけではない。パターン認識の教訓だ。

第一原理で本当の問題を解決すると、プラットフォームベンダーが最終的にリリースする同じアーキテクチャに収束することが多い。

CMSはAgent Teamsをコピーしていない。Agent TeamsはCMSをコピーしていない。両者は独立して以下に到達した：

Context分離 — 別の仕事には別のウィンドウ
共有状態 — 単一contextの外にある協調層
ライフサイクル管理 — 起動、作業、報告、死亡
オーケストレーション — 次に何が起こるかを誰かが決める必要がある

これらは実装の選択ではない。マルチエージェントシステムのアーキテクチャ的必然だ。

次に何を作るべきか

パターンが成立するなら、Agent Teamsが最終的に必要とするもの — そして今すぐ作れるもの：

今日欠けているもの	なぜ必要か	今すぐ作る
Heartbeatプロトコル	サイレントデス検出（Rate Limit Kill）	Checkpointタイムスタンプ + タイムアウト検出
配信確認	メッセージが実際に読まれたか確認	Checkpoint状態のackフィールド
再起動後の復旧	クラッシュ後の復旧	CMSに既存 — `--resume`
失敗間の学習	よりスマートに、単なるリトライではなく	CMSに既存 — Self-Evolving Loop
Teammate毎のコスト追跡	予算管理	イテレーション毎のトークンカウント

今日ユーザーランドのソリューションを作る。明日ネイティブAPIに置き換える。

これが6ヶ月先を行き続ける方法。

Agent Teams：Meshトポロジーと5つの死に方 — 通信トポロジーと障害モード
マルチエージェントアーキテクチャ：並列実行パターン — Sub-agentの基礎
Claude Opus 4.6：Agent Teams、1M Context & Effort Tuning — Agent Teams機能概要