AI を組み込んだ業務システムの開発で、最も多くのプロジェクトが足を取られるのは「精度をどう測るか」です。プロンプトを書き換えた、モデルを新しいものに差し替えた、検索の仕組みを調整した。そのたびに担当者が数件試して「前より良くなった気がします」と報告する。これを繰り返しているうちに、いつの間にか以前は正しく answered できていた質問が壊れている——こうした事態は珍しくありません。
この記事では、AI 機能の評価データ（テストケースの集合）をどう作り、どう運用するかを、中小企業の現場で実行できる粒度でまとめます。大がかりな MLOps 基盤の話ではなく、Excel 1 枚から始められる進め方を中心に扱います。
なぜ「数字で言える状態」が必要なのか
従来の業務システムであれば、仕様に対して動くか動かないかは明確でした。請求書の合計金額が合っているかどうかに「だいたい合っている」はありません。ところが AI 機能、特に大規模言語モデル（LLM: 大量の文章を学習し、自然言語で入出力を行うモデル）を使った機能は、出力が確率的に揺れます。同じ入力でも毎回まったく同じ文字列が返るとは限りません。
この性質が実務にもたらす困りごとは、主に次の 3 つです。
- 改善したつもりが悪化している（リグレッション）：ある質問への回答を良くするためにプロンプトを足したら、別の質問の回答が崩れる。目視では気づけません。
- 検収の基準が決まらない：発注側も受注側も「どこまでできたら完成か」を言語化できず、納品が長期化する。
- モデル更新に追随できない：提供元がモデルを更新したり、旧バージョンの提供を終了したりしたとき、乗り換えて良いか判断する材料がない。
評価データセットは、この 3 つをまとめて解決するための土台です。「正解はこれ」と決めた問題集を持っていれば、変更のたびに同じ問題を解かせて点数を比べられます。
評価データセットは何から作るか
ゼロから想像で作ろうとすると必ず手が止まります。実務では次の順序が現実的です。
1. 実際の問い合わせ・実際の書類から集める
社内 FAQ ボットを作るなら、過去のメール問い合わせやヘルプデスクの記録。請求書の読み取りなら、実際に受領した請求書。業務の現場に既にあるものが最良の素材です。ここで架空の綺麗な入力ばかり集めると、本番で崩れます。
2. 「難しい例」を意図的に混ぜる
評価データが簡単な例ばかりだと、点数が高く出るだけで役に立ちません。意図的に入れるべきものとして、次のような観点があります。
| 観点 | 内容 | 例（文書検索 AI の場合） |
|---|---|---|
| 典型例 | 最も頻度が高い普通の入力 | 「有給休暇は何日もらえますか」 |
| 境界例 | 判断が分かれるきわどい入力 | 「入社半年の契約社員の有給は」 |
| 答えられない例 | 資料に情報が無い質問 | 「来年の賞与はいくらですか」 |
| 表記ゆれ | 同じ意味で書き方が違う入力 | 「年次有給」「有休」「ゆうきゅう」 |
| 範囲外 | この機能が扱うべきでない入力 | 雑談、競合他社の話題 |
特に重要なのが「答えられない例」です。資料に書かれていないことを AI がもっともらしく作文してしまう現象（ハルシネーション）は、業務利用で最も怖い失敗です。「分かりません、担当者にお問い合わせください」と返すのが正解であるケースを、評価データに必ず含めてください。
3. 件数は 30 件から始める
いきなり 500 件を目指すと着手できません。まず 30〜50 件。これだけでも、プロンプト変更で何件が壊れたかは見えます。運用を始めたら、ユーザーから苦情が来た入力をそのまま評価データに追加していく。この「失敗を資産化する」サイクルが回り出せば、データセットは自然に育ちます。
何を正解とするか — 評価軸の決め方
評価データには入力と「期待する結果」をセットで書きます。ここで「期待する結果」を完全一致の文字列にしようとすると破綻します。AI の出力は言い回しが毎回変わるためです。実務では、機能の性質に応じて次のように採点方法を使い分けます。
| 機能の型 | 採点のしかた | 採点コスト |
|---|---|---|
| 分類（問い合わせの振り分けなど） | ラベルが一致するかの完全一致 | 低（自動化しやすい） |
| 抽出（請求書から金額・日付を取る） | 項目ごとに正解値と一致するか | 低 |
| 検索・参照（社内文書 QA） | 参照すべき文書が引けているか、記載に反する内容が含まれていないか | 中 |
| 生成（文章要約、メール下書き） | 必須要素が含まれるか、禁止事項が無いかをチェックリストで判定 | 高 |
分類と抽出は、正解値を決めてしまえば自動採点が可能です。ここは迷わず自動化してください。
問題は生成系です。要約文の良し悪しを完全一致で測ることはできません。現実的な方法は、正解文を書くのではなく「満たすべき条件」をリスト化することです。たとえば問い合わせ返信の下書き機能なら、次のような場面です。
- 宛名が入力の会社名と一致している（必須）
- 納期の日付が入力どおりである（必須）
- 金額を推測して書いていない（禁止）
- 敬体で統一されている（望ましい）
この形にしておくと、人が採点するときも判断がぶれませんし、後述する自動採点にも移行しやすくなります。
採点を AI にやらせる「LLM-as-a-Judge」とその限界
生成系の採点を人手で毎回やるのは、回数を重ねるほど現実的でなくなります。そこで、別の LLM に採点させる手法が広く使われています。英語圏では LLM-as-a-Judge（LLM を審査員として使う）と呼ばれます。採点基準と出力を渡し、「この条件を満たしているか、満たしていれば 1、満たしていなければ 0 で答えよ」と指示する形です。
これは有効ですが、導入する際は次の点を押さえておく必要があります。
- 最初に人間の採点と突き合わせる：20 件程度を人間と AI の両方で採点し、判定が一致するか確認します。ここがずれたまま運用すると、信用できない数字を見続けることになります。
- 基準は細かく分ける：「良い回答か」のような大雑把な問いではブレます。「金額が正しいか」「出典が示されているか」と一問一答に分解するほど安定します。
- 判定役のモデルは固定する：採点側のモデルを変えると点数が動き、何が原因で改善したのか分からなくなります。
なお、評価結果が揺れることを前提に、同じ評価を複数回走らせて平均を見る運用も有効です。1 回の実行で 2 点上がった下がったを議論しても、多くの場合は誤差の範囲です。
評価データを扱ううえでの注意点
評価データは実際の業務データを含みます。ここで法令と社内規程の確認が必要になります。
顧客の氏名や連絡先が含まれる場合、個人情報の保護に関する法律（個人情報保護法）の対象となります。利用目的の範囲内での取り扱いか、外部の AI サービスに送信することが第三者提供や委託にあたらないか、社内の体制で確認してください。評価データは開発者が繰り返し閲覧・共有するものなので、本番運用のデータ以上に扱いが緩くなりがちです。氏名を「A 社 山田」のようなダミーに置き換えたマスキング版を評価用に作っておくのが安全です。
また、AI の開発・利用に関する国内の指針としては、総務省および経済産業省によるAI 事業者ガイドラインが公表されています。開発者・提供者・利用者それぞれの立場で留意すべき事項が整理されているため、社内の AI 利用方針を作る際の参照先になります。最新版の内容は各省庁の公開資料で確認してください。
加えて、取引先から預かった資料を評価データに含める場合は、秘密保持契約（NDA）の範囲を超えないかの確認が要ります。開発ベンダーに評価データを渡す場面では、ここが見落とされやすい箇所です。
小さく始める運用の形
最後に、実際にどう回すかの型を示します。特別なツールが無くても始められます。
- 表計算ソフトで 1 シート作る：列は「ID / 入力 / 期待する結果または条件 / カテゴリ（典型・境界・答えられない等） / 追加した日 / 追加理由」。
- 変更前に必ず全件走らせて点数を記録する：この「変更前の点数」が無いと比較できません。
- 変更後に全件走らせ、落ちたケースを個別に見る：総合点だけ見ていると、重要な 1 件が壊れたことを見逃します。カテゴリ別の点数も出してください。
- 苦情・失敗はその日のうちに追加する：後でまとめてやろうとすると、まず実行されません。
- 四半期に一度、データセット自体を見直す：業務ルールが変われば正解も変わります。古い正解を基準に最適化し続けるのは逆効果です。
開発を外部に委託する場合は、この評価データセットを発注側が持つことを強くおすすめします。仕様書よりも評価データのほうが、求める品質を正確に伝えます。検収条件も「評価データの正答率が X% 以上、かつ『答えられない例』での誤答がゼロ」のように、合意可能な形で書けるようになります。
まとめ
AI 機能の品質は、感想ではなく測定で管理するものです。要点を整理します。
- 評価データは実際の問い合わせ・実際の書類から集め、典型例だけでなく境界例と「答えられない例」を必ず含める
- 30〜50 件から始め、運用中に出た失敗を追加していけば十分に育つ
- 分類・抽出は自動採点、生成は「満たすべき条件のリスト」で採点する
- LLM による自動採点は有効だが、導入時に人間の判定と一致するか検証する
- 実データを使う以上、個人情報保護法および NDA の範囲を確認し、マスキング版を用意する
- 評価データセットは発注側の資産。検収条件と仕様の代わりになる
「良くなった気がする」で止まっているうちは、AI 機能は本番業務に載せられません。逆に言えば、評価データさえ持っていれば、モデルが新しくなっても、担当者が代わっても、品質を落とさずに改善を続けられます。まずは今扱っている業務の問い合わせ記録を 30 件、表計算ソフトに貼り付けるところから始めてみてください。