Claude Opus 5 vs Fable 5:実際にはどちらを使うべきか?

両モデルを並べて比較する

私はeeselでインテグレーションとAPIを構築する仕事をしているので、新しいモデルがリリースされるとまず開くのは仕様表だ。ローンチ動画を見るのはいつも後回しになる。まず平易な説明が欲しい人は、Fable 5とは何かから読み、続けてFable 5の機能の概要をどうぞ。以下はモデル概要が実際に公開している両モデルのスペックだ。

このうち2行はもう一度見る価値がある。

まず知識のカットオフ。Fable 5の信頼できるカットオフは2026年1月で、Opus 5の2026年5月より4か月古い。つまりフラッグシップモデルの方が、実は少し古い情報を抱えて歩いていることになる。今年起きた出来事について尋ねれば、安価な方のモデルの方が単純により多く読み込んでいるわけだ。

次にバッチの行。Message Batches APIでは、Opus 5はoutput-300k-2026-03-24のベータヘッダーの下で最大300kの出力トークンに対応しているが、Fable 5はそのリストに一切登場しない。長文生成タスク向けとして売り出されているモデルにしては奇妙なギャップだ。

価格:あらゆる項目でちょうど2倍

ここには読み解くべき巧妙な構造はない。入力と出力、さらにキャッシュ書き込みとキャッシュ読み取りに至るまで、AnthropicはFable 5をOpus 5のちょうど2倍に設定している。

これらの数字はすべてAnthropicの価格ページから取得している。そのページには目立たない形で埋もれているが、請求額に直結する点がいくつかある。

• どちらのモデルも長文コンテキストの割増料金はない。 90万トークンのリクエストも9千トークンのリクエストも同じトークン単価で課金される。一世代前まではそうではなかった。
• Opus 5の最小キャッシュ可能プレフィックスは512トークンで、Fable 5と並びラインナップ中で最も低い。つまりOpus 4.5ではキャッシュできなかった短いシステムプロンプトも、今はキャッシュできるようになった。
• Opus 5のFast modeは$10/$50で、これは標準Fable 5とまったく同じトークン単価であり、その代わりに得られるのはデフォルトの約2.5倍の速度だ。この分岐点は一考の価値がある。同じ金額で、速度かフラッグシップモデルかを選ぶことになる。
• サブスクリプションでは、ProはFable 5を使用クレジット経由で利用でき、Max 5xと20xは週間上限の50%でFable 5を利用できる。実質的にはFableの割り当てを2倍の速さで消費することになり、Claude Proの価格を基準に予算を組む場合はAPI料金表とは別に注意が必要だ。

Claudeの両フラッグシップモデルは、フロンティア層の中でも高価格帯に位置する。OpenAI側で最も近い比較対象はGPT-5.3 Codexの価格。Google側の同等モデルはGemini 3の価格にある。低価格帯側のオープンウェイトの挑戦者はKimi K2.5だ。

自分の使用量をここに当てはめてみてほしい。何を入力しても比率は2:1のままだが、絶対額の差が痛みとして感じられるのは、ある一定の規模を超えてからだ。

Fable 5がなお勝っている領域

ここでFableに対して公平でありたい。ローンチ時の報道は6週間ほどで「最先端」から「なぜこれを選ぶのか」へと一変したが、どちらの評価も正しくない。

Anthropic自身のOpus 5システムカードの表によれば、Fable 5は4項目でリードを保っている。

• SWE-bench Pro: 80、Opus 5は79.2
• DeepSWE v1.1: 69.7、Opus 5は68.8
• FrontierCode 1.1メインセット: 53.5、Opus 5は53.4
• Humanity's Last Exam(ツールなし): 56.5、Opus 5は56.3

どのベンチマーク表にも表れない優位性がさらに2つある。AA-Omniscienceでは、Artificial AnalysisはOpus 5がFable 5より事実知識の面で劣っていることを発見し、その原因をサイズクラスの違いに求めている。もう一つはLMArenaのテキストリーダーボードで、claude-fable-5は14,646票のうちEloスコア1507で1位に位置している。Opus 5はこのスナップショットがリリース前のデータのため一切登場しない。ブラインドでの人間の好みとベンチマーク上の知性は別物であり、人間の好みの方は今のところFableに軍配が上がっている。

だが左の列と右の列を並べてみてほしい。Fableのリードは小数点以下の差でできている。Opus 5のリードは整数の差だ。

Fableが完全に独占している領域がもう一つあり、それはAnthropicが実際にFableを売り込む際の訴求点そのものでもある。複数日にわたる自律的な作業だ。プロダクトページでは、エージェントハーネスの中でモデルが数日間にわたって稼働し、複数の段階にまたがって計画を立て、サブエージェントに作業を割り振っていく様子が描かれている。Cursorの見解では、Fable 5は「これまでのモデルでは手が届かなかった長時間タスクの領域」を切り開いたという。担当者に任せて最後にレビューするだけの1週間がかりの移行作業は実在するカテゴリーの仕事であり、Fableはまさにそのために作られている。

