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

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

Opus 5とSonnet 5は、現在は旧世代(legacy)に当たります。APIのモデル一覧で現行なのは、Claude Opus 5.5(claude-opus-5-5)とClaude Sonnet 5.5(claude-sonnet-5-5)です。Opus 5とSonnet 5も引き続き使えます。提供終了は、Opus 5が2027年7月24日以降、Sonnet 5が2027年6月30日以降です。この記事の対象は、Opus 5とSonnet 5のガイドです。

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

具体的には、レビュープロンプトに「high-severityの問題のみ報告して」「be conservativeに」「nitpickはしないで」といった指示が入っているケースです。Sonnet 5のガイドによれば、モデルはコードを同じ深さで調べてバグも特定したうえで、自分が基準未満と判断した発見を報告しません。調べた件数は変わらず、報告に変換される件数だけが減ります。特に低severityのバグで目立ちます。

precisionは通常上がる一方で、測定上のrecallは下がります。「報告した発見の精度は高いのに、総数が少ない」という一見矛盾した状態は、こうして生まれます。Opus 5のガイドも同じ注意を1文で挙げており、指示を文字通りに受け取って報告が減ると述べています。Opus 4.8でも同じ現象があり、直し方はOpus 4.8のコードレビューで見逃しが増えたときのプロンプト直し方にあります。

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

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

Sonnet 5のガイドは次のように述べています。

Opus 5のガイドは、Opus 5が高いprecisionとrecallでコードレビューを行い、追加の発見も多くは実在する問題だと説明しています。そのうえで「high-severityのみ」「be conservative」と書くと文字通りに受け取って報告を減らす、と注記しています。2つのガイドが別々の箇所で同じ注意点を挙げている以上、プロンプトの棚卸しは片方のモデルだけの話では済みません。

Sonnet 5のガイドには、もう一つ関連する記述があります。Sonnet 5は特に低いeffortで、指示を文字通りかつ明示的に解釈します。ある項目への指示を別の項目へ暗黙に広げることはせず、頼まれていないことも推測しません。レビュープロンプトに書いた基準は、書いた範囲でそのまま効くと考えておく方が安全です。

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

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

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

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

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

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

旧プロンプトと書き換え後を並べる

くらべる

レビュープロンプトの書き換え

旧モデル向け

Before

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

Opus 5/Sonnet 5向け

After

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

変わったのは判断基準そのものではありません。基準を誰がいつ適用するかです。Beforeは発見と同時に基準を適用させ、Afterは適用を後段へ回しています。

後段の検証ステップとOpus 5のガイドの食い違い

Sonnet 5のガイドは「別の検証ステップ」を前提に書かれています。一方、Opus 5のガイドの「Task scope and over-verification」には、逆向きに読める記述があります。Opus 5は頼まなくても自分の作業を検証するため、「重要なタスクには最終検証ステップを入れる」「サブエージェントで検証する」といった明示的な検証指示は外すよう求めています。外すと無駄なトークンが減り、品質は落ちないという説明です。同じ節は、検証ステップを足す旧ハーネスの足場にも当てはまると述べます。

2つは矛盾というより、検証の置き場所が違います。Sonnet 5のガイドが勧めるのは、発見の報告を絞るフィルタを別ステップに移すことです。Opus 5のガイドが外せと言うのは、モデルが自分の作業を二重に確かめるための指示です。

後段にモデルを呼ぶ検証パスを置くなら、その役割が「報告の取捨選択」か「作業の再確認」かを分けて書くのが安全です。Opus 5のガイドは、サブエージェントのチームをうまく連携させられ、writer-verifierのパターンも有効に働くと述べています。一方、委任の例文では、自分の作業の検証のためにサブエージェントを使わないよう指示しています。レビュー用の別パスを置くなら、役割は「自分の作業の再確認」ではなく「報告の取捨選択」に絞ります。

effortと出力量への影響

報告基準を緩めると、出力は増えます。ここは公式ガイドの記述から導ける運用上の注意です。

Sonnet 5のガイドでは、effortの既定はhighです。mediumはトークンを減らしたいコスト重視の用途向けで、lowは短く範囲の決まったレイテンシ重視の作業に限るとされています。lowでは頼まれた範囲に作業を絞るため、中程度に複雑なタスクで考えが浅くなるリスクがあるとも書かれています。

