はじめに

Claude Fable 5 は、Anthropic が一般提供している中で最も高性能なモデルです。長時間の自律エージェントや、一発で込み入ったシステムを組み上げるような難タスクで力を発揮します。一方で、料金は入力 100万トークンあたり $10、出力 $50 と、Opus 4.8 の約2倍、Sonnet 5 の3〜5倍という高さです。

この記事では、その Fable 5 を「全部のタスクに素で通す」のではなく、ハーネス（エージェントの実行の枠組み）を工夫してコスト効率よく使う設計パターンを整理します。具体的には、オーケストレーター/ワーカーの分業、Advisor ツール、effort の使い分け、キャッシュとコンテキスト削減、非同期サブエージェントの5つです。あわせて、必須トピックとして他LLM とのベンチマーク比較と、モデル別の価格も見ていきます。

きっかけは、Claude Platform チームの Lance Martin さんが X で共有していた「Fable 5 で性能とコストを複数の eval で計測してみた」という一連の投稿です。そこで見えてきた「フロンティア知能を使う場所を絞ると、品質を保ったままコストが大きく下がる」という考え方を、実測値と一緒にまとめます。

先に数字の扱いを断っておきます。本記事のベンチマークやコストの実測値は、Anthropic 公式・各社公称値・第三者集計の寄せ集めで、同じ環境で同じ日に回し直した値ではありません。傾向をつかむ材料として読んでください。Fable 5 自体の仕様と価格は公式ドキュメント準拠です。

Fable 5 とは：最上位モデルと、その値段 🧠

まず対象を確認します。Fable 5（モデルID claude-fable-5）は、最も要求の厳しい推論と長期的なエージェント作業のために設計された、Anthropic の最上位クラスのモデルです。コンテキストウィンドウは 1M トークン、最大出力は 128k トークンです。

Fable 5 には、Opus 系と違う API 挙動がいくつかあります。ハーネスを組むうえで効いてくるので、先に押さえておきます。

思考は常時オンです。thinking パラメータは省略するか {type: "adaptive"} を渡します。{type: "disabled"} や budget_tokens を送ると 400 エラーになります。思考の深さは output_config.effort（low / medium / high / xhigh / max）で制御します。
生の思考連鎖は返りません。display: "summarized" で要約だけ受け取れます。
安全分類器が拒否すると、エラーではなく stop_reason: "refusal" を含む HTTP 200 が返ります。
30日データ保持が必須で、ゼロデータ保持（ZDR）では使えません。

そして本題の価格です。Fable 5 の高さが、そのままハーネス設計の動機になります。

モデル	入力（per 1M）	出力（per 1M）	対 Fable 5 の目安
Fable 5	$10	$50	1x（基準）
Opus 4.8	$5	$25	約 1/2
Sonnet 5	$3（導入 $2）	$15（導入 $10）	約 1/3〜1/5
Haiku 4.5	$1	$5	約 1/10

この表がすべての出発点です。Fable 5 は賢いですが、同じ作業を Sonnet 5 に流せば単価は 3〜5分の1、Haiku 4.5 なら10分の1です。だからこそ「Fable 5 の知能が本当に効く場所だけに使い、それ以外は安いモデルに肩代わりさせる」という発想が生きてきます。

なぜ「ハーネス」で考えるのか 🎛️

素朴にやると、エージェントの全ステップ（計画も、ファイル読みも、テスト実行も、整形も）を Fable 5 が担当します。これは動きますが、単価が高いモデルに雑用まで全部やらせている状態です。

以下の図は、素の使い方とハーネス設計の違いを示しています。

この図のポイントは、Fable 5 の役割を「高レバレッジな推論」に絞っている点です。計画を立て、何を委譲するかを決め、返ってきた結果を統合する。ここは品質差が出力にはっきり出るので、Fable 5 の値段に見合います。逆に、決められた手順をなぞるだけの機械的な作業は、安いモデルでも十分な品質が出ます。

考え方をひとことで言うと、こうなります。

高い知能は、判断が難しいところにだけ使う。

以降で、その「絞り方」を5つのパターンに分けて具体化します。

パターン1：オーケストレーター/ワーカー分業 🏗️

いちばん効果が大きいのが、Fable 5 をオーケストレーター（指揮役）に置き、実作業を安いモデルのワーカーに委譲する構成です。

