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をご覧ください。）
Opus 5の新しさ
このリリースは素の能力の向上というより、モデルをどう制御するか、そしてモデルがどこに労力を割くかという点の変化だと言えます。レビューとコーディングの仕事にとって重要な変更は5つあります。
- effortが第一の制御手段： thinkingはデフォルトで有効になり、無効にできるのはhigh effort以下のみです。また、effortとタスク予算は、キャッシュを無効化せずに会話の途中でターンごとに変更できるようになりました。私たちのデータもこの見立てを裏付けています。effortはルーティングの判断であり、x-highはカバレッジを犠牲に精度の向上を買うもので、一様に良くなる設定はありませんでした。
- ロングコンテキストは安定と主張： コンテキストウィンドウはデフォルト・最大ともに100万トークンになり、全域で性能が維持されると謳われています。これは、Opus 4.8で私たちが報告した20万トークン超えでの劣化への直接の回答です。
- 長時間のエージェント作業が最大の強み： ガイダンスは、タスク仕様を最初に完全に渡すこと、より長い自律セッション、そしてマルチエージェントのライター・ベリファイアパターンを推奨しています。
- プロンプトの書き方を変える挙動の変化： このモデルはレビュー指示を文字どおりに守り（控えめな表現は検出率を抑制）、デフォルトの出力が長くなり、その長さはeffort設定ではなくプロンプトに反応します。また、頼まれなくても自分の作業を検証し、タスクの範囲を広げることがあります。この4つの特徴の内、3つは私たちのデータにも現れており、後段で詳しく見ていきます。
- サイバーセキュリティ関連の安全対策の強化： Fable 5で見たように、無害なセキュリティ作業でも安全機構が作動することがあります。この点は後述のセキュリティカテゴリの結果でも触れますが、Opus 5ではその頻度は低めでした。
何をテストしたか
この比較は、実際のオープンソースのプルリクエストで検証済みの問題から抽出した、約100件の一般的なエラーパターン（EP）を対象としています。各構成を3回ずつ実行し、その平均を現在の本番モデルミックスの3回の実行と比較しました。
本レポートのコメントは、パイプライン通過後の出力です。つまり、検証と重複排除、断定度フィルタリングをすでに通過しています。
重要な指標は4つです。2つはモデルはバグを捕まえたかを問い（既知の問題ごとにカウント）、2つはそのコメントは読む価値があったかを問います（コメントごとにカウント）。
- アクション可能パス率： 確信度が高くアクション可能なコメントで捕捉できたEPの割合
- フルストリームパス率： 差分外コメントや断定・nitpick系（低確信度）を含む、あらゆるコメントクラスで捕捉できたEPの割合
- アクション可能精度： アクション可能なコメントのうち、対象の問題を正しく突いたものの割合
- フルストリーム精度： 同じ指標を、モデルが生成したすべてのコメントで見たもの
要約（TL;DR）
Opus 5は、私たちがテストした中で最良の汎用コードレビュアーではありません。x-high構成は、本番ベースラインよりも高精度なアクション可能コメントのストリームを生成しましたが（39.3%対35.2%）、ベンチマークの既知の問題の検出は少なくなりました（55.2%対61.1%）。
また、nitpickは約4倍に増え、パイプライン通過後の全ストリームで数えると、精度はベースラインを下回りました（28.6%対32.8%）。
私たちの結論は意図的に狭く取っています。Opus 5は、ルーティングされたアンサンブルの中の精度重視レーンとしては有用になり得ますが、この結果は唯一のレビュアーとして、あるいは高リスクな変更の主要なセーフティネットとして使うことを支持しません。
CodeRabbitでは、3つのレビュー構成を実行しました。
- ジュニアレビュアープロファイル、デフォルトのeffortレベル（medium）
- シニアレビュアープロファイル、high effort
- シニアレビュアープロファイル、x-high effort
開発者にとっての意味
Opus 5 x-highは、本番レビュアーの単純なアップグレードではありません。アクション可能なコメントのサブセットは最もクリーンでしたが（精度39.3%対35.2%）、既知の問題の検出は少なく、nitpickは4倍に増えました。開発者にとってはアクション可能なコメントが有用である確率がわずかに上がる一方で、重要な問題を見逃すリスクとトリアージが必要な低価値フィードバックが増えることを意味します。実用上の適所は、2番手の精度重視レビュアーです。
推論を増やしても、レビューが一貫して良くなるわけではありませんでした。ジュニア/デフォルト構成は、すべてのコメントクラスを数えたときに最も多くの問題を見つけましたが、フルストリーム精度は26.4%まで下がり、nitpickを110件生成しました。x-highはアクション可能なコメントの選別には優れていましたが、全体としてはノイジーなままでした。したがってチームは、effortを「失敗モードの選択」として扱うべきです。ワークフローに必要なのは広い探索か、それともクリーンなアクション可能サブセットかを決め、その選択が生むフィルタリング負荷を測ってください。
Opus 5が最も強いのは、設定ミスとコード品質です。統合まわりの詳細や保守性の問題を見つけるのが得意ですが、その幅広いレビュースタイルはノイズも増やします。
逆に弱いのはロジックエラーや競合状態、APIの誤用です。つまりOpus 5は追加の視点としては有用ですが、正しさが問われる変更、特に並行処理やAPIの挙動に関わる変更では唯一のレビュアーにすべきではありません。
最近のモデル情勢の中でのOpus 5の位置づけ
過去の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 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と出力の両方を増やしました。
Opus 5を自分で評価する方法
見出しのスコア1つで判断しないでください。Opus 5は、よりクリーンなアクション可能コメントを生成しながら、同時により多くの既知の問題を見逃し、全体のノイズを増やすことがあります。評価においてはモデルが何を見つけるかと、開発者が何をふるいにかけなければならないかの両方を捉える必要があります。
- lowとmediumを含め、関係するすべてのeffortレベルをテストしてください。私たちの実行では、推論を増やすとトレードオフが変わりましたが、レビューが一貫して良くなることはありませんでした。
- 制約の強いプロンプトと、幅広く報告させてから後工程でフィルタリングする方式を比較してください。「重大度の高い問題だけを報告して」といった指示は、有用な発見を抑え込むことがあります。
- 開発者がレビューを読み飛ばすことを覚える前に、ロールアウトの前段階で簡潔さと重大度のチューニングを済ませてください。
- 冗長な検証指示を取り除き、実行時間やトークン、コストへの影響を観察してください。
- 見逃しをカテゴリ別・重大度別に分解してください。問題の見逃しが高くつく失敗であるなら、Opus 5にはリコール重視のレビュアーを組み合わせてください。
私たちの結論：特定の役割を与える
Opus 5はスタンドアロンのレビュアーとしてよりも、ビルダーとして推奨しやすいモデルです。曖昧で設計中心のコーディングタスクでは、Opus 4.8からの意味のあるステップアップと言えます。より熟慮的で選択肢の探索に優れ、複雑な作業の協調もこなせます。ただし長時間のオーケストレーションでは、依然としてFable 5の方が強力で効率的に見えます。
コードレビューでは、Opus 5 x-highはスペシャリストです。よりクリーンでアクション可能なサブセットを生成しますが、既知の問題の検出は少なく、かなりの量のnitpickも生成します。精度が重要な場面で使い、リコール重視のカバレッジと組み合わせ、開発者に届く前に出力をフィルタリングしてください。
