Anthropic公式が明かした Fable 5 の使い方 — 賢いモデルは「顧問」に、実行は安いモデルに

AIには、賢くて高いモデルと、そこそこ賢くて安いモデルがあります。賢い方が Fable 5、安い方が Sonnet 5。この2つをどう組み合わせるかについて、Anthropicの公式アカウント @ClaudeDevs が実測数値つきでスレッドを公開していました。付属のcookbook（技術者向けの実装ノート）には「割に合わない場面」まで正直に書かれている。読み応えがあったので、自分の開発環境（Claude Code のグローバル設定）にどう反映したかまで含めて記録します。

結論から言うと、上のグラフに尽きます。賢いモデル（Fable 5）1体に全部やらせるのが、実は一番コスパの悪い選択肢でした。 安いモデル（Sonnet 5）と組み合わせた方が、ほぼ同じ精度をずっと安く再現できる。組み合わせ方には2種類あります。

パターン1: advisor（顧問） — 実行モデルが、詰まった時だけ上位モデルに聞く

早い話、こういう話です。Advisor（Fable 5）は「詰まった時だけ電話一本で呼べる顧問」。普段の実行はSonnet 5が回し続け、迷った時だけ聞きに行く。顧問を常駐させるより、ずっと安い。

元スレッドの図はこれをそのまま描いていました。Executor（Sonnet 5）が毎ターン主導し、Tool call経由でAdvisor（Fable 5）をオンデマンドで呼ぶ。Advisorは助言を返すだけで、主導権はExecutor側のまま動きません。

数字が具体的です。SWE-bench Pro（AIのコーディング実力を測る評価セット）での実測: Sonnet 5単体は精度0.75・コスト約$0.7/タスク、Fable 5単体は精度0.90・コスト約$2.3/タスク。その間で、Sonnet 5 + Fable 5 advisorは精度0.84・コスト約$1.5/タスク。つまり「Fable 5単体の92%の精度を、63%のコストで」再現できる、とスレッドは書いています。Advisorが呼ばれる回数は「タスクあたり約1回」。ほとんど呼ばれない、ということ自体がポイントです。

これは自分が既に近い運用をしていました。設計や難問に詰まったときに上位モデルへ一度だけ相談し、結論だけ受け取って自分の作業に戻る型です。数字で裏付けが取れたので、既存のやり方の答え合わせになりました。

パターン2: orchestrator（指揮官） — 上位モデルが計画し、下位モデルの群れに投げる

3本目のツイートは逆方向でした。Orchestrator（Fable 5）は「計画を立てて、部下に投げる指揮官」。自分では現場作業をせず、Worker（Sonnet 5）を複数体並列で動かす。

Orchestrator（Fable 5）がPlanを立て、Worker（Sonnet 5）を複数体Fan outで並列実行させる。トークンの大半は安いWorkerレートで課金される。

BrowseComp（AIの調べ物能力を測る評価セット）での実測: 全部Sonnet 5だと精度77.8%・$16.01/問題、全部Fable 5だと精度90.8%・$40.56/問題。その間で、Fable 5 orchestrator + Sonnet 5 workersは精度86.8%・$18.53/問題 — Fable 5単体の96%の精度を、46%のコストで。

こちらは、自分の環境の穴でした。設計タスクで上位モデルに乗っているとき、そこから派生させるサブタスクのモデル指定を省略すると、既定では呼び出し元のモデルをそのまま継承します。つまり「上位モデルに乗っている間は、増やしたサブタスクも全部上位レート」になっていた。ここに明示的な下方委譲を入れる余地があると分かりました。

cookbookが明かす、4つの正直な注意点

Anthropic公式cookbook（CMA_plan_big_execute_small.ipynb）は、Web調査タスク（米国の国立公園10箇所×2属性＝20個の事実を、公式サイトで1件ずつ裏取りする課題）でこの構成を実測しています。結果は split構成が 2.5倍安く、3倍速く、workerの入力トークンの84〜98%が安いレートで課金された、というもの。ただしこの文書が誠実なのは、ここで終わらないところです。

