Claude Fable 5は高すぎる？コストを3分の1にする賢い使い方

2026年6月9日、AnthropicはOpusの上位に位置する新たな最上位ティアのAIモデル「Claude Fable 5」を公開した。APIで使う場合の価格は入力$10／出力$50（100万トークンあたり）で、Opus 4.8のちょうど2倍である。

その性能は米国の著名な技術者も「化け物（a beast）」と評するレベルだ。

しかしながら、常用するにはコストが高すぎて、あっという間にクレジットを溶かしてしまう。おそらく、Fable 5に全工程を任せる運用は、コストが高すぎて多くの企業や個人開発者にとって（当面の間は）持続的ではなさそうだ。

Fable 5 を実際の開発ワークフローに投入するには、トークン数を節約するテクニックが特に重要になる。

例えば、通常のコードは安いモデル（Opus／Sonnet／Haiku）に書かせ、Fable 5に全体のオーケストレーションと最後の監査を任せるような手法。

あるいは、Claude Codeのサブエージェント機能を最大限に活用し、サブエージェントの司令塔としてFable 5を、タスク難易度に応じてOpus, Sonnet, Haikuのサブエージェントをスポーンするような手法が考えられる。

本記事では、Fable 5のベンチマーク等の速報的な紹介は最小限にとどめ、「実務でどう使い分けるか」に焦点を当てる。

Fable 5の特徴：圧倒的なベンチマークスコアの飛躍

Fable 5は、ソフトウェアエンジニアリング系ベンチマークでOpus 4.8を明確に上回っている。なお、以下の数値はすべてAnthropicの自己申告値である点には留意してほしい。

SWE-bench Verifiedの95.0%も目を引くが、このベンチマークはすでに天井に近く、実質的な伸びを示すのは、より難しいSWE-bench ProでのOpus 4.8比＋10.8ポイントであろう。

プログラミングの難問を集めたFrontierCodeでは首位に立ち、知識労働の総合力をチェスのレートのように相対評価するGDPval-AAでも1932を記録し、Opus 4.8（1890）を引き離して首位である。

公式発表の中には、「タスクが長く複雑になるほど、Fable 5のリードは大きくなる」という一文もある。

こうしたFable 5の性能向上の恩恵が最大化するのは、軽い作業の量産よりも、最も難しく長いタスクに投入したときに顕在化する、というわけだ。

「Mythos 5」と「Fable 5」の違い：セーフガードとフォールバック

今回のリリースには、同じパラメータのモデルが2つの名前で提供されているという特徴もある。

一般公開されたのが今回の「Fable 5」だが、これは「Mythos 5」の「機能制限版」だ。

Mythos 5は、あまりに性能が良く、サイバー攻撃や生物兵器の観点などから危険性があると判断され、サイバー防衛組織などに限定提供されている。

Fable 5には、危険な3分野（サイバー攻撃／生物・化学／モデル能力の抽出）を検知する分類器が組み込まれており、該当するとOpus 4.8での応答に切り替わる。セーフガードによって用途制限されている、ということだ。

公式発表によれば、95%超のセッションではこのOpus 4.8へのフォールバックは発生しないらしい。

とはいえ、5%程度のセッションで、いつの間にか性能の低いモデルに切り替わってしまう、ということには留意が必要だ。

もし、サイバーセキュリティ関連の用途でFable 5を使用する場合、このデメリットは無視できない。サイバー系ベンチマークの高スコア（例：Terminal-Bench 2.1の88.0%）は制限版Mythos 5の数字であり、一般利用できるFable 5では試行の20.9%がセーフガードに該当してOpus 4.8相当に落ちると指摘しているメディアもある。

業務利用上の注意：安全のための制約が複数追加

業務でFable 5を使うなら、次の3点だけは押さえておきたい。

1. 入力データは30日間保持される

Fable 5に渡したデータは、安全対策のため30日間保持される。API・Claudeアプリだけでなく、Amazon Bedrock等のサードパーティ経由も含む全トラフィックが対象で、ゼロデータ保持（ZDR）契約も適用されない。

モデルトレーニングに使われることはないとのことだが、機密コードや顧客データを扱う前に、社内ポリシーとの整合を確認しておきたい。

2. フォールバック方法は、アプリとAPIで異なる

Claudeアプリでは、セーフガードに該当すると通知なくOpus 4.8に切り替わる。

一方APIでは、自動では切り替わらず回答そのものが拒否される（Opus 4.8への自動フォールバックはオプトイン設定が必要）。

「自社のセキュリティ監査を頼んだらサイバー判定でOpusに切り替わる」ということがあり得るので、セキュリティ関連の用途では上記の仕様を理解しておく必要がある。

