「良いモデルは高い、安いモデルは品質に妥協」——LLMをアプリやエージェントに組み込むとき、私たちはずっとこのトレードオフと向き合ってきました。とくにコーディングエージェントのように、何度も試行錯誤を繰り返してトークンを大量に消費する用途では、品質と価格のどちらを取るか が運用コストを直接左右します。

その二択に切り込むのが、Anthropicの新モデル Claude Sonnet 5（model id: claude-sonnet-5） です。位置づけはシンプルで、「コーディングやエージェントのような自律作業で、上位のOpusに近い品質を、Sonnetの価格帯で出す」こと。本記事では、このSonnet 5が何者で、Sonnet 4.6から何が変わり、どう使い分け・移行すればよいのかを、AI開発者の視点で整理します。

Claude Sonnet 5の要点：1Mコンテキスト、$3/$15（導入$2/$10）、effort xhigh対応
Claude Sonnet 5の要点。1Mコンテキスト・$3/$15（導入$2/$10）で、コーディング/エージェント用途で“ほぼOpus”の品質を狙う。

なお、本サイトはAI関連OSSの解説に特化しているため、本稿では「この新モデルで結局、何ができるようになる／何の制約が解ける／何の代わりになるのか」という実装者目線で読み解きます。また、Anthropic公式サイト（anthropic.com）は本稿の執筆環境からは直接取得できなかったため、確定情報（モデル仕様・APIの挙動）と、筆者の解釈・一般的な使い分けの議論とを区別 して記述します。具体的な価格・対応状況・正式な性能比較は、末尾の公式ドキュメントで必ず確認してください。

この記事のポイント
  • ・Claude Sonnet 5は1Mコンテキスト・最大128K出力。価格は$3/$15（導入$2/$10、〜2026/8/31）。
  • ・狙いは「Opus級の品質をSonnet価格で」。コーディング・エージェント用途に最適化。
  • ・アダプティブ思考が既定オンに。thinking省略でadaptive、budget_tokens手動指定は400で拒否。
  • ・思考の深さはeffort（low/medium/high/xhigh/max）で制御。xhighはSonnet系で初。
  • ・新トークナイザーで同テキストでも約3割トークン増。高解像度ビジョン（長辺2576px）もSonnet初。

1. Claude Sonnet 5とは — 何が変わったのか

まず全体像を押さえます。Claude Sonnet 5は、Anthropicの Sonnet系（中位グレード）の新世代モデル です。Sonnetは伝統的に「Opus（最上位）ほど高価ではないが、実務で十分に賢い」バランス型として位置づけられてきました。Sonnet 5はその路線を踏襲しつつ、とくに コーディングとエージェント的な自律作業 での品質を、上位のOpusに迫る水準まで引き上げることを狙っています。

品質かコストかの二択を崩す：Opusに近い品質をSonnet価格で
従来の「高品質ならOpus／コスト重視なら品質に妥協」という二択を、Sonnet 5は『近い品質を低コストで』という形で崩しにいく。

基本スペックを確定情報として並べます。コンテキスト窓は1Mトークン（最大100万トークンを一度に入力できる）、最大出力は128Kトークン。価格は 100万トークンあたり入力$3.00／出力$15.00 で、2026年8月31日までは導入価格として入力$2.00／出力$10.00 が適用されます。これは同世代のOpus（入力$5.00／出力$25.00）と比べると、入力で6割、出力で6割の価格水準であり、大量にトークンを消費する用途ほど価格差が効いてきます。

ここで読者が探している「①結局何ができる／②何を解決する／③何を代替する」に当てはめると——① 長文・大量コードを1Mの文脈に丸ごと入れて、コーディングやエージェント作業を高品質にこなせる。② 「品質を取るとコストが跳ね上がる」という従来の悩みを、Opus未満・従来Sonnet以上の品質で和らげる。③ これまでコスト都合で諦めていた高頻度・長時間のエージェント運用や、品質不足でOpusに頼っていた一部のコード生成を、Sonnet価格帯で代替し得る——という整理になります。

ただし「変わったのは品質と価格だけ」ではありません。むしろ実装者にとって重要なのは、APIの“挙動”がいくつか変わっている ことです。とくにアダプティブ思考の既定オン化、effortの段階制御、新トークナイザー、サンプリング系の制限は、Sonnet 4.6からそのままモデル名を差し替えると挙動差として表面化します。以降のセクションで、この「使ううえで効く変化」を順に見ていきます。

