オーケストレーション

単一のエージェントは、ひとつのことなら得意です。しかし、それより大きな依頼もあります。「X の市場を調査してポジショニングドキュメントを書く」「この機能をエンドツーエンドでリリースする」「このモジュールを監査し、見つかった問題を修正する」。オーケストレーションは、Control Center がそうした依頼を扱う仕組みです。オーケストレーター（通常はあなたの CEO エージェント）がチーム全体のプランを提案し、あなたがそれを一度承認すると、決定論的なマテリアライザーが作業を行うパイプラインに変換します。

これは、作業を進める既存の 2 つの方法の中間に位置します。

やりたいこと	使うもの
1 つのタスクを 1 つのエージェントに任せる	スペース内のメッセージ
すでに知っているプロセスを手作業で定義する	パイプラインテンプレート
目標を伝えて、プランはチームに考えさせる	オーケストレーション

提案の形

オーケストレーターにゴールを与えると、構造化された OrchestrationProposal が返ってきます。自由形式の文章ではなく、アプリが検証して実行できる型付きのプランです。提案には次のものが含まれます。

ゴール: 高レベルな依頼を言い換えたもの。
ロール: 作業を行う担当。各ロールは、あなたが選ぶ既存のエージェントか、承認時にオーケストレーションが作成する新規採用のいずれかです。
サブチケット: 作業をチケットの DAG に分解したもの。
調査 （任意）: 最初に実行され、以降のステップに引き継がれる調査フェーズ。
ディスカッション （任意）: 作業を始める前に各ロールが構造化された立場を投稿する、回数に上限のあるラウンド。
統合: 成果物を生成する最終ステップ。
予算: 宣言されたコスト上限。

どこで確認するか

同じオーケストレーションを表示するサーフェスは 2 つあります。

提案カードは、プランを生成した会話の中にあります。ライフサイクル全体（提案中、実行中、完了）を通じて再描画される 1 つのメッセージで、そこに承認とキャンセルのアクションが付いています。

Plan Studio はエディターです。DAG キャンバス、ノードインスペクター、リビジョンと差分のドロワー、そして見積もりを表示する承認バーを備えています。このカードから直接、エディタータブとして開きます。サイドバーに「プラン」項目は意図的にありません。/plans と /plans/:kind/:id は共有用のディープリンクとして存在します。

承認はオペレーター専用です。そのための MCP ツールはありません。エージェントは提案（propose_orchestration）、プランの送信（submit_plan）、プレイブックのインスタンス化（run_playbook）を行えますが、承認できるのは人間だけです。さらに、エージェントが開始したリビジョンは 2 分間のクールダウンでレート制限されるため、再プランのループはフィードを溢れさせる代わりにまとめられます。

承認前に変更できるのは、ノードインスペクターが表示する範囲です。サブチケットのタイトル変更や書き換え、所有するロールの変更、依存関係の付け替え、出力スキーマの編集、ノードの完全な削除ができます。構造ノード（調査、ディスカッション、統合）と、すでに実行されたノードは読み取り専用です。エディターからは、ロールを特定の名前付きエージェントに固定することも、予算を編集することもできません。

1 つのプランに対する 2 人の編集者は、マージではなく楽観的同時実行制御で解決されます。すべての編集は、それが基づいた base_revision を保持します。古いリビジョンに基づく編集は、他人の編集を黙って上書きするのではなく、「the plan moved on」として拒否されます。巻き戻しも削除ではありません。古い提案を新しいリビジョンとして追加するため、リビジョンのタイムラインは増える一方です。

誠実な見積もり、なければ「なし」

承認バーの見積もりは、ロールごとの実際の完了済み実行履歴から、四分位範囲（p25〜p75）のバンドとして算出されます。コストの合計は見積もり可能なノードを合計したものです。所要時間は合計ではなく、DAG を通るクリティカルパスです（並列ブランチは重なります）。

完了済み実行履歴がないロールのノードは、sampleSize: 0 と null の範囲を報告します。これはまさにそのとおり、つまり不明として表示され、でっち上げの単一値として表示されることはありません。信頼できない見積もりは、見積もりがないよりも悪いからです。履歴があるノードとないノードが混在する場合、合計は部分的とマークされます。影響範囲は、ノードが symbol または file の由来参照を宣言している場合にのみ表示されます。それらがないノードは、文章から推測するのではなく「不明」のままです。

承認は 1 回、その後は決定論的な実行

これが核心となる考え方です。エージェントがプランを立て、決定論的な関数が実行します。 あなたが承認すると、LLM も I/O も持たない純粋関数である OrchestrationMaterializer が、提案を実際のパイプラインに変換します。同じ提案と同じ解決済みロールが与えられれば、常に同じ DAG を生成します。これは重要です。生成されたパイプラインは、エンジンがすでに無償で提供しているすべてを継承するからです。再起動をまたぐ中断と再開、クラッシュからの復旧、実行ごとのコストとトークンの集計、そして実行詳細 UI です。

承認は、作業に必要なスキャフォールドも作成します。

新規とマークされたロールを採用します（採用したエージェント id を記録するため、承認途中でクラッシュしても重複採用なしで再開できます）
ロールをまとめるチーム
親チケットを格納するプロジェクト
すべてを動かすパイプラインのテンプレート + 実行

ライフサイクル

proposed → approved → executing → synthesizing → completed
                  ↘                 ↘              failed
                   ↘                 ↘            cancelled

ステータス	意味
`proposed`	プランの準備が整い、最初の 1 回の承認を待っている
`approved`	承認済み。マテリアライズが進行中（採用、チーム、プロジェクト、パイプライン）
`executing`	生成されたパイプラインが実行中: サブチケット、ディスカッション、作業
`synthesizing`	サブチケットが完了し、統合ステップが成果物を生成している
`completed`	完了: 親チケットが完了としてマークされ、成果物が共有スペースに投稿される
`failed`	マテリアライズに失敗したか、生成されたパイプラインの実行が失敗した
`cancelled`	キャンセルされた

単調増加するリビジョン番号が、オーケストレーターがまだ proposed の間に提案を改訂するのにあわせてそれを追跡します。アプリは、あなたがどのリビジョンを承認したかを記録します。propose_orchestration は、ステータスが proposed でなくなると改訂を拒否します。

オーケストレーションは常に親チケットに対して開始され、1 つのディスカッションスペースを共有するため、取り組み全体が単一の作業項目まで追跡でき、チームは 1 つの部屋で会話します。

完了するとどうなるか

常駐リスナーが生成されたパイプラインを監視し、その終端状態をオーケストレーションと親チケットに反映します。そのため、完了と失敗は、あなたがすでに確認している場所に表示されます。オーケストレーション機能は独自の実行エンジンを必要としません。

オーケストレーションはいつでもキャンセルできます。キャンセルすると、進行中の作業は破棄されます。