敵対的検証をLLMコードレビューで試すと何が起きるのか

LLMを使ったコードレビューの精度を高める手法として、最近「敵対的検証」が注目されている。具体的には、コードの問題を指摘するエージェント（Reviewer）と、その指摘を反論する役のエージェント（Critic）が対話的にやり取りを重ねることで、本当に重要なバグだけを浮き彫りにする仕組みだ。Reviewer が問題候補を洗い出し、Critic がコード上の証拠を示して反論する。その過程で「この指摘は正しいか」「見落としている問題はないか」が繰り返し検証されるという流れである。

ここで興味深いのは、既存手法と比較して精度が3ポイント向上した一方で、トークン消費は4.5倍に増えたという結果だ。これはAIエージェント時代の本質的なトレードオフを示している。「より高精度」を求めるほど、処理コストが指数関数的に増加する。つまり、コードレビューの完璧さを追求することと、月々のAI費用を抑えることは相反する。さらに見逃すべきでないのは、この手法が「バグ狩り」には有効でも、ビジネスロジックの妥当性や設計の根拠といった人間的な判断が必要な領域には対応できていない点である。敵対的検証は機械的な検証には最強だが、判断には弱い。この使い分けを理解せずにAIコードレビューを導入すると、逆に意思決定が遅くなる罠にはまる。

中小企業のコード品質管理で学ぶべきは、自社のレビュープロセスを「バグ検出」と「方針・設計判断」に明確に分離することだ。前者はAIに任せ、後者は人間が担当するという棲み分けを組織で定義する。同時に重要なのは、「完璧なレビューがゴール」ではなく「コスト相応の精度でいつリリースするか」という現実的な意思決定基準を、チーム全体で共有することである。手段が目的化して、AI導入のせいでレビューが終わらない、という本末転倒を避けるために。