経験豊富なレビュアー 2 人に同じプルリクエストを読ませれば、出てくるリストは 2 つとも違います。一方は URL の識別子がセッションと突き合わされていないことに気づき、もう一方はリトライのループが失敗のたびにデータベース接続を開いたままにしていることに気づきます。どちらも間違ってはおらず、どちらも完全ではありません。言語モデルも同じ理由で同じように振る舞います。レビュアーが何に気づくかは、それまでに何を見てきたかで決まるからです。
一致はシグナルである
単一のモデルは自分の確信度を教えてくれます。その数値には意味がありますが、あくまで自己申告です。モデルが自分の答案を採点しているのです。異なる研究所が、異なるデータで、異なる弱点とともに訓練した 2 つのモデルが、独立に同じファイルの同じ弱点にたどり着いたとき、その一致はモデルの外から来た証拠になります。自動レビューがセカンドオピニオンに最も近づく瞬間です。
逆も同じだけ重要です。片方のエンジンだけが報告した指摘が自動的に誤りになるわけではなく、それを捨てることは単独のレビュアーが得意とするバグをそのまま捨てることになります。だからこそ報告し、どのエンジンが見つけたかを示します。判断するのはあなたです。
片方のエンジンが黙る場所
実際に 2 つのエンジンが最も食い違うのは、パターン照合ではなく推論を要するバグの種類です。
- ロジックの欠陥: 二重に適用される割引、返金の後にもう一度返金を受け付ける状態機械、誤ったオブジェクトに対して走る所有権チェック。
- フレームワーク固有の認可: ルートグループは保護するのに、その隣にマウントされた API ハンドラーは保護しないミドルウェア。
- リソースとメモリのリーク: リクエストごとに開かれ、正常系でのみ解放されるリスナー、タイマー、コネクション。
- コメントやフィクスチャに隠されたプロンプトインジェクション。探していなければ無害な文章に読めます。
2 つのレポートを 1 つにする方法
統合こそ、2 つ目のエンジンが元を取るか、ノイズを倍にするかの分かれ目です。私たちが定めたルールは次のとおりです。
- 指摘は表現ではなく、バグを識別するもの、つまり CWE クラスとそれが存在するファイルで突き合わせます。
- 一致した指摘は 1 回だけ、2 つのうち厳しい方の深刻度で報告します。行動すべきなのは安全側の読みだからです。
- 残すのは開発者が動ける記述です。より長い根拠、具体的なパッチ、順序立てた修正手順。
- 裏付けの取れた指摘は信頼度を高に引き上げ、両方のエンジン名を付けます。
- 片方のエンジンだけが見た指摘も、見つけたエンジン名を添えて残します。
2 つのエンジンは同じソースを同時に読むので、監査時間が倍になることはありません。倍になるのは実行コストで、Pro プランに属している理由はそこにあります。2 つ目のエンジンが使えない、あるいは使えない応答を返した場合、監査は失敗せず 1 つ目だけで完了します。
これらはどれもレポートを真実にするものではありません。2 つのエンジンが一致して両方とも間違っていることはあり得ます。各指摘の下に引用された根拠は、信じるのではなく確かめてもらうためにあります。裏付けが与えてくれるのは優先順位です。100 件の指摘が届き、使える時間が半日なら、2 つの独立したレビュアーがともに見たものから始めてください。