この記事は Synthorai ブログの記事 Claude Opus 5 と Opus 4.8 を実測比較：同じ料金でもコストは 3 倍の転載です。原文（多言語対応）はリンク先をご覧ください。

Claude Opus 5 と Claude Opus 4.8 の料金は、入力 100 万 token あたり $5、出力 100 万 token あたり $25 で同じだ。しかし、同一の prompt では、デフォルト設定の Opus 5 が 3.1 倍のコストになった。原因は adaptive thinking にある。Opus 5 はデフォルトで思考し、その分を出力 token として請求するが、思考内容は一切表示しない。リクエスト設定を 1 つ変えれば、コストは完全に同額になる。ただし、上位モデルの Fable 5 はこの設定を受け付けない。Opus 5 は 2026-07-24 に GA となり、token 単価が半分で Fable 5 相当の知能を持つモデルと位置付けられている。実際に請求額が半分になるかは、ほぼこの設定だけで決まる。

TL;DR

デフォルトの Opus 5 は、5 タスクのマトリクスで、同じ単価の Opus 4.8 より請求額が 3.1 倍になった。出力 token の 42～95% は表示されない思考だった。
thinking: {"type": "disabled"} を指定すると、Opus 5 は 4.8 と完全に同じ出力 token 数になった。384 対 384 で、精度も維持された。Fable 5 はこのパラメータを拒否する。
agent トラフィックでは上乗せが +33% まで下がり、tool や batch のシナリオではほぼ同額になる。tool loop では adaptive thinking がほとんど動作しない。
1M context は実際に利用でき、969950 token 地点の needle を再現できた。cache の下限は 512 token で、4.8 の 1024 token の半分になった。

Opus 5、Opus 4.8、Fable 5 はプラットフォームとして何が違うのか？

コストを詳しく見る前に、現在の Claude 3 tier を整理する。主な違いは料金とリクエスト形式の 2 軸だ。以下に並べた。実測項目にはその旨を記載し、それ以外はモデルのドキュメントに基づく。

	Opus 4.8	Opus 5	Fable 5
定価（入出力／M）	$5 / $25	$5 / $25	$10 / $50
thinking のデフォルト	明示しない限り off	adaptive、on（実測）	常に on
`thinking: disabled`	effort と独立して受け付ける	effort `high` 以下で受け付ける	400 で拒否（実測）
effort の段階	`low`～`max`、デフォルトは `high`	`low`～`max`、デフォルトは `high`（コスト面は後述の実測値）	`low`～`max`、デフォルトは `high`
thinking の内容を返すか	デフォルトでは該当なし	返さない（実測）	返さない
cache の下限	1024 token	512 token（実測）	512 token
context window	1M	1M、デフォルトかつ最大（969950 token の needle で実測、後述）	1M
assistant prefill	拒否	拒否、明示的な 400（実測）	拒否
fast mode	利用可能（research preview）	利用可能、$10/$50	提供なし
refusal 時の fallback	デフォルトの fallback 先になる	新しい `"default"` mode を含む `fallbacks`（beta）	このモデルで導入（明示的なリスト）
データ保持	標準オプション	標準オプション	30 日間の保持が必須

このうち 3 点は補足が必要だ。thinking: disabled は移行時の落とし穴になる。Opus 5 では effort と連動しており、ドキュメント上は high 以下でのみ受け付ける。4.8 では両設定が独立していたため、移行 script には version 判定が必要だ。fast mode も後の比較で重要になる。高速化した Opus 5 の料金表は Fable 5 と完全に同じなので、「fast Opus 5 とデフォルト Fable 5」の比較は、token 単価が同じ条件での速度と能力のトレードオフになる。データ保持については compliance 面で利点がある。Opus 5 なら、Fable 5 の 30 日間保持要件なしで Fable class の知能を利用できる。