実際には、その種の作業は単一のチャットウィンドウではなくエージェントハーネスの中で行われる。多くの場合、委任を行っているのはClaude Codeのサブエージェントだ。Anthropic自身のインフラ上で実行する場合は、managed agentsが対象領域になる。そしてマルチエージェントシステムについてのより詳しい解説も用意されているので、その道を進むならぜひ参照してほしい。

Opus 5が圧勝している領域

エージェントループが絡む作業になると、話はまったく逆になる。エージェント型コーディングCLIや現行のAIコーディングアシスタントのいずれかを使っている人にとって、最も重要なカテゴリーだ。

これらの数字はすべてシステムカードから取得している。中でも特に見る価値があるのはFrontierBenchのグラフで、単一の数値ではなくeffortの段階全体をプロットしている。

Opus 5の曲線全体がFableの曲線より上かつ左に位置している。そのグラフ上で最も安価なポイントでさえ、Fableの最も高価なポイントとほぼ同じスコアを記録しており、これはじっくり見る価値のある事実だ。OSWorldについてのAnthropic自身の表現はもっと率直だ。Opus 5はコストのわずか3分の1強でFable 5の最高結果を上回るという。

私はこの同じ対決を他の研究所のモデルに対しても行ってきた。Googleのフラッグシップとの比較はGemini 3 Pro対Opusで扱っている。OpenAIのコーディングモデルについては、同じ切り口をGPT-5.3 Codex対Opusで展開している。

パートナー企業のコメントには小さな皮肉が隠れている。Fableの6月のローンチ時、CognitionはそれをFrontierBenchで最高スコアを記録したモデルと評していた。それから6週間後、同じ企業のOpus 5の発表記事でのコメントは、Opus 5が「半分のコストでFableに近い性能に迫る」というものだ。どちらの発言も書かれた当時は真実だった。それがこの階層の変化のスピードだ。

財務チームに見せたいコメントはZapierのものだ。Opus 5はAutomationBenchで首位に立ちながら、以前のClaudeモデルより多くのトークンを消費することはなく、以前のモデルが完全に失敗していたチャーン防止ワークフローで100%を記録した。

effortダイヤルこそが本当の決め手

ほとんどの比較記事はこの部分を見落としている。だが私が読者の注意をもっとも向けたいのもこの部分だ。

Artificial AnalysisはOpus 5の5つのeffort設定それぞれを別々のモデルとしてベンチマークしている。単純な理由からだ。それらは実際に別々のモデルのように振る舞う。GDPval-AA v2全体で見ると、これらのeffortレベルは407 Eloポイントの幅にわたり、出力トークン使用量はlowからmaxにかけておよそ8倍に増加する。つまり「Claude Opus 5」とは実質的に、一つの名前をまとった5つの性能プロファイルなのだ。

これらの数字はすべてArtificial AnalysisのAA-Briefcase計測によるものだ。highの行こそが議論のすべてを物語っている。フラッグシップモデルより32 Elo優れていながら、価格は47%に過ぎない。

罠は逆方向にも存在する。max effortでは、Intelligence Indexの1タスクあたりのコストは、Opus 5で$2.03、Opus 4.8で$1.80、Sonnet 5で$1.53だ。つまりOpus 5はFableよりタスクあたり26%安いにもかかわらず、自身の前世代モデルよりタスクあたりのコストが高くなっている。effortをmaxに設定してそのまま放置すると、実質的にアップグレードされるのはほぼ請求額だけだ。タスクごとの選び方についてはモデル選択のガイドで詳しく解説している。

開発者たちはローンチから数日でこれを見抜いていた。ある開発者は対照実験を行い、生の数字を公開している。

"Findings: At matched effort, Opus 5 spends roughly 2x the output tokens of 4.8."

u/Abject_Tip3868, Reddit

表示価格は同じでも、月末の請求額は変わってくる。この差こそが、この世代について理解しておくべき最も実用的なポイントであり、Fableにも同様に当てはまる。

ベンチマーク表には表れない3つのこと

どんなモデル比較でも、スコアを見るのは簡単な部分にすぎない。以下はリーダーボードではなくドキュメントを読み込んでいて気づいたことばかりで、そのどれもが2ポイントのベンチマーク差よりずっと私の判断を左右するものだ。

Fableのセーフガードはリクエストを他のモデルに転送する

この2モデルの違いの中でも、これは最も語られていないものだが、実際の運用コストに直結する。