3. ごく一部のリクエストには「見えない介入」がある

公式の技術文書（system card）には、AIモデル開発に関わる一部の高度なリクエストに対し、ユーザーに通知しないまま出力を調整する場合があると記載されている。

モデルが静かに回答品質を落としうる設計であり、対象は推定0.03%のトラフィックと極めて限定的だが、該当しうる分野（AI基盤開発など）の組織は知っておくべき事実だ。

「全部Fable運用」は多分ムリ：安いモデルを上手に使え

現実的なFable 5の運用コストと、Claude系モデルの使い分けについて検討してみよう。

単価2倍より怖い、「推論ヘビー」な実効コスト

まずClaudeの各モデルのAPI価格を整理する。100万トークンあたりの入出力コストは以下の通りだ。

「出力100万トークン」がどの程度の量なのか、体感値も添えておくと、日本語なら文庫本10冊分ほどのテキスト量をClaudeに書かせると約7,500円、というイメージだ。

ただし、100万トークン単価を単純比較して、Opus 4.8の2倍、と考えるのは正しくない。

Fable 5は、難しいタスクでより長く考え、複数の可能性を検討しながら回答する。したがって、同じ質問であっても、内部の推論や試行錯誤により多くのトークンを使う”reasoning-heavy”なモデルなのだ。

2倍の単価のモデルが、より多くのトークンを消費して考えるのだから、1タスクあたりの実効コストは、単価差の2倍よりもずっと大きくなる可能性がある。

実際、公開初日からRedditでは「Max 20xプラン（Claudeの最上位サブスクリプション）の利用枠が1分あたり約2%のペースで溶けていく」「Opus 4.8では同じ作業で上限に近づくことすらなかった」という報告が相次いだ。

普段は安いモデルを使い、本当に重要なときだけFableを使う、というコストを意識したルーティングが、多くの開発者にとっての「必須テクニック」になっていくのだろう。

現実的な運用は2パターン：「Fable司令塔」と「Fable監査役」

そこで考えたいのが、Fable 5の登場場面を一部の高難度な判断に絞り込む、2つの運用パターンである。

パターンA：Fable司令塔型（Fable 5 × サブエージェント）

メインセッションをFable 5にして、実作業はOpus／Sonnet／Haikuのサブエージェントに振っていく形だ。Fableは計画・タスク分解・委任・結果の統合という「司令塔」に徹し、トークンを大量に消費する調査やコード生成は安いモデルが担当する。

Fable 5の強みである「長く複雑なタスクでの判断力」を工程全体に効かせながら、トークン消費の大部分を安い単価に寄せられる。

Claude Codeのサブエージェント機能を使えば、この分業は自然に構築できる（実装方法は後述）。

パターンB：Fable監査役型（Fable Check）

逆に、メインセッションをOpusなどの安価なモデルにして、難易度の高い実作業をFable 5に振ることも考えられる。

どちらがパフォーマンスが良いか／コスト効率が良いかは、自分のプロジェクトの複雑さ・フェーズなど相性によるので、両運用を実際に試してみることを勧める。

1. 調査・実装: Haiku・Sonnet・Opusで分担する。コードベースの探索はHaiku、コードを書くのはSonnet、設計判断が絡む難所の実装はOpusが基本
2. 機械的な検証: テスト・lint・型チェックを通す（依存関係の脆弱性スキャンやマイグレーションのdry-runもここに含む）。機械で確認できることにLLMを使わない
3. Fableによる最終監査: テストを通過した変更だけをFable 5がレビューする
4. 指摘の仕分け: 指摘を重大度（High／Medium／Low）で分類する
5. 修正: 修正作業はSonnetに戻す（設計に関わる難しい修正はOpus）。Fableに手を動かさせない
6. 再確認: Highの指摘を修正した場合など、必要なときだけFableで再監査する

こちらのFableは手を動かす担当ではなく、最後に品質バーを越えているかを確認する担当である。

使い分けの目安

設計判断が多く、複数ファイル・複数領域にまたがる難しいタスクは、判断ミスのやり直しコストが高いのでパターンA（司令塔）が向く。

やることが明確で、実装量が支配的な日常の開発はパターンB（監査役）で十分だ。

どちらを選ぶにせよ、コスト効率を決めるのは「Fableの出番をどれだけ濃い判断に絞れるか」である。

この発想はコードに限らない。設計ドキュメントのレビュー、DB移行計画の妥当性チェック、障害報告書の論理検証など、「生成は安く、判断と最終確認だけ高く」が成立する知的作業全般に応用できる。

実装：Claude CodeでFableを「司令塔」「監査役」にする

