Fable 5をトークン破産させずに使い倒す — オーケストレーターに徹させる運用

はじめに

Claude Fable 5、今までのモデルと比べても頭ひとつ飛び出るぐらい賢いですよね。
以前出た時にすぐメインモデルに設定して、実装からデバッグから雑務まで全部やらせた結果、トークンが凄い勢いで食われていくので対策しました。

Fable 5 の賢さは活かしつつトークンは食わせないようにオーケストレーターに徹させる運用に切り替えた結果、Fable の消費がはっきり減り、しかも長時間セッションでの判断のブレが減りました。その構成と、それを1コマンドで組む方法を共有します。

なぜオーケストレーション設定が必要なのか

Claude Codeはもちろんオーケストレーション設定なしでも動きます。ただオーケストレーション設定なしでメインモデルにFable 5を設定するとかなり勿体無いです。

例えば、以下のようなタスクを送ったとします。

APIにレート制限を追加してください。

このタスク自体はシンプルですが、Claude Code側から見ると、実際は重さの違う作業にほどけていきます。

• アルゴリズムを決める
• カウンタをどこに置くか — インメモリか、複数インスタンスで動かすかなど
• バースト時に何が起きるか、クライアントが 429 で何を受け取るか
• ミドルウェアを書く
• 全ルートに結線する
• テストを書く
• lint と型エラーを直す
• エッジケースを潰す — リミッター自体の障害、期限切れしないキーなど

最初の設計部分は間違えてはいけないコアの部分なのでFable 5に任せるのはまだ良いとして、設計さえ決まってしまえば後はより安価なモデルに任せても十分うまくいきます。

そのため、Fable 5を設計のみに徹底させるということが重要なのです。

賢いモデルは「考える」ことだけに使う

今の私の役割分担はこうです。

• Fable 5（reasoning effort: max）= オーケストレーター：計画・分解・統合だけ。コードは書かない
• Opus = 深い推論用サブエージェント：設計判断、複雑なデバッグ、レビュー
• Sonnet = 機械的作業用サブエージェント：実装、ボイラープレート、テスト、雑務
• Codex = 別視点のシニアエンジニア：高リスクな判断のセカンドオピニオン

Fable 5 には「考えて、割り振って、まとめる」ことだけをやらせます。コードを書いてテストしたりといった泥臭い作業を安いモデルに一任することで、一番トークンを食う Fable の出番が計画と統合だけに絞られます。さらに、オーケストレーターのコンテキストが実装の詳細で汚れないので、判断の質が最後まで落ちません。
usage が減ったのは想定どおりでしたが、コンテキストが綺麗なままだとAIの判断がブレないこともかなり嬉しかったです。

サブエージェントの設計

サブエージェント軍団のセットアップの自体は簡単です。

1. /model で Fable 5 をメインモデルに
2. /agents でサブエージェントを作り、それぞれ Opus / Sonnet を振り当てる
3. CLAUDE.md に「どの仕事を誰に投げるか」のルールを書く

手順自体は単純なんですが、ちゃんと働くサブエージェントを作るのは別の話でした。

• description の質が委譲の精度を決める。 オーケストレーターはサブエージェントの description を見て「この仕事は誰に投げるか」を判断します。「推論が重いタスク用」くらいの粒度だと、境界ケースで委譲先がブレて、出力を見るまで気づけません。
• プロンプトが出力の質を決める。 サブエージェントはメインのコンテキストとは別に独自のコンテキストを持ちます。そのため、「何を読んでから作業するか」「何を返すか（結論だけか、diffかなど）」を書き込んでおかないと、毎回オーケストレーターが尻拭いをして、結局そこで手戻りが発生し、大量のコンテキストを使う羽目になります。
• 「考える人」と「手を動かす人」の2体では粗すぎる。 出発点としては良いのですが、実務では「スコープを切る」「設計を決める」「実装する」「検証する」「出荷する」は別の仕事です。QA を builder と同じエージェントにやらせると、自分の書いたコードに自分で LGTM を出す構図になります。

つまり、この構成で本当に考えないといけないのは、モデルの割り当てではなくチーム設計です。そしてチーム設計をゼロから書くのは、正直けっこう大変だと感じました。
何チームか用意していても、リポジトリごとに必要なチームは異なります。

そこで ccteams：チーム設計を1コマンドでインストールする

手前味噌ですが、私はまさにこの問題のために ccteams という CLI を作りました。
Claude Code のエージェントチームのパッケージマネージャーです。

このCLIに関しては詳しくは以下の記事に書いています。

https://zenn.dev/yui/articles/4f54a98ad94fe5

npm install -g ccteams
ccteams list          # チーム一覧
ccteams use generalist # チームをプロジェクトに適用

これだけで、役割分担済みのサブエージェント一式（description・システムプロンプト・ツール制限まで書き込み済み）と、オーケストレーションルールが .claude/ に入ります。上の Step 3（CLAUDE.md にルーティングルールを書く）に相当するものは、チームにすでに入っているので書かなくていい、ということです。