Fable 5にはサイバーセキュリティと生物学関連のセーフガードが組み込まれており、それに引っかかるクエリは自動的に弱いモデルへと転送される。Fable 5のページで、Anthropicは転送先を具体的に明記している。サイバーセキュリティのフラグはOpus 4.8へ、生物学のフラグはOpus 5へ転送される。この処理に対応するため、APIの顧客はFallback APIを設定する必要がある。

では、これはどれくらいの頻度で発動するのか。FrontierBenchの実行では、システムカードによれば、Fableの分類器はAPI呼び出しの42%を、26%の試行にわたってフラグ付けした。Opus 5の場合、同じ数値はそれぞれ5%と4%だった。

ここには公平を期すべき但し書きがある。これらの数字は、分類器が対象とするよう設計された安全性の高い領域内の単一のベンチマークから得られたもので、一般的なトラフィックを表すものではない。Anthropicもまた、転送されたリクエストに対してFableの料金は課金されないと確認している。それでも、あなたの作業がセキュリティや生物学に少しでも触れるものであれば、フラッグシップモデルの実行のかなりの部分が、実際には別のモデルによって密かに処理されていることになる。しかもその「別のモデル」というのが、まさにあなたが選ぼうとしていたもう一方のモデルなのだ。

Fable 5は19日間ダウンしていた

Anthropic自身の発表記録を見れば、これは十分明確だ。Fable 5は2026年6月9日にローンチしたが、6月12日にアクセスが停止され、7月1日に復旧した。

当時、私はFable 5が復活という記事でその復旧について書いた。

これはFableの信頼性について何か恒久的なことを語るものではないと個人的には思っている。とはいえ、トップティアのモデルを本番パイプラインの必須依存として組み込もうとしているなら、この検討事項は無視できない。Fableの利用には安全性モニタリングのために30日間のデータ保持も求められ、これはOpus 5では一切発生しないコンプライアンス上の議題だ。

どちらも遅く、Opus 5はマーケティングが示唆するより遅い

Artificial AnalysisはOpus 5に対してこの点では手加減していない。モデルページでは、クラス中央値76に対して秒間52.6出力トークン、そして中央値2.81秒に対して初回トークンまで68.04秒と計測されている。Anthropic自身の表では、Fable 5のレイテンシは「遅い」、Opus 5は「中程度」となっており、両者を比べればFableの方が遅いことになる。

この68秒という初回トークンまでの時間はmax effortでの推論を含んでおり、effortを下げても得られるものはごくわずかだ。xhighで52.8t/s、highで56.8t/s。どちらもチャット向けの低レイテンシモデルではない。バッチ処理・バックグラウンド処理向けのモデルであり、それを無視して機能をリリースすれば、誰も待ってくれない代物になる。

開発者たちが実際に語っていること

この組み合わせについては、コミュニティの見方の方がローンチ時の報道より鋭く、しかもその議論はほとんど価格そのものについてではない。

"Another way to ask the question, why is Opus half as expensive?"

u/Decent-Lab-5609, Reddit

人々が行き着く答えは、意外と地味なものだ。そしておそらく正しい。

"I don't understand where this thought of pricing and performance must follow. Opus used to be triple the price. Doesn't mean Opus 4 is better than Opus 5. The cost to serve Fable is higher than the cost to serve Opus. It's that simple."

u/DatDudeDrew, Reddit

サブスクリプションでは、Fableは週間割り当てをまったく違うペースで消費するため、この差は2:1をはるかに超えて広がる。

"working for about 3-5 hours drains 50% of my weekly 20x subscription using Fable 5 only. I have now been using Opus 5 only (since I'm out of Fable) for about 7 hours and it drained about 6% of my weekly usage. Meaning that you can do insane amounts of work with Opus 5 on 20x and I consider it unlimited. While Fable 5 is a sneeze."

u/Typical-Whole-248, Reddit

Opus 5に全員が納得しているわけではなく、その不満は一貫して繰り返されているため、私も真剣に受け止めている。Claude Codeでのスコープクリープが繰り返し挙がる不満だ。

"Opus versions since 4.6 have all had a fair amount of awkward, canned prose. But as Anthropic has increased the model's intelligence, it also seems to have made it more panicky, pedantic, and prone to scope creep. Opus 5 is the worst offender thus far for me [...] To me, its judgment feels strangely anxiety-shaped."

u/Veraticus, Reddit

これが生み出した最も人気の回避策は、一つのモデルを選ぶことをそもそもやめるというものだ。

"/model switching mid-session. Fable in plan mode first — it reads the repo and writes out the plan, no code. Switch to Opus to implement, you can then optionally switch back to Fable to review the diff. Context carries over so nothing gets re-explained."

u/Otherwise-Key806, Reddit

Fableが計画を立て、Opusが実装をこなす。Fableのオーケストレーションの強みと、実行ループにおけるOpus 5の価格の安さを組み合わせれば、この分業はどちらか一方のモデル単体よりも説得力を持って成立する。同じロジックが、実装にはClaude CodeでOpusを使い、機械的な作業には安価な階層のモデルを残しておくという運用の背景にもある。

