Claude Sonnet 5.5のリリース、料金表据え置きでベンチマーク70.6%を記録

Anthropicは、Terminal-Bench 4.0で70.6%を記録したとするClaude Sonnet 5.5をリリースし、公開されているSonnetのトークン料金は据え置いた。

この組み合わせこそが本当の注目点だ。Anthropicは、日常的に使う新モデルについて、開発者にトークン当たりの追加料金を求めていない。同社によれば、このモデルは出力を30%以上高速に生成し、多くのタスクで使用トークン数も少ないという。

公式リリースでは、この70.6%という結果をSonnet 5の10.3%と比較している。同じベンチマークにおけるOpus 5.5の報告値66.4%も上回るとしている。

これらの数値を見る限り、Claude Sonnet 5.5のリリースは単なる通常のモデル更新にはとどまらない。高速なデフォルトモデルと、難しい作業向けに確保されるプレミアムモデルという従来の区分に圧力をかけるものだ。

ただし、この見出しの数値には文脈が必要だ。ベンチマークの構成、推論の強度、エージェントの足場、フォールバック、トークン使用量は、スコアと運用コストの両方を大きく左右し得る。

独立したテストでは、Anthropicのローンチチャートよりも複雑な状況がすでに示されている。Sonnet 5.5は非常に競争力が高いように見えるが、最高の結果がそのまま最も安価な本番導入を意味するわけではない。

Claude Sonnet 5.5のリリースはデフォルトモデルの計算を変える

AnthropicはSonnet 5.5を、Opusの限定的な代替ではなく、チームがデフォルトで使えるモデルとして位置付けている。

このモデルは2026年9月28日、Anthropicのアプリ群と開発者プラットフォームで利用可能になった。Anthropicによれば、Amazon Web Services、Google Cloud、Microsoft Azure経由でも利用できる。

このリリースは、範囲が明確なコーディング、バグ修正、文書作成、プレゼンテーション、スプレッドシート、日常的なエージェントワークフローを対象としている。Anthropicは、持続的な判断を要するオープンエンドな作業については引き続きOpus 5.5を位置付けている。

多くのビジネスワークロードはSonnetのカテゴリに近いため、この区別は重要だ。サポート返信、コードレビュー、文書改訂、構造化分析で、すべてのリクエストに最大限の推論が必要になることはめったにない。

Anthropicは、Sonnet 5.5がSonnet 5より30%以上高速に出力を生成したと報告している。また、公開トークン料金を据え置いたにもかかわらず、総タスクコストを削減できるとしている。

この主張はタスク効率に依存する。使用トークン、ツール、再試行が少なければ、料金表が据え置きでも、完了タスク当たりのコストは下がり得る。

Anthropicは、この主張を裏付けるため、複数の初期顧客の事例を示した。Slackは、プロンプトを変更せずに、オフラインのSlackbot評価全体で出力トークンが約14%減少したと報告した。

Zendeskは、テストでサポートチケットの処理が20%高速化したと報告した。Atlassianは、RovoエージェントがSonnet 5使用時より最大30%高速に動作したとしている。

Balyasny Asset Managementは、2,441件の非公開金融タスクでこのモデルをテストした。分析、抽出、予測、検索の作業全体で、Sonnet 5より回答当たりのトークン使用量が大幅に少なかったと報告している。

これらは企業が選んだローンチ時の事例であり、あらゆるワークロードにわたる統制比較ではない。それでも、Anthropicが購入者に測定してほしいもの、すなわち単独のトークン価格ではなく完了した作業を示している。

したがって、実務上の変化はベンチマークのスコアより広い。モデルを評価するチームは、レイテンシー、成功率、再試行、ツール呼び出し、レビュー時間をまとめて比較する必要がある。

より多くのタスクを正確に完了する高速モデルは、キュー処理能力とユーザー体験を変え得る。不完全な作業を修正するための人手も減らせる可能性がある。

このリリースには、新しいモデル識別子claude-sonnet-5-5が含まれる。Sonnet 5から移行する開発者は、構成によってはその識別子以上の変更が必要になる。

Anthropicの移行ガイダンスには、thinking設定、強制的なツール選択、コンテンツブロック、computer-useツールに関する変更が記載されている。一部の古いリクエストパターンはエラーを返す。

