Claude Sonnet 5 vs Opus 4.8（2026）：表向きは60%安い

TL;DR Anthropic は 2026年6月30日に Claude Sonnet 5 を、導入価格 100万トークンあたり $2/$10 で出荷しました。これは Opus 4.8 の $5/$25 より60%安い水準です（8月31日以降の標準価格は $3/$15 で、それでも40%安）。性能面では、Opus 4.8 が難しい作業で効く2項目を守っています。SWE-bench Pro 69.2% 対 63.2%、そしてツールなし推論で約 6.6 ポイントのリードです。価格差を静かに縮める要素が2つあります。Sonnet 4.6 よりおよそ30%多くトークンを数える新しいトークナイザーと、デフォルトで有効な adaptive thinking で、Artificial Analysis はこれを エージェントタスクあたり Opus 4.8 より約15%高いコスト と見積もっています。値札は「60%オフ」と言います。請求書は「ワークロード次第」と言います。以下では、正確な計算、ベンチマーク表、2つの実際の月額請求、そして両方を使うルーティングパターンを示します。

Claude Sonnet 5 は Opus 4.8 より表示上60%安いのですが、adaptive thinking と新しいトークナイザーのせいで、出力の多いエージェントワークロードでは同額か、それ以上になり得ます。割引は限定的な出力では本物、長いエージェント実行では幻です。

TL;DR：どちらを選ぶべきか？

ほとんどのチームにとっての答えは「Sonnet 5 をデフォルトに、難しいテールに Opus 4.8」です。以下はシナリオ別の一行結論です。

この記事の残りは、その表の裏付けとなる証拠と、コミットする前に自分のワークロードで両方を A/B テストするための10行のやり方です。

クイックスペック比較

両モデルは名目上、同じ 1M コンテキストウィンドウと 128K 最大出力を共有しています。違いは価格、トークナイザー、そしてデフォルトの thinking 挙動です。

導入時の表示価格（$2/$10 と $5/$25）は、2026年7月1日時点で anthropic/claude-sonnet-5 と anthropic/claude-opus-4.8 の ofox モデルページと一致します。導入価格と標準価格の区分、および8月31日の締切は Anthropic 公式の価格ドキュメントに基づきます。標準の出力レートに注意してください。導入期間が終わると Sonnet 5 は $15/M に着地し、Opus 4.8 の $25/M に対して出力差は60%から40%に縮まります。

価格差は本物。正確な計算はこうなる。

トークン単価では、Sonnet 5 は本当に安く、しかも全項目で安くなっています。入力、出力、キャッシュ済み読み取りのいずれもです。

導入期間中（2026年8月31日まで）、Sonnet 5 は $2/$10 で Opus 4.8 の $5/$25 に対抗します。これは入力60%オフ、出力60%オフです。8月31日以降は標準価格の $3/$15 に切り替わり、両項目とも40%オフになります。キャッシュ済み入力の読み取りは $0.2/M 対 $0.5/M で、導入期間に関係なく維持される60%削減であり、プロンプトキャッシュを多用する本番トラフィックでは大きな意味を持ちます。

つまり、あなたのワークロードが入力トークン主体で、短く限定的な出力を生むなら、Sonnet 5 は見出しどおりの働きをします。話が複雑になるのは、大量の出力を生成するもの、つまりエージェント作業のほとんどです。

スペック表の中でも、通常より重く見るべき行が1つあります。キャッシュ済み入力です。Sonnet 5 はキャッシュ済み入力を $0.2/M で読み取り、Opus 4.8 の $0.5/M に対抗します。プロンプトが大きく安定した接頭部（システムプロンプト、ツールスキーマ、呼び出しをまたいで繰り返される取得済み文書群）を持つなら、本当の節約はプロンプトキャッシュにあり、Sonnet 5 のキャッシュ読み取りは導入期間に関係なく60%安です。20K トークンの接頭部を数千回の呼び出しでキャッシュする本番 RAG エンドポイントは、その接頭部に対して Opus 4.8 なら $0.5/M のところ、Sonnet 5 なら $0.2/M で支払います。落とし穴は書き込み側です。Sonnet 5 はキャッシュを $2.5/M（5分）または $4/M（1時間）で書き込み、Opus 4.8 の $6.25 と $10 に対抗します。そのためキャッシュは Sonnet 5 のほうが早く元が取れますが、それは書き込みを償却できるだけヒット率が高い場合に限ります。おおよそ 1:1 から 1.5:1 の読み書き比を下回ると、どちらのモデルでもキャッシュは節約より高くつきます。

