コードレビューにおけるClaude Sonnet 5.5：Sonnet 5より多く検出し、所要時間は半分

Anthropicは、Claude 5.5ファミリーの2つ目のモデルClaude Sonnet 5.5をリリースしました。価格はSonnet 5と同じで、出力は30%高速、タスクあたりのコストは最大30%低下するとされています。今月初めのOpus 5.5と同じ方法で、CodeRabbitのレビューパイプラインで検証しました。多くのチームにとっての問いは、Sonnet 5.5がOpusを上回るかどうかではありません。Sonnet 5をレビュアーとして足踏みさせた弱点、つまりコメントは的確でも見逃すバグが多いという点を解消したかどうかです。

既知のバグを含む最も難しい13件では、解消されていました。Sonnet 5.5はアクション可能なコメントで13件中6件を検出しました（Sonnet 5は4件）。アクション可能なコメントの精度は41.2%（Sonnet 5は40.0%）で、報告されたコメントは17件（Sonnet 5は15件）です。所要時間は実時間でおよそ半分、Claudeモデル呼び出しの定価ベースのコストはレビュー1回あたり約60%減で、Anthropicが示す削減率の2倍にあたります。検出した問題のうち4件はSonnet 5が見逃したバグでしたが、Sonnet 5が検出した2件は見逃しています。つまり「検出数が増えた」だけでなく「見逃しが変わった」という話でもあります。

13件は小さなセットであり、本稿全体を通してその点を明記しています。44件のオープンソースのプルリクエストによる、より大きな2回目の実行でも、速度とコメント数については同じ傾向が確認されました。これらを合わせると、Sonnetのリリースとして初めて、コメントの質だけでなくメインのレビュー工程での採用を検討できるものになりました。

コードレビュー評価におけるSonnetシリーズの変遷（Sonnet 4からSonnet 5.5）。定性的な傾向のみを示しています。

Sonnet 4以降、すべてのSonnetを評価してきたため、今回のリリースもその流れの中に位置づけられます。Sonnet 4.5は推論の深さが加わった一方、断定を避ける癖がありました。Sonnet 4.6は測定した中で最も高いカバレッジを持つSonnetとなり、既知の問題の約63%を検出しましたが、精度は29%で、あらゆる箇所にコメントしていました。Sonnet 5はそのカバレッジを精度と引き換えにしました。コメントは的確になった一方、カバレッジは約50%に低下し、nitpickが増えました。Sonnet 5.5は、精度を落とさずにカバレッジを再び引き上げた、シリーズ初のリリースです。

Claude Sonnet 5.5の新機能

AnthropicはSonnet 5.5を、Opus 5.5を補完する高速で低コストなモデルと位置づけています。バグ修正や文書・スライド・スプレッドシートの作成といった範囲の明確な日常業務に最も強く、継続的な判断が必要な自由度の高い作業にはOpus 5.5が引き続き適しています。発表の中で、レビューやコーディングのワークフローを構築するチームにとって重要な点は次の5つです。

• 価格は同じで、トークンは少ない。 Sonnet 5.5の料金は、入力100万トークンあたり$2、出力100万トークンあたり$10、キャッシュ読み取り100万トークンあたり$0.20、キャッシュ書き込み100万トークンあたり$2.50で、Sonnet 5から変わらず、Opus 5.5の$4と$20の半額です。Anthropicは、同じ作業に必要なトークンが大幅に少なく（タスクあたり最大30%減）、出力も30%以上高速だとしています。私たちのレビュー実行では、これより大きな差が出ました。詳細は後述のコストの節をご覧ください。

• エージェント型コーディングのベンチマークで大幅に向上。 Anthropicの発表資料（下表）では、Sonnet 5.5はTerminal-Bench 4.0で10.3%から70.6%に上昇してOpus 5.5を上回り、その他のほとんどの項目でもOpus 5.5との差は約3ポイント以内です。差が最も大きいのはAA-Briefcaseの11ポイントです。コードレビューの結果もこの傾向に沿いますが、最も難しいケースではOpus 5.5との差がより大きくなります。