ここからは、実際にClaude Codeで、Fableを軸とした開発のワークフローを実装してみる。

監査役型（パターンB）→司令塔型（パターンA）の順に構築し、最後にAPIを直接使うルートも示す。

監査役と統括役を組み合わせれば、「Fableが計画し、安いモデルが作り、仕上げにまっさらなコンテキストのFableが最終確認する」という分業がClaude Code内で完結する。

最短コース：生成はSonnet、PR前のレビューだけFable

最初の一歩は、設定変更も不要で、ユーザー自身の心がけだけで導入できる方法だ。

• 普段の実装はSonnetやOpusで行う
• Fable 5を呼ぶのは、プラン作成時・PR作成前・設計変更前・本番に影響する変更前の重要シーンに限定する
• Fableにはコードを書き換えさせず、指摘だけをさせる

まずは「PR前に1回だけFable Check」が現実的な導入ラインである。

これだけでも、最終確認の品質はFable 5水準になり、コストの大半はSonnet / Opusの単価で済む。

こうしたワークフローを、もっとシステマチックに行いたいなら、以下の（事前定義した）サブエージェント活用方式が良い。

監査役パターン：監査専用サブエージェントを定義する

Claude Codeでは、サブエージェントをMarkdownファイル＋YAMLフロントマターで事前に定義でき、modelフィールドにsonnet／opus／haiku／fableといったエイリアスを指定できる。

これを使えば、Fableによる監査を「仕組み」にできる。

プロジェクトの.claude/agents/code-reviewer.mdに以下を保存すれば、いつでも呼び出せる監査専用サブエージェントが手に入る。

1
---
2
name: code-reviewer
3
description: Expert code reviewer. Use proactively after writing or modifying code.
4
model: fable
5
tools: Read, Grep, Glob, Bash
6
---
7

8
あなたはシニアコードレビュアーである。まず git diff で変更点を確認し、
9
変更されたコードの品質・セキュリティ・保守性を分析して、重大度順に
10
具体的な修正案を提示する。コードを書き換えてはならない。指摘のみを行うこと。

ツール制限によって、Fableのトークンを節約するようにしているのがポイントだ。

toolsはホワイトリスト方式（列挙したツールしか使えない）のフィールドで、WriteやEditといったファイル編集ツールを含めなければ、ファイル編集権限を持たないエージェントを作れる。

「監査役は実装作業はしない」というルールを、プロンプトでのお願いではなく、ツール権限で厳格に縛ることが可能となる。

司令塔パターン：Fable起点で安いサブエージェントに作業を振る

また、向きを逆にして、メインセッションをFable 5にして、実作業を担うサブエージェントに安いモデルを使う、という「司令塔型」も役立つ。

ちなみにサブエージェントは、プロンプト内で「Opusのサブエージェントで修正して」などと言うだけでも使えるが、毎回打ち込むのが面倒なら、事前に.claude/agents内で定義してしまった方が楽だ。

.claude/agents/に、たとえば次の2つを用意する。コンテキスト消費が激しいタスク用に、明示的にHaikuやSonnetを使うサブエージェントを定義しておく。

1
---
2
name: explorer
3
description: コードベースの調査・ファイル探索・既存実装の確認を担当。Use PROACTIVELY for codebase exploration and research.
4
model: haiku
5
tools: Read, Grep, Glob, Bash
6
---
7

8
あなたはコードベース調査の専門家である。指示された調査を実行し、
9
関連ファイルのパス・該当箇所・要点だけを簡潔に報告する。

1
---
2
name: implementer
3
description: 指示された実装・リファクタリング・テスト作成を担当。Use for all code writing tasks.
4
model: sonnet
5
---
6

7
あなたは実装担当のエンジニアである。指示された変更を最小限の差分で
8
実装し、変更したファイルと変更内容を報告する。

そのうえで、プロジェクトのCLAUDE.md（Claude Codeが毎セッション読み込むプロジェクト方針ファイル）に委任の方針を書いておく。Fable本人に「自分で手を動かすな」と教え込む、司令塔型の肝となるテンプレートだ。

1
## モデル運用方針
2

3
- メインセッションは計画・タスク分解・委任・結果の検証・最終判断に専念する
4
- コードベースの調査・ファイル探索は explorer サブエージェントに委任する
5
- コードの実装・リファクタリング・テスト作成は implementer サブエージェントに委任する
6
- 独立した作業は、同一ターンで複数のサブエージェントを並列起動して進める
7
- サブエージェントの報告を鵜呑みにせず、重要な変更は差分を直接確認する
8
- メインセッションは自分でファイルを大量に読み込まない（コンテキストを温存する）