新しいトークナイザーと、実際に影響を受けるのは誰か

Sonnet 5 は新しいトークナイザーを搭載しています。これは今回のローンチの中で最も請求書上あなたを驚かせやすい部分であり、同時に最も誤読されやすい部分でもあります。

検証済みの事実は、Anthropic の「What’s new in Sonnet 5」ドキュメント から直接得たものです。同じ入力テキストが、Sonnet 5 では Sonnet 4.6 よりおよそ30%多くのトークンを生成します。コミュニティの計測では、内容に応じて 1.0〜1.35 倍の幅に収まります。API 変更ではありません（リクエスト、レスポンス、ストリーミングは同じ形を保ちます）が、トークンで数えるものすべてを動かします。

避けるべき誤読はこれです。この30%は Opus 4.8 に対してではなく、Sonnet 4.6 に対して 計測されています。Anthropic はこの種のトークナイザー変更を Opus 4.7 のころ、より早い段階で導入済みなので、Opus 4.8 はすでに同等の前世代トークナイザーで動いています。同じテキストなら、Sonnet 5 と Opus 4.8 はおおよそ同じトークン域に着地します。トークナイザーが最も強く効くのは、Sonnet 4.6 から Sonnet 5 へ移行して 古いトークン予算を使い回すときであって、Sonnet 5 と Opus 4.8 のどちらかを選ぶときではありません。

実践的な結論。Sonnet 4.6 から来るなら、トークンカウント用エンドポイントでプロンプトを数え直し、想定出力に近く設定した max_tokens を見直してから、「同じ $3/$15 価格」という枠組みを信用してください。同じトークン単価、より多いトークン、より高い請求。私たちの Claude Code トークン最適化ガイド では、キャッシュとプロンプト削減でそれを取り戻す方法を解説しています。

コーディングベンチマーク：SWE-bench Pro と本当の差

コーディングベンチマークはノイズが多いのですが、SWE-bench Pro は議論に値する1つです。実際の GitHub イシューに対してエンドツーエンドで走るからです。以下が両モデルの着地点で、参照として Sonnet 4.6 も並べます。

SWE-bench Pro と GDPval-AA v2 の数値は、2026年6月30日に MarkTechPost が Anthropic のローンチ資料からまとめたものです。約 6.6 ポイントのツールなし推論差は、MarkTechPost ではなく Anthropic の System Card（digitalapplied.com と codingfleet.com 経由）に基づきます。リーダーボード式のスコアはスナップショットとして扱い、ベンチマークごとのソースは Anthropic の Transparency Hub を参照してください。この表の2点が、ほとんどのルーティング判断を決めます。

Opus 4.8 は SWE-bench Pro で6ポイントのリードを守っています。 63.2% の Sonnet 5 は、Sonnet 4.6 の 58.1% から確かに大きく飛躍していますが、難しくマルチファイルなエージェント課題では、Opus 4.8 の 69.2% がいまだ超えるべき数字です。SWE-bench Pro での6ポイントは、「初回実行でイシューをクローズする」と「リトライ後にクローズする」の差であり、長いエージェントループではそれがトークン消費として積み上がります。あなたの作業がその天井付近にあるなら、リトライを数え入れた時点で、安いモデルは実際には安くありません。

Sonnet 5 はナレッジワークで僅差で勝ちます。 GDPval-AA v2 の経済作業リーダーボードでは、Sonnet 5 が Opus 4.8 を Elo で3ポイント上回ります（1,618 対 1,615）。これはノイズの範囲内ですが、要点は変わりません。最も難しいコーディングではない一般的なプロ作業では、Sonnet 5 は2倍以上のコストがかかるモデルと同等ということです。Anthropic 自身の説明では、Sonnet 5 の高 effort モードは一部のタスクで Opus 4.8 に匹敵しつつ、より広いコストパフォーマンスの幅を提供するとしています。

これら2つのベンチマークが実際に何を測っているかを知っておくと、重み付けに役立ちます。SWE-bench Pro は、実際の未解決 GitHub イシューに対してモデルをエンドツーエンドで走らせます。モデルがリポジトリを読み、パッチを書き、そのパッチがプロジェクトの隠しテストスイートに通るか通らないかです。部分点はなく、だからこそ絶対値が多肢選択式の評価に比べて低く見えるのです。GDPval-AA v2 は別の形です。実際の経済的ナレッジワーク（起草、分析、構造化推論）を他モデルとの Elo レーティングとして採点するため、3ポイント差はコイントス、100ポイント差は決定的です。合わせて読むと、両表は1つのことを明確に語ります。Opus 4.8 は難しいコードイシューのクローズで明確に優れ、Sonnet 5 は一般的なプロ用途では同等ということです。それこそが、単一の勝者を選ぶのではなくルーティングする理由の全てです。

