サブエージェント駆動開発とは、大きな作業の各タスクを新たにディスパッチしたサブエージェントに任せ、タスクの合間にコードレビューを挟む実践である。これにより品質ゲートがすべてのステップに置かれ、単一のエージェントが仕事全体をコンテキストに抱え込むことがなくなる。メインエージェントはオーケストレーターとして振る舞い、サブエージェントを起動し、それぞれに必要なものを渡し、その作業を制御する。ここでは 2 つの実装を取り上げるが、両者はこの実践を異なる位置に据えている。Context Engineering Kit の Subagent-Driven Development プラグインは、これを 仕様駆動開発 を蒸留した版として提示している。完全な仕様を先に作成する代わりに、judge サブエージェントと meta-judge サブエージェントを通じて、仕様にあたる材料をその場で、実装と並行して生成するというものである。一方 Superpowers は、設計が合意されて詳細な計画として書き起こされた後に、その計画を実行するステップとしてこれを位置づけている。
用法
1 つのコンテキストで作業を続けるのではなく新しいサブエージェントを起動する理由として挙げられているのは コンテキストロット である。独立したエージェントを隔離することで、それぞれが短くクリーンなコンテキストで作業でき、プロジェクトはこれによってモデルがどのステップでも最良に近い性能を保てると主張している。これは サブエージェントアーキテクチャ 全般の背後にあるのと同じ論理を、システムの形ではなく作業の単位に適用したものである。
Context Engineering Kit は、このパターンを単一のワークフローとしてではなく、一連の実行プリミティブとして提供している。自己批評による検証を伴う焦点を絞ったサブエージェントの起動、独立した judge と合格するまで続く自動リトライのループを伴う 1 つのタスクの実行、隔離されたコンテキストで独立した複数の対象に同じタスクを並列実行すること、複雑なタスクをコンテキストを順に引き継ぐ逐次的なサブエージェントのステップに分解すること、競合する解決策を生成して最良のものを統合すること、解の空間を木として探索し弱い枝を刈り込むこと、そして完成した作業を 1 つの judge または討論する複数の judge で評価すること、である。これらと並んで、単一エージェントのコンテキストの上限を超える作業について、スーパーバイザー型、ピアツーピア型、階層型のマルチエージェントアーキテクチャのどれを選ぶかについてのガイダンスも同梱している。
Superpowers では、この実践は番号付きで並ぶ一連のワークフロースキルの 1 つである。計画が存在した時点で有効になる。その計画は 2〜5 分程度のタスクに分割され、各タスクには正確なファイルパス、完全なコード、検証手順が含まれている。そのうえでタスクごとに新しいサブエージェントをディスパッチし、各タスクの後にレビューを行う。スキルライブラリはこのレビューを 2 段階のもの、すなわちまず仕様への準拠を、次にコード品質を確認するものとして説明している。ワークフローの同じ地点には代替案も用意されており、それは現在のセッションの中でインラインに計画を実行し、最後にブランチ全体に対して新たなレビューを 1 回だけ行うというものである。プロジェクトはこの選択をトレードオフとして捉え、サブエージェント駆動開発を最も徹底した選択肢、インライン実行を最も安価な選択肢と位置づけている。README によれば、このやり方で作業するエージェントが計画から逸れることなく数時間にわたって自律的に動き続けることも珍しくない。
適用範囲
このアプローチが当てはまるのは、仕事を、サブエージェントが自己完結した指示書から完了できるステップに切り分けられ、かつ作業が大きく、単一のコンテキストでは終わりまでに劣化してしまう場合である。このアプローチは、オーケストレーターがタスクを正しく分解し、各サブエージェントに十分なコンテキストを渡せることを前提としている。クリーンな状態から始めるサブエージェントは、与えられたものしか持たないからである。Context Engineering Kit の仕様駆動プラグインのガイダンスは、誤った仕様から始めたエージェントも自己修正はできるものの、はるかに長い時間がかかり、誤った道筋に時間を費やすと報告しており、作業を依存関係を持つより小さなタスクに分解することを強く勧めている。Superpowers では、タスクごとのサブエージェントは設計が承認され、計画が書き起こされた後にはじめて起動される。
コストはトークンのオーバーヘッドである。Context Engineering Kit の比較では、judge とリトライを組み合わせる変種と段階的に進める変種は、おおむね単純なリフレクションと完全な仕様駆動のルートの中間に位置づけられている。一般にワンショットのプロンプトより信頼性が高く、書かれた仕様より安価であり、報告されているトークンのオーバーヘッドはそれぞれ 1.5〜3 倍と 3〜5 倍である。これらの数値はプロジェクト自身のものであり、独立したベンチマークではなく自らの本番利用から得られたものである。
このアプローチがどの程度確立されたものなのかは、これらの情報源からは判断できない。いずれもプロジェクトが自らのツールを説明したものであり、独立した評価ではなく自らの利用に基づいている。2 つのツールキットがこの名前の実践を提供しているが、一方が他方から派生したものかどうかについて情報源は何も述べていない。
関連用語
- サブエージェントアーキテクチャ — この実践が作業の単位に適用している一般的な構成
- コンテキストロット — この実践が回避するよう設計されている劣化
- 仕様駆動開発 — この実践がその蒸留版として提示されている、より重いアプローチ
- LLM-as-a-Judge — Context Engineering Kit の judge サブエージェントが実装している手法
- Superpowers — この実践をワークフローの 1 ステップとして提供するスキルプラグイン