表に収めにくい点がほかにも 2 つある。Anthropic は thinking を無効にした場合の edge case として、tool call が表示テキストに書き込まれる場合や、内部 tag が漏れる場合があると説明している。後述する agent suite では thinking を無効にした 84 call のいずれでも発生しなかった。ただし、routing の方針としては、thinking のコストが小さい tool 中心の route では有効のままにするのが妥当だ。また、会話途中での tool 変更機能（beta、Opus 5）を使うと、prompt cache を無効化せずに turn 間で tool を追加、削除できる。長時間の agent session で、prompt cache ガイドが前提としている cached prefix のコスト効率を維持できる。

デフォルトの Opus 5 は Opus 4.8 よりいくら高いのか？

同じ処理、同じ料金表でも 3.1 倍になる。現在の Claude 3 tier を 5 タスクのマトリクスで実行した。各 cell は n=3、prompt には salt を加え、native Messages API を使用した。比較用に Fable 5 も含めている。

タスク	Opus 5 デフォルト	Opus 4.8	Fable 5	精度
単純な算術	12	3	12	すべて 3/3
1 行で答える事実問題	40	6	11	すべて 3/3
小さなコード関数	70	38	44	—
複数段階の文章問題	152	102	52	すべて 3/3
120 語の段落	1031	236	264	—
合計出力 token（1 set のコスト）	1305（$0.03427）	384（$0.01120）	383（$0.02233）

回答内容は同じで、4.8 と単価も同じだが、請求額は 3 倍になった。Opus 4.8 は明示的に要求しない限り思考しない。Opus 5 は adaptive thinking がデフォルトで有効になっており、その思考分には出力の正規料金である $25/M がかかる。

Fable 5 の結果は直感に反する。単価は 2 倍の $10/$50 だが、絶対額ではデフォルトの Opus 5 より 35% 安かった。同じタスクに対し、Fable 5 の出力は 383 token、Opus 5 は 1305 token だったためだ。3 モデルともドキュメント上のデフォルト effort は同じ high なので、この差は設定ではなく思考量の調整によるものだ。数値と整合する理由は 2 つある。まず、能力の高いモデルほど、簡単な回答に確信を持つまでの検討量が少なくて済む。文章問題では Opus 5 が 152 token を使ったのに対し、Fable 5 は 52 token だった。段落作成では Opus 5 の 1031 token に対して Fable 5 は 264 token だった。次に、Opus 5 の主な能力は test-time compute scaling にあり、難問では追加の検討を品質向上につなげる。デフォルト設定では、その保険を不要なリクエストにも適用している。簡単なトラフィックでは、使わない保険にも料金を払うことになる。一方、Fable 5 はほとんどの場合、その保険をかけない。

追加コストは何に使われるのか？

内容を確認できない reasoning に使われる。請求対象の出力 token と表示された回答テキストを比較すると、デフォルトの Opus 5 では出力コストの 42～95% が表示されない思考だった。思考が不要な質問でも動作する。17*23 の回答は 1 token だが、裏で 11 thinking token が使われた。120 語の文章作成では、1031 出力 token のうち約 806 token が検討に費やされていた。思考内容は summary や trace を含め、どの形式でも返されない。この点で Opus 5 は、token 使用量の内訳で調査したモデルの中でも、Fable 5 と並んで可視性が最も低い。usage の内訳で token 数は確認できるが、その token で何が行われたかは確認できない。

thinking の切り替えで実際に何が変わるのか？

Opus 5 の請求額が Opus 4.8 と同水準になる。thinking: {"type": "disabled"} を指定すると、すべてのタスクで thinking がゼロになった。合計も 4.8 と完全に一致し、出力 token は 384 対 384、1 set のコストは $0.01130 対 $0.01120 だった。

条件	出力 token（set）	コスト（set）	Opus 4.8 比	精度（検証可能な 3 タスク）
Opus 5 デフォルト（＝ effort `high`）	1305	$0.03427	3.1x	9/9
Opus 5、effort low	1019	$0.02720	2.4x	9/9
Opus 5、effort medium	1167	$0.03089	2.8x	9/9
Opus 5、明示的な effort high	1514	$0.03956	3.5x	9/9
Opus 5、effort xhigh	1633	$0.04262	3.8x	8/8
Opus 5、effort max	1569	$0.04093	3.7x	9/9
Opus 5、thinking 無効	384	$0.01130	1.0x	9/9
Opus 4.8 デフォルト（＝ effort `high`、thinking なし）	384	$0.01120	1.0x	9/9
Fable 5 デフォルト（＝ effort `high`、thinking は常時 on）	383	$0.02233	2.0x	9/9

