Claude Opus 5 vs Claude Fable 5：Fable に2倍の料金を払う価値はある？
$5 / $25 で公開し、コーディング、PC操作、knowledge workの複数評価でFable 5を上回る、または近づく結果を示しました。一方、Fable 5は引き続き、広く提供されるClaudeの中で最高能力のモデルと位置づけられています。Claude Opus 5 vs Fable 5早見表
| 判断軸 | Claude Opus 5 | Claude Fable 5 | 本番への意味 |
|---|---|---|---|
| 位置づけ | 複雑なagentic coding向けの日常プレミアム | 広く提供されるClaudeの最高能力 | Opusから始め、価値がある時だけFableへ |
| 公式単価 | $5 / $25 per MTok | $10 / $50 per MTok | FableはToken単価2倍 |
| Context / 最大出力 | 1M / 128K | 1M / 128K | 容量だけでは差がない |
| 相対レイテンシ | Moderate | Slower | 対話型の標準はOpusが安全 |
| Thinking | Adaptiveが既定、high以下なら無効化可能 | Adaptiveが常時オン | Opusの方が低推論タスクを制御しやすい |
| 公開証拠 | Coding、automation、problem solvingで強いローンチ結果 | Anthropicの能力上限として残る | 個別benchmarkは実タスク評価の代わりにならない |
| 安全制御 / 保持 | AnthropicはFableよりclassifier介入が少ないと説明。一般アクセスの保持要件なし | 追加classifier、30日保持、ZDRなし | ガバナンスが性能より先にルートを決める場合がある |
最初はOpus 5。検証失敗、低い確信度、または非常に高価値なタスクだけFable 5へ上げます。
Claudeアプリ、Coding agent、APIを分けて考える
「Opus 5かFable 5か」には、実際には3つの異なる判断があります。
| 利用面 | 本当の判断 | 開始点 |
|---|---|---|
| Claudeアプリ | 単発の会話や難問で選ぶモデル | まずOpus。コストより最大能力を優先する時だけFable |
| Claude Codeなどのcoding agent | 計画、実装、デバッグ、レビューの分担 | 実行はOpus。測定済みのescalation、計画、レビューだけFable |
| API / agent platform | Default、予算、監視、rollbackの設計 | 1モデル固定ではなくタスク群でrouting |
本稿の中心は本番APIとagentチームです。アプリ内の選択肢やサブスクリプション枠は変わるため、本番architectureの根拠にはしません。
Opus 5がFableの価値判断を変えた理由
Anthropicによると、Opus 5はCursorBench 3.2のmax effortでFable 5のピークから0.5ポイント以内に入り、タスク当たりコストは約半分です。OSWorld 2.0ではFableの最高結果を約3分の1強のコストで超え、Frontier-Bench v0.1でも首位です。
| 証拠 | 支持できる判断 | 証明できないこと |
|---|---|---|
| Anthropic Frontier-Bench / CursorBench | 特定coding harnessでOpusが同等以上になり得る | 全リポジトリ、全tool stackで勝つ |
| Anthropic OSWorld 2.0 | 試験対象のPC操作で費用効率が高い | 全エージェントで速く安い |
ARC Prize：highでARC-AGI-3 30.16% | 7月24日時点の検証済み最高値 | Fableとの直接比較。公開表にFable値はない |
| Anthropicモデル一覧 | Fableは最高能力ルート | 最高tierが最適default |
つまり証明責任が逆転しました。今後はFableが、割り当てられる各タスク群で増分価値を示す必要があります。
本番判断に影響する仕様
| 項目 | Claude Opus 5 | Claude Fable 5 | Routingへの意味 |
|---|---|---|---|
| Anthropicの位置づけ | 複雑なagentic codingと企業業務の開始モデル | 広く提供される中で最高能力 | まずOpusを検証 |
| 公式Token単価 | Input $5 / Output $25 per MTok | Input $10 / Output $50 per MTok | Fableは最初から2倍 |
| Context / 最大出力 | 1M / 128K Token | 1M / 128K Token | 上限は同じ。長いtraceでの信頼性は別評価 |
| Reliable knowledge cutoff | 2026年5月 | 2026年1月 | 新しい開発知識はOpusが有利な可能性 |
| 相対latency | Moderate | Slower | 対話型ループはOpusから |
| Thinking / effort | Adaptive既定、low〜max | Adaptive常時、effort制御 | 同じeffortで比較する |
| 公開保持条件 | 一般アクセス固有の条件なし | 30日保持、ZDRなし | 品質評価前にガバナンスで除外される場合 |
新しいcutoffはrepoの事実、retrieval、外部検証を代替しません。また1M contextが同じでも、長いtrace中の制約を見つけて守る性能が同じとは限りません。
Opus 5を標準にするワークロード
リポジトリ規模の実装・デバッグ・レビュー、ツールやsubagentを使う長時間エージェント、ブラウザ自動化、金融・法務・研究分析、レイテンシも重要なlong context、高い判断力が必要だが全呼び出しでFable料金を払えないトラフィックはOpus 5から始めます。
lowからmaxのeffortにより複数のプレミアムレーンを設計できます。highから開始し、採用率を保てる場所だけ下げ、xhigh/maxは難問に限定します。失敗したlowとretryは、一度で成功するhighより高くなることがあります。Fable 5が依然として価値を出せる場面
数時間・数日のエージェント、分解が難しいfrontier research、強いOpus試行でも未解決の計画、高価値成果物の独立二次レビュー、replayでFableの採用率が明確に高いタスク群にはFableを残します。
「難しい」だけではルールになりません。検証失敗、低確信度、収束しないtool loop、異常に高いタスク価値、過去に測定したFable優位をシグナルにします。
Codingとagent作業の分担
| ワークロード | 推奨default | Fableを試す条件 | 主な指標 |
|---|---|---|---|
| Repo規模の実装 | Opus 5 | Test失敗が続く、architecture再設計が必要 | Test合格、修正回数、scope外変更 |
| Bug原因分析 | Opus 5 | 仮説が繰り返し崩れる | 最初の正しいroot cause、回帰 |
| Code review | Opus 5 | 高リスクmergeで独立レビューが必要 | True/false positive、人手時間 |
| Multi-agent計画 | Opus 5 | 長いtraceが繰り返し逸脱 | Replan、subtask競合、状態喪失 |
| Subtask実行 | Opusまたは低価格route | 検証可能な失敗後のみ | 採用subtask単価、retry率 |
| Browser / computer use | Opus 5 | 重要stepが復旧できない | 完了率、復旧率、操作数 |
| 長文research | Opus 5 | 高価値成果に独立反証が必要 | Citation精度、欠落、確認時間 |
初期のコミュニティ報告には、計画・難しい調査・最終レビューをFable、実装とtool実行をOpusにする案があります。ただしこれは評価すべき仮説で、確立済みの普遍動作ではありません。
2倍の表ではなく採用タスク単価を測る
| モデル | Input | Output | 5分Cache Write | Cache Read |
|---|---|---|---|---|
| Claude Opus 5 | $5 / MTok | $25 / MTok | $6.25 / MTok | $0.50 / MTok |
| Claude Fable 5 | $10 / MTok | $50 / MTok | $12.50 / MTok | $1 / MTok |
採用タスク単価 =
input + cache write + cache read + output
+ retry + fallback + 人手レビュー
/ 採用成果数C、Fable 1回を2Cとします。採用タスク当たりモデル費 = 1回の費用 ÷ 初回採用率
Fableがモデル費だけで有利になる条件：
Fable採用率 ÷ Opus採用率 > Fable費用 ÷ Opus費用
つまり：Fable採用率 > 2 × Opus採用率| シナリオ | Opus採用率 | Fable採用率 | Opus採用成果単価 | Fable採用成果単価 | 結果 |
|---|---|---|---|---|---|
| 大量実装 | 80% | 90% | 1.25C | 2.22C | Fableは約78%高い |
| 難しいdebug | 60% | 90% | 1.67C | 2.22C | Fableは約33%高い |
| Opusが不安定な狭い群 | 45% | 95% | 2.22C | 2.11C | Fableがわずかに安くなる |
実際にはthinking、output、tool call量が異なります。それでもOpusの採用率が50%を超えると、Fableの小さな改善だけで2倍単価を回収するのは困難です。Retry、人手時間、失敗損失を大きく減らす群なら、Fableが総費用で勝つ可能性はあります。
EvoLinkのルート価格はAnthropicの定価と異なる場合があります。本番予算にはモデルページのライブ料金を使ってください。
Safeguards、データ保持、fallback
AnthropicはFable 5に追加classifierと拒否動作、30日保持、Zero Data Retention非対応を記載しています。Opus 5についてはclassifier介入がFableより約85%少ない見込みで、一般アクセスに保持要件はないと説明しています。
これはチャネル固有の事実です。契約、地域、実際のルートを確認し、自動fallbackではrequested modelとreturned modelを別々に記録してください。
| 項目 | 必要な理由 |
|---|---|
| Requested model | Userまたはrouterの最初の選択を残す |
| Served model | 実際に結果を生成したmodelを特定する |
| Effortとoutput budget | 2つのcallが比較可能か確認する |
| Refusalとclassifier | Policy拒否と品質失敗を分ける |
| Fallback理由とchain | Routeが変わった場所と理由を説明する |
| 各段階のTokenとlatency | 完全な経路費用を計算する |
| 最終採用結果 | 「出力がある」を成功として数えない |
データガバナンスは品質評価より先にFableを除外する場合があります。Provider条件を、実際に使うgateway、region、契約へ対応づけてください。
推奨する本番ルーティング
| ワークロード | Default | Escalation | Fallback |
|---|---|---|---|
| 定型抽出 | Sonnetまたは検証済み低価格route | 検証失敗後にOpus | 既存fast route |
| 難しいcoding | 測定済みeffortのOpus 5 | 失敗/低確信度でFable | Opus 4.8等 |
| 長時間agent | Opus 5 | frontier traceをFableへ | checkpointから再開 |
| 高価値分析 | Opus + evidence check | Fable独立二次評価 | 人手レビュー |
| policy-sensitive | 承認済みroute | 承認済みのみ | 明示的な拒否処理 |
EvoLinkではモデル選択をルーティング層に置きます。1つのclientとAPI keyでdefault、escalation、fallback、rollbackを管理できます。
Opusのみ
自動test、構造化validation、安定した人手rubricでOpusが採用基準を満たす時に使います。別のpremium modelを追加する前にeffortを調整します。
Opus標準、検証失敗後にFable
Failed test、invalid tool、同じloopの反復、明示的な低確信度、またはFable優位を測定済みのタスク群をtriggerにします。1タスク当たりのFable呼び出し数を制限し、人手確認の境界を残します。
Fableで計画・レビュー、Opusで実行
Fableには短い計画、architecture判断、独立reviewだけを依頼し、必要最小限のcontextをOpusへ渡します。追加latencyと重複Tokenを含めても再作業が減るかを測ります。
2つの独立出力
不一致自体が有用な領域に限定します。Review時はmodel名を隠し、裁定rubricを先に定義します。2モデルの一致を正しさの証明にしてはいけません。
EvoLinkでClaude Opus 5を評価する公平な評価とロールアウト
- 成功例、高価な失敗、frontierケースを含む50〜200件を用意する。
- tools、権限、repo、context、timeout、retryを一致させる。
- model ID、effort、出力予算、latency、token、tool妥当性、拒否、fallback、レビュー時間を記録する。
- 正確性、scope、完了度、修正量をblind評価する。
- ワークロード別に採用タスク単価を算出する。
- 基準を満たす群だけOpusをdefaultにする。
- 増分価値がpremiumを超える群だけFableへ上げる。
- 実トラフィック検証まで旧routeを残す。
最低限、次を保存します。
task_id, task_class
requested_model, served_model, effort
input / cache-write / cache-read / output tokens
latency, tool calls, invalid tool calls
refusal, fallback chain
automatic checks, blind human score
repair minutes, accepted全体平均だけでなくワークロード群ごとに結果を公開します。全体で負けるモデルでも、狭いproduction laneに価値を持つことがあります。
FableトラフィックをOpusへ安全に移行する
| 段階 | 実施内容 | 次へ進む条件 |
|---|---|---|
| 1. Historical replay | 成功、高価な失敗、長いtrace、frontierを50〜200件用意 | 実際のtools、context、権限、採用基準を含む |
| 2. Matched test | Tools、timeout、retry、effort、output budgetを同じにする | タスク群ごとに比較できる |
| 3. Shadow | Fable運用と並行してOpusをuser path外で実行 | Safety、format、toolのblockerがない |
| 4. Canary | 適格なタスク群の10%〜25%をOpusへ | 採用率、review、p95が制限内 |
| 5. Workload拡大 | 合格したタスク群だけ拡大 | 採用タスク単価が旧routeより良い |
| 6. Escalation / rollback | Fable優位が証明された群を残す | 各群を旧policyへ戻せる |
Replay前に門を決めます。初回採用率を大きく下げない、invalid toolを増やさない、retryと修正時間がToken削減を打ち消さない、p95を守る、refusalとfallbackを帰属できる、高価値な失敗を平均値に隠さない、という条件が必要です。
最初の成功batchだけでFable routeを削除しないでください。目標は一方向の移行ではなく、version管理された可逆policyです。
チーム別の開始案と未確定事項
| チーム | 開始policy | 理由 |
|---|---|---|
| 小規模product team | Opusのみ、Fableは手動escalation | 運用を単純にしつつ緊急経路を残す |
| Coding-agent platform | Opus default、タスク群別Fable | Routingとobservabilityが中核機能 |
| 企業knowledge workflow | Opus、選択的Fable二次review | 人手とガバナンスがbenchmark順位より重要 |
| 高リスクresearch | 少数だけ独立二重review | 不一致と監査性が追加費用を正当化 |
| 大量automation | Fable前にOpusまたは低価格route | 自動validationでretryが安い |
ローンチ直後は、同じeffortで比較した独立証拠がまだ限られます。初期報告はprompt、harness、subscription surfaceが異なり、provider availabilityやlatencyも変化します。対応した独立評価、保持規則、または自社のworkload構成が変わった時にpolicyを見直します。
数枚のgraphで万能の勝者を決める、retryとreviewを費用から外す、一方だけに多くのtoolを与える、fallback回答をFable成果として数える、といった評価は避けてください。
最終推奨
低価格route -> Opus 5 default -> Fable 5 escalation
\-> 検証済みfallbackとrollback情報源
- Anthropic: Introducing Claude Opus 5
- Anthropic: What's new in Claude Opus 5
- Anthropic: Models overview
- Anthropic: Introducing Claude Fable 5 and Claude Mythos 5
- Anthropic: Claude API pricing
- ARC Prize: Claude Opus 5 verified results
- RuBench: fallback attribution analysis
- Claude Code discussion: Opus 5 vs Fable first impressions
FAQ
Claude Opus 5はClaude Fable 5より優れていますか？
常にではありません。Opusは複数評価でリードまたは接近し半額ですが、Fableは最高能力モデルとして残ります。
Fable 5に2倍払う価値はありますか？
追加の採用成果、retry削減、人手レビュー削減が2倍の単価を回収する場合だけです。
Coding agentにはどちらが適しますか？
Opus 5から始め、検証に失敗したfrontierケースかFable優位を測定済みの群だけ上げます。
Opus 5はbenchmarkでFableを超えましたか？
Anthropicは一部で勝利、別の評価で接近を報告しています。ARC PrizeはOpusのARC-AGI-3を検証しましたが、対応するFable値はありません。
両方とも1M contextですか？
はい。最大同期出力も128Kです。ただし実際のlong traceは別途replayしてください。
どちらが速いですか？
AnthropicはOpusをmoderate、Fableをslowerとしています。effort、出力、tools、routeでも変わります。
1つのEvoLink接続で両方使えますか？
はい。model IDをrouting policyに置き、同じ接続でdefault、escalation、fallbackを管理できます。
Default変更前に何を測りますか？
初回採用率、tool妥当性、retry、拒否、fallback、出力Token、所要時間、人手修正、採用タスク単価です。
Fableが計画し、Opusが実行できますか？
できます。計画出力を短くし、必要なcontextだけ渡し、追加latencyとTokenを含めた総採用タスク単価で判断します。
Fable requestがfallbackしていないと確認する方法は？
Requested model、served model、拒否category、fallback chainを記録します。HTTP 200だけではFableが回答した証明になりません。