この構成にすると、トークン消費の大部分を占めるファイルの読み込みと実装の出力が、Haiku／Sonnet単価で処理される。

また、サブエージェントはそれぞれ独立したコンテキストで動くため、メインのFableのコンテキストが調査結果やファイル内容で膨らまない。

Fableは入力単価も1Mトークンで$10と高いので、毎ターン再送されるコンテキストによってどんどんコストが膨らむ。メインセッションで保持するコンテキストを削減することは、コストカット効果が大きい。

実装：APIでFableの”advisor tool”を使ってみる

Claude Codeではなく、APIを直接使う場合には、「Advisor tool」（ベータ）という方法もある。

安い主モデル（Sonnetなど）との会話コンテキストを保ったまま、重要な場面だけ別モデル（Fableなど）を呼び出して、助言を得られるAPIの機能だ。

1
response = client.beta.messages.create(
2
    model="claude-sonnet-4-6",   # 主モデルは安いSonnet
3
    max_tokens=16000,
4
    betas=["advisor-tool-2026-03-01"],
5
    tools=[{
6
        "type": "advisor_20260301",
7
        "name": "advisor",
8
        "model": "claude-fable-5",  # 重要な判断だけFableに相談
9
        "max_uses": 2,              # 呼びすぎ防止
10
    }],
11
    messages=[{"role": "user", "content": "..."}],
12
)

主処理はSonnetが進め、設計判断や最終確認などの重要な場面でだけFable 5の意見を聞く。「主処理は安いモデル、重要判断だけFable」という設計思想を、Claude Code抜きでAPIレベルに実装できる。

max_usesの指定も実務では重要だ。Fableの呼び出し回数に上限を設けられるため、エージェントが相談を繰り返して高額請求になる事故を仕組みで防げる。

Fable 5 と他モデルの組み合わせによるコスト削減効果の試算

全てのタスクをFableで完結させた場合と、Opus / Sonnet と分業した場合で、どの程度のコスト差が生じるのか。具体的な仮定を置いて概算してみる。

中規模の機能実装1件で、次の2つを仮定する。

• 全体の作業量: 入力400万／出力60万トークン。中規模リポジトリで数十ファイルを読み込ませながら、実装と修正を何往復かするイメージ
• うち最終レビュー部分（最終レビュー1回）: 入力15万／出力1万トークン

この前提で、モデルの組み合わせによるAPI価格を比較すると以下のようになる。 （Claude Maxプランなど定額利用の場合、1週間あたり／数時間あたりのクレジット消化量の消費スピードのイメージの参考としてほしい）

計算式はシンプルで、生成工程＝「4M×入力単価＋0.6M×出力単価」、Fable監査＝「0.15M×$10＋0.01M×$50≒$2」である。

なお、この試算は、Fable 5になっても思考トークン量が増えないことを前提とした見積もりであり、実際の差はさらに大きくなるだろう。同じリポジトリで同じ作業をしても、Fable 5の方が、Opus / Sonnetより長く思考するからだ。

Claude Codeのようなエージェント運用では、全てのコンテキストが会話のラリーの都度送信されるので、Fableを会話に参加させる回数がそのままコストに跳ね返ってくる。

Claudeの設定を開き「Usage」の項を見ると、数時間ごとの制限、1週間ごとの制限の何%を消化したかをチェックできる。

これをこまめに見ながら、自分の日々の開発量と、クレジットの消化量を検証し、「Fableの投入量」のベストミックスを自分なりに見つけるのが大切だ。

Fable 5時代はサブエージェントの調教が必修科目に

Fable 5時代のモデル選びで重要なのは、「一番賢いモデルを常に使う」ことではない。

手を動かす作業は「品質バーを越えられる最も安いモデル」に任せ、Fable 5は計画・判断・最終確認といった、失敗できない頭脳労働にだけ投入することだ。

これまでは、Claude Maxプランの20x, 5xを使っていれば、それほどクレジット消化量を意識しなくても、「全部Opus 4.8でやっちゃう」といった使い方が可能だった。

しかし、Fable 5は、明らかにクレジット消化スピードが早いので、コスト意識とタスクの難度に応じたモデル間のルーティングが、多くの開発者にとって不可欠なスキルになりそうだ。

記事執筆現在（6月11日）は、6月23日以降に、Fable 5がどのような利用料金体系で提供されるか不明だが、できればClaude Maxプランの使用量に含めてもらいたいところだ。

筆者は、当面の間は、メインセッションをFableにしておきつつも、CLAUDE.mdにOpusやSonnetへ積極的に委任すべしとの指示を記載しておく、と言う使い方に落ち着きそうだ。