証拠を求める仕組みは、その証拠が正しいかまでは確かめない

株式会社ナレッジセンスCTOの須藤英寿氏は、LLMによるコードレビューに敵対的検証を組み込んだ実験を公開している(出典)。構成は単純で、まずReviewer役がバグや考慮漏れのエッジケースを指摘する。次にCritic役がその指摘を検証し、AGREE(問題なし)、DISAGREE_EVIDENCE(コード上の証拠を示して反論)、DISAGREE_CONCERN(疑問は残るが反証は見つからない)のいずれかで応答する。両者の意見が一致するまでこのやり取りを繰り返す。既存手法との比較でF1スコアは3ポイント上がったが、トークン消費はゼロショット比で約4.5倍に増えた。

このCriticの設計で目を引くのは、反論に証拠を義務付けている点だ。須藤氏は「なんとなく問題ではなさそうだから無視する」「問題っぽいから指摘として残す」といった曖昧な対応を減らすことを狙いとして明示している。根拠のない同意(false consensus)を防ぐ効果を、証拠の提示という一手間に担わせている。

Why-notの裏付けになる、と思いかけた

PRレビューツールParryを開発している立場からこの実験を読むと、Parryが要求するWhy-not(採用しなかった代替案とその理由)の正しさを裏付ける材料に見える。理由や証拠を書かせることで判断の精度が上がるという実験結果は、Parryの四軸設計、特に根拠を書かせるという発想そのものへの外部的な裏付けになる。そう考えたくなる。

だが、F1スコアが3ポイント上がったという数字が測っているものを確かめると、話はそこで止まらない。F1スコアは、事前にラベル付けされた既知のバグ集合と、Criticが最終的に下した判定との一致率のはずだ。個々のDISAGREE_EVIDENCEに示された証拠そのものが、論理的に正しいかどうかを人間が検証した結果ではない。証拠を出させたことでCriticの最終判定が改善したという効果は測られているが、出された証拠一つひとつの中身が本物かどうかは、この実験の外にある。

証拠を求めることと、証拠が正しいことは別の層にある

この二つを分けて考えると、須藤氏の実験は前者(証拠を求める設計の効果)しか測っていない。証拠の中身が正しいかどうかという後者は、依然として別の検証者を必要とする問いのまま残る。この分け方は、Parryの四軸にもそのまま当てはまる。PRのWhy-not欄に「代替案Aは採用しなかった、理由はXだから」と書かれていても、Xが事実として正しいかをParryが機械的に確認する仕組みはない。書かせることと、書かれた内容の正しさを確かめることは別の層の問題であり、須藤氏の実験もこの二層を混同していない。

そう見ると、須藤氏が用意した3分類のうち、地味に見えるDISAGREE_CONCERNの位置づけが際立ってくる。証拠が見つからないという事実を、AGREEでもDISAGREE_EVIDENCEでもない独立した状態として残しているからだ。無根拠な同意を防ぐ一次防御は、証拠を求めることで達成できる。だが証拠の中身を検証する二次防御が必要な箇所は、DISAGREE_CONCERNというラベルによって、少なくとも「まだ確かめていない」と名指しされたまま次の工程に渡される。

4.5倍のコストと釣り合っているかは、まだ分からない

須藤氏はトークン消費が4.5倍に膨らんだことについて、検証効率化とレビュー負荷低減で解決できるという見通しを述べているが、その具体策は記事に書かれていない。証拠を求める一次防御のコストと、証拠を検証する二次防御のコストは別物であるはずで、前者の4.5倍という数字だけでは、後者にどれだけの負荷が残っているのかは分からない。ParryのWhy-not欄も、書かせるコストと、書かれた内容を人間が確かめるコストの両方を要求する設計になっている。この二重のコストが釣り合っているのかどうかは、須藤氏の実験からも、Parry自身の運用からも、まだ答えが出ていない。