世代が変わるたびに比べ直していては追いつかない
Claude のモデルは更新が速く、数ヶ月おきに新しい世代が出ます。そのたびに「今回はどちらが賢いのか」を調べ直していると、比較そのものが仕事になってしまいます。
そこで一段引いて見ると、Opus と Sonnet の関係には世代をまたいでも変わらない部分があります。そこを先に押さえておけば、新しいモデルが出たときに確認すべき点は数箇所に絞れます。
本記事では、階層としての Opus と Sonnet の違いを、世代に依存しない軸と世代ごとに見直しが要る点に分けて整理します。特定の世代どうしの比較は Claude Opus 5 と Sonnet 5 の使い分け で扱っています。
そもそもの階層
Anthropic のモデルは 4 つの階層で構成されています。2026 年 8 月時点の標準料金 (100 万トークンあたり) と合わせて並べると次のようになります。
| 階層 | 位置づけ | 入力 | 出力 | コンテキスト |
|---|---|---|---|---|
| Haiku | 軽量・最速 | $1 | $5 | 20 万トークン |
| Sonnet | 速度と価格のバランス | $3 | $15 | 100 万トークン |
| Opus | 難しい判断を任せる | $5 | $25 | 100 万トークン |
| Fable | 最も要求の高い推論と長時間実行 | $10 | $50 | 100 万トークン |
隣り合う階層の価格差は 1.67〜3 倍の幅があり、上に行くほど単価が上がります。Sonnet と Opus に絞ると比は約 1.67 倍です。
ここで気づくのは、Sonnet と Opus のあいだにスペック上の差がないことです。コンテキストはどちらも 100 万トークン、最大出力もどちらも 12 万 8000 トークンです。スペック表を並べても違いは見えてきません。
上下 2 つの階層はどう扱うか
実務で迷うのはほぼ Sonnet と Opus のあいだで、Haiku と Fable は例外的な位置にあります。
Haiku は Sonnet のさらに 3 分の 1 の単価ですが、コンテキストが 20 万トークンと 5 分の 1 です。分類や短い要約のように、扱う情報量が小さくて処理の本数が多い作業なら選択肢に入ります。長い文脈を渡す作業では、そもそも入りきりません。
Fable は Opus の 2 倍の単価で、最も要求の高い推論と長時間の自律実行に向きます。日常の実装で常用する階層ではなく、難所に当たったときだけ呼ぶ使い方が現実的です。
つまり中央の 2 階層で大半が片付き、上下は必要になったときだけ足す形になります。以降は Sonnet と Opus の関係に絞って見ていきます。
世代をまたいでも変わらない 3 つのこと
価格の比
Opus は Sonnet の約 1.67 倍という比が、Opus 4.6 から Opus 5 までの世代を通して維持されています。Opus 側は 4 世代にわたって入力 $5・出力 $25、Sonnet 側は入力 $3・出力 $15 で据え置かれています。
絶対額は将来変わりうるとしても、階層のあいだに一定の倍率が置かれているという構造そのものは動いていません。見積もりの前提としては、この比のほうが個別の単価より長持ちします。
この比が入力と出力の両方で同じという点も、見積もりを楽にします。入力が多い作業でも出力が多い作業でも、階層を移したときの総額の比は約 1.67 倍のままです。トークンの内訳を細かく詰めなくても、階層を変えたときの増減はおおよそ読めます。
ひとつ注意するなら、トークナイザーが世代で変わることです。Sonnet 5 は前世代の Sonnet 4.6 と比べて、同じ文章でもトークン数が 3 割ほど増えます。単価が同じでも 1 リクエストあたりの請求額は変わるので、世代を乗り換えるときは実測で確かめてください。
レイテンシの序列
Sonnet のほうが速く応答し、Opus のほうが考える時間を取ります。これは実装上の都合ではなく階層の設計そのものなので、世代が変わっても入れ替わりにくい関係です。
要点
応答が速いことは、単に待ち時間が短いという以上の意味を持ちます。対話的に使う場面では、同じ時間で試せる回数が増える分、最終的な仕上がりが変わります。
新機能が降りてくる順番
新しい API 機能は Opus 側に先に載り、1 世代ほど遅れて Sonnet に降りてきます。高解像度の画像入力に Claude で最初に対応したのは Opus 4.7 で、Sonnet 側では Sonnet 5 から使えるようになりました。推論の深さを段階指定する xhigh も Opus 4.7 で追加され、Sonnet では Sonnet 5 が最初の対応となっています。
2026 年 8 月時点で Opus 側にだけある機能としては、同じモデルを高速に動かす Fast mode と、会話の途中に運用者からの指示を差し込む system メッセージがあります。どちらも Opus 5 と Opus 4.8 で使え、Sonnet 5 では使えません。
恒久的な差ではありませんが、「最新機能を最初に試せるのは Opus 側」という順番自体は繰り返し観測できます。
世代ごとに見直しが要ること
能力の絶対値は作業によって逆転する
同じ世代どうしなら Opus が上位ですが、世代をまたぐと順序が崩れます。Sonnet 5 のシステムカードでは、前世代の最上位である Opus 4.8 と比較して次の結果が示されています。
| ベンチマーク | Sonnet 5 | Opus 4.8 |
|---|---|---|
| SWE-bench Pro | 63.2 | 69.2 |
| Terminal-Bench 2.1 | 80.4 | 74.6 |
ターミナル操作では下位階層の新しい世代が、上位階層の前世代を追い越しています。「Opus か Sonnet か」の前に「世代が古くないか」を確認したほうが効く場面がある、ということです。
古い世代を使い続けているなら、階層を上げる前に世代を上げたほうが安く効くかもしれません。
API の細かい仕様は階層で決まらない
プロンプトキャッシュが効き始める最小の長さを世代順に並べると、階層とは無関係に動いていることがわかります。
| モデル | キャッシュ最小長 |
|---|---|
| Opus 5 | 512 トークン |
| Opus 4.8 / Sonnet 5 | 1,024 トークン |
| Opus 4.7 | 2,048 トークン |
| Opus 4.6 | 4,096 トークン |
Opus 側は世代ごとに半減している一方、階層の違う Opus 4.8 と Sonnet 5 が同じ値になっています。この種の仕様は階層ではなく世代で決まるため、階層から推測せず使う世代ごとに確認してください。
新しい世代が出たら確認する 4 点
ここまでの整理を、実際に新しいモデルが出たときの手順に落とすと 4 点になります。
1 つ目は、料金の比です。階層のあいだの倍率が維持されているかだけ見れば足ります。維持されていれば、既存の見積もりはそのまま使えます。
2 つ目は、自分の作業に近いベンチマークです。前掲の表のとおり、同じ 2 モデルでもコード修正では上位階層が勝ち、ターミナル操作では下位階層の新しい世代が勝ちます。総合スコアではなく、任せたい作業に対応する項目を見てください。
3 つ目は、使っている API 機能が両方の階層にあるかどうかです。上位階層にしかない機能に依存していると、下位階層へ振り替えたときに動きません。
4 つ目は、運用に効く数値です。プロンプトキャッシュの最小長のように、階層から推測できず世代ごとに変わる値がここに入ります。
いずれも「変わったかどうか」を見るだけで済みます。世代が変わるたびにゼロから比較し直す必要はありません。
判断は 3 点で足りる
ここまでを踏まえると、モデル名に依存しない判断基準は次の 3 点に集約できます。
1 つ目は、やり直しのコストです。失敗したときの手戻りが大きい作業ほど Opus に寄せます。難所の複数ファイル改修やコードレビューがこれにあたります。単価の安いモデルで失敗すると、やり直しの分で結局は高くつきます。
2 つ目は、待ち時間が体感を左右するかどうかです。対話的なチャット、分類、要約のように応答の速さがそのまま使い勝手になる作業は Sonnet が向きます。
3 つ目は、本数です。サブエージェントのように同時に大量に並べる用途では、1 本あたりの単価がそのまま総額を決めます。ここは Sonnet の価格優位が素直に効きます。
| 作業の性質 | 寄せる先 |
|---|---|
| やり直しが高くつく難所 | Opus |
| 待ち時間が体感を左右する対話 | Sonnet |
| 定型的な実装・単発の修正 | Sonnet |
| 数で回すサブエージェント | Sonnet |
コツ
この 3 点はモデル名を含みません。次の世代が出ても、対応表の左側はそのまま使えます。
1 本に寄せず、役割で組み合わせる
実務で収まりがよいのは、どちらかに寄せる形ではなく役割で分ける構成です。全体を組み立てるオーケストレーターは Opus に置き、分担して動くサブエージェントを Sonnet にすると、判断の質を保ちながら総額を抑えられます。
flowchart TD
O["オーケストレーター<br/>Opus"] --> S1["サブエージェント<br/>Sonnet"]
O --> S2["サブエージェント<br/>Sonnet"]
O --> S3["サブエージェント<br/>Sonnet"]
S1 --> M["結果を統合"]
S2 --> M
S3 --> M
M --> O1 つ注意があります。プロンプトキャッシュはモデル単位で持たれるため、会話の途中でモデルを切り替えるとキャッシュは効きません。メインループのモデルは固定し、切り替えはサブエージェントの境界だけで行うのが定石です。
調整のつまみはモデルだけではありません。どちらの階層も推論の深さを段階で指定できます。階層の選択と深さの設定を二段構えにすると、コストと品質の落としどころを細かく取れます。
FIXIT新しいモデルが出るたびに調べ直すの、正直しんどいんだけど。
Hayate調べ直す範囲を絞ればいいです。階層の意味は変わらないので。
FIXITHayateいま使っている世代が古くないか。コスパで言うと、そこがいちばん効きます。
FIXIT の運用 — 作業で分けてから階層を当てる
FIXIT では、やり直しの高くつく実装とレビューを Opus に置き、調査や広く浅い一括変更を担うサブエージェントを Sonnet に割り当てて運用しています。さらに難しい判断が必要な場面だけ、最上位の Fable を呼ぶ三段構えです。Fable の位置づけは Claude Fable 5 の料金プラン別ガイド に整理しました。
新しい世代が出たときに見直すのは、どのモデルを当てるかだけです。この分け方にしてから、モデルの更新に振り回されることがほとんど無くなりました。
これから使い分けを始めるなら、まず「やり直しが高くつく作業」と「数で回す作業」の 2 つに分けるところからで十分です。現行世代での具体的な振り分けは Claude Opus 5 と Sonnet 5 の使い分け を、Claude Code そのものの導入と定着は Claude Code を実務に導入する完全ガイド を出発点にしてください。