Claude Sonnet 5.5発表:コーディング性能はOpus 5.5と互角、価格は半額

Sonnet 5と同じトークン単価で、バグ修正、ツール操作、資料作成の待ち時間や反復を減らすことを狙う。公式デモとともに、何が変わったかを確かめる。

著者:Anthropic09-29 · 約12分

AnthropicがClaude Sonnet 5.5を発表した。Sonnet 5と同じ料金で使えるアップグレードであり、Opus 5.5より速く、低価格な選択肢でもある。解決しようとしているのは実務上の問題だ。バグ修正、複数ファイルの変更、資料作成はモデルにできても、試行錯誤やツール呼び出し、長い途中出力が重なると、待ち時間とタスク全体の費用が増える。Sonnet 5.5は、範囲が明確な日常業務をより速く仕上げ、長期的な判断が必要なオープンエンドの仕事はOpusに任せることを狙う。

今回の主な特徴は、まず次の四つだ。

  • 同じタスクをより速く終える。 Sonnet 5.5のAPI単価はSonnet 5と同じ。Anthropicによると、出力速度は30%以上速く、通常は使うトークンも少ない。同社のテストでは、タスク当たりの費用が最大30%下がった。
  • 一連のコーディング作業に強い。 改善はコード補完だけではない。ターミナル操作、複数ファイルの変更、ツール利用、繰り返しの修正にも及ぶ。
  • 納品物に近いオフィス成果物を作る。 資料やテンプレートを使って文書、スライド、表計算ファイルを作成できる。知識労働の一部の評価ではOpus 5.5に近いスコアを得た。
  • タスクに合わせて投入量を変えられる。 effortの設定で速度、費用、品質を調整できる。簡単な仕事まで常にMaxにする必要はない。
Claude公式のSonnet 5.5発表映像。

以下、この四点に沿って、何が速くなり、どの仕事に使え、どう設定すれば費用対効果が高いかを見ていく。

単価が同じなのに、タスク全体の費用が下がる理由

まず、混同しやすい二種類の価格を分けよう。Sonnet 5.5の料金は100万トークン当たり入力が2ドル、出力が10ドル、キャッシュ読み取りが0.20ドル、キャッシュ書き込みが2.50ドルで、Sonnet 5と同額だ。Opus 5.5と比べると、入力・出力・キャッシュ書き込みの単価は半分で、キャッシュ読み取りは同じ0.20ドルとなる。

API料金(100万トークン当たり) Sonnet 5.5 Opus 5.5
入力 2ドル 4ドル
出力 10ドル 20ドル
キャッシュ読み取り 0.20ドル 0.20ドル
キャッシュ書き込み 2.50ドル 5ドル

ただし、単価の比較だけでは重要な半分を見落とす。同じ修正を終えるモデルでも、一方が何度も検索し、書き直し、ツールを呼べば、最終的な費用は高くなりうる。Anthropicの費用対スコアの図は、横軸をタスク当たりの実際の費用、縦軸をスコアとしている。同じモデルでもLow、Medium、High、Xhigh、Maxのeffortを別々の点で示す。各評価の中では、左上にあるほど低費用で高得点だ。

複数の評価では、Sonnet 5.5のLowまたはMediumがSonnet 5の最高スコアを上回り、タスク当たりの費用は約10分の1だった。effortを高くすると、スコアがOpus 5.5に近づく場合がある一方、費用も近づく。つまり、アップグレードの価値は単に「より賢いモデル」へ替えることだけではない。通常のタスクで、少ない投入量でも使える品質に届く可能性がある。ただし「10分の1」はこれらの評価での結果であり、あらゆる請求額に適用される割引ではない。

同じビジュアル制作タスクで、両世代のモデルがコードを書き、実行画面を表示するまでを並べたClaude公式のデモ。

コーディング:一行の補完から、一連の作業の完了へ

Sonnet 5.5で最も目を引く数値は、Terminal-Bench 4.0の70.6%だ。Sonnet 5は10.3%だった。この評価では、エージェントがターミナルで複数段階の専門的な作業を行う。単発のコード補完ではなく、環境の把握、ツール操作、修正、実行、仕上げまでの一連の動きを測る。発表資料ではOpus 5.5が66.4%で、脚注はこの値がXhigh effortによるものだと明記する。Sonnetがこのベンチマークで上回っても、複雑なコーディング案件のすべてでOpusより強いことを意味しない。

