Sonnet 5 と Opus 4.8 を Claude Code で実測比較——コスト差1.67倍は本当に効くのか

「迷ったら上位モデル」で本当にいいのか

Claude Code を毎日使っていると、Sonnet 5 と Opus 4.8 のどちらを選ぶべきかで手が止まる瞬間があります。単純に考えれば Opus のほうが賢いはずで、迷ったら上位を選んでおけば安心という気もします。ただ Opus の出力は Sonnet の約1.67倍の値段がつきます¹。この差を毎回払う価値が本当にあるのかは、体感だけでは判断できません。

そこで、この2モデルを「上位と下位」ではなく「速さ・単価と、決定力・少ない手戻り」のトレードオフとして捉え直し、同じ課題を両方に投げて実際に測りました。プログラミング課題を1つ、執筆課題を1つ、どちらも Claude Code のサブエージェントとして同じ条件で走らせ、正答率とトークン数と所要時間と反復回数を記録しています。結論を先に言うと、定価の1.67倍という差は、Opus のトークン効率のぶんだけ実効では縮みます。ただし縮み方はタスクによって違い、そこに使い分けの勘所があります。

Sonnet 5 と Opus 4.8 の価格とスペックを並べる

比較の土台として、公開されている一次情報を並べます。モデルIDはそれぞれ claude-sonnet-5 と claude-opus-4-8 です。価格は100万トークンあたりで、Sonnet 5 には2026年8月31日までの導入価格が設定されています¹。

入力も出力も、標準価格では Opus が Sonnet のちょうど1.67倍です。導入価格の Sonnet と比べれば2.5倍まで開きます。キャッシュの読み込みは全モデル共通で入力価格の0.1倍に下がり、5分保持のキャッシュなら一度読み直すだけで元が取れます²。コンテキスト長はどちらも100万トークンで、しかも長文でも追加料金はかかりません¹。

トークナイザについては注意が要ります。Opus 4.7 以降と Sonnet 5 は新しいトークナイザを使っていて、同じ文章でも旧モデルよりおよそ3割多くトークンを数えます¹。ただし今回比較する2モデルはどちらも新方式なので、両者のあいだのトークン数比較は同じ物差しで公平にできます。

実測1 同じコーディング課題を両モデルに投げる

コーディングの実力を測るために、ISO 8601 の期間表記（P1Y2M3DT4H5M6S のような文字列）を合計秒数に変換する関数を実装させました。順序制約、週と他コンポーネントの併用禁止、符号や小文字の拒否など、仕様書に細かいエッジケースを詰め込んであります。採点はモデルに見せていない隠しテスト37件（有効17件・無効20件）で自動判定しました。両モデルに同じ仕様書を渡し、effort は high で揃えています。

結果は、正答という一点では互角でした。

両方とも37件すべてを通しました。「Sonnet 5 は範囲の絞れたコーディングで Opus に迫る」という位置づけは、少なくともこの課題では言葉どおりでした。差が出たのは解き方です。Opus はトークンをおよそ3分の2しか使わず、ファイル編集などのツール実行も3回で、時間は Sonnet の半分でした。一発で決めにいく挙動がはっきり出ています。

コードそのものにも性格が出ました。Opus は日付部と時刻部を固定順序の正規表現に丸ごと織り込み、順序違反はマッチ失敗として自然に弾く75行の簡潔な実装でした。一方の Sonnet は、いったんトークンに分解してから順序と重複を手続き的に検証する89行の明示的な実装です。どちらも正しく、読みやすさの好みは分かれますが、Opus が簡潔で決定的、Sonnet が丁寧で手数が多い、という傾向がコードの形にも表れていました。

実測2 同じ執筆課題を両モデルに投げる

次に、このブログでよく書く種類の文章を書かせました。テーマは「ローカルLLMのコンテキスト長は長ければ良いとは限らない理由」で、です・ます調・400〜550字・箇条書き禁止・具体を1つ以上、という制約をつけています。品質の一次判定には、このブログで使っている決定論的な文体チェッカー（太字の多用やコロン列挙、定型句などを検出するもの）を使い、警告の数を見ました。

どちらも文体チェッカーは警告ゼロで、AIっぽさの表層パターンは踏んでいません。ここでの違いは速さと構成に出ました。Sonnet は17秒で書き上げ、単価も安いぶん、短い文章を数多く作る用途では効率が良さそうです。Opus は少ないトークンで4段落に整理し、最後を「この記事では、その勘所を具体的に見ていきます」と本編へつなぐところまで組み立てました。導入文としての設計は Opus のほうが一枚上でした。おもしろいのは、コーディングでは速かった Opus が、執筆ではむしろ Sonnet より時間をかけていた点です。丁寧に構成を練るぶん、時間は延びていました。

定価1.67倍は実効コストでどこまで縮むか

