Claude Sonnet 5でOpus不要に？コスト設計を見直す

朝Claude Codeを開いたら、いつの間にかClaude Sonnet 5になっていました。

Opus 4.8に重いタスクを投げ続けてきた人は、「月の請求、もしかして減らせたんじゃないか」という気持ちになりませんか。

Sonnet 5のベンチマークを見ると、その感覚は当たっているかもしれません。

今回はSonnet 5の中身と、Opusとの使い分けをどう設計し直すかをまとめます。

こんにちは。もるふぉです。

Claude Sonnet 5で何が変わったのか ─ 最もエージェント的なSonnet

これまでのSonnetは「速くて賢いけど、自律ループは少し弱い」という立ち位置でした。

Sonnet 5は、その自律性が別物のレベルになっています。

ブラウザとターミナルを自律で動かすエージェント性能

公式は「最もエージェント的なSonnet」と打ち出していて、ブラウザ操作・ターミナル実行・複数ステップの計画立案を上位モデルに頼らずSonnet単体でこなせる設計です。

これまでは長時間ループや複雑なツール連鎖を任せるとSonnetが途中で迷子になり、結局Opusに投げ直すパターンが多かったんですよね。

あの「Sonnetじゃ無理か、またOpus課金か」の感覚、エージェントを常時走らせているとじわっとストレスになってきます。

Sonnet 5はその「途中で諦めない粘り」が明確に伸びています。

Sonnet 4.6に引き続き1Mトークンのコンテキストウィンドウを備えているので、大規模リポジトリを丸ごと読ませてリファクタ計画を立てさせる使い方もそのまま継続できます。

ベンチマーク比較：Sonnet 5 vs Sonnet 4.6 vs Opus 4.8

数字で見るとOpusとの距離感がはっきりします。

注目してほしいんですが——Terminal-Bench 2.1でSonnet 5（80.4%）がOpus 4.8（74.6%）を5.8ポイント上回っています。

ターミナル操作を伴う自律タスク、つまりClaude Codeが最も使われる場面で、SonnetがOpusを逆転した。

正直、予想していた人は少ないはずです。

HLEのツール有スコアも見てください。

Sonnet 5の57.4%とOpus 4.8の57.9%はほぼ同点です。

ツールを駆使する複合タスクならSonnetで足りる場面が一気に増えた、という見方が現実的になってきました。

このベンチマークの逆転、あなたの Claude Code の設定に今日から直接関係してきます。

Claude CodeのデフォルトがSonnet 5になった現場インパクト

Claude Code Sonnet 5はリリース当日から自動展開が始まっています。

普段使いの設定が静かに置き換わっているので、まず手元の挙動確認が先です。

Proプランで自動切り替え ─ Claude Code Sonnet 5の設定確認

Claude CodeのProプランはデフォルトモデルがSonnet 5に切り替わります。

claude --modelで固定指定していない場合、知らないうちに新しいSonnetで動いている状態です。

モデルを固定しているチームは、設定のmodel値をclaude-sonnet-5に更新する必要があります。

Sonnet 4.6のままだと旧モデルで動き続けるので、品質が想定と違う時はまずここを疑ってください。

Managed Agentsでも使えるようになったインパクト

Managed Agentsの選択肢にSonnet 5が正式追加されました。

今までManaged Agentsで重い処理を回すとOpus課金が積み上がっていたところが、Sonnet 5に差し替えるだけで月のコスト構造が変わります。

チーム導入を検討していたなら、ここが背中を押す材料になります。

使い分けの設計をどうするか——次のセクションが本題です。

Sonnet 5とOpus 4.8をどう使い分けるか ─ Opus不要論への現実解

「もうOpusいらないのでは」という声が出始めていますが、私の感覚では完全置き換えはまだ早いです。

タスク特性で線を引くのが現実的です。

Sonnet 5で十分なタスク / Opus必須が残るタスク

Sonnet 5に任せて問題なさそうな領域はこのあたりです。

