Claude Sonnet 5 vs Sonnet 4.6：既存ワークロードはアップグレードすべきか
Sonnet 4.6 のワークロードが coding agent、長いコンテキスト分析、コードレビュー、複雑な社内 agent であれば、Sonnet 5 は優先的にテストする価値があります。一方で、安定していて高頻度、低リスク、コスト感度が高いワークロードでは、Sonnet 4.6 またはより低コストの route が引き続き最適な default になる場合があります。
クイック判断
| 現在の状況 | 推奨される最初の動き | 理由 |
|---|---|---|
| coding agent で Sonnet 4.6 の retry が多い | Sonnet 5 を canary でテスト | 主な改善領域は coding と agentic task |
| Sonnet 4.6 が高トラフィックを安定処理している | 全面置換しない | 新 tokenizer とパラメータ変更がコストとエラーを変える可能性 |
budget_tokens や非 default sampling parameter に依存している | 先に設定を整理 | 古い設定が 400 エラーを起こす可能性 |
| trace、monitoring、fallback がない | 先に engineering 基盤を補う | observability がないと upgrade 成功を測れない |
| Opus/Fable route への escalation を減らしたい | Sonnet 5 をテスト | 難しい Sonnet task の一部を受け持てる可能性 |
つまり Sonnet 5 は、Sonnet 4.6 トラフィック全体の自動置換ではなく、新しい Sonnet main route 候補として見るべきです。
この記事が対象とする読者
この記事は次のチーム向けです。
- すでに Sonnet 4.6 を本番または準本番で使っている。
- coding agent、code review、support agent、社内 tool、document analysis など実ワークロードがある。
- model quality だけでなく retry rate、output stability、token cost、fallback、rollout risk を見ている。
- Sonnet 5 を default route にするか、高価値タスク限定 route にするかを判断したい。
重要な違いは「強さ」ではなく運用前提
Sonnet 5 は thinking behavior、parameters、token budget という 3 つの本番前提を変えます。
| 領域 | Sonnet 4.6 | Sonnet 5 | 本番チームへの意味 |
|---|---|---|---|
| Thinking behavior | thinking field がなければ thinking なしで動作可能 | adaptive thinking が default | output budget、latency、simple task route を再測定 |
| Manual extended thinking | 古い client が budget_tokens を保持している可能性 | manual budget は非対応 | rollout 前に古い設定を削除 |
| Sampling parameters | client が独自値を設定していることがある | temperature、top_p、top_k の非 default 値は 400 | request builder を監査 |
| Tokenizer | 旧 token count | 同じテキストでも token が増える可能性 | prompt budget と cost baseline を再構築 |
| Migration style | 既知の安定 baseline | 新しい Sonnet route 候補 | global replacement ではなく canary |
Thinking は output budget に影響する
max_tokens で回答が切れやすくなるか、latency variance が増えるか、simple task に Sonnet 5 が本当に必要かを確認してください。古いパラメータは品質問題ではなくエラーになる
400 で失敗する可能性があります。rollout 前に少なくとも budget_tokens、temperature、top_p、top_k を検索してください。Tokenizer 変更は実コストに効く
新 tokenizer は同じテキストをより多くの token として数える可能性があります。短い prompt では影響が小さくても、codebase、documents、tool traces、agent memory では大きくなります。正しい指標は accepted result あたりの cost です。
バージョン番号ではなくワークロードで決める
| Workload | 推奨アクション | 理由 |
|---|---|---|
| Claude Code 型 coding agent | Sonnet 5 を優先テスト | multi-step planning、tool call、test repair が改善する可能性 |
| multi-file refactor と code review | Sonnet 5 を優先テスト | file 横断理解と長い output が重要 |
| 長い document/repo analysis | 小さな traffic でテスト | context value は高いが token budget 再計算が必要 |
| internal operations agent | error cost で判断 | retry が多いならテスト価値が高い |
| support response generation | 慎重に移行 | 既存品質が十分なら cost と latency を先に確認 |
| bulk low-risk generation | 通常は優先しない | low-cost route の方が向いている |
| high-risk architecture decision | Sonnet 5 を試しつつ escalation 維持 | error cost が model cost を上回る |
最初の候補に向くのは、Sonnet 4.6 で retry、手作業修正、不安定な結果がすでに発生しているタスクです。
Sonnet 4.6 を残すべき場合
Sonnet 4.6 を baseline として残すのは保守的すぎる判断ではなく、本番設計として自然です。workload が安定かつ高頻度、prompt が 4.6 向けに強く最適化済み、request builder が複数 service に分散、または agent trace が token、tool、retry、acceptance を記録していない場合は、短期的に Sonnet 4.6 を残してください。
コストは request ではなく accepted result で見る
accepted result の総コスト
= first request
+ retries
+ tool and context cost
+ human cleanup
+ fallback| Workload | Cost risk | 測るべきもの |
|---|---|---|
| Short chat prompts | 低から中 | token count と latency |
| Long coding-agent traces | 高 | token count、retries、accepted output rate |
| Large-document analysis | 高 | context fit、cache hit、truncation |
| Repeated system prompts | 中 | cache reuse と effective input cost |
| Structured output | 中 | validation failures と retries |
EvoLink での推奨ルーティング
EvoLink では、Sonnet 5 を各 service に hardcode するのではなく、layered routing strategy の一部として扱うべきです。
| Routing layer | 推奨 | 適したケース |
|---|---|---|
| Low-cost base layer | low-cost text model または既存 stable route | classification、summary、template generation |
| Balanced Sonnet layer | Sonnet 5 with Sonnet 4.6 fallback | coding、agents、medium/long context |
| Quality escalation | Opus/Fable-class route | high-risk review、architecture、incident analysis |
| Fallback | Sonnet 4.6 または他の stable route | error/cost spike 時の rollback |
この設計の価値は、model upgrade が global code migration ではなく routing policy change になることです。
推奨移行パス
| Phase | やること | 合格条件 |
|---|---|---|
| Replay | Sonnet 4.6 と Sonnet 5 を同じ historical task で比較 | parameter error がなく output が validatable |
| Canary | 小さな割合を Sonnet 5 に送る | error、latency、cost が threshold 内 |
| Task split | high-value task を先に Sonnet 5 へ | coding と long-context task が安定または改善 |
| Default review | Sonnet 5 を default Sonnet route にするか判断 | fallback rate が低く cost が予測可能 |
| Cleanup | old parameter と temporary route を削除 | unsupported parameter path が残らない |
少なくとも 20-50 個の実 Sonnet 4.6 task を使い、成功例と失敗例を含めてください。accepted output rate、tokens per task、retries、validation failures、p95 latency、fallback rate を測定します。
証拠の境界
最終提案
すでに Sonnet 4.6 を使っているなら、Sonnet 5 はテストキューに入れるべきですが、即座に全置換すべきではありません。まず複雑で価値が高く retry の多い Sonnet task を移行し、Sonnet 4.6 を stable fallback として残し、accepted result あたりの cost で判断してください。EvoLink ではこれを routing decision として実装します。
FAQ
Claude Sonnet 5 は Sonnet 4.6 より常に優れていますか？
すべての production workload で自動的に優れるわけではありません。coding と agent task では強い候補ですが、安定した高トラフィックは replay と canary を経て移行すべきです。
Sonnet 5 は Sonnet 4.6 を default として置き換えるべきですか？
replay と canary のデータがそれを支持する場合だけです。まず Sonnet 4.6 が retry を生む workload から始めてください。
最大の behavior difference は何ですか？
adaptive thinking が default になり、manual extended thinking が削除されたことです。output budget と request configuration が変わります。
price tier が似ていても cost が変わるのはなぜですか？
新 tokenizer により同じテキストがより多くの token になる可能性があり、task あたりの effective cost が変わるためです。
古い sampling setting はどうすべきですか？
temperature、top_p、top_k の非 default 値を削除し、budget_tokens の利用箇所を確認してください。この記事は product page の代わりですか？
いいえ。access、pricing、model ID、specifications は product page が所有します。この記事は upgrade decision を支援します。
EvoLink での最適な構成は何ですか？
高価値の Sonnet task に Sonnet 5 を使い、Sonnet 4.6 または別の stable route を fallback として残し、accepted result あたりの cost を測ります。
Coding agent は最初に移行すべきですか？
良い最初の候補ですが、tokens、retries、tool calls を特に慎重に監視する必要があります。
