# 同じAIにセルフレビューさせてもバグは減らない？異種モデル相互監査（Peer-Audit）の欠陥検出率の実測検証

> 実装したAI自身による自己チェックと、文脈を持たない別系統モデル（Codex等）による静的コード監査（N=28回）のバグ・境界条件漏れ検出数を比較

- **Canonical URL**: https://nodus-lab.pages.dev/articles/cross-model-peer-audit-bug-detection-benchmarks.html
- **CSV Dataset**: https://nodus-lab.pages.dev/datasets/cross-model-peer-audit-bug-detection-benchmarks.csv
- **Raw Verification Log (JSON)**: https://nodus-lab.pages.dev/logs/cross-model-peer-audit-bug-detection-benchmarks.json
- **Category**: Software & SaaS Economics
- **Sample Size (N)**: 28
- **Data Updated**: 2026-10-12

## 結論・実測サマリー (TL;DR)
- コードを書いた本人（同一モデルの同一チャットセッション）に『バグがないか見直して』と指示しても、自分自身の思い込み（確証バイアス）を引きずるため、重大な境界条件バグ（P1/P2）の検出率はわずか 21.4% に留まった。
- 会話履歴（言い訳や意図）を一切共有せず、対象ファイルのコードだけを別系統のモデル（MCP peer-audit 経由の Codex 等）に渡して静的監査させると、正規表現の部分一致バグ・ファイル名衝突・数値クランプ歪みなどのP1/P2欠陥検出率が 82.1%（約3.8倍）に跳ね上がった。
- 最もコスト対効果が高いのは『全自動で毎回監査』ではなく、『外部入力バリデーション・正規表現・決済/集計ロジック変更時のみ別モデル監査を1回挟む』運用（1タスクあたり追加時間 約45〜90秒）。

## 主要実測指標 (Key Metrics)
- **P1/P2 実質バグ検出率**: 21.4% → 82.1% (同一スレッド自己見直し vs 異種モデル分離監査)
- **境界条件・正規表現バグ発見数**: 3.8倍 (符号欠落・ゼロ除算・同名上書き等の検出)
- **誤検知 (False Positive) 率**: 14.2% (プロンプトで「具体的な再現入力例」を必須化時)
- **1回あたり平均監査所要時間**: 約 62 秒 (2〜3ファイル対象の静的コード監査中央値)

## 条件別・実測比較データテーブル
| コード監査方式 | P1/P2バグ検出率 | 平均所要時間 | 追加トークン消費 | 得意な検出領域 | 主な弱点・注意点 |
| --- | --- | --- | --- | --- | --- |
| 同一チャット内セルフレビュー | 21.4% | 約 15 秒 | 大 (全履歴を再送) | 単純なタイポ・構文ミスの修正 | 自分の設計ミスや境界条件漏れをほぼ見抜けない |
| 同一モデル・新規スレッド監査 | 53.6% | 約 35 秒 | 小 (対象ファイルのみ) | 一般的な例外処理漏れ・未使用変数 | 同系統モデルが好むアンチパターンを肯定しがち |
| 異種モデル静的監査 (Peer-Audit) | 82.1% | 約 62 秒 | 小 (対象ファイルのみ) | 正規表現の穴・単位換算ミス・上書き衝突 | リポジトリ全体の暗黙仕様を知らないとP3指摘が増える |
| 異種モデル監査 + 自動テスト併用 | 92.9% | 約 95 秒 | 中 | 実動確認 + 未知のエッジケース網羅 | 重要なコアロジック・公開前の最終ゲートに最適 |

## 詳細解説・原因分析
### 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 を呼び出すことです。これだけで手戻りデバッグ時間が半分以下に減ります。

## よくある疑問と回答 (FAQ)
### Q. 別モデルに監査させると、細かすぎる指摘（重箱の隅つつき）ばかりになりませんか？
A. 監査プロンプトで Severity（P1: データ消失・脆弱性、P2: 特定入力でのロジック破綻、P3: スタイル・改善案）を明確に分離させ、『修正は勝手に適用せずレポートのみ返せ』と制限するのがコツです。P1/P2だけを無条件で直し、P3は人間の判断で取捨選択するとオーバーエンジニアリングを防げます。

### Q. 監査モデルにはリポジトリ全体を渡すべきですか？
A. いいえ、変更した2〜4ファイルだけに絞って渡す方が、監査の精度も速度も高くなります。ファイルを絞り込むことで、モデルが1行ずつのデータフローや境界条件に集中して静的解析を行えるためです。

## 検証環境・集計メソドロジー
実際のPython / TypeScriptプロジェクト開発28タスクにおいて、(1) 実装担当モデル自身による同一スレッド内セルフレビュー、(2) 同一モデルの新規スレッド（履歴リセット）でのレビュー、(3) 異種モデル（MCP peer-audit 経由で対象ファイルのみを渡す完全分離型の静的監査）の3方式を実行し、テストスイートまたは人間が後から確認した実バグ（P1: データ破損・例外、P2: 境界条件・ロジック不整合、P3: 設計・保守性）の検出数を集計。