Sonnet 5 の見出し価格は Sonnet 4.6 より低くなっています($2/$10 introductory through Aug 31, 2026, vs. Sonnet 4.6's $3/$15)。また、Anthropic 自身のローンチチャートでも Sonnet 4.6 に対する「strict improvement」とされています。そこで私たちは、その意味するところを実際に確かめるため、同じタスクで両モデルをいくつかの effort level で実行しました。結果は次のとおりです。私たちのテストでは、Sonnet 5 は試したすべての effort level で Sonnet 4.6 よりも 高くつきました。安くはならなかったのです。以下に、見つかったこととその理由を示します。
1つのタスク、単発実行。 以下のすべては1つのコーディングタスクから得られたもので、モデル/努力設定ごとに1回ずつ実行しています。具体的な数値は統計的に平均化されたベンチマークではなく、あくまで傾向を示すものとして扱ってください。再現したい場合は、正確なプロンプトと生のAPI出力のサンプルが付録にあります。ご自身のワークロードで試すことができます。
Sonnet 5は本当にSonnet 4.6より安いのか?検証してみました。
両方のモデルに同じタスクを与えました。――Pythonでtoken-bucket rate limiterをテスト付きで実装し、テストを実行し、失敗したものがあれば修正する――Claude Code CLI(claude -p --model <id> --effort <level> --output-format json)を介して行ったため、コストと所要時間はAPI responseからそのまま取得しています。実行日: 2026-07-01。
設定 | コスト | 所要時間 | ターン数 | 結果 |
|---|---|---|---|---|
Sonnet 5, effort | $0.344 | 31.6s | 5 | 6/6 tests pass |
Sonnet 4.6, effort | $0.261 | 36.0s | 6 | 7/7 tests pass |
Sonnet 4.6, effort | $0.253 | 35.3s | 5 | 7/7 tests pass |
Sonnet 5, effort | $0.349 | 36.4s | 5 | 8/8 tests pass |
Sonnet 5はmediumの努力設定ではより高速でしたが、私たちがテストしたSonnet 4.6の2つの設定のどちらと比べても、Sonnet 4.6よりコストが高くなりました。これには、より低い努力設定で動作しているSonnet 4.6も含まれます。これは、同じ努力階層同士で比較するとSonnet 5のほうがSonnet 4.6より安くなると主張する、いくつかのコミュニティの体験談とは逆です。
考えられる原因: Sonnet 5 は新しいトークナイザー上で動作します。Anthropic 自身のドキュメントによると、同じテキストに対して Sonnet 4.6 より「約30%多くのトークン」を生成します。また、Simon Willison による独立テストでは、特に英語コンテンツで最大約1.4倍多くのトークンになることが確認されました。Sonnet 5 のより低い定価では、私たちのテスト課題ではそれを完全には相殺できませんでした。さらに 2026年8月31日以降、つまり Sonnet 5 の導入価格が終了し、両モデルが同じ $3/$15 の定価になると、他に価格変更がない限り、トークナイザーの差だけでも、Sonnet 5 は同等の英語タスクに対して同じではなく、より高くつく可能性が高いことを示唆しています。(言語別の完全な内訳は当社の Sonnet 5 価格ガイドをご覧ください。)
コスト以外に、他に何が変わったのか
公式ベンチマークでは、Sonnet 5 は実際の向上を示しています。Terminal-Bench 2.1 では 80.4% 対 67.0%、SWE-bench Pro では 63.2% 対 58.1% であり、いずれも Anthropic の Claude Sonnet 5 system card によるものです(Opus 4.8 を含む 当社の完全なベンチマーク表 も参照してください)。Anthropic 自身の 発表告知 の図表では、Sonnet 5 は Sonnet 4.6 に対して「厳密な改善」と説明されています。
4つのテスト出力を自分たちで見てみると、ベンチマーク表では捉えられない1つの行動上の違いが目立ちました。Sonnet 5 は、依頼していないものを追加していました。両方の effort レベルで、テスト内で monkeypatched したフェイククロックを使い、実際の time.sleep() 呼び出しを避けていましたし、high effort では、頼まれてもいないのに rate limiter にスレッドセーフ性を追加していました。Sonnet 4.6 は、両方の effort レベルで、より文字どおりのタスク記述に近くとどまっていました。テストでは実際の time.sleep() を使い、medium effort では読みやすさのための要約表を追加しただけで、実装自体には要求された以上のものは加えていませんでした。
それは、Sonnet 5のローンチ後最初の1日に投稿された実際のユーザーフィードバックとも一致しています。あるr/claudeのスレッドでは、これを「推論の面ではSonnet 4.6から客観的にアップグレードされている...が、4.6よりもはるかに神経質に感じられる」と表現していました。私たちのテストは1つのタスクのサンプルにすぎませんが、「依頼されていない範囲をより容易に追加する」は、その同じ観察を具体的かつ明確に言い換えたものです。
アップグレードすべきですか?
アップグレードを検討すべきなのは、主なワークロードが中国語中心の場合です(トークナイザーの変更は中国語のトークン数にほとんど影響しません)。または、Terminal-Bench と SWE-bench の改善が小幅なコスト増よりも重要な、エージェント的な作業やツールを多用する作業をしている場合です。
見送るべきなのは、ワークロードが大規模で英語中心であり、かつ Sonnet 4.6 がすでに品質基準を満たしている場合です。表示価格を鵜呑みにせず、必ず自分でコスト計算をやり直してください。特に、2026年8月31日に導入価格の期間が終了してからはなおさらです。
いずれにせよ、新しくて一見安そうなモデルだからといって、自動的にタスクあたりのコストが下がると考えないでください。今回のテストでは、そうではありませんでした。
よくある質問
Anthropic が言うように、Sonnet 5 は Sonnet 4.6 に対する「厳密な改善」なのでしょうか?
Anthropic が公開した能力ベンチマークでは、はい — Sonnet 4.6 がトップに立つものは見つかりませんでした。タスクあたりのコストでは、トークナイザーの変更を考慮に入れると、私たちのテストでは逆の結果になったため、「厳密な改善」はすべてのワークロードにおけるコスト効率には及びません。
なぜ Sonnet 5 は Sonnet 4.6 よりも「より神経質」に感じられるのでしょうか?
Anthropicはこれについて具体的な内容を公開していません。私たち自身のテスト出力を見る限り、Sonnet 5はSonnet 4.6よりも、要求されていない範囲(スレッドセーフ性、より防御的なtest-clockの設定)を追加する傾向があり、Sonnet 4.6は文字通りの要求により忠実でした。これは、コミュニティの説明と一致しており、ただしその範囲はより狭いものです。
Sonnet 5 は現在デフォルトモデルですか? Sonnet 4.6 はまだ使用できますか?
Anthropicの発表によると、Sonnet 5は claude.ai においてFreeおよびProユーザー向けのデフォルトとしてSonnet 4.6に代わりました。Max、Team、Enterpriseユーザー、およびAPIユーザーは、引き続きSonnet 4.6を直接選択できます。
Sonnet 5はSonnet 4.6と比較すべきですか、それともOpus 4.8と比較すべきですか?
まったく別の判断です。このページは世代的なアップグレードについてです。もし Sonnet 5 と Opus 4.8 のどちらを選ぶかという話であれば、私たちは別の一連の一対一テストを実施しました。Sonnet 5 vs Opus 4.8: real tests をご覧ください。
オンラインで人々が投稿している「高い労力の階層のほうが安い」という主張は本当ですか?
私たちのテストではそうではありませんでした。Sonnet 5 を medium と high で、Sonnet 4.6 を low と medium で比較したところ、すべての組み合わせで Sonnet 5 のほうがコストが高くなりました。個別の事例報告はタスクによって異なります — 特定の effort レベルでの逆転を前提にする前に、実際のワークロードでご自身の比較を実施してください。
付録: 正確なプロンプトと生の出力
私たちが両方のモデルに送ったタスク:
Pythonクラス `RateLimiter(capacity: int,
refill_rate: float)` としてトークンバケット方式のレートリミッターを実装し、`allow() -> bool` メソッドで、今この瞬間にリクエストを許可するかどうかを返すようにしてください。許可される場合はトークンを1つ消費します。単調増加クロックを使用し、外部依存は不要です。これを limiter.py に保存してください。
次に、test_limiter.py を作成し、少なくとも5つのテストケースで次をカバーしてください: 容量までのバーストは成功し、その後ブロックされる、トークンは時間とともに補充される(time.sleep またはモック可能なクロックを使用)、補充レートが守られる(即時に全回復しない)、容量を決して超えない、そしてゼロ/負の容量が適切に処理される。
pytest でテストを実行し、すべて通ることを確認してください。失敗があれば、コードを修正してすべて通るまで再実行してください。最終的な pytest の出力を報告してください。
Sonnet 5(medium)実行の実際のAPIレスポンス。コストとタイミングに関連するフィールドだけを抜粋しています:
{
"duration_ms": 31616,
"num_turns": 5,
"stop_reason": "end_turn",
"total_cost_usd": 0.3438645,
"usage": {
"input_tokens": 4302,
"cache_creation_input_tokens": 60894,
"cache_read_input_tokens": 233420,
"output_tokens": 2172
}
}