• thinkingは既定で有効で、effortが調整ダイヤル。 適応的thinkingが既定で、effort（low、medium、high、xhigh、max）がコストと深さを制御します。既定はClaudeアプリではMedium、Claude PlatformではHighです。低いeffortではthinkingを無効にすることもでき、Sonnet 5でthinkingを無効にしていたチームは、移行時に新しいbetween_tools設定へ切り替える必要があります。後述のthinking無効の実行はこの設定を使っています。

• Opus 5.5から引き継がれたAPIの挙動。 強制ツール使用は廃止され、構造化出力に置き換えられました。また、プロンプトキャッシュや過去のthinkingブロックを無効にすることなく、会話の途中でツール定義を追加・変更できます。Anthropicのガイダンスには、モデルが指示を文字どおりに解釈するため「ツール呼び出しを最小限にする」といった表現はそのまま守られること、また低いeffortでは、プロンプトで求めない限り、確認を実行せずにコード変更を完了したと報告することがある点も記されています。

• セーフガードと提供。 Sonnet 5.5のサイバー能力はOpus 5と同等のため、Sonnetとして初めてOpus相当のサイバーセーフガードが付きます。通常のバグ修正には影響しませんが、リスクの高いセキュリティ関連のリクエストはSonnet 5にフォールバックします。生物学に関するセーフガードはSonnet 5から変わりません。

レビューにおける実務上の変化は、以下で測定した内容です。Sonnet 5.5はレビュー呼び出しあたりのトークンがSonnet 5よりはるかに少なく、それでいてより多く検出します。

評価の方法

2つのベンチマークを使用しました。SignalはOpus 5.5の評価と同じ、より難しい13件のケースです。それぞれがオープンソースプロジェクト（Elasticsearch、Puma、vLLM、Cilium、axios、Next.js）の実際のプルリクエストで、レビュアーが検出すべき検証済みの問題が1件ずつ含まれています。難易度3が9件、難易度4が3件、難易度5が1件です。OSS Augustはより幅広いセットで、44件のオープンソースのプルリクエストに85件の既知の問題を含み、ロジックエラー、APIの誤用、競合状態、null参照、セキュリティの問題に重点を置いています。

すべての実行で、固定されたカセットから同じ記録済みのファイル要約、ウォークスルー、レイヤーのグルーピングを再生したため、入力は同一でした。変わったのはレビューモデルとそのthinking設定のみです。Signalでは、独立した判定モデルがすべてのコメントを既知の問題に照らして3票で採点し、多数決でPASSしたコメントのみを数えています。

検出した既知の問題は、13件のうち、通常のアクション可能なコメントが少なくとも1つ合格したケースの割合です（差分外のコメントとnitpickは除外）。アクション可能なコメントの精度は、合格したアクション可能なコメントを、すべてのアクション可能なコメントで割った値です。報告されたコメントは、検証、重複排除、フィルタリングを経たパイプライン後の件数で、それぞれを誰かが読む必要があります。

要点

図1. Signalの13ケースで、アクション可能なコメントによって検出した既知の問題。四角は変更行の外の指摘を含みます。Opus 5.5の数値は、同じケースを対象とした9月の評価によるものです。

thinking onのSonnet 5.5は、このセットでSonnet 5の1.5倍の既知の問題を、同じ精度、2件多いコメントで検出しました。Sonnet 5は6月に紹介したとおり、的確だが口数の少ないレビュアーであり、より難しいこのセットではその控えめさが裏目に出て、すべての構成の中で検出数が最も少なくなりました。

同じケースで、Opus 5.5は13件中8件（Standard）と10件（Max）を検出しました。Sonnet 5.5はこの差を埋めていません。この点は後ほど改めて取り上げます。

Sonnet 5.5がコードレビューにもたらすもの

同じ精度で、より多く検出

Sonnet 5.5とSonnet 5のアクション可能なコメントの精度はほぼ同じで、41.2%対40.0%でした。つまり、検出が増えたのは推測に基づくコメントを増やしたからではありません。Sonnet 5.5が報告したコメントは17件でSonnet 5の15件より多いものの、nitpickは少なく、クリティカルのラベルが付いたコメントはありませんでした。一方、Sonnet 5はクリティカルを2件付け、そのうち1件は誤りでした。2つのモデルのコメントの質は同程度で、Sonnet 5.5のほうがより多くをバグに的中させています。

