結論 — Opus 5.5 と Sonnet 5.5 のどちらに何を任せるか
2026 年 10 月 4 日時点で、Claude の Opus と Sonnet の最新世代は Claude Opus 5.5 (9 月 22 日公開) と Claude Sonnet 5.5 (9 月 28 日公開) です。先に結論を 4 点にまとめます。
- 判断が要る複雑な作業は Opus 5.5、範囲の決まった日常の作業は Sonnet 5.5 に任せます。Anthropic は Sonnet 5.5 の発表 で、Opus 5.5 を「慎重な判断を要する複雑な作業」向け、Sonnet 5.5 を「範囲の決まった日常の作業、バグ修正、資料・スライド・スプレッドシートの作成」で最も強いモデルと位置づけています
- 料金は入力・出力とも Opus 5.5 が 2 倍です。一方、キャッシュ読み取りの単価は両方とも 100 万トークンあたり $0.20 で同額です
- 応答は Sonnet 5.5 のほうが速く、公式の相対レイテンシは Sonnet 5.5 が「Fast」、Opus 5.5 が「Moderate」です
- 迷ったら Opus 5.5 から始め、費用が気になったら先に effort (考える量の設定) を下げます。公式のモデル選びのガイド は、費用と品質の釣り合いを取るには、モデルを切り替えるより effort を調整するほうが効くことが多いと書いています
モデルの世代は数ヶ月ごとに入れ替わります。本記事では最新世代の数字を示したうえで、世代が変わっても使える判断の手順もまとめます。それぞれの変更点の詳細は Claude Opus 5.5 とは と Claude Sonnet 5.5 とは で扱っています。
スペックの違いを一枚で
数値は Anthropic の モデル一覧・料金ページ・各機能のドキュメントで 2026 年 10 月 4 日に確認したものです。料金は 100 万トークンあたりの USD です。
| 観点 | Sonnet 5.5 | Opus 5.5 |
|---|---|---|
| 公開日 | 2026 年 9 月 28 日 | 2026 年 9 月 22 日 |
| モデル ID | claude-sonnet-5-5 | claude-opus-5-5 |
| 入力 / 出力 | $2 / $10 | $4 / $20 |
| キャッシュ読み取り | $0.20 | $0.20 |
| 相対的なレイテンシ | Fast | Moderate |
| コンテキスト / 最大出力 | 100 万 / 128k トークン | 100 万 / 128k トークン |
| thinking | 既定でオン。between_tools で事前分を切れる | 常時オン。無効化できない |
| API の既定 effort | high | medium |
| 知識のカットオフ | 2026 年 6 月 | 2026 年 6 月 |
| プロンプトキャッシュの最小長 | 512 トークン | 512 トークン |
| Fast mode | — | 対応 ($8 / $40) |
| 会話途中の system メッセージ | 対応 | 対応 |
| 廃止の時期 | 2027 年 9 月 28 日より前にはならない | 2027 年 9 月 22 日より前にはならない |
前の世代と比べて、2 つの差が消えました。知識のカットオフは、Opus 5 (2026 年 5 月) と Sonnet 5 (2026 年 1 月) で 4 ヶ月ずれていましたが、5.5 では揃っています。会話途中の system メッセージは Sonnet 5 では使えませんでしたが、公式ドキュメント では Sonnet 5.5 が対応モデルに入っています。
料金 — 入力と出力は 2 倍、キャッシュ読み取りは同額
入力と出力の単価は、Opus 5.5 がちょうど Sonnet 5.5 の 2 倍です。ただし、エージェント的な作業やコーディングでは、同じ文脈を何度も読み直すキャッシュ読み取りの比率が高くなります。この単価は両方 $0.20 なので、キャッシュの比率が高い作業ほど、総額の差は 2 倍より縮みます。
仮のトークン数で 1 回分を計算すると次のとおりです。両モデルが同じトークン数を使う前提で、キャッシュ書き込みは含めていません。
| 内訳 | Sonnet 5.5 | Opus 5.5 |
|---|---|---|
| 新しい入力 20 万トークン | $0.40 | $0.80 |
| キャッシュ読み取り 200 万トークン | $0.40 | $0.40 |
| 出力 5 万トークン | $0.50 | $1.00 |
| 合計 | $1.30 | $2.20 |
この例では約 1.7 倍です。実際の請求は、モデルが同じ作業にどれだけトークンを使うかで変わります。Anthropic は Opus 5.5 の発表 で、既定の設定なら典型的な作業のコストが Opus 5 より 40% 低いとしています。Sonnet 5.5 も、Sonnet 5 と同じ単価のまま、使うトークンが減った分だけ 1 作業あたり最大 30% 安くなるとしています。単価の比だけで決めず、自分の作業を両方で流して 1 作業あたりの費用を比べてください。
補足
安いモデルで失敗してやり直すと、その分だけ総額は上がります。単価とやり直しの確率をセットで見ると、判断を誤りにくくなります。
ベンチマーク — 公式が初めて並べた 2 モデル
前の世代では、Opus 5 の発表 のベンチマーク表に Sonnet 5 は入っていませんでした。Sonnet 5.5 の発表では、Opus 5.5 と同じ表で比べています。数値は発表ページの表をそのまま引きます。
| 評価 | Sonnet 5.5 | Opus 5.5 |
|---|---|---|
| Terminal-Bench 4.0 | 70.6% | 66.4% |
| FrontierCode 1.1 (Main) | 52.1% (xhigh)・46.2% (max) | 54.4% |
| CursorBench 4.0 | 55.5% | 57.8% |
| GDPval-AA v2.1 | 1844 | 1846 |
| Humanity's Last Exam (ツールあり) | 64.5% | 67.7% |
| OSWorld 2.1 | 80.1% | 81.8% |
発表の注記では、Opus 5.5 の Terminal-Bench 4.0 は xhigh で取った最高値です。FrontierCode の Sonnet 5.5 は、max のほうが xhigh より低い結果でした。effort を最大にすれば必ず上がるわけではありません。
ターミナル操作の評価では Sonnet 5.5 が上回り、それ以外は Opus 5.5 がわずかに上です。数字の差は小さく見えますが、Anthropic は同じ発表で、ベンチマークは能力の一面にすぎず、持続した判断を要する複雑で答えの決まっていない作業では Opus 5.5 がはっきり強い、という趣旨を書いています。点差の小ささを理由に、難しい作業まで Sonnet 5.5 へ移すのは早計です。
もう 1 つ、発表には費用の話があります。Sonnet 5.5 は低い effort で Opus 5.5 を補うときに最も費用対効果が高く、高い effort では Opus 5.5 と同程度の費用で同程度の性能になる、という説明です。Sonnet 5.5 を xhigh や max で回しているなら、Opus 5.5 を試す価値があります。
実装で差が出る仕様
API から使う場合に、コードの書き方が変わる差は 4 つあります。
1 つ目は thinking の切り方です。Opus 5.5 の thinking は常時オンで、無効にできません。Sonnet 5.5 も既定でオンですが、between_tools という設定で、最初の応答の前に考える分を切れます。この設定は effort が high 以下のときだけ受け付けられます。
2 つ目は Fast mode です。Fast mode は出力速度を最大 2.5 倍に上げる仕組みで、対応は Opus 5.5・Opus 5・Opus 4.8 だけです。Opus 5.5 では 100 万トークンあたり入力 $8・出力 $40 になります。研究プレビューで、Claude API (Anthropic が直接提供する API) 限定です。
3 つ目は会話途中の system メッセージです。運用者からの指示を、キャッシュを壊さずに会話の途中へ差し込めます。Sonnet 5 では使えませんでしたが、Sonnet 5.5 と Opus 5.5 はどちらも対応しています。長い自律実行の制御を理由に Opus を選んでいた構成は、この点だけなら Sonnet 5.5 でも組めます。
4 つ目はサンプリングの設定です。Sonnet 5.5 のモデルページ では、temperature・top_p・top_k を既定以外の値にすると 400 エラーになると書かれています。
Opus 5 や Sonnet 5 からモデル ID を差し替えるときは、ほかにも 400 エラーになる書き方があります。forced tool use や thinking の無効化などで、詳しくは各モデルの速報記事にまとめました。
作業別の使い分けの目安
公式の位置づけと仕様を、作業ごとの振り分けに落とします。迷ったら、やり直しのコストが高いかどうかで決めると外しません。
| 作業 | 向いているモデル | 理由 |
|---|---|---|
| 何時間も続く自律的なコーディング・大規模な整理 | Opus 5.5 | 公式の選択表で Opus 5.5 の用途に挙がっている |
| 設計判断を含むレビュー・原因の見えない不具合 | Opus 5.5 | 持続した判断を要する作業で Opus 5.5 が強いと公式が書いている |
| 範囲の決まった実装・バグ修正 | Sonnet 5.5 | 公式が Sonnet 5.5 の得意分野に挙げている |
| ターミナル操作が中心の作業 | Sonnet 5.5 | Terminal-Bench 4.0 で Opus 5.5 を上回っている |
| 資料・スライド・スプレッドシートの作成 | Sonnet 5.5 | 公式が得意分野に挙げている |
| 対話しながら細かく直す作業 | Sonnet 5.5 | 応答が速く、試せる回数が増える |
| 待ち時間を詰めたい Opus の作業 | Opus 5.5 の Fast mode | 割増料金で出力速度を上げられる |
FIXIT点差がこんなに小さいなら、全部 Sonnet 5.5 でよくない？
Hayate使い分けの目安で言うと、判断が要る作業だけは Opus 5.5 です。点差に出ない差があります。
FIXITじゃあ Sonnet 5.5 は何に使うの？
Hayate範囲の決まった実装と修正です。low や medium で回すと Sonnet 5.5 のほうが安く済みます。
迷ったときの決め方 — effort が先、モデルは後
どちらにするか決めきれないときは、公式ガイドの Optimizing for cost and intelligence の順番が使えます。
- 費用が高いが品質は足りている場合は、いまのモデルのまま effort を下げます
- 品質が足りない場合は、effort を下げていたなら戻します。下げていないなら、1 つ上のモデルを
lowで試します - モデルを選ぶときは、トークン単価ではなく、完了した作業 1 件あたりの費用で比べます
Opus 5.5 の API の既定 effort は medium で、Opus 5 までの high より 1 段下です。Sonnet 5.5 の API の既定は high です。両者を既定のまま比べると、effort の段がそろっていない状態で比べることになります。比べるときは effort を明示してください。
さらに上が必要な場合の次の一手は Fable 5.1 です。モデル選びのガイドは、Opus 5.5 を xhigh や max にしても評価が届かない、要求の厳しい推論や長時間のエージェント作業に Fable 5.1 を勧めています。料金とプラン別の使い方は Claude Fable の料金とプラン別ガイド にまとめました。
1 本に寄せず、役割で組み合わせる
2 つのモデルを組み合わせる型として、公式ガイドは 2 つを挙げています。
| 型 | メインループを持つモデル | 上位モデルの役割 | 向いている作業 |
|---|---|---|---|
| アドバイザー型 | 安いモデル | 判断に迷ったときだけ相談を受ける | 大半は定型で、ところどころに難しい判断がある連続作業 |
| オーケストレーター型 | 上位モデル | 分割・振り分け・統合 | 独立したファイルや文書に分けられる、量の多い作業 |
flowchart TD
O["オーケストレーター<br/>Opus 5.5"] --> S1["ワーカー<br/>Sonnet 5.5"]
O --> S2["ワーカー<br/>Sonnet 5.5"]
O --> S3["ワーカー<br/>Sonnet 5.5"]
S1 --> M["結果を統合"]
S2 --> M
S3 --> M
M --> Oただし、組み合わせれば必ず安くなるわけではありません。公式ガイドの測定では、オーケストレーター型で費用が下がったのは 2 つの場面だけでした。1 つは、普段は解ける定型作業でまれに起きる高額な実行を、安いワーカー側で抑える場面です。もう 1 つは、1 つのコンテキストに収まらない量の作業です。それ以外の場面では、同じモデルの effort を下げたほうが安く済みました。
組み合わせを作る前に、まず 1 つのモデルで effort を変えて測ってください。そのうえで差が残るなら、上位モデルを low で単独で回した費用を基準にして、組み合わせがそれを下回るかを確かめます。なお、プロンプトキャッシュはモデルごとに持たれます。メインループのモデルは固定し、切り替えはワーカーとの境界だけで行うと、キャッシュを無駄にしません。
Claude Code で使うときの既定値
Claude Code では、CHANGELOG にある 2 つの変更を区別しておくと混乱しません。
- 2.1.280 で、Pro と Team Standard の既定モデルが Sonnet から Opus に変わりました。Max・Team Premium・Enterprise と同じ扱いです。同じ版で Opus 5.5 が既定の Opus になっています
- 2.1.284 で Sonnet 5.5 が追加され、Anthropic API で Sonnet を選んだときの既定になりました
Sonnet を主に使いたい場合は、/model sonnet で明示的に選び直す必要があります。effort の既定も API と違います。Sonnet 5.5 の発表によると、Claude Code と Claude のアプリでの既定は medium、Claude Platform (API) では high です。
世代が変わっても使える判断の型
ここまでの数字は、次の世代が出れば入れ替わります。前の世代から振り返ると、変わらなかったものと変わったものがはっきり分かれます。
変わらなかったのは、次の 3 点です。
- 価格の序列。Opus は常に Sonnet より高く置かれています
- レイテンシの序列。Sonnet のほうが速く、Opus のほうが考える時間を取ります
- 新しい機能が Opus 側に先に載る順番。会話途中の system メッセージは Opus 5 で使えて Sonnet 5 では使えず、Sonnet 5.5 で使えるようになりました。Fast mode は 2026 年 10 月時点でも Opus 側だけです
逆に、倍率と細かい仕様は世代ごとに変わります。価格の倍率は、Opus 4.6 と Sonnet 4.6 では約 1.67 倍 ($5 / $25 と $3 / $15) でした。いまは Opus 5 と Sonnet 5 で 2.5 倍、Opus 5.5 と Sonnet 5.5 で 2 倍です。プロンプトキャッシュの最小長も、階層ではなく世代で決まっています。
| モデル | キャッシュ最小長 |
|---|---|
| Opus 5.5 / Sonnet 5.5 / Opus 5 | 512 トークン |
| Opus 4.8 / Sonnet 5 | 1,024 トークン |
| Opus 4.7 | 2,048 トークン |
| Opus 4.6 | 4,096 トークン |
新しいモデルが出たら、次の 4 点だけ確かめれば足ります。
- 料金の倍率。入力・出力に加えて、キャッシュ読み取りの単価も見ます
- 自分の作業に近いベンチマーク。総合ではなく、任せたい作業に対応する項目を見ます
- 使っている API 機能が両方のモデルにあるか。Fast mode のように片方にしかない機能に依存していないかを見ます
- 既定の effort。新しいモデルの既定が前と違うと、effort を指定していないリクエストの考える量が変わります
前の世代 (Opus 5 / Sonnet 5) を使い続ける場合
Opus 5 と Sonnet 5 は引き続き使えます。Sonnet 5 の単価は、発表時に 8 月 31 日までの導入価格とされていた入力 $2・出力 $10 が、そのまま標準価格になりました。料金ページ の脚注には、9 月 1 日に予定されていた $3 / $15 への値上げは行われないと書かれています。Opus 5 は入力 $5・出力 $25 なので、この 2 つの組み合わせでは Opus が 2.5 倍です。
最新世代に移ると、Opus 側は単価が 20% 下がり、Sonnet 側は単価が同じまま速くなります。前の世代の特徴は Claude Opus 5 とは と Claude Sonnet 5 の 9 月値上げは中止 にまとめています。乗り換えの手順は、5.5 の速報記事にある破壊的変更の一覧から確認してください。
FIXIT の運用 — まず 2 つに分けるところから
FIXIT では、設計判断を伴う実装とレビューを Opus に、範囲の決まった修正や調査を Sonnet に振り分ける形を基本にしています。さらに上の判断が要る難所だけ Fable を使う三段構えで、世代が変わってもこの分け方は変えていません。
これから使い分けを始めるなら、まずは「やり直しが高くつく作業」と「範囲の決まった作業」の 2 つに分けるところからで十分です。前者を Opus 5.5、後者を Sonnet 5.5 に振り、そのうえで effort を下げられる作業を測りながら探すと、無理なくコストが下がります。
Claude Code そのものの導入・定着を体系立てて進めたい場合は Claude Code 全社導入 完全ガイド が出発点になります。
チームでどのモデルをどの作業に使うかのルールづくりは AI 開発ツール定着支援 で、個別のご相談は お問い合わせ から承っています。