Claude Opus 5 vs Claude Fable 5：実 API での 7 タスク検証と本番ルーティングの提案
Claude Opus 5 と Claude Fable 5 は、どちらを選ぶべきでしょうか。成功した 1 回の回答だけを見れば、どちらのモデルも見栄えのよい数学的導出を書けます。しかし本番体験を左右するのは、多くの場合それとは別の 3 点です。タスクを安定して完了できるか、レイテンシが対話用途に合うか、失敗後に自動復旧できるかです。
私たちは 2026 年 7 月 25 日、同じ OpenAI-compatible API を使い、同一のプロンプトとパラメータで、2 つのモデルに対して 7 種類のタスクをテストしました。結果は「大きいモデルほど常に優れている」という単純な話にはなりませんでした。
-
claude-fable-5は、両モデルが成功したタスクではより高速で、出力も簡潔でした。 -
claude-opus-5は、最終的に 7 種類すべてのタスクをカバーしました。 - Fable 5 は、通常のコードレビューとインシデント JSON のプロンプトで連続して
content_filterを発生させました。 - Opus 5 は、物理問題で最初の 2 回は HTTP 200 を返したにもかかわらず、無関係な挨拶を 1 文返しただけで、3 回目にようやく正常に完了しました。
つまり、本番でのモデル選定は 1 つのモデル ID だけに依存すべきではありません。より堅実なのは、まずタスク種別ごとに主モデルを選び、そのうえで内容検収、リトライ、モデルフォールバックによって異常系を包み込む方法です。
同じ API で Opus 5 と Fable 5 をテストする
要点
| 質問 | 今回の回答 |
|---|---|
| より多くのタスクをカバーしたのはどちらか？ | Opus 5：本テストでは 6/7、リトライ後は 7/7 |
| より高速だったのはどちらか？ | 両方がしたタスクでは、Fable 5 の P50 総レイテンシが約 24% 低い |
| 出力がより簡潔だったのはどちらか？ | Fable 5。平均可視出力 token が約 43% 少ない |
| コードレビューと厳密な JSON により適していたのはどちらか？ | 今回は Opus 5 のほうが安定。Fable 5 は 2 問で連続 3 回フィルタされた |
| HTTP 200 だけを見ればよいか？ | いいえ。両モデルとも HTTP 200 だがタスク未完了のケースがあった |
| 推奨ルーティングは？ | 検証済みタスクでは Fable 5 を優先し、フィルタまたは空本文なら Opus 5 へフォールバック。Opus が異常な挨拶を返した場合は自動リライ |
入力タイプが予測しにくい場合、または通常の業務プロンプトがフィルタされるリスクをできるだけ避けたい場合は、Opus 5 を優先的に検討すべきです。一方、タスク構造が固定され、すでに回帰テスト済みで、対話速度と出力長を重視する場合は、Fable 5 を最初の呼び出し先にするのが適しています。
テスト方法
テスト前にモデル一覧 API を呼び出し、2 つの正確なモデル ID が見えていることを確認しました。
GET https://cn.crazyrouter.com/v1/models
claude-opus-5
claude-fable-5
すべての正式リクエストは同じ endpoint を使いました。
POST https://cn.crazyrouter.com/v1/chat/completions
共通条件は次のとおりです。
同一 system prompt
同一 user prompt
temperature = 1
各問題で同一の max_tokens を使用
stream = true
ツールとインターネット接続は無効
共通の system prompt は、正確に回答し、指定された出力形式に従うことだけを求めています。特定モデルに有利なロール設定は加えていません。
Answer the user's task accurately. Follow every requested output format and length constraint exactly. Do not use external tools.
記録したのは最終的な本文だけではありません。以下も記録しました。
- HTTP ステータスと
finish_reason - response ID と returned model
- 最初の可視 token までの時間と総レイテンシ
- completion tokens、reasoning tokens
- 可視回答がタスクの検収条件を満たしたか
- 異常リクエストが同一パラメータのリトライで復旧できるか
これは Crazyrouter ゲートウェイのエンドツーエンドテストであり、単一の上流チャネルを指定した実験ではありません。したがって結果には、モデルの挙動、上流のフィルタリング、ゲートウェイのルーティング、その時点でのチャネル状態が同時に反映されています。「ユーザーがこの API 経由で実際に何に遭遇するか」を答えるには適していますが、Claude ファミリーの純粋なオフライン能力ランキングとして扱うべきものではありません。
モデルテストで finish_reason と出力予算を記録すべき理由を知りたい場合は、Claude Fable 5 vs GPT-5.5 の max_tokens 再テストも参照してください。
7 項目の結果サマリー
| テスト観点 | Claude Opus 5 | Claude Fable 5 | 本番への影響 |
|---|---|---|---|
| 厳密な数学：マルコフ連鎖 | 合格 | 合格 | どちらも正しい一次モーメント、二次モーメント、分散を得た |
| 数値物理：結合振動子 | 最初の 2 回は挨拶のみ、3 回目で合格 | 初回で合格 | Opus には内容レベルの検収とリトライが必要 |
| 制約探索 | 合格 | 合格 | どちらも一意解を見つけた |
| 統計の誤り訂正 | 合格 | 合格 | どちらも誤った前提を拒否し、正しい上界を提示した |
| Python コードレビュー | 合格 | 連続 3 回 content_filter
|
Fable は現時点では、回帰未検証のコードレビュー流量には適さない |
| 厳密 JSON のインシデント要約 | 合格 | 連続 3 回 content_filter
|
Fable は現時点では、この種の本番インシデント文面には適さない |
| 実験設計 | 合格 | 合格 | どちらも非対応サンプルと難易度の交絡を識別できた |
本テストにおける 1 回目での納品率は次のとおりです。
Claude Opus 5: 6 / 7 = 85.7%
Claude Fable 5: 5 / 7 = 71.4%
リトライを含めると次のようになります。
Claude Opus 5: 7 / 7
Claude Fable 5: 5 / 7
ここでいう「納品」はリクエストの成功ではなく、業務側が問題要件を満たす可視回答を受け取れたことを指します。HTTP 200、モデル名、token usage が存在していても、本文が空、フィルタされた、または挨拶しか返らなかった場合は、タスク失敗として扱います。
数学、制約、統計：どちらのモデルも信頼できる
数学問題では 3 状態のマルコフ連鎖を使い、状態 1 から初めて状態 3 に到達するまでの待ち時間について、次を計算するよう求めました。
E1[τ]
E1[τ²]
Var1(τ)
どちらのモデルも次を返しました。
E1[τ] = 5
E1[τ²] = 43
Var1(τ) = 18
また、両方とも一時状態行列 Q と一次・二次モーメントの方程式を書いていました。この問題では、「最終的な数値は正しいが導出が一貫しない」という状況は発生しませんでした。
制約探索では、A、B、C、D、E の 5 つの講演を 5 つの時間枠に配置し、直後に隣接、前後関係、間隔、非隣接といった条件を同時に満たすよう求めました。どちらも一意の順序を得ました。
A, C, E, B, D
統計の誤り訂正問題では、あえて誤った結論を与えました。「平均が 10、分散が 4 なので P(X≥14)=0.5」というものです。両モデルとも、二次までのモーメントだけでは尾確率を一意に決定できないと指摘し、片側 Chebyshev/Cantelli 不等式により次を得ました。
P(X >= 14) <= 0.2
この 3 種類のタスクから分かるのは、Fable 5 の速度面の優位が、基礎的な推論の正確性を犠牲にしたものではないということです。明確で短く、検収しやすい数学・論理タスクでは、より軽い第一候補として十分に使えます。
以前の Claude Fable 5 vs Claude Sonnet 5 API テスト と GLM-5.2 vs Fable 5 出力予算テスト でも示したように、あるモデルが本番に適しているかを判断するには、正確性、出力予算、納品形態を合わせて必要があります。
物理問題：Fable は初回完了、Opus は 3 回目で復旧
物理問題では、接地減衰と結合減衰を持つ 2 自由度振動子を扱い、2 つの非減衰固有振動数と、ω=8 rad/s における 2 つの質量の複素周波数応答を計算するよう求めました。
参照値は次のとおりです。
ω1 = 10.0204 rad/s
ω2 = 16.2149 rad/s
|X1| = 0.14929 m, phase = -12.15°
|X2| = 0.07174 m, phase = -13.90°
Fable 5 は初回で正しい結果をすべて返しました。一方、Opus 5 の最初の 2 回の呼び出しでは、本番チームが特に注意すべき異常が発生しました。インターフェースは HTTP 200 と finish_reason=stop を返しましたが、本文は次の 1 文だけでした。
Hi! How can I help you today?
この 2 回のレスポンスでは prompt tokens がどちらも 10 で、実際の入力とは明らかに一致していませんでした。同じリクエストを 3 回目に実行したところ、Opus 5 は 34.901 秒後に完全な回答を返し、6 つの数値はすべてチェックを通過しました。
したがって、この種の異常は「物理問題を計算ミスした」と分類するべきではなく、「リクエストコンテキストが正常に処理されなかった」と分類すべきです。最も簡単な防御策は、人間がログを見ることではなく、呼び出し側でタスクレベルの検収を設定することです。回答に ω1、ω2、X1、X2 が含まれていなければリトライします。
コードと厳密 JSON：Fable のフィルタリングが今回最大の差分
コード問題では、Python の DFS サイクル検出器をレビューさせました。バグはごく一般的なものです。ノードの DFS 完了後に visiting 集合から削除していないため、すでに処理済みのノードがまだ再帰スタック上にあると誤認され、DAG に対してサイクルを誤検出します。
Opus 5 は最小修正を正しく指摘しました。
visiting.discard(node)
visited.add(node)
return False
Fable 5 はコード分析を返さず、finish_reason=content_filter で本文は空でした。system prompt の偏りや偶発的なルーティングを除外するため、3 回確認しました。元のテスト、クリーンな system prompt での再テスト、単独問題としての独立リトライのいずれも、結果は content_filter でした。
厳密 JSON 問題にも危険な内容は含まれていません。入力には、15 分間のリクエスト総数、失敗数、チャネル別要因、リトライで復旧した数、対応アクションだけが含まれており、出力として JSON オブジェクトを求めました。Opus 5 が返した JSON はそのままパースできましたが、Fable 5 は同様に連続 3 回フィルタされました。
この 2 種類の失敗が示しているのは、安全フィルタリングそのものもモデル API の本番能力の一部であるということです。通常のコードレビューやインシデント振り返りのテキストで安定して誤フィルタが発生するなら、たとえ数学問題で高速でも、すべての業務トラフィックをそのモデルに任せることはできません。
2 回の独立リトライの response ID は次のとおりです。
コードレビュー：gen-1784915384-vGI1PtuNXZG0IJ2YiaCz
インシデント JSON：gen-1784915390-buOWZQSnqjgHeJ6nUogF
レイテンシと出力長
失敗リクエストの短い処理時間を「速度優位」として数えないため、ここでは両モデルが成功した 4 つの共通タスク、すなわち数学、制約探索、統計の誤り訂正、実験設計だけを比較します。
| 指標 | Claude Opus 5 | Claude Fable 5 |
|---|---|---|
| P50 総レイテンシ | 10.729 s | 8.147 s |
| P50 最初の可視 token | 8.376 s | 6.974 s |
| 平均可視 completion tokens | 797.5 | 452.3 |
この小さなサンプルでは、Fable 5 の P50 総レイテンシは約 24% 低く、最初の可視 token は約 17% 早く、回答は約 43% 短くなりました。チャット、バッチ要約、高頻度の構造化タスクでは、これらの差はユーザーの待ち時間と下流処理量に直接影響します。
ただし、4 問の中央値を SLA として書くべきではありません。上流の負荷、キャッシュ、ルーティング、レート制限はいずれもレイテンシを変化させます。本番投入前には、自社の業務プロンプトで 20–50 回繰り返し、P50、P95、P99 と、検収を通過した結果 1 件あたりの実コストを集計すべきです。
Fable 5 の本テストレスポンスには cost フィールドがあり、7 回の合計は約 $0.24596 でした。Opus 5 の usage には同じ基準の cost が提供されていなかったため、本記事ではドル価格での勝敗判断は行いません。フィールドがないことは無料を意味せず、未検証の価格で補完すべきでもありません。
推奨する本番ルーティング戦略
単一モデル呼び出しは最も実装しやすい一方で、モデルのあらゆる偶発的な挙動をそのままエンドユーザーに露出させます。今回の 2 モデルについては、次のように役割を分けるのがより合理的です。
Fable 5 を第一候補にする
適している用途：
- 回帰テスト済みの数学、制約推論、短い要約
- 最初の token と全体レイテンシに敏感な対話
- 回答長を抑え、後処理負荷を減らしたいタスク
前提として、対象タスク群でフィルタリングのテストが済んでおり、呼び出し側で content_filter、空本文、必須フィールド欠落をチェックする必要があります。
Opus 5 を広範囲カバーのフォールバックにする
適している用途：
- 入力タイプが予測しにくい
- コードレビュー、厳密 JSON、複雑な物理など、より広いタスクカバレッジが必要な場面
- Fable 5 がフィルタされた後、ユーザーリクエストを自動復旧したい場面
Opus 5 も無検査で使うべきではありません。今回の挨拶異常が示すとおり、HTTP 200 と stop であっても、業務上の回答が含まれていないことがあります。
OpenAI-compatible Python の例
次の例では、まず Fable 5 を呼び出し、フィルタ、空本文、検収失敗が発生した場合に Opus 5 へフォールバックします。Opus でも挨拶しか返らない場合は、さらに 1 回リトライします。
from openai import OpenAI
client = OpenAI(
api_key="YOUR_API_KEY",
base_url="https://cn.crazyrouter.com/v1",
)
def valid_answer(text: str, required_terms: tuple[str, ...]) -> bool:
normalized = (text or "").strip()
if not normalized:
return False
if normalized.lower().startswith("hi! how can i help"):
return False
return all(term in normalized for term in required_terms)
def call_model(model: str, prompt: str) -> tuple[str, str | None]:
response = client.chat.completions.create(
model=model,
messages=[{"role": "user", "content": prompt}],
temperature=1,
max_tokens=3000,
)
choice = response.choices[0]
return choice.message.content or "", choice.finish_reason
def routed_completion(prompt: str, required_terms: tuple[str, ...] = ()) -> str:
for model, attempts in (("claude-fable-5", 1), ("claude-opus-5", 2)):
for _ in range(attempts):
text, finish_reason = call_model(model, prompt)
if finish_reason == "content_filter":
break
if valid_answer(text, required_terms):
return text
raise RuntimeError("No model produced a valid business answer")
answer = routed_completion(
"Return a JSON incident summary with keys total, failed, recovered.",
required_terms=('"total"', '"failed"', '"recovered"'),
)
print(answer)
本番実装ではさらに、model、response ID、finish_reason、総レイテンシ、検収失敗理由を記録すべきです。そうすることで、モデルの計算ミス、出力打ち切り、内容フィルタリング、ルーティングによる入力欠落を区別できます。これらをすべて曖昧な「モデル失敗」にまとめてしまうべきではありません。
マルチモデル基盤を計画している場合は、AI API Gateway、アグリゲーター、モデル API 直結の違い と、Kimi K3 vs Opus 4.8 の 7 次元テスト も参考になります。
最終的な提案
今回最も価値のある結論は、どちらが高得点だったかではなく、2 つのモデルの失敗形態が異なるという点です。
- Fable 5 の強みは、共通タスクでより高速かつ短いことです。リスクは、一部の通常業務プロンプトが安定してフィルタを発生させることです。
- Opus 5 の強みは、リトライ後にすべてのタスクをカバーしたことです。リスクは、実入力と無関係な挨拶を偶発的に返すことです。
したがって、検証済みの高頻度タスクでは Fable 5 を前段に置き、Opus 5 をより広範囲のフォールバックとして使い、両方の経路で内容レベルの検収を行うことを推奨します。そうして初めて、モデル比較の結果を単なるランキングではなく、実際の信頼性へ変換できます。
API Key を作成して、この 2 モデルルーティングを再現する
FAQ
Claude Opus 5 は Claude Fable 5 より必ず強いのですか？
この小さなサンプルから「すべてのタスクでより強い」とは結論できません。数学、制約、統計の誤り訂正、実験設計ではどちらも合格しました。Fable 5 はより高速で短く、Opus 5 はタスクカバレッジがより完全でした。選択はモデル名ではなく、具体的なタスク成功率に基づいて行うべきです。
Claude Fable 5 は本番環境に適していますか？
回帰テスト済みのタスクには適しています。今回、複数の推論タスクでは正確かつ比較的高速でしたが、コードレビューとインシデント JSON では連続してフィルタを発生させました。本番投入前には実際のプロンプトでフィルタ率を測定し、Opus 5 または他モデルへのフォールバックを設定すべきです。
HTTP 200 でも失敗とみなすのはなぜですか？
HTTP 200 は、インターフェースがレスポンスを完了したことだけを示します。本文が空、finish_reason=content_filter、出力が途中で切れている、または挨拶だけを返す場合、業務タスクは完了していません。本番指標では HTTP 成功率だけでなく、「検収通過率」を集計すべきです。
returned model が anthropic/claude-fable-5 なのはなぜですか？
リクエストでは claude-fable-5 を使用し、レスポンス内の returned model は provider プレフィックス付きの anthropic/claude-fable-5 で安定していました。これは正規化されたエイリアスと見なせます。プレフィックスの変化だけでは、モデルが置き換わった証拠にはなりません。
2 つのモデルのドルコストを直接比較できますか？
今回の結果だけではできません。Fable 5 のレスポンスには cost フィールドがありましたが、Opus 5 には同じ基準のフィールドがありませんでした。厳密なコスト比較は、統一された課金ログから取得し、「検収を通過した結果 1 件あたりのコスト」を指標にすべきです。
本番投入を判断する前に何回繰り返すべきですか？
各コアタスク群について少なくとも 20–50 回の繰り返しを推奨します。通常入力、境界入力、長い入力、フィルタを誘発しやすい入力を含めてください。少なくとも、タスク成功率、フィルタ率、空本文率、打ち切り率、P50/P95/P99 レイテンシ、コストを記録すべきです。
どうやってテストを始めればよいですか？
https://cn.crazyrouter.com/v1 を OpenAI-compatible base URL として使い、claude-opus-5 と claude-fable-5 をそれぞれ呼び出します。プロンプトとパラメータを固定し、元レスポンスを保存したうえで、ローカルのアサーションまたは構造検証によってタスクが本当に完了したかを判定します。