筆者は日々の業務支援に Claude を利用していますが、最上位モデルの Claude Fable 5 を常用すると、トークンの減りの速さに驚かされます。調べてみると、これは使い方の工夫でどうにかなる話ではなく価格構造の問題であり、同時に、Anthropic 自身が対策となる2つの構成を実測値つきで示していることも分かりました。本記事では結論を先に示したうえで、その根拠となる料金構造、2つの戦略の仕組みと実測値、導入手段の現状、そして「当面の現実解はどちらか」までを公式ドキュメントと公式発表をもとに整理します。

結論 — Fable 5 は常用せず、節約構成で使う。当面の現実解は戦略A

Fable 5 をメインモデルに据えて成果物を書かせ続ける使い方は、次章で見るとおり API 課金・サブスクリプションのいずれでも持続しにくいものです。かわりに Anthropic の開発者向け公式アカウント @ClaudeDevs が2026年7月8日のスレッドで示したのが、次の2つの構成です。

構成役割分担公式の実測値
戦略A: アドバイザー構成Sonnet 5 が実行し、Fable 5 が要所で助言するFable 5 単体の約92%のスコアを約63%の価格で（SWE-bench Pro）
戦略B: オーケストレーター構成Fable 5 が計画・指揮し、Sonnet 5 ワーカーが実行するFable 5 単体の96%の性能を46%の価格で（BrowseComp）

両者に共通する原則は「高価なモデルにトークンを出させない」ことです。成果物や大量の調査結果といったトークンのかさむ出力は安価な Sonnet 5 に任せ、Fable 5 の出番は短い助言、または計画と指揮に限定します。

ただし、2つの構成は導入の手軽さがまったく違います。戦略Aが Claude Code のコマンド一つで有効化できるのに対し、戦略Bを動かす手段は現時点でベータ提供のAPI機能か自前構築に限られます（後述）。したがって本記事の結論は「当面の現実解は戦略A」です。

なぜ高いのか — 単価は Opus 4.8 の2倍、トークン数も約30%増

Anthropic の公式料金表によれば、主要モデルの API 価格（100万トークンあたり）は次のとおりです。

モデル入力出力
Claude Fable 5$10$50
Claude Opus 4.8$5$25
Claude Sonnet 5 ※$2$10
Claude Sonnet 4.6$3$15

※ Sonnet 5 は2026年8月31日までの導入価格。同年9月1日以降は Sonnet 4.6 と同じ入力 $3・出力 $15 になります。

入力・出力とも、Fable 5 は Opus 4.8 のちょうど2倍、導入価格の Sonnet 5 と比べれば5倍にあたります。

さらに見落とされがちな点として、同じ料金ページには次の注記があります。

Claude Opus 4.7 and later Opus models, Claude Fable 5, Claude Mythos 5, Claude Mythos Preview, and Claude Sonnet 5 use a newer tokenizer that contributes to their improved performance on a wide range of tasks. This tokenizer produces approximately 30% more tokens for the same text.

（Opus 4.7 以降の Opus・Fable 5・Sonnet 5 などは、幅広いタスクでの性能向上に寄与する新しいトークナイザーを採用しており、同じテキストに対して約30%多くのトークンを生成する）

つまり Fable 5 は、単価が高いだけでなく、同一の作業でカウントされるトークン数自体も旧世代モデルより増えます。Claude Code をサブスクリプション（Pro/Max）で使う場合も、この消費はプランの利用上限（usage limit）に計上されるため（Claude Code のドキュメントにも、後述するアドバイザーの使用分が利用上限に計上される旨が明記されています）、Fable 5 を常時メインモデルとして回す使い方は、API 課金・サブスクリプションのいずれでも持続しにくいといえます。

戦略A — Sonnet 5 executor × Fable 5 advisor

土台になるのは、Anthropic が2026年4月9日に発表した advisor tool です。安価な executor（実行役）モデルがタスクを最後まで駆動し、判断に迷う局面でのみ上位の advisor（助言役）モデルに相談する、という構成を API のツール定義ひとつで実現します。@ClaudeDevs は、この executor に Claude Sonnet 5 を名指ししています。

ポストの内容を訳せば「実行役の Sonnet 5 が、判断に迷う場面で Fable 5 を呼び出して助言を得る。大半のトークンはより安価な executor 側の単価で課金される」という構成の紹介です。API ドキュメントによれば、advisor は executor の作業の文脈を読んで短い助言（通常400〜700テキストトークン）だけを返し、ユーザー向けの最終成果物は生成しません。前掲の料金表のとおり Sonnet 5 の単価は導入価格で Fable 5 のちょうど1/5であり、高価な単価が適用されるのは短い助言部分に限定されます。