以下の図は、その役割分担を示しています。

この図のポイントは、Fable 5 が計画と統合という「頭を使う部分」だけにトークンを使い、量が多い機械的な作業は安いモデルが吸収している点です。難所は Opus 4.8、ボイラープレートは Sonnet 5、単純作業は Haiku 4.5、というように仕事の重さでモデルを振り分けます。

Claude Code のようなエージェント環境では、Fable 5 をオーケストレーターにして Opus / Sonnet のサブエージェントへ委譲することで、品質を落とさずにトークンコストを5〜10倍削減できたという集計もあります。

実測の一例が、Web 探索の BrowseComp です。第三者集計では、Fable オーケストレーター + Sonnet ワーカーの構成で、Fable 単独に対して約96%の精度を、46%のコストで出せたと報告されています。コストを1問あたりで見ると、こうなります。

構成	BrowseComp 精度	1問あたりコスト
Fable 5 単独	90.8%	$40.56
Fable オーケストレーター + Sonnet ワーカー	86.8%	$18.53

精度は 90.8% から 86.8% へ 4ポイントほど下がりますが、コストは半分以下です。「その4ポイントに $22 払う価値があるか」をタスクごとに判断できるのが、この分業の良いところです。

💡 実装のコツとして、オーケストレーターとワーカーでモデルを混ぜるとプロンプトキャッシュは効きません（キャッシュはモデル単位です）。メインループは1モデルに固定し、別モデルの仕事はサブエージェントとして切り出すと、キャッシュを保ったまま安いモデルを使えます。

パターン2：Advisor ツール（安い実行役 × Fable 5 助言役）🧭

分業をもっと細かく、1回のリクエストの中でやるのが Advisor ツールです。速くて安い Executor（実行役）を主役に置き、要所だけ高性能な Advisor（助言役）に相談させます。

ポイントは向きです。Advisor は Executor 以上の能力が必要なので、「安い Sonnet 5 が Executor、賢い Fable 5 が Advisor」という組み合わせになります。Executor がほとんどのトークンを生成し、Advisor は計画の相談にだけ呼ばれます。

以下は Advisor ツールの宣言例です（説明用の例です）。

response = client.beta.messages.create(
    model="claude-sonnet-5",          # Executor（安い・主役）
    max_tokens=16000,
    betas=["advisor-tool-2026-03-01"],
    tools=[
        {
            "type": "advisor_20260301",
            "name": "advisor",
            "model": "claude-fable-5",  # Advisor（賢い・要所だけ）
        }
    ],
    messages=[{"role": "user", "content": "この設計方針をレビューして実装して"}],
)

このコードのポイントは3つです。

主役（top-level の model）は安い Sonnet 5。トークンの大半はここで生成します。
相談役（tool の model）が Fable 5。難しい判断のときだけ内部で呼ばれます。
Advisor はサーバー側で動くので、tool_result を自分で返すループは不要です。

第三者集計では、Sonnet 5 Executor + Fable 5 Advisor の構成で、SWE-bench Pro が Fable 単独の約92%の性能を、63%の価格で出せたと報告されています。「9割の性能を6割の値段で」という費用対効果は、ハーネスの主役をどちらに置くかで大きく変わることを示しています。

パターン3：effort の使い分けでトークンを絞る 🎚️

Fable 5 を使う場面でも、output_config.effort で「考える努力」を調整すればトークンを節約できます。effort は low / medium / high / xhigh / max の5段階です。

以下の図は、役割ごとの effort の目安です。

この図のポイントは、effort を「役割に合わせて上下させる」点です。ワーカーの単純作業まで xhigh で回すと、安いモデルに切り替えた意味が薄れます。routine な処理は low〜medium に落とし、オーケストレーターの計画や難所だけ high〜xhigh に上げる。この上下だけでも、同じ構成のまま無駄なトークンを削れます。

なお Fable 5 では、ルーチンな作業まで高い effort にすると、必要以上に文脈を集めて考え込む傾向があります。「タスクが正しく終わっているのに時間がかかりすぎる」ときは、まず effort を一段下げてみるのが手軽です。

パターン4：キャッシュ・コンテキスト編集・Task Budget 🧹

トークンそのものを減らす仕組みも、コスト効率に直結します。長く動くエージェントほど効いてきます。

