Claude Opus 5の公開後、「Fable 5をすべての高難度タスクに使い続けるべきか」「日常の複雑なタスクはOpus 5に切り替えてよいか」という判断が必要になりました。
この比較で重要なのは、ベンチマークの順位だけではありません。料金、データ保持、fallback、再試行、人間による修正まで含めて、合格した成果物を一つ得るためのコストを見る必要があります。
3行まとめ
- 公開仕様から立てられる運用仮説は、Opus 5を日常の高難度タスクのデフォルト候補、Fable 5を長時間・高曖昧度・失敗コストが大きいタスクの昇格候補にすることです
- Opus 5の公式Token単価はFable 5の半分ですが、実際のタスクコストまで必ず半分になるわけではありません
- 30日間のデータ保持要件やfallbackの扱いは、ベンチマークより先にモデルを候補から外すことがあります
対象読者
- Claude APIで複雑なCoding Agentや長時間タスクを動かしている人
- Opus 5とFable 5のどちらを標準ルートにするか検討している人
- Token単価ではなく、再試行や人手修正を含む総コストを比較したい人
- requested modelとresponse modelを分けて評価ログに残したい人
比較の前提
この記事は、2026年7月25日時点のAnthropic公式仕様と第三者評価を整理したものです。
Opus 5とFable 5に同じタスクを送った自社独立実測ではありません。したがって、本文の「デフォルト候補」「昇格候補」は公開仕様から立てた検証前の運用仮説です。
また、異なるベンチマーク、effort、Agent harness、fallback設定のスコアを一列に並べて「総合的な勝者」を決めることはしません。
まず確認する公開仕様
| 項目 | Claude Opus 5 | Claude Fable 5 | 運用上の意味 |
|---|---|---|---|
| 公式の位置づけ | Complex agentic codingとenterprise work向け | 長時間Agent向けの、広く提供される中で最も高能力なモデル | 日常の複雑な仕事と、最難関の長時間仕事を分けて考える |
| API model ID | claude-opus-5 |
claude-fable-5 |
requested modelとして明示する |
| Context window | 1M Tokens | 1M Tokens | 同じContext長でも、品質やコストが同じとは限らない |
| 最大同期出力 | 128K Tokens | 128K Tokens | 長い出力の安定性は別途タスクで確認する |
| Thinking / effort | Adaptive thinking、lowからmaxまで5段階 |
Adaptive thinkingが常時有効 | Opus 5はeffortごとのToken量と品質を記録する |
| 公式の相対Latency | Moderate | Slower | 実環境のLatencyではなく、公式の比較表現 |
| Reliable knowledge cutoff | 2026年5月 | 2026年1月 | 新しい事実を扱う場合は外部ソースで確認する |
| 公式Input / Output価格 |
$5 / $25 per MTok |
$10 / $50 per MTok |
同じToken量ならOpus 5は半額 |
| 一般アクセス時のデータ保持 | 30日保持要件なし | 安全監視のため30日保持が必要 | 機密データでは先に適合性を確認する |
| Safety / fallback | 分類器の対象になり得て、APIで自動fallbackを設定可能 | より強い安全監視の対象で、APIで自動fallbackを設定可能 | 実際に返したresponse modelを必ず記録する |
ここで最も注意したいのは、同じ1M Contextと128K出力を持っていても、同じ製品ではないという点です。
価格、Latency、Thinkingの制御、データ保持、安全分類器の挙動が異なるため、Context長だけで代替可能性を判断できません。
Token単価だけでは決められない理由
公式価格だけを見ると、Opus 5のInput / Output単価はFable 5のちょうど半分です。
一方、Artificial AnalysisのIntelligence Indexタスクでは、Opus 5 maxの平均コストが$2.03、fallbackを含むFable 5が$2.75と報告されています。この差は約26%であり、50%ではありません。
これは公式価格が間違っているという意味ではありません。実際のタスクでは、次の要素が総コストを変えるためです。
- 使用したInput / Output Tokens
- Prompt cacheのwriteとhit
- effortによる出力Token量の差
- Tool callと外部サービスの費用
- 失敗した試行と再実行
- fallback後に実際に応答したモデル
- 人間が修正、確認、再指示に使った時間
図1：Token単価からaccepted task costまでの間には、ワークフロー固有の変数があります
第三者評価の数字も、そのharnessと設定での結果です。自社のRepositoryやAgent workflowへそのまま外挿することはできません。
accepted task costを計算する
モデル比較では、1回のAPI料金ではなく、合格条件を満たした成果物を一つ得るまでの総コストを使います。
accepted_task_cost
= Σ(api_token_cost + cache_cost + tool_cost) # 失敗分を含む全試行
+ human_fix_minutes × hourly_rate / 60
ここでいう「accepted」は、出力が返ったことではありません。たとえばRepository-levelのBug Fixなら、少なくとも次の条件を先に固定します。
- 元の不具合を再現できる
- 修正後に元の失敗ケースが通る
- 既存テストに回帰がない
- 変更範囲が要求を超えていない
- Reviewerが説明とdiffを確認できる
合格しなかった試行のToken、Tool、待ち時間、人手修正も、最終的なaccepted task costに含めます。
タスク別の判断フロー
図2：契約上の制約を確認した後、同じ合格条件でモデルを昇格させる判断フローです
このフローの目的は、Fable 5を「常に最強だから使う」ことでも、Opus 5を「半額だから固定する」ことでもありません。
タスクの失敗コストと契約上の制約を先に見て、同じ合格条件で比較することが目的です。
実務向けの判断表
| タスクや制約 | 最初の候補 | 判断理由 | 追加で確認すること |
|---|---|---|---|
| 日常の複雑なCoding、分析、文書作成 | Opus 5 | 公式の価格、相対Latency、effort制御がデフォルト運用に合わせやすい | 品質、再試行、Token量、Latency |
| 長時間Agent、要件が曖昧な大型実装 | Opus 5で基準を取り、Fable 5も比較 | Fable 5は長時間・高難度タスク向けだが、追加コストがある | 完了率、人工介入、accepted task cost |
| 同じ失敗を繰り返す、または失敗コストが非常に高い | Fable 5への昇格を検討 | 上限能力によって返工を減らせる可能性がある | 同じPrompt、Tool、Timeout、合格条件で再試験 |
| 30日間のデータ保持を許容できない | Fable 5を一般アクセス候補から外す | Fable 5には一般アクセス時の保持要件がある | 利用サービス側の契約と保持条件 |
| Security関連のコードやTool利用 | 先に許可範囲とfallbackを確認 | 分類器によって拒否や別モデルへのroutingが起こり得る | requested model、response model、fallback設定 |
| 公開ベンチマークの結果が矛盾する | 自分のタスクで比較 | effort、harness、Tool、fallbackが異なる | 検証条件を固定し、スコアを混ぜない |
Repository-level Bug Fixで試す場合
最小の比較単位として、実際のRepositoryにあるBug Fixを一つ選びます。
- 同じcommit、Prompt、Tool、権限、Timeout、テストを用意する
- 先に合格条件と変更禁止範囲を書く
- Opus 5ではeffortを明示し、少なくとも1つの基準結果を取る
- 未合格、返工が大きい、または失敗代価が高い場合にFable 5を同条件で試す
- 最終出力だけでなく、失敗した試行、Tool call、人工介入も集計する
比較中にPromptやToolを変えた場合は、別条件として記録します。条件を途中で変えたままモデル差として集計すると、routing判断を誤ります。
最低限残すログ
以下は結果ではなく、比較時に埋めるためのテンプレートです。
{
"task_id": "",
"requested_model": "",
"response_model": "",
"effort": "",
"fallback_enabled": false,
"input_tokens": 0,
"output_tokens": 0,
"cache_write_tokens": 0,
"cache_read_tokens": 0,
"latency_ms": 0,
"tool_calls": 0,
"failed_tool_calls": 0,
"retry_count": 0,
"human_fix_minutes": 0,
"accepted": false,
"acceptance_notes": ""
}
特にrequested_modelとresponse_modelは分けます。
fallbackによって別のモデルが応答した場合、その結果をrequested modelの性能として数えるべきではありません。また、成功した最後の試行だけを残すと、再試行コストが消えてしまいます。
この比較でまだ分からないこと
- 両Routeで同条件のfirst call、usage、Latency、課金を確認した結果
- Repository-level Coding、長時間Agent、Image-to-HTMLにおける反復試験の結果
- fallbackが実際に発生したときのresponse modelと品質差
- 自社のタスクでFable 5の追加コストが返工削減によって回収できるか
公開仕様とベンチマークは、試すべきタスクを選ぶ材料にはなります。しかし、Production routingを確定する証拠にはなりません。
まとめ
Opus 5の登場によって、Fable 5が不要になったわけではありません。変わったのは、Fable 5をすべての複雑なタスクのデフォルトにする必要性です。
まずOpus 5を日常の高難度タスクの候補として測り、長時間・高曖昧度・失敗コストの大きい仕事だけFable 5へ昇格させる。この仮説を、Token単価ではなくaccepted task costで検証するのが実務的です。
最初に比較するなら、公開ベンチマークの再現ではなく、チームで最も返工コストが高い実タスクを一つ選ぶと判断しやすくなります。