効果は、続くポストで公表された実測値に示されています。

コーディングベンチマーク SWE-bench Pro において、この構成は Fable 5 単体のスコアの約92%を、約63%の価格で達成します。しかも Fable 5 が呼び出されるのはタスクあたりまれ（およそ1回）で、作業の大半は Sonnet 5 が実行します。「要所でだけ上位モデルに相談する」という設計が、呼び出し頻度の実測値でも裏付けられている形です。

戦略B — Fable 5 orchestrator × Sonnet 5 workers

第2の戦略は、役割を逆にします。Fable 5 をオーケストレーター（司令塔）に据えて計画と指揮を任せ、実作業は複数の Sonnet 5 ワーカー（サブエージェント）に委任する構成です。ここでも大半のトークンは安価なワーカー側の単価で課金されます。

こちらも実測値が公表されています。Web 調査ベンチマーク BrowseComp を Claude Managed Agents 上で測定したところ、この構成は Fable 5 単体の96%の性能を46%の価格で達成しました。トークンを大量に消費する調査作業が Sonnet 5 側に委任されるためです。

ただし、戦略Bを動かす手段はいまのところ限られる

数字は戦略Aより魅力的ですが、これを実際に動かす経路は現時点で次の3つしかありません。

  1. Claude Managed Agents — 公式実測と同じ経路です。公式ドキュメントによればベータ提供中で、全APIアカウントに既定で有効化されています（ベータヘッダの指定のみで申請は不要）。ただし API 課金専用で、トークン代に加えてセッション実行時間 $0.08/時が加算されます。また戦略Aの advisor tool と異なり、ZDR（Zero Data Retention）の対象外です
  2. Claude Code のサブエージェントで近似 — メインモデルを Fable 5 にし、サブエージェントの定義でモデルを指定（model: sonnet）すれば、似た構成をサブスクリプションの範囲でも組めます。ただし advisor tool のような「コマンド一つで有効化」の仕組みはなく、オーケストレーターが自分で手を動かさずに委任するかはプロンプトとエージェント設計次第です。この経路での公式実測値も公表されていません
  3. Agent SDK 等で自作 — エージェントループから自前で構築する、開発者向けの経路です

いずれも API 課金が前提か、相応の設計・構築を要します。サブスクリプションで Claude Code を使う一般的な利用者にとって、戦略Bは「手軽に試す」選択肢には入りづらいのが現状です。

なお、この実測値は Claude Managed Agents 上での結果であり、Claude Code にそのまま同名の「オーケストレーターモード」が用意されているわけではありません。ただし、Claude Code には subagents という仕組みがあり、役割ごとにサブエージェントを定義して作業を委任できます。そのため、考え方としては Claude Code にも応用できますが、公式実測値そのものは Managed Agents 上の結果として読む必要があります。

どちらを選ぶべきか — しばらくは戦略A

理屈のうえでは、2つの構成は「高価なモデルにトークンを出させない」という原則を共有しつつ、主導権の置き方が逆です。戦略Aでは安価なモデルが手を動かし、上位モデルは舵取りに徹します。戦略Bでは上位モデルが計画を握り、安価なモデルが手を動かします。公式の実測値も対照的な場面で測られており、逐次に判断を積み重ねるコーディング作業（SWE-bench Pro）では戦略Aが、多数のワーカーへ並列に委任できる調査作業（BrowseComp）では戦略Bが、それぞれ好成績を示しました。タスクが一本道なら A、作業を分担できるなら B、というのが数字から読み取れる目安です。

しかし実際の選択では、導入手段の差が決定的です。戦略Aは Claude Code のコマンド一つで有効化でき、公表された実測値もその advisor tool そのものを測ったものです。一方の戦略Bは、前述のとおりベータのAPI機能を使うか自前で組むかしかなく、Claude Code のサブエージェントで近似しても、その効果を裏付ける公式の数字はありません。手軽さと確実さで選ぶかぎり、しばらくは戦略Aが現実解でしょう。

なお、いずれの数値もポストに示された概数であり、それぞれ単一のベンチマークによる測定です。公式ドキュメント自身も “Results are task-dependent. Evaluate on your own workload.”（結果はタスク依存であり、自身のワークロードで評価すること）と留保しています。

advisor tool の使い方