価格の計算：2つの実際の月額請求

値札は1つの数字です。請求書は別の数字です。以下は正反対の結論を導く2つのワークロードで、自分の値に差し替えられるよう前提を明示してあります。

シナリオ A、大量・限定出力（サポートボット、分類、抽出）。月あたり入力3億トークン（半分をキャッシュ配信）、出力3,000万トークンと仮定します。

ここでは割引は見出しどおりです。出力が限定的なので、安いトークン単価がそのまま最終行に反映されます。

シナリオ B、エージェントコーディング（長いマルチステップ実行、thinking 有効）。開発者5人、各自1日25タスク、20営業日（月2,500タスク）と仮定します。1タスクあたり：入力は両モデルとも 60K。出力は Opus 4.8 が 12K、ただし Sonnet 5 は約 30K です。adaptive thinking がデフォルトで有効で、1タスクあたりの推論が多いためです。

標準価格では、出力の多いエージェントワークロードは Sonnet 5 のほうが Opus 4.8 よりわずかに 高く なり得ます。余分な thinking トークンが出力行に乗るからです。私の例示モデルでは +5% ですが、Artificial Analysis の独立した実行コスト試算では +15% 寄り（1タスクあたり $2.29 対 Opus、2026年6月下旬のスナップショット）でした。正確な数字はタスクがどれだけ思考するかに依存します。方向性は変わりません。表示上の割引は、長いエージェント実行との接触に耐えません。 これは、エージェント群を移行する前に腹落ちさせておくべき最も重要な1点です。

Claude Sonnet 5 を選ぶべきとき

出力が限定的で量が多いときは anthropic/claude-sonnet-5 を選びましょう。具体的には：

• 分類、抽出、ルーティング、モデレーション。 短い出力、膨大な入力量、多くの場合キャッシュ多用。Sonnet 5 の $2/$10 と $0.2/M のキャッシュ読み取りが、これらの請求を40〜60%削減します。
• RAG 回答と要約。 重い仕事は検索が担い、モデルは限定的な応答を書きます。性能は十分で、価格が勝ちます。
• 日常的なコーディング。 単一ファイルの編集、定型コード、テストの足場、コードレビューコメント。Sonnet 5 の SWE-bench Pro 63.2% は、最前線ではない作業には十分すぎます。
• チャットとアシスタント面。 インタラクティブなやり取りは短く、Sonnet 5 の速度と価格は Opus クラスのモデルよりもフィットします。

Claude Opus 4.8 を選ぶべきとき

タスクが十分に難しく、最初の答えを間違えるコストが価格差を上回るときは anthropic/claude-opus-4.8 を選びましょう：

• 最前線のエージェントコーディング。 SWE-bench Pro の6ポイントリードは、1回の実行とリトライループの差です。難しいマルチファイルのイシューでは、Opus 4.8 はより少ないターンで終わり、少ないターンは少ないトークンです。このモデルは Opus 4.8 リリースレビュー で詳しく取り上げています。
• ツールなしの長期推論。 約 6.6 ポイントのツールなし推論差は、複雑なマルチステップ問題で「計画が破綻せずまとまる」として表れます。
• Sonnet 5 を計測して同等か高くなった、出力の多いエージェントループ。 タスクあたりコストがどちらでも同じなら、ベンチマークが高いモデルを取りましょう。

どちらも選ばないとき（そして代わりに何をするか）

罠は、これを二者択一の乗り換えとして扱うことです。ほとんどの本番ワークロードは混在しています。大量の安価で限定的な呼び出しに、本当に難しいタスクの小さなテールが付いた形です。それをすべて1つのモデルに押し付けると、簡単な80%に払いすぎるか、難しい20%で力不足になります。

解決策はルーティングです。限定的で大量の作業は Sonnet 5 に、難しいテールは Opus 4.8 に送り、両方を1つのエンドポイントの背後に置くことで、モデルの切り替えを再統合ではなく文字列1つの変更にします。そのパターンと、ルーティングシグナルの選び方は、私たちの Claude Code ハイブリッドルーティングパターン の記事にあります。ofox を通じて両モデルは同じ OpenAI 互換 API 上に載っているため、ルーターは2つ目の SDK ではなく辞書引きで済みます。

