「デモでは完璧に動いていたのに、本番環境に投入した途端に想定外のエラーや誤答が多発して使えない」。LLM（大規模言語モデル）を活用した業務アプリ開発において、これは驚くほど頻繁に起きるトラブルです。
原因の多くは、モデル自体の性能不足ではありません。「デモを通すための確認」と「本番運用に耐えうる評価」が全く別物であることに気づかないまま、開発を進めてしまうことにあります。
この記事では、企業のAI導入現場（FDE）で実践している、LLMアプリの「デモ死」を防ぐ評価データセットの3分類と、実害を防ぐ2軸評価の設計手法を解説します。
この記事の結論（先に3点）
- デモの成功は「錯覚」と心得る: デモは開発者が無意識に選んだ都合の良い数件のサンプルに過ぎず、本番の多様な入力空間を全く網羅していない。
- 評価データセットを3分類で構築する: 「典型ケース」「境界ケース（極端な入力）」「意図的誤用（攻撃・悪用）」の3群を用意し、正解基準を人手で固める。
- 「正しさ」と「被害の大きさ」の2軸で測る: 単なる○×判定ではなく、「タスク達成度」と「誤答時の実害リスク」のマトリクスで足切り基準を設ける。
適合する読者と限定事項
- この記事が役に立つ人:
- 社内向け・顧客向けにLLMアプリケーションを開発しているエンジニアやPM
- PoC（概念実証）のデモは成功したものの、本番リリースの判定基準が定まらず立ち往生しているチーム
- プロンプト改修やモデル乗り換え時に、既存の挙動が壊れていないか機械的に検知したい人
- 限定事項:
- LLM自体の学術的なベンチマーク評価（MMLU等）ではなく、企業の実業務に組み込む業務アプリの品質管理設計を対象としています。
なぜデモは「完璧に通ってしまう」のか
開発段階のデモでLLMがうまく動くのは当然です。作り手は無意識のうちに、モデルが得意とする「素直で典型的な入力パターン」を選んでテストしているからです。
しかし、本番環境のユーザーは開発者の想定通りには入力してくれません。
- 致命的な表記ゆれ、業界特有の略語、誤字脱字
- 極端に短すぎる指示、または数千文字に及ぶ長文の貼り付け
- 複数の質問や条件が複雑に絡み合った入力
- 仕様外の依頼や、プロンプトインジェクションのような意図的な悪用
デモ環境での評価は、広大な入力空間のごく一部を1回サンプリングしたスナップショットに過ぎません。この「動いて見えた」状態を「本番でも動く」と過信してリリースすると、現場投入の初日にクレームの山となって跳ね返ってきます。
対策1：評価データセットを3つの類型で作る
本番に耐えうるLLMアプリを作る第一歩は、コードを書く前に**「評価データセット」を体系的に準備すること**です。
私は評価サンプルを次の3種類に分類して収集・作成しています。
| 分類 | サンプルの性質 | 具体例 | 評価の目的 |
|---|---|---|---|
| ① 典型ケース（約60%） | 全体の大部分を占める、素直で標準的な入力 | 規定フォーマット通りの問い合わせ、簡潔な要約依頼 | 基本的なタスク遂行能力と出力精度の担保 |
| ② 境界ケース（約30%） | 表記ゆれ、極端な長さ、複数意図の混在 | 誤字だらけの長文、前提条件が不足した質問 | 想定外の入力に対するロバスト性（頑健性）の確認 |
| ③ 意図的誤用（約10%） | システムの制限を突破しようとする入力 | 「前の指示を無視して」、対象外業務の質問 | プロンプト漏洩防止、安全なガードレール・拒否応答の確認 |
正解（グラウンドトゥルース）を人手で定義する
集めたサンプルに対しては、「期待される正解出力」、あるいは「満たすべき要件（含めるべきキーワード、出力形式、トーン）」を人間が定義しておきます。
この基準がないまま「目視でなんとなく良さそうか確認する」運用を続けると、評価者の主観やその日の体調によって合否がブレてしまいます。
対策2：評価指標を「正誤」の2値にせず、2軸マトリクスで判定する
従来のソフトウェアテストと異なり、LLMの出力は完全な100点か0点かで割り切れないケースが多々あります。
そのため、評価を単なる「正解／不正解」の2値で見るのではなく、「機能的な正しさ」と「失敗時の被害規模」の2軸で評価します。
【LLM出力の2軸評価マトリクス】
高 ↑ ［要修正］ ［合格］
被 │ 機能不足だが実害小 タスク達成・実害なし
害 │（例: 敬語のニュアンス違い） （例: 正確な回答出力）
規 │
模 │ ［即座に公開停止・足切り］ ［要注意］
│ 致命的な誤答・ハルシネーション 形式は正解だが一部情報漏れ
低 ┼─────────────────────────────────────────→
低 機能的正しさ（タスク達成度） 高なぜ「被害規模」を分けるのか
同じ「不正解」であっても、その業務インパクトは天と地ほど異なります。
- 被害が小さい不正解: 「少し言い回しが硬い」「要約の箇条書きが4行ではなく3行になった」など。業務進行上の実害はほぼありません。
- 被害が壊滅的な不正解: 「存在しない社内規定を自信満々に捏造する（ハルシネーション）」「機密情報を一般ユーザーに漏洩する」など。企業の信用失墜や法的リスクに直結します。
この2軸を導入することで、「多少の表現のブレは許容しつつ、致命的な嘘や情報漏洩は1件でも発生したら即座に不合格とする」というメリハリの効いた品質ゲート（足切り基準）を設定できます。
対策3：プロンプト変更のたびにCIで再評価を回す
評価データセットと2軸評価基準を作ったら、それを開発サイクルの中に自動テスト（CI）として組み込みます。
LLMアプリで最も怖いのは、「あるプロンプトを直して特定のケースの精度を上げたら、別のケースでこれまで動いていた出力が壊れた（リグレッション）」という現象です。
- 評価データセットをJSON等の形式でGit管理する
- プロンプトやシステムプロンプトを変更するたびに、全テストケースに対してスクリプトを実行する
- 判定用LLM（LLM-as-a-judge）やルールベース検査でスコアを算出し、足切り基準を下回ったらPRのマージをブロックする
この仕組みがあることで、チーム開発でも安心してプロンプトのチューニングやモデルのアップグレードを進められるようになります。
まとめ：ソフトウェアテストの当たり前をLLMに適用する
「デモでは動くが本番で使えない」という問題の本質は、AIの限界ではなく、ソフトウェア工学としてのテスト・品質管理の欠落です。
- デモの成功を過信せず、本番の過酷な入力を想定する
- 「典型・境界・誤用」の3分類で評価データセットを揃える
- 「機能的正しさ」×「被害の大きさ」の2軸で合否を判定する
- プロンプト変更のたびに継続的にテストを実行する
これらの当たり前の仕組みを泥臭く整えることこそが、PoC止まりの壁を突破し、本番で本当に使われるAIシステムを作る唯一の道です。具体的なCI連携やLLMによる自動評価の実装方法については、以下の関連記事も参考にしてください。