実際の44件のプルリクエストでは、より静かで2倍速い

Signalのセットは小さいため、オープンソースのベンチマーク（44件のプルリクエストに85件の既知の問題）でもSonnet 5.5とSonnet 5を実行しました。

図2. OSS Augustベンチマーク（44件のプルリクエスト）：レビュー1件あたりの所要時間と、パイプライン後のコメント数。判定スコアリングは保留中です。

Sonnet 5.5のコメントはSonnet 5より24%少なく、重大度の内訳も穏やかで、nitpickは3分の1でした。Sonnet 5はクリティカルを14件付けたのに対しSonnet 5.5は4件で、さらに30件のnitpickを追加しました。これは6月に報告したnitpickの多い傾向と同じです。判定を行ったSignalの結果では、Sonnet 5の追加コメントは検出の増加につながっていません。この傾向が大規模でも当てはまるか、またSonnet 5.5のコメント数の少なさがカバレッジを損なっていないかは、OSSの判定実行で明らかになります。それまでは、コメント数は品質ではなく作業量として読んでください。

レイテンシの結果には、そのような留保は必要ありません。44件のレビューで、Sonnet 5.5の平均は1件あたり6:33、Sonnet 5は13:31でした。中央値では5:44対13:49です。Sonnet 5には10分を超える生成が4回ありましたが、Sonnet 5.5にはありませんでした。

ご自身のコードで確かめてみませんか？ 次のPRでCodeRabbitを試す。無料で始められ、リポジトリの接続は2分ほどです。

thinkingはオンかオフか

SignalでSonnet 5.5を2回実行しました。effortの全段階で適応的thinkingを有効にした実行と、無効にした実行です。明示的なthinkingの切り替えを受け付けないOpus 5.5とは異なり、Sonnet 5.5はlow、medium、highのeffortでthinkingを無効にできます（Anthropicの移行ガイドでは現在between_toolsと呼ばれる設定）。そのため、チームが実際に導入できる構成です。

thinking onは1件多く検出し、精度も2.7ポイント高く、コメントは4件多くなりました。2つの構成の結果は双方向で食い違っています。thinking onはvLLMの設定コンテキストのバグとストリーミングでのツール呼び出しのシリアライズのケースを検出し、thinking offはこれらを見逃しました。一方、thinking offはElasticsearchのterms-enumのケースを通常のコメントで検出し、thinking onは差分外でしか到達できませんでした。

thinkingのコストは想定より小さいものでした。コアのレビュー呼び出しでは、同一の入力に対して、thinking onの出力は1回あたり約5,800トークン、thinking offは2,900トークンで、レビュー1件あたりの平均レイテンシは31秒短くなりました。誤差の範囲内ではありますが、追加のトークンがレビューを遅くしていないことがわかります。既定はthinking onにすべきです。

レビュー1回の実際のコスト

Sonnet 5.5とSonnet 5は価格表が同じなので、両者のコスト差はすべてトークン量の差です。各実行のClaudeモデル呼び出しを、Anthropicの公表料金（100万トークンあたり、入力$2、出力$10、キャッシュ読み取り$0.20、キャッシュ書き込み$2.50）で計算しました。要約や検証を担当する共通の小型モデルは両側で同じため、除外しています。

どちらのベンチマークでも、同じレビューに対するSonnet 5.5のClaude呼び出しのコストはSonnet 5の約40%で、レビュー1件あたり約60%の削減です。Anthropicの発表値は「タスクあたり最大30%減」ですが、Sonnet 5が同じファイルを繰り返し読み、長い熟考を書き出していたコードレビューのワークロードでは、それを大きく上回ります。thinking onはthinking offに比べて請求額が約15%増え、その分、検出が1件増え、精度もわずかに向上しました。この差はトークンの使用量から生じます。

図3. Anthropicの定価で計算した、レビュー1件あたりのClaudeモデル呼び出しのコスト（SignalとOSS August）。