プロンプトキャッシュ: 安定した接頭辞（システムプロンプト、固定のツール定義）を先頭に置くと、キャッシュ読み出しは通常入力の約1割の単価で済みます。日時や UUID を接頭辞に混ぜると毎回キャッシュが壊れるので、変動要素は末尾に寄せます。
コンテキスト編集: 古いツール結果や思考ブロックを消して、履歴を軽く保ちます（要約ではなく削除）。長いエージェントループで積み上がった不要な出力を落とせます。
Task Budgets（beta）: エージェントループ全体のトークン上限をモデルに伝える機能です。モデルはカウントダウンを見ながら、優先順位をつけて綺麗に締めようとします。max_tokens（1レスポンスの強制上限）とは別物で、最低 20,000 トークンから設定できます。

以下は Task Budget の指定例です（説明用の例です）。

with client.beta.messages.stream(
    model="claude-fable-5",
    max_tokens=128000,
    output_config={
        "effort": "high",
        "task_budget": {"type": "tokens", "total": 64000},
    },
    betas=["task-budgets-2026-03-13"],
    messages=[...],
    tools=[...],
) as stream:
    response = stream.get_final_message()

このコードのポイントは、task_budget が「モデルに見せる予算」で、max_tokens が「強制的な打ち切り」だという違いです。予算を渡しておくと、Fable 5 は途中で切られるのではなく、残りトークンを見ながら自分でペース配分してくれます。

パターン5：非同期サブエージェントで速く・賢く 🚀

Fable 5 は、非同期に動くサブエージェントの扱いが得意です。指揮役が待ちに入らず、複数のワーカーを並行で走らせ、必要に応じて途中でやり取りできます。

以下の図は、同期（1体ずつ待つ）と非同期（並行で走らせる）の違いを示しています。

この図のポイントは、非同期だと指揮役が最も遅いワーカーに引きずられない点です。第三者集計では、マルチエージェント構成が単一エージェントを Pareto 支配した（精度とレイテンシが同時に良くなった）と報告されています。エージェントを 3体 / 5体 / 10体に増やすと、単一エージェント比で 2.2倍 / 2.7倍 / 2.7倍の高速化が得られた一方、トークンコストは増えます。

コーディングでも、マルチエージェント版 ProgramBench で 5体チームが単一より 7.9点高く、隠しテスト60%通過を約3.2倍速く達成したという結果があります。各エージェントは自分の Git チェックアウトで作業し、コードは Git 経由で共有する形です。

ここは「速さのためにトークンを足す」トレードオフなので、コスト最優先なら並列数を絞り、レイテンシ最優先なら増やす、という判断になります。

他LLMとのベンチマーク比較 📊

コスト効率の話をする前提として、Fable 5 が「そもそもどれくらい強いのか」も見ておきます。コーディング系のベンチマークで、他モデルと並べます。

繰り返しになりますが、以下の数値はベンダー公称値・第三者集計の寄せ集めで、同一ハーネス・同一日付の再実行ではありません。とくに SWE-bench Pro の Fable 5 スコアは Anthropic 自社スキャフォールディングによる公称値で、独立評価者の間では数値が割れている（論争がある）点に注意してください。

ベンチマーク	Fable 5	Opus 4.8	Sonnet 5	GPT-5.5	Gemini 3.1 Pro
SWE-bench Verified	95.0	88.6	—	88.7	—
SWE-bench Pro	80.3	69.2	63.2	58.6	54.2
GDPval-AA（知識労働）	1,932	1,615	1,618	—	—

（出典: Anthropic 公式・各社公称値をもとにした第三者集計 [morphllm / Vellum / claude5.ai] ほか。同一環境での再実行値ではありません）

この表から読み取れるのは、Fable 5 が確かに最上位の数字を出している、という点です。SWE-bench Verified は 95.0% と独立確認されたとする集計もあり、実務的なコード修正では頭一つ抜けています。ただし SWE-bench Pro の 80.3% は公称値で論争があり、実運用では Opus 4.8（69.2）でも十分に強いことは押さえておくべきです。

ここでコストの視点が効いてきます。ベンチマークの絶対値だけを見ると Fable 5 が魅力的ですが、「その差は自分のタスクで $10/$50 を払う価値があるか」を毎回問う必要があります。多くの定型作業では、Sonnet 5 や Opus 4.8 で品質は足り、差額のほうが大きい、というのが本記事の立場です。

