AIを使っていて、こう思ったことはありませんか。
「最上位モデルは賢い。でも、高すぎる」と。
この悩みに対して、Anthropicが興味深いベンチマークを公開しました。
最上位モデルのFable 5を「指揮役」に据えます。
そして、実作業は安価なSonnet 5に任せるのです。
この構成なら、性能をほぼ維持したままコストを半分以下にできたといいます。
Redditでは、この話題をきっかけに濃い議論が展開されました。
実践ノウハウもあれば、真っ向からの反論もあります。
本記事では、その中身を整理してお届けします。
Anthropicが公開した数値
元になったのは、Anthropicが公式に発表したベンチマーク結果です。
対象は、2つのマルチモデル構成でした。
1つ目は、Fable 5をオーケストレーター（指揮役）とする構成です。
ワーカー（実行役）には、Sonnet 5を使います。
BrowseCompというベンチマークでは、Fable 5単体の96%の性能を46%のコストで達成しました。
具体的には、精度が90.8%に対して86.8%です。
そして、1問あたりのコストは40.56ドルに対して18.53ドルでした。
2つ目は、逆の構成です。
Sonnet 5が実行役となります。
そして、必要なときだけFable 5に「相談」するのです。
こちらはSWE-bench Proで、約92%の性能を約63%のコストで実現しました。
性能とコストの両方で勝ったのは、前者です。
つまり、Fable 5が指揮を執る構成でした。
Claude Codeで同じことができる仕組み
投稿者によると、この分担はClaude Codeの標準機能だけで再現できます。
鍵になるのは、次の3つの機能です。
1つ目は、サブエージェントのmodel:指定です。
エージェント定義ファイルにmodel: haikuやmodel: sonnetと書きます。
すると、その役割は安いモデルに固定されます。
メインセッションで何を使っていても、影響を受けません。
2つ目は、エージェントごとのeffort:設定です。
Anthropicのガイダンスによると、現行モデルの低effortは前世代の最高effortに匹敵します。
つまり、調査や機械的な作業はeffort: lowで回せるのです。
しかも、品質面の犠牲はほとんどありません。
3つ目は、CLAUDE.mdに書く委譲ポリシーです。
「何をどの役割に任せるか」を、メインセッションに伝えておきます。
ポイントは、役割名だけで記述しておくこと。
こうすれば、モデルが世代交代しても書き直す必要がありません。
コミュニティの反応：「それ、みんなやってるよ」
スレッドで特に反響が大きかったのが、この指摘でした。
Claude Codeのv2.1.198以降、組み込みのExploreサブエージェントはメインセッションのモデルを引き継ぎます。
つまり、普段FableやOpusを使っている人は要注意です。
裏で走る検索処理まで、高いモデルの料金で課金されているからです。
対策は、シンプルでした。
Exploreという名前のユーザーエージェントを自分で作ります。
そして、model: haikuを指定するだけです。
これで、組み込みの動作を上書きできます。
コメント欄には、「これだけで先週のOpusクォータが半分浮いた」という報告もありました。
地味ですが、効果の大きい設定です。
コミュニティの反応：「それ、みんなやってるよ」
一方で、スレッドの大勢を占めた反応は意外なものでした。
「それは、とっくに標準的なやり方だ」という声です。
高いモデルに計画させて、安いモデルに実行させる。
この運用をOpusで以前から続けている人が、多かったのです。
そのため、目新しさよりも「やっと公式が数値を出した」という受け止めが目立ちました。
とはいえ、議論の中身は濃いものでした。
実践的な知見も、数多く共有されています。
役割分担の設計例
あるユーザーが、「スキル」の設計思想を共有していました。
モデルの使い分けを考えるうえで、参考になります。
要点は、こうです。
Fableの価値は、労働力ではなく判断力にある。
だから、「最強モデルであることが結果を変える部分」にだけ推論力を使う。
具体的には、次のような仕事です。
- ユーザーの本当の意図を理解する
- アーキテクチャを選択する
- トレードオフを決断する
- 最終レビューを行う
その下の階層は、役割で分かれます。
Opusは、複雑な実装や深いデバッグを担当します。
つまり、委譲できる仕事の中で最も難しい部分です。
Sonnetは、範囲の決まった実装やテスト追加を受け持ちます。
いわば、通常のエンジニアリング作業です。
そしてHaikuには、ファイル探索やログの要約を任せます。
要するに、「証拠集め」の係です。
判断は上へ、証拠は下へ。
この原則が、全体を貫いています。
手堅い運用フローの一例
別のユーザーは、もう一段工夫したフローを紹介していました。
手順は、次の通りです。
まず、Opusに初期計画を書かせます。
そして、自分でレビューして納得いくまで直します。
次に、Fableにその計画への「敵対的レビュー」をさせるのです。
穴を、徹底的に突かせます。
最後に、修正済みの計画をOpusに実装させます。
つまり、Fableの推論力を「計画の粗探し」という一点に集中させるわけです。
この使い方が資源効率の面で優れていた、という報告でした。
逆の結果が出た、という反論
ここからが、本記事の一番のポイントかもしれません。
あるユーザーが、この分担構成を対照実験（A/Bテスト）にかけました。
場所は、Claude Code内です。
すると、コストについて正反対の結果が出たと報告したのです。
実験の条件は、厳密でした。
同じタスク、同じメインモデル（Opus 4.8）を使います。
変えたのは、Sonnetワーカーへの委譲のオン・オフだけです。
結果は、次の通りでした。
- 小さいタスク：単独1.40ドル vs 委譲あり1.73ドル（24%増）
- 大きめのタスク：単独5.67ドル vs 委譲あり11.99ドル（111%増）
しかも、小さいタスクの委譲版は受け入れチェックに落ちています。
なぜ、こうなるのでしょうか。
このユーザーは、自分の累計利用（約210億トークン）を分解しました。
すると、コストの約91%はコンテキストの再処理（キャッシュ読み書き）だったのです。
純粋な出力は、9%弱にすぎません。
一方、ワーカーはメインが既に持っている文脈をゼロから組み立て直します。
そして、その成果は結局メインの文脈に戻ってくるのです。
つまり、9%の部分を節約しようとして、91%の部分を膨らませていたことになります。
さらに、興味深い点があります。
委譲したときは、メインモデル自身の請求額まで増えていたのです。
ワーカーを管理しながら、自分でもコードを書き続けてしまう。
その結果、仕事量がむしろ増えていました。
それでも意味がある場合
ただし、この反論者も元投稿を全否定してはいません。
Fableの利用枠は、Fable専用の週次上限と共有プールの両方を消費します。
そのため、真っ先に枯渇するのです。
ここで、作業量をSonnetワーカーに逃がすとどうなるでしょうか。
総コストは、増えます。
しかし、その増分は余裕のある共有プールから出ていきます。
そして、逼迫しているFable枠が温存されるのです。
つまり、これは「コスト削減」ではありません。
「利用枠の付け替え」だという整理でした。
自分がどちらを買っているのか。
それを理解したうえで導入すべき、という指摘です。
導入前に知っておきたい注意点
スレッド全体から、実務上の注意点をいくつか拾っておきます。
まず、公式の数値はAPIベンチマークです。
そのため、サブスクリプション利用では同じ数字になりません。
節約効果は、方向性として一致する程度です。
投稿者自身が、この点を明記しています。
次に、指揮役へのモデル指定を忘れると悲惨です。
Fableが、自分と同じFableのサブエージェントを量産してしまいます。
その結果、セッション上限があっという間に消えたという体験談が複数ありました。
また、細かい設定が面倒な人もいるでしょう。
その場合は、組み込みの/model opusplanでも大部分はカバーできるとのこと。
凝った構成を組む前に、まず標準機能を試す価値はありそうです。
最後に、モデルの性質についての報告も紹介します。
指揮役をやらせると、「自分でコードを書きたがる」というのです。
管理職は退屈らしい、という笑い話でした。
しかし、委譲が徹底されない原因として頭に入れておくとよいでしょう。
まとめ
「賢いモデルが指揮し、安いモデルが実行する」構成を見てきました。
Anthropicの公式数値では、性能96%・コスト46%という結果です。
Claude Codeなら、今日から試せます。
使うのは、サブエージェントのモデル指定、effort設定、CLAUDE.mdの委譲ポリシーという3つの機能です。
一方で、逆のデータも示されました。
実環境のA/Bテストでは、委譲のほうが高くついたのです。
理由は、コストの大半がコンテキスト再処理にあること。
そして、委譲はそれを増やす方向に働くことでした。
どちらが正しい、という話ではないのでしょう。
要は、タスクの形次第です。
並列化しやすい大量の定型作業には、向いています。
しかし、文脈を深く共有すべき一本道の作業には向きません。
さらに言えば、節約できるのはお金ではないかもしれません。
逼迫しがちな上位モデルの利用枠、というのが実態に近そうです。
まずは、低リスクの設定から試してみてください。
例えば、ExploreエージェントのHaiku固定です。
効果を確かめながら、自分のタスクに合う分担を探っていく。
それが、現実的な進め方だと思います。