たとえば、開発者が該当フィールドを省略すると、thinkingはデフォルトで実行される。そのため、最初に返されるブロックには常に通常のテキストが含まれると想定するアプリケーションは壊れる可能性がある。

このモデルは、対応するeffortレベルでは、無効化された事前thinkingをbetween_tools設定に置き換える。この挙動は、低レイテンシー応答や予測可能な推論予算を前提に設計されたアプリケーションにとって重要だ。

こうした互換性の詳細は、コスト不要のアップグレードという考えを複雑にする。公開料金は変わらなくても、移行作業と評価時間には依然として運用コストがかかる。

そのため、チームはSonnet 5.5を、同一API契約の背後にある単に優れたチェックポイントではなく、新しいランタイムとして扱うべきだ。

Terminal-Benchの70.6%というスコアがSonnetより上位に圧力をかける

驚くべき比較は、Sonnet 5.5と前世代モデルとの対比ではない。Sonnet 5.5とAnthropicのプレミアムOpusラインとの比較だ。

Terminal-Benchは、コマンドラインインターフェースを通じて作業するエージェントを評価する。タスクでは、モデルが環境を調査し、ツールを使い、成果物を変更し、複数ステップの目標を完了する必要がある。

バージョン4.0には、コミュニティが寄稿し、メンテナーがレビューした66のタスクが含まれる。カテゴリには、ソフトウェア、科学、機械学習、運用、ハードウェア、セキュリティ、メディアがある。

ベンチマークの方法論は、説得力のある説明ではなく最終成果物を重視する。エージェントは、もっともらしい応答を返しただけではなく、その作業が採点器を通過したときに評価される。

Anthropicは、Sonnet 5.5が70.6%、Sonnet 5が10.3%だったと報告している。Opus 5.5については、同モデルで評価された最高のeffortにおいて66.4%だったとしている。

2世代のSonnet間の差は異例に大きい。Anthropicのエージェント型コーディングスタックで、段階的な言語品質の改善を超える何かが変わったことを示している。

この結果は、この特定のテストにおける想定された製品階層も逆転させる。低コストのファミリーメンバーが、複雑なターミナル作業でAnthropicのプレミアムモデルを上回ったと報告されている。

だからといって、Sonnet 5.5がOpus 5.5よりあらゆる面で優れているわけではない。Anthropicは、持続的な判断を要する複雑でオープンエンドな課題では、Opusが依然として強いと明言している。

他の公開評価も、その留保を裏付けている。CursorBench 4.0では、Sonnet 5.5は55.5%、Opus 5.5は57.8%を記録した。

職業タスクを評価するGDPval-AA v2.1では、報告スコアはSonnet 5.5が1,844、Opus 5.5が1,846だった。両モデルはそこでほぼ同水準だった。

FrontierCodeも別の混在した結果を示した。Sonnet 5.5はあるeffort設定で52.1%に達した一方、Opus 5.5は54.4%を記録した。

これらを合わせると、より限定的な逆転像が浮かび上がる。Sonnet 5.5は、タスクの目標が明確で、利用可能なツールがあり、完了条件を検証できる場合に特に強いように見える。

成功が曖昧な判断、より広い計画、またはオープンエンドな課題を通じた品質維持に依存する場合、Opusは優位性を保っている。

開発者にとって、この区分はモデルルーティングを促す。システムは日常的な実装と範囲が限定されたエージェントタスクをSonnetへ送り、アーキテクチャや難しいエスカレーション案件にはOpusを確保できる。

Anthropicのローンチ資料では、この役割分担の一例が示されている。あるクリエイターは、ゲームのアーキテクチャを確立するためにOpusを使い、その後の実装をSonnet 5.5に任せたと説明している。

このモデルの組み合わせは、単純なリーダーボード上の勝利よりも重要だ。プレミアムな推論と大量実行が、1つのワークフロー内で別々の段階になる可能性を示唆している。

同じパターンは文書やナレッジワークにも当てはまる。プレミアムモデルが分析計画を定め、Sonnetが抽出、下書き、改訂、書式設定を担うことができる。

すでにエンジニアリングナレッジベースを構築しているチームは、リポジトリ文書とレビュー記録を使ってこの構造をテストできる。一般的なランキングよりも、自社で受け入れられた出力の方が重要だ。

Sonnet 5.5が実行段階を一貫して担えるなら、OpusはAnthropic自身の製品ファミリー内から圧力を受けることになる。開発者は、難しそうに見えるすべてのタスクになぜプレミアムモデルが必要なのかを問うだろう。

