Opus 5/Sonnet 5のコードレビューでrecallが下がる原因

Opus 5/Sonnet 5のコードレビューでrecallが落ちる仕組み

自作のコードレビューハーネスをClaude Opus 5やSonnet 5に切り替えると、検出件数が減ることがあります。Anthropicの公式ガイドは、これをモデルの能力低下ではなくハーネス側の指示が原因の現象と説明しています。旧モデル向けに書いたレビュープロンプトが、新しいモデルには文字通り効きすぎるためです。

具体的には、レビュープロンプトに「high-severityの問題のみ報告して」「be conservativeに」「nitpickはしないで」といった指示が入っているケースです。Opus 5とSonnet 5はこうした指示を旧モデルより忠実に守ります。コードの調査そのものは同じ深さで行い、バグも実際に見つけているのに、指定した基準を下回ると判断した発見を報告しないのです。結果として、調査の質は変わらないまま報告件数だけが減り、recallの数値が下がります。precisionはむしろ上がる傾向にあり、「見つけた発見の精度は高いのに、見つけた総数が少ない」という一見矛盾した状態が生まれます。

「be conservativeに」という指示が招く逆説

この現象が厄介なのは、指示した側からするとモデルが指示通りに動いていることです。ハーネスの設計者が「重要な問題だけ報告してほしい」と書いた意図は正しく伝わっています。問題は、severityやconfidenceの判断をレビュー実行時の1パスに詰め込んでいる構成そのものにあります。

Sonnet 5のガイドは次のように整理しています。

Opus 5のガイドも同じ趣旨に触れています。Opus 5は高いprecisionとrecallでコードレビューを行い、実在するバグを高い割合で見つけると説明したうえで、「レビュープロンプトに『high-severityの問題のみ報告』や『be conservativeに』と書かれていると、モデルはそれを文字通り受け取って報告を減らす可能性がある」と注記しています。両モデルのガイドが独立に同じ注意点を挙げている点は、この挙動が特定モデル固有のクセではなく、指示追従性が上がった世代のモデル全般に共通する設計上の論点であることを示しています。

recallを取り戻すプロンプト設計

対処の方向性は一つです。発見の段階でフィルタリングさせず、まず全部報告させる。severityやconfidenceの判断は、後段の別ステップに切り出します。Sonnet 5のガイドが挙げている具体的な文言は次の通りです。

公式ガイドの推奨プロンプト文言(原文要約)

見つけた問題はすべて報告する。確信が持てないものや低severityと考えるものも含める。この段階では重要度や確信度でフィルタリングしない — フィルタリングは別の検証ステップが担う。ここでの目標は網羅性であり、後で除外されることになる発見を出す方が、実在するバグを黙って落とすより良い。各発見にはconfidenceレベルと推定severityを添え、後段のフィルタが優先順位を付けられるようにする。

このプロンプトは、実際には後段の検証ステップを持たなくても使えますが、confidenceによるフィルタリングを発見ステップから切り離すこと自体に効果があるとされています。ハーネスに検証・重複排除・ランキングの別ステージがあるなら、発見ステージの役割は「フィルタリングではなく網羅性である」とモデルに明示するのが有効です。

1パスで自己フィルタさせたい場合は、「important」のような曖昧な基準語を避け、線引きを具体的に書くことが推奨されています。たとえば「不正な挙動・テスト失敗・誤った結果につながるバグは報告し、純粋なスタイルや命名の好みのようなnitのみ省く」といった書き方です。

実例で見るプロンプトの書き換え

旧モデル向けのレビュープロンプトと、Opus 5/Sonnet 5向けに書き換えたプロンプトを並べると、変えるべき箇所がはっきりします。

Before(旧モデル向け・recallが落ちやすい書き方)

コードレビューを行い、high-severityの問題のみ報告してください。conservativeに判断し、確信が持てないものは報告しないでください。

After(Opus 5/Sonnet 5向け・網羅性を優先する書き方)

コードレビューを行い、見つけた問題はすべて報告してください。確信が持てないものや低severityと考えるものも含めます。この段階では重要度や確信度でフィルタリングしません。各発見にはconfidenceレベルと推定severityを添えてください。優先順位付けは後段の検証ステップで行います。

