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で検証するのが実務的です。

最初に比較するなら、公開ベンチマークの再現ではなく、チームで最も返工コストが高い実タスクを一つ選ぶと判断しやすくなります。

参考資料