GitHubがLLM本番投入前の評価手法を公開 誤検出削減の事例から学ぶ

本番では評価が変わる

GitHubは2026年8月25日、LLMを本番環境に投入する前の評価方法について、実践的な知見を公開しました。対象は、シークレットスキャンの誤検出削減にLLMを活用したシステムです。シークレットスキャンとは、リポジトリにコミットされたトークンや鍵などの認証情報を検出する機能です。

記事はまず、クリーンなベンチマークで良い結果が出ても、本番で重要なケースに苦戦することがあると指摘します。実際の入力は曖昧で、ラベルは一貫せず、重要な文脈が欠けていることもあります。ベンチマークではまれなエッジケースが、本番では一般的な失敗要因になり得るのが実情です。GitHubの記事は、こうした乖離にどう対処するかを整理した内容です。

製品判断から評価を設計

評価の設計で最初に考えるべきは、モデルではなく製品としての判断です。GitHubはシークレットスキャンで「誤検出を減らせるか、安全性を保てるだけの再現率を維持できるか」を問いとして設定しました。誤検出削減を主要成果、再現率を安全制約として扱い、両者を同等に交換可能な指標とは見なしていません。

評価基準は「主要成果」「安全制約」「運用上のガードレール」の3層で構成されます。誤検出が減っても再現率を大きく下げる変更は改善とはみなされません。品質が良くても、速度が遅すぎる、コストが高すぎる、統合が難しいといった問題があれば、本番には載せられません。この層構造によって、何を優先し、どこで妥協できるのかが明確になります。記事は、精度だけを見れば強く見える実験Aよりも、再現率の制約を守りながら誤検出を減らした実験Bの方が製品目標に沿っているという例を示しています。

統合テストとして運用

オフライン評価は一度実行すれば終わりではありません。GitHubは、意味のある変更のたびに再実行する、エンドツーエンドの統合テストと同じように扱いました。実行のたびにプロンプト、モデル、データセットのバージョン、システム構成を記録し、既知のベースラインと比較できるようにしています。

一度に変える変数は1つに絞ります。プロンプトとモデルを同時に変えると、どちらが結果に影響したのか分からなくなるためです。プロンプトと評価構成はコードと同じようにバージョン管理し、過去の設定を再現できる状態を保ちます。

オフライン評価は、本番のタスクに近い形で行うことが重要です。実際のシークレットスキャンでは、候補値を周囲のコードや関連情報と一緒に評価するため、文脈の欠落やノイズを再現したデータが必要になります。きれいなデータセットだけでの評価は、本番より簡単な問題を解いているのと同じという指摘です。

データとエラー分析

本番データのラベルは「シグナル」であって、絶対的な真実ではありません。開発者がアラートを解決した理由は、認証情報のローテーション、リスクの許容、ワークフローを進めるための対応など様々です。そのため、重要なデータや曖昧なデータについては、手作業でのレビューが必要だとしています。

合成データやオープンデータセットは、本番データが不足している段階で評価のカバレッジを補うために使えます。ただし、本番を模したデータの代わりにはなりません。GitHubは、認証情報に似た値が近くにあるケースや、文脈が欠落したケースを合成データで再現しました。

集約指標だけでは、次に何を変えるべきかは分かりません。GitHubは誤検出と見逃しのサンプルをレビューし、モデル、プロンプト、入力、パイプライン、データセット、ラベルのどこに原因があるかを分類しました。このエラー分析によって、集約指標では見えない失敗パターンが明らかになったとしています。