この問いは、より安価なモデルの応答速度も速い場合に特に重要になる。レイテンシーは、ユーザーが対話型コーディングループでエージェントを受け入れるかどうかを左右することが多い。

このベンチマークの飛躍は、より良い回答だけでなく、より優れたエージェントループを反映している

Claude Sonnet 5.5のベンチマーク結果は、より効率的なツール利用を示唆するが、Anthropicは増加分全体の原因を一つに切り分けてはいない。

エージェント型ベンチマークは、複合的なシステムを測定する。基盤モデルは重要だが、プロンプト、ツール、推論の強度、コンテキスト管理、時間制限、フォールバックの挙動も同様に重要だ。

Anthropicによると、初期テスターはステップ数の減少と、より多くの一括ツール呼び出しを観察した。Lovableは、社内コーディング評価において、シェル実行回数がおよそ半分になり、ツール呼び出しが約3分の1減少したと報告している。

CodeRabbitも、Sonnet 5.5は出力トークンの使用量が少なく、複雑さの異なるタスク全体でより良い判断を示したと報告している。Sonnet 5と比べて不要なWeb検索も少なかったと指摘した。

これらの観察は、Terminal-Benchの改善に対するもっともらしい仕組みを示す。目的なく探索することが少ないエージェントは、最終成果物を変える行動のために時間とコンテキストを確保できる。

ツール効率は信頼性にも影響する。シェルコマンド、ブラウザー操作、外部リクエストのすべてが、失敗、レイテンシー、不正な出力の新たな機会を生む。

したがって、より短い有効な経路を選ぶモデルは、劇的に優れた文章を生成しなくても完了率を改善できる。ターミナル作業では、この種の規律が評価される。

AnthropicはSonnet 5.5に5つのeffortレベルを追加した。この設定は、モデルがアクション前またはアクション間に、どれだけ長く推論し作業を確認するかを制御する。

高いeffortは難しいタスクを改善し得るが、より多くのトークンと時間も消費する。Anthropicは、Sonnet 5から古い前提を引き継ぐのではなく、チームが複数の設定を評価することを推奨している。

この推奨は見落とされやすい。ベンチマークで最高の結果は通常、意図的な構成を反映する一方、本番システムではデフォルト設定やコスト制御された設定が使われることが多い。

ローンチチャートは、Anthropicの評価フレームワーク内で70.6%という数値を報告している。独立評価者は、ハーネスやeffortレベルを変えれば異なる結果を得る可能性がある。

たとえばArtificial Analysisは、自身のTerminal-Bench 4.0実行で64%を報告した。独立評価では、Sonnet 5.5を有力モデルの一つに位置付けつつ、最大effort時の大量のトークン使用を指摘した。

同社は、Sonnet 5.5が測定したどのモデルよりも、Intelligence Indexタスク当たりの出力トークンを多く消費したとした。この結果は、単純な効率性の物語に疑問を投げかける。

この2つの知見は必ずしも矛盾しない。Sonnet 5.5は低い設定では効率的である一方、測定上の最大能力へと押し上げるとトークン集約的になり得る。

料金と総消費量の区別は極めて重要だ。モデルの推論時間が長くなれば、料金表が据え置きでも請求額が変わらないとは限らない。

Anthropicは、複数の評価において、lowまたはmedium effortが、完了タスクコストの一部でSonnet 5の最高スコアを上回れるとしている。独立テストは、maximum effortには異なる特性があることを示唆している。

したがって、本番導入を検討する購入者は、一点ではなく曲線を評価すべきだ。有用な比較では、タスク成功率をレイテンシー、トークン、再試行、人によるレビューとともにプロットする。

コーディングチームは、リポジトリの代表的なタスク群から始めることができる。そこには、バグ修正、リファクタリング、テスト作成、依存関係の変更、不慣れなコードの探索を含めるべきだ。

各実行では同じ環境と受け入れチェックを使用する。レビュアーは、パッチが動作するか、スコープ内に収まっているか、人による修正が必要かを記録すべきである。

テストでは、失敗したツール呼び出しと経過時間も数えるべきだ。こうした測定により、見出し上の高いスコアが、より良い開発ループにつながるかどうかが明らかになる。