ルーティングの難しいところは配管ではなく、シグナルです。リクエストごとに、実行前にそのタスクが難しいかどうかをどう判断するか？ 実務では3つのシグナルが効きます。入力長は最も安価な代理指標です。あるトークン閾値を超えるリクエストは、Opus 4.8 が報われるマルチファイル・高コンテキストのタスクである傾向があるからです。自分のアプリケーションからのタスク種別タグ（分類 対 オープンエンドなエージェント作業）は、すでに持っているならより正確です。そして信頼度チェックはフォールバックとして機能します。まず Sonnet 5 を走らせ、安いモデルの出力が検証ステップに失敗したときだけ Opus 4.8 にエスカレーションします。エスカレーションパターンは Opus のシェアを小さく保ちます。それこそが狙いです。Opus は高価なティアであり、作業が許す限り稀にしか触りたくないからです。

flowchart TD
    A[Incoming request] --> B{Bounded output?<br/>classification, RAG, chat}
    B -->|Yes| C[anthropic/claude-sonnet-5]
    B -->|No| D{Frontier coding or<br/>long-horizon reasoning?}
    D -->|Yes| E[anthropic/claude-opus-4.8]
    D -->|No, measure it| F[A/B both, pick lower per-task cost]

ofox で両方を試す：10行で A/B

これに決着をつける誠実な方法は、自分のワークロードで両方を走らせてトークン数を読むことです。ofox は両モデルを1つの OpenAI 互換エンドポイント（https://api.ofox.ai/v1）で公開しているので、実行間で変わるのはモデル ID の文字列だけです。1つ落とし穴があります。Sonnet 5 はデフォルト以外の temperature、top_p、top_k を 400 エラーで拒否するので、サンプリングパラメータはデフォルトのままにしてください（以下の例はそうしています）。

Python：1ループで両モデルを A/B

from openai import OpenAI

client = OpenAI(base_url="https://api.ofox.ai/v1", api_key="YOUR_OFOX_KEY")

prompt = "Refactor this function to remove the nested loop: ..."
for model in ["anthropic/claude-sonnet-5", "anthropic/claude-opus-4.8"]:
    r = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
    )
    u = r.usage
    print(model, u.prompt_tokens, u.completion_tokens)

各モデルの completion_tokens を読みましょう。その列に出力レートを掛けた値こそ、「安い」モデルが静かに安くなくなる地点です。

Node：同じ形

import OpenAI from "openai";

const client = new OpenAI({ baseURL: "https://api.ofox.ai/v1", apiKey: process.env.OFOX_KEY });

const prompt = "Refactor this function to remove the nested loop: ...";
for (const model of ["anthropic/claude-sonnet-5", "anthropic/claude-opus-4.8"]) {
  const r = await client.chat.completions.create({
    model,
    messages: [{ role: "user", content: prompt }],
  });
  console.log(model, r.usage.prompt_tokens, r.usage.completion_tokens);
}

これを代表的な20〜30タスクで走らせ、モデルごとに入力と出力のトークンを合計し、スペック表のレートを掛けてください。その数字は、どのモデルをどこにルーティングするかを決める上で、どんなベンチマークよりも役立ちます。Claude ライン全体の詳しい価格内訳は、私たちの Claude API 価格ガイド をご覧ください。

移行時の落とし穴：Sonnet 5 へ移ると何が壊れるか

Sonnet 5 は形の上では Sonnet 4.6 のドロップイン置き換えですが、古いコードが 4.6 のデフォルトを前提としていると、3つの挙動変更が 400 エラーを返します。これらはほとんどの場合、Opus 4.8 のコードに対しても当てはまります。

max_tokens は見落としやすい失敗です。出力予算を Sonnet 4.6 に対してぎりぎりに設定していると、Sonnet 5 での同じ生成は同じテキストでも多くのトークンを生み、回答の途中で天井に当たり得ます。予算を引き上げないと、切り詰められたレスポンスを出荷することになります。もう1つ知っておくべき新しいセーフガードがあります。Sonnet 5 はリアルタイムのサイバーセキュリティ拒否を備えた最初の Sonnet 帯モデルで、これはエラーではなく成功した HTTP 200 に stop_reason: "refusal" を付けて返るため、その停止理由を明示的に処理してください。

