AI活用を試験的に始めた担当者から、こんな相談をよく受けます。「チャットボットやAIアシスタントを入れてみたが、回答が合っているかどうかを毎回人が確認しないと不安で、結局チェックに時間がかかっている」という声です。AIの回答精度を測る前に、そもそも何を基準に評価するかが決まっていないケースが多くあります。
評価の土台を作るには、現場の業務から具体的な「評価用の業務例」を用意する必要があります。ここでは、その選び方と判断基準を整理します。
評価用の業務例はどう選ぶか
評価の対象にする業務例は、実際の問い合わせやタスクの中から、難易度と頻度の異なるものをバランスよく選ぶことが大切です。たとえば、想定例として次のような分け方が考えられます。
- 頻度が高く、答えが一つに決まる定型的な質問（規定の確認など）
- 頻度は低いが、複数の条件を組み合わせて判断が必要な質問
- 担当者によって回答の幅が出やすい、曖昧な表現を含む質問
この3種類を数件ずつ集めるだけでも、AIが得意な範囲と苦手な範囲がある程度見えてきます。評価担当者には、次のような質問を投げかけて業務例を集めてもらうとよいでしょう。
「最近、AIに聞かれて困った質問や、回答に自信が持てなかった場面はありますか」
評価の基準をどう決めるか
業務例を集めたら、何をもって「正しい回答」とするかを先に決めておきます。基準があいまいなまま評価を始めると、評価者ごとに判断がぶれてしまうためです。
基準の例として、以下のような観点を組み合わせることが考えられます。
- 事実として誤りがないか（ハルシネーションと呼ばれる、事実と異なる内容の生成がないか）
- 業務上必要な情報が欠けていないか
- 回答のトーンや表現が社内ルールに沿っているか
- 個人情報や機密情報を含んでいないか
これらは完璧である必要はなく、合格ラインを「及第点」として最初は緩めに設定し、運用しながら基準を引き上げていく方法も現実的です。
既存サービスで足りる場合と独自開発が必要な場合
評価の仕組みを作る際、既存のAIサービスに備わっているログ機能や評価用のテンプレートで足りる場合（A）と、自社専用の評価フローを開発したほうがよい場合（B）があります。
Aを選ぶ条件は、評価対象の業務例が数十件程度に収まり、担当者が手作業でも確認できる規模であること、また利用しているAIサービスにすでに回答履歴の確認機能が備わっていることです。この場合は、既存の管理画面やスプレッドシートでの記録・確認で十分対応できます。
Bを選ぶ条件は、評価対象の業務例が数百件以上に及び、複数の部署やシステムから回答の元になる情報を集める必要がある場合です。また、評価結果を定期的に集計し、精度の推移を継続的に追う必要がある場合も、専用の仕組みを用意したほうが手戻りが少なくなります。
人の確認をどこに残すか
AIの回答をそのまま現場に展開する前に、人が確認する工程をどこに置くかも決めておく必要があります。想定例として、回答の自動生成後に担当者が目視で確認してから顧客に送る、という二段階の運用にする方法があります。
この確認工程は、AIの精度が安定してくるまでの暫定措置として位置づけ、確認漏れの件数や修正が必要だった割合を記録しておくと、どの時点で確認の頻度を減らしてよいかの判断材料になります。日数や件数の目安はあくまで仮定であり、業務内容によって大きく変わる点には注意が必要です。
評価用業務例づくりのチェックリスト
- 定型・条件付き・曖昧な質問の3種類を数件ずつ集めたか
- 評価の合格基準（事実の正確さ、情報の過不足、表現のルール）を言語化したか
- 評価対象の件数規模を把握し、A（既存機能活用）かB（独自開発）かを検討したか
- 人が確認する工程をどこに置くか決めたか
- 確認結果や修正件数を記録する方法を用意したか
- 評価基準を定期的に見直すタイミングを決めたか
- 個人情報や機密情報の混入チェックを評価項目に含めたか
評価の仕組みは一度作って終わりではなく、現場の声を反映しながら育てていくものです。自社の業務に合わせた評価用の業務例づくりや、評価フローの設計についてお悩みの際は、お気軽にご相談ください。