AI・ボット品質の基礎｜第4回
FAQやプロンプトを直したら、別の質問に答えられなくなった。こうした変更による影響を調べるのが回帰試験です。Botiumの活用を念頭に、AIボットの変更前後を比較する準備、判定方法、失敗時の切り分けを説明します。
1. 回帰試験は以前の動作を確かめ直すこと
回帰試験では、変更後も維持すべき機能が動くかを確認します。変更した箇所だけの試験では、共通の案内文や検索設定を通じて別の用件へ及んだ影響を見落とすことがあります。
AIボットでは、モデルだけでなく、プロンプト、参照文書、検索設定、外部API、会話の分岐も変更点になります。どれを変えたのか記録しないと、同じ質問で結果が変わっても理由を追えません。
2. 比較の条件をそろえる
変更前の基準結果を残し、同じ質問・前提データ・判定条件で変更後を実行します。試験のたびに注文状況が変わるデータでは比較が難しいため、テスト用データの初期状態を決めます。
生成AIの応答には揺れがあります。単に文章が違うことを失敗とせず、必要情報の有無と禁止事項の違反を見ます。同条件を複数回試す場合も、都合のよい一回だけを選ばず、試行回数と各結果を残します。
前回と比較する条件は、ボットの前提条件と期待結果の設計を参考にそろえてください。
| 変更点 | 重点的に再試験する対象 | 比較時に固定するもの |
|---|---|---|
| FAQ改訂 | 関連質問と対象外の質問 | 文書の版・適用日 |
| プロンプト変更 | 訂正・拒否・聞き返し | 入力・判定条件 |
| モデル変更 | 主要用件と例外 | 試験データ・実行条件 |
| API変更 | 成功・失敗・再試行 | テスト用状態・応答条件 |
3. 重要な用件と変更周辺を選ぶ
毎回実行する基本セットには、ログイン後の照会、対象外の依頼、有人引き継ぎなどの重要な動作を含めます。これに、今回変更した領域の用件と、紛らわしい周辺用件を加えます。
Botiumの公式製品情報は、開発工程での自動試験とCI/CDでの検証を案内しています。CI/CDは変更を継続して検証・提供する仕組みです。連携して何をもってリリースを止めるかは、チーム側で決める必要があります。
4. 失敗を製品不具合と決めつけない
失敗したら、会話記録、取得した情報、外部処理、判定理由を順に見ます。ボットの不具合だけでなく、テストデータの不足、接続エラー、古い期待結果が原因のこともあります。
新しい業務ルールへ正しく変更した結果、旧ルールを期待するテストが失敗する場合は、期待結果を更新します。ただし失敗を消すためだけに条件を緩めず、仕様変更の承認と関連付けて残します。
5. 公開判断につながる報告を作る
報告には、対象版、試験件数、失敗の内訳、未実施項目、重大な失敗の有無を含めます。「前回より合格率が高い」だけでは、重要な用件の後退を判断できません。
変更に直接関係する試験が通った後も、認証や誤操作防止などの共通部分を確認します。重大な失敗が残る場合の扱い、再試験の範囲、元の版へ戻す判断を事前に決めておくと、結果を運用へつなげやすくなります。
新しいケースを継続的に取り込む方法は、試験データと品質改善の運用で説明しています。
6. 具体例で確認する
以下は説明のための仮想例です。
架空のサポート窓口で、配送案内の表現だけを変更したところ、キャンセル依頼でも配送FAQを返すようになったとします。変更した案内文の表示確認は合格でも、キャンセルの回帰試験は失敗します。会話記録を確認して共通の分類条件の変更が原因と分かれば、その修正後に配送・キャンセルの両方を再試験します。
7. 最初に確認する三つのこと
- 変更したモデル・プロンプト・文書・APIの版を残します。変更していないつもりの外部サービスにも更新がないか確認し、比較条件のずれを記録します。
- 毎回実行する重要なケースと、今回の変更専用のケースを分けます。実行時間を短くする場合も、重大な誤操作を防ぐ確認を省略しないようにします。
- 再試行で成功した場合も最初の失敗を保存します。接続障害なのか応答の揺れなのかを分類し、成功するまで繰り返した結果だけを報告しないようにします。
参考資料
参照日：2026年9月30日。表と具体例は試験設計の提案です。製品の対応範囲・接続方式・利用できる機能は導入構成に合わせてご確認ください。
AI・ボット品質の試験をご検討の方へ
対象ボット・チャネル・業務と合格条件を整理する際は、Botiumによるチャット・音声ボットの品質検証をご覧ください。ボットの会話・業務シナリオの試験を相談するから、自社の構成に合わせた確認範囲をご相談いただけます。