Claude Sonnet 5 vs Opus 4.8: 「Opusに迫るSonnet」は本当か。価格・ベンチマーク・API挙動の違いを検証

問いの設定：Sonnetが「Opusに迫った」意味

2026年6月30日、AnthropicはClaude Sonnet 5（開発コードネーム「Fennec」）をリリースした。 キャッチコピーは「Opus 4.8に迫る性能を、Sonnet価格で」。 Sonnet 4.6の時代は「安くて速いがOpusには届かない中位モデル」という位置づけが明確だったが、 Sonnet 5はコーディングとエージェントタスクを中心に大幅にスコアを伸ばし、 一部のベンチマークではOpus 4.8を逆転するまでになった。

こうなると「そもそもフラッグシップのOpus 4.8を使う理由はどこに残るのか」という問いが立つ。 この記事では価格・ベンチマーク・そして見落とされがちなAPI挙動の違いの3軸で両モデルを比較し、 「どのシーンでどちらを選ぶべきか」の判断基準を整理する。 結論を先に言えば、答えは「デフォルトをSonnet 5に、要件を満たせない時だけOpus 4.8に昇格」だ。

スペック比較

まず注目すべきは、Sonnet 4.6 vs Opus 4.8のときにあった「コンテキスト窓の壁」（200K vs 1M）が消えた点だ。 Sonnet 5は1Mトークンコンテキストと128K出力を備え、この2つのスペックではOpus 4.8と完全に並んだ。

ベンチマーク比較

Anthropic公式データおよび独立測定によると、Opus 4.8はコーディング精度で依然として先行するが、 その差はSonnet 4.6時代よりも大幅に縮まっている。しかも一部のベンチマークではSonnet 5が逆転している。

コーディング性能

SWE-bench Verified（GitHubのissueを自律解決）はOpus 4.8が88.6%、Sonnet 5が85.2%で差は3.4ポイントまで縮まった。SWE-bench Pro（より難しいマルチ言語）では 69.2% vs 63.2%で6ポイント差とやや開く。一方、Terminal-Bench 2.1（コマンドライン習熟度）では Sonnet 5が80.4%とOpus 4.8の74.6%を5.8ポイント上回る逆転が起きている。

エージェント・知識労働性能

エージェント系ではさらに拮抗する。OSWorld-Verified（デスクトップ操作）は81.2% vs 83.4%で 2.2ポイント差、BrowseComp（自律ウェブ検索）ではSonnet 5が84.7%と高スコアを記録している。 知識労働ベンチマークのGDPval-AA v2にいたっては、Sonnet 5が1,618・Opus 4.8が1,615とほぼ互角（むしろSonnet 5がわずかに上）だ。 Anthropicがこのモデルを「史上最もエージェント性能に優れたSonnet」と呼ぶのは誇張ではない。

総合比較テーブル

コスト計算：年間いくら違うか

ベンチマークが拮抗してきた今、選択を左右する最大の要因はコストだ。 典型的なAPIコール（入力10,000トークン＋出力2,000トークン）での比較を示す。

月100万コールの規模では年間480万円の差が生まれる。 さらにSonnet 5は2026年8月31日まで導入価格（入力$2 / 出力$10）が適用される。 導入価格なら1コール$0.040となり、Opus 4.8（$0.100）に対して実質2.5倍安い。 ベンチマーク差が数ポイントに縮まった状況で、この価格差を埋めるだけの価値が全タスクにあるかは用途次第だ。

見落としがちなAPI挙動の違い

価格とベンチマークは記事でよく語られるが、実装でハマるのはAPI挙動の差だ。 Sonnet 5とOpus 4.8は同じ世代（budget_tokens廃止、サンプリングパラメータ廃止、prefill廃止、adaptive thinking） を共有するが、いくつか重要な違いがある。

① adaptive thinkingのデフォルトが逆

最もハマりやすいのがこれ。thinkingパラメータを省略した場合の挙動が両モデルで逆になる。

Sonnet 4.6から移行してきたコードがthinkingを指定していない場合、 Sonnet 5では意図せず思考トークンを消費し、max_tokensを圧迫して出力が途中で切れることがある。 意図を明確にするため、両モデルともthinkingは明示的に指定するのが安全だ。 なお両モデルともbudget_tokensは廃止されており、思考の深さはoutput_config.effort（low〜max、コーディング/エージェント用途はxhigh推奨）で制御する。

② Fastモードと会話途中systemメッセージはOpus専用

Opus 4.8にはFastモード（入力$10 / 出力$50、最大2.5倍速）がある。 リアルタイム対話でOpus品質と速度を両立したい場面向けの機能で、Sonnet 5には存在しない。

もう一つのOpus 4.8専用機能が会話途中のsystemメッセージだ。messages配列に{role: "system"}を追加することで、 トップレベルのsystemを書き換えずに（＝プロンプトキャッシュを壊さずに） 途中でオペレーター指示を注入できる。モード切替や動的コンテキストの追加に有効だが、 この機能もSonnet 5では利用できない（非対応モデルは400エラーになる）。

ユースケース別推奨

ベンチマーク差が縮まり、コンテキスト窓も並んだ今、選択基準は「最高精度が本当に必要か」「トラフィック量」「Opus専用機能が要るか」の3軸に整理できる。

判断フローチャート

以下の順番で自問することで、モデル選択を素早く決められる。

まとめ：デフォルトはSonnet 5、昇格は要件ベースで

Sonnet 5は「Opus 4.8に迫る」という触れ込みに違わず、ベンチマークの多くで数ポイント差まで肉薄し、 Terminal-Bench 2.1やGDPvalでは逆転・互角にまで達した。 1Mコンテキスト・128K出力というスペックも並び、Sonnet 4.6時代にあった「窓の壁」は消えた。

それでもOpus 4.8を選ぶ理由は残る。整理すると次の通りだ。

• 日常的なコーディング・CLIエージェント・ウェブ検索・高トラフィックAPI → Sonnet 5で十分（むしろ有利）
• 最難関のマルチ言語コーディング・最高精度の長期エージェント → Opus 4.8の数ポイント差が効く
• Fastモード・会話途中systemメッセージが必要な設計 → Opus 4.8一択（Sonnet 5に機能が無い）

タスク設計のベストプラクティスは「デフォルトをSonnet 5にし、 精度・機能の要件を満たせないと判断したときだけOpus 4.8に昇格させる」という段階的アプローチだ。 Sonnet 4.6 vs Opus 4.8のときと結論の形は同じだが、Sonnet側が強くなったぶん「昇格が必要になるシーン」がさらに減ったのが今回の本質的な変化と言える。

理解度チェック