AI機能の精度評価を既存プロダクトで回す方法

「このAI機能、良さそうだけど本番に出していいんだっけ」——社内デモで拍手が起きたAI機能が、リリース判断の会議で急に歯切れが悪くなる場面をよく見ます。担当者に聞いても「触ってみた感じは悪くない」としか答えられず、結局リリースが延び続けるか、逆に評価しないまま出してクレームで気づく、のどちらかに転びがちです。

原因ははっきりしています。AI機能の品質を「人がざっと見た印象」でしか測っていないからです。この記事では、既存プロダクトにAI機能を組み込んだ後、精度を客観的な数値で評価し、継続的に改善を回す仕組みの作り方を整理します。

内部リンクとして 既存プロダクトの改善で外部チームが最初に見る観点 も参考にしてください。AI機能に限らず、既存プロダクトの改善はまず「今どういう状態か」を機械的に把握することから始まります。

「なんとなく良さそう」が起きる理由

AI機能、特にLLMを使った機能は、出力が毎回自然な日本語の文章や、それらしい分類結果として返ってきます。人間はもっともらしい出力を見ると「良い」と判断しがちですが、これはサンプル数1〜2件の主観評価に過ぎません。

典型的な失敗パターンは次の3つです。

• 代表性のないサンプルで判断する: 開発者が普段使うような綺麗な入力でしか試していない。本番の入力は表記ゆれ、長文、想定外のフォーマットが混じる
• 良い結果だけを見て悪い結果を数えていない: 10回試して7回良ければ「良さそう」と感じるが、精度70%が業務要件として十分かは別問題
• 評価基準が言語化されていない: 「良い」の定義が担当者の頭の中にしかなく、担当者が変わると評価がぶれる

この状態のまま本番投入すると、AI PoCが本番化しない理由と、失敗させない進め方で触れた「精度の壁」に必ずぶつかります。評価を仕組み化しないまま先に進めるのは、テストを書かずに本番デプロイするのと同じリスクです。

評価の4要素

AI機能の評価は、以下の4つを揃えることで初めて「客観的」と呼べます。

1. 評価データセット

本番で実際に起こりうる入力を集めた、正解つきのデータセットです。

• 最低30〜50件、できれば100件以上。少なすぎると精度の数値が数件の結果でぶれる
• 「典型的な入力」だけでなく、エッジケース（長文、空欄混じり、専門用語、他言語混入、意図的な誤入力）を意図的に含める
• 正解（正解ラベルや期待される出力）は、実務担当者がレビューして確定する。ここをAIに作らせると評価の意味がなくなる
• 既存プロダクトなら、過去の問い合わせログ・入力履歴・人手で処理した実績データが最良の材料になる。ゼロから作らず、まず既存データを掘る

データセットは一度作って終わりではなく、本番で見つかった失敗例を随時追加していく生きた資産として運用します。

2. 自動評価とLLM-as-judge

数値化できる指標は自動で測ります。

• 分類タスク（意図判定、カテゴリ分けなど）: 正解率・適合率・再現率・F1スコアを機械的に計算できる
• 抽出タスク（情報抽出、要約の事実整合性など）: 正解データとの一致率、あるいは必須項目が漏れていないかのルールベースチェック
• 自由文生成タスク（回答文、提案文など）: 単純な一致率では測れないため、LLM-as-judge（別のLLMに「この出力は正解の意図を満たしているか」を採点させる手法）を使う

LLM-as-judgeは便利ですが過信は禁物です。判定基準（ルーブリック）を具体的な項目に分解しておかないと、判定自体がブレます。「良い/悪い」の2値ではなく、「事実として正しいか」「業務ルールを満たしているか」「文体が適切か」のように採点軸を分けて評価すると精度が上がります。また、judgeに使うモデルと評価対象のモデルを揃えると評価が甘くなりやすいため、可能なら別系統のモデルで判定させます。

3. 人手評価

自動評価だけでは拾えない品質は、定期的に人間がサンプリングしてレビューします。

• 全件は不可能なので、無作為抽出+低スコア/境界値のサンプルを重点的に見る
• 実務担当者（サポート担当、営業担当など、実際に出力を使う人)がレビューするのが理想。開発者だけのレビューは業務文脈のズレを見逃す
• レビュー結果は評価データセットにフィードバックし、次回以降は自動評価でカバーできる範囲を広げていく

自動評価と人手評価は対立関係ではなく、人手評価で見つけた失敗パターンを自動評価のルールに落とし込んでいく、という一方向の流れで密度を上げていくのが実務的です。

4. オフライン評価とオンライン評価