ここまでの数字を、値段の話につなげます。定価では Opus は Sonnet の1.67倍です。ところが今回の2タスクでは、Opus のほうがトークンを少なく使いました。コーディングでは Sonnet の0.67倍、執筆では0.78倍です。単価が1.67倍でも、使うトークンが少なければ、1タスクあたりの実効コストはその積に近づきます。

つまりコーディングのような、仕様が明確で手戻りの少ない作業では、Opus を選んでも実際の支払いは Sonnet とほぼ変わらず、そのうえ倍近く速く終わる可能性があります。効率が単価差をかなり打ち消すわけです。ただし打ち消しきるわけではありません。Sonnet が導入価格（$2/$10）で動いている今の期間は定価差が2.5倍まで開くので、効率を織り込んでも Sonnet のほうが安く収まります。

この試算には正直な限界があります。ここで数えているトークンは Claude Code のハーネスが報告する合算値で、入力・出力・キャッシュの内訳までは分けられていません。厳密な円換算には、API の usage オブジェクトで内訳を取る必要があります。また各タスクは1回ずつの計測で、effort も high に固定しています。ここで示しているのは統計的な断定ではなく、傾向として読める方向性です。再現できるよう、課題・隠しテスト・両モデルの解答・計測ログは記事の companion として同梱してあります。

ベストプラクティス1 タスクで使い分ける

以上を、日々の判断に落とします。まず、正答という結果だけを見ると2モデルは競り合いますが、そこに至るまでの手数と速さが違いました。この差をタスクの性質に合わせるのが基本です。

現実的には、メインの作業を1つのモデルに固定しつつ、重い探索や並列の下調べをサブエージェントに逃がす形が扱いやすいです。Claude Code なら /model で主モデルを切り替えられますし、サブエージェントに安いモデルを割り当てれば、全体の会話のキャッシュを壊さずにコストを下げられます。難所だけ Opus に任せ、量は Sonnet で捌く、という配分が現実的な落としどころです。

ベストプラクティス2 支払いを下げる実務

モデル選び以外にも、支払いを下げる手はいくつもあります。効果の大きい順に挙げます。

第一に effort を見直します。Opus 4.8 と Sonnet 5 の effort は、Claude Code でも既定が high です³。今回のベンチもその既定の high で走らせ、コーディングは両モデルとも満点でした。つまり難所でもないのに反射的に xhigh や max へ引き上げる必要はありません。既定の high を基準にして、簡単な作業なら medium まで下げ、本当に難しいときだけ xhigh へ上げる、というスイープが無駄を生みません。effort を下げると思考と手数が減り、そのぶんトークンも減ります。

第二にプロンプトキャッシュです。キャッシュの読み込みは入力価格の0.1倍まで下がり、同じ前置き（システムプロンプトや大きな資料）を繰り返し使う作業ではここが一番効きます²。前半を固定して後半だけ変える構造にしておくと、2回目以降の入力コストが桁で落ちます。逆に、システムプロンプトに毎回変わる時刻やIDを差し込むとキャッシュが丸ごと無効になるので避けます。

第三に、速さが要るときの fast mode です。fast mode は Opus 4.8 と 4.7 だけの機能で、Opus 4.8 では入出力が $10/$50 と標準の2倍になります¹⁴。速さに割増を払う機能なので、対話的に待ち時間を縮めたい局面に絞って使うものです。時間に追われないバッチ処理なら、逆に Batch API で入出力とも50%引きになります¹。

細かいところでは、ツールを使うだけで乗るシステムプロンプトのトークンも、Opus 4.8 は290トークンとかなり軽くなりました（Opus 4.7 は675トークンでした）¹。ツールを多用するエージェント用途では、この地味な削減も積み重なると効いてきます。

拮抗と割り切りの見取り図

Sonnet 5 と Opus 4.8 は、少なくとも今回の範囲では「上位と下位」ではありませんでした。仕様の明確なコーディングでは正答が互角で、Opus は少ない手数で速く決め、Sonnet は速く安く量をこなしました。定価の1.67倍という差は、Opus のトークン効率でコーディングではほぼ拮抗まで縮み、執筆では1.3倍ほど残りました。だから難所と長時間の自走は Opus、量産と探索は Sonnet、という配分が現実的です。そのうえで effort を反射的に最大へ張らず（既定の high を基準にする）、キャッシュを効かせ、速さやバッチの割引を場面で選べば、支払いはさらに削れます。

最後に限界を正直に書きます。今回の計測は各タスク1回ずつ、effort は high 固定、トークンは内訳を分けない合算値です。統計ではなく傾向として読んでください。課題・隠しテスト・両モデルの解答・計測ログは companion として同梱しているので、手元の API キーで usage の内訳まで取れば、より厳密な円換算に置き換えられます。

参考文献