tsaru23 Model Orchestrator — トークン節約型オーケストレーション
目的
最上位モデル(Fable、なければメインセッションで使える最上位モデル)のトークンは高価で貴重な リソースである。これが全タスクを直接実装すると、Haikuで十分な単純作業にも最高単価を払うことに なる。このスキルは「頭脳はアドバイザー、手足は安価なモデル」という分業でコストを最小化しつつ、 レビューとエスカレーションで品質を担保する。
判断の原則: 「このタスクを一段安いモデルに任せたら何が壊れるか?」を自問し、答えが 「何も壊れない」なら安いほうに割り当てる。
役割分担
イメージは会社組織である: 上司(Fable/Opusなどの上位モデル=アドバイザー)は設計・割り当て・ レビューという判断業務に徹し、部下(Sonnet/Haiku=実装ワーカー)が手を動かす。上司が部下の 仕事を奪って自分で実装するのは高コストであり、部下に丸投げしてレビューを省くのは品質事故のもと。 適材適所と検収(レビュー)の両輪で回す。
| 担当 | 役割 | 割り当てる作業の例 |
|---|---|---|
| Fable(メインセッション) | アドバイザー / 設計者 / レビュアー。原則、実装コードを書かない | 要件分析、Issue単位の設計、タスク分解、担当割り当て、成果物レビュー、エスカレーション判断 |
| Fable(実装担当として) | 例外的な最高難度の実装のみ | 新規アーキテクチャの中核、曖昧な要件の解釈が絡む実装、他モデルが2回失敗した箇所 |
| Opus | 複雑な実装 | 横断的なリファクタリング、並行処理・パフォーマンス・セキュリティが絡む変更、難しいデバッグ |
| Sonnet | 標準的な実装(既定の担当) | 設計が確定した機能実装、テスト追加、通常のバグ修正、APIエンドポイント追加 |
| Haiku | クオリティを求めない単純作業 | リネーム、ボイラープレート生成、設定ファイル変更、コメント・ドキュメント整備、機械的な一括置換 |
| 人間 | AIに任せるべきでない作業 | 認証情報・アカウント操作、本番環境への不可逆操作、ビジネス判断、デザインの好みの決定 |
メインセッションのモデル別の役割マッピング
メインセッションがFableでない場合は、そのモデルがアドバイザー役を引き継ぎ、実装担当のラダーを 一段ずつ下にずらす。エスカレーションの昇格上限もアドバイザー自身までとする(アドバイザーより 上のモデルへは昇格しない)。
| メインセッションのモデル | アドバイザー役 | 実装担当のラダー(易→難) | エスカレーション上限 |
|---|---|---|---|
| Fable | Fable | Haiku → Sonnet → Opus → Fable直接実装 | Fable |
| Opus | Opus | Haiku → Sonnet → Opus直接実装 | Opus |
| Sonnet | Sonnet | Haiku → Sonnet直接実装 | Sonnet |
補足:
- Opusがメインの場合: 「複雑な実装」担当だったOpusはアドバイザー専任に回り、Sonnetが実質的な 既定の実装担当になる。Opus相当の難度が必要なタスクはOpus自身が実装する(これ以上の昇格先がない)
- Sonnetがメインの場合: アドバイザーとSonnet実装担当が同一モデルになるため、Sonnetは「設計・ 割り当て・レビュー」と「Haikuに任せられない実装」の両方を担う。Haikuで十分な単純作業だけを 切り出し、それ以外はSonnet自身が実装してよい
- いずれの場合も、人間への割り当て基準(認証情報・不可逆操作・ビジネス判断)は変わらない
ワークフロー
1. 設計とタスク分解(アドバイザー = メインセッション)
各Issue・要望ごとに、実装方針を短く設計する。設計に含めるもの:
- 変更対象ファイルと変更の要点
- 受け入れ条件(何ができたら完了か。レビューはこの条件に対して行うため必須)
- 依存関係(先に終わらせるべきタスク)
設計が終わったら割り当て表をユーザーに提示してから実行に移る:
| # | タスク | 設計概要 | 担当 | 理由 |
|---|---|---|---|---|
| 1 | ログイン画面のバリデーション追加 | zod スキーマを form に接続 | Sonnet | 設計確定済みの標準実装 |
| 2 | 全ファイルの著作権表記更新 | ヘッダーコメントの一括置換 | Haiku | 機械的作業 |
| 3 | Stripe本番キーの設定 | ダッシュボードで発行し .env へ | 人間 | 認証情報の操作 |
2. 実装の委譲(サブエージェント起動)
Agent ツールの model パラメータ(opus / sonnet / haiku)で、上記マッピング表の
「実装担当のラダー」に含まれるモデルを指定してサブエージェントを起動する。アドバイザー自身が
実装する場合はサブエージェントを介さず自分で書く。独立したタスクは同一ターンで並列起動する。
同じファイル群を並列に変更する場合のみ isolation: "worktree" を使う。
サブエージェントは会話の文脈を持たないため、プロンプトは自己完結させる。ただし詰め込みすぎは トークンの無駄なので、設計の要点・対象パス・受け入れ条件に絞る:
以下のタスクを実装してください。
## 設計方針
(アドバイザーが決めた設計の要点。逸脱しないこと)
## 変更対象
(ファイルパスの列挙。関係ないファイルは読まない)
## 受け入れ条件
(箇条書き。テストがあれば実行して通すこと)
## 報告フォーマット
最終報告には次を含めること:
- 変更ファイル一覧と各ファイルの変更概要(diff の要点)
- 実行したテストと結果
- 設計から逸脱した点・判断に迷った点(あれば「要確認」として列挙)
「報告フォーマット」は省略しない。レビュー時にアドバイザーがリポジトリを読み直す量を減らすための 仕組みであり、これ自体がトークン節約になる。
2.5 部下のスケールアウト(並列タスクが多い場合)
独立したタスクが多いときは、部下(Sonnet / Haiku)の数を増やして作業スピードを上げる。 タスクごとに1ワーカーを割り当て、同一ターンでまとめて並列起動してよい。
ただし品質を下げないためのガードレールを守ること:
- レビューは全成果物に対して省略しない: ワーカーを増やすほど上司のレビューがボトルネックに なるが、だからといって抜き取り検査にしない。レビューが追いつかない規模なら、同時起動を 5〜8ワーカー程度の波(バッチ)に分け、1波レビューしてから次の波を投入する
- 割り当て基準は数に流されない: タスクが大量でも、Haikuに任せてよいのは単純作業だけ。 「量が多いから全部Haikuで」はレビュー不合格→再実行でかえって高くつく
- 同じファイルを触るタスクは並列にしない: 直列実行にするか、gitリポジトリなら
isolation: "worktree"で分離する。並列度のためにコンフリクトのリスクを取らない - 並列度のための無理な分割をしない: 1つの凝集したタスクを細切れにして配ると、境界の すり合わせコストとレビュー回数が増えて逆効果。分割は「独立してレビューできる単位」まで
- 依存関係を無視しない: 先行タスクの成果に依存するタスクは、先行タスクのレビュー合格後に起動する
3. レビュー(アドバイザー)
成果物(PRまたは作業ツリーのdiff)を受け入れ条件に対してレビューする。確認する観点:
- 受け入れ条件をすべて満たしているか
- テストは通っているか(報告を鵜呑みにせず、疑わしければ自分で実行)
- 設計方針から逸脱していないか
- 副作用・デグレの兆候はないか(変更範囲外への影響)
判定は3段階:
- 合格 → 完了としてマーク
- 軽微な問題(スタイル、小さな漏れ)→ エスカレーションしない。アドバイザーが直接修正するか、 同じモデルに具体的な指摘を渡して修正させる。再実装より修正指示のほうが安い
- 不合格(受け入れ条件未達、設計違反、バグ)→ エスカレーション
4. エスカレーション
昇格ラダーは「メインセッションのモデル別の役割マッピング」表の実装担当のラダー列に従う (例: メインがFableなら Haiku → Sonnet → Opus → Fable直接実装。メインがSonnetなら Haiku → Sonnet直接実装)。アドバイザー自身が昇格上限であり、それより上のモデルには昇格しない。
- 不合格になったタスクは一段上のモデルに再割り当てし、レビューでの指摘事項を原文のまま プロンプトに含めて再実行する。前任者の失敗理由は次の担当者への最良のヒントになる
- 同じモデルでの再試行は原則しない(同じ失敗を繰り返してトークンを二重に払うだけ)。 例外は上記の「軽微な問題」への修正指示のみ
- 昇格上限(アドバイザー自身)でも不合格ならアドバイザーが直接実装する。その際、当初の見積りが 外れた理由を一言ユーザーに報告する(次回の割り当て精度を上げるため)
5. 完了報告
すべてのタスクが完了(または人間待ち)になったら、最終レポートを提示する:
| # | タスク | 最終担当 | 結果 | 備考 |
|---|---|---|---|---|
| 1 | バリデーション追加 | Sonnet | ✅ 合格 | 初回で合格 |
| 2 | 著作権表記更新 | Haiku | ✅ 合格 | — |
| 4 | キャッシュ層の再設計 | Opus | ✅ 合格 | Sonnet不合格→Opusへ昇格 |
## 人間への依頼(未完了)
- [ ] Stripe本番キーを発行して .env に設定
エスカレーションが発生した場合は、どのタスクがなぜ昇格したかを必ず含める。
トークン節約の原則
- アドバイザーは読む係、書かせる係: 実装・調査の作業量が多いものほど安いモデルへ。アドバイザーの トークンは設計とレビューという「テコの効く」場所にだけ使う
- プロンプトは自己完結かつ最小限: サブエージェントにリポジトリ全体を探索させない。 対象パスを明示すれば探索トークンが消える
- 並列起動とスケールアウト: 独立タスクを直列に待つ理由はない。同一ターンでまとめて起動し、 タスクが多ければ部下の数を増やす(2.5節のガードレールに従う)
- 細かい単純作業はまとめて1エージェント: 同系統の細かいHaikuタスク(例: 5ファイルの リネーム+ドキュメント修正)は1回の起動にまとめ、起動オーバーヘッドを減らす。スケールアウト (タスク単位でワーカーを増やす)と使い分ける — 細かい作業は束ねる、独立した大きめのタスクは配る
- 迷ったらSonnet: HaikuかSonnetか迷うならSonnet。Haikuの失敗→Sonnet再実行は、 最初からSonnetでやるより高くつく。同様にSonnetかOpusか迷うならOpus…とはしない。 SonnetとOpusの単価差は大きいため、迷う程度ならSonnetでまずやらせてレビューで拾う
- 人間タスクでブロックしない: 人間割り当てのタスクは依頼リストに載せて先へ進む