大規模言語モデルは、整備されたベンチマークでは優れた結果を出しても、本番環境で実際にユーザーにとって重要となる曖昧なケースではつまずくことがある。これは、Mariko WakabayashiとZixiao Chenが2026年8月25日付で執筆した記事でGitHubが示す中心的な教訓であり、GitHub secret scanningにおける誤警告を減らすために大規模言語モデルを利用するシステムの評価経験に基づいている。
秘密情報スキャンは、ソフトウェアリポジトリに登録された可能性のあるトークンや鍵などの認証情報を探す。しかし、一部の文字列は秘密情報に似ていても実際の認証情報ではないため、開発者は対応の必要がないアラートを確認することになる。そのためチームにとっての問いは、モデルが単独の文字列を分類できるかどうかではなく、セキュリティ上重要なワークフローを安全に維持できるだけの再現率を保ちながら、ノイズを減らせるかどうかだった。
モデル選びではなく、プロダクト上の意思決定から始める
GitHubは、プロンプトを変更したり、コンテキストを追加したり、モデルを変更したりする前に、評価が支援すべき意思決定を定めることを推奨している。秘密情報スキャンの場合、目標は誤警告を減らして適合率を高めることであり、再現率は安全上の制約として扱われた。実際の認証情報を誤って見逃すことは、開発者に追加のアラート確認を求めることよりも危険になり得る。
実際には、評価基準を3層に分けた。ユーザーにとっての有用性を測る基本結果は、誤警告の削減と適合率である。安全上の制約は再現率であり、運用上のガードレールには、応答時間、コスト、信頼性、本番環境との互換性が含まれる。これにより、適合率が向上しても、再現率が許容できないほど低下したり、システムが遅く、高価で、統合しにくくなったりすれば、自動的に成功とはみなされない。
評価を再現可能な統合テストにする
評価はリリース前に一度だけ行う手順ではない。プロンプト、モデル、入力の構築方法、それらを取り巻くシステムロジックは常に変化し、どの変更も改善、悪化、またはエラーパターンの別の場所への移動を引き起こす可能性がある。そのためGitHubは、重要な変更のたびに評価を再実行し、その都度、プロンプトのバージョン、モデル、データセット、システム設定を記録した。
またチームは、各実験で主要な変数を1つだけ分離し、モデルのアップグレードを試す前に、プロンプトの変更を既知のベースラインと比較した。プロンプトと評価設定はコードと同じように扱われ、バージョン管理され、変更が文書化され、以前の設定を再実行してロールバックできる状態が維持された。この実践により、改善や悪化の原因を、直前の変更のせいだと誤って判断するのではなく、特定できる。
クリーンなデータだけでなく、本番のタスクを再現する
オフライン評価の結果は、実際のタスクに似ているほど有用になる。秘密情報スキャンでは、モデルは必ずしも単独の値を見るのではなく、周囲のコードや、不足していたり分散していたりする補助情報を含む候補を確認する。また、評価対象の候補ではなく、コード中のテスト用トークンなど、セキュリティとの関連性がより高く見える別の値に注目することもある。
そのため、本番タスクの特性を維持する必要がある。そこには、評価対象の候補、周囲のコンテキスト、補助情報、入力の形式と制約の適用方法、そしてより広範なシステムロジックが含まれる。評価で現実よりも明確な例や完全なコンテキストを使うと、結果はデプロイ後にシステムが直面するものより簡単な問題を反映する可能性がある。
ラベルとデータを検証可能な証拠として扱う
プロダクト上で特定の操作が行われたという結果は、信頼できる正解データを意味しない。秘密情報スキャンでアラートが閉じられた場合、それは認証情報がローテーションされたこと、リスクが受け入れられたこと、ワークフローを開始するためにアラートが閉じられたこと、または誤って分類されたことを意味する可能性がある。これらのケースはワークフローデータ上では似て見えるが、評価における同じ問いに答えるものではない。
本番データを使う前に、ラベルがどのように作成されたのか、評価の問いと一致しているか、異なる結果が1つのカテゴリーにまとめられていないかを把握する必要がある。GitHubは、すべてのラベルが正しいと仮定するのではなく、重要または曖昧なカテゴリーについて人によるレビューを行うことを提案している。合成データや公開ベンチマークは、特にコンテキストの欠落、通常とは異なる形式、認証情報に似た近似値など、まれなケースのカバレッジの不足を補える。ただし、本番に近いデータを置き換えるのではなく、それを補完するものとして使うべきである。
エラーを分析し、評価モデルは慎重に使う
総合指標はシステムが改善したかどうかをチームに伝えるが、次に何を変更すべきかは説明しない。そのためGitHubは、偽陽性と偽陰性のサンプルを確認し、その原因候補をモデル、プロンプト、入力、パイプライン、データセット、ラベルのいずれかに分類した。この分類により、一般的な品質問題が、入力のフレーミング改善、異なるコンテキストの構築、データのクリーニング、より明確なプロダクトポリシーといった具体的なエンジニアリング作業に変わる。
別の大規模言語モデルを評価者として使えば、人によるレビューの負担を減らし、明確なケースを処理したり、曖昧なケースを優先順位付けしたりできる。しかし、その出力は基準となる真実ではない。誤る可能性があり、誤った理由で評価対象のモデルと一致する可能性もある。より安全なパターンは、信頼度が低いケース、判断が食い違うケース、影響の大きいケースを人に回し、評価者が高い確信度で分類したケースから定期的にサンプリングすることである。さらに、評価者とシステムおよびレビュアーとの相違を追跡し、そのプロンプトをバージョン管理して評価する必要がある。
この経験が実際に証明したこと
GitHubは、評価したオフラインデータセット上で誤警告を95%削減し、再現率を定められた安全上の制約内に維持できたと報告した。しかし同社は、この結果を、システムがあらゆる本番シナリオで同じように動作する証拠として提示してはいない。より重要な価値は、その結果に至る方法を理解できたことにあった。すなわち、実際のタスクにより近い評価、再現可能なベースライン、文書化された失敗パターンである。
certi.newsによる編集上の見解：ここでの実際の変化は、新しいモデルを投入することではなく、LLMシステムの評価を、明確な意思決定、安全上の限界、運用上の制約に結び付いた継続的なエンジニアリングプロセスへと変えることにある。これはソフトウェア、セキュリティ、開発者ツールのチームにとって重要である。なぜなら、1つの指標を改善することで、再現率の危険な低下やコストの増加が隠れてしまう可能性があるからだ。一方で、結果は評価セット、ラベルの品質、オフラインテストと本番挙動の間に残る、解消できない隔たりによって制限される。そのため評価は、管理された本番実験へ移行するための基盤であって、リリース後のリスク監視の代替ではない。