• 中規模リファクタリング、テスト追加、ドキュメント整備
• ブラウザ操作を含む調査タスク、UI E2Eテストの自動化
• 既存設計に沿ったコード生成、CRUDレベルの新規実装
• 複数ファイルにまたがる定型的な修正

「これ、うちのタスクの大半じゃないか」という感覚があるなら、それは当たっていると思います。

一方、Opus 4.8を残したい領域もあります。

• アーキテクチャ設計の初期判断（SWE-bench Pro差6ポイントは効いてくる）
• 仕様が曖昧なまま「いい感じに作って」と投げるタスク
• 長時間の自律探索が必要な研究系タスク

ゼロから設計判断が必要な初動はOpus、設計が固まったあとの実装ループはSonnet 5、というのが現時点での私の使い分けです。

コスト試算 ─ 100万トークン出力で$15の差

出力100万トークンで単純比較するとこうなります。

• Sonnet 5（導入価格）: $10（約1,600円）
• Opus 4.8: $25（約4,000円）

差額は$15（約2,400円）、削減率にして60%です。

エージェントを常時走らせるチームなら、月単位で数万円から数十万円のオーダーで効いてきます。

8月末以降の標準価格でもSonnet 5は$15で、Opusの$25より10ドル安い水準が続きます。

裏返すと、今が一番安く検証できる期間です。

導入価格の$10/M出力で自社タスクを流して「Opusとの差が許容範囲かどうか」を判断しておけば、9月以降に価格が変わっても慌てなくて済みます。

検証の具体的な手順は次のセクションでまとめます。

8月末の価格変更前にやっておくべきこと ─ Sonnet 5料金と移行設定

Sonnet 5料金の導入価格は2026年8月31日までです。

検証コストが安いうちに、評価セットを通しておくのが最もリターンが高い動き方です。

Sonnet 5導入価格（$2/$10）の期限と検証項目

8月末までの2か月間は入力$2/M・出力$10/Mで触れます。

この期間で確認しておきたいのは次の3点です。

1. 自社の評価セット（実タスクのサンプル100件程度）をSonnet 5で流し、Opus 4.8の結果と差分を比較する
2. Claude Code Sonnet 5デフォルトでの体感速度と品質を1週間業務利用で記録する
3. Managed Agentsで動かしているパイプラインをSonnet 5に切り替えて、出力トークン量とコスト変化を計測する

ここで「Opusとの差が許容範囲」だと判断できれば、9月以降の標準価格でも安心してデフォルトをSonnet 5に倒せます。

既存エージェントパイプラインの移行判断チェック

自前のエージェント基盤を持つチームは、モデルIDを差し替える前にチェックしたい項目があります。

• プロンプトテンプレートにモデル固有の癖（Opus向けの冗長指示など）が入っていないか
• ツール呼び出しのスキーマがSonnet 5の出力傾向に合っているか
• リトライ・タイムアウト設定が1Mコンテキストを前提にできているか
• ログ・モニタリングがモデル名変更後も継続収集できる構成か

私の手元の複数の案件では、テストコードを先に書いてからモデルを差し替える運用にしています。

テストが緑のまま通れば、品質劣化は起きていないと判断できる。

差し替えの心理的ハードルがぐっと下がります。

まとめ

Sonnet 5は「Opus不要論」を一部現実にしました。

Terminal-Benchではすでに上回り、HLEも同等。

コストは半額以下。

多くの実装タスクはSonnet 5で十分回ります。

設計判断系の難所はSWE-bench Proの差（6ポイント）が残っていて、まだOpusに分があります。

今夜やることは一つだけです。

いつも使っている業務タスクを1件だけ、Sonnet 5に投げてみてください。

評価セットを整える必要はありません、手元のタスクをそのまま流すだけでいい。

挙動が変わらないと確認できたら、それが「移行を始めていい」サインです。

8月末の価格変更を「気づいたら高くなってた」で迎えないために、検証はいま動いておくのが安全です。