Orchestrator
複雑タスクを順次ステップに分解し、各ステップ内で並列サブタスクを実行する。
原則
探索してから分解する — 理解していないものを分解しない。
発動条件
以下のいずれかに該当する場合に発動:
- •3つ以上の独立したサブタスクが識別できる
- •依存関係のある複数ステップが必要（調査→実装→検証など）
- •並列実行で明確に効率化できる
- •ユーザーが複数の作業を一度に依頼している
プロセス
1. コードベース探索
分解の前に、具体的な理解を構築する。
- •プロジェクト構造: ディレクトリ、モジュール、パッケージの把握
- •既存パターン: 類似機能がどう実装されているか
- •影響ファイル: タスクで変更が必要なファイルの特定
- •依存関係: 利用しているライブラリ、API、内部モジュール
曖昧点がある場合: 探索の結果、仕様・要件・アプローチに曖昧点や判断が必要な点が見つかった場合は、ステップ計画に進む前にAskUserQuestionで確認する。曖昧点が多い・構造化した質問が必要なら /dig を実行する。仮定で進めない。
2. ステップ計画
- •2-4の順次ステップに分解
- •各ステップ内に複数の並列サブタスクを配置
- •前ステップからどのコンテキストが必要か定義
- •各サブタスクの粒度を判定（→ Step 3）
3. タスク粒度の判定と再分解
サブタスクをsubagentに渡す前に、粒度が適切か判定する。
適切な粒度（そのまま実行）:
- •単一の明確なゴールがある
- •対象ファイルが1-3個程度
- •単独で検証可能
大きすぎる（再分解が必要）:
- •対象ファイルが4個以上にまたがる
- •複数ゴールが混在（「〜して、さらに〜もする」）
- •完了条件が複数の独立した項目を含む
再分解の手順:
- •大きすぎるサブタスクを検出
- •単一ゴール・少数ファイルの単位に分割
- •分割したタスクをTaskCreateで登録
- •依存関係がなければ並列、あれば順次ステップに再配置
4. サブタスク記述
各サブタスクは以下のフォーマットで記述し、subagentが単独で実行できる情報量を持たせる。
code
**What**: 具体的なアクション（動詞で開始） **Where**: 対象ファイルパス、関数/クラス名 **How**: 実装アプローチ（既存パターンへの参照を含む） **Why**: 目的と全体タスクにおける位置づけ **Verify**: 検証手順（テストコマンド、期待出力、手動チェック方法）
subagentへのpromptにはこの情報をすべて含める。
5. ステップ実行
- •ステップ内の全サブタスクを並列実行（Task toolで並列起動）
- •現ステップの全サブタスクの完了を待つ
- •関連する結果を次のステップに渡す
- •各サブタスクには簡潔な要約（100-200語）を要求
6. ステップレビューと適応
- •各ステップ完了後、結果をレビュー
- •残りのステップがまだ適切か検証
- •発見に基づいて次のステップを調整
- •サブタスクの追加・削除・変更を行う
7. 段階的集約
- •完了ステップの結果を統合
- •統合結果を次ステップのコンテキストとして使用
- •段階的に包括的な理解を構築
コンテキスト効率化
- •各サブタスクに最小限のコンテキストを渡す
- •結果は100-200語の要約で受け取る
- •親コンテキストを圧迫しない
- •サブタスクには必要なファイルパスと具体的指示のみ渡す
使用例
例1: 「テスト・lint・コミット」
Step 1: 初期分析 (1 subtask)
- •プロジェクト構造を分析し、テスト・lintの設定を把握
Step 2: 品質チェック (並列サブタスク)
- •テスト実行と結果キャプチャ
- •lint・型チェック実行
- •git statusと変更内容確認
Step 3: 問題修正 (並列サブタスク, Step 2の結果を使用)
- •lintエラー修正 / 型エラー修正 / コミットメッセージ準備
- •レビュー: エラーなしならスキップ
Step 4: 最終検証・commit
例2: 「認証モジュールをリファクタリング」— 大きすぎるタスクの再分解
code
元: [認証モジュールのリファクタリング] ← 大きすぎる
↓ 再分解
├─ What: JWT検証ロジックをauth/token.tsに抽出
│ Where: src/auth/middleware.ts → src/auth/token.ts
│ How: 既存のverifyToken関数を分離、importを更新
│ Verify: npm test -- --grep "token"
│
├─ What: セッション管理をauth/session.tsに分離
│ Where: src/auth/middleware.ts → src/auth/session.ts
│ How: SessionManagerクラスを新規作成、既存のredisパターンに従う
│ Verify: npm test -- --grep "session"
│
└─ What: テストを新しいモジュール構造に更新 ← 上2つに依存
Where: src/auth/__tests__/*.test.ts
How: importパスを更新、テストケースをファイル別に分割
Verify: npm test -- --grep "auth"
適応計画
code
初期計画: Step 1 → Step 2 → Step 3 → Step 4 Step 2後: "エラーなし" → Step 3スキップ → Step 4簡略化（commitのみ） Step 2後: "重大な問題発見" → 新Step 2.5（調査）→ Step 3変更
実装上の注意
- •必ず最初にコードベースを探索してスコープ全体を把握する
- •関連する並列タスクは同じステップにグループ化
- •ステップ間には要約のみ渡す（全出力は渡さない）
- •TaskCreate/TaskUpdateでステップとサブタスクの進捗を可視化
- •各ステップ後に明示的に計画を再考:
- •次のステップはまだ妥当か？
- •新しいタスクが必要な発見はあったか？
- •今後のステップをスキップ・簡略化できるか？