社内規程を答える問い合わせAIを作ってもらいました。デモでは、聞いた質問すべてに正しく答えていました。導入から2ヶ月、総務部から「たまに間違ったことを言うので、結局規程を開いて確認している」という声が上がります。
開発会社に伝えると、2週間後に修正版が届きます。ここで詰まります。「直りました」と言われても、直ったかどうかを確認する方法が社内にないのです。 前と同じ質問をいくつか試して、たまたま正しく答えたら「直ったのでしょう」と結論するしかありません。
これは開発会社の怠慢ではなく、発注の時点で「何をもって正しいとするか」を決めていないことの帰結です。
デモで完璧だったものが、運用で外れる
生成AIを組み込んだ機能には、従来のシステムと違う性質があります。同じ入力に必ず同じ出力が返るとは限らず、「動いている／動いていない」の二択で判定できません。
GitHub が公開している、実運用向けの評価に関する解説では、この落差の理由が整理されています。きれいなベンチマークで良い成績を出したモデルが、本番で重要なケースを取りこぼすのは珍しいことではありません。挙げられている要因は、そのまま社内システムにも当てはまります。
- 実際の入力は曖昧で、書き方も揺れている
- 何が正解かの判断自体が、人によって割れることがある
- 必要な文脈が欠けていたり、途中で切れていたりする
- 評価に使ったデータが、本番で来る質問の分布を反映していない
- ベンチマークにはめったに出ないケースが、本番では主要な失敗の原因になる
デモは、作った人が「答えられると分かっている質問」で行われます。本番の質問はそこから外れたところに来ます。 この差を埋める作業が評価であり、それは開発の最後にやるおまけではなく、発注時に設計するものです。
正解を知っているのは発注側だけ
ここが実務上いちばん重要な点です。「この質問への正しい答えは何か」を判定できるのは、業務を知っている発注側です。開発会社は規程の運用実態を知りません。
だから評価用のデータセットは、発注側が用意します。難しい作業ではありません。
- 過去に実際に来た質問を集める — 総務や情シスの受信箱、チャットの履歴から50〜100件。作文しないでください。実際の文面には言い間違いや省略が含まれており、それが本番の入力です
- 正しい答えを業務担当が書く — 短くて構いません。「就業規則第12条により、申請は前日まで」程度の粒度で足ります
- 答えられなくていい質問も混ぜる — 「この経費は落ちますか」のような判断を伴うものは、AIが答えるべきではありません。「分かりません、担当へ確認してください」と返すのが正解というケースを、正解として登録します
3つ目を入れておかないと、何かしら答えを作ってしまう挙動を検出できません。実務で困るのは、答えられないときに黙る機能ではなく、もっともらしい嘘を返す機能のほうです。
「正答率90%」と契約に書く前に
数値目標は分かりやすく、契約にも書きやすい。ただし数値を受け入れ条件にすると、その数値を上げる作業が発生します。 これはAIで速く書かれたコードの検収で挙げた、スコアを条件に書いたときの構図と同じです。
評価セットが100件で、合格ラインが90%だとします。開発側は残り10件を通すために調整します。その調整が汎用的な改善なら良いのですが、その10件だけに効く対処になっていても、数値上は区別が付きません。
実務的には、次のように分けるほうが機能します。
| 決めること | 書き方の例 |
|---|---|
| 評価セット | 発注側が提供する100件。うち20件は「答えるべきでない」質問 |
| 合格の条件 | 全体の正答率に加え、「答えるべきでない20件で誤答0件」 |
| 評価の実施 | 納品時と、修正のたびに同じセットで再実行し、結果を提出 |
| セットの更新 | 運用中に見つかった誤答は評価セットに追加する |
効くのは2行目と3行目です。 平均点だけを条件にすると、危険な誤答が数点の減点として埋もれます。「間違った回答を返してはいけない質問」を別枠で0件にしておくと、そこが埋もれません。
そして3行目があると、冒頭の「直ったかを確認できない」が解消します。同じセットを毎回流すので、修正で別の場所が壊れていないかも同時に分かります。
運用が始まってからが本番
評価セットは、納品時点のものが完成形ではありません。運用の中で出てきた誤答を追加していくことで、実際の使われ方に近づいていきます。
現場から「間違っていた」という報告が来たら、その質問と、そのときの回答と、正しい答えを記録してください。記録がないと、報告は「たまに間違う」という感想のまま蓄積されず、修正の依頼も感想のまま伝わります。 3件でも記録があれば、開発会社は再現できます。
このとき、AIに任せる範囲そのものを見直す判断もあります。判断を伴う問い合わせや、金額に関わる回答は、そもそも生成AIに答えさせずに担当へ渡す設計のほうが安定します。 どこまでを機械的な処理に寄せるかの考え方は業務AIは生成AIだけで組まないにまとめています。
次にやること
まず、過去の問い合わせを30件でいいので集めてください。 開発が始まっていてもいなくても、これは今日できます。集めた時点で、AIに向く質問と向かない質問が肉眼で分かれてきます。
そのうえで、すでに稼働しているAI機能があるなら、「間違ったと報告された事例」を記録する場所を作ってください。 スプレッドシート1枚で足ります。次の修正依頼のときに、この記録があるかどうかで会話がまったく変わります。
AI機能の要件定義、評価設計、既存システムへの組み込みについては、グリームハブの開発・AI・自動化のご相談で承っています。業務の性質と求める精度によって設計が変わるため、個別にご相談ください。お問い合わせからどうぞ。