ほかの二つのコーディング評価は、異なる仕事を対象にする。CursorBench 4.0は実際のCursorセッションから、曖昧さを含む複数ファイルのタスクを取り出したものだ。Sonnet 5.5は55.5%、Sonnet 5は34.1%、Opus 5.5は57.8%。FrontierCodeは、人手で修正せずにコード変更をマージできるかを測る。XhighでSonnet 5.5は52.1%、Opus 5.5は54.4%だった。三つを合わせると、プロジェクトを読み、ツールを使い、変更を加えて納品するまでの一連の作業で、大きく前進したことが分かる。

Sonnet 5.5、Sonnet 5、Opus 5.5などのコーディング、知識労働、コンピューター操作の評価をまとめた公式表
Claude公式スレッドの評価表。テストごとに単位や条件は異なる。画像を選択すると拡大できる。

実際の製品テストを見ると、こうした能力の使い道がより具体的になる。Base44は118件のアプリ構築で、Sonnet 5.5製アプリのスコアがOpus 5と同等でありながら、平均の反復回数はOpus 5の7.7回に対して3.6回だったと報告した。Unityはプロジェクトを開き直し、実行時の結果も確認するテストを行い、複数段階のエディター・コーディング作業の90%をSonnet 5.5が完了したとしている。Epic Gamesはゲームシステムの設計や数時間続く作業に言及し、CodeRabbitは簡単から中程度のコードレビューを先に移行する予定だ。これらは各社のテスト結果や計画であり、同条件の共通ランキングではない。

ClaudeDevsの短い動画には、より小さな例がある。一つの調整役が、四つのエージェントに別々の出発点からパズルを並列で解かせる。動画に記されているのは10回実行した中央値で、Sonnet 5.5は10秒、約2万3000トークン、0.11ドルで完了した。Sonnet 5は15秒、約2万8000トークン、0.15ドルだった。差はモデルの返答速度だけでなく、ツールを使う全工程で何段階かかったかにもある。

ClaudeDevs公式の並列エージェントによるパズル実演。時間、探索位置、ツール呼び出し、トークン、費用を同時に示す。

文書、スライド、表計算:資料を読むところから完成品まで

Anthropicは知識労働もSonnet 5.5の重点に据えた。財務報告書に何が書いてあるか答えるだけでなく、資料を読み、要点を整理し、指定された形式の使えるファイルにするという仕事だ。GDPval-AAは44職種・9業界のタスクを扱い、Sonnet 5.5が1844、Opus 5.5が1846、Sonnet 5が1449だった。長い工程の知識労働を評価するAA-Briefcase v1.1では、順に1811、1822、1359だ。これらのタスクではSonnet 5.5がOpus 5.5にかなり近い。

発表ページにはもっと分かりやすい例がある。上場企業の四半期決算資料、決算説明会の記録、スライドのテンプレートを渡し、10枚の事業レビュー資料を作らせた。Anthropicが依頼した二人の専門家は、初稿のまま送れると判断したという。重要なのは単に「スライドが書ける」ことではなく、資料収集、要点の抽出、テンプレートへの準拠を一つのタスクとしてつなげられる点だ。Claudeの公式スレッドには砂丘のウェブページを並べて比較するデモもあり、ビジュアル成果物を具体的に確認できる。

Claude公式のデザイン実演。同じ指示から、二世代のモデルが「風で形づくられる砂丘」の単一HTMLページを作る。

チームにとっては、「同程度の品質に何段階で到達したか」も重要だ。Slackによると、プロンプトを変更しないオフラインのSlackbotテストでSonnet 5.5はほぼ全項目でSonnet 5を上回り、出力トークンは約14%少なかった。Zendeskは数百件の返信・エスカレーション事例で、チケット処理が20%速くなったとする。Balyasny Asset Managementの非公開の金融タスク2441件では、1回答当たり約12万1000トークンで、Sonnet 5の約49万7000トークンを下回った。Lovableのコーディング評価では、ツール呼び出しが約3分の1減り、シェル実行はおよそ半減した。Boxは処理速度が2.4倍、総トークン数が12%減ったと報告し、AtlassianはRovo Agentsが最大30%速くなると見込む。いずれも企業とタスクが異なる数字だ。自社の「完了した仕事1件当たりの費用」を測る手掛かりにはなるが、足し合わせたり、相互に再現した結果とみなしたりはできない。

