「ベンチマーク高得点」AIでも“本番”で障害頻発 GitHubがLLMの誤検知を「95％削減」した7つの教訓：LLMを本番に出す前にやるべきこと（1/2 ページ）

GitHubは、LLMを本番環境への展開前に評価する方法について解説したブログ記事を公開した。

[＠IT]

　GitHubは2026年8月25日（米国時間）、大規模言語モデル（LLM）を本番環境への展開前に評価する方法について解説したブログ記事を公開した。

　この記事は、同社の「シークレットスキャン」機能の誤検知を減らすLLMベースのシステムを構築した経験に基づいている。シークレットスキャンは、リポジトリにコミットされた可能性があるトークンやキーなどの認証情報を検出する機能だ。

　GitHubは、この構築経験で得られた以下の教訓は、コード分析、開発者ツール、セキュリティ、データ分析用のLLMシステムに幅広く当てはまるとしている。

「ベンチマーク高得点」AIでも“本番”で通用しない――評価時7つの教訓

　GitHubによると、言語モデルはクリーンなベンチマークで好成績を収めても、本番環境の重要なケースで苦戦することがある。システムがプロトタイピングから本番展開に近づくにつれ、評価の課題が変わるからだ。

　現実の入力データは曖昧なことが多く、ラベルには一貫性がない場合があり、重要なコンテキストが欠落していることもある。ベンチマークにほとんど現れないエッジケースが、頻発する障害の原因になる場合もある。

　シークレットスキャンでは、本物の認証情報ではないが、シークレットに似た文字列に遭遇することがあるので、開発者は、修復措置が不要なアラートの調査に時間を取られる羽目になりかねない。そこで、LLMが文字列を正しく分類できるかどうかではなく、セキュリティワークフローとして安全性を保てるだけの再現率（※）を維持しつつ、ノイズとなる誤検知アラートを減らすことが重要になる。

※「陽性」の全サンプルのうち、「陽性」と正しく分類されたサンプルの割合。「真陽性率」ともいう（参考）。

LLM評価のライフサイクル。プロダクト上の意思決定から、代表的なデータセット、オフライン評価、エラー分析、的を絞った変更、リグレッション評価を経て、オンライン実験に至る（提供：GitHub）

教訓1．モデルではなくプロダクト上の意思決定を起点に

　LLMシステムの性能が期待を下回ると、チームはプロンプトの書き換えやモデルの変更に飛び付きがちだ。GitHubは、その前に「プロダクト（最終的なLLMシステム）に関するどのような意思決定を支援するために評価するのか」を定義すべきだと主張する。

　GitHubは、「本番環境のセキュリティワークフローにおいて安全を確保できる十分な再現率を維持しつつ、シークレットスキャンの誤検知を減らす」というプロダクト目標を可能にする意思決定の支援という観点から、シークレットスキャンの評価基準を次の3つのレベルに整理した。

1. 主要な成果：誤検知の削減、検出精度。ユーザーメリットを測定する
2. 安全性の制約：再現率。許容できないセキュリティリスクをもたらす“見かけ上の改善”を防ぐ
3. 運用上のガードレール：レイテンシ（遅延）、コスト、信頼性、本番互換性。デプロイ（展開）が現実的かどうかを判断する

　シークレットスキャンでは、本物の認証情報の検出を抑制してしまうことは、開発者に余計なアラートのレビューを求めることよりも重大な結果を招く。このため、GitHubは再現率を安全性上の制約として扱い、低下があらかじめ定めた範囲に収まる場合にのみ実験を先に進めた。検出精度が向上しても、再現率のガードレールに違反する変更は改善ではないと見なした。

教訓2．オフライン評価を統合テストのように扱う

　LLMベースのシステムは、最初の評価後も変化し続ける。チームはプロンプトを改訂し、新しいモデルを採用し、周辺ロジックを見直すからだ。そこでGitHubは、オフライン評価をエンドツーエンドの統合テストのように扱い、意味のある変更を行うたびに再実行した。

　さらに、オフライン評価結果を既知のベースラインと比較できるように、評価を実行するごとにプロンプト、モデル、データセットのバージョン、システム構成を記録した。

一度に1つの主要な変数だけを変更する

　一度に変更する主要な変数は1つに限定した。プロンプト改訂とモデルアップグレードを同時に行うと、改善やリグレッションの原因がどちらにあるのか分からなくなるからだ。プロンプトや評価構成はコードと同様にバージョン管理し、ロールバックを可能にした。

評価実行の記録例（表中の値は説明用の架空のもの）（提供：GitHub）

　GitHubは、モデルを定期的にアップグレードし、テストすることも推奨する。より強力なモデルは、旧モデルを入念にチューニングするよりも、シンプルなプロンプトで高い性能を発揮する場合があるからだ。シンプルなプロンプトは保守も容易だ。

教訓3．オフライン評価を本番環境に近づける

　オフライン評価は、本番でシステムが実行するタスクに似ている場合にのみ有用だ。シークレットスキャンのワークフローでは、LLMが単一のクリーンで孤立した値を評価することはめったにない。対象となる文字列を周囲のコードや、不完全な、あるいは紛らわしいこともある他の情報とともに評価しなければならない。

　下の例では、評価対象の候補（candidate_value）の近くに「example_token」という変数があり、その名前の方がセキュリティに関連しているように見えるので、LLMは誤って後者に注目し、もっともらしい説明を生成してしまうことがある。

example_token = "sample_value_for_documentation"
production_api_key = get_secret_from_environment()
candidate_value = "flagged_value"

評価対象の候補の近くに紛らわしい値がある、本番環境に近い入力形式の例（提供：GitHub）

　この種の失敗は、評価例に明白な候補が1つしか含まれていないと見逃しやすい。GitHubは、ワークフローに存在するこうした曖昧さをオフライン評価に組み込んでいる。