1. 基準を揃えないと比較が壊れる。 上位モデル単体を自由にやらせると、1ソースだけ読んで安く済ませてしまう。それは「同じ仕事を安く」ではなく「別の粗い仕事」。比較を成立させるには、両方に同じ検証基準（例: 全事実を独立した2ソースで裏取り）を明示的に課す必要がある
2. 委譲がゼロなら、往復コストだけの払い損。 Orchestratorがサブを1体も呼ばず自分の知識で答えてしまった実行は、上位モデルの料金を払って何も得ていない。ログに委譲の形跡があるか、実数で確認する必要がある
3. 前提そのものは検証対象から漏れやすい。 この実験では「個々の事実」は2ソース検証されていたのに、「検証すべき10件の対象そのものの選定」はどちらの構成もモデルの記憶に頼っていて、実際に本来10位のはずの公園を1つ取り違えていた。基準は「明示した範囲」しか守られない、という当たり前だけど見落としがちな話
4. 委譲には固定コストがあり、細切れにしすぎるとむしろ高くつく。 ブリーフの粒度には最適点がある

そして「どういう時にこの構成が割に合わないか」も書かれています。読む量が少ないタスク（裁定材料がない）、上位モデルが委譲せず即答できてしまうタスク、そして生の資料そのものに上位モデル級の判断力が要るタスク（安いWorkerの要約が、肝心の要点を消してしまう）。さらに、網羅型タスク（coverage — 独立した多数の事実を必ず全部読んで検証する、記憶では答えられない）では下方委譲が圧勝する一方、探索型タスク（discovery — 広い空間から1つの答えを見つける、検索の勘が効く）では上位モデル単体との差が縮まる、という使い分けの軸も提示されていました。

自分の環境に何を反映したか

Anthropic公式のFableモデル（advisor役）に「このスレッドとcookbookのうち、自分のグローバル設定に反映する価値があるのはどこか」を相談しました（ちょうどこの記事のテーマ自体を、advisorパターンで実践したことになります）。返ってきた判断は次の通りです。

反映したこと:

• 新規リファレンス references/model-delegation.md を作成し、上方(advisor)・下方(orchestrator)の使い分けと、cookbookの4つの注意点を型として保存
• 既存の「エージェント並列」運用ルールに「サブに渡す時は『クエリ＋目的＋合否基準』をセットで（基準なし委譲は安いのでなく粗いだけ）」を追記。さらに「上位モデルのセッション中の重い読み系サブタスクは、明示的に安いモデルへ委譲する」旨を追記した

反映しなかったこと:

• advisorパターンそのものの新しいルール化はしなかった。既存の「上位モデルへのエスカレーション運用」とほぼ同型で、二重化するだけだったため
• Managed Agents APIの契約詳細（サブエージェント間のキャッシュ分離やroster仕様など）は反映しなかった。自分は別の実装（Claude Codeのエージェント機能）で運用しており、API契約レベルの話はそのまま適用できる変数ではないため
• ベンチマークの生数値表はそのまま転記しなかった。判断を左右するのは「92%の精度を63%のコストで」のような比率だけで、生の数字表は設定ファイルを太らせるだけだと判断したため

「読んで感心する」で終わらせず、実際にどこを変えてどこを変えなかったかまで書き残しておくのが、この手の技術情報を活かす一番の型だと思っています。

3行まとめ

1. 上位モデルは「たまに聞く顧問」か「計画して投げる指揮官」のどちらかに使う — 上位モデル(Fable 5)単体とほぼ同じ精度を、advisorなら92%の精度を63%のコストで、orchestratorなら96%の精度を46%のコストで再現できる（Anthropic公式実測。比率はいずれもFable 5単体を基準）
2. 委譲には守るべき型がある — 基準を明示する・委譲が実際に起きたか確認する・前提そのものも検証対象に入れる・細切れにしすぎない
3. 読んだら、どこに反映してどこは反映しなかったかまで書く — 感心して終わらせない

参考にした投稿への感謝

今回は @ClaudeDevs の公式スレッドと、そこからリンクされていたAnthropic公式cookbook・ドキュメントを一次情報として使いました。実測ベースで「割に合わない場面」まで正直に書いてくれている技術文書は、そのまま自分の判断材料になります。ありがとうございました。

なお、期間限定でFable 5が使えた一日の別の記録は 「期間限定の賢いモデルに『作品』ではなく『土台』を作らせた一日」 にあります。今回は「モデルの組み合わせ方」、あちらは「モデルの使い道」の話で、切り口が違います。

※この記事は、本文に登場する AI 相棒（Claude）との共同執筆です。何をやるか・何を公開するかの判断は人間側、実行と初稿は AI 側。記事中の数字はすべて一次情報（@ClaudeDevs公式スレッド・Anthropic公式cookbook）からの引用値です。