ほかのタスクも向上した。Sonnet 5.5は、ツールを使うHumanity's Last Examで64.5%、OSWorld 2.1の一部のタスク群で80.1%、ツールを使わずに図表を読むChartographyで61.6%を得た。Sonnet 5の対応する数値は54.9%、57.0%、15.6%だ。推論、コンピューター操作、図表の読み取りで能力が広がったことを示すが、異なるテストを一つの総合点にはできない。

effort:まずタスクに合わせて設定し、Maxを習慣にしない

effortは、一つのタスクにモデルがどれだけ推論や確認を投入するかを決める。Claude CodeとClaudeアプリの初期値はMedium、Claude PlatformはHighだ。低い設定は通常、速くて安い。高い設定では難しい仕事をより丁寧に確認できるが、タスク全体の費用も増える。公式の四つの費用対スコア図では、青色のSonnet 5.5が低めの設定で旧版の多くの結果を超えている。設定を上げるほど、スコアも費用もOpusに近づく。

FrontierCodeには覚えておきたい例外もある。Sonnet 5.5はXhighで52.1%だったのに対し、Maxでは46.2%に下がった。Anthropicによると、Maxでは複数エージェントによるコードレビューが起きやすく、調査した二つの事例では、それが時間切れやタスク範囲外の変更につながった。バグ修正やファイル変更のように合格条件が明確な仕事なら、まずMedium以下で試し、結果が足りないときだけ投入量を増やす方が、今回示された費用上の利点を生かしやすい。

公式の費用対スコア図を4枚見る:知識労働、CursorBench、FrontierCode、Terminal-Bench
AA-Briefcaseの知識労働スコアとタスク当たり費用をモデルとeffort別に比較した図
AA-Briefcase:横軸はタスク当たりの費用、縦軸は知識労働のスコア。
CursorBenchの複数ファイルにわたるコーディングスコアとタスク当たり費用の比較図
CursorBench:低めのeffortでも、Sonnet 5.5は旧版の高い設定を上回る。
FrontierCodeではSonnet 5.5のMaxのスコアがXhighを下回ることを示す図
FrontierCode:Maxが必ずXhighより良いとは限らない。
Terminal-Benchのスコアと試行1回当たりの費用をモデルとeffort別に比較した図
Terminal-Benchの横軸は、ほかの三図の「タスク当たり」と異なり、試行1回当たりの費用だ。

同じ指示で作ったウェブ作品は、二世代でどう違うか

発表ページでは、Sonnet 5と5.5に同じ三つのビジュアル課題を与え、それぞれ一つのHTMLファイルで完成させている。静止画像で撮影時点の進み具合を確認でき、下の元の動的プログラムではコード生成から実行までの過程を見られる。

400羽のムクドリの群れ

Sonnet 5の画像では、4520トークンの時点でまだコードを書いている。一方、Sonnet 5.5は4158トークンを出力した後、群れが飛ぶ画面を実行している。

Sonnet 5のムクドリのデモはコード記述中で、Writing 4,520 tokensと表示
同じムクドリの指示に対し、Sonnet 5の公式画像ではまだコード作成中だ。
Sonnet 5.5のムクドリのデモでは群れの飛行が表示され、Output 4,158 tokensとFlying 12.5 sと表示
対応するSonnet 5.5の画像には、すでに動く画面が見える。

風が形づくる砂丘

旧版の画像は2966トークンの時点でまだコード作成中。新版は2720トークンの出力後、多層の線で描いた砂丘と赤い太陽を表示した。

Sonnet 5の砂丘デモはコード作成中で、Writing 2,966 tokensと表示
砂丘の課題では、Sonnet 5の画像にまだ実行結果は表示されていない。
Sonnet 5.5の砂丘デモは線で描いた砂丘と赤い太陽を表示し、Output 2,720 tokensとRunning 7.6 sと表示
Sonnet 5.5の対応画像には、描画結果が示されている。

24個の小さな時計で作る大時計