有効化方法は、Claude Code のドキュメントに次のように明記されています。

The advisor tool is experimental and requires Claude Code v2.1.98 or later with the Anthropic API.

You can set the advisor model in three ways:

  • /advisor command: set or change the advisor mid-session and save it as your default
  • advisorModel setting: configure a persistent default in your settings file
  • --advisor flag: set the advisor for a single session at launch

（アドバイザーツールは実験的機能であり、Claude Code v2.1.98 以降かつ Anthropic API での利用が必要である。アドバイザーモデルの設定方法は3通りある。/advisor コマンド——セッション途中でアドバイザーを設定・変更し、既定値として保存する。advisorModel 設定——設定ファイルに恒久的な既定値を設定する。--advisor フラグ——起動時にそのセッション限定でアドバイザーを設定する）

呼び出しのタイミングはモデル側が判断しますが、プロンプトで明示的に相談を指示することもできます。なお、Fable 5 をアドバイザーとして使うには v2.1.170 以降と組織の Fable 5 アクセスが必要です。

モデルの組み合わせには制約があります。アドバイザーはメインモデルと同等以上の能力でなければならず、Fable 5 は Haiku・Sonnet・Opus いずれの executor に対してもアドバイザーになれます。一方、Fable 5 をメインモデルにした場合に許されるアドバイザーは Fable 5 のみです。戦略Aの組み合わせはこの制約にも適合します。逆に Fable 5 をメインに据えたままではアドバイザーを足してもトークン消費は減りません（メインモデルが成果物を生成し続けるうえ、advisor の分だけ消費が増えます）。

メリットとデメリット

メリット。 第一に、効果が公式の実測値で定量的に裏付けられています（SWE-bench Pro で Fable 5 単体の約92%のスコアを約63%の価格で）。第二に、導入が容易なこと。Claude Code ではコマンド一つで有効化できます。第三に、呼び出し回数や助言の長さに上限を設けるといった、コストを管理する仕組みが用意されていること。第四に、Claude Code ではセッション途中で /advisor を切り替えてもメインモデルのプロンプトキャッシュが無効化されません。ZDR（Zero Data Retention）の対象でもあります。

デメリット。 第一に、ベータ・実験的機能であり、挙動・価格・提供条件は変更されえます。提供は Anthropic API（および Claude Platform on AWS）に限られ、Amazon Bedrock・Google Cloud・Microsoft Foundry では使えません。第二に、アドバイザーは呼び出しのたびに会話全体を読み直します。Claude Code ではこの読み込みはキャッシュされないため、長大なセッションで頻繁に呼ばれると入力トークン費（サブスクリプションでは上限消費）が膨らみます。API にはアドバイザー用のキャッシュ設定も用意されていますが、効果が出るのは会話あたり約3回の呼び出しからです。第三に、呼び出しタイミングはモデル任せで、回数を強制・上限設定する仕組みは Claude Code 側にはありません（プロンプトで指示するのみ）。第四に、単発の Q&A のような計画余地のないタスクには向きません。最後に、Fable 5 アドバイザーの応答は暗号化された形式で返されるため、API 利用時に助言の中身を人間が直接検分できないという運用上の制約もあります。

まとめ

  • Claude Fable 5 は単価が Opus 4.8 の2倍（入力 $10・出力 $50/MTok）であるうえ、新トークナイザーにより同じテキストでカウントされるトークン数も約30%増えます。メインモデルとしての常用は持続しにくい価格構造です
  • 公式 @ClaudeDevs が示す解決は、「高価なモデルにトークンを出させない」2つの構成です
  • 戦略A（Sonnet 5 executor × Fable 5 advisor）は、SWE-bench Pro で Fable 5 単体の約92%のスコアを約63%の価格で達成。Claude Code のコマンド一つで今すぐ使えます
  • 戦略B（Fable 5 orchestrator × Sonnet 5 workers）は、BrowseComp で Fable 5 単体の96%の性能を46%の価格で達成。ただし動かす手段はベータのAPI機能（Claude Managed Agents）か自前構築に限られ、手軽な選択肢には入りづらいのが現状です
  • 理屈の目安は「一本道のコーディングは A、分担できる調査は B」。導入の手軽さと実測の確実さも含めると、当面の現実解は戦略Aです
  • advisor tool はベータ機能である点、アドバイザーが毎回会話全体を読み直す点、Fable 5 アドバイザーの助言が暗号化されて返る点など、導入前に把握しておくべき制約もあります

参考