Adaptive thinking は請求を最も動かしやすい変更で、しかもダイヤルが付いています。古い budget_tokens ノブの代わりに、Sonnet 5 は推論の深さとトークン消費を天秤にかける effort パラメータ（low、medium、high）を公開します。Opus 4.8 のワークロードを Sonnet 5 が安くなると期待して移行したのに、請求が横ばいで来たなら、まず試すべきは深い推論を必要としない呼び出しの effort を下げることです。分類呼び出しに high effort は純粋な無駄で、シナリオ B の驚きコストの多くはそこから来ています。すべての呼び出しをデフォルトのままにするのではなく、ルートごとに effort を意図的に設定しましょう。

きれいな移行テストはベンチマークスコアではありません。それは completion_tokens 列です。実際のタスクで両モデルを走らせ、価格表ではなくトークン数にルーティングを決めさせましょう。

FAQ

Claude Sonnet 5 は Opus 4.8 より優れていますか？ すべての面で、ではありません。Opus 4.8 は SWE-bench Pro（69.2% 対 63.2%）とツールなし推論（約 6.6 ポイント）でリードします。Sonnet 5 はナレッジワーク（GDPval-AA v2：1,618 対 1,615）でわずかに上回り、価格で勝ちます。Sonnet 5 のほうが良いデフォルトで、Opus 4.8 は最も難しいタスクでその割高さに見合います。

Claude Sonnet 5 は Opus 4.8 よりどれくらい安いですか？ 導入価格（2026年8月31日まで $2/$10）で60%、その後の標準 $3/$15 レートで40%です。キャッシュ済み入力も60%安です（$0.2/M 対 $0.5/M）。

Claude Sonnet 5 は新しいトークナイザーを使っていますか？ はい。同じテキストに対して Sonnet 4.6 よりおよそ30%多くのトークンを生成します。API 変更ではありませんが、4.6 から移行するならプロンプトを数え直し、max_tokens を見直してください。

Claude Sonnet 5 は価格が示すより1タスクあたりのコストが高くなるのはなぜですか？ adaptive thinking がデフォルトで有効なため、1タスクあたりの出力トークンが増えます。Artificial Analysis はおよそ1タスク $2.29、彼らのエージェント評価で Opus 4.8 より約15%高いと見積もりました。

Claude Sonnet 5 はコーディングに向いていますか？ ほとんどのコーディングには向いています（SWE-bench Pro 63.2%、Sonnet 4.6 の 58.1% から向上）。最も難しいエージェント課題は Opus 4.8 にルーティングしてください。

Opus 4.8 から Sonnet 5 に切り替えるべきですか？ 大量・限定出力の部分を切り替えれば、その請求を40〜60%削減できます。難しいテールには Opus 4.8 を残してください。置き換えるのではなく、ルーティングしましょう。

Claude Sonnet 5 のコンテキストウィンドウはどれくらいですか？ 1M トークン、最大出力 128K です。新しいトークナイザーのせいで、そのウィンドウに収まる実テキスト量は Sonnet 4.6 の同じウィンドウより少なくなります。

Claude Sonnet 5 で temperature を設定できますか？ いいえ。デフォルト以外の temperature、top_p、top_k は 400 エラーを返します。削除して、システムプロンプトで制御してください。

参照した情報源

• Anthropic「What’s new in Claude Sonnet 5」ドキュメント（トークナイザー、挙動変更、価格）、2026年7月1日検証：https://platform.claude.com/docs/en/about-claude/models/whats-new-sonnet-5
• Anthropic「Introducing Claude Sonnet 5」ローンチ投稿、2026年6月30日：https://www.anthropic.com/news/claude-sonnet-5
• Anthropic Transparency Hub（ベンチマークごとのソース）：https://www.anthropic.com/transparency
• MarkTechPost ベンチマーク集約（SWE-bench Pro、GDPval-AA v2 のみ）、2026年6月30日
• digitalapplied.com と codingfleet.com 経由の Anthropic System Card（ツールなし推論差、約 6.6 ポイント）
• Artificial Analysis 実行コスト試算（1タスク $2.29）、2026年6月下旬スナップショット
• anthropic/claude-sonnet-5 と anthropic/claude-opus-4.8 の ofox モデルページ（導入時表示価格 $2/$10 と $5/$25、コンテキストウィンドウ）、2026年7月1日検証。導入/標準の区分と8月31日の締切は Anthropic の価格ドキュメントに基づく