AIチャットボットを業務で使うには：資料・回答範囲・評価・引き継ぎの設計

業務用チャットボットは、自然な回答ができるだけでは運用できません。どの資料を根拠にし、どこまで答え、判断できないときにどう引き継ぐかを決める必要があります。本記事は特定のサービスを実装・検証した記録ではなく、導入前の設計ガイドです。

最初に回答する範囲を決める

答えが作れるかだけでなく、次へつなぐ条件を設計します。

• 資料に根拠がある根拠に沿って回答し、参照先を示す。
• 必要な条件が足りない足りない条件を質問する。
• 資料が矛盾する・対象外断定せず、確認できる担当窓口へつなぐ。
• 予約変更など操作を伴う認証・権限・実際の処理結果を別途確認する。

「変更しました」という文章だけで、システムの変更完了にはなりません。回答と実行を分けて検証します。

「何でも答える窓口」では、評価と保守が難しくなります。まず「公開済みの商品仕様と配送案内に答える」のように対象を限定します。注文変更、返金の判断、個別契約の相談など、別の対応が必要な問い合わせも定めます。

対象外の質問には、推測した回答を作らせず、案内先を返す設計にします。「分かりません」で終わらず、問い合わせ方法や必要な情報を示すと利用者が次へ進めます。

資料を整えてから検索させる

FAQの件数を増やすだけでは、品質は保証できません。同じ内容の旧版と新版が混在していないか、例外条件が抜けていないか、更新担当が決まっているかを確認します。

検索した資料を回答へ使う構成では、参照元を残します。OpenAI APIのFile searchも、アップロードしたファイルから情報を検索するための機能です。ただし、検索が利用できることと、回答が常に正しいことは別です。File searchの公式資料

正常な質問以外でも試す

評価用の質問には、よくある問い合わせだけでなく、曖昧な質問、情報不足、対象外、古い仕様への質問を含めます。次は編集上の評価例です。

モデルや資料を変えたときも、同じ質問で確認します。評価を定義して繰り返す考え方は公式の評価ガイドでも説明されています。

回答と実際の操作を分ける

「予約を変更しました」という文章を生成しただけでは、予約システムの更新は完了しません。操作を伴う場合は、認証、権限、対象の確認、APIの結果、失敗時の対応を実装する必要があります。

初期導入では、説明や下書きまでに範囲を絞り、動作を確認してから更新操作を加える方法が考えられます。外部へ情報を送る連携では、接続先の保存や共有の条件も確認します。

運用開始後に見るもの

回答できなかった質問、誤答、担当者への引き継ぎ、修正時間を記録します。解決率だけを追うと、誤った回答で会話が終わったケースを成功に数えてしまうため、品質と合わせて判断します。

資料の更新日と再評価日を管理し、古い回答が残ったら、資料・検索・指示・モデルのどこが原因かを切り分けます。導入全体の判断は効果を測る方法、データの扱いはプライバシーの整理、候補選びはモデル比較の方法につなげてください。