いろんなモデルを賢く動かす運用術
― 作らせる係と回す係を分ける

# モデル運用方針（このプロジェクト共通）

クレジット消費を抑えつつ品質を確保するため、タスクの性質でモデルとエフォートを使い分ける。

## 既定モデル
- 既定は **Opus 4.8**。判断が必要な通常タスクはこれ。

## 軽量・定型タスク → Sonnet 5
- 明確に軽量・定型（単純置換・CRUD・軽微修正・すぐ欲しい回答）は **Sonnet 5** で消費を抑える。

## 重いタスク → Fable 5（＝"作る係"）
- 以下の「重いタスク」のときだけ Fable 5 を使う：
  - アーキテクチャ設計・大規模な設計判断
  - コードベース全体の監査／大規模移行
  - 複雑なバグの根本原因調査
  - 長時間の自走を要する作業
- ★特に **ハーネス（検証・実行の仕組み）の全体設計・情報収集・エージェントのオーケストレーション・初期構築**は Fable 5 が強い。まず"仕組みを作る"ところを任せる。

## 重い実装ループ（＝"回す係"）→ Codex GPT-5.6 Sol（reasoning effort: ultra）
- できた仕組みの上で回す**重い実装ループ**は、Opus 4.8 でも回るが、**個人的には Codex GPT-5.6 Sol × reasoning effort「ultra」が好相性**。
- Codex側の設定（~/.codex/config.toml）：
  model = "gpt-5.6-sol"
  model_reasoning_effort = "ultra"
- 独立した定型〜中量タスクは Codex（サブスク枠）へ委譲してよい。委譲時は自己完結プロンプトに整形し、結果は必ず自分（メインのAI）側で検収する。

## エフォート（reasoning effort）の使い分け
- **エフォート＝どれだけ考えさせるか**（low / medium / high / xhigh / max）。
- 簡単・定型は **低め**、設計・難所は **高め**。上げっぱなしは消費のムダ、下げすぎは品質不足。

## 使い分けの原則
- **モデル＝誰に頼むか × エフォート＝どれだけ考えさせるか** の掛け算で、「品質を保ちつつ一番安い組み合わせ」を選ぶ。
- **作らせる係（設計・仕組み）＝強いモデル／回す係（繰り返し）＝安いモデル** に分ける。

## ★設計→作業の2段ワークフロー（毎回自動で回す3ステップ）
重いプロジェクト（新機能・大規模改修・自動化の構築）は、次の3ステップを既定とする。

1. **設計係＝Fable 5**：まず**ハーネスだけ**を作らせる
   （全体設計／情報収集／エージェントのオーケストレーション設計／検証ループの初期構築）。
   仕組みが動いたら Fable 5 は降ろす（重いループを回し続けさせない）。
   ※Claude Codeなら「モデルに claude-fable-5 を指定したサブエージェント」を作っておくと、
   メインセッションのモデルを変えずに設計だけFable 5へ渡せる。
2. **作業係＝Codex GPT-5.6 Sol×ultra**：できたハーネスの上で回す**重い実装ループ**は
   Codex CLI（codex exec）へ委譲する。委譲プロンプトは**自己完結**
   （目的・制約・**検証コマンド**・完了条件を必ず含める）。
3. **検収＝メインのAI（Claude）側**：ハーネスのverify系コマンドで受け入れ確認してから取り込む。

- 入口の判断：対象のハーネスが**未整備なら1から、整備済みなら2から**入る。
- 根拠：オーケストレーター＋ワーカーの役割分担は公式実測でも有効
  （リード＋ワーカー構成が単体比+90.2%・ただしトークン増＝だから実行係を安く）。

## 委譲時の注意（落とし穴）
- 環境変数（APIキー）が効いていると、サブスク枠のつもりが**別課金に化ける**ことがある → 委譲前に環境を確認する。
- 設計・難所まで安いモデルに寄せない（役割分担を守る）。