AI・ボット品質の基礎｜第10回
AIボットの品質は、公開前に一度試せば終わりではありません。問い合わせ内容や業務資料が変わるたびに、確認すべき条件も変化します。Botiumを活用した試験を続けるために、データ・指標・役割分担をどう育てるかを説明します。
1. 不具合を再現できる試験へ変える
運用で見つかった問題は、「変な回答だった」という感想だけで終わらせず、入力、前提条件、期待結果へ整理します。必要な情報を加工してテストケースにすることで、同じ問題が再発していないかを確認できます。
会話ログをそのまま大量に保存する前に、必要な項目と保管期間を決めます。個人情報や業務上の秘密を取り除いても再現できるよう、架空の値への置き換えや試験用データの用意を行います。
発見した不具合を次回の試験へ残す際は、再現できるボットのテストケース設計に沿って条件を整理します。
2. 固定した試験と新しい試験を分ける
毎回比較する基本セットは、重要な用件と過去の重大不具合を中心にします。別に、新しい言い方や新商品の問い合わせなどを扱う追加セットを用意します。
基本セットを毎回大きく入れ替えると、合格率が変わった理由が分からなくなります。共通のケースでの前回比較と、新規ケースの結果を分けて報告します。正解の根拠資料とテストケースには版を付けて管理します。
共通するケースで変更の影響を見るには、AIチャットボットの変更後の回帰試験も参考になります。
| 管理するもの | 残す情報 | 主な用途 |
|---|---|---|
| 試験ケース | 前提・入力・期待結果・版 | 再現と比較 |
| 実行結果 | 対象版・日時・成否・理由 | 変化の検出 |
| 重大不具合 | 影響・担当・対応期限 | 優先順位の判断 |
| 評価基準 | 承認者・根拠資料 | 判定のずれを防止 |
| 未確認範囲 | 未実施の理由・次の確認 | 過大な品質判断を防止 |
3. 指標の分母と条件を明らかにする
目的達成率を見るなら、何を達成とし、どの会話を分母にしたかを定義します。途中で接続エラーになった試験を除外したなら、その件数も報告します。実行できなかったケースを黙って取り除くと、結果が良く見えすぎます。
全体の率に加え、重大な誤案内、誤操作、適切な保留、正しい有人引き継ぎを分けます。問い合わせの種類によって難しさが違うため、異なる構成の月次結果を単純比較しないことも大切です。
4. 定期試験と実際の利用状況を組み合わせる
定期試験は決めた条件を繰り返すため、変化に気づきやすい方法です。一方、実際の利用者が新しい表現や予想外の条件で問い合わせる場合もあります。両者を組み合わせて試験を更新します。
定期的に試験会話を流すことは、実際の全会話を監視・評価することとは異なります。Botiumで利用する試験や監視の方式、実行頻度、対象経路を確認し、把握できる範囲を報告に明示します。
5. 判断する担当と更新の流れを決める
業務担当者は期待結果、開発担当者は修正と実装、運用担当者は症状と影響を持ち寄ります。判定が分かれるケースは、誰が正解を確定するかを決めます。ツールの失敗表示だけで、業務仕様の正しさを決定しません。
定例では、未解決の重大不具合、修正したケース、追加した試験、実行できていない範囲を確認します。改善した内容を再試験で確かめ、必要なものを基本セットへ残す流れを作ります。少数でも更新が続く試験が、運用の土台になります。
6. 具体例で確認する
以下は説明のための仮想例です。
架空の月次試験で、前月100件中90件、今月150件中138件が合格だったとします。全体の率だけでは改善とは判断しません。共通する100件の成否、新規50件の結果、重大な失敗の有無を分けます。新規ケースの影響と既存機能の変化を区別することで、次に直す対象を選べます。
7. 最初に確認する三つのこと
- 試験セットと対象ボットに版を付け、前回と共通するケースを識別できるようにします。追加・廃止したケース数も報告に含めます。
- 判定保留、実行エラー、業務上の不合格を区別します。試験が動かなかった状態を、ボットが誤った回答をした状態と混ぜないようにします。
- 改善会議では数値だけでなく代表的な会話を確認します。修正したケースを再試験し、再発防止に必要なものを次回以降の基本セットへ残します。
参考資料
参照日：2026年9月30日。表と具体例は試験設計の提案です。製品の対応範囲・接続方式・利用できる機能は導入構成に合わせてご確認ください。
AI・ボット品質の試験をご検討の方へ
対象ボット・チャネル・業務と合格条件を整理する際は、Botiumによるチャット・音声ボットの品質検証をご覧ください。ボットの会話・業務シナリオの試験を相談するから、自社の構成に合わせた確認範囲をご相談いただけます。