2. 価格と性能 — 「Opus級の品質をSonnet価格で」の意味

「Opus級の品質をSonnet価格で」というキャッチは魅力的ですが、額面どおりに受け取ると判断を誤ります。ここは確定情報（価格）と、一般的な使い分けの議論（どこで効くか）を分けて考えるのが大切です。

確定している価格を、同世代の3モデルで並べてみましょう。

モデル model id 入力 $/1M 出力 $/1M コンテキスト 立ち位置
Claude Sonnet 5 claude-sonnet-5 $3.00（導入$2.00） $15.00（導入$10.00） 1M 中位・コスパ最適化
Claude Sonnet 4.6 claude-sonnet-4-6 $3.00 $15.00 1M 前世代の中位
Claude Opus 4.8 claude-opus-4-8 $5.00 $25.00 1M 最上位・最高品質

表のとおり、Sonnet 5の通常価格はSonnet 4.6と同じ$3/$15 で、そこに 品質向上が上乗せ された格好です（さらに導入期間中は$2/$10とより安い）。一方Opus 4.8は入力$5／出力$25で、品質は最上位ですが、出力1トークンあたりの単価はSonnet 5の約1.7倍。エージェントのように出力（=生成）を大量に重ねるワークロードでは、この差がそのまま月額の運用コスト差として積み上がります。

では「Opus級の品質」をどう捉えるべきか。ここは解釈になりますが、「コーディング・エージェント用途での実用品質が、Opusに肉薄する」 と読むのが妥当です。一般論として、最難関の長時間推論・非常に複雑な計画立案ではOpus系が依然優位なことが多く、Sonnet 5がそれらすべてでOpus 4.8と並ぶわけではありません。逆に、日常的なコード生成・修正や、ツール呼び出しを反復するエージェントの実行 のように「一定品質を、回数を回しながら安く出したい」領域では、Sonnet 5のコスト効率が際立ちます。

実務的な指針はこうです。まず Sonnet 5を既定 にして評価し、品質が足りない一部の経路だけOpusへ引き上げる。エージェントは試行回数が多くトークン消費が大きいため、土台をSonnet 5にできるかどうかが、運用コスト全体を大きく左右します。「全部Opus」でも「全部Sonnet」でもなく、経路ごとに最適モデルを差す ——この発想を持てるのが、Sonnet 5が選択肢に加わったことの実利です。

3. アダプティブ思考が既定オンに — API挙動の最重要変化

ここからは 実装者が必ず知っておくべきAPIの変化 です。Sonnet 5で最も挙動に効くのが、「アダプティブ思考（adaptive thinking）が既定オンになった」 点です。

Sonnet 4.6は思考オフが既定、Sonnet 5はadaptiveが既定オンという挙動差の対比
thinkingを省略したときの既定挙動が逆転。Sonnet 4.6は思考オフ、Sonnet 5はadaptive（必要に応じ自動で思考を深める）が既定。

何が変わったのか。Sonnet 4.6まで は、リクエストで thinking パラメータを省略すると 思考オフ（拡張思考を使わない）が既定 でした。深く考えさせたいときだけ、明示的に思考を有効化していたわけです。ところが Sonnet 5 では、thinking を省略すると adaptive（アダプティブ思考）で動作 します。adaptiveは「タスクの難しさに応じて、モデルが自動で思考の深さを調整する」モードです。つまり、何も指定しなければ「必要に応じて考える」状態がデフォルトになりました。

この変化の意味は二面的です。良い面 は、特別な設定なしに、難しい問いには自動で深く考えてくれること。注意すべき面 は、Sonnet 4.6の感覚で「思考オフのつもり」でモデル名だけ差し替えると、思考が走るぶんトークン消費とレイテンシが増える 可能性があることです。コスト試算やレイテンシ要件を持つ本番では、この既定挙動の反転を見落とさないようにする必要があります。

