↳ 以下の Capability と Product State は現在の Claude Code 公式文書に基づく。判断規則、Cost、Failure Pattern は ClaudeWorld の分析であり、性能保証ではない。
コントロールモデルを選ぶ
五つの Surface、異なる責任。
Subagents、Agent View、Agent Teams、Dynamic Workflows は異なる実行方式。Worktrees は複数方式を支える File State 分離 Layer。
MODE / 01 ● 公式文書あり
BOUND された委任
Subagents
- 用途
- 検索、Logs、Tests、File 内容が Main Context を圧迫する、境界明確な Side Task。
- 調整役
- Parent Conversation が委任と統合を担当。
- 通信
- Worker は Caller に結果を返し、Peers 間の Team Channel はない。
- State 境界
- 既定は新しい Context。編集には Worktree を追加可能。
- Cost 形状
- 起動 Cost と Active Worker ごとの Context。
- 注意点
- Phase 間で同じ Working Context が必要なら Main Conversation に残す。
公式出典 ↗ MODE / 02 ◐ Research Preview
人が監督する SESSIONS
Agent View
- 用途
- 独立した複数 Job を Dispatch し、状態確認、Reply、Attach、後から再開したい。
- 調整役
- 人が完全な Background Sessions を監督。
- 通信
- Sessions は人に報告し、互いに直接通信しない。
- State 境界
- Dispatch された編集 Session は個別 Worktree を使う。
- Cost 形状
- Active Job ごとに完全な Session と Quota。
- 注意点
- 運用 Console であり、Peer-to-peer Team Protocol ではない。
公式出典 ↗ MODE / 03 ◐ Experimental
協調する PEERS
Agent Teams
- 用途
- Workers が Tasks、依存関係、Message、競合仮説を共有する必要がある。
- 調整役
- Team Lead が計画、割当、監督。
- 通信
- Shared Task List と Teammate Messaging。
- State 境界
- Teammate Worktrees は自動ではないため、File Ownership を分割。
- Cost 形状
- 最も高い対話 Cost。Teammate ごとに完全 Context と協調が必要。
- 注意点
- Experimental で既定では無効。通信が Noise になり得て、同じ File の編集は上書きの危険が残る。
公式出典 ↗ MODE / 04 ● 公式文書あり
SCRIPT 化した実行 GRAPH
Dynamic Workflows
- 用途
- 少数 Workers を超える規模、または再実行・Cross-check が必要な固定 Graph。
- 調整役
- JavaScript Workflow が実行 Plan を保持。
- 通信
- 自由な Peer Chat ではなく、構造化 Phase Output と Script 検証。
- State 境界
- Workflow と起動する Workers が定義。
- Cost 形状
- Agent Runs と共に増加。Budget と Failure Policy を明示する。
- 注意点
- 安定した Work Shape 向け。実行中に頻繁な人の方向転換が必要な Task には不向き。
公式出典 ↗ LAYER / FS ◇ 支援 Layer
FILE STATE 分離
Worktrees
- 用途
- 二つの Sessions または Subagents が同じ Repository を同時編集する可能性がある。
- 調整役
- 人、Subagent、Session の各モデルと併用。
- 通信
- なし。Worktree は Workers を調整しない。
- State 境界
- 個別 Checkout と Branch、Repository History は共有。
- Cost 形状
- 環境初期化、Disk、Dependencies、Review、Merge。
- 注意点
- 直接 File 衝突を防ぐだけで、意味的 Conflict、安全性、悪い Merge は解決しない。
公式出典 ↗ ROUTING LOGIC
五つの質問を順番に行う
責任を閉じる最小の Control Surface から始め、次の答えが必要な場合だけ Workers を増やす。
- Q01
一つの境界明確な結果を、この会話へ戻せばよい？
YES Subagents
Research、Logs、Tests、Focused Review の既定。 - Q02
独立した完全な Conversations を自分で監督したい？
YES Agent View
編集 Work は Agent View の Worktrees と組み合わせる。 - Q03
Workers 同士が Message や Dependency 管理を必要とする？
YES Agent Teams
Shared Tasks と Mailbox が Token Cost に見合う場合だけ。 - Q04
Work Shape は大規模、反復可能、Cross-check 必須？
YES Dynamic Workflows
Plan、Fan-out、Barrier、Validation を Code にする。 - Q05
Branch が重複する File または State を変更する？
YES Ownership を分割 · Worktrees を追加
分割できない場合、Write Phase を直列化する。
並列化の受入テスト
すべての Branch に契約が必要
Worker は Plan ではない。Fan-out 前に Dependency、Ownership、Output、Merge 境界を明示する。
GATE / 01 1
独立 Dependency
他 Branch の未完成 Output を待たない。
GATE / 02 2
排他的 Ownership
File Set、State Surface、外部 Side Effect ごとに一人の Owner。
GATE / 03 3
Bounded Return
未加工 Transcript ではなく Evidence、Patch、Decision を返す。
GATE / 04 4
State 分離
衝突時は Read-only Work または Worktree を使う。
GATE / 05 5
Single Merge Gate
一人の Lead が統合、Test、Conflict 解消、Outcome 検証を行う。
! 反射的に並列化しない
次の Work Shape は Fan-out の利益より協調損失が大きくなりやすい。
直列 Dependency Chain
B が A の結果を必要とし、同時開始は待機か Rework を生む。
Shared Mutable State
複数 Workers が同じ Files、Schema、Environment、外部 Record を変更。
小さすぎる Task
起動と統合の Cost が Work 自体を超える。
不明確な Question
曖昧さが増幅し、比較不能な Answer が返る。
厳しい Budget
Active Context ごとに Quota を使う。Concurrency は無料 Throughput ではない。
REFERENCE DISPATCH
Evidence を並列化し、Decision を直列化する。
安全な調査は独立 Evidence を Fan-out し、一つの Synthesis Barrier を通過してから Shared Write を許可する。
MISSION Checkout Latency Regression の原因を探し、三人の Workers が同じ Code を競合編集しないようにする。
FAN-OUT ↓
A / RUNTIME Logs と Latency Metrics を確認
最初の Divergent Signal、Timestamp、Evidence を返す。
B / HISTORY Recent Changes を Review
最小 Suspect Commit Set と Latency へ影響する理由を返す。
C / PATH Request Path を Trace
測定または推論した Bottleneck Boundary を返す。編集しない。
BARRIER → SYNTHESIS → ONE OWNER Lead が Evidence を比較し、一つの Hypothesis と Implementation Owner を選び、Tests と Production-shaped Verification を実行する。
PROMPT PATTERN まず独立した Evidence Branch を特定し、その Branch だけを並列実行する。各 Worker に一つの Bounded Return Contract を与え、重複 Write Ownership を禁止する。実装前に Evidence を統合し、一人の Owner が編集と検証を行う。