チームは複数の努力レベルでこの検証を繰り返すべきだ。中程度の努力で日常的な作業の大半を完了できるなら、最大の努力は十分な追加価値を提供せずにコストだけを増やす可能性がある。

最適な構成は、同じ製品内でも異なる場合がある。高速な対話型アシスタントには、広範な検証を伴う夜間移行エージェントとは別の設定が必要だ。

これが今回のリリースの中核的な仕組みである。Anthropicは、Sonnetがどれだけの計算を費やすかについて開発者の制御を強化しつつ、その範囲全体でより良い結果を実現すると主張している。

数字だけでは決着しないこと

ベンチマークの見出しとなる結果は報告値として信頼できるが、それだけで本番環境での信頼性や普遍的なコスト削減を立証することはできない。

第一の制約は、構成への感度だ。Anthropicの70.6%というスコアとArtificial Analysisの64%というスコアは、いずれもSonnet 5.5を対象としているが、異なる評価設定によるものだ。

第二の制約は、フォールバックの挙動である。一部の評価システムでは、拒否された、またはサポートされていないリクエストを、定義された条件下で別のモデルにルーティングできる。

Artificial Analysisは、タスクのごく一部でフォールバックを観測した。Valsも、プロバイダー側のフォールバックがリーダーボードの解釈に影響し得る要因であると記載している。

フォールバック自体が不適切というわけではない。特に、プロバイダーが安全性や可用性を維持するためにルーティングを用いる場合、それは顧客が実際に受け取る製品の挙動を表すことがある。

ただし、フォールバックに支えられた結果は、純粋な単一モデルの結果とは別の問いに答えるものだ。購入者は、モデル、プロバイダーのゲートウェイ、あるいは完全に管理されたエージェント全体のどれを評価しているのかを把握すべきである。

第三の制約は、ベンチマークの飽和に関するものだ。70.6%というスコアには依然として無視できない失敗の余地がある一方、将来のモデルを区別するベンチマークの能力を狭めてもいる。

主要なシステムがほとんどのタスクを完了するようになると、難しいエッジケースの重要性が増す。通常のユーザー体験を変えなくても、プロンプトやハーネスの小さな変更が順位を動かすこともある。

Terminal-Benchは、タスクが実際の操作を必要とし、検証可能な成果物を生成するため、有用であり続ける。それでも、単一のベンチマークがすべてのコードベース、ツールチェーン、セキュリティポリシー、承認プロセスを代表するわけではない。

第四の制約は、総リソース使用量である。Artificial Analysisによると、Sonnet 5.5の最大努力構成は、Intelligence Indexの1タスクあたり約193,000出力トークンを使用した。

この測定値は、すべてのリクエストを表すものではない。ただし、公開されたトークン単価だけから完了タスクのコストを推測すべきでない理由を示している。

最大努力では、Artificial Analysisの比較においてSonnet 5.5は最も効率的なフロンティアの外にあった。他の構成は異なるバランスを提供していた。

第五の制約は、安全性に関する挙動だ。Anthropicは、Sonnet 5.5が、同社で最も高性能なモデルに使われるものと類似したサイバーセーフガードを備えてリリースされる初のSonnetモデルだとしている。

より高リスクなサイバー関連リクエストは、Sonnet 5にフォールバックする可能性がある。また、モデルには、その推論の抽出を試みる行為を阻止するための分類器も含まれている。

これらの保護策は能力向上への対応だが、新たな拒否パターンを生む可能性もある。正当なセキュリティワークフローが、移行後に異なる挙動を示すかもしれない。

したがって、cyber safeguardsは安全対策であると同時に、運用上の変数でもある。セキュリティチームには、認可済みの防御的作業をカバーする評価ケースが必要だ。

第六の制約は、ローンチパートナーの選定である。Anthropicの顧客推薦コメントは具体的なデータを提供するが、同社が発表に掲載する事例を選んでいる。

Slack、Zendesk、Box、Lovable、Atlassianなどのパートナーは、自社にとって重要なワークロードをテストした。その成果は、無関係なアプリケーションでも同じ改善が得られることを立証するものではない。

金融情報検索システム、コーディングエージェント、カスタマーサポートのワークフローでは、モデルに求められる要件が異なる。許容可能なエラーの基準も異なる。

チームは、自らのデータと評価器を用いて、主張された改善を再現すべきである。トークンを節約してもレビュー時間が増えるモデルは、ワークフロー全体を改善したとは言えない。