さらに重要な破壊的変更として、思考量を直接指定していた thinking: {type: "enabled", budget_tokens: N} は廃止 され、Sonnet 5に送ると 400エラー で拒否されます。旧来は「思考に使うトークン数」を数値で渡していましたが、Sonnet 5ではこの手動指定の代わりに、後述の effort（思考の深さの段階指定） で制御する設計へ移行しました。同様に、temperature・top_p・top_k を既定値から変更 するのも拒否対象です（非既定値を送ると400）。サンプリングを細かく弄っていたコードは、ここで引っかかります。

この「思考まわりの設計の変化」を、リクエストがどう処理されるかの流れで整理すると次のようになります。

flowchart TD REQ["リクエスト"] --> TH{"thinking 指定は?"} TH -->|"省略"| ADA["adaptive
（既定オン・自動で深さ調整）"] TH -->|"enabled + budget_tokens"| ERR["400 エラー
（手動指定は廃止）"] ADA --> EF{"effort で深さ指定"} EF -->|"low / medium"| FAST["速く・安く"] EF -->|"high / xhigh / max"| DEEP["じっくり深く
（xhighはSonnet初）"] FAST --> OUT["応答"] DEEP --> OUT REQ -.->|"temperature/top_p/top_k を変更"| ERR

図のとおり、Sonnet 5では「思考はthinkingを省略してadaptiveに任せ、深さはeffortで段階指定する」のが正道です。旧来の手動指定（budget_tokens）やサンプリング変更は、右側の400エラーへ落ちます。

参考までに、Anthropic SDK（Python）でのSonnet 5呼び出しは、思考まわりを「省略するだけ」でadaptiveになります。最小形は次のとおりです。

import anthropic

client = anthropic.Anthropic()

# thinking を省略 → adaptive（既定オン）。budget_tokens も temperature も付けない
resp = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=4096,
    messages=[{"role": "user", "content": "このバグの原因を特定して修正案を出して"}],
)
print(resp.content)

ポイントは「余計な思考設定を足さない」ことです。Sonnet 4.6時代に書いた thinking={"type": "enabled", "budget_tokens": 8000} のような指定は、そのまま残すと400で弾かれます。移行時は、まずこれらの旧パラメータを 取り除く ところから始めるのが安全です。

4. effortと新トークナイザー — 思考の深さとコスト設計

思考の手動指定（budget_tokens）が廃止された代わりに、Sonnet 5では effort で思考の深さを段階的に制御 します。これがコスト設計の新しい軸になります。

effortの5段階：low/medium/high/xhigh/max。xhighはSonnet系で初
effortはlow/medium/high/xhigh/maxの5段。低いほど速く安く、高いほどじっくり考える。xhighはSonnet系で初搭載。

effort は low / medium / high / xhigh / max の5段階です。低い段ほど思考トークンを抑えて速く・安く、高い段ほど時間とトークンをかけて深く推論します。注目すべきは、Sonnet 5がSonnet系で初めて xhigh（highとmaxの間の上位段）に対応 したことです。これにより、従来は最上位Opusに頼っていた「もう一段深く考えてほしい」領域を、Sonnet価格帯で踏み込めるようになりました。

実務での段の選び方は、用途に対応させると分かりやすくなります。

・low — 分類・抽出・整形など、考える余地が小さい定型処理。速度とコストを最優先
・medium — 通常のコード生成・修正、一般的なQ&A。標準的なバランス
・high — 複数ファイルにまたがる変更、設計の伴うリファクタなど、じっくり考えたい作業
・xhigh — 難しいバグの原因調査、込み入った仕様の実装判断など、一段深い推論が要る場面
・max — 最難関の問題に全力。コスト・遅延は最大になるため、ここぞという経路に限定する

全部をmaxにしないこと が肝心です。深い段ほど思考トークンが増え、コストとレイテンシに直結します。エージェントの各ステップで一律にmaxを使うと、せっかくのSonnet価格の優位を自分で潰しかねません。経路ごとに最適な段を測って差す のが、Sonnet 5を安く賢く使うコツです。

もう一つ、コストに直接効く確定情報があります。Sonnet 5は新しいトークナイザーを採用しており、同じテキストでもSonnet 4.6比で約3割多くトークンを消費 します。これは「1リクエストあたりの入力・出力トークン数が増える」ことを意味し、単価が同じでも 実質コストが上振れし得る ということです。したがって、Sonnet 4.6からの移行時は、過去のトークン数の見積もりをそのまま流用せず、count_tokens（トークン数計測）などで実測し直す のが安全です。価格表の$/1Mだけ見て「同じ$3/$15だから据え置き」と判断すると、トークン増加分で予算がずれます。

