この記事の要点
- 会社でAIを使う時も、最初に決めるのはモデル名ではなく失敗の線引きです。
- GitHubの例では、誤検知削減と見逃し防止を同時に扱いました。
- 本番前の評価は、AIを信じる儀式ではなく不確実さを測る作業です。
AI導入は失敗の線引きで決まる
GitHubは2026年8月25日、LLM（大規模言語モデル）を本番前に評価する公式ブログ記事を公開しました。舞台はsecret scanning（コード内の認証情報漏れを探す機能）です。
仕事に入るAIは、失敗の線引きで選ばれます。GitHubの記事は、AIの賢さより先に決めるものを示しています。
社内でAIを使う時も同じです。速い回答や自然な文章だけでは、本番で任せられる範囲は決まりません。
何を間違えると困るのか。どの失敗なら人が後で直せるのか。そこが先にあります。
社内チャットボットにも同じ弱さがある
会社のAI活用は、GitHubの安全機能から遠く見えます。けれど、失敗の形はかなり似ています。
・総務の社内規程回答
・営業の顧客メール分類
・経理の請求書チェック
・広報の原稿チェック
どれも、AIがもっともらしく答えるだけでは足りません。間違いの重さが、仕事ごとに違うからです。
secret scanningが教える現場の重さ
secret scanningは、API keyやpassword、tokenのような認証情報を探します。GitHub Docsでは、全ブランチのGit履歴もスキャン対象だと説明されています。
さらに、issueやpull request、GitHub Discussions、wiki、secret gistも対象に含まれます。コードだけでなく、周辺の会話や記録にも漏れが起きるからです。
GitHubのLLM評価は、候補文字列が本物の秘密情報かを単に当てる話ではありません。誤検知を減らしながら、見逃しを安全な範囲に抑える話です。
ここが、AI導入の現実に近い部分です。便利にするほど、落としてはいけない失敗がはっきりします。
価格より先に分かること
この公式ブログは、新しい有料機能の販売ページではありません。LLM評価手法の料金や提供開始日は、発表に書かれていません。
| 項目 | 公式情報に書かれた内容 |
|---|---|
| LLM評価記事の公開日 | 2026年8月25日 |
| LLM評価手法の提供時期 | 発表に書かれていない |
| LLM評価手法の料金 | 発表に書かれていない |
| 公開リポジトリのsecret scanning | 自動で無料実行 |
| 組織所有の非公開・内部リポジトリ | GitHub Secret Protectionを有効にしたGitHub TeamまたはGitHub Enterprise Cloudで利用 |
つまり、今回読める価値は価格表ではありません。AIを仕事へ入れる時の考え方です。
数字はひとつでは足りない
GitHubは、precision（当たりの多さ）とrecall（本物を見逃さない度合い）を同じ重さで並べませんでした。目的と安全境界を分けました。
secret scanningでは、false positive（誤検知）を減らすことが主な利益です。一方で、本物の認証情報を見逃す失敗は安全上の痛みになります。
GitHubは、評価済みのオフラインデータセットで誤検知を95%削減したと説明しています。recallは定義済みの境界内に保ちました。
この読み方は、AI導入全般に使えます。ひとつのスコアで勝ったAIより、自分の仕事で許せない失敗を抑えるAIが強いのです。
データはきれいにしすぎない
GitHubは、オフライン評価（本番前に手元データで試す評価）を本番に近づけるべきだと説明しています。候補だけをきれいに抜き出すと、現場の難しさが消えます。
現場の入力には、曖昧な文、足りない文脈、余計な情報が混じります。GitHubの記事では、AIが別の変数名に気を取られる例も出ています。
また、production labels（本番データ上の処理結果ラベル）も絶対の正解ではありません。アラートを閉じた理由は、実際には複数ありえます。
AIの評価は、答え合わせの表を作るだけでは足りません。正解に見える印が、本当に正解を表すかも考える作業です。