図4. Signalにおける、コアのレビュー呼び出し1回あたりの平均入力・出力トークン（1実行あたり22回）。

コアのレビュー呼び出しは、Signalが1実行あたり22回、OSS Augustは84回です。入力はプロバイダー間で標準化した総プロンプトサイズ（非キャッシュトークンにキャッシュの読み取りと書き込みを加えた値）です。

2つのベンチマークの結果は一致しています。レビュー呼び出し1回あたり、Sonnet 5はSonnet 5.5の2倍以上を読み、約4倍を書き、約6倍の語数を考えており、これはどちらのセットでも同じです。Signalでは検出数も少なくなっています。2つのリリースの間でAnthropicが何を変えたにせよ、新しいモデルははるかに少ない熟考で結論に到達しています。

要約や検証を担当する小型モデルを含むパイプライン全体では、Sonnet 5の総トークン消費量はSonnet 5.5より、Signalで27%、44件のOSSレビューで49%多く、出力トークンはどちらでも2倍以上でした。

レイテンシは、Sonnet 5.5が前モデルと最もはっきり差をつける点であり、大きな実行のほうが小さな実行より明確に示しています。Signalでは、レビュー1件あたりの平均時間は5:27対Sonnet 5の9:55、44件のOSSレビューでは6:33対13:31でした。両方のセットを合わせると、57件のレビューに対しSonnet 5は12時間強の実時間を要し、Sonnet 5.5は6時間でした。

図5. Signalにおける、レビュー1件あたりの平均・中央値の実時間。

Sonnetシリーズ、Opus 5.5との比較

テストセット、判定、パイプラインのバージョンは評価ごとに変わるため、以下の数値は性質の異なる2種類の比較です。Signalの行は同じセットでの比較で、13件のケースと記録済みの入力が同一で、数日以内に実行しています。それ以前のSonnetの行は過去の記事からの参考情報であり、順位表ではなく傾向として読んでください。

注目すべき点が3つあります。第一に、Sonnetシリーズの中で、5.5は精度を落とさずにカバレッジを改善した最初のリリースです。4.6にはカバレッジがあっても精度がなく、5には精度があってもカバレッジがありませんでした。第二に、同じSignalの13件で、Opus 5.5は8〜10件を検出したのに対しSonnet 5.5は6件で、精度もOpus 5.5のほうが高くなっています。最も難しいケースでは、フラッグシップのほうが明らかに優れたレビュアーであり、Sonnet 5.5はその差を埋めていません。これはAnthropicの発表ベンチマークで、Sonnet 5.5がほとんどの項目でOpus 5.5との差を約3ポイント以内に収めているのより大きな差ですが、継続的な判断が必要な複雑で自由度の高い作業ではOpus 5.5が明確に優れているというAnthropic自身の見方には合致します。難しいレビューのケースはまさにそのような作業です。第三に、Sonnet 5.5は低コストで結果を出しています。所要時間はSonnet 5の約半分で、定価はOpus 5.5の半分、実際のレビュー1件あたりのコストはSonnet 5の40%です。

これらは役割の異なるモデルです。リスクの高い変更でバグを見逃すことが高くつく失敗であれば、Opus 5.5の追加トークンには価値があります。すべてのプルリクエストで実行するレビュー工程のモデルとして、速く、開発者が実際に読むコメントを出すものを選ぶなら、Sonnet 5.5は候補に加えたい初めてのSonnetです。

作るときの違い：Opus 5.5との並列比較

Sonnet 5.5とOpus 5.5に、並べたClaude Codeセッションで同じ長いプロンプトも与えました。アルパインシャレーのデモモデルを備えたブロックモデルデザイナー「Brick Studio」を作り、45秒の紹介動画を録画するというものです。先に終わったのはSonnet 5.5で29分27秒、Opus 5.5は44分50秒だったため、約1.5倍高速でした。結果はほぼ同じで、忠実度はOpus 5.5がわずかに上でした。これはベンチマークではなく1回の実行です。セッションは作業フォルダーを共有していたため、Sonnet 5.5は途中で独立したサブフォルダーに移動しており、どちらのモデルにも参照用のスクリーンショットは渡していません。それでも上のレビュー結果とは一致します。最も難しい作業ではOpus 5.5が優れており、Sonnet 5.5ははるかに短い時間でそれに迫ります。