このトークナイザー差は地味ですが、月間数千万〜数億トークンを回す規模では無視できないインパクトになります。「単価×トークン数」の両方が変わり得る ことを前提に、移行前後で同一ワークロードのコストを並べて比較するのが、堅実な進め方です。

5. 1Mコンテキストと高解像度ビジョン — 入力側の進化

出力・思考だけでなく、入力側（受け取れる情報量と精細さ） もSonnet 5の強みです。コーディングやエージェント用途では、ここが品質を大きく左右します。

1Mコンテキスト、128K出力、長辺2576pxの高解像度ビジョン
1Mの文脈に長文・大量コードを丸ごと入力でき、長辺2576pxの高解像度画像で図やUIの細部まで読み取れる。高解像度ビジョンはSonnet初。

コンテキスト窓は1Mトークン。これは、大規模なコードベースの関連ファイル群、長大な仕様書、過去のやり取りの全履歴などを、分割せずに一度に渡せる ことを意味します。エージェントが「どのファイルを読むべきか」を都度探し回る代わりに、関連文脈をまとめて持たせられるため、文脈の取りこぼしによる的外れな出力 が減りやすくなります。最大出力128Kも、長いコードや詳細なレポートを一度に生成しきるうえで効いてきます。

そして注目は 高解像度ビジョン。Sonnet 5は、Sonnet系で初めて長辺2576pxまでの高解像度画像入力に対応 しました。従来より細かい画像を、ダウンスケールで潰さずに読み取れるということです。これが効く場面は具体的です——設計図・アーキテクチャ図の細部、UIのスクリーンショットに写る小さな文字やボタン、密なダッシュボードやグラフの数値、手書き図や注釈 など。「画像の細かいところが読めずに誤読する」という、マルチモーダル運用でありがちな失敗を減らせます。

読者の用途に引き付けると、たとえば「スクショを渡してUIのバグを指摘させる」「画面のデザインからコードを起こす」「図表入りの技術ドキュメントを丸ごと読ませて要約・実装させる」といったエージェント的ワークフローで、入力の質が一段上がる ことになります。1Mの文脈量と2576pxの精細さは、どちらも「渡せる情報を増やす／潰さない」方向の進化であり、エージェントの判断材料を厚くする土台になります。

ただし、入力を増やせば増やすほど 入力トークンも増える 点は忘れないでください。1Mまで入るからといって毎回満載にすれば、コストもレイテンシも膨らみます。前述のトークナイザー変更とあわせ、「入れられる」と「入れるべき」は別、という設計判断はここでも有効です。本当に必要な文脈・解像度を見極めて渡すのが、賢い使い方になります。

6. Sonnet 4.6からの移行 — 破壊的変更と注意点の総まとめ

最後に、Sonnet 4.6 → Sonnet 5の移行 で実際に詰まるポイントを、対処法とセットで整理します。モデル名を claude-sonnet-5 に差し替えるだけ、とはいかない箇所がいくつかあります。

移行時の破壊的変更：budget_tokens・temperature変更・思考オフ前提が通らず、thinking省略・effort・再計測へ
移行で400になりやすい指定（左）と、その新しい書き方（右）。thinkingは省略してeffortで制御し、トークンは再計測する。

移行チェックリストとして、効く順に挙げます。

・thinking: {type: "enabled", budget_tokens: N} を外す — Sonnet 5では400で拒否。思考はthinking省略でadaptive、深さはeffortで段階指定する
・思考の既定オン化を前提に試算し直す — thinking省略＝adaptiveなので、4.6の「思考オフ前提」の感覚だとトークン・遅延が増える。コスト/レイテンシ要件を再確認
・temperature・top_p・top_k の非既定値を外す — 既定値から変えると400。サンプリングを弄っていたコードは要修正
・トークン数を再計測する — 新トークナイザーで同テキストでも約3割増。過去見積もりを流用せずcount_tokens等で実測
・Bedrock等クラウド経由は前提が違う — Amazon Bedrockではthinkingをdisabledに設定し、強制的なtool_choiceを併用する必要があるなど、ファーストパーティAPIと挙動差がある。利用プロバイダの最新ドキュメントで確認
・refusal（拒否）への備え — サイバー領域などで能力が上がったぶん安全分類器が敏感。HTTP 200でもstop_reasonがrefusalになり得るので、content取得前に必ずstop_reasonを確認し、必要に応じ上位モデルへのフォールバックを用意する