価格 💰

モデル別の価格を、あらためて整理します。

モデル	入力（per 1M）	出力（per 1M）	位置づけ
Fable 5	$10	$50	最上位。難所の判断・長期エージェント
Opus 4.8	$5	$25	高性能ワーカー。難しい実装
Sonnet 5	$3（導入 $2）	$15（導入 $10）	主力ワーカー。定型・大量処理
Haiku 4.5	$1	$5	軽作業ワーカー。分類・単純処理

Fable 5 の出力 $50 は、Haiku 4.5 の出力 $5 のちょうど10倍です。つまり、出力トークンを大量に吐く作業（コード全文の生成、長い文章の整形など）ほど、安いモデルに肩代わりさせる旨味が大きくなります。

コスト効率ハーネスの効き目を、先ほどの BrowseComp の実測でもう一度見ておきます。

構成	精度	1問あたりコスト	Fable 単独比
Fable 5 単独	90.8%	$40.56	1x
Fable + Sonnet ワーカー	86.8%	$18.53	約 0.46x
Sonnet Executor + Fable Advisor（SWE-bench Pro）	Fable の約92%	—	約 0.63x

数字が示すのは、ハーネスの組み方しだいで「性能の9割前後を、半分〜6割の値段で」出せるということです。フロンティア知能を全面に張るのではなく、要所に差す。この一手でコストの桁が変わります。

refusal とフォールバック：コスト面の注意 ⚠️

最後に、Fable 5 特有の運用上の注意を1つ挙げておきます。Fable 5 は安全分類器を持っていて、研究バイオや高リスクなサイバー領域に近いリクエストを拒否することがあります。拒否はエラーではなく、stop_reason: "refusal" を含む HTTP 200 として返ります。

フォールバックはオプトインです。何もしなければ拒否でそのまま止まります。新規コードでは、サーバー側の fallbacks パラメータ（beta server-side-fallback-2026-06-01、フォールバック先 claude-opus-4-8）を既定で入れておくのが推奨です。拒否されたリクエストが同じ呼び出しの中で Opus 4.8 に再実行され、課金も適切に付け替えられます。

response = client.beta.messages.create(
    model="claude-fable-5",
    max_tokens=16000,
    betas=["server-side-fallback-2026-06-01"],
    fallbacks=[{"model": "claude-opus-4-8"}],
    messages=[{"role": "user", "content": "..."}],
)

このコードのポイントは、出力前の拒否は課金されず、フォールバックした分は Opus 4.8 の単価で課金される点です。安全な業務が誤検知で止まるのを防ぎつつ、コストも読める形になります。response.content[0] をいきなり読むと拒否時にインデックスエラーで落ちるので、stop_reason を先にチェックする処理は入れておきましょう。

まとめ

この記事で一番大切なことは、「Fable 5 の知能は、判断が難しいところにだけ差す」という一点です。全タスクを $10/$50 のモデルに通すのではなく、計画と統合は Fable 5、実作業は安いモデル、という分業に切り替えるだけで、多くのワークロードは品質を保ったままコストが半分以下になります。

手を動かす順番としては、まずオーケストレーター/ワーカー分業を試すのが効果が大きいです。次に、1リクエスト内で細かく効かせたいなら Advisor ツール。そこに effort の使い分け、プロンプトキャッシュ、コンテキスト編集、Task Budget を重ねると、さらに削れます。速さが欲しい局面では非同期サブエージェントでトークンと引き換えにレイテンシを買う。

最後に注意点です。本記事のベンチマークとコストの実測値は第三者集計で、SWE-bench Pro のように数値が割れているものもあります。最終的には、自分のタスクで Fable 5 と安いモデルを実際に回し、精度・トークン・レイテンシを測ってから構成を決めるのが、いちばん確実です。まずは1つのワークフローで「Fable 単独」と「オーケストレーター構成」を並べて計測してみてください。

参考

Lance Martin（@RLanceMartin）の X 投稿 — Fable 5 の性能 × コスト計測の一連の投稿
Fable 5 as Orchestrator, Sonnet as Executor（Data Science Dojo）
Fable 5 Advisor & Orchestrator — Cost Patterns（explainX）
Claude Benchmarks 2026（morphllm）
Claude Fable 5 & Mythos 5 Benchmarks（Vellum）