Sonnet 5.5をご自身で評価するには

13件は傾向を見るには十分ですが、判断を確定するには足りません。切り替える前に、次を行ってください。

• 結果がわかっているご自身のリポジトリのプルリクエストで実行し、現在使っているモデルと、検出するバグと見逃すバグを比較します。Sonnet 5.5とSonnet 5は13件中6件で結果が分かれ、Sonnet 5.5の2つの構成同士も3件で結果が分かれました。

• thinkingのオンとオフを試します。私たちの実行では、thinking onのほうが多く検出し、精度も高く、遅くもなりませんでした。代償は、コメントが4件増え、レビュー呼び出しあたりの出力トークンが約2倍になることでした。

• モデル呼び出しではなく、レビュー全体を測定します。検証エージェント、リトライ、要約モデルのすべてがトークンと時間を増やします。入力、出力、キャッシュ読み取り、キャッシュ書き込みのトークンは別々に追跡してください。

• 合格したコメントと合格しなかったコメントの両方を読みます。Sonnet 5.5の見逃しの多くは、正しいファイルに対するもっともらしい指摘であり、ノイズよりも仕分けが難しいものです。

結論

Sonnet 5.5は、Sonnet 5をメインのレビュー工程から遠ざけていた具体的な弱点を解消しています。最も難しいケースでは、Sonnet 5と同じ精度で1.5倍の既知の問題を検出し、より幅広い44件のプルリクエストでは、コメントが4分の1少なく、nitpickは3分の1、所要時間は半分未満で、コストは約40%です。

Opus 5.5の代わりになるものではありません。難しい13件のうち4件は、実行したどのSonnetの構成でも検出できず、より大きなセットのカバレッジの数値もこれからです。それでも、すべてのプルリクエストで実行する必要のある、速く、開発者が実際に読むコメントを出すレビューにおいて、Sonnet 5.5は私たちがこれまでに検証した中で最も説得力のあるSonnetです。当社のVP of AIであるDavid LokerがAnthropicの発表で述べたように、Sonnet 5.5は出力トークンをはるかに少なく抑えながら「さまざまな複雑さのレベルでSonnet 5より優れた判断を示し」、Sonnet 5にあったWeb検索に頼りすぎる癖もなくなりました。まずは単純および中程度のレビューから移行し、今後数週間でさらに広げていきます。

CodeRabbitを始める：リポジトリを接続すれば、数分で最初のレビューが届きます。無料でお試しいただけ、クレジットカードは不要です。

---

方法論に関する注記。 Signalは、実際のオープンソースのプルリクエストから抽出した、より難しい既知のバグパターン13件のサブセットです。OSS Augustは、44件のオープンソースのプルリクエストにある85件の既知の問題で、判定スコアリングが保留中だったため、ここではコメント数、レイテンシ、トークン使用量、コストのみを報告しています。3票の判定のうち多数が承認した通常のアクション可能なコメントが少なくとも1つある場合に、そのケースを検出済みとしています。精度は、対象の問題に対して判定に合格したアクション可能なコメントの割合であり、開発者による受け入れではありません。すべての実行で、記録されたカセットから同一の上流の要約を再生しました。このサンプルサイズでは、個々の判定が結果に影響します。Pumaのケースでは、Sonnet 5の指摘は承認され、Sonnet 5.5のほぼ同一の指摘は承認されませんでした。また、Sonnet 5.5の合格した7件のコメントのうち1件は2対1の票で合格しており、それを除くと精度は35.3%になります。トークン数は生成呼び出し全体の平均で、入力は非キャッシュトークンにキャッシュの読み取りと書き込みを加えた値として標準化しています。金額は、各実行のトークン数から、Sonnet 5と変わらないSonnet 5.5のAnthropic公表定価で再計算したもので、Claudeモデルの呼び出しのみを対象としています。評価ハーネス自体は、リリース前のモデルには仮の料金を使用していました。