両者の違いは、判断基準そのものではなく「誰がいつその基準を適用するか」です。Beforeはモデルに発見と同時に基準を適用させ、Afterは基準の適用を後段に切り出しています。Opus 5・Sonnet 5は指示追従性が高いぶん、判断を前段に置いたままだと基準がそのまま効いてしまい、後段でしか判断しない設計に切り替える必要があります。

移行の効果を数値で確認する

書き換えたプロンプトが実際に効いているかは、体感ではなく数値で確認するのが確実です。Sonnet 5のガイドは、手元のevalやテストケースの一部に対してプロンプトを反復適用し、recallやF1スコアの変化を検証することを勧めています。レビューハーネスに既存の正解データ(既知のバグを仕込んだテストケースなど)があれば、旧プロンプトと新プロンプトそれぞれでのrecall・precisionを比較し、切り替えの前後でどちらが目的に合うかを判断できます。CIに組み込む前の小規模な検証だけでも、recall低下が指示文言由来なのか、別の要因なのかの切り分けに役立ちます。

Opus 5とSonnet 5で書かれ方が違う理由

同じ現象でも、両モデルのガイドでの扱い方には温度差があります。この違い自体が、公式ドキュメントの重心を読むヒントになります。

Opus 5のガイドではこの話題は「Code review and bug-finding」という能力紹介の1文に収まっています。一方Sonnet 5のガイドは独立した見出しを立て、原因の説明・推奨プロンプト・自己フィルタ時の線引きの書き方・評価による検証手順まで踏み込んでいます。Sonnet 5はコストと速度のバランスを取った主力モデルとして日常的なCI組み込みレビューに使われやすく、既存ハーネスの移行時に踏むトラブルとして重点的に文書化されたと見るのが自然です。Opus 5は複雑なタスク向けの上位モデルという位置付けもあり、同じ注意点でも記載は簡潔に留めています。両モデルの使い分け方はClaude Opus 5の使い方と仕様にまとめています。

コードレビューハーネスをClaude Codeのsub-agentとして構築している場合は、レビュー専任のsub-agentと修正適用のsub-agentを分けておくと、発見ステップとフィルタリングステップの分離がそのまま構成に反映されます。設計の考え方はClaude Code Sub-agents完全ガイドを参照してください。

既存ハーネスを移行するときの確認ポイント

旧モデル向けに調整したコードレビューハーネスをOpus 5やSonnet 5に切り替える際は、次の点を確認すると移行の手戻りを減らせます。

• レビュープロンプトに「conservativeに」「high-severityのみ」「nitpickしない」に類する文言がないか棚卸しする
• 発見ステップとフィルタリングステップが分かれているか確認し、分かれていなければ分離する
• 各発見にconfidenceとseverityを添えさせ、閾値判断は後段に寄せる
• 自己フィルタを維持する場合は、判断基準を「テスト失敗につながるか」のような具体的な条件に書き換える
• 移行前後でrecall・precision・F1のいずれかを手元のevalで比較し、体感ではなく数値で判断する

Opus 5のガイドはこの前提として、「低いeffort設定でも精度が保たれるため、レビュー時の高速パスと後段のより丁寧なパスを両方支えられる」とも述べています。速いパスで広く拾い、遅いパスで絞り込むという二段構成自体は、レビュー精度を落とさずにコストを調整する選択肢として公式に位置付けられているものです。

まとめ

Opus 5・Sonnet 5でコードレビューのrecallが下がって見えたときは、まずモデルの能力ではなくレビュープロンプトの指示文言を疑うのが妥当です。「conservativeに」「high-severityのみ」といった指示は、指示追従性が上がったモデルほど文字通り効き、報告件数を減らします。直し方は発見とフィルタリングの分離で、Sonnet 5のガイドが示す具体的な文言はそのまま使えます。既存のCIレビュー自動化や社内ツールをOpus 5・Sonnet 5に切り替える予定があるチームは、切り替え前にプロンプトの棚卸しをしておくと、recall低下を能力の問題と誤認せずに済みます。