Claude Fable 5 を Claude Code のデフォルトモデルにして1日使ってみて、最初に学んだのは「強い」より先に「全部こいつに任せると使用枠が一瞬で溶ける」だった。出力 $50/1M tok、しかもサブスクの枠の減りも速い。普段の感覚でファイル全文を読ませたり、ログをまるごと貼って要約させたりしていると、あっという間に上限の警告が出る。
でも Fable 5 の本当の価値は、設計やタスク分解、レビューといった「頭を使う上流」にある。だったら、上流だけ Fable 5 にやらせて、ファイルを読む・コードを書くといった「手を動かす下流」は安いモデルに回せばいい。要するに、人間のチームと同じで「シニアが設計してレビューし、実装は手分けする」構成を Claude Code の中で組む。
この記事は、その使い分けを CLAUDE.md でどう設計したかの実例。自分の運用をそのまま晒す。
考え方：Fableは「管理者」、実装は委譲する
役割を最初にはっきり分けた。
- Fable 5 = 責任者 / 管理者。 設計、タスク分解、サブエージェントへの委譲、上がってきた成果物の監査、そしてユーザーへの最終報告。ここだけは Fable 自身がやる。
- 探索・調査・要約 = Sonnet のサブエージェント。 ファイル捜索、コードベースの調査、ログの読み込み、長い出力の要約。読み取り専用。
- 実装・テスト・リファクタ・バグ修正 = Sonnet のサブエージェント。 ただし特に難しい箇所だけ Opus を指定。本当に最高難度のところだけ Fable 自身が直接書く。
ポイントは、メインセッション（Fable）でデカいファイルの全文 Read や長いログの読み込みをやらないこと。それをやると一番単価の高いモデルのコンテキストを安い作業で食い潰す。読むのは安いサブエージェントにやらせて、Fable は要約だけ受け取る。
CLAUDE.mdに書いた実際のルール
抜粋するとこんな感じ。~/.claude/CLAUDE.md に置いて全プロジェクトで効かせている。
## model使用の原則(レート制限の温存)
メインセッション(Fable 5)は制限が最もきつい。Fableは責任者であり管理者：
設計・タスク分解・委譲した作業の監視・成果物の監査を行い、
ユーザーへの最終出力には必ずFable自身が責任を持つ。
トークンを食う実作業はサブエージェントへ委譲する。
- サブエージェント起動時は必ず model を明示する。
未指定はメインのモデル(Fable)を継承し、制限を浪費する。
- 探索・ファイル捜索・ログ調査・要約 → scout エージェント(Sonnet・読み取り専用)
- 実装・テスト作成・リファクタ・バグ修正 → implementer エージェント(Sonnet)。
特に難しい箇所は model: opus を指定。最高難度の箇所のみメイン(Fable)が直接実装。
- メインで大きなファイルの全文Readや長いログの読み込みをしない。
サブエージェントに読ませて要約を受け取る。
scout（読み取り専用・Sonnet）と implementer（実装・Sonnet、難所だけ Opus）の2つのサブエージェントを用意して、Fable はそこへ仕事を振る監督に徹する、という形。
いちばん効いたのは「model を必ず明示する」の一行。これを書く前は、サブエージェントを起動しても親（Fable）のモデルを継承してしまって、「安いモデルに回したつもりが全部 Fable で実行されていた」ということが起きていた。明示しないと節約にならない。ここは本当に注意。
「委譲したら終わり」にしないための歯止め
このやり方の落とし穴は、サブエージェントの出力を確認せずにそのまま報告してしまうこと。安いモデルに投げたぶん品質はブレるので、Fable が監査をサボると事故る。
なので、CLAUDE.md にもう一段ルールを足した。
### 委譲しても責任はFableにある
- サブエージェントに任せた作業も「Fable自身がやった作業」として扱う。
委譲は責任の移譲ではない。
- サブエージェントの出力を未確認のままユーザーへ報告したり、
成果物として確定させることを禁止する。
必ずFable自身が要点(差分・テスト結果・主張の根拠)を実際に見て検証・監査する。
- 検証で問題が見つかったら、差し戻して修正させるか、Fableが自ら直す。
「サブエージェントがそう言ったから」を報告の根拠にしない、という縛り。Fable は安いから雑、ではなく、安い実装役を使うぶん、監督役の Fable がちゃんと差分とテスト結果を見て責任を取る。この分業が崩れると、コストは下がっても品質が落ちるので意味がない。
長時間タスクで地味に効いたのが、「報告前に各主張をツール結果と突き合わせよ」という一文をプロンプトに入れること。これがないと、長く走らせたエージェントが「テストは通りました」みたいな実際には確認していない進捗を報告してくることがある。一文足すだけでこれがほぼ消えるのは、Anthropic 側も検証していて、実感としても効いた。
自己批評より「別コンテキストの検証役」
もうひとつ、Fable 5 みたいな強いモデルでも、自分で書いたものを自分で「OKです」と言わせるのはあまり当てにならない。同じコンテキストにいると、自分の判断を追認しがちになる。
効くのは、まっさらなコンテキストの検証サブエージェントに「これ本当に正しい?」とレビューさせること。実装役とは別のエージェントに、前提を持たせずチェックさせる。人間のコードレビューと同じで、書いた本人じゃない目を入れる。長く生きるサブエージェントはキャッシュも効くので、コスト面でも悪くない。
/goal と長時間自律を噛ませる
Fable 5 は長時間ほったらかしても破綻しにくいので、Claude Code の /goal（完成条件を先に宣言しておくとそこに到達するまで作業を続ける）と相性がいい。
コツは公式も言っているとおりで、最初の1ターンでタスクの仕様を全部書くこと。ふわっとした指示を何ターンにも分けて小出しにするより、ゴール・意図・制約を最初にまとめて渡したほうが、Fable 5 は自律して質も上がるし、無駄なトークンも減る。「あとで細かく指示すればいいや」が一番効率を落とす。
なので運用としては、
- Fable がタスクを受けて、ゴールと完成条件を整理（
/goal） - 作業を分解して、調査は
scout、実装はimplementerに委譲 - 上がってきたものを Fable が検証サブエージェントも使って監査
- 問題があれば差し戻し、最終的な報告だけ Fable が自分の言葉で出す
という流れに落ち着いた。Fable は「考えて・配って・チェックする」だけ。実際に大量のトークンを焼くファイル読みやコード書きは、安いモデルが裏でやっている。
落とし穴メモ
実際にやってみて踏んだ・聞いた地雷をいくつか。
-
modelを明示しないとサブエージェントが親(Fable)を継承する。 節約の前提が崩れる。最重要。 -
fallbacks（拒否時に Opus 4.8 へ自動退避するやつ）は、ツール実行の中のモデル呼び出しには伝播しない。 サブエージェント側で拒否が起きうるなら、そっちにも個別に設定がいる。 -
Batch API では
fallbacksが効かない。 バッチ内の拒否は「成功レスポンス＋stop_reason: refusal」で返ってくるので、拒否ぶんを自分で抜き出して別モデルに投げ直す必要がある。 - メインで長いログを読まない、を徹底する。 ついやりがちで、ここが一番枠を溶かす。Fable に渡すのは要約だけ。
- 「最強だから全部 Fable」はアンチパターン。 何度も書くけど、品質が変わらない作業に最上位単価を払うことになる。
まとめ
Fable 5 を活かす一番のコツは、Fable 5 にやらせる量を減らすことだと思っている。逆説的だけど、強いモデルを「管理者」に格上げして、手を動かす仕事を安いモデルに委譲すると、品質はだいたい保ったままコストがかなり下がる。
CLAUDE.md に「誰が何をやるか」と「委譲しても責任は監督役にある」を明文化しておくだけで、Claude Code が勝手にこの分業で動いてくれる。Fable 5 の値段にビビって使わないのも、ビビらず全部任せて枠を溶かすのも、どっちももったいない。監督に据えるのがちょうどいい落としどころだった。