GitHub、本番前LLM評価で誤検知95%減達成

評価設計の原則

製品判断を起点に評価設計
Recallは安全性の制約条件
3階層の評価基準を設定

継続的な検証体制

オフライン評価を統合テスト化
一度に1変数のみ変更
モデル更新も定期的に検証

データと分析手法

本番ラベルは参考情報扱い
誤検知95%減を達成
詳細を読む

GitHubは2026年8月25日、認証情報の誤コミットを検出するシークレットスキャニング機能で、LLMによる誤検知削減システムを本番投入前に評価した手法を公開しました。Microsoftの応用科学者チームが主導し、誤検知を95%削減しながら安全な検知精度を維持したといいます。

一般にLLMシステムが期待通りに動かないと、プロンプトやモデルなど技術的な要素をすぐ調整しがちですが、同チームはまず「どの意思決定を評価が支えるべきか」を明確にすることを重視しました。誤検知を減らしつつ十分なRecallを保てるか、という製品上の問いを軸に、精度を主目的、Recallを安全制約、レイテンシーやコストを運用ガードレールとする三階層で評価基準を整理したとのことです。

オフライン評価は一度きりの作業ではなく、統合テストのように継続的に扱うべきだと強調しています。プロンプトやモデル、データセットのバージョンを毎回記録し、既知のベースラインと比較。変更する変数を一度に一つへ絞ることで、精度の変化がどの要因によるものかを正確に切り分けられるようにしたといいます。モデルのアップグレードについても定期的に評価し、より単純なプロンプトで高い性能を発揮できないか検証したそうです。

本番環境で生成されたラベルも「絶対的な正解」ではなく参考情報として扱うべきだと指摘しています。開発者がアラートを解消した理由には認証情報のローテーションや誤分類などさまざまなケースがあり、必ずしも誤検知を意味しないためです。合成データやオープンデータセットで希少なケースを補いつつ、誤検知と見逃しの事例を要因ごとに分類するエラー分析によって、次に改善すべき点を具体化したといいます。

全件を人手でレビューするのは非効率なため、LLMを判定役として使い、明確なケースは自動処理し、判断が難しいケースのみ人間のレビューへ回す「トリアージ」方式を採用しました。こうした一連の取り組みにより、オフラインデータセットで誤検知を95%削減しつつ定めたRecallの許容範囲を維持することに成功し、本番投入前の実証実験を進める十分な根拠を得られたとしています。