AI News HubLIVE
サイト内リライト4 分で読了

Claude Code のプロセス外オーケストレーション

Claude Code のプロセス内オーケストレーションは、一見無関係な問題(子エージェント出力のオーバーフロー、トークン共有、階層の欠如、再起動時の状態損失、作業ディレクトリ競合)を引き起こします。Claudeverse はオーケストレーターをエージェントプロセスの外に移動することで解決しますが、プロセス管理の新しい課題が生じます。

ソースHacker News AI著者: kcarriedo

私たちは、複数の Claude Code エージェントを並列実行するツール Claudeverse を構築しています。作業が進むにつれ、Claude Code に関する一見無関係な不満の多くが、単一のアーキテクチャ上の決定に起因することが明確になってきました。

症状

anthropics/claude-code のイシュートラッカーを調べると、同じフラストレーションのバリエーションが見つかります。

子エージェントの出力が親セッションをオーバーフローさせ、クラッシュする(#23463:7つの並列子エージェント、約15万文字の結果、「8回連続の「プロンプトが長すぎる」エラー、回復メカニズムなし」)。子エージェントが一つのトークンバジェットを共有する(#10212:「すべての子エージェントが親セッションの20万トークンバジェットを共有する」5つ実行するとすべてが枯渇)。オーケストレーターパターンが構造的にブロックされる(#46424:「トップレベルのREPLのみがAgent()を呼び出せる」子エージェントは自分の子を調整できない)。再起動ですべてが消える(#39663 と #43696:数時間のデバッグセッションが再起動で消失、--continue と --resume はコンテキストを戻さない)。並列セッションが作業ツリーをめぐって争う(#52051:二つのセッションが同じリポジトリ上で「互いの作業ツリーを踏む」コミュニティはすでに Gwt-Claude のようなツールを構築)。

これらは五つの異なるバグに見えますが、一つに近いです。

共通原因

Claude Code では、オーケストレーター自体がエージェントです。子エージェントを生成する判断は Claude セッションのターンとして行われます。そのため、オーケストレーターが調整するすべてが、そのプロセス、コンテキストウィンドウ、作業ディレクトリ、セッションライフタイムの中に閉じ込められます。

子エージェントの結果は親のコンテキストに戻されるため、十分な数が溢れます。子エージェントは親のトークンバジェットを消費するため、競合します。トップレベルのREPLのみがディスパッチできるため、階層は不可能です。状態はセッションに保存されるため、再起動は消去です。すべてのエージェントが一つのチェックアウトを共有するため、並列エージェントは衝突します。

個々の設計が間違っているわけではありません。問題は、オーケストレーターをエージェント内部に置くことで、コーディネーターとそれが調整する作業が互いに分離されなくなることです。

オーケストレーターの外部化

私たちが採用した代替案:オーケストレーターはエージェントではありません。独立したプロセスであり、Claude Code エージェントを子プロセスとして起動し、外部から調整します。私たちのアーキテクチャはこの分割を中心に設計されており、それが五つの症状を分解可能にします。

  • コンテキスト分離:各エージェントは独自のセッションコンテキストを持つ Claude CLI プロセスとして実行されます。子エージェントの出力はオーケストレータープロセスによってキャプチャされ、親エージェントのプロンプトに連結されません。一つのエージェントがコンテキストを満たしても、それはそのエージェントの問題であり、セッション全体のクラッシュではありません。
  • 独立したコンテキストウィンドウ:各エージェントは独自のプロセスとセッションを持つため、エージェント間で一つのコンテキストウィンドウを分割する必要がありません(これはプロセスレベルの分離であり、Claude アカウントのクォータに影響するものではありません)。
  • ピアディスパッチ:「トップレベルのREPL」は存在しません。オーケストレーターは通常のコードであり、実行するエージェントはすべてピアのサブプロセスです。子エージェントを調整するエージェントも、単なるサブプロセスです。
  • プロセス外部の状態:オーケストレーターは、単一のエージェントプロセスの外部でサイクルとタスクの状態を追跡します。エージェントプロセスは使い捨て可能ですが、記録は残るため、クラッシュや再起動時にその状態から再開でき、ゼロからやり直す必要はありません。
  • ワークスペース分離:各エージェントは明示的な作業ディレクトリを持つ独自の CLI プロセスとして起動されるため、オーケストレーターはエージェントを別々のチェックアウトやワークツリーに配置でき、すべてのワーカーを一つの共有リポジトリ状態に強制する必要がありません。これにより、作業ツリーの衝突は回避不可能な副作用ではなく、オーケストレーションポリシーの問題になります。

正確な説明

いくつか正直な注意点を述べます。

「プロセス外部の状態」はサイクル/タスク状態であり、セッション全体の再生ではありません。再起動後も残るのは構造化された記録(何を試したか、どのようなステータスで終わったか、どのタスクに触れたか)であり、エージェントのコンテキスト内の推論チェーン全体ではありません。再調査のループを止めることができますが、タイムトラベルではありません。

これは協調レイヤーであり、モデルの変更ではありません。Claudeverse は Claude CLI をラップします。単一のタスクでモデルをより良くするわけではなく、多くのタスクを同時に実行可能にします。

プロセス外オーケストレーションには独自のコストがあります。サブプロセスの監視、出力の無制限バッファリングなしの排出、子プロセスがリークしないようにプロセスグループを強制終了、クラッシュをまたいだ共有リソースの調整。私たちはコンテキスト分離の問題をプロセス監視の問題と交換しましたが、それがより良いトレードオフだと考えています。なぜなら、監視は比較的理解された分野であり、コンテキストウィンドウの共有はそうではないからです。

なぜこれを書くのか

主に、イシュートラッカーが多くの人々が独立して同じ壁にぶつかり、それを五つの別々の悩みとして扱っていることを示しているからです。共通の原因を名前付ける価値があります:プロセス内オーケストレーションはコーディネーターを作業に結合させます。修正方法はフラグではなく、コーディネーターを外部に移すことです。