表記について先に説明する。ここに挙げたすべてのモデルは、API のデフォルトを同じ effort high としている。Anthropic も、high を明示した場合とパラメータを省略した場合は同じだと説明している。それでも暗黙のデフォルトと明示的な high で 16% の差が出た。これは文章作成タスクでの実行ごとのばらつきであり、実際の設定差ではない。このタスクは、これまで実行したすべての batch で最も変動が大きかった。この 2 行は、同じ条件を 2 回測定したものとして読むべきだ。3 モデルのデフォルトを分けているのは effort level ではなく、その level で thinking がどう動くかだ。4.8 では thinking なし、Fable 5 では控えめな adaptive thinking、Opus 5 では積極的な adaptive thinking になる。

注目点は 2 つある。まず、effort の dial は品質を調整するもので、コストを直接調整するものではない。low から max までの段階自体は新しくなく、4.8 も同じ範囲を受け付ける。ただし、今回のような簡単なタスクでは、low より上にすると精度が同じまま検討量だけが増えた。xhigh では 4.8 の請求額の 3.8 倍に達した。上位 level は、本当に難しい問題で test-time compute scaling を使うためにあるため、5 タスクの簡易マトリクスでは能力面を評価できない。一方、コスト面は確認できる。effort の調整だけでは 4.8 と同額にならない。デフォルトより 67% 安くして同額にできるのは、thinking を無効にした場合だけだ。次に、無効化できること自体が違いになる。Fable 5 は thinking: {"type": "disabled"} を 400 で拒否するため、これは Claude family 共通の仕様ではなく、Opus 5 固有の差別化要素だ。同じ thinking object は、gateway の /v1/messages と OpenAI 互換の /v1/chat/completions の両方で動作する。後者で無効化した場合、completion_tokens_details の reasoning_tokens はゼロになる。

{"model": "claude-opus-5", "thinking": {"type": "disabled"}}

制約もある。今回の検証可能なタスクは、検索や 1 step の処理に近い。複数段階の文章問題も含めて、thinking を無効にしても精度は 9/9 を維持した。しかし、adaptive thinking が想定している用途は、より難しい agent 処理だ。したがって、この設定は route ごとに判断すべきである。Kimi K3 と Gemini 3.6 Flash で得た結論と同じだ。抽出、formatting、1 step の call では off にし、eval で thinking がコストに見合うと確認できた route ではデフォルトのままにする。

agent workload でも 3 倍の上乗せになるのか？

ならない。この違いが重要だ。agent scenario suite では、tool loop、RAG、tooling、batch、長い chat を対象に、各条件で 50 episode を実行した。デフォルトの Opus 5 は Opus 4.8 より 33% 高いだけで、210% 増ではなかった。tool 型のシナリオでは 1.01～1.22x とほぼ同額だった。この条件では adaptive thinking が実際に適応的に動作する。agent loop 内では 1 call あたり約 88 thinking token で、単独の文章作成 prompt では 806 token だった。例外は長い chat で、1.58x になった。この場合は thinking を無効にする効果があり、1.22x まで下がる。function calling では thinking による上乗せがまったくなかった。デフォルト設定の tool call request は thinking なしの 52 出力 token で返り、thinking を使わないモデルと同じ token 量だった。

実際の使い分けはモデル単位ではなく、トラフィックの形で決めるべきだ。単独の completion や chat 型の call では、デフォルトで 3 倍の上乗せが発生するため無効化が有効になる。tool 中心の agent トラフィックでは、ほとんどの場合、無効化は不要だ。

Opus 5 は本当に Fable 5 の半額なのか？