逆のことも起こり得る。より多くのトークンを使うモデルでも、失敗を防ぎ、再試行を減らし、以前はエスカレーションが必要だった作業を完了できるなら、なお経済的であり得る。

だからこそ、最も妥当な解釈は条件付きのままである。Sonnet 5.5は、特に範囲が限定されたエージェント作業において、能力とコストの境界を押し広げているように見える。

今回のリリースは、Opus、カスタム評価、人によるレビューの必要性をなくすものではない。それぞれをいつ使うかという判断を、より重要なものにする。

Sonnet 5.5が市場を変えるかを示す3つのシグナル

次の検証点は、開発者が通常の努力レベルでAnthropicの結果を再現し、実際のワークロードをプレミアムモデルから移行させるかどうかだ。

第一のシグナルは、独立したベンチマーク再現である。評価者は、努力設定、ハーネスの詳細、フォールバック回数、トークン消費量、タスク単位の失敗を含む結果を公開すべきだ。

Anthropicのスコアに近い再現結果は、Sonnet 5.5が大幅なエージェント能力の改善を示すという主張を強める。大きなばらつきがあれば、構成のほうが重要な論点となる。

70.6%と64%の差は、すでに開示の重要性を示している。どちらのスコアも高い性能を示すが、競合システムとの比較について異なる含意を持つ。

第二のシグナルは、本番環境でのルーティングだ。コーディングツールやエンタープライズプラットフォームが、日常的なエージェント向けのデフォルトモデルとしてSonnet 5.5を採用するかを注視すべきである。

デフォルトとしての配置は、オプションとして利用可能であることより重要だ。それは、ベンダーがモデルのレイテンシ、信頼性、拒否挙動、完了タスクあたりの経済性を信頼しているかを示す。

実装作業でOpusからSonnetへの移行が起きれば、Anthropicの製品戦略を裏付けることになる。採用が限定的であれば、プレミアム推論が依然として不可欠な信頼性を提供していることを示唆する。

初期の推薦コメントは、全面的な置き換えよりもルーティングを示唆している。CodeRabbitはまず単純なレビューと中程度のレビューを移行し、その後、結果に応じて拡大する予定だ。

このアプローチは理にかなっている。モデル選定をブランドの好みではなく、運用ポリシーとして扱うものだ。

第三のシグナルは、努力レベルごとの完了タスクコストである。購入者は、出力トークン、ツール呼び出し、再試行、レイテンシ、レビュアーの介入を含む測定値を探すべきだ。

中程度の努力でベンチマーク上の改善の大半を維持できるなら、Sonnet 5.5は大量利用のデフォルトとしての根拠を強める。最大努力が常に必要なら、経済的な優位性は狭まる。

開発者は移行時のエラーも監視しなければならない。新しい思考挙動、ツール選択ルール、安全性フォールバック、コンテンツブロック処理は、既存の統合に影響する可能性がある。

Anthropicのドキュメントは、チームに努力レベルのスイープを再実行し、コストのベースラインを再設定するよう助言している。この指示は、変更されていない料金表より重要である。

Claude Sonnet 5.5のリリースは最終的に、重大なエージェント作業にはプレミアムモデルが常により安全な選択である、という馴染み深い前提に挑戦している。

Anthropic自身の結果では、Sonnetは重要な端末ベンチマークの一つでOpusを上回っている。他のテストでは、特に持続的な判断が重要な領域で、依然としてOpusが優位に立つ。

これにより、より明確な役割分担が生まれる。Sonnet 5.5は高速で範囲の限定された実行を担い、Opusは曖昧な判断に対するエスカレーション経路として残る。

市場への影響は、この役割分担が実際のリポジトリ、文書、サポートキュー、セキュリティ制御に直面しても維持されるかどうかにかかっている。

Claude Sonnet 5.5を評価するチームは、単独のプロンプトではなく完了タスクから始めるべきだ。固定されたテストセットを構築し、複数の努力レベルで実行し、すべての再試行を記録する。

本番環境で既に使用しているSonnet 5とプレミアムな代替モデルの両方と比較する。移行作業、レビュアーの時間、拒否、失敗したツール呼び出しを含めるべきである。

そして、重要な判断を問う。Claude Sonnet 5.5は、十分な信頼性で十分な実作業を完了し、新たなデフォルトになれるだろうか。