# Model Orchestrator

> トークン消費を節約するためのモデルオーケストレーション。複数のIssue・タスク・機能をまとめて 実装する依頼、「タスクを振り分けて」「安いモデルで済ませて」「オーケストレーションして」 「Issueを消化して」「コスパよく実装して」といった依頼では必ずこのスキルを使うこと。 最上位モデル(Fable)はアドバイザーとして設計・担当割り当て・レビューに専念し、実装は 難易度に応じて Opus / Sonnet / Haiku / 人間 に割り当てる。品質不足の成果物は担当を 上位モデルに切り替えて再実行する。単発の小さな修正1件だけの依頼には使わない。

- Skill: `tsaru23/model-orchestrator` (Agent Skill)
- Install (CLI): `npx skillmds@latest add tsaru23/model-orchestrator`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tsaru23/model-orchestrator/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: tsaru23 (https://skillmd.com/u/tsaru23)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/tsaru23/model-orchestrator

---


# 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・要望ごとに、実装方針を短く設計する。設計に含めるもの:

- 変更対象ファイルと変更の要点
- 受け入れ条件(何ができたら完了か。レビューはこの条件に対して行うため必須)
- 依存関係(先に終わらせるべきタスク)

設計が終わったら**割り当て表**をユーザーに提示してから実行に移る:

```markdown
| # | タスク | 設計概要 | 担当 | 理由 |
|---|---|---|---|---|
| 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)を受け入れ条件に対してレビューする。確認する観点:

1. 受け入れ条件をすべて満たしているか
2. テストは通っているか(報告を鵜呑みにせず、疑わしければ自分で実行)
3. 設計方針から逸脱していないか
4. 副作用・デグレの兆候はないか(変更範囲外への影響)

判定は3段階:

- **合格** → 完了としてマーク
- **軽微な問題**(スタイル、小さな漏れ)→ エスカレーションしない。アドバイザーが直接修正するか、
  同じモデルに具体的な指摘を渡して修正させる。再実装より修正指示のほうが安い
- **不合格**(受け入れ条件未達、設計違反、バグ)→ エスカレーション

### 4. エスカレーション

昇格ラダーは「メインセッションのモデル別の役割マッピング」表の**実装担当のラダー**列に従う
(例: メインがFableなら Haiku → Sonnet → Opus → Fable直接実装。メインがSonnetなら
Haiku → Sonnet直接実装)。アドバイザー自身が昇格上限であり、それより上のモデルには昇格しない。

- 不合格になったタスクは一段上のモデルに再割り当てし、**レビューでの指摘事項を原文のまま**
  プロンプトに含めて再実行する。前任者の失敗理由は次の担当者への最良のヒントになる
- 同じモデルでの再試行は原則しない(同じ失敗を繰り返してトークンを二重に払うだけ)。
  例外は上記の「軽微な問題」への修正指示のみ
- 昇格上限(アドバイザー自身)でも不合格ならアドバイザーが直接実装する。その際、当初の見積りが
  外れた理由を一言ユーザーに報告する(次回の割り当て精度を上げるため)

### 5. 完了報告

すべてのタスクが完了(または人間待ち)になったら、最終レポートを提示する:

```markdown
| # | タスク | 最終担当 | 結果 | 備考 |
|---|---|---|---|---|
| 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でまずやらせてレビューで拾う
- **人間タスクでブロックしない**: 人間割り当てのタスクは依頼リストに載せて先へ進む