Claude Code /code-review の effort は low で足りる？low/high を3回ずつ実測した検出率の差

Claude Codeの/code-reviewは複数のeffortレベルを提供している。だが、effortを上げれば上げるほど「多くのバグが見つかる」のか。その疑問に答えるため、7件の欠陥を仕込んだPRに対してlowとhighを3回ずつ実行し、検出率を比較した。結果は意外だった。lowは4件を検出（全て正解、致命的なバグ3件含む）、highは10件を検出（仕込んだ欠陥6件、実在バグ1件、残り3件は回ごとに変動）。処理時間はlowが15秒以内、highは数分だ。

驚くべきは「深刻度別の検出パターン」だ。致命的・重大なバグ3件はlowが3回とも全て検出した。一方、highが上乗せした6件は中程度と軽微なバグだけだ。つまりeffortを上げても「見逃していた重大バグが見つかる」のではなく、「細かい問題がノイズとして追加される」だけなのだ。さらに競合状態のようなコード構造的欠陥は、low・high合わせて6回すべて検出されなかった。つまり、AIレビューは確信度の高いバグは拾うが「構造的問題」は見落とす傾向があるということだ。

高effortの挙動から推測すると「トップNランク」で報告数が固定されている可能性がある。実際の候補は毎回異なるのに、毎回ちょうど10件で切られる。カットラインの近辺では、指摘の順位が回ごとに変動し、下位の指摘が浮上したり沈んだりする。また、同じ位置を指摘していても「説明が間違う」こともある。つまり「高effort＝網羅的」ではなく「高effort＝ノイズが増え、確信度が下がる」のだ。

中小企業の実務への含意は明快だ。コードレビューは「effortを上げて人手を削る」のではなく「effortと運用を使い分ける」ことが正解である。日常の差分はlowで回し、十数秒で流れるように直す。大型変更やアーキテクチャが絡む箇所だけhighで深掘りする。そしてhighの指摘を鵜呑みにしない。AIの指摘は「場所は信じるが、説明は疑う」という読み方が、失敗を避ける最小限の工夫だ。構造的欠陥は人間の注視とUNIQUE制約やトランザクションで防ぐ。つまりAIレビューは「補助」であって「代替」ではないのだ。