全部Opusで回したら、1回で週の上限の6〜8割が消えた。Claude Codeの仕事を5つの席に分けて、モデルを固定した

AIに成果物を検証させる工程を、全部のラウンドでいちばん上のモデル（Opus）にしたことがあります。その回だけで、週の利用上限の6〜8割を使いました。

逆に、Webで調べる役をいちばん安いモデル（Haiku）に落として、その日のうちに戻したこともあります。

どの仕事に、どのモデルを使うか。私はいま、Claude Codeの仕事を5つの「席」に分けて、席ごとにモデルを固定しています。この記事はその経緯と、線の引き方です。

一度安くして、その日のうちに戻した

最初に分けたのは8月です。そのときは3つの席でした。

・判定する役（納品前に間違いを探す）: Opus
・調べる役（Webで事実を集める）: Sonnet
・全体を回す役（メインの会話）: Sonnet

このとき、調べる役を一度 Haiku に落としました。

その日のうちに Sonnet に戻しました。事故が起きたからではありません。起きたら取り返せない場所だと判断したからです。

私の副業の1つは、企業ごとの担当者や部署を調べて、出典付きのリストにして納品する仕事です。この仕事では、出典が正しいこと自体が納品物の品質です。ページの日付を読み違える、古い情報を新しいと判断する。こうした劣化は、後ろの検証で拾えばいい種類のものではありません。入口で間違えた事実は、検証役が「この出典にはこう書いてある」と確認しても、出典ごと間違っていれば素通りします。

このとき決めたのは1行です。

「品質に関わる所を、安いモデルに落とさない」

節約するなら、品質と関係のない所でやる。

全ラウンドをOpusにしたら、1回で週の上限の6〜8割

逆方向の失敗もしています。

納品物を検証する工程は、作った内容を別のAIに何周もチェックさせる仕組みにしています。この検証を、全部のラウンドで Opus にしたことがあります。

その回だけで、週の利用上限の6〜8割を使いました。

いまは、途中のラウンドは Sonnet、最後の総点検（と、そこで出た指摘の裁定）だけ Opus、という配分にしています。途中で見逃したものは最後の総点検が拾う設計なので、判定の最終ゲートは Opus のままです。作る役より上のモデルで最後に見る、という点は変えていません。

足りなかったのは、モデルの指定ではなく「渡す先」だった

3つの席で1か月回して、もう1つ問題が見えました。

判定役と調べ役には仕事を渡せます。でも、仕様が決まった実装や、大量のファイルを同じ形に整えるような単純作業を渡す先がありませんでした。結果として、全部をメインの会話が自分でやっていました。設計を考える役が、手も動かしていたわけです。

9月に、席を2つ足しました。

席        モデル        担当
統括      起動時に選ぶ  目的の解釈・設計・分解・最終判断・報告
実装      Sonnet        仕様が決まったタスクの実装と実行
機械作業  Haiku         判断を含まない反復作業（集計・整形・存在確認）
調査      Sonnet        Webの一次情報の収集（出典必須）
判定      Opus          納品前の反証検証

足した2つの席には、それぞれ「受けてはいけない仕事」を書いてあります。実装役は、仕様が足りなければ推測で埋めずに差し戻す。機械作業役は、良し悪しの判断を含む仕事が来たら差し戻す。安い席が、判断を黙って引き受けないようにするためです。

席を選べば、モデルは自動で決まる

モデル名は、席の定義ファイルに書いてあります。Claude Codeでは、サブエージェント（仕事を渡す先）を .claude/agents/ にMarkdownで定義でき、冒頭にモデルを書けます。たとえば機械作業の席はこうです。

---
name: bulk-worker
description: 判断を含まない機械的な反復作業を担う作業者。良し悪しの判定・出典の突合・文章作成は担当しない。
tools: Read, Write, Edit, Bash, Glob, Grep, WebFetch
model: haiku
---

こう書いておくと、渡すときに別のモデルを指定しない限り、その席に渡した仕事はそのモデルで動きます。description に「担当しない仕事」まで書いておくのがコツです。

こうしておくと、仕事を渡すときに考えるのは「どの席か」だけになります。「この仕事はどのモデルで」と毎回決める場面がなくなります。

メインの会話のモデルは、設定ファイルでは Sonnet のままにしています。無人で動いている定期実行も同じ設定を読むので、ここを Opus にすると、夜中の定期実行まで全部が Opus で動くからです。設計に頭が要る日は、起動するときに私が Opus を選びます。

渡す前に、1つだけ自問する

席を分けても、渡し方が雑だと品質は落ちます。私が渡す前に確認しているのは1つだけです。

「渡す先が、追加の質問をせずに最後までやりきれるところまで、仕様が決まっているか」

答えがNoなら、分解が足りていません。そのまま渡すと、渡された側は推測で埋めます。推測で埋めたものは、あとで作り直しになります。

逆に、渡さないと決めているものもあります。

・30行程度までの小さな修正（渡す手間のほうが大きい）
・良し悪しの判断を含むもの
・人に読ませる文章
・出典の正しさが品質そのものになる作業

最後の1つが、8月に戻した理由と同じです。

最後に

モデルの使い分けは、「賢いモデルは高いから節約する」という話に見えます。やってみると、節約の話より「どこで間違えると取り返しがつかないか」を決める話でした。取り返しがつかない所には Opus を置き、そこだけは節約しない。残りで節約する。

判定役がどう間違いを探しているか、何周回して、どこで止めるかは、別の記事に全部書きました。

→ AIの「確認しました」を信じたら、異動済みの人が混ざっていた。AIにAIを検証させる収束ループ
https://note.com/grand_loris1427/n/nc9b82ccfbf3f

Xでも、記事にするほどではない小さな失敗を書いています。
https://x.com/minato_shikumi