「エージェントがエージェントを生成」というコンセプトはAI界隈で使い古されている。ほとんどのデモは結局10個の派手なウィンドウを立ち上げて、何もせず終わる。
しかしCursorの/orchestrateは違う。
Cursor SDK上に構築されたスキルで、コア機能は複雑なタスクを分解・完了するためにサブエージェントを再帰的に生成すること。エージェントを大量にspawnして喧嘩しないことを祈るのではなく、明確な階層アーキテクチャを持っている。
アーキテクチャは並列処理ではなく、責務分離
最初の反応は「マルチエージェント並列処理じゃん」かもしれない。違う。
鍵は関心の分離：root plannerがタスク分解と担当を処理し、scoped workerが具体的なサブタスクを処理し、verifierが結果の品質をチェックする。これは単純な並列処理のトリックではなく、コントロールプレーンアーキテクチャだ。
コミュニティ開発者の言葉：
"重要なのは多くのエージェントをspawnすることじゃない。それは表面的で簡単なトリックだ。重要なのは関心の分離：root planner -> scoped worker -> verifier。"
ここが見る価値がある部分。
内部データは退屈じゃない
Cursorチームは自社プロジェクトで実測：
- 内部スキル自動研究：token使用量20%削減、evalスコアは逆に向上
- 内部バックエンドコールドスタート時間：80%削減
この二つの数字を一緒に見ると面白い。token使用量は減ったが品質は上がった。つまり再帰的に生成されたサブエージェントは無駄なことをしていない — 各サブタスクのスコープが十分に狭く、エージェントがコンテキストで迷子にならない。コールドスタート時間の大幅削減は並列分解が実際に効いていることを示している。
どう使うか
インストールは簡単、Cursorで実行：
/add-plugin orchestrate
Cursor SDKを通じて呼び出す。タスク境界と検証ロジックを定義するための工学的基礎が必要 — 「一句话入力すれば全て完了」系のおもちゃではない。
Cursor以前の並列タスクとの違い
Cursorは以前parallel multitaskingをリリース済み。プランを並列サブタスクに分割し、非同期サブエージェントで同時に実行できる。
/orchestrateの違いは再帰性と検証。並列タスクは「一回分割して並列実行」；orchestrateは「分割後、サブエージェントがさらに分割でき、各層に検証がある」。
これは「チーム分工」から「管理階層のある組織」への進化のようなもの。
追う価値があるか
Cursor SDKでエンジニアリング自動化を既に使っているなら、/orchestrateはすぐに試す価値がある。高頻度使用シナリオではtoken削減効果は小数ではない。
Cursorエディタでコードを書くだけなら、この機能の直接的価値は限定的 — CI/CDパイプラインや自動コードメンテナンスが必要なチーム向け。
しかしアーキテクチャの考え方は参考になる。エージェントタスクの複雑さが一定の閾値を超えると、「一つのpromptで全てやる」アプローチは崩壊する。その時、階層編成はオプションではなく必須になる。
コミュニティでは既にこのパターンをClaude Codeや他のエージェントフレームワークに移植する議論が出ている。普遍的に適用可能だと証明されれば、エージェント編成の標準パラダイムが変わるかもしれない。
主要ソース：