順位よりも心配すべき数字

上のすべての表が測っているのは能力だ。だが次のこの数字は、顧客対応のあらゆる場面を左右する。

AA-Omniscienceにおいて、Artificial AnalysisはOpus 5の正確性がOpus 4.8より7ポイント向上したことを発見した。また、不確かな場合でもより頻繁に回答するようになっており、そのハルシネーション率は14ポイント上昇して50%に達した。つまり、そのセットにおける回答の半分はハルシネーションだということだ。正確性の向上は、より自信満々な当てずっぽうによって得られたものだった。

テストを走らせて検証できるコーディングエージェントであれば、自信満々な当てずっぽうもまだ回復可能だ。だが顧客と対話するボットにとっては、それがそのまま失敗のすべてを意味する。サポートの現場から、私はこの構図が一度ならず現実に起きるのを見てきた。私が関わったあるチーム、Zendeskで月間約200件のチケットを処理し、2,000件規模へと拡大中のデンマークのB2B車両テレマティクス系サポートチームが、これ以上ないほどありふれた形でこの問題にぶつかった。彼らのナレッジベースには「すべての車種に対応している」と書かれていたため、ボットは自社のデータベースにまったく存在しない自動車ブランドにも対応していると、平然と顧客に伝えてしまったのだ。モデル自体には何の問題もなかった。グラウンディングが間違っていて、しかもモデルはそれを疑うには自信を持ちすぎていた。

だからこそ、私にとってベンチマークの順位がサポート導入の意思決定を左右することは決してない。決め手となるのは、モデルに何を見せることを許すか、そしてモデルが確信を持てないときに何が起きるか、その2点だ。この議論全体はRAG vs LLMできちんと展開しており、失敗モードについてはAIハルシネーションのガイドにまとめている。

注目すべき指標はEloではない。AI解決率を解決あたりコストと照らし合わせたものこそが指標だ。

そして、サポートキューを実際に構成している大量・短時間のタスクにおいては、どちらのフラッグシップモデルもそもそも適したツールではない。チケットトリアージを例に取れば、数百トークンが入力されてラベルが一つ出力される、これが一日に何千回も繰り返される作業だ。

Sonnet 5は同等の品質をより速く、より安く実現し、Haikuはさらに安価だ。

結局どちらを使うべきか

私の実際のおすすめを短くまとめると、デフォルトはhigh effortのOpus 5にすること。Fable 5は、本当に何日もかかる作業の計画立案とレビューのパスのために取っておき、必要のないタスクにmax effortの価格を払い続けるのはやめることだ。

これは、Anthropicが実際に推奨していることとも大枠で一致する。彼らのドキュメントはClaude Opus 5から始めるよう述べており、最高水準の能力が必要になった場合にのみステップアップするよう案内している。ベンダーが自社の高価な製品から利用者を引き離すようなアドバイスをすることは、そう頻繁にはない。

もしここでの答えが「どちらでもない」だとしたら、検討する価値のある選択肢はClaude代替ツールにまとめている。そして開発者以外のチームにとってはモデルよりも操作面の方が重要になるため、それはこの記事の論点というよりClaude Coworkの価格の話になってくる。

eeselがどう関わるか

この記事の大部分は、2つのモデルのどちらかを選ぶという話だった。eeselが何年もかけて実際のサポートキューでAIを運用してきた末に私がたどり着いた立場は、そもそもサポートチームがこの選択を迫られるべきではないというものだ。

eesel AIのチームメイトはあなたのヘルプデスクに接続し、あなた自身の過去のチケットとヘルプセンターをもとに学習し、その裏側でモデルのルーティングをすべて処理する。6週間後にフロンティアが再び動いても、それは必ず起きるものだが、あなたのセットアップ側は何も変える必要がない。実際に調整すべきなのは重要な部分、つまりAIが何に答えることを許されるか、いつ人間にエスカレーションするか、そして返信する前にどれだけの確信を持っている必要があるか、という点だけだ。すべてのロールアウトはまず過去のチケットに対してシミュレーションされるため、実際のチケットに対してAIが何を答えていたかを、実際の顧客に見せる前に確認できる。このシミュレーションのステップが存在するのは、まさに上で触れた「すべてのモデルに対応しています」問題があるからだ。

サポートキューに何を導入すべきか検討するためにこのモデル比較を読んでいるのであれば、その裏にある本当の問いはこれだ。私のAIヘルプデスクソフトウェアのまとめではより広い視点を扱っており、サポートに最適なLLMではモデルごとに検討している。

eeselを試してみるのは無料でできるし、デモであなたのチケットをどう処理するか見ることもできる。料金はタスクごとに発生するため、この記事で取り上げたeffortレベルの罠はそもそも当てはまらない。