レビューは複数ファイルにまたがる推論を要することが多く、lowで発見数が少ないとき、原因をプロンプトだけに求めると見誤ります。ガイドは、浅い推論を見たらプロンプトで補う前にeffortをhighかxhighに上げるよう勧めています。

Opus 5のガイドはこれと対照的です。精度は低いeffortでも保たれ、レビュー時の高速パスと後段のより丁寧なパスの両方を支えられると述べています。「報告基準の緩和」と「effortの調整」は、別々のレバーとして切り分けて動かします。

effortの既定値を旧モデルから引き継いでいる場合は、見直しの対象です。Opus 5のガイドは、Opus 5の既定であるhighから始めてevalに基づいて調整し、品質が保てる場面ではlowとmediumを積極的に使うよう述べています。旧モデルから持ち込んだeffortの既定値は、自分のevalでeffortを振り直すよう勧めています。Sonnet 5には換算の目安もあります。Sonnet 5のmediumはSonnet 4.6のhighに、Sonnet 5のhighはSonnet 4.6のmaxに相当する知能です。比較するときは、effortの名前ではなく実際の思考の長さで合わせるとされています。

この換算はSonnet 5とSonnet 4.6の間のものです。Sonnet 5.5ではeffortの水準が再調整されており、同じ水準でもSonnet 5と同じ量の思考にはなりません。Opus 5.5の既定はmediumで、コーディングと知識作業の評価でOpus 5のhighと同等以上とされています。5.5へ移る場合は、Sonnet 5の換算を引き継がず、effortを振り直します。

Opus 5には、出力量について別の注意があります。effortを下げると思考の量は減りますが、見える応答の長さが確実に縮むとは限りません。全件報告に切り替えて出力が増えるレビューで長さを抑えたいなら、プロンプトで長さを明示して指示します。

もう一点、Sonnet 5は新しいトークナイザーを使い、同じ文章で約30%多くのトークンが出るとガイドの注記にあります。high以上のeffortでは、思考と応答でmax_tokensを使い切り、回答が途中で切れてstop_reason: "max_tokens"になることがあるとも書かれています。全件報告に切り替えて出力が増えるレビューでは、max_tokensの余裕を見直す対象になります。

切り分けから移行までの手順

以下は、公式ガイドの推奨(全件報告・具体化・evalでの反復)を、筆者が切り分けの順に並べた手順です。公式の診断フローではありません。

手順

recall低下を直すまで

1. 1

   プロンプトの基準語を探す

   「conservativeに」「high-severityのみ」「nitpickしない」に類する文言をすべて洗い出します。

2. 2

   発見とフィルタを分ける

   発見ステップでは全件報告させ、各発見にconfidenceと推定severityを添えさせます。閾値判断は後段へ寄せます。

3. 3

   残す自己フィルタは具体化する

   1パスのまま絞るなら、「テスト失敗につながるか」のような具体的な条件に書き換えます。

4. 4

   同じテストケースで両方を測る

   既知のバグを仕込んだテストケースに旧プロンプトと新プロンプトをかけ、recallとprecisionを比べます。

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

Sonnet 5のガイドは、手元のevalやテストケースの一部でプロンプトを反復し、recallやF1スコアの改善を確かめるよう勧めています。体感の「減った」では、指示文言が原因なのか、effortやmax_tokensが原因なのかを区別できません。

切り分けの目安は単純です。新プロンプトに替えてrecallが戻れば、原因は報告基準の指示でした。戻らないなら、前節のeffortと出力上限が次の候補になります。

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

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

移行時は、Sonnet 5側のガイドを実践の手引き、Opus 5側を注意喚起として読むと役割が合います。両モデルの違いはClaude Opus 5の使い方と仕様にまとめています。

コードレビューハーネスをClaude Codeのsub-agentで組んでいるなら、レビュー専任と修正適用に分けると、発見とフィルタの分離がそのまま構成に出ます。設計の考え方はClaude Code Sub-agents完全ガイドを参照してください。

まとめ

recallが下がって見えたら、能力を疑う前に、レビュープロンプトの基準語を探します。基準をモデルに任せて切るのではなく、発見は全件出させて後段で取捨選択する構成が出発点になります。指示の一般化の癖は、Sonnet 5が指示を一般化しない仕組みで扱っています。