同じAIにセルフレビューさせてもバグは減らない？異種モデル相互監査（Peer-Audit）の欠陥検出率の実測検証
実装したAI自身による自己チェックと、文脈を持たない別系統モデル（Codex等）による静的コード監査（N=28回）のバグ・境界条件漏れ検出数を比較
- コードを書いた本人（同一モデルの同一チャットセッション）に『バグがないか見直して』と指示しても、自分自身の思い込み（確証バイアス）を引きずるため、重大な境界条件バグ（P1/P2）の検出率はわずか 21.4% に留まった。
- 会話履歴（言い訳や意図）を一切共有せず、対象ファイルのコードだけを別系統のモデル（MCP peer-audit 経由の Codex 等）に渡して静的監査させると、正規表現の部分一致バグ・ファイル名衝突・数値クランプ歪みなどのP1/P2欠陥検出率が 82.1%（約3.8倍）に跳ね上がった。
- 最もコスト対効果が高いのは『全自動で毎回監査』ではなく、『外部入力バリデーション・正規表現・決済/集計ロジック変更時のみ別モデル監査を1回挟む』運用（1タスクあたり追加時間 約45〜90秒）。
1. レビュー方式別の重大ロジック・境界条件バグ（P1/P2）検出率の比較 単位: % (実際の欠陥に対する検出率)
2. 条件別・実測比較データテーブル 列見出しクリックで数値ソート可能
| 同一チャット内セルフレビュー | 21.4% | 約 15 秒 | 大 (全履歴を再送) | 単純なタイポ・構文ミスの修正 | 自分の設計ミスや境界条件漏れをほぼ見抜けない |
|---|---|---|---|---|---|
| 同一モデル・新規スレッド監査 | 53.6% | 約 35 秒 | 小 (対象ファイルのみ) | 一般的な例外処理漏れ・未使用変数 | 同系統モデルが好むアンチパターンを肯定しがち |
| 異種モデル静的監査 (Peer-Audit) | 82.1% | 約 62 秒 | 小 (対象ファイルのみ) | 正規表現の穴・単位換算ミス・上書き衝突 | リポジトリ全体の暗黙仕様を知らないとP3指摘が増える |
| 異種モデル監査 + 自動テスト併用 | 92.9% | 約 95 秒 | 中 | 実動確認 + 未知のエッジケース網羅 | 重要なコアロジック・公開前の最終ゲートに最適 |
3. 検証結果の詳しい解説・なぜこの差が出るのか？
1. なぜAIに「自分のコードを見直して」と言ってもバグが見つからないのか？
AIコーディングで最も多い失敗パターンが、実装させた直後に同じチャットで『バグやセキュリティ上の問題がないかチェックして』と聞くことです。28タスクの検証ログを分析すると、同一スレッド内のセルフレビューでは『問題ありません』『堅牢に実装されています』と太鼓判を押しながら、実際には負の数値やカンマ区切り数値でパースが壊れるバグを78%以上見逃していました。これはモデルの能力が低いのではなく、直前の自分の思考過程（Chain of Thought）がコンテキストにあるせいで、実際のコードではなく『自分が意図した仕様』を読んでしまうためです。
2. 解決策：会話履歴を遮断し、別系統のモデルに「反証入力例」を出させる
そこでMCP（Model Context Protocol）経由で、実装モデルとは別のモデル（例：実装がGemini/Claudeなら監査はCodex、あるいはその逆）に『会話履歴を一切渡さず、変更したファイルパスだけ』を渡す Peer-Audit 構成を検証しました。このとき『漠然とレビューして』ではなく『具体的な破綻入力例（Evidence）と行番号を示せ』と制約を課すことで、たとえば『run_mine("USB4", subreddit="A") の後に subreddit="B" を呼ぶと同名ファイルを上書きしてデータが消える』『official_value=0 でも最小幅4%にクランプされてグラフが嘘をつく』といった、人間でも気づきにくい仕様バグを1発で引き当てることができました。
3. 実践ワークフロー：いつ別モデル監査を呼ぶべきか？
すべての小さなCSS修正で毎回60秒かけて外部監査を回す必要はありません。実測データから導かれるベストプラクティスは、(1) 正規表現・パーサー・数値集計ロジックを書いたとき、(2) 認証・CSP・URL検証などのセキュリティ境界を触ったとき、(3) デザインやアーキテクチャの根本方針でセカンドオピニオンが欲しいときの3場面に絞って Peer-Audit を呼び出すことです。これだけで手戻りデバッグ時間が半分以下に減ります。
検証対象モデル・関連サービス公式リンク 公式・参考リンク (広告なし)
※上記は読者の利便性のための参考リンクであり、現在アフィリエイト報酬等は設定されていません。
4. よくある疑問と回答 (FAQ)
Q. 別モデルに監査させると、細かすぎる指摘（重箱の隅つつき）ばかりになりませんか？
監査プロンプトで Severity（P1: データ消失・脆弱性、P2: 特定入力でのロジック破綻、P3: スタイル・改善案）を明確に分離させ、『修正は勝手に適用せずレポートのみ返せ』と制限するのがコツです。P1/P2だけを無条件で直し、P3は人間の判断で取捨選択するとオーバーエンジニアリングを防げます。
Q. 監査モデルにはリポジトリ全体を渡すべきですか？
いいえ、変更した2〜4ファイルだけに絞って渡す方が、監査の精度も速度も高くなります。ファイルを絞り込むことで、モデルが1行ずつのデータフローや境界条件に集中して静的解析を行えるためです。
5. 検証条件・一次情報ソース (Provenance)
https://nodus-lab.pages.dev/articles/cross-model-peer-audit-bug-detection-benchmarks.html