Fable 5をトークン破産させずに使い倒す — はてなブックマークレポート

📋 記事の概要

Claude Fable 5（Anthropicの最上位モデル）をメインモデルとしてClaude Codeで使うと、その圧倒的な賢さゆえにトークン消費が凄まじく、「トークン破産」に陥ってしまう問題に対処する記事です。著者はFable 5を「考えることだけに使うオーケストレーター」として位置づけ、実作業を安価なモデルに委譲する役割分担の手法と、それを1コマンドで構築できる自作CLIツール「ccteams」を紹介しています。

Claude Code Fable 5 オーケストレーションサブエージェント ccteams トークン最適化

🔥 重要ポイント

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

Fable 5をメインモデルとして通常設定で使うと、シンプルなタスク（例：「APIにレート制限を追加」）でも、そのタスクが以下のような重さの異なる作業に分解されるため、全部Fable 5が処理してしまいトークンが浪費されます。

アルゴリズムを決める（コア設計 — Fable 5がやるべき）
カウンタの配置、バースト時の挙動検討（設計 — Fable 5がやるべき）
ミドルウェアを書く、ルートに結線（実装 — 安いモデルでOK）
テストを書く、lint修正（機械的作業 — 安いモデルでOK）
エッジケースを潰す（検証 — 中級モデルでOK）

      💡 核心： 設計さえ決まってしまえば、後はより安価なモデルに任せても十分うまくいく。だからFable 5を設計のみに徹底させる。
    

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

著者の役割分担：

🧠 Fable 5（reasoning effort: max）= オーケストレーター

計画・分解・統合だけ。コードは書かない。

🔍 Opus = 深い推論用サブエージェント

設計判断、複雑なデバッグ、レビュー。

⚙️ Sonnet = 機械的作業用サブエージェント

実装、ボイラープレート、テスト、雑務。

👥 Codex = 別視点のシニアエンジニア

高リスクな判断のセカンドオピニオン。

Fable 5には「考えて、割り振って、まとめる」ことだけをやらせます。コードを書いてテストする泥臭い作業を安いモデルに一任することで、一番トークンを食うFableの出番が計画と統合だけに絞られます。

      🎯 最大の発見： usageが減ったのは想定通りだったが、「コンテキストがきれいなままだとAIの判断がブレない」こともかなり嬉しかった。実装の詳細でコンテキストが汚れないので、判断の質が最後まで落ちない。
    

3. サブエージェントの設計の難しさ

セットアップ自体は簡単ですが、ちゃんと働くサブエージェントを作るのは別問題。

descriptionの質が委譲の精度を決める： 「推論が重いタスク用」程度の粒度だと、境界ケースで委譲先がブレる。
プロンプトが出力の質を決める： 「何を読んでから作業するか」「何を返すか」を書き込んでおかないと、毎回オーケストレーターが尻拭いして手戻りが発生。
「考える人」と「手を動かす人」の2体では粗すぎる： スコープを切る・設計する・実装する・検証する・出荷するは別の仕事。QAをbuilderと同じエージェントにやらせると「自分の書いたコードに自分でLGTM」になる。

⚠️ 本当に考えないといけないのは、モデルの割り当てではなくチーム設計。そしてチーム設計をゼロから書くのは、正直けっこう大変。

4. ccteams：チーム設計を1コマンドでインストール

著者が作ったClaude Codeのエージェントチーム・パッケージマネージャー。役割分担済みのサブエージェント一式（description・システムプロンプト・ツール制限まで書き込み済み）とオーケストレーションルールが.claude/に入る。

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

用意されているチーム：

チーム	用途
generalist	スタック非依存の万能チーム：スコープ→設計→実装→QA→出荷
next-ts	Next.js (App Router) + TypeScript + Tailwind
go-api	Go の HTTP API バックエンド
python-fastapi	FastAPI + Pydantic v2
rails / django	Rails / Django + DRF
debug	再現→原因特定→最小修正→回帰テスト
research	コードを書かない技術調査専門

5. generalistチームの構成（モデル割り当て済み）

エージェント	役割	モデル
（メインセッション）	オーケストレーター	Fable 5（effort max）
scope-planner	スコープを削る・要件を固める	opus
architect	設計判断	opus
builder	実装・ボイラープレート・テスト	sonnet
qa-reviewer	検証・エッジケース探し	opus
shipper	コミット・CI・雑務	sonnet（haikuでも可）

      💡 ここがミソ： architectやqa-reviewerをFable 5にしない。一見、重要な設計やレビューにも一番良いモデルを使いたくなるが、タスクがサブエージェントに渡る前にFable 5はすでに一番難しい仕事（曖昧な依頼を明確で境界のある問いに変換）を終えている。問いが整理された後なら、Opusで十分足りる。
    

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

OpenAIの公式Codexプラグインを入れると、Claude Codeの中からCodexを呼べる。コツは「レビュアー」ではなく「対等な相棒」として扱い、高リスクな判断ではOpus系エージェントとCodexに同じ問題を独立に解かせてから統合すること（お互いの答えを見せない）。

7. 指示を出す時は簡潔に

エージェントチーム適用後は、ゴールを述べるだけでOK：

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

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

📌 まとめ（記事から引用）

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

💡 この記事の価値

279はてブの大人気記事 — 多くのClaude Codeユーザーの悩み（トークン消費）に直結
実践的なノウハウ： 単なる「モデルを変える」提案ではなく、チーム設計という本質に踏み込んでいる
ツール提供： ccteamsというCLIで、ベストプラクティスを1コマンドで導入可能
「コンテキストの汚染防止」という洞察： オーケストレーターに実装詳細を触らせないことで判断精度が保たれるという点が目から鱗

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