Hendrik Krack
July 24, 2026
2 min read
Opus 5 for code review: Cleaner actionable comments, noisier overallの日本語訳です。
Anthropicが先ほどClaude Opus 5をリリースしました。多くの人が好きになってきたOpusファミリー（少なくともFableに主役の座を奪われるまでは）の、次のメジャーバージョンです。一歩引いて、CodeRabbitのテストを通じてOpusがどう進化してきたかを見るのに良いタイミングです。
私たちはバージョン4以降のすべてのOpusリリースをベンチにかけてきたので、その進化の軌跡はかなりはっきり見えています。Opus 5は、「より多くのバグを見つける」という単純な話ではなくなった初めてのリリースです。
（これまでの経緯を知りたい方は、4.1から始めて、4.5、4.7、4.8、そしてFable 5をご覧ください。）
このリリースは素の能力の向上というより、モデルをどう制御するか、そしてモデルがどこに労力を割くかという点の変化だと言えます。レビューとコーディングの仕事にとって重要な変更は5つあります。
この比較は、実際のオープンソースのプルリクエストで検証済みの問題から抽出した、約100件の一般的なエラーパターン（EP）を対象としています。各構成を3回ずつ実行し、その平均を現在の本番モデルミックスの3回の実行と比較しました。
本レポートのコメントは、パイプライン通過後の出力です。つまり、検証と重複排除、断定度フィルタリングをすでに通過しています。
重要な指標は4つです。2つはモデルはバグを捕まえたかを問い（既知の問題ごとにカウント）、2つはそのコメントは読む価値があったかを問います（コメントごとにカウント）。
Opus 5は、私たちがテストした中で最良の汎用コードレビュアーではありません。x-high構成は、本番ベースラインよりも高精度なアクション可能コメントのストリームを生成しましたが（39.3%対35.2%）、ベンチマークの既知の問題の検出は少なくなりました（55.2%対61.1%）。
また、nitpickは約4倍に増え、パイプライン通過後の全ストリームで数えると、精度はベースラインを下回りました（28.6%対32.8%）。
私たちの結論は意図的に狭く取っています。Opus 5は、ルーティングされたアンサンブルの中の精度重視レーンとしては有用になり得ますが、この結果は唯一のレビュアーとして、あるいは高リスクな変更の主要なセーフティネットとして使うことを支持しません。
CodeRabbitでは、3つのレビュー構成を実行しました。
Opus 5 x-highは、本番レビュアーの単純なアップグレードではありません。アクション可能なコメントのサブセットは最もクリーンでしたが（精度39.3%対35.2%）、既知の問題の検出は少なく、nitpickは4倍に増えました。開発者にとってはアクション可能なコメントが有用である確率がわずかに上がる一方で、重要な問題を見逃すリスクとトリアージが必要な低価値フィードバックが増えることを意味します。実用上の適所は、2番手の精度重視レビュアーです。
推論を増やしても、レビューが一貫して良くなるわけではありませんでした。ジュニア/デフォルト構成は、すべてのコメントクラスを数えたときに最も多くの問題を見つけましたが、フルストリーム精度は26.4%まで下がり、nitpickを110件生成しました。x-highはアクション可能なコメントの選別には優れていましたが、全体としてはノイジーなままでした。したがってチームは、effortを「失敗モードの選択」として扱うべきです。ワークフローに必要なのは広い探索か、それともクリーンなアクション可能サブセットかを決め、その選択が生むフィルタリング負荷を測ってください。
Opus 5が最も強いのは、設定ミスとコード品質です。統合まわりの詳細や保守性の問題を見つけるのが得意ですが、その幅広いレビュースタイルはノイズも増やします。
逆に弱いのはロジックエラーや競合状態、APIの誤用です。つまりOpus 5は追加の視点としては有用ですが、正しさが問われる変更、特に並行処理やAPIの挙動に関わる変更では唯一のレビュアーにすべきではありません。
過去のCodeRabbitの結果は、文脈であってリーダーボードではありません。各レポートはEP数やモデルミックス、判定者、プロンプト、パイプラインのバージョンが異なるため、小さな数値差を直接対決の勝敗として扱うべきではありません。
フロンティアモデルは、2つの陣営に分かれています。多くをキャッチし、後始末をプロダクト側に任せるリコール重視のレビュアーと、発言は少ないが正しいことが多い精度重視のレビュアーです。GPT-5.6 Solはスペクトラムの一方の端を固定します。既知の問題の69.7%をキャッチしましたが、残す価値のあるコメントは31.6%にとどまりました。
Opus 5 x-highは、スペクトラムのもう一端です。チャート上で最もクリーンなアクション可能ストリームを、私たちがテストしたOpusレーンの中で最も低いカバレッジで実現しています。最も近かったのは、先に同レベルの精度に到達していたSonnet 5です。違いは、Opus 5の方がカバレッジをわずかに多く保ちながら、フルストリームはよりノイジーになる点です。ベースラインの隣に位置するOpus 4.8は、引き続きこのファミリーのバランス型です。
Opus 5は、レビュアーとしてよりもビルダーとしての方が説得力があります。私たちのエンジニアの一人は、以前のOpusモデルより不安が少ないと表現しました。目標を明確にする時間を取り、複数の妥当なアプローチを提示し、オープンエンドなプロジェクトでも最初の解に飛びつかずに進められます。また、作業内容を丁寧にドキュメント化するため、説明可能性は上がりますが、トークンを大量に消費することがあります。
より大きなエージェントタスクでは、Opus 5は数百のバックグラウンドエージェントを協調させ、Opus 4.8よりはるかに優れた設計判断を示しました。それでもFable 5より遅くて効率も劣り、時折リミットに達してしまい、セキュリティ関連のタスクでは慎重すぎる傾向が残りました。現時点での見立てはこうです。特に曖昧で設計中心のプロジェクトでは、Opus 4.8からの明確なステップアップです。ただし、Fableに並ぶ存在ではありません。
Opus 5は、レビュー呼び出し1回あたり、ベースラインのフロンティアモデルより約50%多く読み、約65%多く書きます。1回あたりの平均は入力約60.5kトークン（構成により55〜64k）、出力約9.5kトークン（8.1〜10.8k）で、同じ実行で同じ仕事をしたGPT-5.6レーンの入力約40.5k・出力約5.8kと対照的です。実際のところ、Opus 5のレビュー呼び出しは毎回より大きなコンテキストを持ち込み、より長い回答を返します。コメント量、そしてコスト差の一部はここから来ています。
最も多く出力したのはx-highで、呼び出しあたり10.8kの出力トークンを生成しました。effortを増やせば出力が自動的に増えるわけではありません。highはジュニア/デフォルトより少なく書き、x-highはthinkingと出力の両方を増やしました。
見出しのスコア1つで判断しないでください。Opus 5は、よりクリーンなアクション可能コメントを生成しながら、同時により多くの既知の問題を見逃し、全体のノイズを増やすことがあります。評価においてはモデルが何を見つけるかと、開発者が何をふるいにかけなければならないかの両方を捉える必要があります。
Opus 5はスタンドアロンのレビュアーとしてよりも、ビルダーとして推奨しやすいモデルです。曖昧で設計中心のコーディングタスクでは、Opus 4.8からの意味のあるステップアップと言えます。より熟慮的で選択肢の探索に優れ、複雑な作業の協調もこなせます。ただし長時間のオーケストレーションでは、依然としてFable 5の方が強力で効率的に見えます。
コードレビューでは、Opus 5 x-highはスペシャリストです。よりクリーンでアクション可能なサブセットを生成しますが、既知の問題の検出は少なく、かなりの量のnitpickも生成します。精度が重要な場面で使い、リコール重視のカバレッジと組み合わせ、開発者に届く前に出力をフィルタリングしてください。