とくに最初の3つ（budget_tokens／思考既定／サンプリング）は、そのままだと400エラーで即座に失敗 するため、移行時に真っ先に潰すべき箇所です。逆にいえば、これらを外して「思考はthinkingを省略してeffortで深さを指定する」という新しい書き方に合わせれば、移行自体は素直に進みます。

セキュリティ寄りの処理を扱う場合は、refusal（拒否）の扱い も実装しておくと安心です。Sonnet 5はサイバー領域を含め能力が高まっているぶん、安全性の分類器が以前より敏感で、実際は防御目的・正当な業務でも、攻撃的に見えるリクエストを断る ことがあります。APIはHTTP 200で返しつつ stop_reason を refusal にする挙動があり得るため、content を読む前に必ず stop_reason を確認 し、拒否時は上位モデルへフォールバックする、目的と防御的文脈を明示してリクエストし直す、といったハンドリングを用意しておきましょう。

総じて、Sonnet 5への移行は「旧来の思考・サンプリングの手動指定を捨て、adaptive＋effort＋実測の新しい作法に乗り換える」作業だと捉えると見通しが良くなります。挙動の変化さえ押さえれば、得られるのは「Opusに近い品質を、Sonnet価格で、1M文脈と高解像度ビジョン付きで」という、なかなか強力な土台です。

まとめ：Sonnet 5は「品質×コスト」の前提を更新する

Claude Sonnet 5は、1Mコンテキスト・$3/$15（導入$2/$10）で、コーディングやエージェント用途で“ほぼOpus”の品質を狙う新モデルです。実装面では、アダプティブ思考が既定オンになり、思考の手動指定（budget_tokens）が廃止されてeffort（low〜max、xhighはSonnet初）で深さを制御する設計へ移行。新トークナイザーで同テキストでも約3割トークンが増え、長辺2576pxの高解像度ビジョンと1M文脈で入力の質も上がりました。Sonnet 4.6からの移行は、budget_tokens・非既定のtemperature等を外し、トークンを再計測し、クラウド経由やrefusalの挙動差に備えるのが要点。『品質か、コストか』の二択を、Sonnet 5は『近い品質を低コストで』という形で更新します。最新の正確な値は必ず公式ドキュメントで確認してください。

まとめ

本記事では、Anthropicの新モデル Claude Sonnet 5 を、API挙動の変化を軸にAI開発者の視点で解説しました。

要点は3つです。第一に、Sonnet 5は1Mコンテキスト・$3/$15（導入$2/$10）で、「コーディング・エージェント用途でOpusに近い品質を、Sonnet価格で」を狙うモデルだということ。第二に、最も実装に効く変化は アダプティブ思考の既定オン化 で、budget_tokensの手動指定は廃止され、思考の深さは effort（xhighを含む5段） で制御する設計に変わったこと。第三に、新トークナイザーで約3割トークンが増える ため、価格表の単価だけでなく トークン数も再計測 してコストを見直す必要があること。

これらを押さえれば、Sonnet 5は「品質はOpusに迫り、コストはSonnet帯、文脈は1M、画像は高解像度」という、エージェント時代に噛み合った土台になります。まずは既定をSonnet 5にして評価し、品質が足りない経路だけOpusへ上げる——その使い分けができれば、品質とコストのトレードオフは確実に一段やわらぎます。正確な価格・対応状況・性能の数値は、末尾の公式ドキュメントで必ず確認のうえ、自分のワークロードで実測してみてください。

参照ソース

・Introducing Claude Sonnet 5（Anthropic公式ニュース） — 本記事が解説した一次情報（Sonnet 5の発表）
・Models overview（Anthropic公式ドキュメント） — モデルID・コンテキスト・価格・対応機能の確認先
・Extended thinking（Anthropic公式ドキュメント） — アダプティブ思考・effort・thinking設定の挙動