Orchestration

オーケストレーション: モデル委譲プロトコル

目的

メインモデルがすべての作業を直接行うとトークン消費が激しく、速度も出ない。 このスキルは「メインモデルは司令塔に徹し、実働は適切なモデルのサブエージェントに委譲する」ための判断基準と手順を定める。

ここでいう「司令塔」とは、この会話を担当しているメインモデル自身を指す。 特定のモデル名には依存しない。モデルのラインナップは変わるため、 「そのとき使える最上位クラスのモデルが司令塔、1〜2段下のモデルが実働」 という相対的な原則で運用する。

役割分担の原則

役割	担当	任せる作業の例
司令塔(メインモデル=自分)	最終責任者	要件の解釈、曖昧さの解消、タスク分解、アーキテクチャ判断、委譲結果のレビューと統合、ユーザーとの対話
上級エンジニア(Opus相当)	難しい実働	複雑なロジックの実装、難しいデバッグ、設計ドキュメントのドラフト、コードレビュー、リファクタリング設計
中堅エンジニア(Sonnet相当)	通常の実働	通常の機能実装、テストコード作成、CRUD・ボイラープレート、ドキュメント整形、コードベース調査、定型的なバグ修正
アシスタント(Haiku相当)	軽作業	ファイル探索、単純な置換・変換、ログやエラーメッセージの一次解析、リンク・参照の収集

委譲先はAgent toolの model パラメータで指定する。 メインモデルが最上位(例: Opus)の場合、「上級エンジニア」枠は同格モデルのサブエージェントでよい。 重い作業をサブエージェントに出すこと自体に、メインの会話コンテキストを汚さない価値がある。

判断に迷ったら 1段階下のモデルに任せて結果をレビューする 方が、最初から司令塔が手を動かすより安い。 レビューで品質不足が判明したときだけ上のモデルでやり直す。

委譲の判断フロー

1. タスクを分解する — 着手前に「設計判断が必要な部分」と「手順が明確な部分」に分ける
2. 設計判断は司令塔が行う — 何をどう作るかを決め、明確な指示書に落とす
3. 手順が明確な部分は委譲する — Agent tool に model パラメータを付けて起動する
4. 独立した作業は並列に投げる — 依存関係のないサブタスクは1つのメッセージで複数Agentを同時起動する
5. 結果は必ず司令塔がレビューする — 受け入れ基準に照らして確認し、不足があれば差し戻すか自分で修正する

委譲プロンプトの書き方

サブエージェントは会話のコンテキストを持たない。委譲プロンプトには必ず以下を含める:

• 背景: 何のプロジェクトで、いま何をしているか(2〜3文)
• 対象: 読むべきファイルの絶対パス、従うべき規約(CLAUDE.md、既存コードのパターン)
• 作業内容: 具体的な手順。判断の余地を残さない
• 成果物: 何をどこに書くか、返答に何を含めるか
• 受け入れ基準: 完了とみなす条件(テストが通る、lintが通る、等)

悪い例: 「ログイン機能を実装して」 良い例: 「src/auth/ 配下に JWT ベースのログインを実装。既存の src/users/users.service.ts のパターンに従い、エンドポイントは POST /auth/login。完了条件: npm test -- auth が通ること。変更したファイル一覧と判断に迷った点を報告すること」

並列化のパターン

• 調査のファンアウト: 「この機能に関係するコードを探す」→ 観点別(API層/データ層/テスト)にSonnet/Haikuを並列起動
• 実装の分割: 互いに触らないファイル群に分けて並列実装。同じファイルを触る作業は直列にするか、worktree分離を使う
• レビューの多視点化: 大きな変更は「正しさ」「セキュリティ」「性能」の観点で別々のエージェントにレビューさせる

司令塔が直接やるべきこと(委譲禁止)

• ユーザーへの質問・報告・確認
• 要件の解釈と優先順位付け
• 複数エージェントの成果物の統合と整合性チェック
• 破壊的操作(削除、force push、本番影響のある操作)の判断
• 委譲結果の最終レビュー

アンチパターン

• 丸投げ: 設計判断ごと下位モデルに委譲する。判断がぶれて手戻りが増える
• 過剰分割: 5分で終わる作業を3エージェントに分ける。起動コストの方が高い
• レビュー省略: 委譲結果を読まずに統合する。不整合が後工程で爆発する
• コンテキスト不足の委譲: 規約や既存パターンを伝えず、リポジトリと噛み合わないコードが返ってくる
• 同一ファイルへの並列書き込み: コンフリクトする。直列化かworktree分離を使う
• 特定モデル名への依存: スキルや手順書に固有のモデル名を焼き込む。役割(司令塔/上級/中堅/軽作業)で書き、モデル名は実行時に解決する

関連スキル

各開発フェーズのスキル([[requirements-definition]]、[[implementation]]、[[testing]] など)には それぞれ「モデル委譲ガイド」セクションがあり、そのフェーズ固有の分担を定めている。本スキルは共通原則。