thinking を無効にした場合だけ半額になる。token 単価では確かに半分で、Opus 5 は $5/$25、Fable 5 は $10/$50 だ。しかし、単独タスクのマトリクスでは、デフォルトの Opus 5 が 1 set あたり $0.03427、Fable 5 が $0.02233 で、絶対額では Opus 5 のほうが 53% 高かった。同じタスクで Fable 5 の出力が 383 token だったのに対し、Opus 5 は 1305 token を使ったためだ。thinking を無効にすると、Opus 5 は $0.01130 になり、Fable 5 の請求額のほぼ半分になる。これで launch 時の説明どおりになるが、そのために使うパラメータを Fable 5 自身は受け付けない。

context、cache、tokenizer についてほかに確認できたこと

1M window は実際に利用でき、上限超過時も明示的に失敗する。969950 token の prompt の先頭に置いた recall needle を 39 秒で正しく取得できた。1010221 token の prompt は、黙って truncate されるのではなく、prompt is too long: … > 1000000 maximum を返した。

cache の下限は半分になった。Anthropic のドキュメントでは、Opus 5 と Fable 5 の cache 可能な prefix の最小値は 512 token で、Opus 4.8 と Sonnet 5 の 1024 token から下がっている。実測も一致し、約 511 token の prefix は一度も cache されず、547 token では安定して cache された。cache read は $0.50/M、つまり 0.1x、write は 1.25x、TTL は 5 分だ。短い system prompt も cache できるようになり、高 QPS の route では地味だが効果が大きい。

tokenizer は Opus 5、Opus 4.8、Fable 5、Sonnet 5 で変わっていない。多言語とコードの sample では token 数がすべて同じだった。そのため、言語別の token budget や prompt size の見積もりを取り直す必要はない。

FAQ

Claude Opus 5 で thinking を無効にできるか？

できる。effort high 以下で利用可能だ。ドキュメントでは、xhigh または max と組み合わせると 400 を返すと説明されている。検証では thinking token がゼロになり、コストも Opus 4.8 と同水準になった。マトリクスでの出力 token は 384 対 384 だった。これは Opus 5 固有の機能で、Fable 5 は effort に関係なく同じパラメータを 400 で拒否する。low から max までの effort dial も使えるが、同額にはならない。今回のマトリクスでは、デフォルト比で low は -21%、xhigh は +24% だった。

同じ定価なのに、Opus 5 の請求額が Opus 4.8 より高いのはなぜか？

Opus 5 はデフォルトで思考し、その分が出力として $25/M で請求されるためだ。単独の prompt では、請求対象の出力の 42～95% が表示されない reasoning だった。2 桁の掛け算でも、1 token の回答の裏で 11 thinking token が使われた。自分のトラフィックで割合を確認するには、usage の内訳から reasoning_tokens を読む。thinking が不要な route では無効にする。

agent workload では Opus 5 の thinking を無効にすべきか？

通常は無効にしなくてよい。今回の agent suite では、デフォルトでも Opus 4.8 比で +33% にとどまり、tool と batch のシナリオはほぼ同額だった。tool loop 内では adaptive thinking がほとんど動作しないためだ。例外は長い chat 型の session で、1.58x になった。この場合は無効化の効果がある。実際のトラフィック構成で測定すべきだ。上乗せが大きいのは tool call ではなく、単独の completion である。

2026-07-25 から 2026-07-27 にかけて、Synthorai gateway 経由の claude-opus-5、claude-opus-4-8、claude-fable-5 で測定した。5 タスクのマトリクスと effort／switch の ablation は、1 つの canonical batch から取得した。各 cell は n=3、prompt には salt を加え、native Messages API を使用した。agent の数値は 150 episode の scenario suite、context と cache の検証は needle recall と prefix sweep、API 形式に関する項目である prefill と switch の受け付け可否は、直接の request 検証に基づく。精度は正解を一意に判定できるタスクだけを集計した。料金と動作は変わる可能性があるため、実際の usage record で確認してほしい。