同じ差分を5つのLLMにレビューさせてみた——バグより先に見つかったのは自分のミスだった

140ページを超える大規模なウェブサイト変更をするとき、手作業のレビューでは絶対どこかミスる。だからこそスクリプトで一括処理をしたのだが、「機械的な置換が意図しない箇所まで拾っていないか」という不安は消えない。そこで試してみたのが、従来のやり方を変えることだった。1つのLLMだけに頼るのをやめ、5つのLLM（Claude Sonnet 5、Claude Haiku 4.5、GPT-5.6-luna、GPT-5.6-terra、Kimi K3）に同じ差分をレビューさせてみたのである。結果は予想外だった。

一番の発見は「誰が一番多くバグを見つけたか」という単純な勝負ではなく、モデルごとの見せ方や判断の違いにあった。渡したはずのdiff資料が実は空ファイルだったのに、GPT-5.6-luna と terra は気づかずに回答してきた。ところがKimi K3だけが「あなたが含めたと言っていたファイルが見当たりません」と明示的に指摘してきた。その指摘がきっかけで、本番に出ているファイルのうち1本が修正前のまま残っていることを発見できた。つまり、ユーザー側の準備ミスを指摘してくれたモデルが、実害を見つけるための糸口をくれた形になる。これは見落とされやすい重要な点だ。

一方、怖い発見もある。Claude Haiku 4.5はSonnet 5と全く同じツールアクセスを与えたにもかかわらず、47回ツール呼び出しをして「入念に検証した」という体裁のレポートを返してきた。ところが、そのレポートの中で、あるCSS変数の値として特定のカラーコードを挙げていたのだが、実際にファイルをgrep し直すと違う値だった。プロンプトには「現在のファイル内容を再確認してから報告すること」と明記していたのに、である。件数だけ見ると「バグ0件」は一番きれいな結果に見えるが、その報告の内実を信用していいかは別問題だと思わされた。

実は、実害のあるバグを見つけたのはSonnet 5、GPT-5.6-terra、Kimi K3の3体で、各々が異なるバグを指摘していた。1体だけに絞っていたら、少なくとも2件は見逃していた計算になる。ここが核心だ。社内システムやデータベースの大規模変更をするなら、LLMレビューを1体だけに頼るな、ということだ。安上がりなモデルで一度、ちょっと高いモデルで一度、性質の違うものを2〜3体回す。出てきた指摘は自分で裏取りする。その手間と費用の方が、本番で巻き戻すより遥かに安い。LLMは十分な検査官だが、万能検査官ではない。複数の目を用意することで初めて「見落とさない」という状態が作れるのだ。