スタック別のチームが最初から入っています。

プラグインもあります。

/plugin marketplace add toffyui/ccteams
/plugin install ccteams@ccteams

例えば、/ccteams:choose-team バックエンドのAPI開発 のように自然言語で頼むと、合うチームを選んで適用してくれます。

モデルはすでに割り当て済みです（v0.1.5以降）

チームが入ったら、残っている作業はモデルを設定するだけなのですが、ccteamsではなんとすでに入っています。（v0.1.5で入れました。）

モデルの変更は、.claude/agents/ に入ったエージェントのmodelの行から変更できます。

---
name: architect
description: Technical design specialist. ...
tools: Read, Glob, Grep, WebSearch, WebFetch
model: opus        # ← ここを必要に応じて別のモデルに変えてください。
---

ccteamsにあらかじめ入っているgeneralist チームは以下のようになっています。

「深く考える役」「手を動かす役」という考え方は同じですが、役割を細かく分けることで委譲の精度が上がります。上記のように分かれていれば、どの仕事をどのモデルに投げるかも役割に紐づくので、オーケストレーターが毎回迷わなくなります。

ここでミソなのは、architectやqa-reviewerをFable 5にしないことです。

一見すると、重要な設計やレビューにも一番良いモデルを使いたくなります。でも実際には、サブエージェントにタスクが渡る前に、Fable 5 はすでに一番難しい仕事を終えています。あいまいな依頼を、他のモデルが解けるくらい明確で境界のある問いに変換しているからです。

Fable 5が本当に効くのは、長くてあいまいで、トレードオフだらけのタスクです。問いが十分に整理された後なら、設計案やレビュー案を出すところは Opusでかなり足ります。しかも、最終的にその案を採用するかどうかは Fable 5が判断します。

つまり、Fable 5 はコアな判断を握ったまま、途中のすべての役割にまで高いトークンを使わずに済みます。そのためのオーケストレーションルールやエージェントのプロンプトは必要ですが、そこはccteamsが最初から用意しています。

ccteams経由でチームを設定した場合は、Claude Code を再起動（/exit → 起動）すれば反映されます。

Codex も作業者として入れたい場合

OpenAI の公式 Codex プラグインを入れると、Claude Code の中から Codex を呼べます（Codex CLI を先にインストールしておく必要があります）。

/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/reload-plugins
/codex:setup

そのうえで、プロジェクトの CLAUDE.md（ccteams が作る @.claude/active-team.md の import の下）に以下を足します。

## Peer engineer
Codex (/codex:rescue --background) is a peer senior engineer with a different
perspective. For high-stakes decisions, task the architect agent and Codex on
the same problem in parallel and synthesize — without showing either the
other's answer.

ポイントは Codex を「レビュアー」ではなく対等な相棒として扱い、高リスクな判断では Opus 系のエージェントと Codex に同じ問題を独立に解かせてから統合すること。お互いの答えを見せないのがコツです。モデルの系統が違うほど盲点の重なりが小さくなるので、設計判断の抜け漏れ潰しには特に効きます。

指示を出す時は簡潔に

エージェントチーム適用後は、例えばこう頼みます。

APIにレート制限を追加してください。
Express + Redis、ロードバランサーの背後に3つのインスタンスとしてデプロイされています。

ゴールを述べるだけです。あとは Claude Code が勝手に回します。タスクを各エージェントの description と照合して自動で委譲するので、Fable 5 は上記の曖昧なタスクを分解し、サブエージェントがわかりやすいように棚卸した上でタスクを譲渡します。

こうすることで、Fable 5 は計画と統合だけに集中し、コンテキストはきれいなまま。実作業のトークンは Opus / Sonnet が消費するので、Fable の usage も温存できます。

まとめ

• Fable 5 はトークンを食う。実作業をさせると usage が溶けるので、考えることだけに使うのがコスパ最強
• モデル割り当てよりサブエージェントのチーム設計が重要
• チーム設計は ccteams で1コマンドインストールできる（オーケストレーションルールもすでに入ってます）

もちろんタスクごとで最適なモデルを随時判断させることもできます。その場合はCLAUDE.md に「推論が重いタスクは Opus に…」などと書けば良いんですが、model を固定しておくと、委譲先が決まった時点でモデルも決まり、追加の条件分岐が不要になります。良し悪しはプロジェクトごとであるとは思いますが、大体のタスクであればエージェントごとにモデルを固定する形で問題ないかなと思います。

もしこの設定で少しでも手間が省けましたら、リポジトリにスターをいただけると励みになります 🙌

追記（7月7日）

Fable 5が終了した後のためにどのように「引き継ぎ」をしたら良いかも書きました！参考になると嬉しいです。

https://zenn.dev/yui/articles/e4f8268ab5c6c1