なぜGraph、Loop、Harness Engineを追わないのか：CMSはすでにOuter Loopへ移っている

ここ数か月、graph engine、loop engine、harness、Agent Teams、nested subagentsが大きな話題になっている。

では、なぜ私たちはこうした仕組みをほとんど議論せず、積極的に共有もしないのか。

答えは単純だ。その多くはプロダクトのinner loopを拡張するものであり、私たちはすでに問題をouter loopへ移しているからだ。

inner loopが重要ではない、という意味ではない。むしろClaude Code、Codex、Grok自体がプロダクトなのだから、agentの思考力やtool利用能力を高め、より多層のsubagentを扱えるようにするのは当然だ。ただし、すでにouter loopを持っていれば、新しいgraph、loop、harnessは能力を初めて解放するものではない。評価し、取り込み、交換できる部品になる。

Inner Loopを磨くのはプロダクトの役割

coding agentの基本的なinner loopは、次のようなものだ。

prompt
  → modelが判断
  → tool call
  → observation
  → 次の判断

現在のClaude Code、Codex、Grokは、このloopに優れたcontext管理、subagent、team、graph、hook、background task、resume体験を加え続けている。

これはプロダクトが担うべき仕事だ。すべての利用者がsupervisor、state machine、checkpoint、failure domainに詳しいわけではない。エンジニアが最初に独自のexecution systemを設計しなくても、仕事を確実に完了できるよう、プロダクト側が複雑さを包み込む必要がある。

しかし、設計経験のあるエンジニアには、もう一段外側の構造が見える。Claude Code、Codex、Grokがtask lifecycle全体を所有する必要はない。それらをworkerとして扱うこともできる。

アーキテクチャの経験があれば、早い段階でOuter Loopへ進める

process、state、retry、idempotency、lock、recoveryを理解していれば、プロダクトが提供するinner loopを自分のouter loopに組み込める。

durable stateを読み込む
  → inner-loop workerを1つ選ぶ
  → 独立processを起動する
  → 実際の結果を検証する
  → checkpointへ書き込む
  → retry、CLIの切り替え、停止、または次のiterationへ進む

この時点でworkflowを所有するのは、特定のLLM sessionではなく外部control planeになる。

modelもCLIも交換でき、processが終了してもtask自体は残る。何が完了し、何が未完了で、どの判断を行い、どこで止まり、次に何をすべきかは、model contextの外側に保存されているからだ。

これがCMS（Claude Multi-Session）の中核である。

CMSは`claude -p`を交換可能なWorkerにする

CMSは、すべての知能を巨大なroot promptへ詰め込むものではない。Claude Codeの非対話型-p／--print modeを切り出し、外部プログラムから繰り返し起動できるworker protocolとして扱う。

CMS orchestrator
  → checkpointを読み込む
  → claude --printをspawnする
  → workerが限定されたtaskを完了し、reportを出力する
  → orchestratorが結果を検証し、stateを更新する
  → processを終了し、次のiterationで新しいworkerを起動する

workerの内部では、引き続きsubagent、Agent Teams、graph workflowを利用できる。違いは、そのworkerがmission全体を所有しないことだ。scheduling、parallelism、retry、stop condition、CLI routing、resume pointはouter loopが管理する。

CMSは特定のmodelにも依存しない。同じstate contractをClaude、Codex、Geminiへ渡せる。workerがtask stateを読み、構造化されたreportを出力できれば、次のiterationを別のCLIが引き継げる。

CheckpointはProcess間のAPIである

outer loopでは、「前のiterationで多くの作業をした」という会話要約を残すだけでは不十分だ。次のprocessには、少なくとも次の情報が必要になる。

完了済みと未完了の項目
重要な判断と、破ってはいけない制約
現在のblockerと失敗理由
前のiterationで実際に変更した内容と検証結果
次に実行できるaction

CMSは、これらをcheckpointとiterationごとのreportとして保存する。stateの更新にはlock、atomic write、backupを使い、parallel workerによる上書きや、process中断時に不完全なstateが残ることを防ぐ。

そのため、process crashはmissionの消失を意味しない。新しいterminal、新しいprocess、さらには別のCLIからでも、checkpointを起点に続行できる。

CMSの各コマンドは、形の異なる長期Taskを扱う

社内で使っている高度なCMSは、1本の長大なpromptではない。同じprocess、state、recovery contractを共有するコマンド群である。

コマンド	用途
`/cms`	engineering requirementを分解し、planner、builder、tester、reviewer、fixerなどの独立workerへ割り当てる
`/cms-auto-cycle`	iterationごとにfresh processを使い、TDD／acceptance criteriaのcycleを1回完了する
`/cms-iterate`	数十iterationにわたって継続でき、stopとresumeが可能な汎用iteratorを実行する
`/cms-auto-explore`	次の高価値な機会を繰り返し探索、評価、実装、検証する
`/cms-review`	大規模projectをmodule単位でreviewし、発見事項を保存して、段階的に修正と検証を行う

これらに共通するのはagent数ではない。task lifecycleがagent processの外側にあることだ。

このアーキテクチャは最近始めたものではない

私たちは2025年7〜11月の社内構築期間からouter loop architectureを使い始め、現在まで運用を続けている。高度なCMSでは各iterationを独立processへ隔離し、checkpoint、report、resume、backup、parallel control、cross-CLI routingまで扱う。

2026年1月には、オープンソースprojectのDirector Mode Liteを通じて基盤版も公開した。初版にはiteration、checkpoint、resume、status、stop、Stop Hookが含まれ、その後のEvolving Loop／Orchestratorではphase-based stateとfile-based reportを追加した。

公開したのはouter loopの基礎modelであり、完全なprocess-isolated CMSは現在も社内で使う高度版である。

このアーキテクチャ路線は、最近のgraph、loop、harnessをめぐる議論より少なくとも8か月早い。重要なのは特定の機能名ではない。より早い段階で、誰がloopを所有すべきかを捉えていたことだ。

なぜ私たちは新しいEngineを逐一追わないのか

新しいAgent Team、graph engine、harnessによってworkerが高速になり、協調しやすくなり、telemetryが充実するなら、もちろん採用できる。CMSのworker processへそのまま組み込めばよい。

ただし、評価基準は「最新の方法かどうか」ではなく、次の点になる。

state contractを改善するか
isolation、recovery、observabilityを高めるか
failure costを下げるか
workerを交換しやすくするか

答えがyesなら取り込む。既存のtopologyへ新しい名前を付けただけなら、そのまま仕事を進める。

最近注目されているinner-loop mechanismを、私たちが一つずつ議論しないのはそのためだ。見落としているわけでも、新しいtoolを拒んでいるわけでもない。outer loopはすでに整っており、そうしたtoolを正しいアーキテクチャ上の位置へ置けばよい。

toolの名前は変わり続け、subagentの層も増え続ける。しかし、成熟したexecution systemが問い続けることは同じだ。

今考えているprocessが消えたあとも、仕事そのものを続けられるか。

CMSの答えは「続けられる」だ。processはworkerであり、checkpointが事実を保持し、outer loopがmission全体を所有しているからだ。