• オフライン評価: 本番投入前に、評価データセットに対してバッチで精度を測る。リリースの可否判断に使う
• オンライン評価: 本番投入後、実際のユーザー入力に対する挙動をモニタリングする。ユーザーの明示的なフィードバック（いいね/よくないね、修正操作）や、AI機能を使った後の離脱率・再試行率などの行動指標を見る

オフラインで高精度が出ても、本番の入力分布がデータセットとズレていれば意味がありません。オンラインで継続的に精度を監視し、ズレが出たらデータセットを更新するというループを最初から設計しておく必要があります。この監視の仕組みは AIをプロダクトに組み込む時のガードレール設計 でも扱っている、本番運用の安全網の一部です。

何を指標にするか

指標選びを誤ると「数値は良いのに現場では使い物にならない」状態に陥ります。タスクの性質で指標を変えます。

タスクの種類	主要指標	補助指標
分類・判定	正解率、F1スコア	誤判定時の業務影響度別内訳
情報抽出	項目別の抽出精度	抽出漏れ率(false negative)
文章生成・要約	LLM-as-judgeスコア(事実整合性・業務適合性)	文字数・トーンの逸脱率
検索・レコメンド	適合率@k、正解が含まれる率	クリック率・採用率(オンライン)

特に業務システムでは、「誤判定した場合の被害の大きさ」で重み付けした指標を作ることを勧めます。単純な正解率90%より、「重大な誤りが0.5%以下」の方が業務上意味を持つケースが多くあります。例えば与信判定や請求関連の機能では、精度全体よりも「誤って過大な金額を提示するケースがゼロか」の方が重要です。

継続的に評価を回す仕組み

評価は一度やって終わりではなく、開発サイクルに組み込みます。

• プロンプトやモデルを変更するたびに評価データセットで自動実行する。CIにAI機能の評価ジョブを組み込み、精度が閾値を下回ったらマージをブロックする、という運用が理想形
• 本番の失敗ログを週次・月次で棚卸しし、評価データセットに追加する。運用が長くなるほどデータセットの網羅性が上がり、評価の信頼度が上がっていく
• 評価結果をダッシュボード化し、非エンジニアの意思決定者(PdM等)も精度の推移を見られるようにする。「なんとなく良い」から「先月比でF1が3ポイント改善した」に会話のレベルを上げる

この仕組みがないと、モデルやプロンプトを変更するたびに「前より良くなったか」を人の感覚で判断することになり、改善のたびにリグレッション(過去直した不具合の再発)が起きます。

PoCから本番化への判断ゲート

評価の仕組みが整ったら、本番化の可否は次のような判断ゲートで機械的に決めます。

1. 評価データセットでの精度が業務要件の閾値を超えているか(例: 重大誤りが0.5%以下)
2. エッジケース(異常入力・境界値)での挙動が許容範囲か。平均精度が高くてもエッジケースで暴走するAI機能は本番投入すべきではない
3. 精度が閾値を下回った場合のフォールバック(人手確認への切り替え、確信度が低い場合は保留にする等)が用意されているか
4. オンライン監視の仕組み(ログ収集・アラート)が本番投入前に稼働しているか

この4つが揃っていない状態での本番投入は、「PoCの延長を本番でやっている」状態です。評価の仕組みそのものが完成してから初めて、本番化の判断ができます。

外注する場合の進め方

社内にAI評価のノウハウがない場合、外部に依頼する際は次を最初のスコープに含めることを勧めます。

• 評価データセットの設計・初期構築(既存の業務データからの抽出含む)
• 自動評価パイプラインの構築(CI組み込み、LLM-as-judgeのルーブリック設計)
• 本番投入の判断ゲート(閾値・フォールバック設計)の定義

「AI機能を作る」ことだけを依頼すると、評価の仕組みが後回しになりがちです。最初から評価をセットで発注することで、リリース後に「精度が悪い」と気づいて作り直す手戻りを避けられます。

まとめ

• AI機能の品質を「なんとなく良さそう」で判断せず、評価データセット・自動評価/LLM-as-judge・人手評価・オンライン監視を組み合わせて客観的な数値で測る
• 指標はタスクの性質と業務上の被害の大きさで選び、評価はプロンプトやモデルの変更のたびに継続的に回す仕組みにする
• 本番化は精度・エッジケース・フォールバック・監視の4条件が揃った判断ゲートで機械的に決める。感覚での判断はしない

torcheeesでは、既存プロダクトへのAI機能の後付けと、その評価パイプラインの構築を合わせて支援しています。「AIは入れたが精度が測れていない」「本番化の判断基準がない」という段階からのご相談も歓迎します。まずは既存プロダクト診断、またはAI連携サービス・活用している技術要素をご覧の上、お問い合わせください。