この組の違いは特に分かりやすい。Sonnet 5は2万7581トークンを書いている時点でもコード画面のまま。Sonnet 5.5は1万4386トークンの出力後、小さな時計の針を並べて大きな数字を表示した。

Sonnet 5の小時計デモはコード作成中で、Writing 27,581 tokensと表示
小時計の課題では、Sonnet 5の画像はまだコード生成中だ。
Sonnet 5.5の小時計デモでは針が大きな数字を作り、Output 14,386 tokensとRunning 20.9 sと表示
Sonnet 5.5の対応画像には、すでに目に見える結果がある。

全体の過程を見るには、下の六つの元の動的プログラムを展開してほしい。旧版の画像がコード作成中に撮影されたからといって、最終的に完成できなかったとは限らない。ここで分かるのは、公式デモのその時点での進み具合だ。

三組の比較に使われた六つの元のプログラムを再生する

ムクドリの群れ · Sonnet 5

ムクドリの群れ · Sonnet 5.5

風が形づくる砂丘 · Sonnet 5

風が形づくる砂丘 · Sonnet 5.5

小時計で作る大時計 · Sonnet 5

小時計で作る大時計 · Sonnet 5.5

利用開始時に確認したい設定と制約

Sonnet 5.5では安全対策の扱いも一部変わった。Anthropicによる約1850の自動化された行動シナリオのテストでは、アラインメント、誠実さ、悪用への耐性の多くの指標でSonnet 5と同等以上だった。一方、全体としてはOpus 5.5がわずかに上回る。新版はより厳しい発表前の確認を通ったが、実際の業務では通常どおり権限と検収条件を設定する必要がある。

実務に関係しうる変更は三つある。通常のバグ発見・修正はサイバーセキュリティ上のフォールバックの影響を受けないが、リスクの高いセキュリティ関連の依頼はSonnet 5に切り替わる場合がある。生物分野では従来の防護策が続き、正当な依頼の一部が誤って遮断される可能性がある。会話を別アカウントへ移す際は、拡張されたpreserved thinkingにより、新しいアカウントで推論内容を再生成する必要がある。一般的なコーディングや文書作成では最初の二つに遭遇しないかもしれないが、セキュリティ研究や組織をまたぐ会話移行を行うチームは事前に試したい。

まずSonnet 5.5に切り替えて試したい仕事

入力と合格条件が明確なタスクから始めるとよい。再現可能なバグの修正、テンプレートに沿った事業レビューの作成、問い合わせチケットの一括処理などだ。Sonnet 5.5をMedium以下のeffortで実際のサンプルに使い、完了率、手戻り時間、ツール呼び出し、所要時間、最終費用を記録して、Sonnet 5やOpusと比べる。目標が変わり続け、長期的な判断が必要な仕事では、Opus 5.5が引き続きAnthropicの推奨する出発点だ。

開発者はClaude PlatformでモデルID claude-sonnet-5-5を利用でき、AWS、Google Cloud、Microsoft Azure経由でも使える。Anthropicによるとゼロデータ保持にも対応する。これまでSonnetのthinkingを無効にしていたチームは、5.5への移行時に公式ガイドに従ってbetween_tools設定を使う必要がある。発表ページは、高スループットで費用に敏感な用途向けのHaiku 5.5が後に加わるとしているが、ここには選定の根拠になる実測結果はまだない。

Sonnet 5.5の価値は、すべてのランキングで勝つことではない。日々のコーディングやオフィス作業のより多くを、Opusを使わずに納品可能な形へ比較的速く仕上げられることだ。最も確かめたいのは単独のベンチマークスコアではなく、自分たちの仕事で待ち時間、手戻り、費用が実際にどれだけ減ったかである。

出典
Introducing Claude Sonnet 5.5Anthropic·原文を見る
編集部注
画像・動画・数値はAnthropicの発表ページと公式アカウントによるもの。顧客企業のテスト結果はそれぞれの出典に帰属する。
↑ 本文ここまで
✓ この記事は全文無料です

メンバーは全文 Markdown のコピー・保存に加え、自分の AI に購読・質問させることができます。

原文を読む ↗
📮 新着解説をメールでいち早く

役に立ちましたか?メールを登録すると、新着解説を公開と同時にお届けします。解除はいつでも。